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. Claims 1- 18 are pending in this application. Information Disclosure Statement The IDS filed on 5/07/2024 has been considered. 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) FILLIN "Insert the claim numbers which are under rejection." \d "[ 1 ]" 1-18 are rejected under 35 U.S.C. 103 as being unpatentable over FILLIN "Insert the prior art relied upon." \d "[ 2 ]" 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) . 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 containing a total number of tokens equal to at least the number of tokens required by the request , allocating the number of tokens required by the request from the per-core token pool corresponding to the identified processor core and processing the request without accessing the shared token pool ( ¶ [0064], “ A control unit may authorize an associated frequency domain to use an amount of power up to that represented by the number of power tokens held by the control unit. 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. ” ¶ [0072], “ In some embodiments of the present invention, at each interaction with a control unit, token pool 420 may perform one or more of the following actions (without limitation): ( i ) pass token(s) to the control unit; (ii) receive token(s) from the control unit; (iii) receive a starvation flag from the control unit; (iv) return a power request token to the control unit; (v) exchange status information (unidirectionally, or bidirectionally) with the control unit; and/or (vi) take no action . ” Examiner Note: One of ordinary skill in the art would recognize that t aking no action indicates the per-core token pool/count has enough tokens to satisfy request processing requirements. ). Vankamamidi and Shah are considered to be analogous to the claimed invention because they are in the same field of task scheduling 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.). As per claim 2, Vankamamidi and Shah teach the method of claim 1. Vankamamidi teaches allocating tokens from the shared token pool and processing 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. ”). Shah teaches 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 tokens from the shared token pool and processing the request (¶ [0073], “ In particular, token pool 420 initially has 100 power tokens and control unit 401 has none. Token pool 420 transfers ten of the 100 power tokens to control unit 401. After the transfer, token pool 420 has 90 tokens and control unit 401 has 10. Consequently, control unit 401 allows the corresponding frequency domain (not shown) to increase power consumption by an increment not exceeding the power represented by the ten tokens. ” See also Fig. 4B.). As per claim 3, Vankamamidi and Sha teach the method of claim 2. Shah teaches wherein allocating tokens from the shared token pool comprises allocating tokens from the shared token pool in bulk, such that a total number of tokens allocated is larger than the number of tokens required by the host I/O request (¶ [0082]-[0083], “Once token pool 420 back around to control unit 403, token pool 420 transfers, to control unit 403, starvation flag 405 and the 50 surplus tokens contributed by control unit 404. Control unit 403, authorizes the associated frequency domain to increase operating frequency by an amount based on the 50 additional power tokens now in possession of control unit 403. The frequency domain subsequently processes workload more quickly at the expense of consuming more power, yet the total power used by all the frequency domain participants of the ring topology, in aggregate, remains within the established power budget.”). As per claim 4, Vankamamidi and Shah teach the method of claim 3. 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. ”). As per claim 5, Vankamamidi and Shah 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. ). As per claim 6, Vankamamidi and Shah 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. ” ). As per claim 7, Vankamamidi and Shah 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.). 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 9, it is a system claim comprising similar limitations to claim 2, so it is rejected for similar reasons. As per claim 10, it is a system claim comprising similar limitations to claim 3, so it is rejected for similar reasons. 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 1 2 , 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 16, it is a product claim comprising similar limitations to claim 2, so it is rejected for similar reasons. As per claim 17, it is a product claim comprising similar limitations to claim 3, so it is rejected for similar reasons. As per claim 18, it is a product claim comprising similar limitations to claim 4, so it is rejected for similar reasons. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. FILLIN "Enter the appropriate information" \* MERGEFORMAT Wang et al. (US Pub No. 2017/0192921 A1) and Zhuo et al. (US Pub. No. 2020/0133506 A1) teach maintaining token/credit pools used in determining whether or not a request can be processed . Any inquiry concerning this communication or earlier communications from the examiner should be directed to FILLIN "Examiner name" \* MERGEFORMAT JOHN ROBERT DAKITA EWALD whose telephone number is FILLIN "Phone number" \* MERGEFORMAT (703)756-1845 . The examiner can normally be reached FILLIN "Work Schedule?" \* MERGEFORMAT 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, FILLIN "SPE Name?" \* MERGEFORMAT Lewis Bullock can be reached at FILLIN "SPE Phone?" \* MERGEFORMAT (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