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 .
This action is responsive to Applicant’s Amendment filed on 10/13/2025.
Claims 1-2, 4-9 and 11-20 are presented for examination. Claims 1, 8 and 15 have been amended.
Applicant’s amendments to the claims have overcome 112 rejections set forth in the non-Final Office Action mailed 7/11/2025.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirely as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Claim Objections
Claims 1-2, 4-9 and 11-20 are objected to because of the following informalities:
“wherein the container engine is to isolate the container corresponding to the container image from other applications of the host device that are compatible with the second operating system wherein the container is unaware that the container is operating on a non-native operating system” at lines 22-25 of claim 1 should be: wherein the container engine is to isolate the container corresponding to the container image from other applications of the host device that are compatible with the second operating system, wherein the container is unaware that the container is operating on a non-native operating system.
Claims 8 and 15 are objected due to same reason as set forth in the objection of claim 1 above.
Each of claims 2, 4-7, 9, 11-14 and 16-20 is objected for failing to cure the deficiency from their respective parent claim by dependency.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claims 4, 11 and 17 are rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
Regarding to Claim 4, claim 4 recites a feature of “the container image” is “free of a kernel of the first operating system”. Claim 4 depends on claim 1, claim 1 includes limitations of “the container image comprises a container application compatible with a first operating system”, “executing a container corresponding to the container image” and “wherein the container is unaware that the container is operating on a non-native operating system”. Based on these limitations from claim 1, one with ordinary skill in the art would recognize the facts of this claimed invention (at claim 1): the claimed first operating system at this particular claimed invention is a non-native operating system while the container image is the basis of executing the container. In this way, the claimed container image from claim 1 is not free of a kernel of the first operating system and such feature conflicts with the feature or limitation from claim 4, i.e. the claimed container image from claim 4 is “free of a kernel of the first operating system”. Thereby, claim 4 fails to include all the limitations of the claim upon which it depends. For the purpose of examination, examiner would consider the whole claim 4 as: wherein the host device is free of a kernel of the first operating system and the container image is not free of the kernel of the first operating system.
Regarding to Claim 11, Claim 11 is rejected under the same reason set forth in the rejection of Claim 4 above.
Regarding to Claim 17, Claim 17 is rejected under the same reason set forth in the rejection of Claim 4 above.
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 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 of this title, 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, 4-9, 11-16 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Engel et al. (US 20170269978 A1, hereafter Engel) and in view of Hardy et al. (US 20170228245 A1, hereafter Hardy), Schneider (US 8464252 B2), Thomas et al. (US 20230103402 A1, hereafter Thomas) and Araujo et al. (US 20190068641 A1, hereafter Araujo).
Engel, Hardy, Schneider, Thomas and Araujo ere cited on the previous office actions.
Regarding to claim 1, Engel discloses: a method comprising:
receiving a container image at a host device, wherein the container image comprises a container application compatible with a first operating system, and wherein the host device comprises a second operating system, different from the first operating system (see Figs. 1, 2, [0049], [0057], [0060]; “an image loaded into a container can be placed in an image store. An image store, as referred to herein, can include any memory repository that can store any suitable number of images. An image, as referred to herein, can include any operating system software, driver package, and/or software application that can be loaded into a container”. Also see [0055]; “the host operating system 300 can include any suitable operating system such as a version of Windows®, Linux® … By contrast, the container 1 runtime 302 can include a different operating system than the host operating system 300. In some examples, the container 1 runtime 302 can implement a version of Linux®, an Apple® operating system, any Google® operating system, or any Amazon® operating system”. At one of the reasonable embodiments recited at [0055], the container image comprises a container application compatible or native to Apple® operating system while the host device receives and instantiates the container image for executing the container application comprises Linux as its host OS); and
executing a container corresponding to the container image, by a container engine on a processing device, wherein the container engine comprises an emulator to translate a request from the container application that is directed to the first operating system into a request to the second operating system (see [0048]; “application software 204 in the container 1 runtime 202 can execute system calls. In some examples, the system calls can be modified by any number of drivers in the container facilities 218” and “the shim driver 220 can use an API mapping table to map system calls from application software 204 to corresponding kernel APIs 222”. Also see [0054] and [0065]; “an API mapping table that the OSLayer Shim driver 308 creates … use the API mapping table along with operating system information of the container 1 runtime 302 to determine a mapping for the system call. For example, the OSLayer Shim Driver 308 can change or modify the system call to a function and file name corresponding to the host operating system 300”. Furthermore, see [0003], [0021]-[0022] and [0068], “a processor to manage, via a container facility, the one or more container temporary storage spaces and the one or more container runtime environments” and “code to direct the processor 602 to perform the steps of the current method”, and thus it is reasonable to consider such container facility as claimed container engine on a processing device), wherein the emulator provides a compatibility layer with workload specified in the container an input to [intercept and] translate the request directed to the first operating system into one or more system calls that correspond the second operating system within a compartmentalized environment, wherein the compatibility layer modifies a directory structure of the first operating system and provides alternative implementations of system libraries of the first operating system, wherein the emulator is integrated into the container engine such that the one or more system calls are executed over the compartmentalized environment, wherein the container engine configures a runtime environment to provide an instantiation of the emulator, wherein the container itself refrains from facilitating translation of non-native requests, wherein the container engine is to isolate the container corresponding to the container image from other applications of the host device that are compatible with the second operating system wherein the container is unaware that the container is operating on a non-native operating system (see Fig. 2, [0048], [0054], [0065] and the explanations or rejection of translating limitation above. According to the explanations or rejection of translating limitation above, the OSLayer Shim Driver uses the API mapping table created as claimed emulator to provide a combability layer to modify or translate the request or system calls directed to container OS that is compatible with the container application into request or system calls corresponds to the host OS (note: due to the requests or system calls associated with the container OS are translated into the requests or system calls associated with the host OS, such translation result generated by the OSLayer Shim Driver modifies directory structure of the container OS and provides alternative implementations of system libraries of the container OS). In addition, instead of directly executing the request/system call from the container application within the host OS, the OSLayer Shim Driver (i.e., non-container component) modifies or translates such request/system call into request or system call that is compatible to the host OS, and thus it is the OSLayer Shim Driver (i.e., non-container component) as claimed emulator provides a compatibility layer with workload specified in the container an input to translate the request or system call, i.e., the container itself refrains from facilitating translation of non-native requests; the container facility 218 including the API mapping table, and thus such container facility would configure a runtime environment to provide an instantiation of the API mapping table, and thus the container is unaware that the container is operating on a non-native operating system. Furthermore, the interactions between the container application and certain applications or processes that are compatible with host OS are achieved with the conversion or translation process performed by the container facility, i.e., claimed container engine, instead of direct interactions, and thus such container facility isolates the container or container image from other applications or processes that are compatible with host OS, and it is the host OS or claimed second OS within a compartmentalized environment), wherein the container engine utilizes an isolation mechanism to isolate the container, wherein the isolation mechanism includes namespaces within a host operating system (see [0015] and [0049]; “container-based virtualization can depend on namespace isolation. Namespace isolation, as referred to herein, enables an application being executed in a container to view the application's environment as an isolated operating system entity. This improves compatibility between the application and its runtime environment” and “the shim driver 220 can verify that the container configuration data 210 includes accurate CPU information, memory information, filesystem information, and I/O information that reflect the isolated namespace of the container 1 runtime 202 environment”)
Note1: according to [0055] from the specification (particularly, “the OCI runtime infrastructure can invoke a Windows compatibility layer (e.g., as emulator 170) with “workload specified in container as an input” instead of allowing the workload to be executed directly in a Linux environment”), it is reasonable to consider the process of using OSLayer Shim Driver to modify the request/system call from the container application into request/system call for the host kernel to include feature or sub-process of the OSLayer Shim Dirver provides a combability layer with workload specified in the container to translate the request.
Note2: according to [0039], [0059] and [0072] from the specification (particularly, “due to the isolation 165, the container application 118 may be unable to interact with the other processes 112 … In this way, the container 114 may be compartmentalized in its execution”, “the first and second containers 114A, 114B may be isolated … The isolation mechanisms 165 may provide increased security and compartmentalization between the executing containers 114”, emphasis added), the limitation “the second operating system within a compartmentalized environment” is actually the inherence result from the isolating limitation above. Thereby, when Engel alone already teaches the isolating limitation, Engel alone will also teach the amended limitation “the second operating system within a compartmentalized environment”. Examiner also attached several references at the Conclusion session of non-Final Office Action mailed by 1/28/2025 as technical support for such inherence feature.
Note3: according to [0016] and [0051] from the specification (particularly, “The compatibility infrastructure may be included in a runtime environment of the container such that the container itself may not need to include any facilitation for the non-native support. By implementing the compatibility infrastructure into the container runtime environment, the container itself may be completely unaware that it is running on a non-native operating system” and “configuration of the emulator 170 may be maintained by the container engine 160, such that the container 114 is unaware of it (e.g., the emulator 170 is not configured by the container 114 or contained within the container 114)”, emphasis added by Examiner), the previous existing limitations like “wherein the container engine comprises an emulator to translate a request from the container application that is directed to the first operating system into a request to the second operating system, wherein the emulator provides a computability layer … translate the request directed to the first operating system into one or more system calls that correspond to the second operating system” from claim 1 is the reason for the claimed invention is able to achieve the current amended feature/limitation of “wherein the container is unaware that the container is operating on a non-native operating system” from claim 1.
Engel does not disclose:
wherein the container image is received from a repository remote from the host device,
the emulator to intercept the request,
wherein the one or more system calls include portable operating system interface (POSIX) compliant system calls,
wherein the container engine configures a runtime environment to provide an execution phase for the container where the runtime environment communicates with an operating system kernel of the host device to initiate execution of one or more containerized processes within the container,
the isolation mechanism includes namespaces and cgroups within a host operating system.
However, Hardy discloses: receiving a container image at a host device, wherein the container image is received from a repository remote from the host device (see Figs 1, 3A, 3B, [0110]; “the hypervisor 149 can install the virtual machine package 163 by, for example, installing or mounting a disk image if the virtual machine package 163 is a virtual machine image”. Also see [0028], [0035], [0066]; “the virtual machine execution environment 143 can be a containerized environment”, “A virtual machine package 163 can include a disk image that can be mounted by the hypervisor 149”, “the host management component 139 can then retrieve the package from the management service 113”),
the emulator provides a compatibility layer with workload specified in the container as an input to intercept and translate the request directed to the guest operating system into one or more requests that correspond to the host operating system within a compartmentalized environment (see [0028], [0030]-[0031], “the virtual machine execution environment 143 can be a containerized environment”, “the operation of components in the virtual machine execution environment 143 can be separate and isolated from other components in the client device 106”, “the hypervisor 149 can intercept hardware calls made from the guest operating system or guest applications, potentially modify or interpret those calls, and relay the calls to the kernel of the host operating system 136”, emphasis added. Instead of allowing the workload related to the hardware calls/requests from the guest domain to be executed directly in the host environment, the hypervisor is able to provides a combability layer with workload specified in the container as input to intercept and translate the request or calls directed to the guest/container OS into request or calls corresponds to the host OS for further executed. Also see “determine that the virtual machine 146 is required to execute the application by virtue of the application being incompatible with the host operating system 136 in the client device 106” from [0039]).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the processes of modifying or translation of the system calls or requests directed from the guest/container into system calls or requests correspond to host OS from Engel by including the process of intercepting requests/calls from the guest domain and then modifying such intercepted requests/calls for execution on the host domain from Hardy, and thus the combination of Engel and Hardy would disclose the missing limitation related to intercepting the request from Engel, since it is understood to perform an intercepting step/action to intercept a request/call from the guest domain before modifying or translating such request/call into another form that is suitable for host domain for further execution (see [0030]-[0031] from Hardy).
In addition, Schneider discloses: wherein the virtual execution environment engine configures a runtime environment to provide an execution phase for the virtual execution environment where the runtime environment communicates with an operating system kennel of the host device to initiate execution of one or more virtualized processes within the virtual machine (see lines 65-29 of cols. 5-6, lines 12-19 of col. 10 and claim 24; “the hypervisor 140 intercepts a request from an executing process 110 to write to the copy-on-write memory image 230”, “through the selective mapping of the various modular kernel components which constitute most modern operating system kernels 235, the hypervisor 140 can selectively expose the particular modular kernel components that are required or authorized for a particular process 110 to the virtual machine 115 in which that process 110 is executing” and “The hypervisor 140 may then expose the appropriate API subset 125 to the virtual machine, expose the operating system kernel 235 in memory 150 to the virtual machine, and then initiate execution of the process”. The hypervisor as virtual execution environment engine configures a runtime environment execution to provide execution phase for the virtual execution environment where the runtime environment communicates with host OS kernel to initiate execution of certain virtual processes within the virtual execution environment).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the processes of container facility intercepts and translate request from the container application from the combination of Engel and Hardy by including the processes of a hypervisor expose portion functions associated with host OS kernel to the guest virtual machine for further processes from Schneider, and thus the combination of Engel, Hardy and Schneider would disclose the missing limitation related to “initiate execution of one or more containerized processes” from Engel (note: it is understood to one with ordinary skill in the art that a hypervisor functioning as intermediary between host OS/kernel and guest virtual machine to translate requests or objects between the guest virtual machine and the host OS/kernel. Examiner provides several references at the Conclusion session of Final Office Action mailed by 4/3/2025 as evidences to show such feature, and thus it is reasonable to combine the features or functionalities discussed for a hypervisor into the container facility from Engel), since it would provide a mechanism of not only isolating processes executing within a computing device but also exposing host OS kernel functions to the isolated processes (see lines 52-61 of col. 2 from Schneider).
In addition, Thomas discloses: translate the non-native request into one or more native requests, wherein the one or more native requests include portable operating system interface (POSIX) compliant requests (see [0027]; “assuming an object or cloud storage protocol (e.g., S3) is not natively supported by the APIs 251a-x, one of the protocol gateways 230a-n may be responsible for translating S3 protocol requests, for example, received via an API (not shown) implemented by the protocol gateway at issue to corresponding native filesystem requests (e.g., POSIX, JDBC, HDFS, etc.) that are natively supported by the APIs 251a-x”. Also see [0013] for POSIX discussed at [0027] is Portable Operating System Interface).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the translation or mapping of non-native requests from containerized application to native system calls associated with host OS from the combination of Engel, Hardy and Schneider by including the translation of non-native requests to native POSIX compliant requests from Thomas, since POSIX is well-known and understood standards used by Unix like operating systems (note: it is understood that Linux OS discussed at Engel is also Unix like OS).
In addition, Araujo discloses: an isolation mechanism to isolate the container, where the isolation mechanism includes namespaces and cgroups within a host operating system (see [0029]-[0031]; “The first namespace, cgroup, refers to the Linux kernel functionality called cgroups that allows limitation and prioritization of resources (CPU, memory, block I/O, network, etc.)” and “It is also known to provide so-called “container” technology that combines the operating system kernel's support of cgroups and namespaces to provide isolated execution environments for applications. Thus, for example, where a host machine executes an operating system (OS), such as the Linux kernel, the operating system provides an OS-level virtualization method for running multiple isolated computing workloads (containers). Typically, a container in this environment hosts one or more applications”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the namespace implemented isolation mechanism used for containers from the combination of Engel, Hardy, Schneider and Thomas by including both of namespace and cgroup implemented isolation mechanism used for containers from Araujo, and thus the combination of Engel, Hardy, Schneider, Thomas and Araujo would disclose the missing limitations from Engel, since it is understood that a container is isolated with both of namespace and cgroup technologies used by Linux kernel (see [0029]-[0031] from Araujo).
Regarding to Claim 2, the rejection of Claim 1 is incorporated and further the combination of Engel, Hardy, Schneider, Thomas and Araujo discloses: wherein the container image is free of an executable that is compatible with the second operating system (see [0016]-[0017] from Engel; “a container may be built from an operating system that is used for mobile phones, and the host may be a server-based operating system that is used to host many containers and server applications. Therefore, an application running in the container for mobile devices may encounter missing or incompatible application program interfaces (APIs) or environmental incompatibilities, among others” and “The mapping enables a container to implement any suitable operating system regardless of the type or version of the host operating system”. The executions of certain containers are incompatible from the host OS, and thus there must be at least one executable or service of the host OS, i.e., claimed executable that is compatible with the second OS, is incompatible with the container or container image, otherwise the incompatible containers or container applications should be considered as being compatible with the host OS. In this way, the container or container image is free of at least one executable that is compatible with the host OS. Such as, see “host configuration data 214” and “host device drivers 216” discussed at [0047] from Engel).
Regarding to Claim 4, the rejection of Claim 1 is incorporated and further the combination of Engel, Hardy, Schneider, Thomas and Araujo discloses: wherein the host device and the container image are free of a kernel of the first operating system (see [0055] and [0057] from Engel; “the host operating system 300 can include any suitable operating system such as a version of Windows®, Linux® … By contrast, the container 1 runtime 302 can include a different operating system than the host operating system 300. In some examples, the container 1 runtime 302 can implement a version of Linux®, an Apple® operating system, any Google® operating system, or any Amazon® operating system” and “An image, as referred to herein, can include any operating system software, driver package, and/or software application that can be loaded into a container”. At one of the reasonable embodiments recited at [0055], the host OS is a different OS from the container OS, and thus such host device is free from the kernel of the container OS, i.e., the kernel of the claimed first operating system; the container image includes the OS to run the container application, and thus the container image is not free of the kernel of the claimed first operating system).
Regarding to Claim 5, the rejection of Claim 1 is incorporated and further the combination of Engel, Hardy, Schneider, Thomas and Araujo discloses: wherein the second operating system is a Linux-based operating system, and wherein the first operating system is a non-Linux-based operating system (see [0055] from Engel; “the host operating system 300 can include any suitable operating system such as a version of Windows®, Linux® … By contrast, the container 1 runtime 302 can include a different operating system than the host operating system 300. In some examples, the container 1 runtime 302 can implement a version of Linux®, an Apple® operating system, any Google® operating system, or any Amazon® operating system”. At one of the reasonable embodiments recited at [0055], the container image comprises a container application compatible or native to Apple® operating system, i.e., claimed first operating system, while the host device to receive and instantiate the container image for executing the container application comprises Linux® as host OS, i.e., claimed second operating system).
Regarding to Claim 6, the rejection of Claim 1 is incorporated and further the combination of Engel, Hardy, Schneider, Thomas and Araujo discloses: wherein the request from the container application that is to the first operating system is a system call directed to the first operating system, and wherein the emulator is configured to translate the system call directed to the first operating system into a system call directed to the second operating system executing on the host device (see [0048] from Engel; “application software 204 in the container 1 runtime 202 can execute system calls. In some examples, the system calls can be modified by any number of drivers in the container facilities 218” and “the shim driver 220 can use an API mapping table to map system calls from application software 204 to corresponding kernel APIs 222”. Also see [0054] and [0065] from Engel; “use the API mapping table along with operating system information of the container 1 runtime 302 to determine a mapping for the system call. For example, the OSLayer Shim Driver 308 can change or modify the system call to a function and file name corresponding to the host operating system 300”).
Regarding to Claim 7, the rejection of Claim 1 is incorporated and further the combination of Engel, Hardy, Schneider, Thomas and Araujo discloses: determining a container type of the container image; and selecting the emulator based on the container type (see [0059]-[0061] from Engel; “detect the version and type of the operating system image for the container”, “determine if an operating system version and type for a container matches a shim driver, such as shim driver 220” and “a shim driver matches the operating system version and type for a container, the process continues at block 408. At block 408, the container facilities 206 load the appropriate shim driver to enable a container to execute images or software applications with a host operating system).
Regarding to Claim 8, Claim 8 is a system claim corresponds to method Claim 1 and is rejected for the same reason set forth in the rejection of Claim 1 above.
Regarding to Claim 9, the rejection of Claim 8 is incorporated and further Claim 9 is a system claim corresponds to method Claim 2 and is rejected for the same reason set forth in the rejection of Claim 2 above.
Regarding to Claim 11, the rejection of Claim 8 is incorporated and further Claim 11 is a system claim corresponds to method Claim 4 and is rejected for the same reason set forth in the rejection of Claim 4 above.
Regarding to Claim 12, the rejection of Claim 8 is incorporated and further Claim 12 is a system claim corresponds to method Claim 5 and is rejected for the same reason set forth in the rejection of Claim 5 above.
Regarding to Claim 13, the rejection of Claim 8 is incorporated and further Claim 13 is a system claim corresponds to method Claim 6 and is rejected for the same reason set forth in the rejection of Claim 6 above.
Regarding to Claim 14, the rejection of Claim 8 is incorporated and further Claim 14 is a system claim corresponds to method Claim 7 and is rejected for the same reason set forth in the rejection of Claim 7 above.
Regarding to Claim 15, Claim 15 is a product claim corresponds to method Claim 1 and is rejected for the same reason set forth in the rejection of Claim 1 above.
Regarding to Claim 16, the rejection of Claim 15 is incorporated and further Claim 16 is a product claim corresponds to method Claim 2 and is rejected for the same reason set forth in the rejection of Claim 2 above.
Regarding to Claim 17, the rejection of Claim 15 is incorporated and further Claim 17 is a product claim corresponds to method Claim 4 and is rejected for the same reason set forth in the rejection of Claim 4 above.
Regarding to Claim 18, the rejection of Claim 15 is incorporated and further Claim 18 is a product claim corresponds to method Claim 5 and is rejected for the same reason set forth in the rejection of Claim 5 above.
Regarding to Claim 19, the rejection of Claim 15 is incorporated and further Claim 19 is a product claim corresponds to method Claim 6 and is rejected for the same reason set forth in the rejection of Claim 6 above.
Regarding to Claim 20, the rejection of Claim 15 is incorporated and further Claim 20 is a product claim corresponds to method Claim 7 and is rejected for the same reason set forth in the rejection of Claim 7 above.
Response to Arguments
Applicant’s arguments, filed 10/13/2025, with respect to rejections of claims 1-2, 4-9 and 11-20 under 35 U.S.C. 103 have been full considered but they are not persuasive.
Applicant’s arguments at pages 10-13 are summarized as the following:
For the independent claims, the claims were amended to recite feature of “wherein the container itself refrains from facilitating translation of non-native requests”. “Paragraph [0054] of Engel teaches a host operating system includes a container runtime, where the container facilities include an API mapping table that is created during initialization of the container runtime. However, paragraph [0054] of Engel does not suggest or disclose ‘the container engine configures a runtime environment …. wherein the container itself refrains from facilitating translation of non-native requests,’ as recited in claim 1. Engel’s teaching of a host operating system includes a container runtime, wherein the container facilities include an API mapping table that is created during initiation of the container runtime is unrelated to ‘the container engine configures a runtime environment …. Wherein the container itself refrains from facilitating translation of non-native requests,’ of claim 1. Thus, Engel does not disclose all the features of amended claim 1 (see pages 10-11 of the Remarks).
For the independent claims, the claims were amended to recite feature of “wherein the container is unaware that the container is operating on a non-native operating system”. “Paragraph [0048] of Engel teaches application software in the container runtime can execute system calls, wherein the system calls are modified by drivers in container facilities.” “Engel’s teaching of container facilities including OSLayer shim driver that can use an API mapping table to map system calls from application software to corresponding kernel APIs and … is unrelated to “the container engine is to isolate … wherein the container is unaware that the container is operating on a non-native operating system,” of claim 1. Thus, Engel does not disclose all the features of amended claim 1” (see pages 11-12 from the Remarks).
The examiner respectively disagrees.
First of all, Examiner did not provide or cite paragraph [0054] from Engel only to teach or disclose related limitations that Applicant argued about, and thus Applicant’s conclusion on Engel based on [0054] only is unreasonable. Such as, Examiner also cited [0048], [0065], [0021]-[0022] and [0068] from Engel when Examiner rejected the related limitations. It is not clear that reason that Applicant discussed or argued [0054] only.
Secondly, in addition to the feature that Applicant admitted at the Remarks, i.e., “a host operating system includes a container runtime, where the container facilities include an API mapping table that is created during initialization of the container runtime” (see last paragraph of page 10 from the Remarks), [0054] also discusses feature of “use the API mapping table along with operating system information of the container 1 runtime 302 to determine a mapping for the system call. For example, the OSLayer Shim Driver 308 can change or modify the system call to a function and file name corresponding to the host operating system 300” (Examiner even recited this particular feature at the corresponding rejection section, it is not clear that why Applicant did not make any analysis on such feature when Applicant tried to argue [0054] from Engel at the Remarks). According to such additional feature from [0054], it is clear to one with ordinary skill in the art that the translation of system calls from the container 1 runtime 302 (to be more specific, from application software 304 executed within the container 1 runtime 302, and thus such system calls are non-native requests) are performed by the container facilities 310 (to be more specific, it is the OSLayer Shim Driver 308 and the API mapping table). According to Fig. 3, such container facilities 310 or OSLayer Shim Driver 308 are not considered as container 1 runtime, and thus it is reasonable to consider the container 1 runtime 302 from Engel itself refrains from facilitating translation of non-native requests.
Similar as response a) above, Examiner did not provide or cite paragraph [0048] from Engel only to teach or disclose related limitations that Applicant argued about, and thus Applicant’s conclusion on Engel based on [0048] only is unreasonable.
Secondly, as explained at the rejection section, according to [0016] and [0051] from the specification (particularly, “The compatibility infrastructure may be included in a runtime environment of the container such that the container itself may not need to include any facilitation for the non-native support. By implementing the compatibility infrastructure into the container runtime environment, the container itself may be completely unaware that it is running on a non-native operating system” and “configuration of the emulator 170 may be maintained by the container engine 160, such that the container 114 is unaware of it (e.g., the emulator 170 is not configured by the container 114 or contained within the container 114)”, emphasis added by Examiner), the previous existing limitations like “wherein the container engine comprises an emulator to translate a request from the container application that is directed to the first operating system into a request to the second operating system, wherein the emulator provides a computability layer … translate the request directed to the first operating system into one or more system calls that correspond to the second operating system” from claim 1 is the reason for the claimed invention is able to achieve the current amended feature/limitation of “wherein the container is unaware that the container is operating on a non-native operating system” from claim 1, and thus it is understood that the teaching of these limitations from Engel is reasonable to cover the current amended feature/limitation of “wherein the container is unaware that the container is operating on a non-native operating system” from claim 1. Applicant did not argue that Engel fails to disclose such previous existing limitations.
Therefore, Claims 1-2, 4-9 and 11-20 are rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Moubayed et al. (US 20210127241 A1) discloses: a virtual machine 740 or container is a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine (see [0095]).
Ott (US 20110072505 A1) discloses: A virtual server is an isolated software container that can run its own operating system and applications as if it were a physical computer. A virtual server behaves exactly like a physical computer and contains its own virtual (i.e. software-based) CPU, RAM, hard disk and network interface card. Virtual servers are also called virtual machines (see ([0007]).
Campion (US 20100022306 A1) discloses: Using virtualization, a physical computer has one or multiple virtual machines, which are each isolated software containers that can run their own operating systems and applications as if they were a physical computer. A virtual machine behaves like a physical computer and contains it own virtual (i.e., software-based) CPU, RAM hard disk and network interface card (NIC). An operating system can't tell the difference between a virtual machine and a physical machine, nor can applications or other computers on a network (see [0032]).
Huang et al. (US 20220391253 A1) discloses: The virtual machine is a tightly isolated software container that can run its own operating system and applications as if it were a physical computer. The virtual machine operates exactly like a physical computer (see [0027]).
Fan et al. (US 20210286638 A1) discloses: The guest operating systems, VMs, or containers may be unaware that the device hardware has been virtualized (see [0024]).
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 extension fee 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 ZHI CHEN whose telephone number is (571)272-0805. The examiner can normally be reached on M-F from 9:30AM to 5:30PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y Blair can be reached on 571-270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Zhi Chen/
Patent Examiner, AU2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196