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 Objections
Claims 5 is objected to because of the following informalities:
Claim 5 recites: “encrypted by the accelerator though one or more…” should be corrected to –encrypted by the accelerator through one or more…--
Claim Rejections - 35 USC § 103
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 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, 3-4, 7-9, 11, 13-15, 17, 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Xu Pub. No.: US 2008/0089232 (hereinafter Xu) in view of Giri et al. Pub. No.: US 2021/0026684 (hereinafter Giri).
As per claim 1, Xu teaches a method to manage data processing in a computing system, comprising:
setting one or more processing rate limits of the computing system (see paragraph [0024], “the traffic rate for a defined class is set by software,” and that software assigns credits for each traffic class and forwards the credits to the hardware components. It also teaches that, for a configured rate Rc, the number of credits C to be issued each time interval is calculated and send to the hardware, see paragraph [0026]) for a respective one of a set of data flows (see paragraph [0024], it shows that a traffic class may be associated with a physical port, an outgoing queue, or a particular flow pattern defined by an ACL group. Thus, the rate limit is set for a respective traffic type/flow pattern among multiple traffic classes flows) based on a priority within a plurality of priorities (see paragraph [0031], port and priority based rate limiting, where the traffic class is mapped using a port and a priority queue number, with q={1, 2, 3, 4} representing the priority queue), the respective one of the set of data flows to be processed a processor of the computing system (see paragraph [0023]-[0024], it shows that the rate-limiting system includes both a hardware component and a software component. The hardware component is a credit-based system, and the software component calculates/assigns credit and forwards them to the hardware component. Thus, software/processor functionality);
upon receiving data of a data flow (see paragraph [0025], as packets arrive for a given class, the hardware component examines packet size and performs credit-based processing. It also teaches that, for each packet received in incoming traffic of the traffic type, the packet size is evaluated), determining whether to process the data based on the one or more processing rate limits for the data flow (see paragraphs [0024]-[0026] and paragraph [0307], the hardware reads the current counter value for the traffic class, compares it to the number of credits the packet is worth, and forwards the packet if sufficient credits exist; otherwise, the packet is dropped. This is a determination whether to process/forward the packet based on the applicable rate limit/credits for the traffic class/flow) and a processing rate of the data flow (see paragraph [0026], sample actual output rate Rs over a time period and comparing it with the configured rate Rc. It also teaches sampling outgoing traffic of the traffic type to arrive at an outgoing traffic rate. This maps to using the actual processing/output rate of the data flow); and
responsive to a determination to process the data, causing a processing rate update of the data flow based on resources consumed (see Fig. 3 and paragraphs [0037], [0040] if the counter is greater than or equal to the number of credits the packet is worth, the packet is forwarded; otherwise, it’s dropped. Forwarding the packet corresponds to processing the data after a positive determination; It further teaches dynamically adjusting the actual output rate by changing the number of credits issued per interval at runtime, wherein the sampled actual output rate is compared with the configured rate, and a new credit allotment is sent to the hardware, see also paragraph [0041]);
Xu teaches a hardware/software components but did not specifically teach an accelerator. However, the secondary reference Giri teaches an accelerator communicatively coupled to the processor and identifies a priority level in a task control block (see Giri abstract and paragraph [0027];
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to utilize the teach of Giri’s hardware accelerator and priority job queue with Xu’s rate-limiting/credit-based control as both references directed to controlling hardware processing of work/data according to priority or class. The combination would predictably allow system to avoid over-consuming accelerator resources by using rate-limit and credit-update technique to queue accelerator work, which significantly improves performances.
As per claim 3, Xu in view of Giri further teach wherein setting the one or more processing rate limits at the accelerator of the computing system for the respective one of the set of data flows is further based on a first data structure to track a number of data flows to be processed concurrently by the accelerator (Xu paragraph [0032] teaches a table holding traffic class credit information and that a traffic class correspond to a port, queue, or ACL-defined flow pattern. This maps to using a first data structure to track multiple data flows to be processed concurrently; Giri teaches a queue/list of TCBs stored in memory, where TCBs are to be executed by the accelerator, including previously executed, currently executing, and to-be-executed TCBs, see paragraph [0027] and abstract).
As per claim 4, Xu in view of Giri further teach wherein the first data structure includes one entry for the respective one of the set of data flows, wherein the one entry includes a user identifier (ID), a priority indication of the data flow, based on which one or more corresponding rate limits are determined (Giri abstract and paragraph [0038] teaches that each TCB includes an indication of priority level, and the processor identifies a location in a queue based on that priority. Xu paragraphs [0024] and [0044] teaches traffic class/flow patterns and ACL-defined flow patterns, which would reasonably include identifiers/classification information for determining the corresponding rate limit. Therefore, an entry including a user/flow identifier and priority indication would have been an obvious way to identify the flow and select the corresponding rate limit).
As per claim 7, Xu in view of Giri further teach wherein a controller is to maintain a second data structure to track processing rate limits at the accelerator of the computing system for the set of data flows and a third data structure to track processing rates of the set of data flows (Giri paragraphs [0054]-[0056] teaches that processor maintains queue-related information, including the first TCB in the queue, first TCB at a given priority level, last TCB in the queue, and last TCB at a given priority level. Xu teaches traffic-class credit tables, counters, sampled outgoing traffic rates, and updated credit allotments. These correspond to a second data structure tracking processing rate limits and a third structure tracking processing rate, Xu paragraphs [0026] and [0032]).
As per claim 8, Xu in view of Giri further teach wherein setting the one or more processing rate limits at the accelerator is through an application programming interface (API) (Giri paragraphs [0054]-[0056] expressly teaches APIs for queue management, including submitting jobs, inserting jobs, deleting TCBs, querying status, modifying TCBs, and resetting the hardware accelerator. Xu teaches that rate limits/credits are assigned by software and sent to the hardware component (Xu paragraph [0024]). It would have been obvious to provide Xu’s rate-limit setting through Giri’s accelerator-management API).
As per claim 9, Xu in view of Giri further teach wherein determining whether to process the data at the accelerator comprises comparing the one or more processing rate limits for the data flow and the processing rate of the data flow (Xu paragraphs [0033]-[0035] and [0040]-[0041] teaches comparing the configured rate limit with actual output rate by sampling outgoing traffic and repeating the implementation with a different rate limit chosen to reduce the difference between the rate limit and outgoing traffic. It also shows dropping or forwarding packets based on the counter/credits for the traffic type. This maps to comparing processing rate limits with the processing rate of the data flow).
As per claim 11, it’s rejected for the same reasons set forth above in claim 1. For the processor, both prior arts teach a processor (see Giri abstract).
As per claim 13, it’s rejected for the same reasons set forth above in claim 3.
As per claim 14, it’s rejected for the same reasons set forth above in claim 4.
As per claim 15, it’s rejected for the same reasons set forth above in claim 7.
As per claim 17, it’s rejected for the same reasons set forth above in claim 1.
As per claim 19, it’s rejected for the same reasons set forth above in claim 3.
As per claim 20, it’s rejected for the same reasons set forth above in claim 9.
Claims 2, 10, 12, 16, 18 are rejected under 35 U.S.C. 103 as being unpatentable over Xu in view of Giri, and further in view of Gandhi et al. Pub. No.: US 2005/0120102 (hereinafter Gandhi)
As per claim 2, Xu in view of Giri further teach setting a rate limit as credits per time interval for a traffic type, where each credit represents a fixed number of bits, and the rate limit is sent to rate-limiting component (see Xu, paragraphs [0037] to [0042]).
Xu in view of Giri fail to teach CIR and PIR. However, Gandhi teaches CIR and PIR, it discloses that a customer aggregate CIR and individual granular CIRs and/or PIRs for various types of information, and that one token bucket may be used with CIR while other token buckets may be associated with PIR (See Gandhi, paragraphs [0007], [0011]-[0013]).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filling date, to set CIR/PIR for the data flow in the system of Xu in view of Giri credit-based rate limiting, for the purpose of regulating network traffic and allocating bandwidth among traffic/services with different priority or QoS requirements, which improves overall system performance.
As per claim 10, Xu in view of Giri fail to teach the limitation of claim 10. However, Gandhi teaches token-bucket bandwidth profiles, CIR and PIR token buckets, and hierarchical/flexible token allocation. Specifically, it teaches that Fig. 4 depicts a PIR token bucket and a CIR token bucket used to control a service, and Fig. 5 tests packets against the PIR and CIR token buckets. Gandhi further teaches hierarchical allocation in which excess tokens from a higher-priority service may be donated to lower priority services (see abstract, and paragraphs [0019] and [0066]). This maps to using hierarchical token bucket with CIR/PIR-based ingress/egress tokens. The motivation in claims 2 applies in here as well.
As per claims 12 and 18, they are rejected for the same reasons set forth above in claim 2.
As per claim 16, it’s rejected for the same reasons set forth above in claim 10.
Claims 5-6 are rejected under 35 U.S.C. 103 as being unpatentable over Xu in view of Giri, and further in view of Yang et al. Patent No.: US 7,003,118 (hereinafter Yang).
As per claim 5, Xu in view of Giri did not specifically teach the encryption. However, Yang teaches that IPsec encryption/decryption is handled within the IP layer and that IPsec can encrypt data sent by any application (see col. 2, lines 5-20 and col. 3, lines 30-42). It further teaches a high-performance IPsec accelerator installed on a NIC and implemented in hardware, assisting the host with inbound and outbound IP-layer security services (see abstract and col. 2, lines 36-59). Yang also shows crypto/decrypto engine programmed to encrypt or decrypt AH and ESP fields of outbound and inbound packets (col. 9, lines 30-47). This maps to encrypting the data flow using cryptographic algorithms and at least IPsec.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to utilize Yang IPsec hardware accelerator with Xu/Giri for the purpose of encrypting/decrypting/authenticating computationally intensive without burdens the processor, and therefore provides a hardware IPsec accelerator on a NIC to assist the host with inbound and outbound IPsec processing.
As per claim 6, Xu in view of Giri did not specifically teach the limitation of claim 6. However, Yang teaches IPsec TX and RX processing, including an IPsec TX packet parser, IPsec TX control state machine, TX security association database, RX security association database, and SA_ID/SPI look (see col. 5, lines 58 to col. 6, line 60). For the outbound traffic, Yang teaches looking up the security association and starting IPsec encryption/authentication; for inbound traffic, Yang shows RX packet parsing, SA lookup, and decryption/authentication. This maps to IPsec flows, SADB, decrypting a first set of IPsec flows arriving at the system, forwarding them to the processor, and encrypting a second set of IPsec flows before routing them out (see col. 5, lines 58 to col. 6, line 60 and col. 3, lines 5-42).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to utilize the teach of Yang IPsec/SADB accelerator functionality in the invention of Xu/Giri because doing so would merely apply Xu’s known rate-limiting resource-control technique to a known accelerator workload taught by Yang, namely IPsec encryption/decryption. The benefit is to control accelerator resource consumption among multiple encrypted IPsec flows while reducing host CPU burden and maintaining priority/QoS treatment.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US PG-Pub No.: 2007/0206018 teaches dynamically controlled power reduction for a graphics processor.
US PG-Pub No.: 2024/0330092 teaches reporting of errors in packet processing.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IDRISS N ALROBAYE whose telephone number is (571)270-1023. The examiner can normally be reached Mon-Fri, 8am-4:30pm.
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, John Cottingham can be reached at 571-272-1400. 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.
/IDRISS N ALROBAYE/ Supervisory Patent Examiner, Art Unit 2181
Prosecution Insights