DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-5 are pending. Claims 6-19 are cancelled.
Response to Arguments
Regarding: Prior Art Rejections:
Applicant’s amendments and arguments regarding the rejection of claims 1-5 under 35 U.S.C. 102/103 have been fully considered and are found to be not persuasive.
Applicant’s remarks recite:
Claim 1 now expressly requires that verification of availability of each associated predefined modular image file operates as a condition precedent to generating and transmitting the container image manifest in response to the request for execution. Neither Douglas nor Ramachandra, alone or in combination, teaches or suggests this control flow. Douglas generates and transmits manifests without any verification-based gating, while Ramachandra verifies images only in the context of offline import and repository population, not execution-time assembly. The Office Action does not articulate any reasoning, grounded in the references themselves, that would motivate a person of ordinary skill in the art to modify Douglas's on-demand manifest generation to incorporate Ramachandra's import-oriented verification logic in a manner that conditions manifest generation and transmission on verification success.
On further examination of Ramachandra, the steps disclosed in Fig 7A along with specification [0082] suggest the system validates whether the user’s request is valid/authorized to obtain the container images associated with the request. This control flow is akin to applicant’s newly amended limitation of ensuring each image is verified to be accessible/available to the user prior to generating/creating the container image manifest. The system can approve or deny the request. On approval, the container image manifest is created.
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.
Claims 1, 2 are rejected under 35 U.S.C. 103 as being unpatentable over Douglas et al. US 20240086168 A1 in view of Ramachandra et al. US 20240061667 A1.
Regarding claim 1, Douglas teaches the invention substantially as claimed including:
A computer-implemented method for assembling an executable image file for execution as a software container element at a terminal ([0015] providing a virtual image server that behaves as a smart container registry that builds container images on the fly using existing image files, instead of building a container image and pushing it to the image registry. The smart container registry may generate image manifests on the fly for a container image based on image tags that define the image files/packages that the container image needs), comprising the steps of:
transmitting, via a container engine element at the terminal that is configured to execute executable image files, a request for a named executable image file for execution as the software container element to a dynamic container proxy at a server ([0028] When a user wishes to obtain a container image comprising a combination of different image files 223, they can aggregate the code name of each image file 223 they require into an image tag … the user may provide an image tag of JDK11.0-MVN3.8-GRD7.0 to the container host 214, which may send this image tag to the virtual image server 160);
parsing, by the dynamic container proxy, the named executable image file to identify associated predefined modular image files for the named executable image file ([0029] When a container image defined by JDK11.0-MVN3.8-GRD7.0 is requested, the virtual image server 160 may parse the code name of each requested image file 223 from the image tag);
creating, by the dynamic container proxy, a container image manifest that identifies each associated predefined modular image file for the executable image file ([0029] Once the image registry 150 has served the image files 223A-C, the virtual image server 160 may then dynamically generate an image manifest 224 corresponding to JDK11.0-MVN3.8-GRD7.0);
transmitting, by the dynamic container proxy, the container image manifest to the container engine element ([0034] The virtual image server 160 may also provide the image manifest 224 to the container host 214);
receiving, by the container engine element, each of the predefined modular image files identified on the container image manifest from the container registry ([0035] The container host 214 may use the image manifest 224 to obtain the corresponding binary content for image files 223A-C an individual layers as discussed herein; [0043] the corresponding binary content may be redirected or proxied through the virtual image server 160 from the image registry 150.);
assembling an executable image file, for execution as the software container element, from the received predefined modular image files ([0043] At block 425, the container host 214 may then build a container image 221 for JDK11.0-MVN3.8-GRD7.0 using the obtained binary content), each of the received predefined modular image file comprising at least one layer defining executable instructions ([0030] When the container host 214 builds a container image in the traditional manner, it may layer each component image file (base layer) on top of each other in a particular order as specified by an image manifest of the container image),
responsive to executing the executable image file, providing the software container element as an element that contains executable software defined by the executable image file and that is executable on one or more processors of a computing device ([0022] The container host 214 may add a new writable (e.g., in-memory) layer on top of the underlying base layers 201 and 202. This new writable layer is illustrated as the in-memory layer 203 in FIG. 2. When the container is deleted, the in-memory layer 203 is also deleted. However, the underlying container image 200 remains unchanged. Although illustrated as having two base layers for simplicity, container image 200 may include any suitable number of base layers (image files). Base layers may define the runtime environment as well as the packages necessary for a containerized application to run); and
via the software container element, executing the executable software in an isolated computing environment ([0018] Many application instances can be running in containers on a single host without visibility into each other's processes, files, network, and so on. In some embodiments, each container may provide a single function (often called a “micro-service”) or component of an application, such as a web server or a database, though containers can be used for arbitrary workloads. In this way, the container host 214 provides a function-based architecture of smaller, decoupled units that work together).
While Douglas teaches retrieving specific versions of image files, it does not explicitly teach verifying, by the dynamic container proxy, that each associated predefined modular image file for the executable image file on the container image manifest is available from a container registry at the server.
However, Ramachandra teaches verifying, by the dynamic container proxy, that each associated predefined modular image file for the executable image file on the container image manifest is available from a container registry at the server ([0063] Image lookup 502, in conjunction with remote repository 504, verifies whether requested container images are valid and available from an upstream repository 551-553 and whether the user is permitted (for example, based on the user's job function) to obtain the requested container images), wherein the container image manifest is generated for transmission to the container engine element only upon successful verification that each associated predefined modular image file is available from the container registry (Fig 7A; [0082] verification by image store 503 at block 703 may ascertain that the requested container images are available from upstream repositories. Image lookup engine 502 utilizes validation information from image store 503 to inform image checker 501 whether the requested container images are valid. Moreover, image checker 501 may determine whether the requested container images are consistent with the user's job function. For example, either through an automated process and/or manual gateway, if the requested container image involves important functions of the computer infrastructure and the user is not an administrator, image checker 501 may deny the user's request. If the request is deemed valid by image checker 501, image checker 501 may create or modify the manifest file associated with the user at block 705 and store it at tracking repository 512 at block 706; Examiner notes: process of figure 7A suggests control flow of verifying images to create manifest file i.e., if image is valid, then create manifest file);
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Ramachandra’s verification of container images with the system of Douglas. A person of ordinary skill in the art would have been motivated to make this combination to provide Douglas’ system with the advantage of improved security in accessing container images by first validating user authentication for requested container images prior to generating container image manifests (see Ramachandra [0004] Container images are often stored in a registry (repository) that is either private or public on a repository, such as Docker Hub. The image creator pushes it to the registry, and a user pulls the image when they want to run it as a container. Features such as Docker Content Trust rely on digital signatures to help verify that images files downloaded from public repositories are original and unaltered. However, this added verification of authenticity does not prevent the creation or distribution of malware; [0082] if the requested container image involves important functions of the computer infrastructure and the user is not an administrator, image checker 501 may deny the user's request. If the request is deemed valid by image checker 501, image checker 501 may create or modify the manifest file associated with the user at block 705 and store it at tracking repository 512 at block 706).
Regarding claim 2, Douglas and Ramachandra teach the method as claimed in claim 1.
Douglas further teaches assembling the executable image file from at least one first predefined modular image file of said received predefined modular image files and at least one second predefined modular image file of said received predefined modular image files ([0015] Multiple code names may be aggregated into an image tag defining all the component image flus/packages that a container image must have. When an image tag is received by the virtual image server, the virtual image server may parse the tag and pull the image file corresponding to each code name in the image tag from the image registry),
whereby at least one of or each said first predefined modular image file comprises at least one layer defining executable instructions that cannot be executed as the software container element without executable instructions defined by at least one layer of at least one said second predefined modular image file ([0022] The container image 200 may include base layers 201 and 202, each of which may correspond to an image file themselves … Base layers may define the runtime environment as well as the packages necessary for a containerized application to run Any changes (e.g., data to be written by the application running on the container) may be implemented in subsequent (upper) layers such as the in-memory layer. Changes made in the in-memory layer may be saved by creating a new layered image; Examiner notes: in-memory layer requires base layer to execute).
Claims 3, 4, and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Douglas et al. US 20240086168 A1 in view of Ramachandra et al. US 20240061667 A1 in view of Vajravel et al. US 11308001 B1.
Regarding claim 3, Douglas and Ramachandra teach the method as claimed in claim 2.
Douglas further teaches providing the at least one second predefined modular image file as at least one base operating system image file and at least one software dependencies image file ([0022] Although illustrated as having two base layers for simplicity, container image 200 may include any suitable number of base layers (image files). Base layers may define the runtime environment as well as the packages necessary for a containerized application to run; [0025] the image file 223A may correspond to version 3.8 of the Maven package (MVN3.8), the image file 223B may correspond to version 7.0 of the Gradle package (GRD7.0), and the image file 223C may correspond to version 11.0 of the Java development kit (JDK) package (JDK11.0); Examiner notes: it is understood that the base layer image file must contain the operating system executing within the container).
Douglas does not explicitly teach providing the at least one first predefined modular image file as at least one peripheral device driver image file.
However, Vajravel teaches providing the at least one first predefined modular image file as at least one peripheral device driver image file (peripheral arbitrator 206 and container agent 212 may implement driver mapping to make peripheral 201a available to application 213. By provisioning peripheral 201a at the function level, peripheral arbitrator 206 can simultaneously provision peripheral 201a to other containers on computing device 200. For example, if hardware container 215 is created on computing device 200 while software container 211 is running, peripheral arbitrator 206 could provision peripheral 201a to hardware container 215 to allow application 216 to access it, Col 10 5-14; Examiner notes: by implementing driver mapping within the container, the driver for the peripheral is introduced to the container).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Vajravel’s peripheral arbitrator driver mapping between containers and peripherals with the system of Douglas. A person of ordinary skill in the art would have been motivated to make this combination to provide Douglas’ system with the advantage of containerized applications being able to interface with system peripheral devices (see Vajravel Col 2 6-8 it is becoming common to run user interactive applications in containers. In such cases, it may be necessary to allow the containers to access peripherals.).
Regarding claim 4, Douglas, Ramachandra, and Vajravel teach the method as claimed in claim 3.
Vajravel further teaches providing the at least one peripheral device driver image file as a scanner driver image file and/or a printer driver image file and/or a scale driver image file and/or a laser scanner driver image file (the peripherals could include a webcam, a microphone, a USB storage drive, a printer, etc., Col 4 lines 15-17; peripheral arbitrator 206, which will have determined that printer class peripherals should be provisioned to software container 211, may determine that peripheral 201a is a printer class peripheral. As a result, in step 1b, peripheral arbitrator 206 may instruct container agent 212 that peripheral 201a should be accessible within software container 211. For example, peripheral arbitrator 206 could send container agent 212 an identifier of peripheral 201a and any information necessary to create a representation of peripheral 201a (e.g. a symbolic link) within software container 211. In step 1c, container agent 212 can then enable access to peripheral 201a such as by creating a symbolic link for peripheral 201a within software container 211. After step 1c, application 213 will “see” peripheral 201a and will therefore be able to send requests to it, Col 7 56 – Col 8 4).
Alongside claim 3, it would be obvious to one of ordinary skill in the art to be motivated to combine Vajravel with Douglas to be able to utilize various peripheral devices (printers, scanners, etc.) from containerized applications.
Regarding claim 5, Douglas, Ramachandra, and Vajravel teach the method as claimed in claim 3.
Douglas further teaches providing the software dependencies image file as an image file comprising a driver layer and/or a common layer and/or a utilities layer ([0025] the image file 223A may correspond to version 3.8 of the Maven package (MVN3.8), the image file 223B may correspond to version 7.0 of the Gradle package (GRD7.0), and the image file 223C may correspond to version 11.0 of the Java development kit (JDK) package (JDK11.0)).
Conclusion
Any inquiry concerning this communication or earlier communications from the
examiner should be directed to HARRISON LI whose telephone number is (703) 756-1469. The
examiner can normally be reached Monday-Friday 9:00am-5:30pm ET.
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 Li can be reached on (571) 272-4169. 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.
/H.L./
Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights