DETAILED ACTION
Reopening After Board Decision
Due to the newly discovered references of Min, US 2016/0191412, and Bhandaru, US 8984313 B2, this application is being reopened for prosecution based on the rejections set forth below. This action has been approved by the Technology Center Director.
/AMY COHEN JOHNSON/TC2400 Group Director, Art Unit 2400
Claim Objections
Claims 11-18 are objected to because of the following informalities:
Claims 11-17 each recite the limitation "The computer-readable medium of …" in line 1. The Examiner recommends to rewrite the statement "The computer-readable medium of …" as "The at least one non-transitory computer-readable medium of …".
Claim 18 recites the limitation "the system agent" in line 6. The Examiner recommends to rewrite the statement "the system agent" as "the system agent circuitry", or claim the limitation “a system agent” prior to line 6 of claim 18.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-10 and 13-21 are rejected under 35 U.S.C. 103 as being unpatentable over US PG-PUB No. 2016/0191412 A1 to Min et al. (hereinafter “Min”) in view of USPAT No. 8984313 B2 to Bhandaru et al. (hereinafter “Bhandaru”)
Regarding claim 1:
Min discloses:
A method (see the method of Fig. 6) comprising:
altering a frequency of operation … based on detection of a traffic violation (¶62-63: “modify a hardware operating parameter of the computing device. … wherein the hardware operating parameter comprises … (ii) processor core frequency,”; ¶42: “… an incoming flow may require deep packet inspection … As such, the decision engine module 416 can calculate …. (c) appropriate CPU core frequencies … For example, if a controller node 114 detects … an increase in traffic volume, it may inform one or more destination platforms to prepare for the increase in advance to maximize performance”; i.e., alter the frequency of operation of CPU core frequencies based on detection of an increase of network traffic volume, where an increase of network traffic volume constitutes “a traffic violation”), wherein [a] peripheral device interface communicatively couples a network interface controller and a processor (¶21: “… the NIC 132 is embodied as a Peripheral Component Interconnect Express (PCIe) device communicatively coupled to the processor 118 via a PCIe I/O bus of the computer node 104.”, see Fig. 1), and
wherein the traffic violation comprises packet flooding (¶42: “if there are multiple incoming flows … a controller node 114 detects … an increase in traffic volume”; i.e., the examiner notes that “packet flooding” is defined by Applicant’s Specification at paragraph 15 as being “… a flood of received packets”. Paragraph 40 of Applicant’s Specification further states that said flooding may be considered “malicious or non-malicious”. Therefore, under Broadest Reasonable Interpretation, the examiner interprets the claimed “packet flooding” as being an increase in volume of malicious or non-malicious packet traffic which may result in increased network congestion).
However, Min does not explicitly disclose the following limitation taught by Bhandaru:
altering a frequency of operation of a peripheral device interface (Bhandaru, Fig. 5, element 450; col 19, lines 56-57, “… the uncore may include … various interfaces 450…”; col. 20, lines 9-10, “In additional, by interfaces 450, connection can be made to various off-chip components such as peripheral devices…”; i.e., the uncore comprises at least a peripheral device interface) based on detection of a traffic violation (Bhandaru, col 4, lines 56-59: “For a compute centric workload the uncore can be run at a lower … frequency, resulting in applying power savings toward higher core frequencies at a socket level.”; col 11, lines 8-12, “Embodiments may monitor various information, including … interconnect traffic … to determine usage of uncore circuitry of a processor, to detect congestion and under-utilization”; i.e., the examiner notes that “compute centric workload” here corresponds to Min’s increasing of processor core frequency responsive to determining an increase in network traffic flows. Thus, Bhandaru discloses lowering the frequency of an uncore logic (i.e., a peripheral device interface) in order to increase the frequency of processor cores (i.e., Min’s processor core)) …
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Min’s method of increasing frequency of processor core logic for compute centric workloads to overcome performance bottlenecks by incorporating Bhandaru’s method of reducing an uncore (i.e., peripheral device interface) frequency for compute centric workloads by monitoring traffic to detect congestion and under-utilization (see Fig. 5 of Bhandaru for processor core logic and uncore logic comprising a peripheral device interface). Such modification would enable the system of Min to overcome higher core frequency thermal constraints by running uncore logic (i.e., Min’s NIC element 132) at lower frequency, and provide better control over power consumption and performance by applying power savings toward higher core frequencies, and thus increase performance by way of allocating the excess power budget to only cores that seek it, allowing them to run faster and increase system performance (Bhandaru, col 4, lines 29-42 & 46-62).
Regarding claim 2:
The combination of Min and Bhandaru discloses:
The method of claim 1, comprising detecting a traffic violation based on detection of Internet Protocol (IP) packet fragments (Min, ¶41-42: “the monitoring engine module may receive monitored traffic flows and traffic characteristics (e.g., traffic volume, packet size, protocol, etc.) produced internally and/or received from the remote entity 116. … if there are multiple incoming flows with different characteristics, the decision engine module 416 can adjust system configurations and/or parameters to separate incoming flows and send them from a NIC (e.g., the NIC 132) to different power control unit (PCU) cores running at different frequencies.”),
Min does not explicitly disclose the following limitation taught by Bhandaru:
Wherein:
altering the frequency of operation of the peripheral device interface based on detection of the traffic violation comprises reducing a frequency of operation of the peripheral device interface based on detection of the traffic violation (Bhandaru, col 4, lines 56-59: “For a compute centric workload, the uncore can be run at a lower … frequency, resulting in applying power savings toward higher core frequencies at a socket level.”).
The same motivation which is applied to claim 1 with respect to Bhandaru applies to claim 2.
Regarding claim 3:
The combination of Min and Bhandaru discloses:
The method of claim 2, wherein IP packet fragments comprise one or more of:
IP packet fragments that are incomplete packets, IP packet fragment that are too small, IP packet fragments that result in excessive packets (Min, ¶42: “if there are multiple incoming flows … a controller node 114 detects … an increase in traffic volume,”, Note: “multiple incoming flows” teaches “excessive packets”), or IP packet fragmentation buffer being full.
Regarding claim 4:
The combination of combination of Min and Bhandaru discloses:
The method of claim 2, wherein the detecting a traffic violation based on detection of IP packet fragments comprises detecting a traffic violation based on detection of IP packet fragments at one or more of:
a network appliance, the network interface controller, uncore, system agent, operating system, application, or a computing platform (Min, ¶42: “… the decision engine module 416 can calculate, among other things, (a) an optimal packet batch size for one or more NICs, … if there are multiple incoming flows with different characteristics, the decision engine module 416 can adjust system configurations and/or parameters to separate incoming flows”).
Regarding claim 5:
The combination of Min and Bhandaru discloses:
The method of claim 1, wherein the peripheral device interface comprises one or more of:
a system agent, an uncore interface (Bhandaru, col 19, lines 53-54: “… an uncore or system agent logic 420”, see also Fig. 5 depicting a peripheral device interface within uncore space), a bus, (Min, ¶21: “… a PCIe I/O bus …”) peripheral component interconnect express (PCIe) interface (Min, ¶21: “… Peripheral Component Interconnect Express (PCIe)”), and a cache (Min, ¶37: “GPU’s 306 cache”).
The same motivation which is applied to claim 1 with respect to Bhandaru applies to claim 5.
Regarding claim 6:
The combination of Min and Bhandaru discloses:
The method of claim 1, wherein the peripheral device interface is part of a system on a chip (SoC) (Min, ¶19: “… the I/O subsystem 120 may be embodied as, … communication links (i.e., … bus links, …) … the I/O subsystem 120 may form a portion of a system-on-a-chip (SoC) and be incorporated, along with processor 118, …”, see also ¶21: “a PCIe I/O bus”) and the SoC includes one or more of:
a core (Min, ¶16: “one or more cores of the processor 118.”), system agent, or uncore.
Regarding claim 7:
The combination of Min and Bhandaru discloses:
The method of claim 1, wherein the processor comprises one or more of:
a core, accelerator(Min, ¶35: “accelerator 308”, see Fig. 3, Accelerator 308), or graphics processing unit (GPU) (Min, ¶35: “a graphics processing unit (GPU) 306”, see Fig. 3, GPU 306).
Regarding claim 8:
The combination of Min and Bhandaru discloses:
The method of claim 1, wherein altering the frequency of operation of the peripheral device interface based on detection of the traffic violation comprises increasing a frequency of operation of the peripheral device interface (Bhandaru, col 4, lines 59-61: “… the uncore can be run at a higher voltage and frequency, …”, see also col 11, lines 9-13: “… monitor … interconnect traffic, core activity levels, … to detect congestion and under-utilization.”) based on one or more of:
management of the traffic violation at the processor or not detecting a traffic violation interface (Bhandaru, col 11, lines 9-13: “… monitor … interconnect traffic, core activity levels, … to detect congestion ...”) and comprising:
increasing a frequency of operation of the processor based on a power budget, allocated for the processor and the peripheral device interface, permits the increasing the frequency of operation of the processor (Bhandaru, col 2, lines 55-58: “… when power and thermal budget is available, processor hardware can configure the processor … to operate at a higher than guaranteed frequency.”).
The same motivation which is applied to claim 1 with respect to Bhandaru applies to claim 8.
Regarding claim 9:
The combination of Min and Bhandaru discloses:
The method of claim 1, wherein altering the frequency of operation of the peripheral device interface based on detection of the traffic violation comprises:
based on a rate of packets received at the network interface controller (Min, ¶42: “… an incoming flow may require deep packet inspection at a line rate processing (e.g., 10 Gbps) with a specified latency requirement.”), altering a frequency of a clock … (Min, ¶82: “modify a hardware operating parameter comprises generating data to modify … (ii) processor core frequency ”, see also ¶01: “… to determine device parameters (e.g., processor clock speed, memory usage, etc.) and to adjust appropriate parameters …”, ¶42: “… if there are multiple incoming flows with different characteristics, the decision engine module 416 can adjust system … parameters to separate incoming flows and send them from a NIC (e.g., the NIC 132) to different power control unit (PCU) cores running at different frequencies.”),
Min does not explicitly disclose the following limitation taught by Bhandaru:
altering a frequency of a clock (Bhandura, col. 3, lines 56-60, “The UFS feature uses sensor values to dynamically adjust uncore interconnect frequency to better allocate power between cores and uncore interconnect to increase performance, and under idle scenarios to conserve power”; col. 11, lines 29-31 further disclose the frequency to be altered as a clock frequency) provided to system agent circuitry (Bhandura, col. 2, line 31, “referred to herein as an uncore or a system agent”), wherein the system agent comprises a bus interface (Bhandaru, see Fig. 5, element 420 comprising elements 450) a cache (Bhandaru, see Fig. 5, element 420 comprising shared cache 430), and a caching and home agent (Bhandaru, see Fig. 4, element 420 comprising memory agent 440).
The same motivation which is applied to claim 1 with respect to Bhandaru applies to claim 9.
Regarding claim 10:
Min discloses:
at least one non-transitory computer-readable medium comprising instructions stored thereon (¶11: “… instructions carried by or stored on one or more non-transitory machine-readable (e.g., computer-readable) storage medium, …”), that if executed by one or more processors (¶11: “… which may be read and executed by one or more processors.”), cause the one or more processors to:
detect for traffic violations based on detection of Internet Protocol (IP) packet fragments (¶41-42: “the monitoring engine module may receive monitored traffic flows and traffic characteristics (e.g., traffic volume, packet size, protocol, etc.) produced internally and/or received from the remote entity 116. … if there are multiple incoming flows with different characteristics, the decision engine module 416 can adjust system configurations and/or parameters to separate incoming flows and send them from a NIC (e.g., the NIC 132) to different power control unit (PCU) cores running at different frequencies.”; i.e., Min monitors multiple traffic flows and characteristics (including packet sizes) in order to detect if any increase in network traffic volume exist across the multiple flows, where the increase in the network traffic volume across multiple network flows constitutes “traffic violations”) and
[alter] a frequency of operation …, (¶62-63: “modify a hardware operating parameter of the computing device. … wherein the hardware operating parameter comprises … (ii) processor core frequency,”) that provides a communicative coupling between a network interface controller and a processor (¶21: “… the NIC 132 is embodied as a Peripheral Component Interconnect Express (PCIe) device communicatively coupled to the processor 118 via a PCIe I/O bus of the computer node 104.”, see Fig. 1), based on detection of a traffic violation (¶42: “… an incoming flow may require deep packet inspection … As such, the decision engine module 416 can calculate …. (c) appropriate CPU core frequencies … For example, if a controller nod 114 detects … an increase in traffic volume, it may inform one or more destination platforms to prepare for the increase in advance to maximize performance”; Note: a device has its CPU core frequencies altered based on detection of an increase of network traffic volume) wherein the traffic violation comprises packet flooding (¶42: “if there are multiple incoming flows … a controller node 114 detects … an increase in traffic volume”; i.e., the examiner notes that “packet flooding” is defined by Applicant’s Specification at paragraph 15 as being “… a flood of received packets”. Paragraph 40 of Applicant’s Specification further states that said flooding may be considered “malicious or non-malicious”. Therefore, under Broadest Reasonable Interpretation, the examiner interprets the claimed “packet flooding” as being an increase in volume of malicious or non-malicious packet traffic which may result in increased network congestion).
However, Min does not explicitly disclose the following limitation taught by Bhandaru:
reduce a frequency of operation of a peripheral device interface (Bhandaru, Fig. 5, element 450; col 19, lines 56-57, “… the uncore may include … various interfaces 450…”; col. 20, lines 9-10, “In additional, by interfaces 450, connection can be made to various off-chip components such as peripheral devices…”; i.e., the uncore comprises at least a peripheral device interface) … based on detection of a traffic violation (Bhandaru, col 4, lines 56-59: “For a compute centric workload the uncore can be run at a lower … frequency, resulting in applying power savings toward higher core frequencies at a socket level.”; col 11, lines 8-12, “Embodiments may monitor various information, including … interconnect traffic … to determine usage of uncore circuitry of a processor, to detect congestion and under-utilization”; i.e., the examiner notes that “compute centric workload” here corresponds to Min’s increasing of processor core frequency responsive to determining an increase in network traffic flows. Thus, Bhandaru discloses reducing the frequency of an uncore logic (i.e., a peripheral device interface) in order to increase the frequency of processor cores (i.e., Min’s processor core)) …
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Min’s method of increasing frequency of processor core logic for compute centric workloads to overcome performance bottlenecks by incorporating Bhandaru’s method of reducing an uncore (i.e., peripheral device interface) frequency for compute centric workloads by monitoring traffic to detect congestion and under-utilization (see Fig. 5 of Bhandaru for processor core logic and uncore logic comprising a peripheral device interface). Such modification would enable the system of Min to overcome higher core frequency thermal constraints by running uncore logic (i.e., Min’s NIC element 132) at lower frequency, and provide better control over power consumption and performance by applying power savings toward higher core frequencies, and thus increase performance by way of allocating the excess power budget to only cores that seek it, allowing them to run faster and increase system performance (Bhandaru, col 4, lines 29-42 & 46-62).
Regarding claim 13:
The combination of Min and Bhandaru discloses:
The computer-readable medium of claim 10, wherein the peripheral device interface comprises a system agent or an uncore (Bhandaru, col 19, lines 53-54: “… an uncore or system agent logic 420”, see also Fig. 5).
The same motivation which is applied to claim 10 with respect to Bhandaru applies to claim 13.
Regarding claim 14:
The combination of Min and Bhandaru discloses:
The computer-readable medium of claim 10, wherein the peripheral device interface comprises a bus (Min, ¶21: “… a PCIe I/O bus …”), peripheral component interconnect express (PCIe) interface (Min, ¶21: “… Peripheral Component Interconnect Express (PCIe)”), and a cache (Min, ¶37: “GPU’s 306 cache”).
Regarding claim 15:
The combination of Min and Bhandaru discloses:
The computer-readable medium of claim 10, wherein the processor comprises a core (Min, ¶16: “For example, processor 118 may be embodied as a single or multi-core processor(s)”), accelerator, or graphics processing unit (GPU).
Regarding claim 16:
The combination of Min and Bhandaru discloses:
The computer-readable medium of claim 10, comprising instructions stored thereon, that if executed by one or more processors, cause the one or more processors to:
increase a frequency of operation of the peripheral device interface (Bhandaru, col 4, lines 59-61: “… the uncore can be run at a higher voltage and frequency, …”, see also col 11, lines 9-13: “… monitor … interconnect traffic, core activity levels, … to detect congestion and under-utilization.”) based on one or more of:
management of traffic violations at a core (Bhandaru, col 11, lines 9-13: “… monitor … interconnect traffic, core activity levels, … to detect congestion ...”) or not detecting a traffic violation.
The same motivation which is applied to claim 10 with respect to Bhandaru applies to claim 16.
Regarding claim 17:
The combination of Min and Bhandaru discloses:
The computer-readable medium of claim 10, comprising instructions stored thereon, that if executed by one or more processors, cause the one or more processors to:
increase a frequency of operation of the processor if a power budget for the peripheral device interface and the processor permits the increasing the frequency of operation of the processor (Bhandaru, col 2, lines 55-58: “… when power and thermal budget is available, processor hardware can configure the processor … to operate at a higher than guaranteed frequency.”).
The same motivation which is applied to claim 10 with respect to Bhandaru applies to claim 17.
Regarding claim 18:
Min discloses:
An apparatus (¶13: “a computer node 104,”, see Fig. 3) comprising:
at least one processor core (see Fig. 3, CPU 304);
and a power manager circuitry (¶42: “power control unit (PCU) cores”) to:
a … agent … (see Fig. 2, control module 202) coupled to receive packets from a network interface controller and provide the received packets for processing by a core (¶36: “The computer node decision engine 310 takes … NIC 132 information (platform information) and forwards it via the NIC 132 to the controller node 114 for processing …”, see Fig. 3, Control module 202 comprises decision engine 310.);
Min does not explicitly disclose the following limitation taught by Bhandaru:
reduce a frequency of operation of the system agent (Bhandaru, col 2, lines 30-31: “ non-core circuitry, referred to herein as an uncore or a system agent.”, col 19, lines 53-54: “an uncore or system agent logic 420”) based on a request (Bhandaru, col 4, lines 56-59: “For a compute centric workload, the uncore can be run at a lower … frequency, resulting in applying power savings toward higher core frequencies at a socket level.” i.e., the examiner notes that “compute centric workload” here corresponds to Min’s increasing of processor core frequency responsive to determining an increase in network traffic flows. Thus, Bhandaru discloses reducing the frequency of an uncore logic (i.e., a peripheral device interface) in order to increase the frequency of processor cores (i.e., Min’s processor core)), wherein the request is based on detection of a traffic violation (Bhandaru, col 11, lines 8-15: Embodiments may monitor various information, including … interconnect traffic … to determine usage of uncore circuitry of a processor, to detect congestion and under-utilization. This information can be used to adapt the operating frequency of such circuitry to changing workload characteristics, and thus gain power and performance benefit”; i.e., monitor interconnect traffic to determine whether congestion is occurring at uncore circuitry, and change operating frequency (request) of the uncore circuitry based on the congestion. Here, the congestion itself is considered a “traffic violation”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Min’s method of increasing frequency of processor core logic for compute centric workloads to overcome performance bottlenecks by incorporating Bhandaru’s method of reducing an uncore (i.e., peripheral device interface) frequency for compute centric workloads by monitoring traffic to detect congestion and under-utilization (see Fig. 5 of Bhandaru for processor core logic and uncore logic comprising a peripheral device interface). Such modification would enable the system of Min to overcome higher core frequency thermal constraints by running uncore logic (i.e., Min’s NIC element 132) at lower frequency, and provide better control over power consumption and performance by applying power savings toward higher core frequencies, and thus increase performance by way of allocating the excess power budget to only cores that seek it, allowing them to run faster and increase system performance (Bhandaru, col 4, lines 29-42 & 46-62).
Regarding claim 19:
The combination of Min and Bhandaru discloses:
The apparatus of claim 18, comprising circuitry (Min, ¶41: “… monitoring engine module”) to:
detect for traffic violations based on detection of IP packet fragments (Min, ¶41-42: “the monitoring engine module may receive monitored traffic flows and traffic characteristics (e.g., traffic volume, packet size, protocol, etc.) produced internally and/or received from the remote entity 116. … if there are multiple incoming flows with different characteristics, the decision engine module 416 can adjust system configurations and/or parameters to separate incoming flows and send them from a NIC (e.g., the NIC 132) to different power control unit (PCU) cores running at different frequencies.”),
wherein IP packet fragments comprise one or more of:
IP packet fragments that are incomplete packets, IP packet fragment that are too small, IP packet fragments that result in excessive packets (Min, ¶42: “if there are multiple incoming flows … a controller node 114 detects … an increase in traffic volume,”, Note: “multiple incoming flows” teaches “excessive packets”), or IP packet fragmentation buffer being full.
Regarding claim 20:
The combination of Min and Bhandaru discloses:
The apparatus of claim 18, comprising circuitry (Bhandaru, col 12, lines 24-25: “… the PCU may be used to analyze the data to adapt the uncore frequency as necessary. ”) to increase a frequency of operation of the system agent (Bhandaru, col 4, lines 59-61: “… the uncore can be run at a higher voltage and frequency, …”, see also col 11, lines 9-13: “… monitor … interconnect traffic, core activity levels, … to detect congestion and under-utilization.”, col 2, lines 30-31: “non-core circuitry, referred to herein as an uncore or a system agent.”) based on one or more of:
management of traffic violations at a core (Bhandaru, col 11, lines 9-13: “… monitor … interconnect traffic, core activity levels, … to detect congestion ...”) or not detecting a traffic violation and request the power manager to increase a frequency of operation of the system.
The same motivation which is applied to claim 18 with respect to Bhandaru applies to claim 20.
Regarding claim 21:
The combination of Min and Bhandaru discloses:
The apparatus of claim 18, wherein the system agent circuitry comprises an interface to a cache (Bhandaru, col 19, lines 54-57: “… an uncore or system agent logic 420 … may include a shared cache 430 …”) and an interface to a memory (Bhandaru, col 19, lines 56-57: “the uncore may include an integrated memory controller 440,”).
The same motivation which is applied to claim 18 with respect to Bhandaru applies to claim 21.
Claims 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Min in view of Bhandaru, and further in view of US-PGPUB No. 2005/0018618 A1 to Mualem et al. (hereinafter “Mualem”)
Regarding claim 11:
The combination of Min and Bhandaru discloses the computer-readable medium of claim 10, but fails to explicitly disclose the following limitation taught by Mualem:
wherein IP packet fragments comprise one or more of:
IP packet fragments that are incomplete packets, IP packet fragment that are too small (Mualem, ¶24: “The protocol anomaly detection module looks for a number of anomalies, including but not limited to, … an IP packet having a header that is too small; … an IP packet that is not large enough to carry its advertised data;”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Min and Bhandaru to incorporate the functionality of the protocol anomaly detection module to look for an IP fragment and determine anomalies in the packet when the fragments are either too small or the fragments are in excess of a determined value, as disclosed by Mualem, such modification would allow the system to determine the validity of the IP Packet before applying additional resource intensive computations to determine other validation issues.
Regarding claim 12:
The combination of Min, Bhandaru and Mualem discloses:
The computer-readable medium of claim 11, comprising instructions stored thereon, that if executed by one or more processors, cause the one or more processors to:
detect traffic violations based on detection of IP packet fragments (Min, ¶41-42: “the monitoring engine module may receive monitored traffic flows and traffic characteristics (e.g., traffic volume, packet size, protocol, etc.) produced internally and/or received from the remote entity 116. … if there are multiple incoming flows with different characteristics, the decision engine module 416 can adjust system configurations and/or parameters to separate incoming flows and send them from a NIC (e.g., the NIC 132) to different power control unit (PCU) cores running at different frequencies.”) at one or more of:
a network appliance, the network interface controller, uncore, system agent, operating system, application, or a computing platform (Min, ¶42: “… the decision engine module 416 can calculate, among other things, (a) an optimal packet batch size for one or more NICs, … if there are multiple incoming flows with different characteristics, the decision engine module 416 can adjust system configurations and/or parameters to separate incoming flows”).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHIAS HABTEGEORGIS whose telephone number is (571)272-1916. The examiner can normally be reached M-F 8am-5pm ET.
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, William R. Korzuch can be reached at (571)272-7589. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/M.H./Examiner, Art Unit 2491
Prosecution Insights