DETAILED ACTION
Status of Claims
Claims 1 – 20 are pending.
Claims 1, 8 and 15 are independent.
This office action is Non-Final.
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 § 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 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Shanker et al. (US Patent Application Publication No. 2019/0235879, hereinafter “Shanker”), in view of Kashyap et al. (US Patent Application Publication No. 2012/0198442, hereinafter “Kashyap”, in even further view of Glaum et al. (US Patent Application Publication No. 2005/0132123, hereinafter “Glaum”).
As per claim 1, Shanker teaches a method comprising: obtaining, on a first hardware platform, a container image corresponding to a containerized first operating system (OS) [0006: a chain of container definitions whose base image is a boot OS (base boot OS 210, layer 0)., 0018: base images include Red Hat OS image , 0026, 0030 – 0031: these are the inputs to controller 420];
extracting, from the container image, … a specification … [0021: In one or more implementations, a specification may include configuration information. For example, the configuration information may include Docker configuration information. For instance, the Docker configuration information may include a Docker configuration file.];
generating, by a processing device, a disk image based on the specification [method 500, fig. 5, 0007: The method includes a controller machine creating a single partition within an output VM disk file (e.g., a VMdisk file) where the single partition comprises a master boot record and a partition table, forming a valid file system in a main partition of the output VM disk file, arranging an input set of container image definitions as a list where a base image forms a head of the list and subsequent images follow in the list, sequentially processing the list for each image by adding the input set of container image definitions to the output VM file; and applying a final networking configuration over the output VM file; 0031 - 0033]; and
storing the disk image in a storage device according to the specification [0008: The system includes a controller and a memory coupled to the controller and configured to store programmed instructions and an output VM disk file. ].
However, Shanker does not explicitly teach “… extracting, from the container image, metadata of the containerized first OS, the metadata comprising a specification of a second OS configured to be executed on a second hardware platform different from the first hardware platform…”.
Kashyap is cited to teach a container whose metadata covers multiple operating systems and versions, which avoids maintaining a separate appliance per OS and version [0018-0020]. Kashyap improves Shanker’s invention, as carrying target-specific metadata inside the container would let one container drive the creation of the correct bootable disk for each target. The container becomes self-describing. Both Kashyap and Shanker are directed toward deployment of container images to VMs and partitions.
As per claim 1, Kashyap further teaches extracting, from the container image, metadata of the containerized first OS, the metadata comprising a specification of a second OS [0004, 0020, 0045 – 0048: virtual container includes the application computer program, and metadata representing the operating system requirements, 0051, 0055, 0065: metadata for second OS].
Glaum is cited to teach generating a disk image file on a build machine for a different target device. The input is a specification (memory configuration file 236) describing that device’s memory layout, reserved regions and partitions. Glaum improves Shanker by allowing the container to be adapted to more targets; Glaum drives partition creation from a machine-readable specification of the target, as embedded devices may need partitions tailored to the device, and the storage technology may impose its own layout requirement [0009, 0016, 0036, 0041, 0045]. Both Glaum and Shanker are directed toward generating partitioned, bootable OS images for target device.
As per claim 1, Glaum further teaches … extracting, from the container image, … a specification of a second OS configured to be executed on a second hardware platform different from the first hardware platform… [memory configuration file 236 describes the target device’s RAM and flash layout, reserved regions, and partitions for the platform. CPU architecture restrictions and CPU type field usCPUType tie it to the target hardware 0045, 0047, 0048, 0053, 0064, 0073, 0121: metadata for target hardware].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Shanker, Kashyap, Glaum, as the combination explicitly teaches what data the image generator reads (the container’s metadata) and which layout it writes (the multi-partition, MBR based layout from the specification).
As per claim 2, Shanker teaches the method of claim 1, wherein obtaining the container image comprising accessing a container registry1 on the first hardware platform [0029: Docker engine 336 interfaces with the plurality of containers 340, including containers 340a, 340b, 340c, and 340d. Each of the containers 340 includes applications as well as bins and libraries.].
As per claim 3, Kashyap and Glaum teaches the method of claim 1, wherein extracting the metadata comprises: accessing a label2 of the container image; and determining, based on the label, a partition layout of the first hardware platform and a bootloader location of the first hardware platform [Glaum: 0038, 0047 – 0048, 0057, 0064: configuration defines the partition layout and reserved regions, including fixed address IPL and EBOOT regions. The bootloader 214 and IPL 215 are pre-pended to the file; Kashyap: 0046, 0065: metadata caried with the container, including OVF metadata].
As per claim 4, Shanker teaches the method of claim 1, wherein generating the disk image comprises: generating a data structure comprising a partition table of the first hardware platform [0007, 0032, claim 6: the single partition comprises a master boot record and a partition table].
As per claim 5, Glaum teaches the method of claim 4, wherein generating the disk image further comprises: validating the partition table of the first hardware platform based on the specification [detects invalid configurations, such as a partition on a nonexistent flash part and also enforces alignment, overlap, and partition rules, 0074-0081] ; and adjusting a configuration of the partition table of the first hardware platform based on the validation [partitions are automatically resized, 0062,0063; post processor modifies partition and file system layout for the specific storage technology and moves the USERSTORE start, 0179].
As per claim 6, Kashyap teaches the method of claim 1, wherein the containerized first OS is configured to manage a software package on a first partition of a first memory space of the first hardware platform, the method further comprising: booting the second OS on the second hardware platform using the disk image; allocating, based on the disk image, a second partition of a second memory space of the second hardware platform, the second partition being associated with the first partition; and loading the software package from the second partition [the application is first installed on a source partition (an LPAR/WPAR) and encapsulated, 0022, 0047; a target partition is created 0032, 0051; the application is configured and run 0053, 0054, 0062 ].
As per claim 7, Glaum teaches the method of claim 1, wherein the second hardware platform is an embedded device [0007-0009, 0019, 0033 - 0037: embedded OS, handheld devices, flash, radio reserved regions].
As per claims 8-14, it is directed to a system to implement the method of steps set forth in claims 1 - 7. Shanker, Kashyap and Glaum teaches the claimed method steps. Therefore, Shanker, Kashyap and Glaum teaches the system to implement the claims steps.
As per claims 15 - 20, it is directed to a computer readable medium to implement the method of steps set forth in claims 1 - 7. Shanker, Kashyap and Glaum teaches the claimed method steps. Therefore, Shanker, Kashyap and Glaum teaches the computer readable medium to implement the claims steps.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
De Lima Junior; Juscelino et al. (US Patent Application Publication No. 2019/0392045) “Tailoring Container Images To A Specific Microarchitecture In Virtualized Environments “ is cited to teach a system and method for tailoring container images stored in a container image registry to a specific microarchitecture that a host operating system is running on in a virtualized environment that includes sending a container image fetch request to the container image registry, receiving microarchitecture identification instructions from the image registry in response to the container image fetch request, the microarchitecture identification instructions configured to be run on the host operating system, transmitting results from the microarchitecture identification instructions to the container image registry to identify the specific microarchitecture that the host operating system is running on in the virtualized environment, and starting a container within the virtualized environment using an optimal container image received from the container image registry, the optimal container image being tailored to the specific microarchitecture to leverage as many functionalities and capabilities of the specific microarchitecture of the computing system.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TERRELL S JOHNSON whose telephone number is (571)270-3485. The examiner can normally be reached 10AM-7PM EST M-F.
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, Jaweed Abbaszadeh can be reached at 571-270-1640. 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.
/TERRELL S JOHNSON/Primary Examiner, Art Unit 2176
1 Setting container registry is a design choice, as access to the containers via the docker is functionally similar.
2 Combination could be adapted to create container metadata/label
Prosecution Insights