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 .
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 8-14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims do not fall within at least one of the four categories of patent eligible subject matter because they are directed to non-statutory subject matter of transitory media, including propagation and communication mediums. Claim 8 recites claim language of a "machine readable storage medium (see claim 15 lines 1-2). However, in paragraph [0104] the instant specification, such a medium has not been limited to non-transitory media. Transitory media, including propagation and communication mediums, are not a type of non-transitory hardware storage that can be read by a computer, as functional descriptive material cannot be recorded on this medium, nor can said functional descriptive material become structurally and functionally interrelated to the medium. As such, the claim is drawn to non-statutory subject matter.
Examiner suggests changes to claims 8-14 such as a "non-transitory computer readable storage medium, the non-transitory computer readable medium stores computer programs. " in order to draw the claim to statutory subject matter. Claims 9-14 are rejected under 35 U.S.C. 101 as non-statutory for at least the reason stated above.
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-4, 6-11, 13-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Tripathi (US 7,937,499 B1) in further view of Koukos et al. (US 20220075654 A1).
Regarding claim 1, Tripathi teaches the invention substantially as claimed including a method, comprising:
respectively adding respective identifiers of respective queues that provide packets to a CPU to a list in response to the respective queues being deemed quiet (Col. 7, lines 62-64: As described above, a NIC is capable of operating in two different modes for each ring buffer associated therewith. These modes may be entered upon initialization (e.g., boot up), upon instruction from an external source (e.g., CPU or driver associated with the NIC), or upon instruction internally from within the NIC. For instance, the NIC may choose to alter its mode of operation due to an external (e.g., busy or non-busy state); Col. 8, lines 12-20: As described above, a NIC and an associated buffer may be mapped to a CPU and its associated queue. In accordance with one embodiment, this mapping is performed during initialization of the computer system…This may be accomplished through the use of a ring buffer identifier…Upon receiving the ring buffer identifier, the operating system kernel stores the ring buffer identifier (e.g., during initialization or upon receiving an interrupt) such that the ring buffer identifier is associated with an interrupted CPU and its associated queue.; Col. 9, lines 18-43: Once all of the packets in the queue of the CPU have been processed, the operating system kernel polls the NIC at block 322 to determine if the ring buffer of the NIC received one or more packets. For instance, the operating system kernel, the driver and/or the NIC may ascertain whether there are any packets in the identified ring buffer. This may be accomplished, for example, by querying the NIC with a specific ring buffer identifier…If no more packets have been received by the identified ring buffer of the network interface card (e.g., no packets are in the ring buffer of the NIC) at block 324, the network interface card is instructed to switch from the polling mode to the interrupt mode for the identified ring buffer at block 328. For instance, as described above, the NIC may be instructed to switch from the polling mode to the interrupt mode for the ring buffer identified by the specific ring buffer identifier. The process then continues at block 310 to process interrupts as they are received.);
as a consequence of an interrupt having been generated in response to one of the respective queues having received a packet, removing the respective identifiers from the list and executing respective poll service handlers for the respective queues (Col. 7, lines 62-64 For instance, the NIC may choose to alter its mode of operation due to an external (e.g., busy or non-busy state); Col. 8, lines 12-20 Upon receiving the ring buffer identifier, the operating system kernel stores the ring buffer identifier (e.g., during initialization or upon receiving an interrupt) such that the ring buffer identifier is associated with an interrupted CPU and its associated queue.; Col. 10, lines 25-51: When the CPU receives notification of the interrupt, the CPU signals a worker thread (e.g., dedicated to the CPU) to process packets at block 418. The worker thread may be dedicated to processing all packets for the CPU, or merely dedicated to processing packets in the queue associated with the CPU. Specifically, the IP layer or worker thread transfers a set of packets in the identified ring buffer of the NIC to the queue of the CPU as identified in the mapping at block 420. In accordance with one embodiment, the worker thread calls a procedure GET_PACKETS with the ring buffer identifier (and optionally the NIC identifier) as a parameter to transfer the packets from the identified ring buffer of the appropriate NIC to the queue of the CPU. As described above, the ring buffer identifier maps the CPU and its associated queue to the identified ring buffer of the NIC. The worker thread then calls a procedure CHANGE_INTERRUPT at block 422 with the ring buffer identifier (and NIC identifier) as parameters and a boolean value to turn off interrupt processing for the ring buffer identified by the ring buffer identifier (and its associated CPU). In this manner, the NIC is instructed to enter the polling mode for the identified ring buffer. (The NIC remains in interrupt mode for the remaining ring buffers.) For instance, the NIC may be instructed to enter the polling mode for the identified ring buffer when the interrupt identifying the ring buffer is received or shortly thereafter. In addition, the worker thread processes each of the packets in the queue of the CPU at block 424.); and,
adding those of the respective identifiers back to the list for those of the respective queues that are again deemed quiet (Col. 7, lines 62-64 For instance, the NIC may choose to alter its mode of operation due to an external (e.g., busy or non-busy state); Col. 8, lines 12-20; Col. 10, line 66 through Col. 11, line 13: Once it is determined that the identified ring buffer of the NIC has not received any additional packets (e.g., there are no additional packets in the identified ring buffer), the worker thread calls the procedure CHANGE_INTERRUPT at block 432 with the ring buffer identifier (and NIC identifier) and a boolean value as a parameter to turn on interrupt processing for the ring buffer identified by the ring buffer identifier (and its associated CPU). In this manner, the NIC is instructed to enter the interrupt mode for the identified ring buffer. (The mode of all remaining ring buffers remains unmodified.) Thus, the NIC is instructed to switch to the interrupt mode for the identified ring buffer when no packets are in the queue associated with the CPU identified in the mapping or the identified ring buffer of the NIC. The process then continues at block 412 as interrupts are received by the CPU.), while, continuing executing others of the respective poll service handlers for others of the respective queues that are not deemed quiet (Col. 10, lines 25-51: When the CPU receives notification of the interrupt, the CPU signals a worker thread (e.g., dedicated to the CPU) to process packets at block 418. The worker thread may be dedicated to processing all packets for the CPU, or merely dedicated to processing packets in the queue associated with the CPU. Specifically, the IP layer or worker thread transfers a set of packets in the identified ring buffer of the NIC to the queue of the CPU as identified in the mapping at block 420. In accordance with one embodiment, the worker thread calls a procedure GET_PACKETS with the ring buffer identifier (and optionally the NIC identifier) as a parameter to transfer the packets from the identified ring buffer of the appropriate NIC to the queue of the CPU.)
Tripathi as cited teaches instantiation of worker threads in Col. 10, line 66 through Col. 11, line 13. But does not expressly teach disabling those of the respective poll service handlers.
However, Koukos teaches disabling those of the respective poll service handlers ([0004] The method comprises, as a result of the at least one work queue being empty during the polling for a first period of time, causing the worker thread to alternately: poll the at least one work queue during at least one polling interval; and enter an autonomous sleep state during at least one sleep interval. The method comprises, as a result of the at least one work queue being empty during each polling interval for a back-off period, causing the worker thread to enter a non-autonomous sleep state for a yield period controlled by a wake-up signal.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Koukos with the teachings of Tripathi to place a polling working thread to enter a sleep/disabled mode after polling for a period of time. The modification would have been motivated by the desire of preventing wasting resources while waiting for an incoming packet/interrupt as taught by Tripathi.
Regarding claim 2, Tripathi teaches further comprising registering respective poll objects for the respective queues through an application programming interface, wherein, the respective poll objects contain information used to invoke their respective queue's poll service handler (Col. 10, line 25 through line 51: When the CPU receives notification of the interrupt, the CPU signals a worker thread (e.g., dedicated to the CPU) to process packets at block 418. The worker thread may be dedicated to processing all packets for the CPU, or merely dedicated to processing packets in the queue associated with the CPU. Specifically, the IP layer or worker thread transfers a set of packets in the identified ring buffer of the NIC to the queue of the CPU as identified in the mapping at block 420.; Col. 6, line 59 through Col. 7, line 12: Communication between the CPUs 202, 204, 206 and the NICs 208, 210, 212 may be achieved through the use of a driver 228. In accordance with one embodiment, the driver includes one or more application programming interfaces (APIs) (e.g., CHANGE_INTERRUPT(BUFFER_NUMBER) to enable the operating system kernel to instruct one of the NICs 208, 210, 212 to change its mode from the interrupt mode to the polling mode for a particular ring buffer, or from the polling mode to the interrupt mode for a particular ring buffer. In addition, an API (e.g., GET_PACKETS(BUFFER_NUMBER) may be provided that enables the operating system kernel to move a set of packets from one of the buffers 222a-n, 224a-n, 226a-n associated with one of the NICs 208, 210, 212 to one of the queues 216, 218, 220 associated with one of the CPUs 202, 204, 206. Thus, the operating system kernel may instruct a NIC to change its mode from interrupt mode to polling mode for one or more ring buffers, or from polling mode to interrupt mode for one or more ring buffers. In response, the NIC enters the polling mode or the interrupt mode for the specified ring buffer(s), as instructed.).
Regarding claim 3, Tripathi teaches wherein the application programming interface is an NDIS interface and the poll objects are NDIS_POLL_CHARACTERISTICS data structures (Col. 6, line 59 through Col. 7, line 12: Communication between the CPUs 202, 204, 206 and the NICs 208, 210, 212 may be achieved through the use of a driver 228. In accordance with one embodiment, the driver includes one or more application programming interfaces (APIs) (e.g., CHANGE_INTERRUPT(BUFFER_NUMBER) to enable the operating system kernel to instruct one of the NICs 208, 210, 212 to change its mode from the interrupt mode to the polling mode for a particular ring buffer, or from the polling mode to the interrupt mode for a particular ring buffer. In addition, an API (e.g., GET_PACKETS(BUFFER_NUMBER) may be provided that enables the operating system kernel to move a set of packets from one of the buffers 222a-n, 224a-n, 226a-n associated with one of the NICs 208, 210, 212 to one of the queues 216, 218, 220 associated with one of the CPUs 202, 204, 206. Thus, the operating system kernel may instruct a NIC to change its mode from interrupt mode to polling mode for one or more ring buffers, or from polling mode to interrupt mode for one or more ring buffers. In response, the NIC enters the polling mode or the interrupt mode for the specified ring buffer(s), as instructed.).
Regarding claim 4, Tripathi teaches further comprising binding the poll objects with the CPU (Col. 10, line 25 through line 51: When the CPU receives notification of the interrupt, the CPU signals a worker thread (e.g., dedicated to the CPU) to process packets at block 418. The worker thread may be dedicated to processing all packets for the CPU, or merely dedicated to processing packets in the queue associated with the CPU.).
Regarding claim 6, Tripathi teaches wherein the interface is an NDIS interface and the information is contained within NDISPOLLRECEIVEDATA data structures (Col. 6, line 59 through Col. 7, line 12: an API (e.g., GET_PACKETS(BUFFER_NUMBER) may be provided that enables the operating system kernel to move a set of packets from one of the buffers 222a-n, 224a-n, 226a-n associated with one of the NICs 208, 210, 212 to one of the queues 216, 218, 220 associated with one of the CPUs 202, 204, 206).
Regarding claim 7, it has similar limitations as claim 1 but pertaining to a second CPU and its respective queue. Given that the combination of references as cited cover a plurality of CPUs, the same rationale applies. Also, see Fig 6 and corresponding description.
Regarding claim 8, it is a media/product type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above.
Regarding claim 9, it is a media/product type claim having similar limitations as claim 2 above. Therefore, it is rejected under the same rationale above.
Regarding claim 10, it is a media/product type claim having similar limitations as claim 3 above. Therefore, it is rejected under the same rationale above.
Regarding claim 11, it is a media/product type claim having similar limitations as claim 4 above. Therefore, it is rejected under the same rationale above.
Regarding claim 13, it is a media/product type claim having similar limitations as claim 6 above. Therefore, it is rejected under the same rationale above.
Regarding claim 14, it is a media/product type claim having similar limitations as claim 7 above. Therefore, it is rejected under the same rationale above.
Regarding claim 15, it is a system type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above. Further, the additional limitations are taught as follow: a network (Col. 1, line 41: receives a packet over the network);
a memory pool coupled to the network (Fig. 2, NIC memories 1-n);
a storage pool coupled to the network (Fig. 2, shows NIC memories connected through a network);
a host processor pool coupled to the network, the host processor pool comprising a processing unit coupled to local memory, the processing unit comprising a plurality of central processing units (CPUs) (Fig. 2, CPU0-n), one or more packet processing pipeline and one or more traffic shaper circuits, wherein, packets that are processed by the one or more packet processing pipelines and the one or more traffic shaper circuits are placed into respective queues that are implemented within the local memory, wherein, the respective queues provide packets to one of the CPUs (Fig. 2, Col. 8, discusses the use of worker threads managing packets in queues, see citations for claim 1); and,
a machine readable storage medium containing program code that when processed by the processing unit causes a method to be performed (Col. 3, lines 48-50: The invention can also be embodied as computer readable code on a computer readable medium. In addition, data structures disclosed are also part of the invention.)
Regarding claim 16, it is a system type claim having similar limitations as claim 2 above. Therefore, it is rejected under the same rationale above.
Regarding claim 17, it is a system type claim having similar limitations as claim 3 above. Therefore, it is rejected under the same rationale above.
Regarding claim 18, it is a system type claim having similar limitations as claim 4 above. Therefore, it is rejected under the same rationale above.
Regarding claim 20, it is a system type claim having similar limitations as claim 6 above. Therefore, it is rejected under the same rationale above.
Claims 5, 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Tripathi (US 7,937,499 B1) in view of Koukos et al. (US 2022/0075654 A1), in further view of Musa et al. (US 11,474,868 B1).
Regarding claim 5, Tripathi nor Koukos explicitly teach wherein the respective poll service handlers refer to respective information that sets a limit on the amount of packet data that can be serviced from the respective queues.
However Musa teaches wherein the respective poll service handlers refer to respective information that sets a limit on the amount of packet data that can be serviced from the respective queues (Abstract: A shard polling system fairly distributes stored items from producers to consumer processes and includes polling threads that poll for items from respective portions of a storage source, place the items in respective queues, and increment a global permit counter, restricted to a configurable maximum, that tracks the quantity of messages across the respective queues. The polling threads are restricted by respective shard permit counters that limit a quantity of items that may be moved from a storage source to a respective queue.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Musa with the teachings of Tripathi and Koukos to enforce a limit on the amount of items/packets moved to a respective queue. The modification would have been motivated by the desire of ensuring fair resource utilization.
Regarding claim 12, it is a media/product type claim having similar limitations as claim 5 above. Therefore, it is rejected under the same rationale above.
Regarding claim 19, it is a system type claim having similar limitations as claim 5 above. Therefore, it is rejected under the same rationale above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Vasudevan et al. (US 2019/0391940 A1) See at least Abstract.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORGE A CHU JOY-DAVILA whose telephone number is (571)270-0692. The examiner can normally be reached Monday-Friday, 6:00am-5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee J Li can be reached at (571)272-4169. 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.
/JORGE A CHU JOY-DAVILA/Primary Examiner, Art Unit 2195
Prosecution Insights