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 office action is in response to claims filed on 02/15/2024. Claims 1-20 are pending.
Drawings
The drawings are objected to under 37 CFR 1.83(a) because they fail to show system 400 as described in line [0043] of the specification. Any structural detail that is essential for a proper understanding of the disclosed invention should be shown in the drawing. MPEP § 608.02(d). Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The disclosure is objected to because of the following informalities:
[0013] states "The address this issue" when it should be "To address this issue".
[0026] states "OS kernel 220" when it was previously referred to as "OS kernel 208".
[0026] states "overlay mount file system 208" but overlay mount file system does not exist in Figure 2 nor does 208 refer to it. 208 refers to the OS kernel.
[0027] states "OSkernel 208. There should be a space in between "OS" and "kernel".
[0033] states "cannot not be set differently", creating a double negative when it should probably be a single negative.
[0039] states "lower layer that resides in non-volatile storage and is mounted in ready-only mode". It should be "read-only mode".
Appropriate correction is required.
Claim Objections
Claims 7 and 14 objected to because of the following informalities: They claim "a lower layer that resides in non-volatile storage and is mounted in a ready-only mode." Appropriate correction is required.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-3, 5-6, 8-10, 12-13, 15-17, and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over DockerDocs (Using tmpfs mounts; published June 05, 2020; hereinafter referred to as DockerDocs), in view of openSUSE(Tuning the Memory Management Subsystem; published September 29, 2023; hereinafter referred to as openSUSE), in further view of Emelianov et al. (US8725963; published May 13, 2014; hereinafter referred to as Emelianov.), and in further view of Banerjee et al. (US-20170262215-A1; published September 14, 2017; hereinafter referred to as Banerjee).
As per claim 1, DockerDocs teaches
a method comprising: receiving a mount request comprising a request to mount a temporary file system for a container (e.g. DockerDocs: [Page 2; Paragraph 0002] discloses create a container with a tmpfs mount.),
wherein the mount request indicates that the temporary file system is to reside in volatile memory of the container (e.g. DockerDoc: [Page 2; Paragraph 0003] discloses a tmpfs mount is temporary, and only persisted in the host memory.),
and wherein the mount request includes one or more local memory-swapping specifications to be applied to the container (e.g. DockerDocs: [Page 4; Under specify tmpfs options] discloses tmpfs-size which lets users specify the size of the tmpfs mount in bytes. Unlimited by default. Please note changing the file size changes when the local memory swaps occur.);
receiving write operations addressed to the container (e.g. DockerDocs: [Page 2; Paragraph 0002] discloses the container can create files outside the container’s writable layer. Please note container can create files corresponds to Applicant's write operations addressed to the container.);
DockerDocs does not teach determining, by a processing device, whether to initiate local memory swapping for the container by comparing memory usage of the container with a threshold memory usage;
and in response to determining that local memory swapping is initiated, swapping data from the volatile memory of the container to a local swap file specified by the one or more local memory-swapping specifications included in the mount request.
However, openSUSE does teach determining, (e.g. openSUSE: [Page 4; Paragraph 0003] discloses when the amount of dirty memory reaches a specified number of pages in bytes (vm.dirty_background_bytes), the kernel begins writeback. Please note the dirty_background_bytes parameter corresponds to Applicant’s threshold memory usage.).
DockerDocs and openSUSE are in the same field of endeavor in terms of memory management and therefore it would have been obvious for one of ordinary skill in the art before the effective date of the claimed invention to have modified the teachings of DockerDocs with the teachings of openSUSE to determining, This causes the container to run more smoothly because the application is less likely to face memory shortage problems by swapping out data before the RAM fills up.
DockerDocs-openSUSE does not teach
and in response to determining that local memory swapping is initiated, swapping data from the volatile memory of the container to a local swap file specified by the one or more local memory-swapping specifications included in the mount request.
However, Emelianov does teach (e.g. Emelianov: [Fig. 6] discloses processing unit 21. Emelianov: [0016] discloses a set of configuration settings corresponding to each Container stored within the Container and a corresponding set of configuration settings for all Container s stored by the kernel, a unique file space, means for management of the particular Container. Please note openSUSE previously taught above the dirty_background_bytes parameter which is the global threshold for memory swapping. Emelianov teaches that configurations used for global, like dirty_background_bytes, can have corresponding settings to be applied for local as well.).
DockerDocs-openSUSE and Emelianov are in the same field of endeavor in terms of memory management and therefore it would have been obvious for one of ordinary skill in the art before the effective date of the claimed invention to have modified the teachings of DockerDocs-openSUSE with the teachings of Emelianov to This allows local containers to run more smoothly because the application is able to swap out data when they need to as compared to waiting for a global threshold.
DockerDocs-openSUSE-Emelianov does not teach in response to determining that local memory swapping is initiated, swapping data from the volatile memory of the container to a local swap file specified by the one or more local memory-swapping specifications included in the mount request.
However, Banerjee does teach in response to determining that local memory swapping is initiated, swapping data from the volatile memory of the container to a local swap file specified by the one or more local memory-swapping specifications (e.g. Banerjee: [0018] discloses in some cases (e.g., memory over-commitment), memory data in the virtual memory space can be stored in one or more locations in host storage 116, referred to as swap space or swap file 117. Swap file(s) 117 (i.e., 117.sub.1-117.sub.N) can be implemented as one or more files designated exclusively on a per-VM basis. Please note storing data in the VM exclusive swap files like 117.sub.1 corresponds to Applicant's swapping data to a local swap file.).
DockerDocs-openSUSE-Emelianov and Banerjee are in the same field of endeavor in terms of memory management and therefore it would have been obvious for one of ordinary skill in the art before the effective date of the claimed invention to have modified the teachings of DockerDocs-openSUSE-Emelianov with the teachings of Banerjee to in response to determining that local memory swapping is initiated, swapping data from the volatile memory of the container to a local swap file specified by the one or more local memory-swapping specifications Banerjee shows that personalized swap files can be used for each virtual machine. It would then be simple to then use that same idea for containers as well.
As per claim 2, DockerDocs-openSUSE-Emelianov-Banerjee teaches claim 1 as applied above. Emelianov further teaches wherein the container is a member of a container cluster comprising the container and a plurality of additional containers (e.g. Emelianov: [0012] discloses the Container, in the exemplary embodiment, is an isolated Virtual Environment (VE), where multiple containers share services of a single OS.), and wherein additional local memory-swapping specifications are specified for each of the plurality of additional containers individually (e.g. Emelianov: [0016] discloses a set of configuration settings corresponding to each Container stored within the Container and a corresponding set of configuration settings for all Container s stored by the kernel, a unique file space, means for management of the particular Container. Please note the set of configuration settings corresponding to each Container corresponds to Applicant’s local memory-swapping specifications for each container.).
As per claim 3, DockerDocs-openSUSE-Emelianov-Banerjee teaches claim 1 as applied above. Emelianov further teaches wherein determining whether to initiate local memory swapping for the container is performed by an OS kernel (e.g. Emelianov: [0002] discloses when the Container process requests memory from the OS, the memory manager allocates memory pages in the RAM and also allocates memory pages for the Container process in the VE/Container RAM. If no free VE/Container RAM is available, the process data is moved to a virtual SWAP file. Please note the memory manager corresponds to Applicant’s OS kernel.); and wherein the OS kernel is to perform a background cache management process in accordance with a set of global memory-swapping specifications (e.g. openSUSE: [Page 2; Paragraph 0002] discloses the VM is responsible for freeing up RAM when there is a shortage. [Page 6; Paragraph 0003] further discloses /proc/sys/vm/swappiness. This control is used to define how aggressively the kernel swaps out anonymous memory relative to pagecache and other caches. Increasing the value increases the amount of swapping. Please note VM corresponds to Applicant’s OS kernel because the VM is the memory management subsystem which is part of the kernel. Please note swappiness corresponds to Applicant’s global memory-swapping specification that determines how often background cache management is performed.).
As per claim 5, DockerDocs-openSUSE-Emelianov-Banerjee teaches claim 1 as applied above. openSUSE further teaches wherein the threshold memory usage is a soft memory limit specified by the one or more local memory-swapping specifications (e.g. openSUSE: [Page 7; Paragraph 0005] discloses /proc/sys/vm/dirty_background_ratio. This is the percentage of the total amount of free and reclaimable memory. When the amount of dirty pagecache exceeds this percentage, writeback threads start writing back dirty memory. The default value is 10 (%). Please note dirty_background_ratio is a global soft memory limit but as Emelianov taught above, global configurations can have corresponding local configurations.).
As per claim 6, DockerDocs-openSUSE-Emelianov-Banerjee teaches claim 1 as applied above. openSUSE teaches wherein the threshold memory usage is a hard memory limit specified by the one or more local memory-swapping specifications (e.g. openSUSE: [Page 8; Paragraph [0002] discloses /proc/sys/vm/dirty_ratio. Similar percentage value as for dirty_background_ratio. When this is exceeded, applications that want to write to the pagecache are blocked and start performing writeback as well. The default value is 20 (%). Please note dirty_ratio is a global hard memory limit but as Emelianov taught above, global configurations can have corresponding local configurations.).
As per claim 8, DockerDocs teaches
receive a mount request comprising a request to mount a temporary file system for a container (e.g. DockerDocs: [Page 2; Paragraph 0002] discloses create a container with a tmpfs mount.),
wherein the mount request indicates that the temporary file system is to reside in volatile memory of the container (e.g. DockerDoc: [Page 2; Paragraph 0003] discloses a tmpfs mount is temporary, and only persisted in the host memory.),
and wherein the mount request includes one or more local memory-swapping specifications to be applied to the container (e.g. DockerDocs: [Page 4; Under specify tmpfs options] discloses tmpfs-size which lets users specify the size of the tmpfs mount in bytes. Unlimited by default. Please note changing the file size changes when the local memory swaps occur.);
receive write operations addressed to the container (e.g. DockerDocs: [Page 2; Paragraph 0002] discloses the container can create files outside the container’s writable layer. Please note container can create files corresponds to Applicant's write operations addressed to the container.).
DockerDocs does not teach a memory; and a processing device operatively coupled to the memory, determine whether to initiate local memory swapping for the container based on a comparison of memory usage of the container with a threshold memory usage;
and in response to determining that local memory swapping is initiated, swap data from the volatile memory of the container to a local swap file specified by the one or more local memory-swapping specifications included in the mount request.
However, openSUSE does teach (e.g. openSUSE: [Page 4; Paragraph 0003] discloses when the amount of dirty memory reaches a specified number of pages in bytes (vm.dirty_background_bytes), the kernel begins writeback. Please note the dirty_background_bytes parameter corresponds to Applicant’s threshold memory usage.).
DockerDocs and openSUSE are in the same field of endeavor in terms of memory management and therefore it would have been obvious for one of ordinary skill in the art before the effective date of the claimed invention to have modified the teachings of DockerDocs with the teachings of openSUSE to This causes the container to run more smoothly because the application is less likely to face memory shortage problems by swapping out data before the RAM fills up.
DockerDocs-openSUSE a memory; and a processing device operatively coupled to the memory,
and in response to determining that local memory swapping is initiated, swap data from the volatile memory of the container to a local swap file specified by the one or more local memory-swapping specifications included in the mount request.
However, Emelianov does teach a memory; and a processing device operatively coupled to the memory, (e.g. Emelianov: [Fig. 6] discloses a processing system 21 connected via system bus 23 to ram 22. Emelianov: [0016] discloses a set of configuration settings corresponding to each Container stored within the Container and a corresponding set of configuration settings for all Container s stored by the kernel, a unique file space, means for management of the particular Container. Please note openSUSE previously taught above the dirty_background_bytes parameter which is the global threshold for memory swapping. Emelianov teaches that configurations used for global, like dirty_background_bytes, can have corresponding settings to be applied for local as well.).
DockerDocs-openSUSE and Emelianov are in the same field of endeavor in terms of memory management and therefore it would have been obvious for one of ordinary skill in the art before the effective date of the claimed invention to have modified the teachings of DockerDocs-openSUSE with the teachings of Emelianov to a memory; and a processing device operatively coupled to the memory, This allows local containers to run more smoothly because the application is able to swap out data when they need to as compared to waiting for a global threshold.
DockerDocs-openSUSE-Emelianov does not teach in response to determining that local memory swapping is initiated, swap data from the volatile memory of the container to a local swap file specified by the one or more local memory-swapping specifications included in the mount request.
However, Banerjee does teach in response to determining that local memory swapping is initiated, swap data from the volatile memory of the container to a local swap file specified by the one or more local memory-swapping specifications (e.g. Banerjee: [0018] discloses in some cases (e.g., memory over-commitment), memory data in the virtual memory space can be stored in one or more locations in host storage 116, referred to as swap space or swap file 117. Swap file(s) 117 (i.e., 117.sub.1-117.sub.N) can be implemented as one or more files designated exclusively on a per-VM basis. Please note storing data in the VM exclusive swap files like 117.sub.1 corresponds to Applicant's swapping data to a local swap file.).
DockerDocs-openSUSE-Emelianov and Banerjee are in the same field of endeavor in terms of memory management and therefore it would have been obvious for one of ordinary skill in the art before the effective date of the claimed invention to have modified the teachings of DockerDocs-openSUSE-Emelianov with the teachings of Banerjee in response to determining that local memory swapping is initiated, swap data from the volatile memory of the container to a local swap file specified by the one or more local memory-swapping specifications Banerjee shows that personalized swap files can be used for each virtual machine. It would then be obvious to then use that same idea for containers as well.
As per claim 9, DockerDocs-openSUSE-Emelianov-Banerjee teaches claim 8 as applied above. Emelianov further teaches wherein the container is a member of a container cluster comprising the container and a plurality of additional containers (e.g. Emelianov: [0012] discloses the Container, in the exemplary embodiment, is an isolated Virtual Environment (VE), where multiple containers share services of a single OS.), and wherein additional local memory-swapping specifications are specified for each of the plurality of additional containers individually (e.g. Emelianov: [0016] discloses a set of configuration settings corresponding to each Container stored within the Container and a corresponding set of configuration settings for all Container s stored by the kernel, a unique file space, means for management of the particular Container. Please note the set of configuration settings corresponding to each Container corresponds to Applicant’s local memory-swapping specifications for each container.).
As per claim 10, DockerDocs-openSUSE-Emelianov-Banerjee teaches claim 8 as applied above. Emelianov further teaches wherein the determination to initiate local memory swapping is performed by an OS kernel executing on the processing device (e.g. Emelianov: [0002] discloses when the Container process requests memory from the OS, the memory manager allocates memory pages in the RAM and also allocates memory pages for the Container process in the VE/Container RAM. If no free VE/Container RAM is available, the process data is moved to a virtual SWAP file. Please note the memory manager corresponds to Applicant’s OS kernel.), and wherein the OS kernel is configured to perform a background cache management process in accordance with a set of global memory-swapping specifications (e.g. openSUSE: [Page 2; Paragraph 0002] discloses the VM is responsible for freeing up RAM when there is a shortage. [Page 6; Paragraph 0003] further discloses /proc/sys/vm/swappiness. This control is used to define how aggressively the kernel swaps out anonymous memory relative to pagecache and other caches. Increasing the value increases the amount of swapping. Please note VM corresponds to Applicant’s OS kernel because the VM is the memory management subsystem which is part of the kernel. Please note swappiness corresponds to Applicant’s global memory-swapping specification that determines how often background cache management is performed.).
As per claim 12, DockerDocs-openSUSE-Emelianov-Banerjee teaches claim 8 as applied above. openSUSE further teaches wherein the threshold memory usage is a soft memory limit specified by the one or more local memory-swapping specifications (e.g. openSUSE: [Page 7; Paragraph 0005] discloses /proc/sys/vm/dirty_background_ratio. This is the percentage of the total amount of free and reclaimable memory. When the amount of dirty pagecache exceeds this percentage, writeback threads start writing back dirty memory. The default value is 10 (%). Please note dirty_background_ratio is a global soft memory limit but as Emelianov taught above, global configurations can have corresponding local configurations.).
As per claim 13, DockerDocs-openSUSE-Emelianov-Banerjee teaches claim 8 as applied above. openSUSE teaches wherein the threshold memory usage is a hard memory limit specified by the one or more local memory-swapping specifications (e.g. openSUSE: [Page 8; Paragraph [0002] discloses /proc/sys/vm/dirty_ratio. Similar percentage value as for dirty_background_ratio. When this is exceeded, applications that want to write to the pagecache are blocked and start performing writeback as well. The default value is 20 (%). Please note dirty_ratio is a global hard memory limit but as Emelianov taught above, global configurations can have corresponding local configurations.).
As per claim 15, DockerDocs teaches
receive a mount request comprising a request to mount a temporary file system for a container (e.g. DockerDocs: [Page 2; Paragraph 0002] discloses create a container with a tmpfs mount.),
wherein the mount request indicates that the temporary file system is to reside in volatile memory of the container (e.g. DockerDoc: [Page 2; Paragraph 0003] discloses a tmpfs mount is temporary, and only persisted in the host memory.),
and wherein the mount request includes one or more local memory-swapping specifications to be applied to the container (e.g. DockerDocs: [Page 4; Under specify tmpfs options] discloses tmpfs-size which lets users specify the size of the tmpfs mount in bytes. Unlimited by default. Please note changing the file size changes when the local memory swaps occur.);
receive write operations addressed to the container (e.g. DockerDocs: [Page 2; Paragraph 0002] discloses the container can create files outside the container’s writable layer. Please note container can create files corresponds to Applicant's write operations addressed to the container.).
DockerDocs does not teach a non-transitory computer-readable storage medium including instructions; determine, by the processing device, whether to initiate local memory swapping for the container based on a comparison of memory usage of the container with a threshold memory usage;
and in response to determining that local memory swapping is initiated, swap data from the volatile memory of the container to a local swap file specified by the one or more local memory-swapping specifications included in the mount request.
However, openSUSE does teach (e.g. openSUSE: [Page 4; Paragraph 0003] discloses when the amount of dirty memory reaches a specified number of pages in bytes (vm.dirty_background_bytes), the kernel begins writeback. Please note the dirty_background_bytes parameter corresponds to Applicant’s threshold memory usage.).
DockerDocs and openSUSE are in the same field of endeavor in terms of memory management and therefore it would have been obvious for one of ordinary skill in the art before the effective date of the claimed invention to have modified the teachings of DockerDocs with the teachings of openSUSE to This causes the container to run more smoothly because the application is less likely to face memory shortage problems by swapping out data before the RAM fills up.
DockerDocs-openSUSE does not teach a non-transitory computer-readable storage medium including instructions;
and in response to determining that local memory swapping is initiated, swap data from the volatile memory of the container to a local swap file specified by the one or more local memory-swapping specifications included in the mount request.
However, Emelianov does teach a non-transitory computer-readable storage medium including instructions; (e.g. Emelianov: [0042] discloses the drives and their associated computer-readable media provide non-volatile storage of computer readable instructions, data structures, program modules and other data for the personal computer 20. [Fig. 6] discloses processing unit 21. Emelianov: [0016] discloses a set of configuration settings corresponding to each Container stored within the Container and a corresponding set of configuration settings for all Container s stored by the kernel, a unique file space, means for management of the particular Container. Please note openSUSE previously taught above the dirty_background_bytes parameter which is the global threshold for memory swapping. Emelianov teaches that configurations used for global, like dirty_background_bytes, can have corresponding settings to be applied for local as well.).
DockerDocs-openSUSE and Emelianov are in the same field of endeavor in terms of memory management and therefore it would have been obvious for one of ordinary skill in the art before the effective date of the claimed invention to have modified the teachings of DockerDocs-openSUSE with the teachings of Emelianov to a non-transitory computer-readable storage medium including instructions; This allows local containers to run more smoothly because the application is able to swap out data when they need to as compared to waiting for a global threshold.
DockerDocs-openSUSE-Emelianov does not teach in response to determining that local memory swapping is initiated, swap data from the volatile memory of the container to a local swap file specified by the one or more local memory-swapping specifications included in the mount request.
However, Banerjee does teach in response to determining that local memory swapping is initiated, swap data from the volatile memory of the container to a local swap file specified by the one or more local memory-swapping specifications (e.g. Banerjee: [0018] discloses in some cases (e.g., memory over-commitment), memory data in the virtual memory space can be stored in one or more locations in host storage 116, referred to as swap space or swap file 117. Swap file(s) 117 (i.e., 117.sub.1-117.sub.N) can be implemented as one or more files designated exclusively on a per-VM basis. Please note storing data in the VM exclusive swap files like 117.sub.1 corresponds to Applicant's swapping data to a local swap file.).
DockerDocs-openSUSE-Emelianov and Banerjee are in the same field of endeavor in terms of memory management and therefore it would have been obvious for one of ordinary skill in the art before the effective date of the claimed invention to have modified the teachings of DockerDocs-openSUSE-Emelianov with the teachings of Banerjee in response to determining that local memory swapping is initiated, swap data from the volatile memory of the container to a local swap file specified by the one or more local memory-swapping specifications Banerjee shows that personalized swap files can be used for each virtual machine. It would then be simple to then use that same idea for containers as well.
As per claim 16, DockerDocs-openSUSE-Emelianov-Banerjee teaches claim 15 as applied above. Emelianov further teaches wherein the container is a member of a container cluster comprising the container and a plurality of additional containers (e.g. Emelianov: [0012] discloses the Container, in the exemplary embodiment, is an isolated Virtual Environment (VE), where multiple containers share services of a single OS.), and wherein additional local memory-swapping specifications are specified for each of the plurality of additional containers individually (e.g. Emelianov: [0016] discloses a set of configuration settings corresponding to each Container stored within the Container and a corresponding set of configuration settings for all Container s stored by the kernel, a unique file space, means for management of the particular Container. Please note the set of configuration settings corresponding to each Container corresponds to Applicant’s local memory-swapping specifications for each container.).
As per claim 17, DockerDocs-openSUSE-Emelianov-Banerjee teaches claim 15 as applied above. Emelianov further teaches wherein the determination to initiate local memory swapping is performed by an OS kernel executing on the processing device (e.g. Emelianov: [0002] discloses when the Container process requests memory from the OS, the memory manager allocates memory pages in the RAM and also allocates memory pages for the Container process in the VE/Container RAM. If no free VE/Container RAM is available, the process data is moved to a virtual SWAP file. Please note the memory manager corresponds to Applicant’s OS kernel.), and wherein the OS kernel is to perform a background cache management process in accordance with a set of global memory-swapping specifications (e.g. openSUSE: [Page 2; Paragraph 0002] discloses the VM is responsible for freeing up RAM when there is a shortage. [Page 6; Paragraph 0003] further discloses /proc/sys/vm/swappiness. This control is used to define how aggressively the kernel swaps out anonymous memory relative to pagecache and other caches. Increasing the value increases the amount of swapping. Please note VM corresponds to Applicant’s OS kernel because the VM is the memory management subsystem which is part of the kernel. Please note swappiness corresponds to Applicant’s global memory-swapping specification that determines how often background cache management is performed.).
As per claim 19, DockerDocs-openSUSE-Emelianov-Banerjee teaches claim 15 as applied above. openSUSE further teaches wherein the threshold memory usage is a soft memory limit specified by the one or more local memory-swapping specifications (e.g. openSUSE: [Page 7; Paragraph 0005] discloses /proc/sys/vm/dirty_background_ratio. This is the percentage of the total amount of free and reclaimable memory. When the amount of dirty pagecache exceeds this percentage, writeback threads start writing back dirty memory. The default value is 10 (%). Please note dirty_background_ratio is a global soft memory limit but as Emelianov taught above, global configurations can have corresponding local configurations.).
As per claim 20, DockerDocs-openSUSE-Emelianov-Banerjee teaches claim 15 as applied above. openSUSE teaches wherein the threshold memory usage is a hard memory limit specified by the one or more local memory-swapping specifications included in the mount request, and wherein the write operations addressed to the container are blocked while data is swapped from the volatile memory of the container to the local swap file (e.g. openSUSE: [Page 8; Paragraph [0002] discloses /proc/sys/vm/dirty_ratio. Similar percentage value as for dirty_background_ratio. When this is exceeded, applications that want to write to the pagecache are blocked and start performing writeback as well. The default value is 20 (%). Please note dirty_ratio is a global hard memory limit but as Emelianov taught above, global configurations can have corresponding local configurations.).
Claim(s) 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over DockerDocs-openSUSE-Emelianov-Banerjee, in view of Colbert et al. (7624240; published February 18, 2010; hereinafter referred to as Colbert.).
As per claim 4, DockerDocs-openSUSE-Emelianov-Banerjee teaches claim 1 as applied above. DockerDocs-openSUSE-Banerjee does not teach wherein the one or more local memory-swapping specifications are specified by an unprivileged user account.
However, Colbert does teach wherein the one or more local memory-swapping specifications are specified by an unprivileged user account (e.g. Colbert: [0029] discloses with the per-VM swap file of the present invention, all of the VM's swapped memory is contained within a regular per-VM swap file that can be controlled independently of other VMs' swap file, and is fully configurable. [0029] of the background discloses using a per-host common pool for swap space also prevents administrators and users of the host computer system. Please note Colbert specifically differentiated between privileged administrators and regular users of the computer. As a result, the regular per-VM swap file that is fully configurable by a regular user corresponds to the Applicant’s unprvilieged user specifying one or more local memory-swapping specifications.).
DockerDocs-openSUSE-Banerjee and Colbert are in the same field of endeavor in terms of memory management and therefore it would have been obvious for one of ordinary skill in the art before the effective date of the claimed invention to have modified the teachings of DockerDocs-openSUSE-Emelianov-Banerjee with the teachings of Colbert wherein the one or more local memory-swapping specifications are specified by an unprivileged user account. This allows for much greater flexibility when working with containers. It allows developers and administrators to tailor resource margins to unique workload demands.
As per claim 11, DockerDocs-openSUSE-Emelianov-Banerjee teaches claim 8 as applied above. DockerDocs-openSUSE-Banerjee does not teach wherein the one or more local memory-swapping specifications are specified by an unprivileged user account.
However, Colbert does teach wherein the one or more local memory-swapping specifications are specified by an unprivileged user account (e.g. Colbert: [0029] discloses with the per-VM swap file of the present invention, all of the VM's swapped memory is contained within a regular per-VM swap file that can be controlled independently of other VMs' swap file, and is fully configurable. [0029] of the background discloses using a per-host common pool for swap space also prevents administrators and users of the host computer system. Please note Colbert specifically differentiated between privileged administrators and regular users of the computer. As a result, the regular per-VM swap file that is fully configurable by a regular user corresponds to the Applicant’s unprvilieged user specifying one or more local memory-swapping specifications.).
DockerDocs-openSUSE-Banerjee and Colbert are in the same field of endeavor in terms of memory management and therefore it would have been obvious for one of ordinary skill in the art before the effective date of the claimed invention to have modified the teachings of DockerDocs-openSUSE-Emelianov-Banerjee with the teachings of Colbert wherein the one or more local memory-swapping specifications are specified by an unprivileged user account. This allows for much greater flexibility when working with containers. It allows developers and administrators to tailor resource margins to unique workload demands.
As per claim 18, DockerDocs-openSUSE-Emelianov-Banerjee teaches claim 15 as applied above. DockerDocs-openSUSE-Banerjee does not teach wherein the one or more local memory-swapping specifications are specified by an unprivileged user account.
However, Colbert does teach wherein the one or more local memory-swapping specifications are specified by an unprivileged user account (e.g. Colbert: [0029] discloses with the per-VM swap file of the present invention, all of the VM's swapped memory is contained within a regular per-VM swap file that can be controlled independently of other VMs' swap file, and is fully configurable. [0029] of the background discloses using a per-host common pool for swap space also prevents administrators and users of the host computer system. Please note Colbert specifically differentiated between privileged administrators and regular users of the computer. As a result, the regular per-VM swap file that is fully configurable by a regular user corresponds to the Applicant’s unprvilieged user specifying one or more local memory-swapping specifications.).
DockerDocs-openSUSE-Banerjee and Colbert are in the same field of endeavor in terms of memory management and therefore it would have been obvious for one of ordinary skill in the art before the effective date of the claimed invention to have modified the teachings of DockerDocs-openSUSE-Emelianov-Banerjee with the teachings of Colbert wherein the one or more local memory-swapping specifications are specified by an unprivileged user account. This allows for much greater flexibility when working with containers. It allows developers and administrators to tailor resource margins to unique workload demands.
Claim(s) 7 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over DockerDocs-openSUSE-Emelianov-Banerjee, in view of Kim et al. (Overlit: New Storage Driver for Localization and Specialization; published February 27, 2019; hereinafter referred to as Kim.).
As per claim 7, DockerDocs-openSUSE-Emelianov-Banerjee teaches claim 1 as applied above. DockerDocs-openSUSE-Banerjee does not teach wherein the temporary file system is an upper layer of an overlay file system, wherein the overlay file system further includes a lower layer that resides in non-volatile storage and is mounted in a ready-only mode.
However, Kim does teach wherein the temporary file system is an upper layer of an overlay file system (e.g. Kim: [Page 1; Paragraph 0004] discloses meanwhile, the upper layer is a temporary read-write filesystem which can be used in a container only while the container is alive. All the contents in the upper layer will be destroyed after the container is removed.), wherein the overlay file system further includes a lower layer that resides in non-volatile storage and is mounted in a ready-only mode (e.g. Kim: [Page 1; Paragraph 0004] discloses the lower layers keep all the contents necessary to run a service in a container, and they are set to read-only to prevent the container from modifying the layers and to guarantee the repeatability of the containers strongly. Please note this is under the assumption that ready-only mode refers to read-only mode.).
DockerDocs-openSUSE-Emelianov-Banerjee and Kim are in the same field of endeavor in terms of memory management and therefore it would have been obvious for one of ordinary skill in the art before the effective date of the claimed invention to have modified the teachings of DockerDocs-openSUSE-Emelianov-Banerjee with the teachings of Kim to wherein the temporary file system is an upper layer of an overlay file system, wherein the overlay file system further includes a lower layer that resides in non-volatile storage and is mounted in a ready-only mode. This improves security and efficiency. Files in the lower layer can never be corrupted, modified, or deleted. Multiple containers can share the same lower layer making it so that duplicating the same data multiple times unnecessary. And since upper layer files are all in RAM if a clean slate is needed, it is as simple as restarting the machine.
As per claim 14, DockerDocs-openSUSE-Banerjee teaches claim 8 as applied above. DockerDocs-openSUSE-Emelianov-Banerjee does not teach wherein the temporary file system is an upper layer of an overlay file system, wherein the overlay file system further includes a lower layer that resides in non-volatile storage and is mounted in a ready-only mode.
However, Kim does teach wherein the temporary file system is an upper layer of an overlay file system (e.g. Kim: [Page 1; Paragraph 0004] discloses meanwhile, the upper layer is a temporary read-write filesystem which can be used in a container only while the container is alive. All the contents in the upper layer will be destroyed after the container is removed.), wherein the overlay file system further includes a lower layer that resides in non-volatile storage and is mounted in a ready-only mode (e.g. Kim: [Page 1; Paragraph 0004] discloses the lower layers keep all the contents necessary to run a service in a container, and they are set to read-only to prevent the container from modifying the layers and to guarantee the repeatability of the containers strongly. Please note this is under the assumption that ready-only mode actually refers to read-only mode.).
DockerDocs-openSUSE-Emelianov-Banerjee and Kim are in the same field of endeavor in terms of memory management and therefore it would have been obvious for one of ordinary skill in the art before the effective date of the claimed invention to have modified the teachings of DockerDocs-openSUSE-Emelianov-Banerjee with the teachings of Kim to wherein the temporary file system is an upper layer of an overlay file system, wherein the overlay file system further includes a lower layer that resides in non-volatile storage and is mounted in a ready-only mode. This improves security and efficiency. Files in the lower layer can never be corrupted, modified, or deleted. Multiple containers can share the same lower layer making it so that duplicating the same data multiple times unnecessary. And since upper layer files are all in RAM if a clean slate is needed, it is as simple as restarting the machine.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL N TRUONG whose telephone number is (571)270-0856. The examiner can normally be reached Monday-Thursday 9:00AM-6:00PM.
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, April Blair can be reached at (571) 270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
/DANIEL NHU TRUONG/Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights