DETAILED ACTION
Claims 1-4 are pending.
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 .
Claim Rejections - 35 USC § 102
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 following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1 and 3 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Wang et al. (US 2024/0118916 A1).
Wang was cited in the previous Office Action.
Regarding claim 1, Wang teaches the invention as claimed including an information handling system (Fig. 2, Edge Cloud 240) comprising:
a processor ([0050] a Central Processor Unit (CPU) executing first instructions); and
a container orchestrator comprising a program of instructions configured to, when read and executed by the processor, in a distributed ecosystem comprising a plurality of host systems, in connection with a build of a new container image to be stored in a container image repository associated with the distributed ecosystem (Fig. 2, edge cloud (i.e., distributed ecosystem); Abstract: create a third file by integrating contents of the first file and the second file, the third file being a Virtual Execution Environment (VEE) image, store the third file, and deploy the third file to a container runtime environment for execution.; [0052] The machine readable instructions may be distributed across multiple hardware devices and/or executed by two or more hardware devices [0146] an apparatus comprising interface circuitry, machine readable instructions, and programmable circuitry to at least one of instantiate or execute the machine readable instructions to process a request to access a data structure, the data structure including a common layer and a supplemental layer, the common layer associated with a first file to be used in creation of a local file structure, the supplemental layer associated with a second file to be used to supplement the local file structure to implement a Virtual Execution Environment (VEE) image; [0149] wherein the VEE image is at least one of a container image; Fig. 2, Application Launcher circuitry 250 corresponds to the container orchestrator):
identify, based on existing container images stored in the container image repository, existing dependency layers of the existing container images for which the new container image has dependencies ([0036] the application launcher circuitry 250 pulls (e.g., retrieves, obtains, requests, etc.) the container image 100 of the application 270, 272, 274 from the remote image repository 220. In some examples, the size of the image is relatively small (e.g., less than 300 megabytes). The application launcher circuitry 250 parses the container image 100 and starts to build a file structure for the application(s) 270, 272, 274 based on the files associated with the common layer 110 and the supplemental layer 120.; [0038] For the common layer 110, the application launcher circuitry 250 checks whether files associated with the common layer 110 have been cached before (e.g., are cached locally within the local file cache pool 260). The application launcher circuitry 250 may then reuse the cached files if they exist. Alternatively, the application launcher circuitry 250 can initiate a request for the files from the remote image repository 220.; [0040] This container image contains all dependencies required by those applications. Using such an approach simplifies the building and/or release of applications. When launching one of those applications, not all files in the container image are required.; [0061] Accessing this data can allow the container image analyzer circuitry 320 to determine whether files associated with the common layer 110 has been cached or needs to be retrieved from the central cloud 210);
identify application-specific layers of the new container image unique to the new container image ([0039] For each file associated with the supplemental layer 120, the application launcher circuitry 250 obtains a file corresponding to the hash value (either from the local file cache pool 260 or from the remote file cache pool 230).; [0062] In some examples, when the supplemental layer 120 is analyzed, one or more files are accessed from the supplemental layer 120 (e.g., via the supplemental layer data 124). Accessing the files associated with the supplemental layer 120 can allow the container image analyzer circuitry 320 to determine if the files associated with the hash value of the supplemental layer has been cached or need to be retrieved from the central cloud 210.); and
build and store the new container image in the container image repository, the image including the application-specific layers and the dependency layers (Abstract: create a third file by integrating contents of the first file and the second file, the third file being a Virtual Execution Environment (VEE) image, store the third file, and deploy the third file to a container runtime environment for execution. [0037]; [0042] Since the application launcher circuitry 250 knows which application is going to be launched, the application launcher circuitry 250 can analyze the dependency of this application and fetch all required files when building the file structure.; [0059]; [0063-64]; [0127] Example 9 includes the apparatus of any of examples 1-8, wherein the VEE image is at least one of a container image, a virtual machine, or an operating system.).
Regarding claim 3, it is a method type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above.
Response to Arguments
Applicant's arguments filed on 06/10/2026 have been fully considered but they are not persuasive.
In Remarks Applicant argues:
Rejections under 35 U.S.C. & 102(a)(1)
For example, Applicant submits that Wang fails to teach, either expressly or inherently:
in connection with a build of a new container image to be stored in a container image repository associated with the distributed ecosystem: identify, based on existing container images stored in the container image repository, existing dependency layers of the existing container images for which the new container image has dependencies; identify application-specific layers of the new container image unique to the new container image; and build and store the new container image in the container image repository, the image including the application- specific layers and the dependency layers,
as recited in Claim 1 and as similarly recited in Claim 3.
Wang is not concerned with the build of a new container image at all, much less with identifying layers of pre-existing container images stored in a repository for incorporation into a newly-built container image. To the contrary, Wang is directed to the deployment and launch of a pre-existing container image at an edge cloud in a network-constrained environment. Wang's container image format is fixed at authoring time as a "common layer" and a "supplemental layer" (see Wang at FIG. 1; [0027]-[0031]), and Wang's "application launcher circuitry 250" merely consumes that pre-existing image - by parsing it into its common and supplemental layers, checking the local file cache pool 260 for previously-cached files, and either re-using the cached files or fetching them from the remote image repository 220 or remote file cache pool 230 in order to build a runtime file structure and launch the application. See Wang at FIG. 5; [0024]-[0025], [0038]-[0040], [0061]-[0063]. That is a launch-time file-fetching workflow, not the build-time image creation workflow recited by Claim 1.
Critically, nothing in Wang teaches "identify[ing], based on existing container images stored in the container image repository, existing dependency layers of the existing container images for which the new container image has dependencies." Wang's common and supplemental layers are properties of the single container image being launched; Wang does not survey the contents of other container images stored in the remote image repository 220 to detect dependency layers for a new container image being built. Wang's local file cache pool 260 is described as a cache of files associated with the layers of the image being launched - not a registry of "existing container images stored in the container image repository" against which a new image's dependencies are matched. The portions of Wang cited by the Office Action (e.g., [0037], [0042], [0059], [0063]-[0064], and [0127]) do not bridge this gap; at most, they confirm that Wang's application launcher knows which application is going to be launched and fetches the files needed to build that application's file structure. They do not disclose, either expressly or inherently, identifying dependency layers of other, pre-existing images stored in the repository for purposes of building a new image to be stored in that repository.
Equally, Wang does not teach "identify[ing] application-specific layers of the new container image unique to the new container image" in the context of a build of a new container image. Wang's "application layer" (Wang at FIG. 7, element 710) is a pre-defined, encrypted layer of an existing container image - not a layer identified during the build of a new image as being unique to that new image relative to the contents of other images stored in the repository. Nor does Wang teach "build[ing] and stor[ing] the new container image in the container image repository, the image including the application-specific layers and the dependency layers." Wang's storing of files in the local file cache pool 260 (Wang at [0039]; FIG. 5, block 585) is a caching operation performed at launch, not the building and storing of a new container image - comprising identified application-specific layers and identified dependency layers - into the container image repository.
In response to the Remarks above,
Examiner respectfully disagrees with the Applicant. Examiner submits that Wang as cited teaches the creation of a third file/Virtual Execution Environment (VEE) image which is further defined in [0127] as “a container image”. This third file is created by integrating the contents of the first file and the second file. The first file is associated with a common layer and the second file with a supplemental layer. A central cloud comprises a remote image repository that stores all container images within an environment that can be accessed by the edge cloud. Further, the image repository populates both the common layer and the supplemental layer. Further, Wang teaches “The application launcher circuitry 250 parses the container image 100 and starts to build a file structure for the application(s) 270, 272, 274 based on the files associated with the common layer 110 and the supplemental layer 120.”. Wang’s common layer comprises base elements such as a base OS layer and the supplemental layer adds, subtracts and/or replaces data on the base layer information. The third VEE file is created and stored as described in [0119]. In regards to Applicant’s argument that Wang focuses on a “a launch-time file-fetching workflow, not the build-time image creation workflow recited by Claim 1” Examiner directs attention to Wang’s [0024] “a container launcher requests common files from the local file pool when needed during launching of an application or building of a local file structure to launch/execute an application”. Accordingly, Applicant’s argument is not persuasive and the rejection is maintained.
Conclusion
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORGE A CHU JOY-DAVILA whose telephone number is (571)270-0692. The examiner can normally be reached Monday-Friday, 6:00am-5:00pm.
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, Aimee J Li can be reached at (571)272-4169. 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.
/JORGE A CHU JOY-DAVILA/Primary Examiner, Art Unit 2195
Prosecution Insights