DETAILED ACTION
A preliminary amendment to the claims was received on 12/27/2023 and is acknowledged by the Examiner for examination purpose. In the preliminary amendment, Claims 1, 2, 4, 5, 8-12, and 15-20 have been amended, and Claims 3, 6, 7, 13, and 14 remain original.
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 .
Priority
The instant application 18/574,708 is a 371 of PCT/CN/2023115783, which claims priority to the foreign application CN202310865291.X, which claims the priority filing date of 07/13/2023. Therefore, the effective filing date of the instant application is 07/13/2023.
Oath/Declaration
Applicant’s oath/declaration filed on 12/27/2023 has been reviewed by the examiner and is found to conform to the requirements prescribed in 37 C.F.R. 1.63.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 03/28/2024 and 04/07/2024 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Drawings
The drawings submitted on 12/27/2023 with the instant application are acceptable for examination purposes.
Specification
The specification submitted on 12/27/2023 with the instant application are acceptable for examination purposes.
Claim Objections
Claim 5-7, 9, and 12-16 are objected to because of the following informalities:
In Claim 5, the limitation “and booting the working software when the encryption container is instructed to determine that a local authorization file in the encryption container disk image is legal” could be re-written as “and booting the working software when the encryption container determines that a local authorization file in the encryption container disk image is legal”, or the like, to clarify that the working software is not booted until it is determined to be legal
Claim 12 includes similar limitations to those of Claim 5 and is objected to for the same reasons
In Claim 6, the limitation “when the encryption container is instructed to determine that the local authorization file of the working software is illegal” could be re-written as “when the encryption container is instructed to determine whether the local authorization file of the working software is illegal”, or the like, to clarify that the local authorization file is being determined to be either illegal or legal
Claim 13 includes similar limitations to those of Claim 6 and is objected to for the same reasons
In Claim 7, the limitation “exit abnormally when the encryption container obtains an authorization illegal reply” could be re-written as “terminate the working software when the encryption container obtains an authorization illegal reply”, or the like, to clarify the intended meaning of “exit abnormally”
Claim 14 includes similar limitations to those of Claim 7 and is objected to for the same reasons
In Claim 9, the limitation “booting the working software in a trial state” could be re-written as “booting the working software in a safe state”, or the like, to clarify the intended meaning of “trial state”
Claim 16 includes similar limitations to those of Claim 9 and is objected to for the same reasons
In Claim 15, the limitation “when adapted to instruct the encryption container to obtain an authorization reply from a software server corresponding to the working software, is adapted to instruct …” should read: “when adapted to instruct the encryption container to obtain an authorization reply from a software server corresponding to the working software, is further adapted to instruct …”
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Independent Claims 1, 5, 12, 19, and 20 through repeated use of the similar yet distinct terms “encryption container disk image file”, “encryption container disk image”, and “encryption container”, create confusion regarding the lifecycle of the claimed encryption container. The encryption container is used to decrypt the encryption container disk image file to obtain the encryption container disk image. However, it is not clear how the encryption container could be used to decrypt the encryption container disk image file if the decrypted encryption container disk image would be required to instantiate the encryption container. There is further confusion regarding the intended structural and operational relationships of these elements, in addition to the encryption memory and the working software, because it is unclear which elements exist before decryption, which are instantiated during runtime, and which are artifacts or execution environments. Therefore, the scope of the claim is unclear. For examination purposes, the “encryption container” will be interpreted as a virtual machine, and the “encryption container disk image” will be interpreted as a VM image used to instantiate the VM (encryption container).
Claims 2-4, 6-11, and 13-18 are also rejected due to their respective dependence on Claim 1, 5, and 12
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-4, and 12-20 are rejected under 35 USC 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter. Independent Claim 1 is direct to a software file, which is software per se, and thus, is not patent eligible. Independent Claim 12 is directed to a software running apparatus, described in the instant specification as “a functional module that is required to be set up by the operating system to implement the software running method provided in the embodiments of the present disclosure” (Paragraph [0152]), which does not preclude the apparatus from being interpreted as software per se. Lastly, independent Claims 19 and 20 are both directed to an operating system and a computer system comprising only an operating system, which both may also be interpreted as be directed to subject matter that are implemented as software per se. Therefore, independent Claims 1, 12, 19, and 20 are rejected under 35 USC 101.
Claims 2-4 and 13-18 are also rejected due to their respective dependence on Claims 1, 12, 19, and 20.
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-4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Martinez De La Cruz et al. (US 20230050944 A1), hereinafter Martinez, in view of Lango et al. (US 20180373879 A1), hereinafter Lango.
Regarding Claim 1:
Martinez teaches a software file, comprising: an encryption container disk image file (Martinez – Figure 1: illustration of a container image and paragraph [0051]: … a container image as shown in the lower part of Fig. 1. Paragraph [0055]: To create the container images, the application providing the service should be generated by using an encryption tool that generates an encrypted version of the application software), encrypted by a first encryption key (Martinez – Paragraphs [0056]-[0059]: [0056] An example procedure for creating a container image is discussed below: [0057] In a first step an encryption key or a key pair is created depending on the used encryption scheme. [0058] The application software is then compiled, and a package of the application software is generated. [0059] The encryption entity is used to create the encrypted package by encrypting the application software using the encryption key resulting in the creation of the application layer 51b) and comprising an encryption container disk image packaged with working software (Martinez – Paragraph [0054]: The application layer or second part 51b is unique to every or each container image. It contains the encrypted software package, also called encrypted package hereinafter. This encrypted package comprises a representation of the file system of the application binaries. An example of the encrypted software package is a file in a “tar” format, optionally compressed with “gzip” and encrypted using the corresponding encryption technique and key); a bootstrap program (Paragraph [0051]: the container image 51 comprises a base layer 51a which is generally common to all contain imagers of the application. It can contain a base operating system that provides the basic system binaries, libraries and configuration files. However it is also possible that the container does not include a base operating system if it is not needed by the application. Paragraph [0052]: A decryption entity 90 in the base layer can be a software application that can read an encrypted software package, can decrypt it, can unpack its content into of a file system, and can run a selected software from it), used to [instruct a security processor to] obtain a first decryption key (Martinez – Paragraph [0084]: The decryption entity 90 reads the injected one-time token and presents it to the secure vault 60 in step S43 in order to retrieve the decryption key. The secure vault 60 validates the one-time token, returns the decryption key to the decryption entity 90) corresponding to the first encryption key (Martinez – Paragraph [0013]: Encryption is done using a key. To decrypt the file, a key must be provided. In symmetric encryption schemes, the same key is used for encryption and decryption. In asymmetric encryption schemes a key pair is used: one key is used for encryption, and the other key for decryption), so that an encryption container decrypts the encryption container disk image file according to the first decryption key to obtain the encryption container disk image and the working software (Martinez – Paragraph [0084]: The decryption entity 90 uses the decryption key to decrypt the encrypted software package in step S44) to be stored [[to]]into an encryption memory of the encryption container (Martinez – Paragraph [0085]: The decryption entity 90 uses the volatile file system as destination for the decrypted content; and Paragraph [0109]: the access to the decrypted image is prevented due to the fact that a volatile file system is used, which is accessible only by the container instance), wherein the encryption container is a container corresponding to the encryption container disk image (Paragraph [0066]: A container instance 100 is a container image run by a container runtime 80).
Martinez does not expressly teach … instruct a security processor.
However, Lango teaches instruct a security processor to obtain a first decryption key (Lango – Paragraph [0038]: The instance launch module 106 generates a virtual machine instance based on the encrypted machine image which passes control over to the intermediary guest manager of the newly created instance. The intermediary guest manager establishes a secure connection to the key management module 108 of the management device 107. After the secure connection is established the intermediary guest manager sends a request to unwrap the wrapped KEK to the key management module 108 and receives in response the unwrapped KEK. Using the KEK the intermediary guest manager unwraps the DEK and uses the DEK to boot up the encrypted guest operating system).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Martinez, further incorporating Lango to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Lango’s teaching to employ a security processor to securely access encrypted disk image files into Martinez’s encrypted software file. This additional feature would provide enhanced data protection in the process of accessing/running the encrypted files.
Regarding Claim 2:
The combination of Martinez and Lango teaches the software file according to claim 1.
Martinez further teaches the bootstrap program (Paragraph [0051]: the container image 51 comprises a base layer 51a. It can contain a base operating system that provides the basic system binaries, libraries and configuration files. However it is also possible that the container does not include a base operating system if it is not needed by the application. Paragraph [0052]: A decryption entity 90 in the base layer can be a software application that can read an encrypted software package, can decrypt it, can unpack its content into of a file system, and can run a selected software from it); and to obtain the encryption container disk image and the working software to be stored [[to]]into the encryption memory of the encryption container (Martinez – Paragraph [0084]: The decryption entity 90 uses the decryption key to decrypt the encrypted software package in step S44; and Paragraph [0085]: The decryption entity 90 uses the volatile file system as destination for the decrypted content; and Paragraph [0109]: the access to the decrypted image is prevented due to the fact that a volatile file system is used, which is accessible only by the container instance).
Lango further teaches further comprising a key ciphertext of the first encryption key, wherein the key ciphertext is obtained by encrypting the first encryption key with a second encryption key (Lango – Paragraph [0035]: In some embodiments, the image encryption module 101 takes as input an operating system image and produces a DEK which is then used to wrap the operating system image. In addition, the image encryption module generates a KEK which is used to wrap the DEK. To protect the KEK, the image encryption module 101 establishes a secure channel with the key management module 108 of the management device 107. Using the secure channel, the image encryption module 101 then sends a request to the key management module 108 to wrap the KEK with the account root key associated with the customer/enterprise and return the result back to the image encryption module 101. Upon receiving the wrapped KEK, the image encryption module 101 writes the wrapped KEK and the wrapped DEK onto the label of the encrypted operating system image and uploads the encrypted operating system to the virtual data center 103); [the bootstrap program is used] to instruct the security processor to decrypt the key ciphertext according to a second decryption key to obtain the first encryption key and the first decryption key, so that the encryption container decrypts the encryption container disk image file according to the first decryption key (Lango – Paragraph [0038]: The instance launch module 106 generates a virtual machine instance based on the encrypted machine image which passes control over to the intermediary guest manager of the newly created instance. The intermediary guest manager establishes a secure connection to the key management module 108 of the management device 107. After the secure connection is established the intermediary guest manager sends a request to unwrap the wrapped KEK to the key management module 108 and receives in response the unwrapped KEK. Using the KEK the intermediary guest manager unwraps the DEK and uses the DEK to boot up the encrypted guest operating system); and wherein the first encryption key corresponds to the first decryption key, and the second decryption key corresponds to the second encryption key (Lango – Paragraph [0035]: In some embodiments, the image encryption module 101 takes as input an operating system image and produces a DEK which is then used to wrap the operating system image. In addition, the image encryption module generates a KEK which is used to wrap the DEK. To protect the KEK, the image encryption module 101 establishes a secure channel with the key management module 108 of the management device 107. Using the secure channel, the image encryption module 101 then sends a request to the key management module 108 to wrap the KEK with the account root key associated with the customer/enterprise and return the result back to the image encryption module 101. Upon receiving the wrapped KEK, the image encryption module 101 writes the wrapped KEK and the wrapped DEK onto the label of the encrypted operating system image and uploads the encrypted operating system to the virtual data center 103; and Paragraphs [0082]-[0086]: the intermediary guest manager 210 sends a request to the key management module 108 to unwrap the wrapped KEK, {KEK}.sub.ARK … key management module 108 receives the request and unwraps the {KEK}.sub.ARKusing the account root key… the intermediary guest manager 210 uses the KEK to unwrap {DEK}.sub.KEK … the intermediary guest manager 210 uses the unwrapped DEK to boot up the guest operating system represented by the mounted encrypted operating system image {OSI}.sub.DEK).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 3:
The combination of Martinez and Lango teaches the software file according to claim 2.
Martinez further teaches wherein the second encryption key comprises a second public key, and the second decryption key comprises a second private key (Martinez – Paragraph [0052]: A decryption entity 90 in the base layer can be a software application that can read an encrypted software package, can decrypt it, can unpack its content into of a file system, and can run a selected software from it. Several encryption techniques may be used, providing that all of them require some form of key for decryption and the decryption becomes too complex without the decryption key. The decryption keys can be symmetric, asymmetric, or of any other type).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 4:
The combination of Martinez and Lango teaches the software file according to claim 1.
Martinez further teaches wherein the first encryption key comprises a first public key, and the first decryption key comprises a first private key (Martinez – Paragraph [0052]: A decryption entity 90 in the base layer can be a software application that can read an encrypted software package, can decrypt it, can unpack its content into of a file system, and can run a selected software from it. Several encryption techniques may be used, providing that all of them require some form of key for decryption and the decryption becomes too complex without the decryption key. The decryption keys can be symmetric, asymmetric, or of any other type).
The motivation to combine the arts is the same as that of Claim 1.
Claim(s) 5-8, 10-15, and 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Martinez in view of Lango and Pascual et al. (US 20240160750 A1), hereinafter Pascual.
Regarding Claim 5:
Martinez teaches a software running method for running software (Martinez – Paragraph [0109]: As discussed above, the proposed solution provides a method for running a cloud native application in an untrusted platform using encrypted software packages), adapted to an operating system (Martinez – Paragraph [0051]: As shown, the container image 51 comprises a base layer 51a which is generally common to all contain images of the application. It can contain a base operating system that provides the basic system binaries, libraries and configuration files), wherein the software comprises a software file wherein the software file comprises: an encryption container disk image file (Martinez – Figure 1: illustration of a container image), encrypted by a first encryption key (Martinez – Paragraphs [0056]-[0059]: [0056] An example procedure for creating a container image is discussed below: [0057] In a first step an encryption key or a key pair is created depending on the used encryption scheme. [0058] The application software is then compiled, and a package of the application software is generated. [0059] The encryption entity is used to create the encrypted package by encrypting the application software using the encryption key resulting in the creation of the application layer 51b) and comprising an encryption container disk image packaged with working software (Martinez – Paragraph [0054]: The application layer or second part 51b is unique to every or each container image. It contains the encrypted software package, also called encrypted package hereinafter. This encrypted package comprises a representation of the file system of the application binaries. An example of the encrypted software package is a file in a “tar” format, optionally compressed with “gzip” and encrypted using the corresponding encryption technique and key); a bootstrap program (Paragraph [0051]: the container image 51 comprises a base layer 51a; and Paragraph [0052]: A decryption entity 90 in the base layer can be a software application that can read an encrypted software package, can decrypt it, can unpack its content into of a file system, and can run a selected software from it), used to [instruct a security processor to] obtain a first decryption key (Martinez – Paragraph [0084]: The decryption entity 90 reads the injected one-time token and presents it to the secure vault 60 in step S43 in order to retrieve the decryption key. The secure vault 60 validates the one-time token, returns the decryption key to the decryption entity 90) corresponding to the first encryption key (Martinez – Paragraph [0013]: Encryption is done using a key. To decrypt the file, a key must be provided. In symmetric encryption schemes, the same key is used for encryption and decryption. In asymmetric encryption schemes a key pair is used: one key is used for encryption, and the other key for decryption), so that an encryption container decrypts the encryption container disk image file according to the first decryption key to obtain the encryption container disk image and the working software (Martinez – Paragraph [0084]: The decryption entity 90 uses the decryption key to decrypt the encrypted software package in step S44) to be stored [[to]]into an encryption memory of the encryption container (Martinez – Paragraph [0085]: The decryption entity 90 uses the volatile file system as destination for the decrypted content; and Paragraph [0109]: the access to the decrypted image is prevented due to the fact that a volatile file system is used, which is accessible only by the container instance), wherein the encryption container is a container corresponding to the encryption container disk image (Paragraph [0066]: A container instance 100 is a container image run by a container runtime 80); the software running method comprises: obtaining a booting request to boot the working software of the software file (Martinez – Paragraph [0049]: When instantiating a container instance from the container image, the decryption entity is run and this decryption entity can access a secure vault to retrieve a decryption key. The secure vault can be essentially deployed in a cloud. The decryption entity can, furthermore, use the decryption key to decrypt the encrypted software package into a volatile file system that the container instance mounts and uses as a regular file system. The decryption entity furthermore runs the corresponding software binary; and Paragraph [0050]: the solution discussed below uses a decryption agent that intercepts the container instantiation requests in the container orchestration platform that use container images with encrypted software packages); booting the bootstrap program of the software file according to the booting request (Martinez – Paragraph [0049]: When instantiating a container instance from the container image, the decryption entity is run and this decryption entity can access a secure vault to retrieve a decryption key. The secure vault can be essentially deployed in a cloud) and allocating an encryption memory for an encryption container corresponding to the software file (Martinez – Paragraph [0085]: The decryption entity 90 uses the volatile file system as destination for the decrypted content; and Paragraph [0109]: the access to the decrypted image is prevented due to the fact that a volatile file system is used, which is accessible only by the container instance); [instructing the security processor through] the bootstrap program to obtain the first decryption key of the encryption container disk image file of the software file and sending the first decryption key to the encryption container, so that the encryption container decrypts the encryption container disk image file to obtain the encryption container disk image and the working software (Martinez – Paragraph [0084]: The decryption entity 90 reads the injected one-time token and presents it to the secure vault 60 in step S43 in order to retrieve the decryption key. The secure vault 60 validates the one-time token, returns the decryption key to the decryption entity 90 … The decryption entity 90 uses the decryption key to decrypt the encrypted software package in step S44) to be stored [[to]]into the encryption memory (Martinez – Paragraph [0085]: The decryption entity 90 uses the volatile file system as destination for the decrypted content; and Paragraph [0109]: the access to the decrypted image is prevented due to the fact that a volatile file system is used, which is accessible only by the container instance), wherein the first decryption key corresponds to the first encryption key and the encryption container disk image file is encrypted by the first encryption key (Martinez – Paragraph [0013]: Encryption is done using a key. To decrypt the file, a key must be provided. In symmetric encryption schemes, the same key is used for encryption and decryption. In asymmetric encryption schemes a key pair is used: one key is used for encryption, and the other key for decryption; and Paragraph [0054]: The application layer or second part 51b is unique to every or each container image. It contains the encrypted software package, also called encrypted package hereinafter. This encrypted package comprises a representation of the file system of the application binaries. An example of the encrypted software package is a file in a “tar” format, optionally compressed with “gzip” and encrypted using the corresponding encryption technique and key).
Martinez does not expressly teach instructing a/the security processor.
However, Lango teaches instruct a security processor to obtain a first decryption key (Lango – Paragraph [0038]: The instance launch module 106 generates a virtual machine instance based on the encrypted machine image which passes control over to the intermediary guest manager of the newly created instance. The intermediary guest manager establishes a secure connection to the key management module 108 of the management device 107. After the secure connection is established the intermediary guest manager sends a request to unwrap the wrapped KEK to the key management module 108 and receives in response the unwrapped KEK. Using the KEK the intermediary guest manager unwraps the DEK and uses the DEK to boot up the encrypted guest operating system); and instructing the security processor [through the bootstrap program] to obtain the first decryption key (Lango – Paragraph [0038]: The instance launch module 106 generates a virtual machine instance based on the encrypted machine image which passes control over to the intermediary guest manager of the newly created instance. The intermediary guest manager establishes a secure connection to the key management module 108 of the management device 107. After the secure connection is established the intermediary guest manager sends a request to unwrap the wrapped KEK to the key management module 108 and receives in response the unwrapped KEK. Using the KEK the intermediary guest manager unwraps the DEK and uses the DEK to boot up the encrypted guest operating system).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Martinez, further incorporating Lango to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Lango’s teaching to employ a security processor to securely access encrypted disk image files into Martinez’s encrypted software file. This additional feature would provide enhanced data protection in the process of accessing/running the encrypted files.
The combination of Martinez and Lango does not expressly teach and booting the working software when the encryption container is instructed to determine that a local authorization file in the encryption container disk image is legal.
However, Pascual teaches and booting the working software when the encryption container is instructed to determine that a local authorization file in the encryption container disk image is legal (Pascual – Paragraph [0020]: As discussed in greater detail below, upon receipt of a request to create a confidential container image, processing logic of the container encryption architecture may extract workflow parameters from a submitted container image. The processing logic may also verify that, along with a container image, TEE and attestation server parameters are provided; and Paragraph [0029]: In some embodiments, a user executes a tool that transforms a container image into a confidential container image, specifying the container image to be transformed along with parameters defining a TEE where the confidential container image is going to be executed and attestation server parameters; and Paragraph [0032]: the attestation server verifies that the received launch measurement matches the expected values according to the confidential container image parameters. In some embodiments, if the values match, the attestation server sends the encryption key of the encrypted volume of the disk image. In some embodiments, upon receipt of the encryption key from the attestation server, the Virtualization-based TEE opens the encrypted volume of the disk image, reads the workload parameters to set up an environment, and launches the workload at the workload's designated “entry point.”)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Martinez and Lango, further incorporating Pascual to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Pascual’s teaching to check attestation parameters of encrypted disk image files before allowing the workload to run into Martinez and Lango’s combined software file and method to run the software file. The combined functionality results in security for the system and for the software itself, as only verified software would be permitted to run and unverified software would be identified before being widely distributed.
Regarding Claim 6:
The combination of Martinez, Lango, and Pascual teaches the software running method according to claim 5.
Pascual further teaches further comprising: instructing the encryption container, when the encryption container is instructed to determine that the local authorization file of the working software is illegal, to obtain an authorization reply from a software server corresponding to the working software, so as to boot the working software when the encryption container obtains an authorization legal reply (Pascual – Paragraph [0031]: In some embodiments, to deploy a confidential container image, a user requests the execution of the newly created confidential container image using regular container tools that have been extended to support these kind of images … A container runtime detects the existence of the configuration file within the confidential container image and launches a TEE using an embedded VMM (Virtual Machine Monitor), e.g., libkrun. In some embodiments, the embedded VMM reads the configuration file and creates a Virtualization-based TEE based on the contents of the configuration file. In some embodiments, the Virtualization-based TEE contacts a specified attestation server providing its signed launch measurement; and Paragraph [0032]: the attestation server verifies that the received launch measurement matches the expected values according to the confidential container image parameters. In some embodiments, if the values match, the attestation server sends the encryption key of the encrypted volume of the disk image. In some embodiments, upon receipt of the encryption key from the attestation server, the Virtualization-based TEE opens the encrypted volume of the disk image, reads the workload parameters to set up an environment, and launches the workload at the workload's designated “entry point.”).
The motivation to combine the arts is the same as that of Claim 5.
Regarding Claim 7:
The combination of Martinez, Lango, and Pascual teaches the software running method according to claim 6.
Pascual further teaches further comprising: instructing the encryption container, when the encryption container is instructed to determine that the local authorization file of the working software is illegal, to obtain an authorization reply from a software server corresponding to the working software, so as to exit abnormally when the encryption container obtains an authorization illegal reply (Pascual – Paragraph [0031]: In some embodiments, to deploy a confidential container image, a user requests the execution of the newly created confidential container image using regular container tools that have been extended to support these kind of images … A container runtime detects the existence of the configuration file within the confidential container image and launches a TEE using an embedded VMM (Virtual Machine Monitor), e.g., libkrun. In some embodiments, the embedded VMM reads the configuration file and creates a Virtualization-based TEE based on the contents of the configuration file. In some embodiments, the Virtualization-based TEE contacts a specified attestation server providing its signed launch measurement; and Paragraph [0032]: the attestation server verifies that the received launch measurement matches the expected values according to the confidential container image parameters. In some embodiments, if the values match, the attestation server sends the encryption key of the encrypted volume of the disk image. In some embodiments, upon receipt of the encryption key from the attestation server, the Virtualization-based TEE opens the encrypted volume of the disk image, reads the workload parameters to set up an environment, and launches the workload at the workload's designated “entry point.”).
The motivation to combine the arts is the same as that of Claim 5.
Regarding Claim 8:
The combination of Martinez, Lango, and Pascual teaches the software running method according to claim 6.
Pascual further teaches instructing the encryption container to obtain software authorization feature information of the working software and a software authorization code obtained according to the software authorization feature information; and instructing the encryption container to send the software authorization feature information and the software authorization code to the software server of the working software to obtain the authorization reply (Pascual – Paragraph [0031]: to deploy a confidential container image, a user requests the execution of the newly created confidential container image using regular container tools that have been extended to support these kind of images. In some embodiments, the container tools obtain the confidential container image from a registry and expand it into a local directory in an execution environment. A container runtime detects the existence of the configuration file within the confidential container image and launches a TEE using an embedded VMM (Virtual Machine Monitor), e.g., libkrun. In some embodiments, the embedded VMM reads the configuration file and creates a Virtualization-based TEE based on the contents of the configuration file. In some embodiments, the Virtualization-based TEE contacts a specified attestation server providing its signed launch measurement; and Paragraph [0032]: the attestation server verifies that the received launch measurement matches the expected values according to the confidential container image parameters. In some embodiments, if the values match, the attestation server sends the encryption key of the encrypted volume of the disk image).
The motivation to combine the arts is the same as that of Claim 5.
Regarding Claim 10:
The combination of Martinez, Lango and Pascual teach the software running method according to claim 5.
Martinez further teaches the bootstrap program (Paragraph [0051]: the container image 51 comprises a base layer 51a; and Paragraph [0052]: A decryption entity 90 in the base layer can be a software application that can read an encrypted software package, can decrypt it, can unpack its content into of a file system, and can run a selected software from it).
Lango further teaches wherein the software file further comprises a key ciphertext obtained by encrypting the first encryption key with a second encryption key, the instructing the security processor [through the bootstrap program] to obtain the first decryption key of the encryption container disk image file of the software file and sending the first decryption key to the encryption container, so that the encryption container decrypts the encryption container disk image file, further comprises: instructing the security processor [through the bootstrap program] to obtain a second decryption key for the key ciphertext, decrypting the key ciphertext to obtain the first encryption key and the first decryption key corresponding to the first encryption key (Lango – Paragraph [0038]: The instance launch module 106 generates a virtual machine instance based on the encrypted machine image which passes control over to the intermediary guest manager of the newly created instance. The intermediary guest manager establishes a secure connection to the key management module 108 of the management device 107. After the secure connection is established the intermediary guest manager sends a request to unwrap the wrapped KEK to the key management module 108 and receives in response the unwrapped KEK. Using the KEK the intermediary guest manager unwraps the DEK and uses the DEK to boot up the encrypted guest operating system), wherein the second decryption key corresponds to the second encryption key (Lango – Paragraph [0035]: In some embodiments, the image encryption module 101 takes as input an operating system image and produces a DEK which is then used to wrap the operating system image. In addition, the image encryption module generates a KEK which is used to wrap the DEK. To protect the KEK, the image encryption module 101 establishes a secure channel with the key management module 108 of the management device 107. Using the secure channel, the image encryption module 101 then sends a request to the key management module 108 to wrap the KEK with the account root key associated with the customer/enterprise and return the result back to the image encryption module 101. Upon receiving the wrapped KEK, the image encryption module 101 writes the wrapped KEK and the wrapped DEK onto the label of the encrypted operating system image and uploads the encrypted operating system to the virtual data center 103; and Paragraphs [0082]-[0086]: the intermediary guest manager 210 sends a request to the key management module 108 to unwrap the wrapped KEK, {KEK}.sub.ARK … key management module 108 receives the request and unwraps the {KEK}.sub.ARKusing the account root key… the intermediary guest manager 210 uses the KEK to unwrap {DEK}.sub.KEK … the intermediary guest manager 210 uses the unwrapped DEK to boot up the guest operating system represented by the mounted encrypted operating system image {OSI}.sub.DEK); and instructing the security processor to send the first decryption key to the encryption container, so that the encryption container decrypts the encryption container disk image file using the first decryption key (Lango – Paragraph [0038]: The instance launch module 106 generates a virtual machine instance based on the encrypted machine image which passes control over to the intermediary guest manager of the newly created instance. The intermediary guest manager establishes a secure connection to the key management module 108 of the management device 107. After the secure connection is established the intermediary guest manager sends a request to unwrap the wrapped KEK to the key management module 108 and receives in response the unwrapped KEK. Using the KEK the intermediary guest manager unwraps the DEK and uses the DEK to boot up the encrypted guest operating system).
The motivation to combine the arts is the same as that of Claim 5.
Regarding Claim 11:
The combination of Martinez, Lango and Pascual teach the software running method according to claim 10.
Martinez further teaches wherein the second encryption key comprises a second public key, and the second decryption key comprises a second private key (Martinez - Paragraph [0052]: A decryption entity 90 in the base layer can be a software application that can read an encrypted software package, can decrypt it, can unpack its content into of a file system, and can run a selected software from it. Several encryption techniques may be used, providing that all of them require some form of key for decryption and the decryption becomes too complex without the decryption key. The decryption keys can be symmetric, asymmetric, or of any other type); and the bootstrap program (Martinez – Paragraph [0051]: the container image 51 comprises a base layer 51a; and Paragraph [0052]: A decryption entity 90 in the base layer can be a software application that can read an encrypted software package, can decrypt it, can unpack its content into of a file system, and can run a selected software from it).
Lango further teaches the instructing the security processor through the bootstrap program to obtain the first decryption key of the encryption container disk image file of the software file and sending the first decryption key to the encryption container, so that the encryption container decrypts the encryption container disk image file (Lango – Paragraph [0038]: The instance launch module 106 generates a virtual machine instance based on the encrypted machine image which passes control over to the intermediary guest manager of the newly created instance. The intermediary guest manager establishes a secure connection to the key management module 108 of the management device 107. After the secure connection is established the intermediary guest manager sends a request to unwrap the wrapped KEK to the key management module 108 and receives in response the unwrapped KEK. Using the KEK the intermediary guest manager unwraps the DEK and uses the DEK to boot up the encrypted guest operating system) further comprises: instructing the security processor [through the bootstrap program] to obtain the second private key, decrypting the key ciphertext to obtain the first encryption key and the first decryption key corresponding to the first encryption key; and instructing the security processor to send the first decryption key to the encryption container, so that the encryption container decrypts the encryption container disk image file using the first decryption key (Lango – Paragraph [0038]: The instance launch module 106 generates a virtual machine instance based on the encrypted machine image which passes control over to the intermediary guest manager of the newly created instance. The intermediary guest manager establishes a secure connection to the key management module 108 of the management device 107. After the secure connection is established the intermediary guest manager sends a request to unwrap the wrapped KEK to the key management module 108 and receives in response the unwrapped KEK. Using the KEK the intermediary guest manager unwraps the DEK and uses the DEK to boot up the encrypted guest operating system).
The motivation to combine the arts is the same as that of Claim 5.
Regarding Claim 12:
Claim 12 is an apparatus claim with limitations corresponding to those of method Claim 5. Therefore, Claim 12 is rejected with the same combination and rationale.
The various functional units (i.e. booting request obtaining unit, encryption memory allocation unit, encryption container disk image and working software obtaining unit, working software booting unit) are interpreted as modules (hardware and/or software), the use of which is rendered obvious by at least the teachings of Lango (Lango – Figure 1: example system for implementing a method for unwrapping and launching encrypted images; and Paragraph [0034]: In an embodiment, the on-premises device 100 includes one or more modules, including the image encryption module 101 and the instance startup module 102, which perform various functions. The modules of the on-premises device 100 may be implemented by software executing on the on-premises device 100, hardware components of the on-premises device 100, or combinations thereof. However, for the following explanations, the modules are described in terms of logic for performing functions associated with each of the respective modules. In some embodiments, the modules may represent instructions or scripts which when executed perform the tasks and/or responsibilities associated with each respective module).
Regarding Claim 13:
Claim 13 is an apparatus claim with limitations corresponding to those of method Claim 6. Therefore, Claim 13 is rejected with the same combination and rationale.
Regarding Claim 14:
Claim 14 is an apparatus claim with limitations corresponding to those of method Claim 7. Therefore, Claim 14 is rejected with the same combination and rationale.
Regarding Claim 15:
Claim 15 is an apparatus claim with limitations corresponding to those of method Claim 8. Therefore, Claim 15 is rejected with the same combination and rationale.
Regarding Claim 16:
Claim 16 is an apparatus claim with limitations corresponding to those of method Claim 9. Therefore, Claim 16 is rejected with the same combination and rationale.
Regarding Claim 17:
Claim 17 is an apparatus claim with limitations corresponding to those of method Claim 10. Therefore, Claim 17 is rejected with the same combination and rationale.
Regarding Claim 18:
Claim 18 is an apparatus claim with limitations corresponding to those of method Claim 11. Therefore, Claim 18 is rejected with the same combination and rationale.
Regarding Claim 19:
Claim 19 is an operating system claim with limitations corresponding to those of method Claim 5. Therefore, Claim 19 is rejected with the same combination and rationale, with Martinez teaching the additional claim element including: An operating system, wherein the operating system is capable of executing a program for implementing the software running method according to claim 5 (Martinez – Paragraph [0051]: As shown, the container image 51 comprises a base layer 51a which is generally common to all contain images of the application. It can contain a base operating system that provides the basic system binaries, libraries and configuration files).
Regarding Claim 20:
Claim 20 is an operating system claim with limitations corresponding to those of method Claim 5. Therefore, Claim 20 is rejected with the same combination and rationale, with Martinez teaching the additional claim element including: A computer system, comprising: an operating system, wherein the operating system is capable of executing a program for implementing the software running method according to claim 5 (Martinez – Paragraph [0051]: As shown, the container image 51 comprises a base layer 51a which is generally common to all contain images of the application. It can contain a base operating system that provides the basic system binaries, libraries and configuration files).
Claim(s) 9 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Martinez in view of Lango, Pascual, and Beardall et al. (EP 3168768 A1).
Regarding Claim 9:
The combination of Martinez, Lango and Pascual teaches the software running method according to claim 5.
Lango further teaches when the encryption container is instructed to be connected to a software server of the working software (Lango – Paragraph [0031]: A container runtime detects the existence of the configuration file within the confidential container image and launches a TEE using an embedded VMM (Virtual Machine Monitor), e.g., libkrun. In some embodiments, the embedded VMM reads the configuration file and creates a Virtualization-based TEE based on the contents of the configuration file. In some embodiments, the Virtualization-based TEE contacts a specified attestation server providing its signed launch measurement).
The combination of Martinez, Lango, and Pascual does not expressly teach booting the working software in a trial state when the encryption container is instructed to be connected to a software server of the working software and the encryption container is not capable of being connected to the software server.
However, Beardall teaches booting the working software in a trial state when the … the [encryption container] is not capable of being connected to the software server (Beardall – P. 5: Some software applications currently include a grace or expiry period for coping with network instability or short interruption to the licence server. The grace period allows the application to continue to run (remain in a 'licensed state') in the event that the licence becomes unavailable e.g. connection to the license server is lost. That grace period is reliant on the application having successfully launched and acquired a licence in the first place; and P. 8: In embodiments, the software includes an expiry date/period or grace period feature permitting off-line use of the software if within a specified grace period … data that may be stored in the encrypted configuration file includes, but is not limited to: computer host name; computer domain; computer MAC address(es); expiry date/time (current date/time plus grace period); username (including domain) of the computer account that is running the software; product and feature IDs of all the licenses that are currently checked out by the software; process ID if the running software; and a copy of the license key memory data).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Martinez, Lango, and Pascual, further incorporating Beardall to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Beardall’s teaching to allow a limited grace period to run an unverified software file into Martinez, Lango, and Pascual’s combined software file and method to run the software file. This additional functionality establishes a fallback to allow limited access to the software file in the event that connectivity to some software attestation server becomes temporarily unavailable.
Regarding Claim 16:
Claim 16 is an apparatus claim with limitations corresponding to those of method Claim 9. Therefore, Claim 16 is rejected with the same combination and rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Brasher et al. (US 20190005244 A1) teaches a secure boot mechanism in which a series of boot loaders can operate on encrypted disks
Maino et al. (US 20110302400 A1) teaches methods for securely booting and running a VM image in an untrusted cloud, including the use of public/private key pairs for authentication
Itkin (US 10984107 B2) teaches a secure boot that includes authentication via codes and keys
Xu (US 20200356673 A1) teaches a method for booting a system using an unencrypted bootloader unseal a secret used to decrypt encrypted data in a storage
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS JOSEPH DILUZIO whose telephone number is (703)756-1229. The examiner can normally be reached Mon - Fri -- 7:30 AM - 5 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, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/NICHOLAS JOSEPH DILUZIO/Examiner, Art Unit 2498
/YIN CHEN SHAW/Supervisory Patent Examiner, Art Unit 2498
Prosecution Insights