DETAILED ACTION
Claims 1-20 are pending.
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 .
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d).
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 120 is acknowledged.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 04/15/25 has been acknowledged and considered by the examiner.
Examiner Comment
The examiner recommends filing a written authorization for Internet communication in response to the present action. Doing so permits the USPTO to communicate with Applicant using Internet email to schedule interviews or discuss other aspects of the application. Without a written authorization in place, the USPTO will not respond via Internet email to any Internet correspondence which contains information subject to the confidentiality requirement as set forth in 35 U.S.C. 122. The preferred method of providing authorization is by filing form PTO/SB/439, available at: https://www.uspto.gov/patent/forms/forms. See MPEP § 502.03 for other methods of providing written authorization.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-5, 8-12 and 15-19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Eshwarappa et al. (U.S. 2017/0168715 A1).
Regarding claims 1, 8 and 15, Eshwarappa discloses a method and device for dynamically processing data message flows using different non- uniform memory access (NUMA) nodes of a processing system (see Eshwarappa; paragraph 0019; Eshwarappa disclose individual, i.e. “different”, NUMA nodes connected so that data may be transferred, i.e. “processing data message flows”), each NUMA node comprising a local memory and a set of processors that can access data from local memories of other NUMA nodes (see Eshwarappa; paragraph 0018; Eshwarappa discloses CPUs, i.e. “set of processors”, and local memories for NUMA nodes), the method comprising:
receiving, at a load balancing application associated with a first NUMA node, data message flows destined for an endpoint application, wherein the data message flows are assigned to the first NUMA node to be forwarded to the endpoint application (see Eshwarappa; Abstract, and paragraphs 0019, 0024 and 0047; Eshwarappa discloses data, i.e. “data message”, being transferred between NUMA nodes and NUMA optimization techniques are performed whereby execution contexts and/or data for such contexts are migrated between NUMA nodes. Migration may occur for various reasons, including for load balancing, i.e. “at a load balancing application”, to achieve fairness. In particular, a first VM is scheduled for execution on a first NUMA node. The contexts are isolated from each other, each having at least a user application, i.e. “endpoint application”, running therein and each virtual machine includes a guest operating system in which at least one application runs. In other words, the data for a context, i.e. “data message flows”, are destined for one of the at least user application running on said context, i.e. “…to be forwarded to the endpoint application”);
monitoring a central processing unit (CPU) usage of the first NUMA node to determine whether the CPU usage of the first NUMA node exceeds a particular threshold (see Eshwarappa; paragraphs 0024 and 0033; Eshwarappa discloses NUMA optimizer performs NUMA migrations to maintain long term CPU utilization fairness. A first VM is scheduled for execution on a first NUMA node and second and third VMs are scheduled for execution on a second NUMA node. Over the long run, the first VM receives more CPU time than the second and third VMs, i.e. “monitoring a CPU usage of the first NUMA node…”. NUMA optimizer may migrate the VMs between the first and second NUMA nodes to ensure a "fair" allocation of CPU time, i.e. “determine whether the CPU usage of the first NUMA node exceeds a particular threshold”. For example, rather than the first VM receiving 100% of a CPU's time and the other two receiving 50%, of a CPU's time each, each VM would receive 66% of a CPU, i.e. “…a particular threshold”. The CPU load balancing calculation is a calculation whereby NUMA optimizer determines the CPU load for the VM at its current NUMA node and compares that CPU load to the CPU load for other NUMA nodes. The fairness calculation is the determination for the maintenance of long term fairness. Specifically, these calculations determine, over a relatively long period of time, how much CPU time each VM is being allocated. As described above, the purpose of this calculation is to determine whether VMs should be migrated to maintain a "fair" allocation of CPU time. In other words, a threshold for determining the “fair” allocation of CPU time is the threshold, such as 66%); and
when the CPU usage of the first NUMA node exceeds the particular threshold, reassigning at least a subset of the data message flows to a second NUMA node for processing (see Eshwarappa; paragraphs 0019, 0024 and 0033; Eshwarappa discloses transferring VM data, i.e. “data message flow”, between NUMA nodes and determining a first VM on the first NUMA node receives more CPU time, i.e. “when the CPU usage of the first NUMA node exceeds a particular threshold”, such as receiving 100%, by comparing the CPU load to other NUMA nodes and migrating the VM, including the data, to a second NUMA node, i.e. “reassigning at least a subset of the data message flows to a second NUMA node”).
Further, Eshwarappa discloses the additional limitations of claim 15, a non-transitory machine readable medium storing a program for execution by at least one processing unit (see Eshwarappa; paragraphs 0005 and 0050; Eshwarappa discloses a non-transitory computer-readable storage medium storing instructions).
Regarding claims 2, 9 and 16, Eshwarappa discloses all the limitations of claims 1, 8 and 15, as discussed above, and further Eshwarappa clearly discloses after reassigning the at least subset of data message flows to the second NUMA node: forwarding the at least subset of data message flows to the second NUMA node to be processed (see Eshwarappa; paragraphs 0019, 0024 and 0033; Eshwarappa discloses transferring VM data, i.e. “data message flow”, between NUMA nodes and determining a first VM on the first NUMA node receives more CPU time then migrating the VM, including the data, to a second NUMA node, i.e. “forwarding the at least subset of data message flows to the second NUMA node to be processed”);
receiving processed data message flows from the second NUMA node (see Eshwarappa; paragraphs 0021, 0024, 0028 and 0038; Eshwarappa discloses in migrating the data from the NUMAs goes through the optimizer, i.e. “receiving processed data message flows”, to reach VM or container that hosts applications ); and
forwarding the processed data message flows to the endpoint application (see Eshwarappa; paragraphs 0024, 0028, 0038 and 0047; Eshwarappa discloses migrating the data from the VMs, such that, the data for a context, i.e. “data message flows”, are destined for one of the at least user application running on said context, i.e. “…to be forwarded to the endpoint application”).
Regarding claims 3, 10 and 17, Eshwarappa discloses all the limitations of claims 1, 8 and 15, as discussed above, and further Eshwarappa clearly discloses wherein the at least subset of data message flows comprises large data messages such that data message flows comprising small data messages maintain assignment to the first NUMA node (see Eshwarappa; paragraph 0022; Eshwarappa discloses if a particular VM utilizes large amounts of data stored in non-local memory within a particular NUMA node that is not the home node for that VM, NUMA optimizer may trigger a NUMA migration to migrate the VM to the NUMA node for which the large amounts of data are accessed by that VM, i.e. “data message flows comprising small data messages maintain assignment to the first NUMA node”).
Regarding claims 4, 11 and 18, Eshwarappa discloses all the limitations of claims 1, 8 and 15, as discussed above, and further Eshwarappa clearly discloses wherein the data message flows are initially assigned to the first NUMA node based on quality of service (QoS) parameters of the endpoint application (see Eshwarappa; paragraph 0042; Eshwarappa discloses a mission critical, i.e. “quality of service (QoS)”, workload, where "mission critical" means that fast execution time and/or real-time execution is important. In other words, the mission critical is a type of quality of service).
Regarding claims 5, 12 and 19, Eshwarappa discloses all the limitations of claims 4, 11 and 18, as discussed above, and further Eshwarappa clearly discloses wherein the data message flows are initially assigned to the first NUMA node because the data message flows are critical data message flows requiring a low latency (see Eshwarappa; paragraph 0042; Eshwarappa discloses the NUMA optimizer selects one or more optimizations to skip. The selections may be based on various factors including characteristics of the workload. For example, a “mission critical workload” may use a no memory migration technique, where “mission critical” means that fast execution time and/or real-time execution is important, i.e. “data message flows are critical data message flows requiring a low latency”).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 6 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Eshwarappa et al. (U.S. 2017/0168715 A1) in view of Sorenson, III et al. (U.S. 2014/0310390 A1).
Regarding claims 6 and 13, Eshwarappa discloses all the limitations of claims 1 and 8, as discussed above. While Eshwarappa discloses the “load balancing application”, as discussed above, Eshwarappa does not explicitly disclose wherein the load balancing application is a first instance of a distributed load balancing application implemented by a plurality of instances operating on the different NUMA nodes.
In analogous art, Sorenson discloses wherein the load balancing application is a first instance of a distributed load balancing application implemented by a plurality of instances operating on the different NUMA nodes (see Sorenson; Abstract, paragraphs 0052, 0055 and 0254 and Figure 33B; Sorenson discloses a distributed load balancer as a first instance of a distributed load balancing node, i.e. “…a first instance of distributed load balancing application”, that supports NUMA optimized allocation).
One of ordinary skill in the art would have been motivated to combine Eshwarappa and Sorenson because they both disclose features of load balancing between nodes, and as such, are within the same environment.
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the feature of load balancing as taught by Sorenson into the system of Eshwarappa in order to provide the benefit of efficiency by enabling load balancing in a distributed manner (see Sorenson; Abstract).
Claims 7, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Eshwarappa et al. (U.S. 2017/0168715 A1) in view of Sorenson, III et al. (U.S. 2014/0310390 A1), as applied to claims 6, 13 and 19 above, and further in view of Hughes et al. (U.S. 7430755).
Regarding claims 7, 14 and 20, Eshwarappa and Sorenson discloses all the limitations of claims 6, 13 and 19, as discussed above. The combination of Eshwarappa and Sorenson does not explicitly disclose after the reassigning, storing a record associating the at least subset of data message flows with the second NUMA node in the local memory of the first NUMA node, wherein the record specifies, for each data message flow in the at least subset of data message flows, a flow identifier (ID) identifying the data message flow and a NUMA node ID identifying the second NUMA node.
In analogous art, Hughes discloses after the reassigning, storing a record associating the at least subset of data message flows with the second NUMA node in the local memory of the first NUMA node (see Hughes; column 4 lines 30-60 and column 13 lines 35-50; Hughes discloses wherein the server array controller can be a proxy server itself and storing mapping of data flow identifier and target server, i.e. “storing a record associating the at least subset of data message flows…”), wherein the record specifies, for each data message flow in the at least subset of data message flows, a flow identifier (ID) identifying the data message flow and a NUMA node ID identifying the second NUMA node (see Hughes; column 4 lines 30-60 and column 13 lines 35-50; Hughes discloses a session ID, i.e. “flow identifier (ID)” ).
One of ordinary skill in the art would have been motivated to combine Eshwarappa, Sorenson and Hughes because they all disclose features communication between nodes/entities, and as such, are within the same environment.
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the feature of secure communication as taught by Hughes into the combined system of Eshwarappa and Sorenson in order to provide the benefit of efficiency by looking up destination/target server based on session ID (see Hughes; column 13 lines 35-50).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Krasilnikov et al. (U.S. 11,625,175 B1) discloses a device for migrating virtual resources between NUMA nodes to reduce resource contention.
McGrath et al. (U.S. 2014/0068611 A1) discloses a distributed load balancing application among nodes.
Masputra et al. (U.S. 2022/0094763 A1) discloses receiving policies among endpoint applications.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ADAM A COONEY whose telephone number is (571)270-5653. The examiner can normally be reached M-F 7:30am-5:00pm (every other Fri off).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Umar Cheema can be reached at 571-270-3037. 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.
/A.A.C/Examiner, Art Unit 2458 07/21/26
/UMAR CHEEMA/Supervisory Patent Examiner, Art Unit 2458
Prosecution Insights