DETAILED ACTION
Information Disclosure Statement
The information disclosure statement (IDS) submitted on February 2, 2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Amendment
The Amendment filed March 18, 2026 has been entered. Claims 1-5, 7-14, and 16-20 remain pending in the application.
Regarding the rejection of claims 1-2, 5-6, 10-11, 14-15, and 19-20 under 35 U.S.C. 102(a)(2) as previously set forth in the Non-Final Office Action mailed January 7, 2026, Applicant’s amendments to the Claims have modified the scope of the claims and warrant new grounds for rejection as set forth below
Regarding the rejection of claims 3-4, 7-9, 12-13, and 16-118 under 35 U.S.C. 103, Applicant’s amendments to the Claims have modified the scope of the claims and warrant new grounds for rejection as set forth below.
Response to Arguments
Applicant’s arguments with respect to claims 1-5, 7-14, and 16-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Interpretation
Claims 3 and 12 both recite “documents and/or files”. In general, claim language drafted using “and/or” is interpreted using the broader interpretation, “or”. “Files” is broader than “documents”, and therefore “documents and/or files” may be shortened to simply read “files”.
Claim Objections
Claims 1, 10, and 19 are objected to because of the following informalities:
Each claim recites “…wherein the secure virtual machine hosts a computing environment that includes cloud computing technology that exists within a Central Processing Unit (CPU) enclave and is configured to isolate data from being accessed while being processed…”. It is grammatically ambiguous which element of the claim “is configured to isolate data from being accessed while being processed”. Examiner notes 3 grammatically correct interpretations of the claim:
“…wherein the secure virtual machine hosts [other claim elements] and is configured to isolate…”
“…wherein the secure virtual machine hosts a computing environment that includes [other claim elements] and is configured to isolate…”
“…wherein the secure virtual machine hosts a computing environment that includes cloud computing technology that [both] exists within a Central Processing Unit (CPU) enclave and is configured to isolate…”
Examiner finds support for the amended limitation at ¶0045 of the accompanying: “For context, in some approaches, confidential computing refers to cloud computing technology that enables data to be isolated from being accessed while being processed.” The specification therefore supports the 3rd interpretation provided above. Examiner requests that the claim be amended to unambiguously distinguish which element “is configured to isolate”.
Appropriate correction is required. Examiner notes the proposed correction below to simultaneously obviate the objections to claims 1, 10, and 19 as well as the rejections under §112(b).
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-5, 7-14, and 16-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.
Claims 1, 10, and 19 recite “the secure virtual machine” in the introduction of the first added “wherein” clause. There is insufficient antecedent basis for this term in the claim. For purposes of examination of the instant application, the claims shall be interpreted as reading “the secure execution virtual machine”.
Claims 2-5 and 7-9 are rendered indefinite by their dependence on claim 1 and are thereby rejected under 35 U.S.C. 112(b).
Claims 11-14 and 16-18 are rendered indefinite by their dependence on claim 10 and are thereby rejected under 35 U.S.C. 112(b).
Claim 20 is rendered indefinite by its dependence on claim 19 and is thereby rejected under 35 U.S.C. 112(b).
Examiner recommends the following language to simultaneously obviate the objections to claims 1, 10, and 19 as well as the rejections under §112(b):
“…wherein the secure execution virtual machine hosts a computing environment which is undiscoverable by a program and includes cloud computing technology configured to isolate data from being accessed while being processed, wherein the cloud computing technology exists within a Central Processing Unit (CPU) enclave …”
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1-2, 5, 10-11, 14, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20220335139 by Yang et al. (hereinafter “Yang”) as previously made of record in view of “Layered Security Analysis for Container Images: Expanding Lightweight Pre-Deployment Scanning”, Majumder et al. (hereinafter “Majumder”) and further in view of “Security Vulnerability Detection Using Deep Learning Natural Language Processing” by Ziems et al. (hereinafter “Ziems”).
Regarding claim 1, Yang discloses:
A method, comprising:
generating an encryption key pair (Yang Fig. 4, 7/[0044]: “The security service 412 then creates 5 a key that is specific to the new layer.”) within a secure execution virtual machine (Yang [0049]: “In the processes described just above [in [0044]]… the security service 312, 412 can… be implemented as… a local service that is implemented on the same chip hardware and/or same computer system as the container engine 301, 401…”) wherein the encryption key pair includes a private key (Yang [0025]: “ …the enclave uses its internal private key…”) and a public key (Yang Fig. 3, 313/Fig. 4, 413), wherein the secure virtual machine hosts a computing environment (Yang Fig. 1: TEE Enclave 108) that includes cloud computing technology (Yang Fig. 1, 101/Fig. 3, Container Engine 301) that exists within a Central Processing Unit (CPU) enclave (Yang Fig 1: The region of 107 that overlaps with 109 is the enclave portion assigned to a particular CPU) and is configured to isolate data from being accessed while being processed (Yang [0019]: “After the information in the container image is unpacked and processed, ideally, an instance of the application is ready for isolated execution on the container engine 104.”), wherein the computing environment is undiscoverable by a program (Yang Fig. 1: Container engine 101 is undiscoverable by any program that does not have access to memory section 106_1, such as the OS of 106_2's respective TEE enclave);
storing the private key within the secure execution virtual machine (Yang [0025]: “ …the enclave uses its internal private key…”);
determining whether any layers of a first container image contain sensitive data (Yang [0033]: “In even further embodiments, some container image layers may not be encrypted (e.g., their content is not deemed sensitive)…”);
in response to a determination that a first of the layers of the first container image includes the sensitive data, using the public key to encrypt the first layer (Yang Fig. 3, 9: “apply decrypted keys [sent from the security service 312] to encrypt[] one or more layers of container image X”); and
in response to receiving a request for the first container image, using the private key to decrypt the first layer in the secure execution virtual machine (Yang [0035]: “After the per image layer keys 5 that are encrypted with the enclave's public key have been received from the security service 312 by the enclave 308, they are decrypted 8 with the enclave's private key.”) to create an unencrypted version of the first container image in the secure execution virtual machine (Yang [0035]: “When all of the layers have been decrypted, the container engine 301 has the full container image in decrypted form and can instantiate its corresponding application.”).
Yang does not disclose scanning each layer of the container using a static analysis tool.
However, Majumder discloses:
scanning the layers of the first container image (Majumder p. 5: “… These layers are then analyzed to identify potentially vulnerable files (PVFs) within the image…”), wherein the scanning is performed using a static analysis tool configured to scan container images (Majumder p. 7: “To enhance our understanding of the image’s vulnerability landscape, we conduct package analysis using the CVE Binary Tool… The tool performs static analysis…”).
Yang and Majumder are art analogous to the claimed invention because all are directed to the security of layered containerized applications. It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to scan each layer with a static analysis tool as taught by Yang in order “[t]o enhance [] understanding of the image’s vulnerability landscape” (Majumder, p. 7).
Neither Yang nor Majumder disclose scanning each layer using a natural language processing (NLP) engine.
However, Ziems describes developing multiple NLP models to analyze code and detect software vulnerabilities. Ziems p. 4: “In this work, we have developed a few deep learning models based on classic NLP architectures for software vulnerability auto detection, including an LSTM model, a bi-directional LSTM model, and a transformer BERT model, in an effort to sufficiently and fairly compare latest models to other techniques. Each model’s objective is to classify a file of code.”
Ziems is art analogous to the claimed invention because both are directed towards securing software. It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to use an NLP engine as taught by Ziems when scanning each layer in order to automate manual analysis of large codebases. See MPEP §2144.04(III).
Regarding claim 2, Yang in view of Majumder and further in view of Ziems discloses:
The method of claim 1, further comprising:
in response to the determination that a second of the layers of the first container image does not include the sensitive data, not encrypting the second layer (Yang [0033]: “In even further embodiments, some container image layers may not be encrypted (e.g., their content is not deemed sensitive)…”).
Regarding claim 5, Yang in view of Majumder and further in view of Ziems discloses:
The method of claim 1, further comprising:
pushing the first container image with the encrypted first layer to a container registry (Yang Fig. 4, 4), wherein the container registry is located outside of the secure execution virtual machine (Yang [0049]: “In the processes described just above [in 0044] the container image registry 311, 411 can… be implemented as… a cloud service where a public network resides between the service and the container engine…”), wherein the container registry is created and maintained for storing container images until the stored container images are requested for use (Yang Fig. 3, 6 is the “request for use”); and
in response to receiving the request for the first container image, pulling the first container image with the encrypted first layer from the container registry into the secure execution virtual machine (Yang Fig. 2, 2) to decrypt the first layer in the secure execution virtual machine (Yang [0035]: “Each key is then used to decrypt its corresponding encrypted layer of the container image.”).
Claim 10 recites:
A computer program product comprising: one or more computer readable storage media (Yang Fig. 1,106); and program instructions stored on the one or more computer-readable storage media to perform operations comprising essentially the method of claim 1. Therefore, claim 10 recites essentially the same content as claim 1 and is rejected for the same reasons.
Claim 11 recites essentially the same content as claim 2 and is rejected for the same reasons.
Claim 14 recites essentially the same content as claim 5 and is rejected for the same reasons.
Claim 19 recites essentially the same content a claim 10, with “computer-readable medium” replaced with “computer system” and “processor set”. In both cases, the patentable weight is placed upon the method performed by the computer system or medium, which is the method of claim 1. Therefore claim 19 recites essentially the same content as claim 1 and is rejected for the same reasons.
Claim 20 recites essentially the same content as claim 2 and is rejected for the same reasons.
Claims 3 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Yang in view of Majumder and further in view of Ziems as applied to claims 1-2 and 10-11 above, and further in view of “Public package repos expose thousands of API security tokens—and they’re active” by A. Polkovnychenko & S. Menashe, available October 18, 2022 from InfoWorld.com (hereinafter “InfoWorld”) as previously made of record and of “Finding API secrets in hidden layers within Docker containers” by Dana Epp, published April 25, 2023 (hereinafter “Epps”).
Regarding claim 3, Yang in view of Majumder and further in view of Ziems discloses:
The method of claim 2, further comprising:
in response to a determination that a third layer of the first container image includes the sensitive data, using the public key to encrypt the third layer (Yang [0035]: “After the per image layer keys 5 that are encrypted with the enclave's public key have been received from the security service 312 by the enclave 308, they are decrypted 8 with the enclave's private key.”); and
in response to receiving the request for the first container image, using the private key to decrypt the third layer in the secure execution virtual machine (Yang [0033]: “In even further embodiments, some container image layers may not be encrypted (e.g., their content is not deemed sensitive).”).
However, Yang in view of Majumder and further in view of Ziems does not disclose gathering information used to identify a pattern of the sensitive data in the first layer of the container image, the nature of the gathered information, or what happens with the gathered information afterwards.
However, InfoWorld discloses:
gathering information (InfoWorld p. 4: “All in all, we scanned more than 8 million artifacts.”) used to identify a pattern of the sensitive data in the first layer of the container image (InfoWorld p. 3-4: Access token prefixes), wherein the gathered information identifies: types of sensitive data that was identified in the first layer in the first container image (InfoWorld p. 3: Access tokens is the type) and owners of the documents and/or files determined to include the sensitive data (InfoWorld p. 4: “Understand the token’s owner (whenever possible) so we could disclose the issue privately to them.”);
storing the gathered information in a knowledge base (InfoWorld p. 4: “All in all, we scanned more than 8 million artifacts.” Examiner notes that while a knowledge base was not explicitly mentioned, a person having ordinary skill in the art would know that scanning 8 million artifacts requires some form of data storage. Additionally, the figures and breakdowns presented throughout InfoWorld demonstrate data analysis performed on the 8 million artifacts, which is known to be possible by taking use of databases/knowledge bases); use the identified pattern to perform a similarity comparison of the first layer and other layers in the first container image (InfoWorld pp. 3-4: Access token prefixes. Examiner notes that the table suggests that one learned pattern could be “Strings that begin with a known prefix, such as AKAI, gho, npm, etc.”), the other layers including the second layer and a third layer (InfoWorld p. 9: Examiner notes that the table shows 3,438 total tokens found in Docker layers, of which 2,055 were active. It would have been obvious to one of ordinary skill in the art that these over 2,000 vulnerable tokens were not in 1 Docker layer. Examiner also notes that “the second layer” of claim 2 which did not need encryption maps to any layer studied by InfoWorld which had no tokens or only inactive tokens, therefore not vulnerable to the vulnerability in question.)
InfoWorld is art analogous to the claimed invention because both are directed towards ensuring the security of containers and other related virtualization technology. It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to combine Yang in view of Majumder and further in view of Ziems and InfoWorld and arrive at the present invention in order to preemptively identify exposed secrets and protect them (InfoWorld p. 17: “We suggest embedding a secrets scanner in your DevOps pipeline and alerting on leaks before publishing a new build.”).
Neither Yang in view of Majumder and further in view of Ziems nor InfoWorld disclose gathering a size of documents and/or files determined to include the sensitive data.
However, Epps discloses gathering a size of documents and/or files determined to include the sensitive data (Epps p. 9: “Dive allows users to quickly access detailed information about each layer such as its size, version history, creation date, content hashes, and dependencies.”).
Epps is art analogous to the claimed invention because both are directed to the security of layered containerized applications. It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to gather size data as taught by Epps because one of ordinary skill may want to perform differing levels of analysis on small files (which may be considered safer on account of containing less data) and large ones (which, by contrast, may be considered less safe).
Claim 12 recites essentially the same content as claim 3 and is rejected for the same reasons.
Claims 4 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Yang in view of Majumder and further in view of Ziems as applied to claims 1-2 and 10-11 above, and further in view of InfoWorld.
Regarding claim 4, Yang in view of Majumder and further in view of Ziems discloses:
The method of claim 1.
Yang in view of Majumder and further in view of Ziems does not disclose the remainder of the claim.
However, InfoWorld discloses:
the sensitive data is selected from the group consisting of: an API key (InfoWorld p. 3-4, Access Token Prefixes; see also p. 3: “As we continued testing, we discovered there were a lot more identified active access tokens than we expected” and p. 6: “In terms of the sheer volume of leaked secrets…”), a secret, a proprietary code, a proprietary configuration, confidential data files, and confidential documents.
InfoWorld is art analogous to the claimed invention because both are directed towards ensuring the security of containers and other related virtualization technology. It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to combine scan for API keys as taught InfoWorld in order to preemptively identify exposed secrets and protect them (InfoWorld p. 3: “Unlike the presence of a code vulnerability, a leaked access token usually means the immediate “game over” for the security team, since using a leaked access token is trivial and, in many cases, negates all investments into security mitigations. It doesn’t matter how sophisticated the lock on the vault is if the combination is written on the door.”).
Claim 13 recites essentially the same content as claim 4 and is rejected for the same reasons.
Claims 7 and 16 are rejected under rejected under 35 U.S.C. 103 as being unpatentable over Yang in view of Majumder and further in view of Ziems as applied to claims 1 and 10 above, and further in view of US 20100011200 by Rosenan et al. (hereinafter “Rosenan”) as previously made of record.
Regarding claim 7, Yang in view of Majumder and further in view of Ziems discloses the method of claim 1.
Yang in view of Majumder and further in view of Ziems does not disclose the remainder of the claim.
However, Rosenan discloses the storing the private key within the secure execution virtual machine comprises:
injecting the private key into a bootloader of the secure execution virtual machine (Rosenan [0012]: “When using the public key algorithm, the private key can be stored in the boot-loader firmware…”).
Rosenan is art analogous to the claimed invention because both are directed towards computer security methods. It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to store the private key in the bootloader as taught by Rosenan in order to prevent “the leakage of information from their internal computer network to the outside world.” Rosenan [0002].
Claim 16 recites essentially the same content as claim 7 and is rejected for the same reasons.
Claims 8 and 17 are rejected under rejected under 35 U.S.C. 103 as being unpatentable over Yang in view of Majumder and further in view of Ziems in view of Rosenan as applied to claims 7 and 16 above, and further in view of US 20130039491 by Unagami et al. (hereinafter “Unagami”) as previously made of record.
Regarding claim 8, Yang in view of Majumder and further in view of Ziems in view of Rosenan discloses the method of claim 7, including injecting the key into the bootloader.
Yang in view of Majumder and further in view of Ziems in view of Rosenan does not disclose taking a particular action, including deletion, on the key after successful decryption.
However, Unagami discloses:
in response to a determination that the first layer is successfully decrypted in the secure execution virtual machine, delete the private key (Unagami [0113]: “…decrypting the encrypted application program, with use of the decryption key…and deleting the decryption key, after the decryption in the decrypting step is completed”; see also [0132]: “The deletion unit 384d deletes the decryption key, after the decryption by the decryption unit 383d is completed”) from the bootloader (Unagami [0014]: “Then, upon completion of the decryption, the protection control module deletes the decryption key. This reduces the possibility of a malicious leak of the decryption key from the protection control module”).
Unagami is art analogous to the claimed invention because both are directed towards securing virtual programs. It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to delete the key after decryption as taught by Unagami from the bootloader of Yang in view of Majumder and further in view of Ziems in view of Rosenan as this “reduces the possibility of a malicious leak of the decryption key” (Unagami [0014]).
Claim 17 recites essentially the same content as claim 8 and is rejected for similar reasons.
Claims 9 and 18 are rejected under rejected under 35 U.S.C. 103 as being unpatentable over Yang in view of Majumder and further in view of Ziems in view of Rosenan and Unagami as applied to claims 1, 8, 10, and 17 above and further in view of US 20220092192 by Wolfson et al. (hereinafter “Wolfson”) as previously made of record.
Regarding claim 9, Yang in view of Majumder and further in view of Ziems in view of Rosenan and Unagami discloses: The method of claim 8, wherein the private key is used to decrypt the first layer.
Yang in view of Majumder and further in view of Ziems in view of Rosenan and Unagami does not disclose the remainder of the claim.
However, Wolfson discloses the decryption occurring during provisioning (Wolfson Fig. 5 502: “Run Initialization Container” is a start-up process) of a virtual server instance on the secure execution virtual machine (Wolfson [0099]: “…embodiments of the invention may be performed in client-server environments, whether network or local environments, or in any other suitable environment”), and the method further comprising:
in response to a determination that the first layer is unsuccessfully decrypted in the secure execution virtual machine, terminating the virtual server instance (Wolfson Fig. 5, 508: “If [Decryption 506] Successful, Run Main Application”; see also Wolfson [0070]: “In one example, the main application container does not start or run unless the initialization container successfully completes”).
Wolfson is art analogous to the claimed invention because both are directed towards the field of securing containerized applications. It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to apply the invention of Yang in view of Majumder and further in view of Ziems in view of Rosenan and Unagami to a virtual server instance and only allow it to run after successful decryption as suggested by Wolfson in order to increase the security of virtual server infrastructure running on or alongside layered container images.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL HABASHI whose telephone number is (571)272-2245. The examiner can normally be reached M-F: 9 AM-6 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, Catherine Thiaw can be reached at (571)270-1138. 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.
DH
Examiner
Art Unit 2407
/Catherine Thiaw/ Supervisory Patent Examiner, Art Unit 2407 6/23/2026
Prosecution Insights