DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
The amendment filed on 6/29/2026 has been entered. Claims 1, 4-8, 11-15, and 18 remain pending in this application.
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, 4-8, 11-15, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Vankamamidi et al. (US Pub. No. 2021/0034409 A1 hereinafter Vankamamidi *cited in IDS*) in view of Shah et al. (US Pub. No. 2022/0026972 A1 hereinafter Shah) in view of Hill et al. (US Patent No. 12,238,009 hereinafter Hill).
As per claim 1, Vankamamidi teaches a method comprising: initializing a shared token pool (¶ [0098], “QoS (e.g., via regulation process 10) may maintain a pool of tokens (or credits or other similar scheme) corresponding to resources required to issue IOs. Enough tokens must generally be available to issue an IO; otherwise, the IO may be queued until tokens are available.” ¶ [0100], “Regarding read/write throttling (as discussed above), QoS maintains a pool of tokens for issuing IO. Each IO is assigned a required number of tokens based on the load the IO is expected to exert on the DP. If the number of tokens in the pool is larger than the number of tokens needed by the IO, the IO may be sent to the DP and the number of tokens remaining in the pool may be reduced; otherwise, the IO may be queued until sufficient number of tokens exist in the pool. When an IO completes, its tokens are added back to the pool. Based on observed latency, the token pool size may be increased or decreased.”); receiving a host I/O (Input/Output) request and identifying, among the multiple processor cores, a processor core for processing the I/O request (¶ [0097], “In some implementations, the rate of one of the background IOs and the rate of host IOs may be regulated based on a Quality of Service metric. For example, as noted above, a “regulator” component of regulation process 10 may be responsible for regulating the execution of host IO and internal background operations…Regulation process 10 may achieve this by, for example purposes only, distributing scheduling “credits” or tokens (or similar scheme) to a host IO scheduler and background operation scheduler during each scheduling cycle. To decide on scheduling “tokens,” the regulator may continuously (or intermittently) measure latency on host IOs. As a general rule, when host IO latency is increasing, the number of “tokens” available for background operations may be trimmed up to a minimum “credit” (e.g., trickle mode). If host IO latency is increasing even when background operations are at minimum token level, the scheduler “credits” to the host IO scheduler may be reduced thereby throttling host IOs. This mechanism may help with reducing the congestion in the data path.” ¶ ); calculating a number of tokens required by the host I/O request (¶ [0102], “Referring again to the above-noted token pool, it may be partitioned across the cores that serve the IOs. The number of tokens required for an IO may be based on IO size and type. The intent is to make the “token cost” for an IO represent as close as possible the cost in system resources required to service the IO. The size of the token pool may control the amount of concurrent IOs sent to the DP.”); and allocating the number of tokens required by the host I/O request corresponding to the identified processor core and processing the host I/O request (¶ [0102]-[0103], “Referring again to the above-noted token pool, it may be partitioned across the cores that serve the IOs. The number of tokens required for an IO may be based on IO size and type. The intent is to make the “token cost” for an IO represent as close as possible the cost in system resources required to service the IO…The amount of load an IO is expected to place on the DP, and thus the number of tokens the IO requires, may be based on the following example and non-limiting premises: (1) Reads exert less load than writes; (2) A base factor indicating an IO exerts at least this amount of load regardless of its size; (3) An inflection point over which the size of the IO matters (e.g., a 4 KB IO and an 8 KB IO may be considered to exert an equivalent amount of load but not so for a 128 KB IO); (4) An inflection scaling factor once the inflection point is surpassed…”).
Although Vankamamidi teaches a shared token pool and partitioning the shared token pool across cores, Vankamamidi fails to explicitly teach per-core token pools and ensuring that per-core token pools have enough tokens to execute a request.
However, Shah teaches initializing a shared token pool and multiple per-core token pools, wherein each per-core token pools corresponds to a respective one of multiple processor cores (¶ [0046], “Processing begins at operation S252, where token pool 420, of power management program 300, traverses a plurality of frequency domains of an integrated circuit chip. In some embodiments, the integrated circuit chip is a central processing unit (CPU), and each frequency domain, for example first frequency domain 306 and second frequency domain 312, is a core of the CPU. The frequency domains are organized in a ring topology. Token pool 420 traverses around the ring indefinitely, interacting in turn with each frequency domain. At each interaction between token pool 420 and a frequency domain, various events may take place including, but not limited to: (i) token pool 420 receives token(s) from the frequency domain; (ii) token pool 420 gives token(s) to the frequency domain; (iii) token pool 420 receives a “starvation” flag from the frequency domain, which signals that the frequency domain is in need for more tokens.” ¶ [0066], “Token pool 420 repeatedly (iteratively) cycles through the ring topology, interacting in turn with all control units during each cycle. Each control unit is associated with, manages, and/or governs a frequency domain (not shown in the Figures) with respect to power usages allowed for each of the frequency domains. Each control unit is associated with a respectively corresponding starvation flag and a token count (the number of tokens held by the control unit). The ring topology may comprise any number of control units and respectively corresponding frequency domains.” See also Figs. 4A-4F.) and in response to the per-core token pool corresponding to the identified processor core not containing a total number of tokens equal to at least the number of tokens required by the request, allocating all tokens contained in the per-core token poo corresponding to the identified processor core from the per-core token pool corresponding to the identified processor core (¶ [0049], “In some embodiments, starvation flag 318 includes information indicating a magnitude of power allowance requested by first control module 308. Starvation flag 318 indicates that first control module 308, due to current workload, requests permission to consume more power so as to process the current workload (or backlog thereof) more quickly. In some embodiments, control modules not running a heavy workload voluntarily donate excess tokens to the token pool, even in the absence of a starvation flag. The starvation flag is a new feature added to a conventional system that operates under “altruistic” (fair distribution based on workload requirements) principles. The starvation flag may indicate that the associated control unit urgently needs additional tokens to start performing an operation.”), calculating a number of additional tokens necessary to be allocated for the host I/O request to be processed, allocating a number of tokens from the shared token pool, and processing the host I/O request (¶ [0075]-[0077], “FIG. 4D is a schematic diagram showing placement of a power request token by a control unit onto the token pool in accordance with some embodiments of the present invention. In particular, control unit 403 has a power deficit, and places starvation flag 405, asking for 50 power tokens, onto token pool 420…Once token pool 420 determines the reason why the control unit issued the signal (for example to donate excess power tokens to token pool 420), token pool 420 takes appropriate action (for example to receive the excess power tokens and deliver the donated power tokens to a “needy” control unit. Once no more action is called for, token pool 420 re-enters the idle state. In some embodiments, a starvation flag specifies a number of tokens requested by the associated control unit, called the “remaining to be filled” number (RTBF number). The token pool collects up to the RTBF number of power tokens, earmarks them for delivery to the requesting control unit, and delivers the power tokens to the requesting control unit in satisfaction of the starvation flag. The token pool then returns the starvation flag (or otherwise cancels the starvation flag) to the requesting control unit.”).
Vankamamidi and Shah are considered to be analogous to the claimed invention because they are in the same field of request processing and resource allocation using token pools. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the I/O request processing method of Vankamamidi with the token pool functionality of Shah to arrive at the claimed invention. The motivation to modify Vankamamidi with the teachings of Shah is that implementing token pools associated with cores of a CPU keeps the CPU within a power budget which avoids a situation in which processing power exceeds cooling capacity. Additionally, per-core token pools allow heavily loaded cores to possess more tokens which allows them to operate at a higher frequency which increases workload execution (See Shah para. 0047-0048.).
Although Vankamamidi and Shah teach allocating additional tokens from the shared token pool, Vankamamidi and Shah fail to teach allocating a number of tokens from the shared token pool that is larger than the number of additional tokens necessary for the host I/O request.
However, Hill teaches a known technique of calculating a number of additional tokens necessary to be allocated for the host I/O request to be processed and allocating a number of tokens from the shared token pool that is larger than the number of additional tokens necessary to be allocated for the host I/O request to be processed (Col. 34, lines 10-35, “According to some examples, when the control agent 612A determines that the current number of tokens available in the logical bucket 708 for Traffic Class 1 is less than the amount of tokens necessary to route the network data, the flow control node may re-allocate a portion of remaining tokens from another logical bucket or drop the network data and return one or more error messages. The re-allocation of tokens may be performed in response to running out of tokens and/or at some point in time prior to running out of tokens.” Col. 38, lines 4-22 & 47-65, “At 1108, a determination is made as to whether there are enough available tokens within the class-specific bucket to route the network data…When there are not enough available tokens, the process flows to 1110. At 1110, a determination is made as to whether to re-allocate tokens. When all of tokens are removed from a logical bucket, or there are not enough remaining tokens to process the received data, additional tokens (e.g., tokens remaining in the physical bucket) may be allocated to the logical bucket, subject to the maximum allowable token allocation for the logical bucket. In some examples, once the maximum allowable token allocation for a logical bucket has been reached for the time period, no additional tokens may be allocated to that logical bucket…At 1204, the available token allocation for the class-specific bucket is determined. When all tokens are removed from a logical bucket, additional tokens (e.g., tokens remaining in the physical bucket) may be allocated to the logical bucket, subject to the maximum allowable token allocation for the logical bucket. Once the maximum allowable token allocation for a logical bucket has been reached for the first time period, no additional tokens may be allocated to that logical bucket. At 1206, a determination is made as to whether there are available tokens to re-allocate. When there are available tokens to re-allocate, the process 1200 flows to 1208. When there are not available tokens to re-allocate, the process 1200 flows to 1210. At 1208, tokens are re-allocated to the class-specific bucket. As discussed above, the flow control node 610 can re-allocate the number of tokens needed to process the received data, or a higher amount of tokens can be re-allocated.”).
Vankamamidi, Shah, and Hill are all considered to be analogous to the claimed invention because they are all in the same field of request processing and resource allocation using token pools. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute the process of allocating additional tokens from the shared token pool of Vankamamidi and Shah with the process of allocating additional tokens from the shared token pool wherein the number of additional tokens is larger than the number of tokens required for the I/O request as taught in Hill to arrive at the claimed invention. This simple substitution would have been reasonable and yielded predictable results under MPEP § 2143 as all references calculate a number of tokens to process a request and use token pools to allocate said calculated number of tokens to process the request.
As per claim 4, Vankamamidi, Shah, and Hill teach the method of claim 1. Vankamamidi teaches in response to completion of the host I/O request, returning the allocated tokens at least in part by: returning any allocated tokens to the shared token pool (¶ [0100], “When an IO completes, its tokens are added back to the pool. Based on observed latency, the token pool size may be increased or decreased. For example, the pools of tokens is adjusted based on whether the above-noted IO latency is acceptable or not.”). Shah teaches returning allocated tokens to the per-core token pool until a total number of tokens contained in the per-core target pool reaches a target quota for the per-core token pool; and after the total number of tokens contained in the per-core token pool reaches the target quota for the per-core token pool, returning any remaining allocated tokens to the shared token pool (¶ [0060], “In some embodiments, each control unit (CU) retains only the number of tokens of which the CU can make use. This number of “useful” tokens is determined based on CU utilization and instructions per second (IPS) values. The combination of utilization and IPS values determines whether granting a token to the CU would be useful. If the CU has excess tokens (tokens which the CU is not using), it may donate the excess tokens to the token pool, ensuring that no CU holds unnecessary tokens.” ¶ [0064]-[0065], “Some embodiments assign a default (base) amount of power to a frequency domain. Power tokens held by the control unit permit the frequency domain to increase power usage above the base by an increment up to that represented by the number of power tokens the control unit holds. Some embodiments assign the control unit a default number of power tokens, and assign the frequency domain a default amount of power. If the frequency domain uses less than the default amount of power (meaning the frequency domain has a power surplus), the control unit may pass to the token pool some or all of the power tokens held by the control unit…Subsequently, when the token pool interacts with other control units as it travels around the ring, the other control units (i) detect the starvation flag, (ii) limit themselves to an upper limit of power tokens that they can consume, and (iii) relinquish excess (surplus) power tokens to the token pool.”).
Refer to claim 1 for reason to combine.
As per claim 5, Vankamamidi, Shah, and Hill teach the method of claim 4. Shah teaches wherein each of the multiple per-core token pools has a separate target quota; and wherein initializing the shared token pool and the per-core token pools includes setting the target quota of each one of the per-core token pools to an initial value (¶ [0059]-[0061], “In some embodiments, each control unit (CU) retains only the number of tokens of which the CU can make use. This number of “useful” tokens is determined based on CU utilization and instructions per second (IPS) values. The combination of utilization and IPS values determines whether granting a token to the CU would be useful. If the CU has excess tokens (tokens which the CU is not using), it may donate the excess tokens to the token pool, ensuring that no CU holds unnecessary tokens.” ¶ [0064], “Some embodiments assign a default (base) amount of power to a frequency domain. Power tokens held by the control unit permit the frequency domain to increase power usage above the base by an increment up to that represented by the number of power tokens the control unit holds. Some embodiments assign the control unit a default number of power tokens, and assign the frequency domain a default amount of power.” See also para. 0066.).
Refer to claim 1 for reason to combine.
As per claim 6, Vankamamidi, Shah, and Hill teach the method of claim 5. Shah teaches periodically rebalancing the per-core token pools at least in part by: detecting whether a workload change has occurred for any of the processor cores; and in response to detecting that a workload change has occurred for one of the processor cores, changing a value of the target quota of the per-core token pool corresponding to that processor core to reflect the workload change (¶ [0048]-[0049], “Constrained by the total number of tokens for the CPU, power management program 300 distributes the tokens among the frequency domains based on the relative workloads of the frequency domains. Heavily loaded frequency domains, therefore, tend to possess more tokens, and consequently may operate at higher frequencies (consume more power), so as to perform the workload more quickly. The converse holds true for lightly loaded frequency domains. Processing proceeds at operation S255, where token pool 420, of power management program 300, interacts with first control module 308, of first frequency domain 306 of power management program 300. In connection with the interaction, token pool 420, receives starvation flag 318 from first control module 308. Starvation flag 318 is sometimes herein referred to as a “starvation token”, a “power request”, a “power allowance request”, or similar terms. In some embodiments, starvation flag 318 includes information indicating a magnitude of power allowance requested by first control module 308. Starvation flag 318 indicates that first control module 308, due to current workload, requests permission to consume more power so as to process the current workload (or backlog thereof) more quickly.” ¶ [0077], “In some embodiments, a starvation flag specifies a number of tokens requested by the associated control unit, called the “remaining to be filled” number (RTBF number). The token pool collects up to the RTBF number of power tokens, earmarks them for delivery to the requesting control unit, and delivers the power tokens to the requesting control unit in satisfaction of the starvation flag.”).
Refer to claim 1 for reason to combine.
As per claim 7, Vankamamidi, Shah, and Hill teach the method of claim 6. Vankamamidi teaches processing the I/O request (¶ [0102], “Referring again to the above-noted token pool, it may be partitioned across the cores that serve the IOs. The number of tokens required for an IO may be based on IO size and type. The intent is to make the “token cost” for an IO represent as close as possible the cost in system resources required to service the IO.”). Shah teaches in response to detecting that the per-core token pool corresponding to the identified processor core and the shared pool together do not contain a total number of tokens equal to at least the number of tokens required by the request, allocating tokens from another one of the per-core token pools (¶ [0080], “FIG. 4E is a schematic diagram showing relinquishment of power tokens, in response to starvation flag 405, in accordance with some embodiments of the present invention. As discussed above with respect to FIG. 4D, control unit 403 placed starvation flag 405 onto token pool 420. Token pool 420 subsequently moves around the ring topology, and interacts next with control unit 404. Control unit 404 has 50 surplus power tokens, and in response to detecting starvation flag 405 present in token pool 420, transfers the 50 surplus tokens to token pool 420. Token pool 420 earmarks the 50 tokens for delivery to control unit 403 in fulfillment of starvation flag 405.” See also para. 0102.).
Refer to claim 1 for reason to combine.
As per claim 8, it is a system claim comprising similar limitations to claim 1, so it is rejected for similar reasons. Vankamamidi teaches processing circuitry and a memory, wherein the processing circuitry includes multiple processor cores (¶ [0102], “Referring again to the above-noted token pool, it may be partitioned across the cores that serve the IOs.”) and non-volatile data storage drives (¶ [0052], “In some implementations, storage processor 100 may include front end cache memory system 122. Examples of front end cache memory system 122 may include but are not limited to a volatile, solid-state, cache memory system (e.g., a dynamic RAM cache memory system), a non-volatile, solid-state, cache memory system (e.g., a flash-based, cache memory system), and/or any of the above-noted storage devices.”).
As per claim 11, it is a system claim comprising similar limitations to claim 4, so it is rejected for similar reasons.
As per claim 12, it is a system claim comprising similar limitations to claim 5, so it is rejected for similar reasons.
As per claim 13, it is a system claim comprising similar limitations to claim 6, so it is rejected for similar reasons.
As per claim 14, it is a system claim comprising similar limitations to claim 7, so it is rejected for similar reasons.
As per claim 15, it is a product claim comprising similar limitations to claim 1, so it is rejected for similar reasons. Shah teaches a non-transitory computer readable medium having instructions stored thereon (¶ [0023], “The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.”).
As per claim 18, it is a product claim comprising similar limitations to claim 4, so it is rejected for similar reasons.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 4-8, 11-15, and 18 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Applicant has amended the claims with new limitations that change the scope of the claimed invention. Therefore, the amended claims necessitate new rejections, as addressed above. The amended claims are not allowable over prior art cited previously in the Non-Final Office Action along with an additional reference, necessitated by amendment, for reasons indicated above.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN ROBERT DAKITA EWALD whose telephone number is (703)756-1845. The examiner can normally be reached Monday-Friday: 9:00-5:30 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, Lewis Bullock can be reached at (571)272-3759. 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.
/J.D.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights