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 office Action is in response to claims filled on 08/22/2025.
Claims 1-7, 14-26 are pending.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 1, 7, 14, 15, 21 are rejected under 35 U.S.C. 103 as being unpatentable over US 7020874 B2 – hereinafter “Sokolov”, in view of US 20230195435 A1 – hereinafter “Jaeger”.
With respect to claim 1, Sokolov teaches,
A method comprising: “The invention can be implemented in numerous ways, including as a method, an apparatus, a computer readable medium, and a database system. Several embodiments of the invention are discussed below.” [Col. 2 lines 56-59];
decoding, by the virtualized runtime environment, the binary format of the source file, “Computer programs written in the Java.TM. programming language (and other languages) may be compiled into Java.TM. virtual machine instructions (typically referred to as Java.TM. bytecodes) that are suitable for execution by a Java.TM. virtual machine implementation.” [Col. 1 lines 36-41]; “A class written in the Java.TM. programming language is compiled to a particular binary format called the "class file format" that includes Java.TM. virtual machine instructions for the methods of a single class” [Col. 1 lines 54-58];
Examiners note: Java TM bytecode is the binary file that is later decoded into a format of the source file into an executable in-memory data structure.
wherein decoding the binary format of the source file comprises transforming the binary format of the source file into an executable in-memory data structure executable by the virtualized runtime environment; “As another method for loading a class file into a virtual machine, another embodiment of the invention include the act of:… creating an internal representation of the class file in the virtual machine when the determining determines that an internal representation of the class file does not exist in the virtual machine; and loading into the virtual machine the selected information associated with the at least one method of the class and not loading into the virtual machine information that was not selected.” [Col. 3 lines 1-17]; “The internal class representation 206 can be, for example, implemented as a data structure embodied in a computer readable medium that is suitable for use by a virtual machine.” [Col. 4 line 65 – Col. 5 line 1]; “The inventive mechanisms are especially effective in virtual machines that operate with limited memory resources (e.g., embedded systems). In one embodiment, class files suitable for loading into a virtual machine are initially loaded into a memory portion (e.g., heap memory).” [Col. 4 lines 15-20];
instantiating, based on the executable in-memory data structure, a virtualized runtime instance comprising one or more modules for executing a process of the source file; “an internal representation of the class is created. This internal representation can be, for example, the internal representation 206 illustrated in FIG. 3. Next, at operation 510, the required components of the class are identified and extracted from the raw-class heap. As will be appreciated, these components can be selected, for example, when the class is resolved. Accordingly, only the required components of the class need to be extracted after being identified. Thereafter, the extracted components of the class are loaded into the virtual machine at operation 512. This can include loading required methods and creating references for loaded methods in a method information portion (e.g., similar to a method table implemented in a standard Java.TM. class). The method 500 ends following operation 512.” [Col. 6 lines 37-51];
and executing the process in the virtualized runtime instance. “Computer programs written in the Java.TM. programming language (and other languages) may be compiled into Java.TM. virtual machine instructions (typically referred to as Java.TM. bytecodes) that are suitable for execution by a Java.TM. virtual machine implementation.” [Col. 1 lines 36-41]; “Finally, the code reference field 406 is arranged for referencing the code associated with the method. As will be appreciated by those skilled in the virtual machine art, there is often code associated with a method that the virtual machine executes at runtime. The code reference field 406 simply provides a place to identify the location where such information can be or is stored. It should also be noted that the code reference field 406 can be loaded when it is determined that there is a need for the code. Similarly, method name field 402 and method signature field 404 can selectively be loaded.” [Col. 6 lines 11-21];
Sokolov does not explicitly teach receiving, at an interface of a virtualized runtime environment running on a host computer system source file having a binary format.
However, analogous art Jaeger teaches,
receiving, at an interface of a virtualized runtime environment running on a host computer system source file having a binary format. “In some scalable container-based systems, the container builder (375) includes a load module compiler, that receives as input, the binaries” [0124];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov to include receiving, at an interface of a virtualized runtime environment running on a host computer system source file having a binary format using the teachings of Jaeger. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of running virtual environments tailored for specific applications while reducing or eliminating the possible overhead, inefficiencies, and failures caused by running standard binaries for all environments (Jaeger, 0008-0009).
With respect to claim 7, Sokolov and Jaeger teach The method of claim 1,
Sokolov teaches,
the one or more modules are instantiated without a full guest operating system. “A particular Java.TM. virtual machine implementation and corresponding support libraries together constitute a Java.TM. runtime environment.” [Col. 1 lines 45-47]; “Computer programs in the Java.TM. programming language are arranged in one or more classes or interfaces (referred to herein jointly as classes or class files). Such programs are generally platform independent (i.e., hardware and operating system). As such, these computer programs may be executed unmodified on any computer that is able to run an implementation of the Java.TM. runtime environment.” [Col. 1 lines 48-54];
Examiners note: Sokolov teaches loading and executing modules inside the JVM runtime, not inside a full guest OS. The framework is an application-level VM where modules are selectively instantiated in the VM’s internal representation – no OS boot or guest OS environment per instance.
With respect to claim 14, Sokolov teaches,
A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors of a computing system, cause the computing system to perform operations comprising: “A system, in accordance with the description above, may be implemented in computer instructions stored in a non-transitory medium, such as a computer storage medium in a server or server cluster, or set of server clusters. The computer instructions may be stored on a non-volatile fixed or removable storage medium for installation on such a system” [0156];
decoding, by the virtualized runtime environment, the binary format of the source file, “Computer programs written in the Java.TM. programming language (and other languages) may be compiled into Java.TM. virtual machine instructions (typically referred to as Java.TM. bytecodes) that are suitable for execution by a Java.TM. virtual machine implementation.” [Col. 1 lines 36-41]; “A class written in the Java.TM. programming language is compiled to a particular binary format called the "class file format" that includes Java.TM. virtual machine instructions for the methods of a single class” [Col. 1 lines 54-58];
wherein decoding the binary format of the source file comprises transforming the binary format of the source file into an executable in-memory data structure executable by the virtualized runtime environment; “As another method for loading a class file into a virtual machine, another embodiment of the invention include the act of:… creating an internal representation of the class file in the virtual machine when the determining determines that an internal representation of the class file does not exist in the virtual machine; and loading into the virtual machine the selected information associated with the at least one method of the class and not loading into the virtual machine information that was not selected.” [Col. 3 lines 1-17]; “The internal class representation 206 can be, for example, implemented as a data structure embodied in a computer readable medium that is suitable for use by a virtual machine.” [Col. 4 line 65 – Col. 5 line 1]; “The inventive mechanisms are especially effective in virtual machines that operate with limited memory resources (e.g., embedded systems). In one embodiment, class files suitable for loading into a virtual machine are initially loaded into a memory portion (e.g., heap memory).” [Col. 4 lines 15-20];
instantiating, based on the executable in-memory data structure, a virtualized runtime instance- comprising one or more modules for executing a process of the source file; “an internal representation of the class is created. This internal representation can be, for example, the internal representation 206 illustrated in FIG. 3. Next, at operation 510, the required components of the class are identified and extracted from the raw-class heap. As will be appreciated, these components can be selected, for example, when the class is resolved. Accordingly, only the required components of the class need to be extracted after being identified. Thereafter, the extracted components of the class are loaded into the virtual machine at operation 512. This can include loading required methods and creating references for loaded methods in a method information portion (e.g., similar to a method table implemented in a standard Java.TM. class). The method 500 ends following operation 512.” [Col. 6 lines 37-51];
and executing the process in the virtualized runtime instance. “Computer programs written in the Java.TM. programming language (and other languages) may be compiled into Java.TM. virtual machine instructions (typically referred to as Java.TM. bytecodes) that are suitable for execution by a Java.TM. virtual machine implementation.” [Col. 1 lines 36-41]; “Finally, the code reference field 406 is arranged for referencing the code associated with the method. As will be appreciated by those skilled in the virtual machine art, there is often code associated with a method that the virtual machine executes at runtime. The code reference field 406 simply provides a place to identify the location where such information can be or is stored. It should also be noted that the code reference field 406 can be loaded when it is determined that there is a need for the code. Similarly, method name field 402 and method signature field 404 can selectively be loaded.” [Col. 6 lines 11-21];
Sokolov does not explicitly teach receiving, at an interface of a virtualized runtime environment running on a host computer system source file having a binary format.
However, analogous art Jaeger teaches,
receiving, at an interface of a virtualized runtime environment running on a host computer system source file having a binary format. “In some scalable container-based systems, the container builder (375) includes a load module compiler, that receives as input, the binaries” [0124];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov to include receiving, at an interface of a virtualized runtime environment running on a host computer system source file having a binary format using the teachings of Jaeger. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of running virtual environments tailored for specific applications while reducing or eliminating the possible overhead, inefficiencies, and failures caused by running standard binaries for all environments (Jaeger, 0008-0009).
With respect to claim 15, Sokolov teaches,
A system comprising: one or more processors; and a non-transitory computer-readable medium comprising instructions that, when executed by the one or more processors, cause the system to perform operations comprising: “FIG. 1B depicts an example of a container management system (110). The hardware (15) of the container system may be a physical server or a cluster of physical servers, which may, for example, be X86-based computers.” [0006]; “A system, in accordance with the description above, may be implemented in computer instructions stored in a non-transitory medium, such as a computer storage medium in a server or server cluster, or set of server clusters. The computer instructions may be stored on a non-volatile fixed or removable storage medium for installation on such a system” [0156];
decoding, by the virtualized runtime environment, the binary format of the source file, “Computer programs written in the Java.TM. programming language (and other languages) may be compiled into Java.TM. virtual machine instructions (typically referred to as Java.TM. bytecodes) that are suitable for execution by a Java.TM. virtual machine implementation.” [Col. 1 lines 36-41]; “A class written in the Java.TM. programming language is compiled to a particular binary format called the "class file format" that includes Java.TM. virtual machine instructions for the methods of a single class” [Col. 1 lines 54-58];
wherein decoding the binary format of the source file comprises transforming the binary format of the source file into an executable in-memory data structure executable by the virtualized runtime environment; “As another method for loading a class file into a virtual machine, another embodiment of the invention include the act of:… creating an internal representation of the class file in the virtual machine when the determining determines that an internal representation of the class file does not exist in the virtual machine; and loading into the virtual machine the selected information associated with the at least one method of the class and not loading into the virtual machine information that was not selected.” [Col. 3 lines 1-17]; “The internal class representation 206 can be, for example, implemented as a data structure embodied in a computer readable medium that is suitable for use by a virtual machine.” [Col. 4 line 65 – Col. 5 line 1]; “The inventive mechanisms are especially effective in virtual machines that operate with limited memory resources (e.g., embedded systems). In one embodiment, class files suitable for loading into a virtual machine are initially loaded into a memory portion (e.g., heap memory).” [Col. 4 lines 15-20];
instantiating, based on the executable in-memory data structure, a virtualized runtime instance- comprising one or more modules for executing a process of the source file; “an internal representation of the class is created. This internal representation can be, for example, the internal representation 206 illustrated in FIG. 3. Next, at operation 510, the required components of the class are identified and extracted from the raw-class heap. As will be appreciated, these components can be selected, for example, when the class is resolved. Accordingly, only the required components of the class need to be extracted after being identified. Thereafter, the extracted components of the class are loaded into the virtual machine at operation 512. This can include loading required methods and creating references for loaded methods in a method information portion (e.g., similar to a method table implemented in a standard Java.TM. class). The method 500 ends following operation 512.” [Col. 6 lines 37-51];
and executing the process in the virtualized runtime instance. “Computer programs written in the Java.TM. programming language (and other languages) may be compiled into Java.TM. virtual machine instructions (typically referred to as Java.TM. bytecodes) that are suitable for execution by a Java.TM. virtual machine implementation.” [Col. 1 lines 36-41]; “Finally, the code reference field 406 is arranged for referencing the code associated with the method. As will be appreciated by those skilled in the virtual machine art, there is often code associated with a method that the virtual machine executes at runtime. The code reference field 406 simply provides a place to identify the location where such information can be or is stored. It should also be noted that the code reference field 406 can be loaded when it is determined that there is a need for the code. Similarly, method name field 402 and method signature field 404 can selectively be loaded.” [Col. 6 lines 11-21];
Sokolov does not explicitly teach receiving, at an interface of a virtualized runtime environment running on a host computer system source file having a binary format.
However, analogous art Jaeger teaches,
receiving, at an interface of a virtualized runtime environment running on a host computer system source file having a binary format. “In some scalable container-based systems, the container builder (375) includes a load module compiler, that receives as input, the binaries” [0124];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov to include receiving, at an interface of a virtualized runtime environment running on a host computer system source file having a binary format using the teachings of Jaeger. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of running virtual environments tailored for specific applications while reducing or eliminating the possible overhead, inefficiencies, and failures caused by running standard binaries for all environments (Jaeger, 0008-0009).
With respect to claim 21, Sokolov and Jaeger teach The non-transitory computer-readable medium of claim 14,
Sokolov teaches,
the one or more modules are instantiated without a full guest operating system. “A particular Java.TM. virtual machine implementation and corresponding support libraries together constitute a Java.TM. runtime environment.” [Col. 1 lines 45-47]; “Computer programs in the Java.TM. programming language are arranged in one or more classes or interfaces (referred to herein jointly as classes or class files). Such programs are generally platform independent (i.e., hardware and operating system). As such, these computer programs may be executed unmodified on any computer that is able to run an implementation of the Java.TM. runtime environment.” [Col. 1 lines 48-54];
Examiners note: Sokolov teaches loading and executing modules inside the JVM runtime, not inside a full guest OS. The framework is an application-level VM where modules are selectively instantiated in the VM’s internal representation – no OS boot or guest OS environment per instance.
Claim 2, 16 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over US 7020874 B2 – hereinafter “Sokolov”, in view of US 20230195435 A1 – hereinafter “Jaeger”, further in view of US 6289506 B1 – hereinafter “Kwong”.
With respect to claim 2, Sokolov and Jaeger teach The method of claim 1,
Sokolov and Jaeger do not explicitly teach decoding the binary format of the source file further comprises validating the source file against a set of runtime constraints of the virtualized environment.
However, analogous art Kwong teaches,
decoding the binary format of the source file “FIG. 4 illustrates a block diagram of the elements in a client computer system 400 equipped to interpret and compile Java class files.” [Col. 6 lines 29-31];
further comprises validating the source file against a set of runtime constraints of the virtualized environment. “After the class file 460 has been downloaded, it is passed into the Java VM 430, which then verifies the downloaded class file at step 320. Step 320 of verifying the class file is to ensure that the program will not cause security violations nor will it cause harm to the computer system resources. After the Java class file has been verified, the interpreter 432 begins interpreting the Java bytecodes of the class file 460.” [Col. 6 lines 45-53];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov and Jaeger to include decoding the binary format of the source file further comprises validating the source file against a set of runtime constraints of the virtualized environment using the teachings of Kwong. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of performing runtime compilations without exposing the system to failures or possible vulnerabilities (Kwong, Col. 2 lines 21-34).
With respect to claim 16, Sokolov and Jaeger teach The non-transitory computer-readable medium of claim 14,
Sokolov and Jaeger do not explicitly teach decoding the binary format of the source file further comprises validating the source file against a set of runtime constraints of the virtualized environment.
However, analogous art Kwong teaches,
decoding the binary format of the source file “FIG. 4 illustrates a block diagram of the elements in a client computer system 400 equipped to interpret and compile Java class files.” [Col. 6 lines 29-31];
further comprises validating the source file against a set of runtime constraints of the virtualized environment. “After the class file 460 has been downloaded, it is passed into the Java VM 430, which then verifies the downloaded class file at step 320. Step 320 of verifying the class file is to ensure that the program will not cause security violations nor will it cause harm to the computer system resources. After the Java class file has been verified, the interpreter 432 begins interpreting the Java bytecodes of the class file 460.” [Col. 6 lines 45-53];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov and Jaeger to include decoding the binary format of the source file further comprises validating the source file against a set of runtime constraints of the virtualized environment using the teachings of Kwong. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of performing runtime compilations without exposing the system to failures or possible vulnerabilities (Kwong, Col. 2 lines 21-34).
With respect to claim 22, Sokolov and Jaeger teach The system of claim 15,
Sokolov and Jaeger do not explicitly teach decoding the binary format of the source file further comprises validating the source file against a set of runtime constraints of the virtualized environment.
However, analogous art Kwong teaches,
decoding the binary format of the source file “FIG. 4 illustrates a block diagram of the elements in a client computer system 400 equipped to interpret and compile Java class files.” [Col. 6 lines 29-31];
further comprises validating the source file against a set of runtime constraints of the virtualized environment. “After the class file 460 has been downloaded, it is passed into the Java VM 430, which then verifies the downloaded class file at step 320. Step 320 of verifying the class file is to ensure that the program will not cause security violations nor will it cause harm to the computer system resources. After the Java class file has been verified, the interpreter 432 begins interpreting the Java bytecodes of the class file 460.” [Col. 6 lines 45-53];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov and Jaeger to include decoding the binary format of the source file further comprises validating the source file against a set of runtime constraints of the virtualized environment using the teachings of Kwong. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of performing runtime compilations without exposing the system to failures or possible vulnerabilities (Kwong, Col. 2 lines 21-34).
Claim 3, 17, and 23 are rejected under 35 U.S.C. 103 as being unpatentable over US 7020874 B2 – hereinafter “Sokolov”, in view of US 20230195435 A1 – hereinafter “Jaeger”, further in view of US 20230092214 A1 – hereinafter “Wu”.
With respect to claim 3, Sokolov and Jaeger teach The method of claim 1
Sokolov and Jaeger do not explicitly teach wherein executing the process comprises making a system call to a of the virtualized runtime environment.
However, analogous art Wu teaches,
wherein executing the process comprises making a system call to a of the virtualized runtime environment. “Every operating system has some functions embedded in the kernel. These functions may be used by every operation of the system, and the functions used by Linux are called system calls (or systemcalls or syscalls)” [0041]; “According to a preferred mode, the virtual kernel constructing module is further configured to: allow the user to select how the virtual kernel is customized; semantically parse a user-edited customization file so as to generate a virtual kernel source code; compile the virtual kernel source code” [0015]; “The reconstruction sub-module also reconstructs the call table of the Linux kernel, and provides every container with an independent virtual kernel call table and isolated virtual kernel calls” [0072];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov an Jaeger to include wherein executing the process comprises making a system call to a of the virtualized runtime environment using the teachings of Wu. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of providing each container with fine-grained isolation while preserving the performance and scale of the containerized microservice, by having Syscalls serve as a controlled interface between the containerized microservice and the host operating system (Wu, 0064).
With respect to claim 17, Sokolov and Jaeger teach The non-transitory computer-readable medium of claim 14,
Sokolov and Jaeger do not explicitly teach wherein executing the process comprises making a system call to a of the virtualized runtime environment.
However, analogous art Wu teaches,
wherein executing the process comprises making a system call to a of the virtualized runtime environment. “Every operating system has some functions embedded in the kernel. These functions may be used by every operation of the system, and the functions used by Linux are called system calls (or systemcalls or syscalls)” [0041]; “According to a preferred mode, the virtual kernel constructing module is further configured to: allow the user to select how the virtual kernel is customized; semantically parse a user-edited customization file so as to generate a virtual kernel source code; compile the virtual kernel source code” [0015]; “The reconstruction sub-module also reconstructs the call table of the Linux kernel, and provides every container with an independent virtual kernel call table and isolated virtual kernel calls” [0072];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov an Jaeger to include wherein executing the process comprises making a system call to a of the virtualized runtime environment using the teachings of Wu. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of providing each container with fine-grained isolation while preserving the performance and scale of the containerized microservice, by having Syscalls serve as a controlled interface between the containerized microservice and the host operating system (Wu, 0064).
With respect to claim 23, Sokolov and Jaeger teach The system of claim 15,
Sokolov and Jaeger do not explicitly teach wherein executing the process comprises making a system call to a of the virtualized runtime environment.
However, analogous art Wu teaches,
wherein executing the process comprises making a system call to a of the virtualized runtime environment. “Every operating system has some functions embedded in the kernel. These functions may be used by every operation of the system, and the functions used by Linux are called system calls (or systemcalls or syscalls)” [0041]; “According to a preferred mode, the virtual kernel constructing module is further configured to: allow the user to select how the virtual kernel is customized; semantically parse a user-edited customization file so as to generate a virtual kernel source code; compile the virtual kernel source code” [0015]; “The reconstruction sub-module also reconstructs the call table of the Linux kernel, and provides every container with an independent virtual kernel call table and isolated virtual kernel calls” [0072];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov an Jaeger to include wherein executing the process comprises making a system call to a of the virtualized runtime environment using the teachings of Wu. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of providing each container with fine-grained isolation while preserving the performance and scale of the containerized microservice, by having Syscalls serve as a controlled interface between the containerized microservice and the host operating system (Wu, 0064).
Claim 4,18, and 24 is rejected under 35 U.S.C. 103 as being unpatentable over US 7020874 B2 – hereinafter “Sokolov”, in view of US 20230195435 A1 – hereinafter “Jaeger”, in view of US 20230092214 A1 – hereinafter “Wu”, further in view of US 20240134742 A1 – hereinafter “Hwang”.
With respect to claim 4, Sokolov, Jaeger, and Wu teach The method of claim 3,
Sokolov and Wu do not explicitly teach wherein the virtualized runtime environment is deployed on a hypervisor, and wherein making the system call comprises making a hypercall to the hypervisor.
Jaeger teaches,
wherein the virtualized runtime environment is deployed on a hypervisor, “FIG. 1A depicts the elements of a legacy platform (100) that uses hypervisor virtualization. The system hardware (10) may include, for example, a mainframe computer running a hypervisor (30), often as a virtual machine monitor (z/VM), to provide as set of fully isolated virtual machines (70)” [0005];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov to include wherein the virtualized runtime environment is deployed on a hypervisor using the teachings of Jaeger. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of running virtual environments tailored for specific applications while reducing or eliminating the possible overhead, inefficiencies, and failures caused by running standard binaries for all environments (Jaeger, 0008-0009).
Hwang teaches,
and wherein making the system call comprises making a hypercall to the hypervisor. “According to various embodiments, if the system is started, the compiler 610 may add an instruction for calling the hypervisor 530 from the kernel 520 to the original code (or executable file) 605” [0083];
Examiners note: The compiler adds the hypervisor call at the compilation/decoding stage. Executing the compiled file would cause a system call to the hypervisor to be performed.
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov, Jaeger, and Wu to include and wherein making the system call comprises making a hypercall to the hypervisor using the teachings of Hwang. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, to reduce overhead when deploying container while maintaining fine-grained control of hypervisor functionalities that might be required for a microservices execution (Hwang, 0086).
With respect to claim 18, Sokolov, Jaeger, and Wu teach The non-transitory computer-readable medium of claim 17,
Sokolov and Wu do not explicitly teach wherein the virtualized runtime environment is deployed on a hypervisor, and wherein making the system call comprises making a hypercall to the hypervisor.
Jaeger teaches,
wherein the virtualized runtime environment is deployed on a hypervisor, “FIG. 1A depicts the elements of a legacy platform (100) that uses hypervisor virtualization. The system hardware (10) may include, for example, a mainframe computer running a hypervisor (30), often as a virtual machine monitor (z/VM), to provide as set of fully isolated virtual machines (70)” [0005];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov to include wherein the virtualized runtime environment is deployed on a hypervisor using the teachings of Jaeger. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of running virtual environments tailored for specific applications while reducing or eliminating the possible overhead, inefficiencies, and failures caused by running standard binaries for all environments (Jaeger, 0008-0009).
Hwang teaches,
and wherein making the system call comprises making a hypercall to the hypervisor. “According to various embodiments, if the system is started, the compiler 610 may add an instruction for calling the hypervisor 530 from the kernel 520 to the original code (or executable file) 605” [0083];
Examiners note: The compiler adds the hypervisor call at the compilation/decoding stage. Executing the compiled file would cause a system call to the hypervisor to be performed.
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov, Jaeger, and Wu to include and wherein making the system call comprises making a hypercall to the hypervisor using the teachings of Hwang. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, to reduce overhead when deploying container while maintaining fine-grained control of hypervisor functionalities that might be required for a microservices execution (Hwang, 0086).
With respect to claim 24, Sokolov, Jaeger, and Wu teach The system of claim 23,
Sokolov and Wu do not explicitly teach wherein the virtualized runtime environment is deployed on a hypervisor, and wherein making the system call comprises making a hypercall to the hypervisor.
Jaeger teaches,
wherein the virtualized runtime environment is deployed on a hypervisor, “FIG. 1A depicts the elements of a legacy platform (100) that uses hypervisor virtualization. The system hardware (10) may include, for example, a mainframe computer running a hypervisor (30), often as a virtual machine monitor (z/VM), to provide as set of fully isolated virtual machines (70)” [0005];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov to include wherein the virtualized runtime environment is deployed on a hypervisor using the teachings of Jaeger. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of running virtual environments tailored for specific applications while reducing or eliminating the possible overhead, inefficiencies, and failures caused by running standard binaries for all environments (Jaeger, 0008-0009).
Hwang teaches,
and wherein making the system call comprises making a hypercall to the hypervisor. “According to various embodiments, if the system is started, the compiler 610 may add an instruction for calling the hypervisor 530 from the kernel 520 to the original code (or executable file) 605” [0083];
Examiners note: The compiler adds the hypervisor call at the compilation/decoding stage. Executing the compiled file would cause a system call to the hypervisor to be performed.
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov, Jaeger, and Wu to include and wherein making the system call comprises making a hypercall to the hypervisor using the teachings of Hwang. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, to reduce overhead when deploying container while maintaining fine-grained control of hypervisor functionalities that might be required for a microservices execution (Hwang, 0086).
Claim 5 are rejected under 35 U.S.C. 103 as being unpatentable over US 7020874 B2 – hereinafter “Sokolov”, in view of US 20230195435 A1 – hereinafter “Jaeger”, in view of in view of US 20240134742 A1 – hereinafter “Hwang”, in view of in view of US 20230418645 A1 – hereinafter “Tsirkin”, further in view of US 8874888 B1 – hereinafter “Beda”.
With respect to claim 5, Sokolov, Jaeger, and Hwang teach The method of claim 4,
Sokolov, Jaeger, and Hwang do not explicitly teach wherein: the virtualized runtime instance is instantiated in a user space, non-root mode; and the method further comprises mounting a virtual machine disk as a root file system of the virtualized runtime instance.
However, analogous art Tsirkin teaches,
wherein: the virtualized runtime instance is instantiated in a user space, non-root mode; “Supervisor 110 may manage the execution of one or more computing processes and provide the computing processes with access to one or more underlying computing devices (e.g., hardware or virtualized resources). Supervisor 110 may be the same or similar to a kernel and may be a part of an operating system, hypervisor, or a combination thereof… In another example, supervisor 110 may be a hypervisor or include hypervisor functionality and each of computing processes 120A-C may be or execute within a separate virtual machine or container. In either example, the supervisor may be implemented as part of a kernel and execute as one or more processes in kernel space (e.g., privileged mode, kernel mode, root mode)” [0023]; “ In one example, the privilege levels may correspond generally to a user mode (e.g., reduced privilege mode, non-root mode, non-privileged mode) and a supervisor mode (e.g., enhanced privilege mode, kernel mode, root mode)” [0026];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov, Jaeger, and Hwang to include wherein: the virtualized runtime instance is instantiated in a user space, non-root mode using the teachings of Tsirkin. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of increasing efficiency and improving performance by avoiding container-exit/transitions associated with root mode operations. Each container can be spun up according to the privileges required by each individual microservice (Tsirkin, 0026).
However, analogous art Beda teaches,
and the method further comprises mounting a virtual machine disk as a root file system of the virtualized runtime instance “Techniques and systems for managed boot are described. A described technique includes creating, at a server system, a boot image based on one or more user-specified parameters associated with virtual machine booting, providing a first virtual drive that includes the boot image, booting a virtual machine using the boot image on the first virtual drive, and providing a second virtual drive to the virtual machine, where the virtual machine mounts the second virtual drive as a root file system” [Abstract];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov, Jaeger, Hwang, and Tsirkin to include and the method further comprises mounting a virtual machine disk as a root file system of the virtualized runtime instance using the teachings of Beda. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, to streamline each microservice container by keeping only the minimal boot-time components in an immutable boot image and then mounting the remainder of the OS and application libraries at runtime (Beda, Col. 1 lines 36-50).
Claims 6, 20, 26 is rejected under 35 U.S.C. 103 as being unpatentable over US 7020874 B2 – hereinafter “Sokolov”, in view of US 20230195435 A1 – hereinafter “Jaeger”, in view of US 20240103882 A1 – hereinafter “Scrivano”, further in view of US 20230297352 A1 – hereinafter “Chen”.
With respect to claim 6, Sokolov and Jaeger teach The method of claim 1
Sokolov and Jaeger do not explicitly teach wherein: the virtualized runtime environment is a virtualized WebAssembly runtime environment; and the interface is a WebAssembly System Interface (WASI) layer.
However, analogous art Scrivano teaches,
wherein: the virtualized runtime environment is a virtualized WebAssembly runtime environment; “FIG. 1 is a block diagram showing an example process 100 by which a webassembly container engine can deploy and run a webassembly application using a webassembly unikernel, according to an example embodiment of the present disclosure. As shown in FIG. 1, the process 100 involves a container engine 112, a container image 116, and a virtual machine 118. The container engine 112 may comprise any portion or entirety of a software, program, module, plug-in, or code that: receives user requests; pulls, retrieves, and/or extracts container images; and runs or executes the container. In some embodiments, the container engine 112 may be executed on a computing system having resources that are shared, relied on, and/or allocated to a plurality of virtual machines via a hypervisor” [0018];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov and Jaeger to include wherein: the virtualized runtime environment is a virtualized WebAssembly runtime environment using the teachings of Scrivano. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of providing a microservice framework that is language-agnostic, lightweight, portable, and fast-executing (Scrivano, 0003).
However, analogous art Chen teaches,
and the interface is a WebAssembly System Interface (WASI) layer. “WebAssembly (WASM) is a new format that is portable, small, and compatible with the World Wide Web, and loads fast, and is a bytecode standard proposed to improve performance of performance-sensitive templates in web pages. A WebAssembly system interface (WASI) is a new application programming interface (API) system. The purpose of WASI is to design a set of engine-independent API standards oriented to non-web systems for WASM.” [0041]; “The WASI daemon process 120 performs snapshot management and startup on each instance in the WASI instance 1220 by using the WASI runtime 1210, so that when executing the delivered service, each instance in the WASI instance 1220 can be quickly started and serve upper-layer applications.” [0047];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov, Jaeger, and Scrivano to include the interface is a WebAssembly System Interface (WASI) layer using the teachings of Chen. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of establishing engine independent API standard for communication (Chen, 0041).
With respect to claim 20, Sokolov and Jaeger teach he non-transitory computer-readable medium of claim 14,
Sokolov and Jaeger do not explicitly teach wherein: the virtualized runtime environment is a virtualized WebAssembly runtime environment; and the interface is a WebAssembly System Interface (WASI) layer.
However, analogous art Scrivano teaches,
wherein: the virtualized runtime environment is a virtualized WebAssembly runtime environment; “FIG. 1 is a block diagram showing an example process 100 by which a webassembly container engine can deploy and run a webassembly application using a webassembly unikernel, according to an example embodiment of the present disclosure. As shown in FIG. 1, the process 100 involves a container engine 112, a container image 116, and a virtual machine 118. The container engine 112 may comprise any portion or entirety of a software, program, module, plug-in, or code that: receives user requests; pulls, retrieves, and/or extracts container images; and runs or executes the container. In some embodiments, the container engine 112 may be executed on a computing system having resources that are shared, relied on, and/or allocated to a plurality of virtual machines via a hypervisor” [0018];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov and Jaeger to include wherein: the virtualized runtime environment is a virtualized WebAssembly runtime environment using the teachings of Scrivano. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of providing a microservice framework that is language-agnostic, lightweight, portable, and fast-executing (Scrivano, 0003).
However, analogous art Chen teaches,
and the interface is a WebAssembly System Interface (WASI) layer. “WebAssembly (WASM) is a new format that is portable, small, and compatible with the World Wide Web, and loads fast, and is a bytecode standard proposed to improve performance of performance-sensitive templates in web pages. A WebAssembly system interface (WASI) is a new application programming interface (API) system. The purpose of WASI is to design a set of engine-independent API standards oriented to non-web systems for WASM.” [0041]; “The WASI daemon process 120 performs snapshot management and startup on each instance in the WASI instance 1220 by using the WASI runtime 1210, so that when executing the delivered service, each instance in the WASI instance 1220 can be quickly started and serve upper-layer applications.” [0047];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov, Jaeger, and Scrivano to include the interface is a WebAssembly System Interface (WASI) layer using the teachings of Chen. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of establishing engine independent API standard for communication (Chen, 0041).
With respect to claim 26, Sokolov and Jaeger teach The system of claim 15
Sokolov and Jaeger do not explicitly teach wherein: the virtualized runtime environment is a virtualized WebAssembly runtime environment; and the interface is a WebAssembly System Interface (WASI) layer.
However, analogous art Scrivano teaches,
wherein: the virtualized runtime environment is a virtualized WebAssembly runtime environment; “FIG. 1 is a block diagram showing an example process 100 by which a webassembly container engine can deploy and run a webassembly application using a webassembly unikernel, according to an example embodiment of the present disclosure. As shown in FIG. 1, the process 100 involves a container engine 112, a container image 116, and a virtual machine 118. The container engine 112 may comprise any portion or entirety of a software, program, module, plug-in, or code that: receives user requests; pulls, retrieves, and/or extracts container images; and runs or executes the container. In some embodiments, the container engine 112 may be executed on a computing system having resources that are shared, relied on, and/or allocated to a plurality of virtual machines via a hypervisor” [0018];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov and Jaeger to include wherein: the virtualized runtime environment is a virtualized WebAssembly runtime environment using the teachings of Scrivano. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of providing a microservice framework that is language-agnostic, lightweight, portable, and fast-executing (Scrivano, 0003).
However, analogous art Chen teaches,
and the interface is a WebAssembly System Interface (WASI) layer. “WebAssembly (WASM) is a new format that is portable, small, and compatible with the World Wide Web, and loads fast, and is a bytecode standard proposed to improve performance of performance-sensitive templates in web pages. A WebAssembly system interface (WASI) is a new application programming interface (API) system. The purpose of WASI is to design a set of engine-independent API standards oriented to non-web systems for WASM.” [0041]; “The WASI daemon process 120 performs snapshot management and startup on each instance in the WASI instance 1220 by using the WASI runtime 1210, so that when executing the delivered service, each instance in the WASI instance 1220 can be quickly started and serve upper-layer applications.” [0047];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov, Jaeger, and Scrivano to include the interface is a WebAssembly System Interface (WASI) layer using the teachings of Chen. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of establishing engine independent API standard for communication (Chen, 0041).
Claims 19 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over US 7020874 B2 – hereinafter “Sokolov”, in view of US 20230195435 A1 – hereinafter “Jaeger”, in view of in view of US 20230418645 A1 – hereinafter “Tsirkin”, further in view of US 8874888 B1 – hereinafter “Beda”.
With respect to claim 19, Sokolov, and Jaeger teach The non-transitory computer-readable medium of claim 14,
Sokolov and Jaeger do not explicitly teach wherein: the virtualized runtime instance is instantiated in a user space, non-root mode; and the method further comprises mounting a virtual machine disk as a root file system of the virtualized runtime instance.
However, analogous art Tsirkin teaches,
wherein: the virtualized runtime instance is instantiated in a user space, non-root mode; “Supervisor 110 may manage the execution of one or more computing processes and provide the computing processes with access to one or more underlying computing devices (e.g., hardware or virtualized resources). Supervisor 110 may be the same or similar to a kernel and may be a part of an operating system, hypervisor, or a combination thereof… In another example, supervisor 110 may be a hypervisor or include hypervisor functionality and each of computing processes 120A-C may be or execute within a separate virtual machine or container. In either example, the supervisor may be implemented as part of a kernel and execute as one or more processes in kernel space (e.g., privileged mode, kernel mode, root mode)” [0023]; “ In one example, the privilege levels may correspond generally to a user mode (e.g., reduced privilege mode, non-root mode, non-privileged mode) and a supervisor mode (e.g., enhanced privilege mode, kernel mode, root mode)” [0026];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov and Jaeger to include wherein: the virtualized runtime instance is instantiated in a user space, non-root mode using the teachings of Tsirkin. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of increasing efficiency and improving performance by avoiding container-exit/transitions associated with root mode operations. Each container can be spun up according to the privileges required by each individual microservice (Tsirkin, 0026).
However, analogous art Beda teaches,
and the method further comprises mounting a virtual machine disk as a root file system of the virtualized runtime instance “Techniques and systems for managed boot are described. A described technique includes creating, at a server system, a boot image based on one or more user-specified parameters associated with virtual machine booting, providing a first virtual drive that includes the boot image, booting a virtual machine using the boot image on the first virtual drive, and providing a second virtual drive to the virtual machine, where the virtual machine mounts the second virtual drive as a root file system” [Abstract];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov, Jaeger, and Tsirkin to include and the method further comprises mounting a virtual machine disk as a root file system of the virtualized runtime instance using the teachings of Beda. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, to streamline each microservice container by keeping only the minimal boot-time components in an immutable boot image and then mounting the remainder of the OS and application libraries at runtime (Beda, Col. 1 lines 36-50).
With respect to claim 25, Sokolov, and Jaeger teach The system of claim 15,
Sokolov and Jaeger do not explicitly teach wherein: the virtualized runtime instance is instantiated in a user space, non-root mode; and the method further comprises mounting a virtual machine disk as a root file system of the virtualized runtime instance.
However, analogous art Tsirkin teaches,
wherein: the virtualized runtime instance is instantiated in a user space, non-root mode; “Supervisor 110 may manage the execution of one or more computing processes and provide the computing processes with access to one or more underlying computing devices (e.g., hardware or virtualized resources). Supervisor 110 may be the same or similar to a kernel and may be a part of an operating system, hypervisor, or a combination thereof… In another example, supervisor 110 may be a hypervisor or include hypervisor functionality and each of computing processes 120A-C may be or execute within a separate virtual machine or container. In either example, the supervisor may be implemented as part of a kernel and execute as one or more processes in kernel space (e.g., privileged mode, kernel mode, root mode)” [0023]; “ In one example, the privilege levels may correspond generally to a user mode (e.g., reduced privilege mode, non-root mode, non-privileged mode) and a supervisor mode (e.g., enhanced privilege mode, kernel mode, root mode)” [0026];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov and Jaeger to include wherein: the virtualized runtime instance is instantiated in a user space, non-root mode using the teachings of Tsirkin. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of increasing efficiency and improving performance by avoiding container-exit/transitions associated with root mode operations. Each container can be spun up according to the privileges required by each individual microservice (Tsirkin, 0026).
However, analogous art Beda teaches,
and the method further comprises mounting a virtual machine disk as a root file system of the virtualized runtime instance “Techniques and systems for managed boot are described. A described technique includes creating, at a server system, a boot image based on one or more user-specified parameters associated with virtual machine booting, providing a first virtual drive that includes the boot image, booting a virtual machine using the boot image on the first virtual drive, and providing a second virtual drive to the virtual machine, where the virtual machine mounts the second virtual drive as a root file system” [Abstract];
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Sokolov, Jaeger, and Tsirkin to include and the method further comprises mounting a virtual machine disk as a root file system of the virtualized runtime instance using the teachings of Beda. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, to streamline each microservice container by keeping only the minimal boot-time components in an immutable boot image and then mounting the remainder of the OS and application libraries at runtime (Beda, Col. 1 lines 36-50).
Response to Arguments
Applicant’s arguments filed 08/22/2025 have been fully considered but they are not persuasive. Applicant argues in substance:
Jaeger fails to teach the transformation of a binary file as recited by claim 1. For example, claim 1 recites transforming a source file in a binary format into an executable in- memory data structure. The Examiner incorrectly equates this with Jaeger's disclosure of compiling source code into binaries. Office Action, at 12 (citing Jaeger, 0082). These are fundamentally different processes. Jaeger's compiling is a build-time activity performed by a developer to create the binaries from human-readable code. In contrast, the claimed invention performs a runtime activity on an already-compiled binary file to prepare it for execution. A POSITA would not consider a developer's compiler to be the same as a runtime environment's binary file loader. Jaeger simply does not teach or suggest the claimed runtime transformation step.
With regard to point (a), Examiner disagrees with Applicant. Jaeger is used to teach receiving at an interface the binary file. Sokolov teaches the transformation of a source file in a binary format into an executable in-memory data structure. Sokolov teaches performing a runtime activity on a binary file, as recited in claim 1. “Computer programs written in the Java.TM. programming language (and other languages) may be compiled into Java.TM. virtual machine instructions (typically referred to as Java.TM. bytecodes) that are suitable for execution by a Java.TM. virtual machine implementation.” [Col. 1 lines 36-41]. Java TM bytecode is then decode into the in memory data structure: “As another method for loading a class file into a virtual machine, another embodiment of the invention include the act of:… creating an internal representation of the class file in the virtual machine when the determining determines that an internal representation of the class file does not exist in the virtual machine; and loading into the virtual machine the selected information associated with the at least one method of the class and not loading into the virtual machine information that was not selected.” [Col. 3 lines 1-17].
Jaeger fails to teach the instantiation of a virtualized runtime instance, as recited claim 1. Claim 1 further recites instantiating a virtualized runtime instance based on the in-memory data structure described above. As the specification describes in a non-limiting example, this feature can provide a dynamic, just-in-time creation of a lightweight execution environment tailored to the specific process. Application, 0027, 0059. Jaeger, conversely, teaches a static, build-time packaging of all necessary components- including legacy emulators and OS elements-into a monolithic container image before execution. Jaeger, 0124. This static packaging of a heavy, emulated environment teaches away from the claimed invention's dynamic and lightweight approach for native execution.
With regard to point (b), Examiner disagrees with Applicant. Jaeger is used to teach receiving at an interface the binary file. Sokolov teaches instantiating a virtualized runtime instance based on the in-memory data structure. “an internal representation of the class is created. This internal representation can be, for example, the internal representation 206 illustrated in FIG. 3. Next, at operation 510, the required components of the class are identified and extracted from the raw-class heap. As will be appreciated, these components can be selected, for example, when the class is resolved. Accordingly, only the required components of the class need to be extracted after being identified. Thereafter, the extracted components of the class are loaded into the virtual machine at operation 512. This can include loading required methods and creating references for loaded methods in a method information portion (e.g., similar to a method table implemented in a standard Java.TM. class). The method 500 ends following operation 512.” [Col. 6 lines 37-51]. Additionally, Just-in-time environment tailoring demonstrated by “In one embodiment, class files suitable for loading into a virtual machine are initially loaded into a memory portion (e.g., heap memory). Then, information that is needed to be loaded into the virtual machine is selected. Finally, only the selected information is loaded into the virtual machine.” [Abstract].
A POSITA would not find it obvious to combine the references as proposed. Moreover, any reference including Jaeger cannot establish that claim 1 is prima facie unpatentable under § 103. The technique recited by claim 1 provides a solution to the problem of creating an efficient, secure, and lightweight runtime for modern, native binary formats like WebAssembly. Application, 0022. Jaeger, on the other hand, is directed to solving the problem of migrating legacy mainframe applications to a modern infrastructure. Jaeger, 0124. A POSITA seeking to improve the performance of a native WebAssembly runtime would not be motivated to incorporate Jaeger's teachings on emulating legacy systems or to combine those teachings with any reference to produce anything resembling the method of claim 1. Inclusion of Jaeger's teachings in any combination directed to WebAssembly runtimes would introduce the very overhead, complexity, and performance penalties that the present invention is designed to overcome. Thus, not only does Jaeger fail to teach or suggest multiple features against which it is cited, a POSITA would not believe that any combination including Jaeger would provide any reasonable expectation of success.
With regard to point (c), Examiner disagrees with Applicant. Jaeger is used to teach receiving at an interface the binary file. Sokolov is used to teach creating secure, and lightweight runtime environments (See points a and b). Additionally, Scrivano and Chen are used to teach the runtime WASM environment and WASI interfaces respectively. Scrivano teaches, “FIG. 1 is a block diagram showing an example process 100 by which a webassembly container engine can deploy and run a webassembly application using a webassembly unikernel, according to an example embodiment of the present disclosure. As shown in FIG. 1, the process 100 involves a container engine 112, a container image 116, and a virtual machine 118. The container engine 112 may comprise any portion or entirety of a software, program, module, plug-in, or code that: receives user requests; pulls, retrieves, and/or extracts container images; and runs or executes the container. In some embodiments, the container engine 112 may be executed on a computing system having resources that are shared, relied on, and/or allocated to a plurality of virtual machines via a hypervisor” [0018]. Chen teaches, “WebAssembly (WASM) is a new format that is portable, small, and compatible with the World Wide Web, and loads fast, and is a bytecode standard proposed to improve performance of performance-sensitive templates in web pages. A WebAssembly system interface (WASI) is a new application programming interface (API) system. The purpose of WASI is to design a set of engine-independent API standards oriented to non-web systems for WASM.” [0041]; “The WASI daemon process 120 performs snapshot management and startup on each instance in the WASI instance 1220 by using the WASI runtime 1210, so that when executing the delivered service, each instance in the WASI instance 1220 can be quickly started and serve upper-layer applications.” [0047].
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Examiner respectfully requests, in response to this Office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 CFR 1.111(c).
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MIGUEL A RODRIGUEZ DELGADO whose telephone number is (571)272-2813. The examiner can normally be reached Monday-Friday 9AM-5PM. 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, Bradley Teets can be reached on 571-272-3338. 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.
/M.A.R./Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights