DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This action is made non-final.
Claims 1-20 filed on 01/30/2024 have been reviewed and considered by this office action.
Drawings
The drawings filed on 01/30/2024 have been reviewed and are considered acceptable.
Specification
The specification filed on 01/30/2024 has been reviewed and is considered acceptable.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over the USENIX paper “Firecracker: Lightweight Virtualization for Serverless Applications” (herein Firecracker), in view of Li et al. (US 9256532 B2, herein Chiang), Kumar et al. (US 20170357454 A1, herein Kumar), and Franaszek et al. (US 20080307188 A1 herein Poff).
Regarding claim 1, Firecracker teaches A system for implementing memory compression, comprising:
a host device
Firecracker, 422, column 2, paragraph 4: Firecracker is a Virtual Machine Monitor (VMM), which uses the Linux Kernel’s KVM virtualization infrastructure to pro vide minimal virtual machines (MicroVMs), supporting modern Linux hosts
Firecracker establishes a system running on a host device, in this case a Linux host
a plurality of micro virtual machines on the host device, each micro virtual machine including an application running thereon
Firecracker, 426, column 1, paragraph 1: Each worker runs hundreds or thousands of MicroVMs… EachMicroVM contains a single sandbox for a single customer function
MicroVMs are micro virtual machines, where the customer function is the application running thereon)
and an application monitor configured to monitor operation of each application
Firecracker, 427, column 1, paragraph 3: We keep detailed per-workload metrics, including latency and error-rate
Firecracker teaches application monitoring which due to the single function per MicroVM would track each application separately.
Firecracker does not teach
to ascertain memory use characteristics of each application and to determine a memory compression mechanism suitable for compressing memory used by each application based on the ascertained memory characteristics
However, Chiang teaches ascertaining memory use characteristics. See Chiang: [Column 7, Paragraph 1], the space in the zram driver 158 may be adjusted by the processor 110 according to a plurality of access probabilities of the memory pages
Chiang teaches adjusting zram space according to access probabilities of memory pages, which is making a determination regarding compression treatment based on ascertained memory characteristics (wherein the characteristics are access probabilities in this case
See Chiang: [Column 7, Paragraph 3] the access time of the memory pages on the LRU list may be recorded by the processor 110. Teaches that the memory pages are recorded (and thus must be monitored) fulfilling the function of determining these characteristics through monitoring as claimed )
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to adapt the application monitoring of Firecracker to incorporate the teachings of Chiang so as to include a compression determination based on ascertained memory characteristics. As set forth in MPEP § 2143, by combining the known technique of making a determination regarding compression based on memory characteristics as taught by Chiang with the application monitoring of Firecracker, one of ordinary skill would expect to achieve the predictable result of application monitoring capable of making a compression determination based on ascertained memory characteristics.
However, while the combination of Firecracker and Chiang teach an application monitor capable of making a compression determination based on ascertained memory characteristics, they do not explicitly teach that such a compression decision would determine a compression mechanism.
See Kumar [0005], The device further selects one of a plurality of compression algorithms based on at least a characteristic of the object
Kumar teaches a determination (the selection) of a compression mechanism (the algorithm) based on characteristics. The particular characteristics used in this determination are not explicitly defined as memory use characteristics; however Chiang has already addressed making such determinations based on access probability characteristics.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to adapt the compression determination based on ascertained memory characteristics of Firecracker and Chiang to incorporate the teachings of Kumar so as to include the determining a compression mechanism (or algorithm). As set forth in MPEP § 2143, by combining the known technique of determining a compression mechanism as taught by Kumar with the compression determination based of ascertained memory characteristics of Firecracker and Chiang, one of ordinary skill would expect to achieve the predictable result of a determination of a memory compression mechanism based on ascertained memory characteristics.
As per claim 2, Firecracker in combination with Chiang and Kumar teaches the system for implementing memory compression of claim 1 further including:
a hypervisor on which the plurality of micro virtual machines operate
see Chiang. [Column 4, Paragraph 1] A hypervisor is installed on the computer system 100 and supports virtual machine execution space within which at least one virtual machine may be concurrently instantiated and executed
Firecracker, 426, column 2, paragraph 4: Each worker runs hundreds or thousands of MicroVMs… Firecracker is a Virtual Machine Monitor (VMM), which uses the Linux Kernel’s KVM virtualization infrastructure to pro vide minimal virtual machines (MicroVMs)
Chiang teachers the inclusion of a hypervisor upon which virtual machines operate (instantiate and execute), Firecracker establishes the equivalent (a virtual machine monitor) with micro virtual machines
As per claim 3, Firecracker in combination with Chiang and Kumar teaches the system for implementing memory compression of claim 2
wherein at least one of the applications is configured to run on a container runtime.
see Firecracker, 420, column 2, paragraph 1: Firecracker’s process-per-VM model also means that it doesn’t offer VM orchestration, packaging, management or other features — it replaces QEMU, rather than Docker or Kubernetes, in the container stack.
Firecracker teaches that it “Replaces QEMU in the container stack”, placing both itself and its functions (applications) as running on containers.
As per claim 4, Firecracker in combination with Chiang and Kumar teaches the system for implementing memory compression of claim 2
wherein each micro virtual machine comprises
a guest operating system (OS) kernel.
See Firecracker, 426, column 1, paragraph 1: EachMicroVM contains a single sandbox for a single customer function, along with a minimized Linux kernel
Firecracker teaches that each microVM includes an OS kernel
As per claim 5, Firecracker in combination with Chiang and Kumar teaches the system for implementing memory compression of claim 2
wherein the memory use characteristics include at least one of memory accesses by the application and memory compressibility.
See Chiang [Column 8, Claim 1] maintaining a least recently used (LRU) list according to a last access time by at least one processor
Chiang teaches monitoring the characteristic of memory access See Kumar [31], the device selects the compression algorithm based on at least the object characterization, a predicted compression ratio for the object, and/or an amount of time that it takes the compression algorithm to run.
Kumar [45], This type of history-based predictor can also assist in reducing the computation overhead of the hybrid compression mechanism, by identifying sequences of pages that are incompressible or poorly compressible by one or all algorithms
Kumar teaches both making compression determinations on predictions regarding the compressibility of an object, as well as a mechanism to identify incompressible pages. Together, Chiang and Kumar teach the use of memory characteristics including memory accesses and compressibility.
As per claim 6, Firecracker in combination with Chiang and Kumar teaches the system for implementing memory compression of claim 1
wherein the memory compression mechanism comprises
memory compression on the host.
See Chiang [Column 1, Paragraph 3], A host machine is an actual physical machine on which the virtualization takes place
Chiang establishes the host machine and the presence of virtualization (and thus the hypervisor) on that host. However, Chiang, along with Firecracker and Kumar do not necessarily establish that the memory compression takes place on the host.
See Poff [34], the computing system 100 includes, for example, one or more processors 102, operating system (OS) 125, a cache 104, a memory controller 106
See Poff [37], Functions of the memory controller 106 that includes a compressor/decompressor 107 for compression and decompression of data
Poff establishes a compressor (compression mechanism) that is a function of the memory controller (a physical component of the computing system, establishing that the memory controller is host hardware) and thus that the compressor is on the host.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to adapt the memory compression system of Firecracker in combination with Chiang and Kumar to incorporate the teachings of Poff so as to include the compressor on the host. As set forth in MPEP § 2143, by combining the known technique of a compressor on the host machine as taught by Poff with the memory compression mechanism of Firecracker in combination with Chiang and Kumar, one of ordinary skill would expect to achieve the predictable result of a compression mechanism as described in firecracker, Chiang, and Kumar on a host device.
As per claim 7, Firecracker in combination with Chiang, Kumar, and Poff teaches the system for implementing memory compression of claim 4
wherein the memory compression mechanism comprises
memory compression on the guest OS of the micro virtual machine.
See Chiang [Column 4, Paragraph 3]: The guest OS 155 includes a guest kernel 156 with a LRU list 157 and a zram driver 158
See Chiang [Column 2, Paragraph 2]: As to compress the swapped-out pages, a zram driver, an experimental module of a Linux kernel, may present as a swap disk in the virtual machines, compress and store the swapped-out pages in guest memory.
Chiang establishes that the zram driver is a component of the guest kernel, and that it performs compression in guest memory
As per claim 8, Firecracker in combination with Chiang, Kumar, and Poff teaches the system for implementing memory compression of claim 1
wherein memory compression is performed by a CPU of the host.
See Poff [0029] The processes depicted in the figures that follow, are performed by processing logic that comprises hardware (e.g., circuitry, dedicated logic, etc.), software (such as is run on a general-purpose computer system or a dedicated machine), or a combination of both.
See Poff [0033] the device 100 includes a central processing unit (CPU) 102
See Poff [0034] the VMS 104 manages the use of the memory by compressing objects stored in memory… the VMS 104 selects a compression algorithm
Poff teaches a VMS that compresses memory through an algorithm, and also teaches that software such as this would be run on a “general-purpose computer system”, which is later identified as the CPU included in the device. This CPU is described as a subcomponent of the physical device, not a guest’s virtual CPU. Thus, Poff teaches the possibility of the memory compression being performed by a CPU located on the host machine.
As per claim 9, Firecracker in combination with Chiang, Kumar, and Poff teaches the system for implementing memory compression of claim 1
wherein memory compression is performed by a hardware accelerator.
See Poff [0005]: A convenient way to perform this compression is by automatically compressing the data using special-purpose hardware, with a minimum of intervention by the software or operating system. This permits compression/decompression to be done rapidly, avoiding what might otherwise be long delays associated with software compression/decompression.
Poff teaches special purpose hardware capable of compressing data, allowing compression to be done rapidly. Thus establishing compression by a hardware accelerator.
As per claim 10, Firecracker in combination with Chiang, Kumar, and Poff teaches the system for implementing memory compression of claim 4
wherein each guest OS includes memory swap functionality.
See Chiang [Column 4, Paragraph 5] a guest kernel may swap the content to a swap disk, mark the corresponding PTE of the process to be not-present, and then free the corresponding memory page.
Chiang teaches the guest kernel (and thus the guest OS) includes functionality to swap memory.
As per claim 11, Firecracker in combination with Chiang, Kumar, and Poff teaches the system for implementing memory compression of claim 1
wherein the memory compression mechanism comprises
one of a tiered zram swap, a non-tiered zram swap, an SSD swap, and no memory compression.
See Chiang [Column 5, Paragraph 4]: when a page fault occurs, the missing page may be fetched from the zram driver 158, in which case the fault leads to a pseudo page fault, or from the swap disk 130, See Chiang [Column 7, Paragraph 5]: the processor 110 may dynamically adjust the size of the zram driver 158 by evicting the cold memory pages in the zram driver 158 to the swap disk 130.
See Chiang [Column 3, Paragraph 10]: the swap disk 130 may be an area on a hard disk drive (HDD) or a solid state drive (SSD) on the computer system 100 to offload excessive data from the system memory 120.
See Chiang [Column 6, Paragraph 4]: the processor 110 may directs all future swapped-out memory pages from the virtual machine 150 to the swap disk 130 without attempting to compress them
Chiang teaches all four options as claimed: Pages served from zram (non-tiered zram), zram whose cold pages are evicted is a two tier arrangement (zram as the fast tier and the disk as the backing tier, thus a tiered zram swap), a SSD swap, and no compression.
As per claim 12, Firecracker in combination with Chiang, Kumar, and Poff teaches A computer program product residing on a non-transitory computer readable medium having a plurality of instructions stored thereon which, when executed by a processor, cause the processor to perform operations comprising:
see Kumar [0006] a non-transitory machine-readable medium containing executable program instructions which when executed by a data processing device cause the device to perform a method to compress an object stored in memory of the device.
Kumar teaches a non-transitory computer readable product which when executed perform operations for memory compression.
monitoring operation of each of a plurality of applications running in an associated micro virtual machine residing on a host
see Firecracker, 422, column 2, paragraph 4: Firecracker is a Virtual Machine Monitor (VMM), which uses the Linux Kernel’s KVM virtualization infrastructure to pro vide minimal virtual machines (MicroVMs), supporting modern Linux hosts
see Firecracker, 427, column 1, paragraph 3: We keep detailed per-workload metrics, including latency and error-rate
Firecracker establishes a system running on a host device, monitoring micro virtual machines on the host.
ascertaining memory use characteristics of each application
See Chiang: [Column 7, Paragraph 1], the space in the zram driver 158 may be adjusted by the processor 110 according to a plurality of access probabilities of the memory pages
Chiang teaches ascertaining memory use characteristics to make a decision (determination) regarding memory compression.
and determining a memory compression mechanism suitable for compressing memory used by each application based on the ascertained memory characteristics
See Chiang: [Column 7, Paragraph 1], the space in the zram driver 158 may be adjusted by the processor 110 according to a plurality of access probabilities of the memory pages
Chiang teaches ascertaining memory use characteristics to make a decision (determination) regarding memory compression.
See Kumar Abstract, The device further selects one of a plurality of compression algorithms based on at least a characteristic of the object
Kumar teaches a determination (the selection) of a compression mechanism (the algorithm) based on characteristics.
As per claim 13, Firecracker in combination with Chiang, Kumar, and Poff teaches the computer program product of claim 12
wherein each micro virtual machine comprises
a guest operating system (OS) kernel.
See Firecracker, 426, column 1, paragraph 1: EachMicroVM contains a single sandbox for a single customer function, along with a minimized Linux kernel
Firecracker teaches that each microVM includes an OS kernel
As per claim 14, Firecracker in combination with Chiang, Kumar, and Poff teaches the computer program product of claim 13
wherein the memory use characteristics include at least one of memory accesses by the application and memory compressibility.
See Chiang [Column 8, Claim 1] maintaining a least recently used (LRU) list according to a last access time by at least one processor
Chiang teaches monitoring the characteristic of memory access See Kumar [31], the device selects the compression algorithm based on at least the object characterization, a predicted compression ratio for the object, and/or an amount of time that it takes the compression algorithm to run.
Kumar [45], This type of history-based predictor can also assist in reducing the computation overhead of the hybrid compression mechanism, by identifying sequences of pages that are incompressible or poorly compressible by one or all algorithms
Kumar teaches both making compression determinations on predictions regarding the compressibility of an object, as well as a mechanism to identify incompressible pages. Together, Chiang and Kumar teach the use of memory characteristics including memory accesses and compressibility.
As per claim 15 Firecracker in combination with Chiang, Kumar, and Poff teaches the computer program product of claim of claim 12
wherein the memory compression mechanism comprises
memory compression on the host.
See Chiang [Column 1, Paragraph 3], A host machine is an actual physical machine on which the virtualization takes place
Chiang establishes the host machine and the presence of virtualization (and thus the hypervisor) on that host.
See Poff [34], the computing system 100 includes, for example, one or more processors 102, operating system (OS) 125, a cache 104, a memory controller 106
See Poff [37], Functions of the memory controller 106 that includes a compressor/decompressor 107 for compression and decompression of data
Poff establishes a compressor (compression mechanism) that is a function of the memory controller (a physical component of the computing system, establishing that the memory controller is host hardware) and thus that the compressor is on the host.
As per claim 16, Firecracker in combination with Chiang, Kumar, and Poff teaches the computer program product of claim of claim 13
wherein the memory compression mechanism comprises
memory compression on the guest OS of the micro virtual machine.
See Chiang [Column 4, Paragraph 3]: The guest OS 155 includes a guest kernel 156 with a LRU list 157 and a zram driver 158
See Chiang [Column 2, Paragraph 2]: As to compress the swapped-out pages, a zram driver, an experimental module of a Linux kernel, may present as a swap disk in the virtual machines, compress and store the swapped-out pages in guest memory.
Chiang establishes that the zram driver is a component of the guest kernel, and that it performs compression in guest memory
As per claim 17, Firecracker in combination with Chiang, Kumar, and Poff teaches A computing system comprising:
a memory
Firecracker, 419, column 1, paragraph 1: We have deployed Firecracker in two publically-available serverless compute services
Firecracker, 420, column 1, paragraph 3: With the provided minimal Linux guest kernel con figuration, it offers memory overhead
Firecracker establishes a computing system with memory
and a processor configured to
See Poff [34], the computing system 100 includes, for example, one or more processors 102, operating system (OS) 125, a cache 104, a memory controller 106
Poff teaches that the computing system includes a processor
monitor operation of each of a plurality of applications running in an associated micro virtual machine residing on a host
Firecracker, 422, column 2, paragraph 4: Firecracker is a Virtual Machine Monitor (VMM), which uses the Linux Kernel’s KVM virtualization infrastructure to pro vide minimal virtual machines (MicroVMs), supporting modern Linux hosts
Firecracker establishes a monitor of MicroVms (and their applications) residing on a host.
ascertain memory use characteristics of each application
See Chiang: [Column 7, Paragraph 1], the space in the zram driver 158 may be adjusted by the processor 110 according to a plurality of access probabilities of the memory pages
Chiang teaches adjusting zram space according to access probabilities of memory pages, which is making a determination regarding compression treatment based on ascertained memory characteristics (wherein the characteristics are access probabilities in this case).
and determine a memory compression mechanism suitable for compressing memory used by each application based on the ascertained memory characteristics
See Kumar Abstract, The device further selects one of a plurality of compression algorithms based on at least a characteristic of the object
Kumar teaches a determination (the selection) of a compression mechanism (the algorithm) based on characteristics.
As per claim 18, Firecracker in combination with Chiang, Kumar, and Poff teaches the computer program product of claim 17
wherein each micro virtual machine comprises
a guest operating system (OS) kernel.
See Firecracker, 426, column 1, paragraph 1: EachMicroVM contains a single sandbox for a single customer function, along with a minimized Linux kernel
Firecracker teaches that each microVM includes an OS kernel
As per claim 19, Firecracker in combination with Chiang, Kumar, and Poff teaches the computer program product of claim 17
wherein the memory use characteristics include at least one of memory accesses by the application and memory compressibility.
See Chiang [Column 8, Claim 1] maintaining a least recently used (LRU) list according to a last access time by at least one processor
Chiang teaches monitoring the characteristic of memory access See Kumar [31], the device selects the compression algorithm based on at least the object characterization, a predicted compression ratio for the object, and/or an amount of time that it takes the compression algorithm to run.
Kumar [45], This type of history-based predictor can also assist in reducing the computation overhead of the hybrid compression mechanism, by identifying sequences of pages that are incompressible or poorly compressible by one or all algorithms
Kumar teaches both making compression determinations on predictions regarding the compressibility of an object, as well as a mechanism to identify incompressible pages. Together, Chiang and Kumar teach the use of memory characteristics including memory accesses and compressibility.
As per claim 20, Firecracker in combination with Chiang, Kumar, and Poff teaches the computer program product of claim of claim 17
wherein the memory compression mechanism comprises
memory compression on the host.
See Chiang [Column 1, Paragraph 3], A host machine is an actual physical machine on which the virtualization takes place
Chiang establishes the host machine and the presence of virtualization (and thus the hypervisor) on that host.
See Poff [34], the computing system 100 includes, for example, one or more processors 102, operating system (OS) 125, a cache 104, a memory controller 106
See Poff [37], Functions of the memory controller 106 that includes a compressor/decompressor 107 for compression and decompression of data
Poff establishes a compressor (compression mechanism) that is a function of the memory controller (a physical component of the computing system, establishing that the memory controller is host hardware) and thus that the compressor is on the host.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEFFERSON TAYLOR MATRICARDI whose telephone number is (571)270-0765. 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, Aimee Li can be reached at 5712724169. 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.
/J.T.M./Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights