DETAILED ACTION
This communication is in response to the application filed on November 20, 2024 in which claims 1-20 are pending in the application. Claims 1, 8, and 15 are in independent form.
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on November 21, 2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Specification
The disclosure is objected to because of the following informalities:
[0015] recites "an isolated and secure environment for executing the cross-platform workload 115." The cross-platform workload is designated 114 and numeral 115 is not used for any element. The passage should recite "cross-platform workload 114."
[0021] recites "when the cross-platform workload 113 is completed." The cross-platform workload is designated 114 and numeral 113 is not used for any element. The passage should recite "cross-platform workload 114."
[0025] recites "the initialization service 102 has executed the remove directories command 118" and subsequently "the initialization service 102 may receive another request associated with another cross-platform workload." Reference numeral 102 designates the host machine and the initialization service is designated 108. Both passages should recite "initialization service 108."
[0032] recites "the processing device 202 can execute the initialization service 110 of FIG. 1." FIG. 1 designates the initialization service 108, and numeral 110 does not appear in any figure. The passage should recite "initialization service 108."
[0033] recites "deploy and execute the first container 114a on the host machine 102" and subsequently "execute the initialization service 108 in an environment of the first container 114a." The first container is designated 104a and numeral 114 designates the cross-platform workload. Both passages should recite "first container 104a."
[0034] recites "generate a new user namespace, a temporary filesystem, a new sub-control group, a PID namespace, or a combination thereof within the first container 108a." The first container is designated 104a and numeral 108 designates the initialization service. The passage should recite "first container 104a."
The following minor typographical errors should also be corrected: [0013] recites "Examples of the the client device 106" (doubled "the"); [0016] recites "Examples cross-platform workloads can include" (should recite "Examples of cross-platform workloads"); [0019] recites "usable to access a file or a I/O resource" (should recite "an I/O resource")
Appropriate correction is required.
Claim Objections
Claims 2, 9, and 16 objected to because of the following informalities:
As per claims 2, 9, and 16, the claims recite "a WASM payload file descriptor," the first occurrence of the acronym in the claims, while claims 7 and 14 spell out "Web Assembly." The first occurrence should recite "a Web Assembly (WASM) payload file descriptor," consistent with the specification's usage at [0016].
Appropriate correction is required.
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.
Claim(s) 1, 8, and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Larsson et al. (US 2024/0330003 A1) (hereinafter Larsson) in view of Oakes et al., "SOCK: Rapid Task Provisioning with Serverless-Optimized Containers," 2018 USENIX Annual Technical Conference, pp. 57-70 (July 2018) (hereinafter Oakes) in view of Jiang et al. (US 2019/0272205 A1) (hereinafter Jiang).
As per claim 1, Larsson primarily teaches the invention as claimed including:
A system comprising:
a processing device; and a memory device including instructions that are executable by the processing device for causing the processing device to perform operations comprising: ([0026] FIG. 1 is a block diagram of a computing device 10 that comprises a system memory 12, a processor device 14, and a storage device 16);
generating, by the initialization service, a second container based on the request, the second container executing within the first container ([0030] the first restricted container environment 32-1 can include a second system and service manager 22-2. The second system and service manager 22-2 (i.e., the init process) can be systemd; [0035] starting the process 28-3 from the third unit file 30-3 can cause the generation of a second restricted container environment 32-2 inside the first restricted container environment 32-1 ... this allows for a container with an application running inside the container (i.e., the child container) to be within another container (i.e., the parent container); The examiner notes that the second system and service manager 22-2 corresponds to the claimed initialization service, the first restricted container environment 32-1 to the claimed first container, and the second restricted container environment 32-2 to the claimed second container);
Larsson discloses executing, by the initialization service, a started process in the second container ([0035] the process 28-4 started by the second system and service manager 22-2 can execute inside the second restricted container environment 32-2). The examiner notes that the manager starts its processes from unit files stored on the container's root volume ([0035] the second system and service manager 22-2 can start a process 28-3 from a third unit file 30-3 that may be stored in the predetermined directory 34 on the second root volume 26-2), but Larsson does not describe the started application as a cross-platform workload; and executing an application started from a stored unit file is not executing the cross-platform workload associated with a received request.
Larsson therefore does not explicitly teach:
executing, by the initialization service, the cross-platform workload in the second container.
In addition, Larsson does not explicitly teach:
receiving, by an initialization service of a first container, a request associated with a cross-platform workload;
and the second container using a network namespace of the first container;
However, Oakes teaches:
receiving, by an initialization service of a first container, a request associated with a cross-platform workload ((Section 4.2, p. 63) a Zygote helper first pre-imports a set of modules. Then, when a lambda is invoked requiring those modules, the Zygote helper is forked to quickly create a new handler helper, which then loads the lambda code to handle a forwarded request; (Section 4.2, p. 63) we assume packages that may be pre-imported may be malicious ... and handlers certainly may be malicious, so both Zygote helpers and handler helpers must run in containers; (Section 4.1, p. 62) requests arrive over Unix domain socket; The examiner notes that the Zygote helper resident in its container corresponds to the claimed initialization service of the first container and the forwarded invocation of the lambda corresponds to the claimed request). The examiner interprets a cross-platform workload, as used in the specification, as one or more tasks designed to be operable on more than one operating system or platform without modification, with a serverless function among the specification's examples (specification as filed [0016] a cross-platform workload can involve one or more tasks designed to be operable on more than one operating system or platform without modification and [0008] the initialization service may receive a request to execute a cross-platform workload (e.g., a WASM workload, a serverless function, or the like));
Oakes teaches such a workload ((Section 4, p. 62) first, we want low-latency invocation for Python handlers that import libraries; The examiner notes that the invoked lambda is a Python serverless function);
executing, by the initialization service, the cross-platform workload in the second container ((Section 4.2, p. 63) the child calls fork again, creating a grandchild helper ("helper-H" in the figure) that executes fully in the new container; (Section 4.2, p. 63) the helper listens on the channel for the next commands; the manager will direct the helper to load the lambda code, and will then forward a request to the lambda; The examiner notes that the forked helper executes the invoked lambda, the cross-platform workload of the received request, in the new handler container, the claimed second container).
Larsson and Oakes are both concerned with running workloads in container environments set up by a resident service manager on a shared host kernel and are therefore combinable/modifiable.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Larsson in view of Oakes to have Larsson's second system and service manager receive a request for a serverless workload and then generate the nested container environment and execute the workload for that request.
Motivation would improve responsiveness to workload invocations because the Zygote helper has already pre-imported the needed modules and its forked copy becomes the new handler with those modules in place rather than importing them for each request, as taught by Oakes (Section 4.2, p. 63).
Larsson in view of Oakes do not explicitly teach:
the second container using a network namespace of the first container.
However, Jiang teaches:
the second container using a network namespace of the first container ([0066] the docker container engine creates a new network namespace (Np2 for short in the following) and a new IPC namespace (Ip2 for short in the following) for C2; [0068] a running parameter net_namespace of C3 is set to a parameter corresponding to Np2, so that C3 shares the network namespace Np2 with C2 during running, that is, both C3 and C2 may use the network device in Np2; [0010] the first load balancing container shares the first network namespace corresponding to the container for the first service during running, that is, may use a network device in the first network namespace; The examiner notes that the container C2 corresponds to the claimed first container, the load balancing container C3 to the claimed second container, and the shared namespace Np2 to the claimed network namespace of the first container).
Larsson, Oakes, and Jiang are all concerned with running software containers that share a host's Linux kernel isolation facilities and are therefore combinable/modifiable.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Larsson in view of Oakes in view of Jiang by setting the running parameter of the second container to the network namespace of Larsson's first restricted container environment so that the second container uses that namespace rather than a namespace of its own.
Motivation would improve network resource efficiency on the host because the second container uses the network device already established in the first container's network namespace rather than requiring a network device of its own as taught by Jiang ([0068]).
As per claim 8, it has similar limitations as claim 1 and is therefore rejected using the same rationale.
As per claim 15, it has similar limitations as claim 1 and is therefore rejected using the same rationale. Larsson further teaches a non-transitory computer-readable medium comprising instructions that are executable by a processing device ([0073] all or a portion of the examples may be implemented as a computer program product 118 stored on a transitory or non-transitory computer-usable or computer-readable storage medium and [0026]).
Claim(s) 2, 3, 9,10, 16, and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Larsson in view of Oakes in view of Jiang in view of Clark, "Standardizing WASI: A System Interface to Run WebAssembly Outside the Web," Mozilla Hacks (March 27, 2019) (hereinafter Clark) in view of inetd(8), FreeBSD System Manager's Manual (Dec. 6, 2021) (hereinafter Inetd).
As per claim 2, Larsson in view of Oakes in view of Jiang disclose the claimed invention as detailed above for claim 1. Oakes further teaches wherein the operation of receiving the request comprises receiving a set of file descriptors ((Section 4.2, p. 63, fig. 11) (1) the manager obtains references, represented as file descriptors (fds), to the namespaces and the root file system of the new container. (2) The fds are passed to helper-Z; (Section 4.1, p. 62) requests arrive over Unix domain socket; The examiner notes that the fds passed to helper-Z are the claimed set of file descriptors received with the request).
Larsson in view of Oakes in view of Jiang do not explicitly teach:
comprising at least a WASM payload file descriptor and a standard streams file descriptor.
However, Clark teaches:
a WASM payload file descriptor. The examiner interprets a WASM payload file descriptor, as used in the specification, as a file descriptor that facilitates interactions between a WASM module and files or I/O resources (specification as filed [0019] the WASM payload file descriptors can be file descriptors that facilitate interactions between a WASM module and files or I/O resources).
Clark teaches such descriptors ((Section "What should this system interface look like?", p. 19) with WASI, if you're calling a function that needs to access a file, you have to pass in a file descriptor, which has permissions attached to it; (Section "Security", p. 13) the host (which might be a browser, or might be a wasm runtime) puts functions in the sandbox that the code can use; (Section "What: WebAssembly is an assembly language for a conceptual machine", p. 1) this way, it can be run across all different OSs; The examiner notes that the descriptors are passed in for the WebAssembly module's file access and such a passed descriptor corresponds to the claimed WASM payload file descriptor).
Larsson, Oakes, Jiang, and Clark are all concerned with executing requested workloads in sandboxed execution environments on a host and are therefore combinable/modifiable.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Larsson in view of Oakes in view of Jiang in view of Clark by executing the requested workload as a WebAssembly module and passing the file descriptors for the module's file access in with the request.
Motivation would improve security of the workload's file access because each passed file descriptor carries its attached permissions and the workload reaches only the files whose descriptors it has been handed, as taught by Clark (Section "What should this system interface look like?", p. 19).
Larsson in view of Oakes in view of Jiang in view of Clark do not explicitly teach:
a standard streams file descriptor.
However, Inetd teaches:
a standard streams file descriptor ((p. 1) the server program is invoked with the service socket as its standard input, output and error descriptors; (p. 1) when a connection is found on one of its sockets, it decides what service the socket corresponds to, and invokes a program to service the request; The examiner notes that the service socket serving as the invoked program's standard input, output and error descriptors corresponds to the claimed standard streams file descriptor).
Larsson, Oakes, Jiang, Clark, and Inetd are all concerned with launching programs to service requests received on a host and are therefore combinable/modifiable.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Larsson in view of Oakes in view of Jiang in view of Clark in view of Inetd so that the set of file descriptors received with the request carries the descriptor of the service connection as the workload's standard streams descriptor.
Motivation would improve efficiency of servicing the request because the invoked program reads and writes its response directly over the service connection as its standard input and output, with no relay of the data through the initialization service and no further channel to open, as taught by Inetd (p. 1).
As per claim 3, Inetd further teaches wherein the operation of generating the second container comprises setting one or more standard streams based on the standard streams file descriptor ((p. 1) the server program is invoked with the service socket as its standard input, output and error descriptors; (p. 1) after the program is finished, inetd continues to listen on the socket; The examiner notes that invoking the program with the received socket as its standard input, output and error is the claimed setting of the one or more standard streams based on the standard streams file descriptor).
As per claim 9, it has similar limitations as claim 2 and is therefore rejected using the same rationale.
As per claim 10, it has similar limitations as claim 3 and is therefore rejected using the same rationale.
As per claim 16, it has similar limitations as claim 2 and is therefore rejected using the same rationale.
As per claim 17, it has similar limitations as claim 3 and is therefore rejected using the same rationale.
Claim(s) 4, 11, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Larsson in view of Oakes in view of Jiang in view of systemd-nspawn(1), systemd version 252 manual page (hereinafter Nspawn).
As per claim 4, Larsson in view of Oakes in view of Jiang disclose the claimed invention as detailed above for claim 1 but do not explicitly teach:
wherein the operation of generating, by the initialization service, the second container based on the request comprises:
generating a user namespace, a process identifier namespace, and a temporary file system;
copying code or data associated with the cross-platform workload into the temporary file system; and
setting the temporary file system as a root for the second container.
However, Nspawn teaches:
generating a user namespace, a process identifier namespace, and a temporary file system ((p. 11) controls user namespacing. If enabled, the container will run with its own private set of UNIX user and group ids (UIDs and GIDs); (p. 1) it virtualizes the file system hierarchy, as well as the process tree, the various IPC subsystems, and the host and domain names; (p. 6) the root directory is mounted as a mostly unpopulated "tmpfs" instance);
copying code or data associated with the cross-platform workload into the temporary file system ((p. 21) the /etc/resolv.conf file from the host is copied into the container; The examiner notes that the copy lands in the tmpfs root in volatile mode and is data the containerized workload uses; (p. 4) the container is run with a temporary snapshot of its file system); and
setting the temporary file system as a root for the second container ((p. 6) this means the root directory is mounted as a mostly unpopulated "tmpfs" instance, and /usr/ from the OS tree is mounted into it in read-only mode). The examiner notes that the container's own private set of user and group identifiers is the claimed user namespace, the virtualized process tree is the claimed process identifier namespace, and the tmpfs instance is the claimed temporary file system. The examiner further notes that in the combination the initialization service performs these operations in generating the second container.
Larsson, Oakes, Jiang, and Nspawn are all concerned with running workloads in light-weight namespace containers on a shared host and are therefore combinable/modifiable.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Larsson in view of Oakes in view of Jiang in view of Nspawn so that the second container runs with its own private set of user and group identifiers and its root directory is mounted as a temporary file system holding the copied data of the workload.
Motivation would improve security of the second container because user namespacing is required for security and massively enhances container security while operating fully automatically as taught by Nspawn (p. 13).
As per claim 11, it has similar limitations as claim 4 and is therefore rejected using the same rationale.
As per claim 18, it has similar limitations as claim 4 and is therefore rejected using the same rationale.
Claim(s) 5, 12, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Larsson in view of Oakes in view of Jiang in view of Nspawn in view of "Control Group v2," Linux Kernel Documentation, admin-guide/cgroup-v2.rst, kernel release v5.15 (October 2021) (hereinafter CGroup v2).
As per claim 5, Larsson in view of Oakes in view of Jiang in view of Nspawn disclose the claimed invention as detailed above for claims 1 and 4. Oakes further teaches forking to generate a copy of the initialization service ((Section 4.2, p. 63) the Zygote helper is forked to quickly create a new handler helper; (Section 4.2, p. 63, fig. 11) (6) the manager then moves the grandchild to the new cgroup; (Section 4.1, p. 62) it is relatively expensive to create cgroups; thus, OpenLambda creates a pool of cgroups (shown in Figure 10) that can be used upon SOCK container creation; cgroups are returned to the pool after container termination). The examiner notes that the new handler helper is a forked copy of the Zygote helper, the claimed copy of the initialization service, and is placed in the control group used for the new container. Oakes draws that control group from a pool of already created groups; and allocating a pooled control group is not generating a sub-control group for the second container.
Larsson in view of Oakes in view of Jiang in view of Nspawn therefore do not explicitly teach:
generating a sub-control group for the second container.
However, CGroup v2 teaches:
generating a sub-control group for the second container. The examiner interprets the sub-control group, as used in the specification, as a child or nested group within a control group associated with the first container (specification as filed [0023] the sub-control group 112 can be a child or nested group within a control group associated with the first container 104a).
CGroup v2 teaches such a group ((Organizing Processes and Threads, p. 3) a child cgroup can be created by creating a sub-directory: # mkdir $CGROUP_NAME; (What is cgroup?, p. 1) cgroups form a tree structure and every process in the system belongs to one and only one cgroup; (Organizing Processes and Threads, p. 3) a process can be migrated into a cgroup by writing its PID to the target cgroup's 'cgroup.procs' file). Nspawn likewise places the container within the service manager's control group hierarchy ((p. 11) make the container part of the specified slice, instead of the default machine.slice). The examiner notes that in the combination the control group into which the forked copy of the initialization service is moved is generated as a child group under the control group of the first container, so that the forking generates the copy of the initialization service for the sub-control group.
Larsson, Oakes, Jiang, Nspawn, and CGroup v2 are all concerned with managing the resources and environments in which software executes on a shared Linux host and are therefore combinable/modifiable.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Larsson in view of Oakes in view of Jiang in view of Nspawn in view of CGroup v2 by creating the control group of the second container as a sub-directory under the control group of the first container and then moving the forked copy of the initialization service into it.
Motivation would improve control over the workload’s resource consumption because resources are distributed top-down and the sub-control group receives only what the first container’s group distributes to it, so the workload cannot consume beyond the first container’s allocation, as taught by CGroup v2 (Controlling Controllers, Top-down Constraint, p. 7).
As per claim 12, it has similar limitations as claim 5 and is therefore rejected using the same rationale.
As per claim 19, it has similar limitations as claim 5 and is therefore rejected using the same rationale.
Claim(s) 6, 13, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Larsson in view of Oakes in view of Jiang in view of Guim Bernat et al. (US 2021/0044646 A1) (hereinafter Guim Bernat) in view of CGroup v2.
As per claim 6, Larsson in view of Oakes in view of Jiang disclose the claimed invention as detailed above for claim 1 but do not explicitly teach:
wherein the request is a first request and wherein the operations further comprise, subsequent to executing the cross-platform workload using the second container:
executing a remove directories command; and
subsequent to executing the remove directories command, receiving a second request associated with another cross-platform workload.
However, Guim Bernat teaches:
cleaning the used container subsequent to executing the workload using the second container ([0088] upon determining that the container is to be cleaned, the example container cleaner 825 removes user data from the container ... the example container cleaner 825 deletes any data which is not identified in the list of data objects. The example container cleaner 825 does not, however, delete the entirety of the container. That is, the container to be cleaned remains within the edge node, but in a cleaned state; [0089] the example container cleaner 825 restores any settings ... that a prior execution of the container may have modified); and
subsequent to the cleaning, receiving a second request associated with another workload (Abstract storing information identifying the container, the information including a flavor of the container, the storing of the information to enable the container to be re-used by a subsequent requestor; [0090] the example process 1000 of the illustrated example of FIG. 10 begins when the example container controller 845 accesses (e.g., receives) a request to allocate a container for use).
The examiner notes that in the combination the request received after the cleaning is another workload invocation per Oakes, a second request associated with another cross-platform workload.
Larsson, Oakes, Jiang, and Guim Bernat are all concerned with executing successive workloads in containers on shared computing infrastructure and are therefore combinable/modifiable.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Larsson in view of Oakes in view of Jiang in view of Guim Bernat to clean the per-workload state of the second container after the cross-platform workload completes and then receive the second request.
Motivation would avoid the overhead of deleting and re-creating containers upon subsequent use because a previously used container is cleaned and later re-used rather than completely deleted and then re-created as taught by Guim Bernat ([0093]).
Guim Bernat describes the cleanup as deleting the user data remaining in the container rather than as executing a remove directories command; and deleting the remaining user data from the container is not executing a remove directories command.
Larsson in view of Oakes in view of Jiang in view of Guim Bernat therefore do not explicitly teach:
executing a remove directories command.
However, CGroup v2 teaches:
executing a remove directories command ((Organizing Processes and Threads, p. 4) a cgroup which doesn't have any children or live processes can be destroyed by removing the directory ... # rmdir $CGROUP_NAME).
The examiner notes that in the combination the cleaning removes the completed workload's control group directory with the remove directories command per CGroup v2 and the initialization service then receives the next request per Guim Bernat [0090].
Larsson, Oakes, Jiang, Guim Bernat, and CGroup v2 are all concerned with managing the resources of software executing on a shared Linux host and are therefore combinable/modifiable.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Larsson in view of Oakes in view of Jiang in view of Guim Bernat in view of CGroup v2 with a remove directories command that removes the control group directory of the completed workload during the cleaning.
Motivation would improve isolation between the successive workloads of the re-used container because deleting the user data does not remove the container’s used control group and a group with no live processes is destroyed by remoting its directory, so no state of one workload leaks into the next when the container is re-used, as taught by CGroup v2 (Organizing Processes and Threads, p. 4).
As per claim 13, it has similar limitations as claim 6 and is therefore rejected using the same rationale.
As per claim 20, it has similar limitations as claim 6 and is therefore rejected using the same rationale.
Claim(s) 7 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Larsson in view of Oakes in view of Jiang in view of Atanasov et al. (US 2025/0021365 A1) (hereinafter Atanasov).
As per claim 7, Larsson in view of Oakes in view of Jiang disclose the claimed invention as detailed above for claim 1 but do not explicitly teach:
wherein the cross-platform workload is a Web Assembly workload and wherein the initialization service includes a Web Assembly virtual machine.
However, Atanasov teaches:
the cross-platform workload is a Web Assembly workload ([0033] each LC 504, 506, 508, 510 is a WASM VM, which runs a container application on behalf of a node and [0032] WASM VM 410 thus enables the execution of platform-independent application code and sandboxing) and wherein
the initialization service includes a Web Assembly virtual machine. The examiner interprets the Web Assembly virtual machine, as used in the specification, as the cross-platform runtime environment of the initialization service configured to execute WASM code (specification as filed [0016] the cross-platform runtime environment 120 of the initialization service 108 may be a WASM virtual machine (VM) configured to execute WASM code associated with the WASM workload).
Atanasov teaches that runtime ([0032] a lightning container (LC) 412 is a WASM VM 408 running in a thread or green thread assigned from a pool 414 ... and [0034] the proxy plugin loads a ready application into a virtual machine). The examiner notes that Atanasov's persistent proxy plugin process on the worker node maintains the pool of WASM virtual machines into which the applications are loaded. The examiner further notes that in the combination the initialization service includes such a WASM virtual machine as its cross-platform runtime environment, the claimed Web Assembly virtual machine.
Larsson, Oakes, Jiang, and Atanasov are all concerned with low latency execution of requested workloads in isolated environments on orchestrated hosts and are therefore combinable/modifiable.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Larsson in view of Oakes in view of Jiang in view of Atanasov with a Web Assembly virtual machine in the initialization service that executes the requested cross-platform workload as a WebAssembly application.
Motivation would improve portability of the requested workload because the WASM virtual machine executes platform-independent application code with sandboxing rather than code compiled for a particular host platform, as taught by Atanasov ([0032]).
As per claim 14, it has similar limitations as claim 7 and is therefore rejected using the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Woodruff et al. (US 11,140,455) discloses that a first network namespace and second network namespace are created in a computing instance of a computer system, with the second network namespace being accessible to the first network namespace via an interface. A service is executed in the first namespace and an encoder is executed in the second namespace (abstract), which relates to the claimed executing of the cross-platform workload in the second container.
Li et al. (US 12,170,646) discloses a container management tool of a container management service of a service provider network that operates a first container in a network mode associated with a software generated namespace generated by the container management tool ... adds a link to a desired, e.g., existing application network namespace (abstract), which relates to the claimed second container using a network namespace of the first container.
Lu et al. (US 2021/0011740) discloses preparing, by a main process, for communication, cloning a child process ... elevating, by the child process, permission, executing namespace isolation, and cloning a grandchild process, and setting, by the parent process, cgroups for the grandchild process (abstract), which relates to the claimed forking to generate a copy of the initialization service for the sub-control group.
Examiner has cited particular columns/paragraphs/sections and line numbers in the references applied and not relied upon to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THANH NGO whose telephone number is (571)270-3019. The examiner can normally be reached M-F 9am to 6pm ET, first F of bi-week off.
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, Pierre Vital can be reached at (571)272-4215. 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.
/T.N./ Examiner, Art Unit 2198
/PIERRE VITAL/ Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights