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 applicant’s amendment filed on 03/26/2026.
Claims 1-20 are pending and examined.
The non-final rejection office action dated 12/13/2015 has been withdrawn.
Response to Arguments
Applicant's arguments filed 03/26/2026 with respect to 35 U.S.C. 101 have been fully considered but they are not persuasive. Applicant argued that “independent Claims 1 and 10 are not directed to the alleged mental processes indicated in the Office Action for at least the reason that each of Claims 1 and 10 as whole, and in light of the specification, reflects an improvement to the functioning of disaggregated memory technology.” Examiner respectfully disagrees, see 35 U.S.C. 101 rejections below for a detailed analysis. With respect to the recommendations noted in the interview summary, the examiner would like to clarify that the recommendation was not to explicitly include the improvement itself in the claim, but rather, to have the components and steps for the improvement in the claims. Therefore, as claims 1 and 10 were not amended to further elaborate on the identified mental processes or improvements, the 35 U.S.C. 101 rejections are maintained.
Applicant's arguments filed 03/26/2026 with respect to 35 U.S.C. 103 have been fully considered but they are not persuasive. Applicant argued that the rejections of claims 1 and 10 should be withdrawn due to the Radi reference not qualifying as prior art. While the examiner agrees that the Radi reference is not eligible as prior art, the rejections for claims 1 and 10 are maintained - see 35 U.S.C. 103 rejections below for a detailed analysis. The existing reference of Chigurapati discloses the application program sending a memory allocation request to a VM kernel, which is redirected to an emulator and hypervisor. The kernel choosing to not execute the request and instead redirecting the request to the emulator hypervisor for execution therefore correlates to parsing the packet to identify a memory request from an application executed by the VM. Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Miyamuko with Chigurapati because system virtualization with in-memory file systems improve overall network performance. Switching networks can use network elements to route information and data packets, which can increase or decrease over time depending on the demand of network services. Hardware resources can additionally be allocated for a network system in a VM environment when receiving a memory allocation request sent from an application program to a VM kernel.
With regards to claim 19, the applicant argued that the applied art fails to disclose or suggest a network controller "retrieving memory usage information added to packets sent by the plurality of servers via the network to network devices." While Miyamuko does not explicitly teach that the disclosed memory usage information is added to packets sent by the plurality of servers via the network to network devices of the plurality of network devices and that the memory usage information indicates usage of shared memory by applications, transmitting information via packets in a server between network devices is a popular method of communication as evidenced by Chigurapati. Additionally, applications executed by VMs sharing memory is a popular method of memory management as evidenced by Jain, and a plurality of network devices communicating with a plurality of servers is a popular configuration of servers as evidenced by Jain. Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Miyamuko with Jain because infrequent interactions with the global pool can result in significant improvements in performance, particularly when the workload is distributed across many processors.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that use the word “means” or “step” and are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph because the claim limitation(s) do not recite(s) sufficient structure, materials, or acts to entirely perform the recited function. Such claim limitation(s) is/are: “means for: … retrieving/performing/sending” in claim 19.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-18 are rejected under 35 U.S.C. 101 because the claimed invention is directed to (an) abstract idea(s) without significantly more.
Claims 1 and 10 recite:
A server, comprising:
at least one local memory configured to be used at least in part as a shared memory;
a network interface configured to communicate with one or more network devices via a network, the one or more network devices each configured to provide a respective shared memory via the network; and
at least one processor configured to: execute a Virtual Switching (VS) kernel module in a kernel space of the at least one local memory, the VS kernel module configured to:
receive a packet from a Virtual Machine (VM) executed by the at least one processor or by a processor of a remote server;
parse the packet to identify a memory request from an application executed by the VM;
determine memory usage information for the application based at least in part on the identified memory request;
provide the determined memory usage information to a VS controller executed by the at least one processor; and
adjust, using the VS controller, at least one of a memory request rate and a memory allocation for the application based at least in part on the determined memory usage information.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 1 is a machine.
Claim 10 is a process.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature, or natural phenomenon?
Yes: (an) abstract idea(s).
The ‘parsing’ limitation in #2 above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. The limitation “parsing” in the context of this claim encompasses a person analyzing, evaluating, or parsing a packet to identify a memory request, including comparison or judgement.
The ‘determining’ limitation in #3 above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. The limitation “determining” in the context of this claim encompasses a person analyzing, evaluating, or determining memory usage information for the application, including comparison or judgement.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘receiving’ limitation in #1 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element that is insignificant extra-solution activity. The limitation “receiving” in the context of this claim encompasses mere data gathering. See MPEP 2106.05(g).
The ‘providing’ limitation in #4 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element that is insignificant extra-solution activity. The limitation “providing” in the context of this claim encompasses mere data gathering. See MPEP 2106.05(g).
The ‘adjusting’ limitation in #5 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “adjusting” in the context of this claim encompasses merely adjusting the memory request rate or memory allocation for the application. See MPEP 2106.05(f).
Additionally, one or more of the claims recite the following additional elements:
Local memory (Claims 1 and 10)
Shared memory (Claims 1 and 10)
Network interface (Claim 1)
One or more network devices (Claims 1 and 10)
Virtual switching kernel module (Claims 1 and 10)
These additional elements are recited at a high level of generality (i.e., as generic computer components) such that they amount to no more than components comprising mere instructions to apply the exception. Accordingly, these additional elements do not integrate the abstract idea(s) into a practical application because they do not impose any meaningful limits on practicing the abstract ideas(s).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(g)&(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 1 and 10 are directed to (an) abstract idea(s) without significantly more.
Claims 2 and 11 recite:
wherein the at least one processor is further configured, individually or in combination, to:
use the VS kernel module to further provide memory request performance information for different applications to the VS controller; and
adjust, using the VS controller, at least one of memory request rates and memory allocations for the different applications executed by one or more VMs based at least in part on the memory request performance information.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 2 is a machine.
Claim 11 is a process.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘providing’ limitation in #6 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element that is insignificant extra-solution activity. The limitation “providing” in the context of this claim encompasses mere data gathering. See MPEP 2106.05(g).
The ‘adjusting’ limitation in #7 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “adjusting” in the context of this claim encompasses merely adjusting the memory request rate or memory allocation for the application. See MPEP 2106.05(f).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(g)&(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 2 and 11 are directed to (an) abstract idea(s) without significantly more.
Claims 3 and 12 recite:
wherein the at least one processor is further configured, individually or in combination, to:
retain previous memory usage information for a previously executed application; and
in response to a new execution of the previously executed application, set at least one of a new memory request rate and a new memory allocation for the previously executed application based on the retained previous memory usage information.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 3 is a machine.
Claim 12 is a process.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘retaining’ limitation in #8 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element that is insignificant extra-solution activity. The limitation “retaining” in the context of this claim encompasses merely retaining information in memory. See MPEP 2106.05(g).
The ‘setting’ limitation in #9 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “setting” in the context of this claim encompasses merely setting a new memory request rate or memory allocation for the application. See MPEP 2106.05(f).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(g)&(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Additionally, with regards to #8 above, per MPER 2106.05(d)(II), the courts have recognized the following computer functions as well-understood, routine, and conventional functions when they are claimed in a merely generic matter (e.g., at a high level of generality) or as insignificant extra-solution activity:
Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93;
Therefore, Claims 3 and 12 are directed to (an) abstract idea(s) without significantly more.
Claims 4 and 13 recite:
wherein the at least one processor is further configured, individually or in combination, to:
use the VS controller to adjust memory request rates and memory allocations for applications executed by local VMs running at the server and by remote VMs running at remote servers on the network.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 4 is a machine.
Claim 13 is a process.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘adjusting’ limitation in #10 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “adjusting” in the context of this claim encompasses merely adjusting the memory request rate or memory allocation for the application. See MPEP 2106.05(f).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 4 and 13 are directed to (an) abstract idea(s) without significantly more.
Claims 5 and 14 recite:
wherein the at least one processor is further configured, individually or in combination, to:
use the VS kernel module to update a data structure in the kernel space for monitoring respective memory usage by different applications.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 5 is a machine.
Claim 14 is a process.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘updating’ limitation in #11 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “updating” in the context of this claim encompasses merely updating a data structure in the kernel space. See MPEP 2106.05(f).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 5 and 14 are directed to (an) abstract idea(s) without significantly more.
Claims 6 and 15 recite:
wherein the at least one processor is further configured, individually or in combination, to:
set, using the VS controller, at least one of memory request rates and memory allocations for VMs accessing the shared memory at the least one local memory;
provide the at least one of memory request rates and memory allocations set by the VS controller to the VS kernel module; and
use the VS kernel module to send an indication of at least one of a set memory request rate and a set memory allocation to at least one VM.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 6 is a machine.
Claim 15 is a process.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘setting’ limitation in #12 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “setting” in the context of this claim encompasses merely setting the memory request rate or memory allocation for the application. See MPEP 2106.05(f).
The ‘providing’ limitation in #13 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element that is insignificant extra-solution activity. The limitation “providing” in the context of this claim encompasses mere data gathering. See MPEP 2106.05(g).
The ‘sending’ limitation in #14 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “sending” in the context of this claim encompasses merely sending an indication to at least one VM. See MPEP 2106.05(f).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(g)&(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 6 and 15 are directed to (an) abstract idea(s) without significantly more.
Claims 7 and 16 recite:
wherein the at least one processor is further configured, individually or in combination, to:
determine, using the VS kernel module, that a level of pending requests in at least one submission queue for the shared memory is greater than or equal to a threshold level of pending requests; and
in response to determining that the level of pending requests in the at least one submission queue is greater than or equal to the threshold level, set a congestion notification in a message sent to a remote VM.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 7 is a machine.
Claim 16 is a process.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature, or natural phenomenon?
Yes: (an) abstract idea(s).
The ‘determining’ limitation in #15 above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. The limitation “determining” in the context of this claim encompasses a person analyzing, evaluating, or determining whether the level of pending requests in a submission queue is greater than or equal to a threshold, including comparison or judgement.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘setting’ limitation in #16 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “setting” in the context of this claim encompasses merely setting a congestion notification in a message. See MPEP 2106.05(f).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 7 and 16 are directed to (an) abstract idea(s) without significantly more.
Claims 8 and 17 recite:
wherein the at least one processor is further configured, individually or in combination, to:
use the VS kernel module to add at least one of memory usage information and memory request performance information for different applications to messages sent from the server via the network interface for use by
a network controller on the network in performing at least one of setting memory request rates and allocating memory for applications executed by servers on the network.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 8 is a machine.
Claim 17 is a process.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘adding’ limitation in #17 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “adding” in the context of this claim encompasses merely adding memory usage information or memory request performance information to messages. See MPEP 2106.05(f).
The ‘setting’ limitation in #18 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “setting” in the context of this claim encompasses merely setting a memory request rate or allocating memory for applications. See MPEP 2106.05(f).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 8 and 17 are directed to (an) abstract idea(s) without significantly more.
Claims 9 and 18 recite:
wherein the at least one processor is further configured, individually or in combination, to:
receive, from a network controller via the network interface, at least one of memory request rates and memory allocations for one or more applications executed by the at least one processor; and
adjust memory usage by the one or more applications based on the at least one of memory request rates and memory allocations received from the network controller.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 9 is a machine.
Claim 18 is a process.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘receiving’ limitation in #19 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element that is insignificant extra-solution activity. The limitation “receiving” in the context of this claim encompasses mere data gathering. See MPEP 2106.05(g).
The ‘adjusting’ limitation in #20 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “adjusting” in the context of this claim encompasses merely adjusting the memory request rate or memory allocation for the application. See MPEP 2106.05(f).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(g)&(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 9 and 18 are directed to (an) abstract idea(s) without significantly more.
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(s) 1-6, 8-15 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Miyamuko (US Patent No. US 20100235669 A1), hereinafter “Miyamuko” in view of Jain et al. (U.S. Patent No. US 11494297 B2), hereinafter “Jain,” Chigurapati et al. (U.S. Patent No. US 9703582 B1), hereinafter “Chigurapati.”
With regards to Claim 1, Miyamuko teaches:
determine memory usage information for the application based at least in part on the identified memory request (Fig. 2, paragraphs 33-34 and 36, “When a process running on the OS 40 executes a memory allocation request, the memory management section 403 accesses the process management section 401 and acquires (inputs) information indicating the process that has executed the memory allocation request (step S11). More specifically, the memory management section 403 acquires (inputs) the average startup time, average memory usage amount, and startup count of the process, which the process management section 401 acquired (extracted) from the process statistical information storage section 402. Next, the memory management section 403 acquires (inputs) the average startup time of all processes, which the process management section 401 acquired (extracted) from the process statistical information storage section 402 (step S12) … Next, the memory management section 403 predicts (calculates) a remaining memory request amount from the average memory usage amount and allocated memory usage amount of the process (step S14).” The memory management unit acquiring information indicating the process that has executed the memory allocation request including average startup time, average memory usage of the corresponding process, and number of times the process started and calculating the remaining memory request amount correlates to determining memory usage information for the application based at least in part on the identified memory request);
provide the determined memory usage information to a controller executed by the at least one processor (Fig. 2, paragraphs 36-37, “Next, the memory management section 403 predicts (calculates) a remaining memory request amount from the average memory usage amount and allocated memory usage amount of the process (step S14). Next, the memory management section 403 issues a request for physical memory to the VMM 20 (step S15). In this instance, the memory management section 403 passes (outputs) hint information for memory allocation, or more specifically, information indicative of a process generation (indicating either a long-lived process or a short-lived process) and information indicative of the predicted remaining memory request amount, to the VMM 20.” The memory management unit passing the information indicating the predicted remaining memory request amount to the VMM to execute processing for the requesting physical memory correlates to providing the determined memory usage information to a controller executed by the at least one processor); and adjust, using the controller, at least one of a memory request rate and a memory allocation for the application based at least in part on the determined memory usage information (Fig. 2 and 2B, paragraphs 39-40 and 44, “In accordance with the information indicative of a process generation, which was passed (input) from the OS 40, the physical memory management section 211 determines the physical memory to be allocated to the process (step S21). More specifically, if the process generation is short-lived, the physical memory management section 211 selects a physical memory for a short-lived process. If, on the other hand, the process generation is long-lived, the physical memory management section 211 selects a physical memory for a long-lived process. Next, the physical memory management section 211 determines (calculates) the total amount of available physical memory at an allocation destination and judges whether there is an allocatable area (step S22) … If the judgment result obtained in step S22 indicates that allocation is achievable, the physical memory management section 211 allocates a memory block of the size specified by the OS 40 (step S23). More specifically, the physical memory management section 211 updates the information contained in the memory allocation table 212 and stores the correlation between a memory area and a process assigned to the memory area in the memory allocation table 212. If the process is long-lived, the physical memory management section 211 locates a virtual memory area corresponding to a long-lived physical memory in accordance with the address conversion table 213 and assigns the long-lived process to the located virtual memory area. If, on the other hand, the process is short-lived, the physical memory management section 211 locates a virtual memory area corresponding to a short-lived physical memory in accordance with the address conversion table 213 and assigns the short-lived process to the located virtual memory area.” The physical memory management unit allocating a virtual memory area based on the request correlates to adjusting at least one of a memory allocation for the application based at least in part on the determined memory usage information using the controller).
Miyamuko does not explicitly teach that the controller is a VS controller. However, virtual switching techniques are a popular method of packet management as evidenced by Chigurapati below (Fig. 1-2, Col. 4, lines 19-24 and 44-50 and Col. 7, lines 29-34).
Miyamuko does not explicitly teach:
A server, comprising:
at least one local memory configured to be used at least in part as a shared memory;
a network interface configured to communicate with one or more network devices via a network, the one or more network devices each configured to provide a respective shared memory via the network; and
at least one processor configured, individually or in combination, to: execute a Virtual Switching (VS) kernel module in a kernel space of the at least one local memory, the VS kernel module configured to:
receive a packet from a Virtual Machine (VM) executed by the at least one processor or by a processor of a remote server;
parse the packet to identify a memory request from an application executed by the VM;
However, Jain teaches:
A server, comprising:
at least one local memory configured to be used at least in part as a shared memory (Col. 2, lines 21-37 and Col. 3, lines 10-14, “In embodiments, a memory manager manages two kinds of memory pools: a global pool shared by all processors and a local pool for each processor. At system start, all available memory is claimed by the global pool. If the local pool has sufficient memory to serve the request, the memory manager fulfills the request from the local pool. This path is lockless. If the local pool does not have sufficient memory, the memory manager requests a chunk of memory from the global pool for use in the local pool. This allocation of memory from the global pool to the local pool is performed under locking. Processes release memory back to the local pool. This is also a lockless operation. When total free memory in the local pool exceeds a threshold, the memory can be returned back to the global pool.… Local storage 163 may comprise magnetic disks, solid-state disks, flash memory, and the like as well as combinations thereof. In some embodiments, local storage 163 in each host 120 can be aggregated and provisioned as part of a virtual storage area network (SAN).” The global memory pool being shared across all processors correlates to a shared memory. The memory allocation requests being fulfilled through a local or global pool and being returned back to the global pool correlates to at least one local memory configured to be used at least in part as a shared memory);
a network interface configured to communicate with one or more network devices via a network, the one or more network devices each configured to provide a respective shared memory (Col. 2, lines 21-37 and lines 65-67 and Col. 3, lines 1-3 and 6-14, “In embodiments, a memory manager manages two kinds of memory pools: a global pool shared by all processors and a local pool for each processor. At system start, all available memory is claimed by the global pool. If the local pool has sufficient memory to serve the request, the memory manager fulfills the request from the local pool. This path is lockless. If the local pool does not have sufficient memory, the memory manager requests a chunk of memory from the global pool for use in the local pool. This allocation of memory from the global pool to the local pool is performed under locking. Processes release memory back to the local pool. This is also a lockless operation. When total free memory in the local pool exceeds a threshold, the memory can be returned back to the global pool… As shown, a hardware platform 122 of host 120 includes conventional components of a computing device, such as central processing units (CPUs) 160, system memory (e.g., random access memory (RAM) 162), one or more network interface controllers (NICs) 164, and optionally local storage 163… NICs 164 enable host 120 to communicate with other devices through a physical network 180. Physical network 180 enables communication between hosts 120 and between other components and hosts 120 (other components discussed further herein). Local storage 163 may comprise magnetic disks, solid-state disks, flash memory, and the like as well as combinations thereof. In some embodiments, local storage 163 in each host 120 can be aggregated and provisioned as part of a virtual storage area network (SAN).” The network interface controllers in each of the hosts enabling hosts to communicate with other hosts through the physical network correlates to a network interface configured to communicate with one or more network devices via the network. All the available memory being initially claimed by a global pool and allocated to local pools for processors to use based on requests before being returned back to the global pool correlates to the one or more network devices each configured to provide a respective shared memory);
Jain does not explicitly teach that the network devices provide a respective shared memory via the network. However, network devices providing memory via a network is a popular method of memory allocation as evidenced by Chigurapati (Fig. 1, Col. 4, lines 19-24 and 44-50, “One embodiment of the presently claimed invention discloses a network device or node having one or more routers and/or switches able to redistribute information, system states, and/or context between virtual machines (“VMs”) via information or data stored in a virtualized in-memory file system (“VIMFS”). To implement data transfer between VMs, the VIMFS manages and facilitates memory allocation via hypervisor. For example, VIMFS is able to pass the memory allocation request from kernel to emulator upon receipt of the request from an application program. The memory allocation request is again forwarded from the emulator to the hypervisor for storage allocation… In one embodiment, CO 116 and/or network devices in network 104 employ a VIMFS such as VIMFS 164-166. VIMFS 164 or 166, which can reside in any devices in network 104, is able to facilitate and provide nearly instantaneous data transfer of IMFS from one VM to another, without substantial performance penalty, data loss, size restrictions, and/or marshaling.” The network devices in the network using VIMFS and hypervisor to facilitate data transfer from different VMs correlates to one or more network devices each configured to provide memory via the network).
Additionally, Chigurapati teaches:
and at least one processor configured, individually or in combination, to: execute a Virtual Switching (VS) kernel module in a kernel space of the at least one local memory (Fig. 1-2, Col. 4, lines 19-24 and 44-50 and Col. 7, lines 29-34, “One embodiment of the presently claimed invention discloses a network device or node having one or more routers and/or switches able to redistribute information, system states, and/or context between virtual machines (“VMs”) via information or data stored in a virtualized in-memory file system (“VIMFS”). To implement data transfer between VMs, the VIMFS manages and facilitates memory allocation via hypervisor. For example, VIMFS is able to pass the memory allocation request from kernel to emulator upon receipt of the request from an application program. The memory allocation request is again forwarded from the emulator to the hypervisor for storage allocation… In one embodiment, CO 116 and/or network devices in network 104 employ a VIMFS such as VIMFS 164-166. VIMFS 164 or 166, which can reside in any devices in network 104, is able to facilitate and provide nearly instantaneous data transfer of IMFS from one VM to another, without substantial performance penalty, data loss, size restrictions, and/or marshaling… In one aspect, VIMFS 210 is at least a part of hypervisor 230 configured to create persistent storage areas for VMs. For example, hypervisor 230 is able to present allocated storage location in IMFS or memory to an application program as its local memory and allows it to access a memory-mapped filed system.” The VIMFS being part of a hypervisor and configured to create persistent storage areas for multiple VMs as local memory correlates to a kernel space of the at least one local memory. The network devices in the network using VIMFS and hypervisor and having one or more switches to facilitate data transfer from different VMs correlates to executing a Virtual Switching (VS) kernel module in a kernel space of the at least one local memory), the VS kernel module configured to:
receive a packet from a Virtual Machine (VM) executed by the at least one processor or by a processor of a remote server (Fig. 6, Col. 3, lines 59-64, Col. 4, lines 66-67, Col. 5, lines 1-4, and Col. 11, lines 30-39, “IP communication network, IP network, or communication network means any type of network having an access network that is able to transmit data in a form of packets or cells, such as ATM (Asynchronous Transfer Mode) type, on a transport medium, for example, the TCP/IP or UDP/IP type… Switching network 104 receives and/or routes information, such as packet streams and packet flows between users and/or providers connected to the network. Network 104 includes communication devices or network elements (“NEs”) 130-140 which are also known as nodes, switches, bridges, and/or routers… FIG. 6 is a flowchart illustrating an exemplary process of allocating memory space via IMFS in accordance with one embodiment of the present invention. At block 602, a process of allocating hardware resource for a network system in a VM environment receives a memory allocation request sent from an application program to a VM kernel. At block 604, instead of executing the request, the kernel redirects the request to an emulator which operates between the abstraction layer of the VM kernel and the abstraction layer of hypervisor emulating and supporting VMs.” The application program sending a memory allocation request to a VM kernel, which is redirected to an emulator, correlates to receiving a request from a VM executed by the at least one processor of a remote server. The communication network transmitting data in the form of packets correlates to receiving a packet from a virtual machine);
parse the packet to identify a memory request from an application executed by the VM (Fig. 6, Col. 4, lines 66-67, Col. 5, lines 1-4, and Col. 11, lines 30-44, “Switching network 104 receives and/or routes information, such as packet streams and packet flows between users and/or providers connected to the network. Network 104 includes communication devices or network elements (“NEs”) 130-140 which are also known as nodes, switches, bridges, and/or routers… FIG. 6 is a flowchart illustrating an exemplary process of allocating memory space via IMFS in accordance with one embodiment of the present invention. At block 602, a process of allocating hardware resource for a network system in a VM environment receives a memory allocation request sent from an application program to a VM kernel. At block 604, instead of executing the request, the kernel redirects the request to an emulator which operates between the abstraction layer of the VM kernel and the abstraction layer of hypervisor emulating and supporting VMs. At block 606, upon receipt of the request, the emulator again forwards the request to the hypervisor for execution. At block 608, a portion of storage space is allocated in a memory or physical memory disk organized in the IMFS configuration by the hypervisor according to the request.” The application program sending a memory allocation request to a VM kernel, which is redirected to an emulator and hypervisor, correlates to a memory request from an application executed by the VM. The kernel choosing to not execute the request and instead redirecting the request to the emulator hypervisor for execution correlates to parsing the packet to identify a memory request from an application executed by the VM);
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Miyamuko with a server, comprising: at least one local memory configured to be used at least in part as a shared memory; a network interface configured to communicate with one or more network devices via a network, the one or more network devices each configured to provide a respective shared memory as taught by Jain because infrequent interactions with the global pool can result in significant improvements in performance, particularly when the workload is distributed across many processors (Jain: Col. 2, lines 55-59).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Miyamuko with at least one processor configured to: execute a Virtual Switching (VS) kernel module in a kernel space of the at least one local memory, the VS kernel module configured to: receive a packet from a Virtual Machine (VM) executed by the at least one processor or by a processor of a remote server, parse the packet to identify a memory request from an application executed by the VM as taught by Chigurapati because system virtualization with in-memory file systems improve overall network performance. Switching networks can use network elements to route information and data packets, which can increase or decrease over time depending on the demand of network services. Hardware resources can additionally be allocated for a network system in a VM environment when receiving a memory allocation request sent from an application program to a VM kernel (Chigurapati: Col. 2, lines 60-64, Col. 4, lines 66-67, Col. 5, lines 1-20 and Col. 11, lines 30-44).
With regards to Claim 10, the machine of Claim 1 performs the same steps as the method of Claim 10, and Claim 10 is therefore rejected using the same rationale set forth above in the rejection of Claim 1.
With regards to Claim 2, Miyamuko in view of Jain and Chigurapati teaches the system of Claim 1 above. Miyamuko further teaches:
wherein the at least one processor is further configured, individually or in combination, to:
use the module to further provide memory request performance information for different applications to the controller (Paragraphs 20-21, “Next, the memory management unit 403 acquires (inputs) the average startup time of all processes acquired (extracted) by the process management unit 401 from the process statistical information storage unit 402 (step S12).” The memory management unit acquiring the average startup time for all processes from the process management unit correlates to using the module to provide memory request performance information for different applications to the controller); and
adjust, using the controller, at least one of memory request rates and memory allocations for the different applications executed by one or more VMs based at least in part on the memory request performance information (Fig. 2 and 2B, paragraphs 26-27, 39-40 and 44, “The process management section 401 causes the process statistical information storage section 402 to store the average startup time and average memory usage amount of an application (hereinafter referred to as a process) running on the OS. The process statistical information storage section 402 is managed by the OS 40 to store statistical information including the information about the average startup time and average memory usage amount of each process… In accordance with the information indicative of a process generation, which was passed (input) from the OS 40, the physical memory management section 211 determines the physical memory to be allocated to the process (step S21). More specifically, if the process generation is short-lived, the physical memory management section 211 selects a physical memory for a short-lived process. If, on the other hand, the process generation is long-lived, the physical memory management section 211 selects a physical memory for a long-lived process. Next, the physical memory management section 211 determines (calculates) the total amount of available physical memory at an allocation destination and judges whether there is an allocatable area (step S22) … If the judgment result obtained in step S22 indicates that allocation is achievable, the physical memory management section 211 allocates a memory block of the size specified by the OS 40 (step S23). More specifically, the physical memory management section 211 updates the information contained in the memory allocation table 212 and stores the correlation between a memory area and a process assigned to the memory area in the memory allocation table 212. If the process is long-lived, the physical memory management section 211 locates a virtual memory area corresponding to a long-lived physical memory in accordance with the address conversion table 213 and assigns the long-lived process to the located virtual memory area. If, on the other hand, the process is short-lived, the physical memory management section 211 locates a virtual memory area corresponding to a short-lived physical memory in accordance with the address conversion table 213 and assigns the short-lived process to the located virtual memory area.” The process statistical information storage section storing information on each application or process of the OS correlates to different applications executed by one or more VMs. The physical memory management unit allocating a virtual memory area based on a request from one of the many processes correlates to adjusting at least one of a memory allocation for the different applications based at least in part on the memory request performance information).
With regards to Claim 11, the machine of Claim 2 performs the same steps as the method of Claim 11, and Claim 11 is therefore rejected using the same rationale set forth above in the rejection of Claim 2.
With regards to Claim 3, Miyamuko in view of Jain, and Chigurapati teaches the system of Claim 1 above. Miyamuko further teaches:
wherein the at least one processor is further configured, individually or in combination, to:
retain previous memory usage information for a previously executed application (Paragraphs 79 and 81, “The process information storage section stores operation history information (such as the average startup time of a process) which represents a process operation history… The memory request amount calculation section predicts and calculates the amount of memory to be requested by a process in accordance with the operation history information (such as the average memory usage amount) stored in the process information storage section when the process is to be generated in a virtual machine.” The process information storage section storing information such as the average memory usage amount of a process from a virtual machine correlates to retaining previous memory usage information for a previously executed application); and
in response to a new execution of the previously executed application, set at least one of a new memory request rate and a new memory allocation for the previously executed application based on the retained previous memory usage information (Paragraphs 81, “The memory request amount calculation section predicts and calculates the amount of memory to be requested by a process in accordance with the operation history information (such as the average memory usage amount) stored in the process information storage section when the process is to be generated in a virtual machine.” The process having operation history information stored in the process information storage section correlates to a previously executed application. The process being generated in a virtual machine and having the memory request amount calculation section referencing the operation history information correlates to a new execution of the previously executed application. Therefore, the memory request amount calculation section calculating the amount of memory to be requested by a process to be generated by a virtual machine based on the historical average memory usage amount correlates to setting at least one of a new memory allocation for a new execution of the previously executed application).
With regards to Claim 12, the machine of Claim 3 performs the same steps as the method of Claim 12, and Claim 12 is therefore rejected using the same rationale set forth above in the rejection of Claim 3.
With regards to Claim 4, Miyamuko in view of Jain, and Chigurapati teaches the system of Claim 1 above. Miyamuko further teaches:
wherein the at least one processor is further configured, individually or in combination, to use the controller to adjust memory allocations for applications executed by local VMs running at the server (Fig. 1, 2 and 2B, paragraphs 17, 39-40 and 44, “The VMM 20 is capable of dividing and managing resources (physical memories, etc.) included in the physical server 10. The VMM 20 is also capable of controlling a virtual machine (VM) 30 that is implemented by virtualizing a resource of the physical server 10… In accordance with the information indicative of a process generation, which was passed (input) from the OS 40, the physical memory management section 211 determines the physical memory to be allocated to the process (step S21). More specifically, if the process generation is short-lived, the physical memory management section 211 selects a physical memory for a short-lived process. If, on the other hand, the process generation is long-lived, the physical memory management section 211 selects a physical memory for a long-lived process. Next, the physical memory management section 211 determines (calculates) the total amount of available physical memory at an allocation destination and judges whether there is an allocatable area (step S22) … If the judgment result obtained in step S22 indicates that allocation is achievable, the physical memory management section 211 allocates a memory block of the size specified by the OS 40 (step S23). More specifically, the physical memory management section 211 updates the information contained in the memory allocation table 212 and stores the correlation between a memory area and a process assigned to the memory area in the memory allocation table 212. If the process is long-lived, the physical memory management section 211 locates a virtual memory area corresponding to a long-lived physical memory in accordance with the address conversion table 213 and assigns the long-lived process to the located virtual memory area. If, on the other hand, the process is short-lived, the physical memory management section 211 locates a virtual memory area corresponding to a short-lived physical memory in accordance with the address conversion table 213 and assigns the short-lived process to the located virtual memory area.” The physical memory management unit allocating a virtual memory area of the physical server to the VM based on the request correlates to adjusting a memory allocation for the application executed by local VMs running at the server using the controller).
Miyamuko does not explicitly teach that the controller adjusts memory request rates for local VMs running at the server and that the controller adjusts memory request rates and memory allocations for applications executed by remote VMs running at remote servers on the network. However, adjusting memory request rates of VMs is a popular method of memory management as evidenced by Jain (Col. 5, lines 16-19 and 47-59, “To remediate this issue, memory manager 110 can use a monotonously increasing counter for each CPU 160. The activity counter is incremented on each allocation and deallocation… At step 212, memory manager 110 determines whether this is the first allocation request. If so, the method proceeds to step 214, where memory manager 110 requests allocation of local pool 121 from global pool 119 using allocate local pool from global pool 192. The allocation of local pool 121 may block subsequent allocation requests until sufficient memory is available in global pool 119 for the new local pool. If at step 212 this is not the first request, the method proceeds to strep 216, where memory manager 110 adds the request to the local wait queue for the processor. Steps 206 and 216 are lockless, whereas step 214 requires global pool 119 to be locked. Step 216 blocks until sufficient memory in local pool 121 is available to serve the request.” The activity counter for each CPU incrementing for each memory allocation correlates to a memory request rate. The first allocation request for a process would therefore have an activity counter of zero and any subsequent requests would have an activity counter greater than 0. The memory manager blocking subsequent allocation requests from a process correlates to adjusting memory request rates for VMs). Additionally, remote VMs running at remote servers are a popular network configuration as evidenced by Chigurapati (Fig. 1, “FIG. 1 is a block diagram illustrating a network configuration having network nodes able to enhance network performance using the VIMFS in a VM environment in accordance with one embodiment of the present invention. Diagram 100 includes a cell site 102, a switching network 104, a central office (“CO”) 116, and Internet 150. Internet 150 is further coupled with a user 108, a content provider 110 such as a website, and a wireless computer 126. CO 116 provides various network managements including system virtualization and software updates to various network devices. In one embodiment, CO 116 and/or network devices in network 104 employ a VIMFS such as VIMFS 164-166. VIMFS 164 or 166, which can reside in any devices in network 104, is able to facilitate and provide nearly instantaneous data transfer of IMFS from one VM to another, without substantial performance penalty, data loss, size restrictions, and/or marshaling. It should be noted that the underlying concept of the exemplary embodiment(s) of the present invention would not change if one or more blocks (or devices) were added to or removed from diagram 100.” The network configuration having network devices transferring data across multiple VMs correlates to remote VMs running at remote servers on the network).
With regards to Claim 13, the machine of Claim 4 performs the same steps as the method of Claim 13, and Claim 13 is therefore rejected using the same rationale set forth above in the rejection of Claim 4.
With regards to Claim 5, Miyamuko in view of Jain and Chigurapati teaches the system of Claim 1 above. Miyamuko further teaches:
wherein the at least one processor is further configured, individually or in combination, to use the module to update a data structure in the space for monitoring respective memory usage by different applications (Paragraphs 26-27, “The process management section 401 causes the process statistical information storage section 402 to store the average startup time and average memory usage amount of an application (hereinafter referred to as a process) running on the OS. The process statistical information storage section 402 is managed by the OS 40 to store statistical information including the information about the average startup time and average memory usage amount of each process. Specifically, the process statistical information storage section 402 is implemented by an optical disk, magnetic disk, or other storage device included in the physical server 10.” The process statistical information store section storing the average memory usage amount of each application or process in a storage device correlates to using the module to update a data structure for monitoring respective memory usage by different applications).
Miyamuko does not explicitly teach that the module is a VS kernel module and the space is a kernel space. However, virtual switching techniques utilizing VS kernel modules are a popular method of packet management as evidenced by Chigurapati below (Fig. 1-2, Col. 4, lines 19-24 and 44-50 and Col. 7, lines 29-34).
With regards to Claim 14, the machine of Claim 5 performs the same steps as the method of Claim 14, and Claim 14 is therefore rejected using the same rationale set forth above in the rejection of Claim 5.
With regards to Claim 6, Miyamuko in view of Jain and Chigurapati teaches the system of Claim 1 above. Miyamuko further teaches:
wherein the at least one processor is further configured, individually or in combination, to:
set, using the controller, at least one of memory request rates and memory allocations for VMs accessing the shared memory (Fig. 2 and 2B, paragraphs 17, 28, 33, 44, “The VMM 20 is capable of dividing and managing resources (physical memories, etc.) included in the physical server 10. The VMM 20 is also capable of controlling a virtual machine (VM) 30 that is implemented by virtualizing a resource of the physical server 10… The memory management section 403 is capable of managing a memory that is used in the VM 30… When a process running on the OS 40 executes a memory allocation request, the memory management section 403 accesses the process management section 401 and acquires (inputs) information indicating the process that has executed the memory allocation request (step S11)… If the judgment result obtained in step S22 indicates that allocation is achievable, the physical memory management section 211 allocates a memory block of the size specified by the OS 40 (step S23). More specifically, the physical memory management section 211 updates the information contained in the memory allocation table 212 and stores the correlation between a memory area and a process assigned to the memory area in the memory allocation table 212. If the process is long-lived, the physical memory management section 211 locates a virtual memory area corresponding to a long-lived physical memory in accordance with the address conversion table 213 and assigns the long-lived process to the located virtual memory area. If, on the other hand, the process is short-lived, the physical memory management section 211 locates a virtual memory area corresponding to a short-lived physical memory in accordance with the address conversion table 213 and assigns the short-lived process to the located virtual memory area.” The virtual machines being implemented by virtualizing a resource of the physical server correlates to VMs accessing the shared memory. The physical memory management section allocating a virtual memory area based on the request correlates to setting at least one of memory request rates and memory allocations for VMs accessing the shared memory).
Miyamuko does not explicitly teach that the shared memory is at the least one local memory. However, local memory is a popular configuration of shared memory as evidenced by Jain above (Col. 2, lines 21-37 and Col. 3, lines 10-14).
Chigurapati further teaches:
provide the at least one of memory request rates and memory allocations set by the VS controller to the VS kernel module (Col. 11, lines 42-50, “At block 608, a portion of storage space is allocated in a memory or physical memory disk organized in the IMFS configuration by the hypervisor according to the request. In one example, after execution of memory allocation, a result memory addresses or result codes associated with the allocated storage space is returned to the emulator. After receipt of the result memory addresses, the emulator passes the result memory addresses to the VFS module in the VM kernel.” The result memory address or codes associated with the allocated storage space being returned to the emulator and VFS module correlates to providing the at least one of memory request rates and memory allocations set by the VS controller to the VS kernel module);
and use the VS kernel module to send an indication of at least one of a set memory request rate and a set memory allocation to at least one VM (Col. 11, lines 44-55, “In one example, after execution of memory allocation, a result memory addresses or result codes associated with the allocated storage space is returned to the emulator. After receipt of the result memory addresses, the emulator passes the result memory addresses to the VFS module in the VM kernel. When the result memory addresses are forwarded to the application program, the application memory addressed by the result memory addresses becomes visible to the application program whereby it can store and/or retrieve information to and from the portion of allocated storage space as its local in-memory file storage.” The VFS module forwarding the result memory addresses to the application program correlates to using the VS kernel module to send an indication of at least one of a set memory request rate and a set memory allocation to at least one VM).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Miyamuko with at least one local memory configured to be used at least in part as a shared memory as taught by Jain because infrequent interactions with the global pool can result in significant improvements in performance, particularly when the workload is distributed across many processors (Jain: Col. 2, lines 55-59).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Miyamuko with provide the at least one of memory request rates and memory allocations set by the VS controller to the VS kernel module; and use the VS kernel module to send an indication of at least one of a set memory request rate and a set memory allocation to at least one VM as taught by Chigurapati because system virtualization with in-memory file systems improve overall network performance. Switching networks can use network elements to route information and data packets, which can increase or decrease over time depending on the demand of network services. Hardware resources can additionally be allocated for a network system in a VM environment when receiving a memory allocation request sent from an application program to a VM kernel (Chigurapati: Col. 2, lines 60-64, Col. 4, lines 66-67, Col. 5, lines 1-20 and Col. 11, lines 30-44).
With regards to Claim 15, the machine of Claim 6 performs the same steps as the method of Claim 15, and Claim 15 is therefore rejected using the same rationale set forth above in the rejection of Claim 6.
With regards to Claim 8, Miyamuko in view of Jain and Chigurapati teaches the system of Claim 1 above. Miyamuko further teaches:
wherein the at least one processor is further configured, individually or in combination, to use the module to add at least one of memory usage information (Fig. 2, paragraphs 36-37, “In this instance, the memory management section 403 passes (outputs) hint information for memory allocation, or more specifically, information indicative of a process generation (indicating either a long-lived process or a short-lived process) and information indicative of the predicted remaining memory request amount, to the VMM 20.” The memory management unit passing the information indicating the predicted remaining memory request amount to the VMM to execute processing for the requesting physical memory correlates to adding at least one of memory usage information for different applications to messages sent from the server for use by a controller) and memory request performance information for different applications to messages sent from the server for use by a controller (Paragraphs 20-21, “Next, the memory management unit 403 acquires (inputs) the average startup time of all processes acquired (extracted) by the process management unit 401 from the process statistical information storage unit 402 (step S12).” The memory management unit acquiring the average startup time for all processes from the process management unit correlates to using the module to add memory request performance information for different applications to the controller) in performing at least one of setting memory request rates and allocating memory for applications executed by servers (Fig. 2 and 2B, paragraphs 26-27, 39-40 and 44, “The process management section 401 causes the process statistical information storage section 402 to store the average startup time and average memory usage amount of an application (hereinafter referred to as a process) running on the OS. The process statistical information storage section 402 is managed by the OS 40 to store statistical information including the information about the average startup time and average memory usage amount of each process… In accordance with the information indicative of a process generation, which was passed (input) from the OS 40, the physical memory management section 211 determines the physical memory to be allocated to the process (step S21). More specifically, if the process generation is short-lived, the physical memory management section 211 selects a physical memory for a short-lived process. If, on the other hand, the process generation is long-lived, the physical memory management section 211 selects a physical memory for a long-lived process. Next, the physical memory management section 211 determines (calculates) the total amount of available physical memory at an allocation destination and judges whether there is an allocatable area (step S22) … If the judgment result obtained in step S22 indicates that allocation is achievable, the physical memory management section 211 allocates a memory block of the size specified by the OS 40 (step S23). More specifically, the physical memory management section 211 updates the information contained in the memory allocation table 212 and stores the correlation between a memory area and a process assigned to the memory area in the memory allocation table 212.” The physical memory management unit allocating a virtual memory area based on a request from one of the many processes and information indicative of a process generation correlates to performing at least one of setting memory request rates and allocating memory for applications executed by servers).
Miyamuko does not explicitly teach that the controller is a network controller on the network and the message [is] sent via the network interface. However, network controllers and using network interfaces to send messages for providing memory via a network is a popular method of memory allocation as evidenced by Chigurapati (Fig. 1, Col. 4, lines 19-24 and 44-50).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Miyamuko with a network controller on the network and messages sent from the server via the network interface as taught by Chigurapati because system virtualization with in-memory file systems improve overall network performance. Switching networks can use network elements to route information and data packets, which can increase or decrease over time depending on the demand of network services. Hardware resources can additionally be allocated for a network system in a VM environment when receiving a memory allocation request sent from an application program to a VM kernel (Chigurapati: Col. 2, lines 60-64, Col. 4, lines 66-67, Col. 5, lines 1-20 and Col. 11, lines 30-44).
With regards to Claim 17, the machine of Claim 8 performs the same steps as the method of Claim 17, and Claim 17 is therefore rejected using the same rationale set forth above in the rejection of Claim 8.
With regards to Claim 9, Miyamuko in view of Jain and Chigurapati and teaches the system of Claim 1 above. Jain further teaches:
wherein the at least one processor is further configured, individually or in combination, to:
receive, at least one of memory request rates and memory allocations for one or more applications executed by the at least one processor (Col. 3, line 36-39, Col. 4, lines 8-11, 13-20 and 25-27, Col. 5, lines 18-19, “Processes 102 execute in VMs 140 managed by guest OS 104. Guest OS 104 can also execute a memory manager 110 that manages allocating and freeing memory for processes 102… Activity counters 127 monitor allocation activity on each CPU 160 and can be used by memory manager 110 to release local pools 121 to global pool 119 in case of inactivity... Memory manager 110 includes a routine for allocating memory (“allocate memory 190”), a routine for allocating a local pool from the global pool (“allocate local pool from global pool 192”), a routine to release a local pool to the global pool (“release to global pool 194”), and a routine to free memory from to a local pool (“free memory 196”). A process can call allocate memory 190 to obtain a memory allocation from a local pool… In some embodiments, memory manager 110 includes activity monitor 197 configured to monitor activity counters 127 (if present) … The activity counter is incremented on each allocation and deallocation.” The activity monitor monitoring the activity counter, which increments on each allocation and deallocation, correlates to receiving, at least one of memory request rates for one or more applications executed by the at least one processor. The process calling the allocate memory routine on the memory manager, which additionally increments the activity counter, correlates to receiving, at least one of memory allocations for one or more applications executed by the at least one processor); and
adjust memory usage by the one or more applications based on the at least one of memory request rates and memory allocations (Col. 6, lines 61-67 and Col. 7, lines 1-6, “The method begins at step 602, where memory manager 110 periodically checks activity counter 127 for a processor. Activity counter 127 can exceed a threshold, indicating memory is actively allocated (e.g., activity counter 127 greater than zero). Activity counter 127 can be below a threshold, indicating memory is not actively allocated. At step 604, memory manager 110 determines inactivity based on a threshold. If memory allocation on a processor is active, the method returns to step 602. Otherwise, the methods proceeds to step 606, where memory manager 110 releases local pool 121 for the processor back to global pool 119 (e.g., using release to global pool 194).” The memory manager checking the activity counter for a particular processor, detecting the activity counter is below a threshold, which indicates that memory is not actively allocated, and releasing the local pool for the processor correlates to adjusting memory usage by the one or more applications based on the at least one of memory request rates and memory allocations).
Jain does not explicitly teach that the at least one of memory request rates and memory allocations for one or more applications executed by the at least one processor [is received] from a network controller via the network interface. However, network controllers and using network interfaces to send at least one of memory request rates and memory allocations for one or more applications executed by the at least one processor is a popular method of memory allocation as evidenced by Chigurapati (Fig. 1, Col. 4, lines 19-24 and 44-50).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Miyamuko with a network controller on the network and messages sent from the server via the network interface as taught by Chigurapati because system virtualization with in-memory file systems improve overall network performance. Switching networks can use network elements to route information and data packets, which can increase or decrease over time depending on the demand of network services. Hardware resources can additionally be allocated for a network system in a VM environment when receiving a memory allocation request sent from an application program to a VM kernel (Chigurapati: Col. 2, lines 60-64, Col. 4, lines 66-67, Col. 5, lines 1-20 and Col. 11, lines 30-44).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Miyamuko with wherein the at least one processor is further configured, individually or in combination, to: receive, at least one of memory request rates and memory allocations for one or more applications executed by the at least one processor; and adjust memory usage by the one or more applications based on the at least one of memory request rates and memory allocations as taught by Jain because activity counters can be used to determine whether memory is actively or not actively allocated. If the activity counter is below a threshold, the memory manager can determine inactivity and release a local pool for the certain processor back to the global pool (Jain: Col. 6, lines 61-67 and Col. 7, lines 1-6).
With regards to Claim 18, the machine of Claim 9 performs the same steps as the method of Claim 18, and Claim 18 is therefore rejected using the same rationale set forth above in the rejection of Claim 9.
With regards to Claim 19, Miyamuko teaches:
And means for: retrieving memory usage information, the memory usage information indicating usage of the memory by applications executed by Virtual Machines (VMs) running at the plurality of servers (Fig. 2, paragraphs 33-34 and 36, “When a process running on the OS 40 executes a memory allocation request, the memory management section 403 accesses the process management section 401 and acquires (inputs) information indicating the process that has executed the memory allocation request (step S11). More specifically, the memory management section 403 acquires (inputs) the average startup time, average memory usage amount, and startup count of the process, which the process management section 401 acquired (extracted) from the process statistical information storage section 402. Next, the memory management section 403 acquires (inputs) the average startup time of all processes, which the process management section 401 acquired (extracted) from the process statistical information storage section 402 (step S12) … Next, the memory management section 403 predicts (calculates) a remaining memory request amount from the average memory usage amount and allocated memory usage amount of the process (step S14).” The memory management unit acquiring information indicating the process that has executed the memory allocation request including average startup time, average memory usage of the corresponding process, and number of times the process started and calculating the remaining memory request amount correlates to means for retrieving memory usage information indicating usage of memory by applications executed by VMs running at the plurality of servers);
performing at least one of setting memory request rates and allocating memory for one or more applications executed by the VMs based at least in part on the retrieved memory usage information (Fig. 2 and 2B, paragraphs 39-40 and 44, “In accordance with the information indicative of a process generation, which was passed (input) from the OS 40, the physical memory management section 211 determines the physical memory to be allocated to the process (step S21). More specifically, if the process generation is short-lived, the physical memory management section 211 selects a physical memory for a short-lived process. If, on the other hand, the process generation is long-lived, the physical memory management section 211 selects a physical memory for a long-lived process. Next, the physical memory management section 211 determines (calculates) the total amount of available physical memory at an allocation destination and judges whether there is an allocatable area (step S22) … If the judgment result obtained in step S22 indicates that allocation is achievable, the physical memory management section 211 allocates a memory block of the size specified by the OS 40 (step S23). More specifically, the physical memory management section 211 updates the information contained in the memory allocation table 212 and stores the correlation between a memory area and a process assigned to the memory area in the memory allocation table 212. If the process is long-lived, the physical memory management section 211 locates a virtual memory area corresponding to a long-lived physical memory in accordance with the address conversion table 213 and assigns the long-lived process to the located virtual memory area. If, on the other hand, the process is short-lived, the physical memory management section 211 locates a virtual memory area corresponding to a short-lived physical memory in accordance with the address conversion table 213 and assigns the short-lived process to the located virtual memory area.” The physical memory management unit allocating a virtual memory area based on the request correlates to performing at least one of a memory allocation for one or more applications based at least in part on the retrieved memory usage information);
Miyamuko does not explicitly teach that the memory usage information [is] added to packets sent by the plurality of servers via the network to network devices of the plurality of network devices and that the memory usage information indicates usage of shared memory by applications. However, transmitting information via packets in a server between network devices is a popular method of communication as evidenced by Chigurapati above (Fig. 6, Col. 3, lines 59-64, Col. 4, lines 66-67, Col. 5, lines 1-4, and Col. 11, lines 30-39). Additionally, applications executed by VMs sharing memory is a popular method of memory management as evidenced by Jain above (Col. 2, lines 21-37 and lines 65-67 and Col. 3, lines 1-3, 10-14, 24-28, and 34-37) and a plurality of network devices communicating with a plurality of servers is a popular configuration of servers as evidenced by Jain below (Col. 2, lines 21-37 and lines 65-67 and Col. 3, lines 1-3 and 6-14).
Miyamuko does not explicitly teach:
A network controller, comprising:
a network interface configured to communicate with a plurality of servers on a network, wherein a plurality of network devices on the network provides a shared memory;
and sending the at least one of set memory request rates and memory allocations to at least one server of the plurality of servers to adjust usage of the shared memory by different applications executed by VMs running on the at least one server.
However, Jain teaches:
A network controller, comprising:
a network interface configured to communicate with a plurality of servers on a network, wherein a plurality of network devices on the network provides a shared memory (Col. 2, lines 21-37 and lines 65-67 and Col. 3, lines 1-3 and 6-14, “In embodiments, a memory manager manages two kinds of memory pools: a global pool shared by all processors and a local pool for each processor. At system start, all available memory is claimed by the global pool. If the local pool has sufficient memory to serve the request, the memory manager fulfills the request from the local pool. This path is lockless. If the local pool does not have sufficient memory, the memory manager requests a chunk of memory from the global pool for use in the local pool. This allocation of memory from the global pool to the local pool is performed under locking. Processes release memory back to the local pool. This is also a lockless operation. When total free memory in the local pool exceeds a threshold, the memory can be returned back to the global pool… As shown, a hardware platform 122 of host 120 includes conventional components of a computing device, such as central processing units (CPUs) 160, system memory (e.g., random access memory (RAM) 162), one or more network interface controllers (NICs) 164, and optionally local storage 163… NICs 164 enable host 120 to communicate with other devices through a physical network 180. Physical network 180 enables communication between hosts 120 and between other components and hosts 120 (other components discussed further herein). Local storage 163 may comprise magnetic disks, solid-state disks, flash memory, and the like as well as combinations thereof. In some embodiments, local storage 163 in each host 120 can be aggregated and provisioned as part of a virtual storage area network (SAN).” The network interface controllers in each of the hosts enabling hosts to communicate with other hosts through the physical network correlates to a network interface configured to communicate with a plurality of servers on the network. All the available memory being initially claimed by a global pool and allocated to local pools for processors to use based on requests before being returned back to the global pool correlates to a plurality of network devices providing a shared memory);
and sending the at least one of set memory request rates and memory allocations to at least one server of the plurality of servers to adjust usage of the shared memory by different applications executed by VMs running on the at least one server (Col. 2, lines 21-37 and lines 65-67 and Col. 3, lines 1-3, 10-14, 24-28, and 34-37 “In embodiments, a memory manager manages two kinds of memory pools: a global pool shared by all processors and a local pool for each processor. At system start, all available memory is claimed by the global pool. If the local pool has sufficient memory to serve the request, the memory manager fulfills the request from the local pool. This path is lockless. If the local pool does not have sufficient memory, the memory manager requests a chunk of memory from the global pool for use in the local pool. This allocation of memory from the global pool to the local pool is performed under locking. Processes release memory back to the local pool. This is also a lockless operation. When total free memory in the local pool exceeds a threshold, the memory can be returned back to the global pool… As shown, a hardware platform 122 of host 120 includes conventional components of a computing device, such as central processing units (CPUs) 160, system memory (e.g., random access memory (RAM) 162), one or more network interface controllers (NICs) 164, and optionally local storage 163… Local storage 163 may comprise magnetic disks, solid-state disks, flash memory, and the like as well as combinations thereof. In some embodiments, local storage 163 in each host 120 can be aggregated and provisioned as part of a virtual storage area network (SAN)… Hypervisor 150 abstracts processor, memory, storage, and network resources of hardware platform 122 to provide a virtual machine execution space within which multiple virtual machines (VM) may be concurrently instantiated and executed… Each of VMs 140 includes a guest operating system (OS) 104, which can be any known operating system (e.g., Linux®, Windows®, etc.). Processes 102 execute in VMs 140 managed by guest OS 104.” All the available memory being initially claimed by a global pool and allocated to local pools for processors to use based on requests before being returned back to the global pool correlates to sending the at least one of a memory allocation to at least one server to adjust usage of a shared memory. Each host including multiple VMs concurrently instantiated and executed which each execute processes correlates to different applications executed by VMs running on the at least one server).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Miyamuko with a server, comprising: at least one local memory configured to be used at least in part as a shared memory; a network interface configured to communicate with one or more network devices via a network, the one or more network devices each configured to provide a respective shared memory and sending the at least one of set memory request rates and memory allocations to at least one server of the plurality of servers to adjust usage of the shared memory by different applications executed by VMs running on the at least one server as taught by Jain because infrequent interactions with the global pool can result in significant improvements in performance, particularly when the workload is distributed across many processors (Jain: Col. 2, lines 55-59).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Miyamuko with packets sent by the server via the network to network device as taught by Chigurapati because system virtualization with in-memory file systems improve overall network performance. Switching networks can use network elements to route information and data packets, which can increase or decrease over time depending on the demand of network services. Hardware resources can additionally be allocated for a network system in a VM environment when receiving a memory allocation request sent from an application program to a VM kernel (Chigurapati: Col. 2, lines 60-64, Col. 4, lines 66-67, Col. 5, lines 1-20 and Col. 11, lines 30-44).
With regards to Claim 20, Miyamuko in view of Chigurapati and Jain teaches the system of claim 19 above. Miyamuko further teaches:
retrieving memory request performance information for different applications (Paragraphs 20-21 and 26-27, “Next, the memory management unit 403 acquires (inputs) the average startup time of all processes acquired (extracted) by the process management unit 401 from the process statistical information storage unit 402 (step S12) … The process management section 401 causes the process statistical information storage section 402 to store the average startup time and average memory usage amount of an application (hereinafter referred to as a process) running on the OS. The process statistical information storage section 402 is managed by the OS 40 to store statistical information including the information about the average startup time and average memory usage amount of each process” The process statistical information storage section storing statistical information on each application or process of the OS correlates to memory request performance information for different applications. The memory management unit acquiring the average startup time for all processes from the process management unit correlates to retrieving memory request performance information for different applications); and
using the retrieved memory request performance information to perform at least one of setting memory request rates and allocating memory for the one or more applications (Fig. 2 and 2B, paragraphs 26-27, 39-40 and 44, “The process management section 401 causes the process statistical information storage section 402 to store the average startup time and average memory usage amount of an application (hereinafter referred to as a process) running on the OS. The process statistical information storage section 402 is managed by the OS 40 to store statistical information including the information about the average startup time and average memory usage amount of each process… In accordance with the information indicative of a process generation, which was passed (input) from the OS 40, the physical memory management section 211 determines the physical memory to be allocated to the process (step S21). More specifically, if the process generation is short-lived, the physical memory management section 211 selects a physical memory for a short-lived process. If, on the other hand, the process generation is long-lived, the physical memory management section 211 selects a physical memory for a long-lived process. Next, the physical memory management section 211 determines (calculates) the total amount of available physical memory at an allocation destination and judges whether there is an allocatable area (step S22) … If the judgment result obtained in step S22 indicates that allocation is achievable, the physical memory management section 211 allocates a memory block of the size specified by the OS 40 (step S23). More specifically, the physical memory management section 211 updates the information contained in the memory allocation table 212 and stores the correlation between a memory area and a process assigned to the memory area in the memory allocation table 212. If the process is long-lived, the physical memory management section 211 locates a virtual memory area corresponding to a long-lived physical memory in accordance with the address conversion table 213 and assigns the long-lived process to the located virtual memory area. If, on the other hand, the process is short-lived, the physical memory management section 211 locates a virtual memory area corresponding to a short-lived physical memory in accordance with the address conversion table 213 and assigns the short-lived process to the located virtual memory area.” The process statistical information storage section storing information on each application or process of the OS correlates to different applications executed by one or more VMs. The physical memory management unit allocating a virtual memory area based on a request from one of the many processes correlates to setting at least one of a memory allocation for the different applications using the memory request performance information).
Claim(s) 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Miyamuko in view of Jain, Chigurapati and Knauft et al. (U.S. Patent No. US 20190303308 A1), hereinafter “Knauft.”
With regards to Claim 7, Miyamuko in view of Jain and Chigurapati teaches the system of Claim 1 above. Miyamuko in view of Jain and Chigurapati does not explicitly teach:
wherein the at least one processor is further configured, individually or in combination,to:
determine, using the VS kernel module, that a level of pending requests in at least one submission queue for the shared memory is greater than or equal to a threshold level of pending requests; and
in response to determining that the level of pending requests in the at least one submission queue is greater than or equal to the threshold level, set a congestion notification in a message sent to a remote VM.
However, Knauft teaches:
wherein the at least one processor is further configured, individually or in combination, to:
determine, using the module, that a level of pending requests in at least one submission queue for the shared memory is greater than or equal to a threshold level of pending requests (Paragraphs 16 and 30, “The VSAN module 114 of each host computer 104 provides access to the local storage resources of that host computer (e.g., handle storage input/output (I/O) operations to data objects stored in the local storage resources as part of the VSAN 102) by other host computers 104 in the cluster 106 or any software entities, such as VMs 124, running on the host computers in the cluster… The backpressure congestion controller 426 operates to generate an independent backpressure signal for each of the queues 424A, 424B, 424C and 424D being maintained by the dispatch scheduler 422 as needed. Depending on the amount of different storage I/O requests coming to the VSAN module 114 to be processed, the queues may fill up at different rates. For each queue, the backpressure congestion controller generates a backpressure signal when the storage I/O requests in that queue reaches a certain threshold. Thus, each backpressure signal for a particular queue is independent of backpressure signals for the other queues.” The backpressure congestion controller generating a backpressure signal when the local storage I/O requests in the queue reach a certain threshold correlates to determining, using the module, that a level of pending requests in at least one submission queue for the shared memory is greater than or equal to a threshold level of pending requests) and
in response to determining that the level of pending requests in the at least one submission queue is greater than or equal to the threshold level, set a congestion notification in a message sent to a remote VM (Paragraph 31, “The backpressure congestion controller 426 transmits the backpressure signals to the respective clients or sources, e.g., sources 428A and 428B, that had issued the corresponding storage I/O requests, which were placed in the different queues 424A, 424B, 424C and 424D. The sources of storage I/O requests include the host computers 104 of the cluster 106, the VMs 124 running on the host computers 104 and software processes or routines (not shown) operating in the host computers 104. Thus, for the queue 424A holding VM I/O requests, the backpressure signal will be sent to the VMs that are issuing the VM I/O requests.” The backpressure congestion controller transmitting the backpressure signal to the respective source that issued the corresponding storage I/O requests which includes a VM correlates to setting a congestion notification in a message sent to a remote VM in response to determining that the level of pending requests in the at least one submission queue is greater than or equal to the threshold level).
Knauft does not explicitly teach that the module is a VS kernel module. However, virtual switching techniques utilizing VS kernel modules are a popular method of packet management as evidenced by Chigurapati above (Fig. 1-2, Col. 4, lines 19-24 and 44-50 and Col. 7, lines 29-34).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Miyamuko with wherein the at least one processor is further configured, individually or in combination, to: determine, using the VS kernel module, that a level of pending requests in at least one submission queue for the shared memory is greater than or equal to a threshold level of pending requests; and in response to determining that the level of pending requests in the at least one submission queue is greater than or equal to the threshold level, set a congestion notification in a message sent to a remote VM as taught by Knauft because backpressure congestion controllers can generate independent backpressure signals for each queue. Each queue can have a predefined minimum and maximum threshold number of elements, and upon generating a backpressure signal, it can be transmitted to the respective client or source. The client or source can implement a delay based on the received congestion signal that can be time-averaged and latency-based in response to receiving the backpressure signal. Therefore, less backlogged classes of storage I/O requests can still fill their corresponding queues without being bottlenecked by a particular class with backpressure (Knauft: paragraphs 30-31).
With regards to Claim 16, the machine of Claim 7 performs the same steps as the method of Claim 16, and Claim 16 is therefore rejected using the same rationale set forth above in the rejection of Claim 7.
Prior Art Made of Record
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Cao et al. (U.S. Patent No. US 9635134 B2); teaching a method of managing resources in a cloud computing environment including determining a consumption rate of cloud resources by one or more virtual machines and prioritizing one or more virtual machines based on the determined consumption rate. If a change in the consumption rate exceeds a threshold, a second resource management scheme may be used to migrate the consumption of cloud resources to alternate cloud resources.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SELINA HU whose telephone number is (571)272-5428. The examiner can normally be reached Monday-Friday 8:30-5:30.
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, Chat Do can be reached at (571) 272-3721. 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.
/SELINA ELISA HU/Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193
Prosecution Insights