DETAILED ACTION
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 .
This Office Action is in response to amendment filed on 04/29/2026.
Claims 1-20 are pending.
Any objections and rejections not repeated below is withdrawn due to Applicant's amendment.
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on 05/27/2026 and 06/16/2026 were filed after the mailing date of the non-final Office action on 01/29/2026. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Response to Arguments
Applicant's arguments filed 04/29/2026 have been fully considered. Applicant argues in substance:
In particular, Check does not disclose or suggest that a scheduling period includes slack time, as required by claim 1. Check describes assigning time budgets to virtual functions within a time slice and enforcing those budgets by excluding requests when budgets are exhausted (see Check at paragraph [0005]). Check further describes that time budgets may not fill the time slice and that remaining cycles may be assigned as needed (see Check at paragraph [0020]), that operations may exceed estimated cycles and continue execution (see Check at paragraph [0023]), and that unused cycles may be reallocated among virtual functions (see Check at paragraph [0038]). However, none of these disclosures describes or suggests that the scheduling period itself includes a slack time. Rather, these disclosures describe dynamic execution behavior within a time slice, such as unused capacity, overruns, or reallocation of cycles, and do not disclose or suggest that the scheduling period includes slack time as required.
In contrast, claim 1 requires that the scheduling period "includes a slack time", which requires that slack time be part of the structure of the scheduling period itself, rather than arising incidentally during execution. The Office's interpretation that time exceeding a budget or unused cycles constitute slack time is not supported by Check. Even assuming, arguendo, that unused or excess cycles could be interpreted as some form of additional time, such behavior is not part of a defined scheduling period and therefore does not satisfy the claimed requirement that the scheduling period includes slack time. Check does not define any portion of the time slice as slack time, nor does it describe any additional interval included within the scheduling period for accommodating variance. Accordingly, Check fails to disclose or suggest the claimed feature of a scheduling period that includes slack time.
With regard to point (a), Examiner respectfully disagrees with Applicant that Check fails to suggest the claimed feature of a scheduling period that includes slack time. As Applicant’s claims do not disclose that the slack time included within the scheduling period must be “separated” or “isolated” from the time partitions given to the virtual functions, any unused or excess cycles from previous virtual functions’ executions can be interpreted as slack time that is reallocated to other virtual functions. Therefore, the claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
Konik does not cure this deficiency. The Office relies on Konik's paragraph [0044] disclosure of extending an expiration time of a virtual machine and interprets the difference between a previous expiration time and a new expiration time as slack time. This interpretation is not consistent with the claimed subject matter. Konik is directed to determining whether a virtual machine can complete a task before expiration, and if not, extending the expiration time, redirecting the task to another virtual machine, or requesting additional resources (see Konik at paragraphs [0042]-[0048]). The expiration time in Konik represents a termination boundary for execution of a virtual machine, not a scheduling period composed of time partitions. Extending the expiration time, therefore, changes the duration of the virtual machine's execution, not the structure of a scheduling period. Konik does not disclose any scheduling period that includes slack time, nor any interval within such a period that is reserved to accommodate variance in job submission behavior. Thus, Konik does not disclose or suggest the claimed slack time, and does not remedy the deficiencies of Check.
With regard to point (b), Examiner respectfully disagrees with Applicant that Konik fails to disclose the claimed feature of a scheduling period that includes slack time. As Applicant’s claims do not disclose that the slack time included within the scheduling period must be “separated” or “isolated” from the time partitions given to the virtual functions, any extensions of execution time can be interpreted as slack time. Therefore, the claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
Moreover, the Office has not established a sufficient rationale for combining Check and Konik. The Office asserts that it would have been obvious to modify Check in view of Konik to allow completion of tasks when time is exceeded. However, this rationale is directed to permitting tasks to continue execution beyond a time limit, which is not the claimed invention. Claim 1 requires a scheduling period that includes slack time for accommodating variances in cadence and job size, not merely allowing execution beyond an allocated time. Check addresses arbitration of shared resources among virtual functions (see Check at paragraph [0005]), while Konik addresses whether a task can be completed before expiration of a virtual machine (see Konik at paragraphs [0042]-[0044]). These references address different problems and operate under different frameworks. The Office has not articulated any reason why one of ordinary skill in the art would modify Check's time-slice arbitration framework to incorporate Konik's expiration-based mechanism in a manner that results in a scheduling period including slack time, as opposed to merely allowing execution beyond a time budget. Accordingly, the proposed combination is based on impermissible hindsight reconstruction.
…
Furthermore, claim 1 requires that the slack time allows for variances in at least one of cadence and job size. Neither Check nor Konik discloses or suggests this functional relationship. Check enforces time budgets and may reallocate cycles, but does not disclose accommodating variance in submission cadence or job size within a defined slack interval. Konik evaluates estimated completion time relative to expiration time, but does not address cadence or job size variance in the context of a scheduling period. Accordingly, even when considered together, Check and Konik fail to disclose or suggest the claimed arrangement in which slack time is included in a scheduling period for the purpose of accommodating variances in cadence and/or job size.
With regard to point (c), Examiner respectfully disagrees with Applicant there is insufficient rationale for combining Check and Konik. As Applicant’s claims do not disclose that the slack time included within the scheduling period must be “separated” or “isolated” from the time partitions given to the virtual functions, any unused or excess cycles from previous virtual functions’ executions can be interpreted as slack time that is reallocated to other virtual functions in Check. In addition, any extensions of execution time can be interpreted as slack time in Konik. Furthermore, Check also discloses variances in cadence and job size ([0028] “…In that case, the priority arbiters 130 may allow the virtual function 110 to send two requests of 500 bytes each or 100 requests of ten bytes each…”, Note: The requests are the jobs, the cadence is the number of requests (jobs) sent by the virtual function, and the size of the requests are in units of bytes in the referenced example). In combination, Check and Konik disclose an extension of time (slack time) to accommodate the job variances. In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971). Therefore, the claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
Additionally, the Office's interpretation of "cadence" is not consistent with the broadest reasonable interpretation of the term. While cadence may generally relate to frequency, frequency inherently requires a temporal component, i.e., events per unit time. Claim I recites "a cadence at which each virtual function submits jobs", which requires a rate or pattern of submission over time. A mere number of requests, without any temporal context, does not define such a cadence. The same number of requests may be submitted over different time intervals, resulting in different cadences. Thus, interpreting cadence as merely a number of requests eliminates the temporal aspect inherent in the claim language and renders the phrase "at which" superfluous. To the extent the Office asserts that "cadence is not limited to the specification", the Applicant notes that the broadest reasonable interpretation must be determined in light of the specification and not in a manner divorced from how the term is understood in the art (see MPEP § 2111.01). The Office's interpretation, which reduces cadence to a mere count of requests without any temporal component, is, therefore, not reasonable. Accordingly, Check's disclosure of a number of requests or credits (see Check at paragraph [0028]) does not disclose or suggest the claimed cadence.
With regard to point (d), Examiner respectfully disagrees with Applicant in respect to the BRI of “cadence”. As Applicant stated in arguments, BRI is used to determine the meaning of interpretation of the term “cadence”. As cadence has a plain meaning similar to “frequency”, the number of requests submitted by a virtual function for its given time slice is interpreted by the Examiner to be the cadence (as stated in prior art Check). In addition, Examiner has interpreted expected cadence to be the number of requests which is further indicated by the number of credits given to a virtual function for its given time slice. Thus, Examiner’s BRI is consistent with the plain meaning of the term, “cadence”. Argument has not been found to be persuasive.
For example, with respect to dependent claims 2, 10, and 18 the Office asserts that Check discloses scheduling based on an expected cadence defined by a number of requests or credits. However, as discussed above, Check does not disclose or suggest determining a cadence as claimed, nor determining whether a plurality of jobs exceeds an expected cadence. Further, Check merely enforces limits by excluding requests when credits are exhausted (see Check at paragraphs [0031] and [0041]) and does not disclose scheduling a first virtual function after a second virtual function based on a determination that the first virtual function exceeds an expected cadence while the second does not. Accordingly, claims 2, 10, and 18 are novel and non-obvious in view of Check and Konik.
With regard to point (e), Examiner respectfully disagrees with Applicant in respect to the BRI of “cadence”. As Applicant stated in arguments, BRI is used to determine the meaning of interpretation of the term “cadence”. As cadence has a plain meaning similar to “frequency”, the number of requests submitted by a virtual function for its given time slice is interpreted by the Examiner to be the cadence (as stated in prior art Check). In addition, Examiner has interpreted expected cadence to be the number of requests which is further indicated by the number of credits given to a virtual function for its given time slice. Thus, Examiner’s BRI is consistent with the plain meaning of the term, “cadence”. In addition, Check discloses scheduling a first virtual function after a second virtual function based on a determination that the first virtual function exceeds an expected cadence while the second does not as all other virtual functions (not exceeding their expected cadences) will process their requests before the additional requests of the virtual function that exceeded its expected cadence. Therefore, the claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
With respect to dependent claims 3, 11, and 19, the Office equates a size budget with an expected job size. However, Check discloses enforcing size limits (see Check at paragraphs [0027] and [0029]) and does not disclose or suggest comparing whether submitted jobs exceed an expected job size and scheduling virtual functions based on such a comparison. Enforcement of a limit is not equivalent to scheduling decisions based on exceeding or not exceeding an expected job size. Accordingly, claims 3, 11, and 19 are novel and non-obvious in view of Check and Konik.
With regard to point (f), Examiner respectfully disagrees with Applicant. In Check, when a virtual function exceeds its size budget, all its requests (jobs) afterwards are disallowed until the next time slice (scheduling period), and therefore, all other virtual functions that do not exceed their size budgets will still be allowed to process requests before the disallowed requests of the virtual function that exceeded its size budget. Therefore, the claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
With respect to dependent claims 5, 13, and 20 the Office asserts that Check's request queue corresponds to a first level list and that requests not added to the queue correspond to a second level list. However, Check does not disclose or suggest maintaining multiple lists that classify virtual functions based on compliance with expected cadence and job size. Rather, Check merely filters requests based on time budgets and credits (see Check at paragraph [0041]). The claimed first and second level lists require classification of virtual functions based on behavior, which is not disclosed or suggested by Check. Accordingly, claims 5, 13, and 20 are novel and non-obvious in view of Check and Konik.
With regard to point (g), Examiner respectfully disagrees with Applicant. In Check, requests (jobs) of virtual functions that exceed their expected cadences (number of requests indicated by the number of credits given to the virtual function for each time slice (scheduling period)) and size budgets (expected job sizes) are not added to the request queue (first level list) for processing. Therefore, this condition above also separates the other requests into a group (second level list) to the request queue for processing. Thus, the requests (jobs) of virtual functions are classified into two lists based on the condition (behavior) above. Therefore, the claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
Kruglick does not disclose or suggest assigning a credit based on a determination that a size of jobs submitted by a virtual function is smaller than an expected job size. Rather, Kruglick paragraph [0029] describes a different circumstance altogether, namely, a particular virtual machine entering a wait state and receiving a processing credit corresponding to the remaining time allotted for that virtual machine in the modified dispatch cycle. Thus, the triggering condition in Kruglick is entry into a wait state with remaining allotted time, not that the size of submitted jobs is smaller than an expected job size. The claim requires a comparison between the size of submitted jobs and an expected job size, and assigns the claimed credit based on that comparison. Kruglick contains no disclosure of expected job size, no comparison of job size to an expected job size, and no disclosure that a credit is assigned because jobs submitted by a virtual function are smaller than an expected job size. Accordingly, Kruglick does not disclose the basis for the claimed job-size credit.
Kruglick also does not disclose or suggest carrying the claimed credit forward to a subsequent scheduling period immediately following the scheduling period during which the credit is assigned. To the contrary, Kruglick paragraph [0029] states that, prior to completion of the modified dispatch cycle, the virtual machine manager may pass access back to the waiting virtual machine for an amount of time corresponding to the processing credit. Thus, Kruglick teaches use of the credit before the end of the current modified dispatch cycle, not carry-forward for use in the immediately following scheduling period. The Office's assertion that the credit is used "at the beginning of the next modified dispatch cycle" is not supported by the cited passage. Paragraph [0029] of Kruglick states the opposite, namely, that the credit is used prior to completion of the current modified dispatch cycle. Therefore, Kruglick fails to disclose the recited carry-forward requirement of claim 4.
Further, the Office's equation of Kruglick's "remaining time allotted" with the claimed "expected job size" is unsupported. Remaining allotted time in a dispatch cycle is a time allocation concept. Expected job size, as recited in claim 4, is a job-size concept. These are not the same. Kruglick' s processing credit is tied to unused remaining time resulting from a wait state. Claim 4, by contrast, requires a job size credit tied to the size of submitted jobs being smaller than an expected job size. The Office's interpretation effectively rewrites the claim by substituting remaining allotted time for expected job size, even though Kruglick contains no disclosure equating the two. Such a mapping is not supported by the reference itself.
The Office also does not provide a sufficient reason why one of ordinary skill in the art would have modified Check and Konik in view of Kruglick to arrive at the claimed subject matter. The Office asserts generally that the proposed combination would increase processing speed in a virtualized environment, citing Kruglick paragraph [0030]. However, Kruglick's discussion of increased processing speed is tied to reducing DVFS switches by reordering virtual machines based on DVFS states. See Kruglick at paragraphs [0015], [0024]-[0030], and [0035][0037]. That is a different concept from assigning a job size credit when submitted job size is smaller than an expected job size and carrying that credit forward to the immediately following scheduling period. The Office's rationale is therefore too general and does not explain why one of ordinary skill would specifically modify the Check/Konik framework to adopt Kruglick's wait-state processing credit mechanism in a manner that results in the claimed job-size-based, next-period carry-forward credit. As such, the proposed combination is based on hindsight rather than a teaching or suggestion in the cited references.
With regard to point (h), Examiner respectfully disagrees with Applicant. In Kruglick, processing credit (interpreted as the job size credit) is given when the virtual machine is idle with remaining time still allocated. The remaining time is interpreted to be proportional to the expected job size (full time given to execute) subtracted from the size of jobs (actual time utilized for execution) as different job sizes execute for different amounts of time (the comparison is the subtraction to determine if there is remaining time). The remaining time is given to the virtual machine in the form of processing credits which are utilized at the beginning of the next modified dispatch cycle (next scheduling period). Although, Kruglick [0029] states that the credit is used prior to completion of the current modified dispatch cycle, there is no technical difference between using the credits before the end or at the start of a dispatch cycle as both situations carry forward credits. Furthermore, as Kruglick’s motivation to combine is general, Examiner has further included an additional motivation from Kruglick. Kruglick’s motivation to combine being [0023] “As discussed previously, virtual machine manager 120 may adjust a size of blocks of core time assigned to respective virtual machines 105 and assigned to virtual machine manager 120 in dispatch cycle 124. Adjusting the size of the blocks may help ensure that processing needs of each virtual machine 105 are satisfied and that service level guarantees are met…”. Therefore, the claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
For example, regarding claim 7, the Office relies on Bert to disclose scheduling a first virtual function after a second virtual function based on a comparison of a number of jobs submitted across a plurality of scheduling periods. However, Bert does not disclose or suggest this feature. Bert describes assigning priorities and processing commands in batches based on user-defined parameters, such as processing a fixed number of commands for one virtual machine before switching to another (see Bert at paragraph [0034]). This disclosure relates to static priority-based scheduling and batch processing, and does not involve determining a number of jobs submitted by a virtual function over a plurality of scheduling periods, nor comparing such numbers between virtual functions. Claim 7, by contrast, recites scheduling based on a comparison of a first number of jobs submitted by a first virtual function and a second number of jobs submitted by a second virtual function across multiple scheduling periods. Bert provides no disclosure of tracking or comparing job submissions over multiple scheduling periods, and does not disclose dynamically scheduling virtual functions based on such a comparison.
Moreover, the Office's assertion that a virtual function with more commands can be processed after another virtual function is not supported by Bert. Bert teaches that scheduling order is determined by user-assigned priority and batch size, not by observed submission behavior over time. Accordingly, Bert does not disclose or suggest the claimed scheduling based on comparative job submission counts across multiple scheduling periods.
Further, the Office has not articulated a sufficient rationale for combining Check and Konik with Bert to arrive at the claimed subject matter. Bert's disclosure is directed to static priority and batch-based execution, which addresses a different problem than the claimed scheduling based on job submission behavior across multiple scheduling periods. The Office's rationale of generally processing commands before another virtual function does not explain why one of ordinary skill in the art would modify the Check/Konik framework to incorporate Bert in a manner that results in the claimed behavior. Therefore, the proposed combination is based on impermissible hindsight.
With regard to point (i), Examiner respectfully disagrees with Applicant. Applicant’s claims do not disclose a comparison of a number of jobs submitted. Applicant discloses “if a first number of a first plurality of jobs submitted by the first virtual function within the plurality of scheduling periods is more than a second number of a second plurality of jobs submitted”. Bert discloses first number of a first plurality of jobs submitted by the first virtual function (first priority) compared to the second number of a second plurality of jobs submitted by the second virtual function (second priority), wherein the comparison is made for determining priority of each batch (scheduling period is interpreted to comprise a combination of a batch from the first virtual function and a batch from the second virtual function). Furthermore, as Bert’s motivation to combine is general, Examiner has further included an additional motivation from Bert. Bert’s motivation to combine being Bert [0034] “…In this manner, the SR-IOV firmware will process VF1 commands faster than VF2 commands.”. Therefore, the claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
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-3, 5-6, 8-11, 13-14, and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Check et al. Pub. No. US 2016/0147687 Al (hereafter Check) in view of Konik et al. Pub. No. US 2014/0173614 Al (hereafter Konik).
Regarding claim 1, Check teaches a method comprising: allocating a plurality of time partitions within a scheduling period to a plurality of virtual functions for execution of jobs at a parallel processor … in at least one of a cadence at which each virtual function submits jobs for execution and a size of jobs submitted for execution ([0005] “…assigning a time budget to each of a plurality of virtual functions in an SRIOV environment … within a time slice. A plurality of requests issued by the plurality of virtual functions are selected by a computer processor…”, [0028] “…In that case, the priority arbiters 130 may allow the virtual function 110 to send two requests of 500 bytes each or 100 requests of ten bytes each…”, Note: The time budget is the time partition, the time slice is the scheduling period, the requests are the jobs, the cadence is the number of requests (jobs) sent by the virtual function, and the size of the requests are in units of bytes in the referenced example); and preventing execution of any jobs that exceed an allocated time partition for a virtual function of the plurality of virtual functions ([0041] “…For example, a priority arbiter 130 may opt not to add to its request queue those requests that come from virtual functions 110 that have used up their time budgets or have used up their credits within the current time slice. In this manner, the time budgets and credits may be enforced.”, Note: The time budget is the time partition, and the requests are the jobs).
It is further noted that although Check fails to directly teach wherein the scheduling period includes a slack time to allow for variances, Check implies a slack time within a time slice ([0020] “…time budgets needs not fill the time slice to capacity, and remaining cycles may be assigned to the virtual functions 110 as needed during a time slice.”, [0023] “…a virtual function 110 may request an operation, which may be estimated to take five thousand cycles, when that virtual function 110 has six thousand cycles remaining in its time budget. An engine 120 may start executing the operation in a current time cycle, and the operation may end up taking 20,000 cycles. The operation may be allowed to run to completion in the current time slice, but this takes the virtual function 110 significantly over its time budget…”, [0034] “…the arbitration system 100 may allow the first virtual function 110 to complete its requested work, so long as the other customers get what they paid for…”, [0038] “…Thus, the arbitration system 100 may reallot a virtual function's unused cycles of a time slice. This reallotment may occur in various ways … the unused cycles may be divided equally or near-equally among the remaining virtual functions 110 … In the case of reallotment, even virtual functions 110 with no more credits remaining in the current time slice may be allowed one or more additional sessions with the engines 120 if allotted additional cycles in the current time slice.”, Note: Time that virtual functions exceed their given time slices is the slack time).
In analogous art Konik teaches wherein the scheduling period includes a slack time to allow for variances ([0044] “If the determination at block 425 is true, then an automatic extension of the expiration time is allowed, so control continues to block 430 where the first virtual machine 150 changes the expiration time 314 by an adjustment amount to a new expiration time to be sufficiently further in the future, so as to allow the first virtual machine 150 to complete the task before the new expiration time.”, Note: A virtual machine similar to a virtual function allows extensions to its given expiration time, and the new expiration time subtracted from the previous expiration time of the virtual machine is interpreted to be the slack time).
It would have been obvious to a person having ordinary skill in the art prior to the
effective filing date of the claimed invention to have modified Check to incorporate the teachings of Konik to complete tasks even when a given time has exceeded (Konik [0052] “In this way, tasks may be completed even though the execution of virtual machines automatically expire.”).
Regarding claim 2, Check and Konik teach the method of claim 1, and Check further teaches wherein preventing execution comprises: scheduling a first virtual function to execute a first plurality of jobs after a second virtual function in response to submission of the first plurality of jobs exceeding an expected cadence and submission of a second plurality of jobs by the second virtual function not exceeding the expected cadence ([0031] “Each credit may correspond to the quantity of times a virtual function 110 may access the engines 120. More specifically, each time a request issued by a virtual function 110 is given processing attention by an engine 120 or a processing session with an engine 120, one credit is used up…”, [0041] “…For example, a priority arbiter 130 may opt not to add to its request queue those requests that come from virtual functions 110 that have used up their time budgets or have used up their credits within the current time slice. In this manner, the time budgets and credits may be enforced.”, Note: The requests are the jobs, and when a virtual function exceeds its expected cadence (number of requests indicated by the number of credits given to the virtual function for each time slice (scheduling period)), all its requests (jobs) afterwards are not added to the request queue, and therefore, all other virtual functions that do not exceed their expected cadences will process their requests before the requests of the virtual function that exceeded its expected cadence).
Regarding claim 3, Check and Konik teach the method of claim 1, and Check further teaches further comprising: scheduling a first virtual function to execute a first plurality of jobs after a second virtual function in response to the first plurality of jobs exceeding an expected job size and a second plurality of jobs submitted by the second virtual function not exceeding the expected job size ([0027] “…In other words, each virtual function 110 may be assigned a size budget, indicating the amount of data allowed to be consumed by requests from that virtual function 110 within a single time slice.”, [0029] “…if a virtual function 110 has 100 bytes left in its time budget and tries to make a request of 5000 bytes, the priority arbiters 130 may allow this and deliver that request to the engines 120, but may then disallow future requests from that virtual function 110 within the current time slice.”, Note: The size budget is the expected job size. When a virtual function exceeds its size budget, all its requests (jobs) afterwards are disallowed until the next time slice (scheduling period), and therefore, all other virtual functions that do not exceed their size budgets will still be allowed to process requests before the disallowed requests of the virtual function that exceeded its size budget).
Regarding claim 5, Check and Konik teach the method of claim 1, and Check further teaches further comprising: maintaining a first level list and a second level list, the first level list including a first virtual function submitting a first plurality of jobs that are within an expected cadence and that do not take longer to execute than an expected job size, and the second level list including a second virtual function not included on the first level list ([0041] “Each priority arbiter 130 may place requests from the virtual functions 110 on its queue in a selective manner, and these selections may be based on the time budgets and credits of the virtual functions 110. For example, a priority arbiter 130 may opt not to add to its request queue those requests that come from virtual functions 110 that have used up their time budgets or have used up their credits within the current time slice. In this manner, the time budgets and credits may be enforced.”, [0031] “Each credit may correspond to the quantity of times a virtual function 110 may access the engines 120. More specifically, each time a request issued by a virtual function 110 is given processing attention by an engine 120 or a processing session with an engine 120, one credit is used up…”, [0029] “…if a virtual function 110 has 100 bytes left in its time budget and tries to make a request of 5000 bytes, the priority arbiters 130 may allow this and deliver that request to the engines 120, but may then disallow future requests from that virtual function 110 within the current time slice.”, Note: Requests (jobs) of virtual functions that exceed their expected cadences (number of requests indicated by the number of credits given to the virtual function for each time slice (scheduling period)) and size budgets (expected job sizes) are not added to the request queue (first level list) for processing. Therefore, this check above also separates these other requests into a group (second level list) that does not comply with the condition above); and scheduling the first plurality of jobs for a virtual function in the first level list prior to scheduling a second plurality of jobs for a virtual function in the second level list ([0040] “…When a request reaches the top, or front, of the queue, the priority arbiter 130 may deliver that request to the engine 120.”, [0041] “…For example, a priority arbiter 130 may opt not to add to its request queue those requests that come from virtual functions 110 that have used up their time budgets or have used up their credits within the current time slice. In this manner, the time budgets and credits may be enforced.”, Note: All requests (jobs) not added to the request queue (first level list) are not processed in the current time slice (scheduling period), and therefore, all other requests from virtual functions that comply with the condition will be processed before those requests from virtual functions that do not comply).
Regarding claim 6, Check and Konik teach the method of claim 5, and Check further teaches further comprising: bypassing scheduling the second plurality of jobs for the virtual function in the second level list within a current scheduling period ([0041] “…For example, a priority arbiter 130 may opt not to add to its request queue those requests that come from virtual functions 110 that have used up their time budgets or have used up their credits within the current time slice. In this manner, the time budgets and credits may be enforced.”, Note: All requests (jobs) not added to the request queue (first level list) are not processed and therefore bypass scheduling in the time slice (scheduling period)).
Regarding claim 8, Check and Konik teach the method of claim 1, and Check further teaches further comprising: allowing a virtual function with remaining time within the allocated time partition and not having completed a job within the scheduling period to submit the job if the parallel processor is idle ([0038] In some instances, it may be the case that one or more of the virtual functions 110 complete whatever work they need done prior to using their full time budget in the current time slice. In that case, one or more cycles would remain unused if not reassigned, and unused cycles may be wasteful when other virtual functions 110 have pending unfinished requests. Thus, the arbitration system 100 may reallot a virtual function's unused cycles of a time slice … the unused cycles may be divided equally or near-equally among the remaining virtual functions 110…”, Note: The time budget is the time partition, and the time slice is the scheduling period).
Regarding claim 9, Check further teaches a processing system, comprising: a parallel processor; and scheduler module circuitry configured to ([0055] “The present invention may be a system, a method, and/or a computer program product. 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.”, [0047] “…The processor 405 may be any custom made or commercially available processor…”, [0056] “…A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se…”). The other limitations are substantially the same as those of claim 1. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 10, it is a machine claim whose limitations are substantially the same as those of claim 2. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 11, it is a machine claim whose limitations are substantially the same as those of claim 3. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 13, it is a machine claim whose limitations are substantially the same as those of claim 5. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 14, it is a machine claim whose limitations are substantially the same as those of claim 6. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 16, it is a machine claim whose limitations are substantially the same as those of claim 8. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 17, Check further teaches a server, comprising: a parallel processor configured to … scheduler module circuitry configured to ([0055] “The present invention may be a system, a method, and/or a computer program product. 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.”, [0047] “…The processor 405 may be any custom made or commercially available processor…”, [0056] “…A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se…”). The other limitations are substantially the same as those of claim 1. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 18, it is an article of manufacture claim whose limitations are substantially the same as those of claim 2. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 19, it is an article of manufacture claim whose limitations are substantially the same as those of claim 3. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 20, it is an article of manufacture claim whose limitations are substantially the same as those of claim 5. Accordingly, it is rejected for substantially the same reasons.
Claims 4 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Check et al. Pub. No. US 2016/0147687 Al (hereafter Check) in view of Konik et al. Pub. No. US 2014/0173614 Al (hereafter Konik) as applied to claims 1-3, 5-6, 8-11, 13-14, and 16-20 above, and further in view of Kruglick Pub. No. US 2015/0046923 Al.
Regarding claim 4, Check and Konik teach the method of claim 1.
Check and Konik fail to teach further comprising: assigning a job size credit to a first virtual function if a size of jobs submitted by the first virtual function is smaller than an expected job size, wherein the job size credit is carried forward to a subsequent scheduling period immediately following the scheduling period during which the job size credit is assigned for use by the first virtual function in the subsequent scheduling period.
In analogous art Kruglick teaches further comprising: assigning a job size credit to a first virtual function if a size of jobs submitted by the first virtual function is smaller than an expected job size, wherein the job size credit is carried forward to a subsequent scheduling period immediately following the scheduling period during which the job size credit is assigned for use by the first virtual function in the subsequent scheduling period ([0029] “During execution of modified dispatch cycle 130, a particular virtual machine 105 may enter a wait state. A wait state may be, for example, a state in which virtual machine 105 remains idle until an input is received. When a virtual machine 105 enters a wait state, virtual machine manager 120 may be configured to cause an exit from waiting virtual machine 105 to virtual machine manager 120. Virtual machine manager 120 may pass access to core 104 to the next consecutive virtual machine 105 of modified dispatch cycle 130. Waiting virtual machine 105 may receive a processing credit corresponding to the remaining time allotted for the waiting virtual machine in modified dispatch cycle 130. Prior to the completion of modified dispatch cycle 130, virtual machine manager 120 may pass access to core 104 back to waiting virtual machine 105 for an amount of time corresponding to the processing credit.”, Note: A virtual machine similar to a virtual function is allocated execution time, processing credit is interpreted as the job size credit which is given when the virtual machine is idle with remaining time still allocated, remaining time is interpreted to be proportional to the expected job size (full time given to execute) subtracted from the size of jobs (actual time utilized for execution) as different job sizes execute for different amounts of time (the comparison is the subtraction to determine if there is remaining time), and remaining time is given to the virtual machine in the form of processing credits which are utilized at the beginning of the next modified dispatch cycle (next scheduling period)).
It would have been obvious to a person having ordinary skill in the art prior to the
effective filing date of the claimed invention to have modified Check and Konik to incorporate the teachings of Kruglick to ensure processing needs of each virtual machine are satisfied and that service level guarantees are met (Kruglick [0023] “As discussed previously, virtual machine manager 120 may adjust a size of blocks of core time assigned to respective virtual machines 105 and assigned to virtual machine manager 120 in dispatch cycle 124. Adjusting the size of the blocks may help ensure that processing needs of each virtual machine 105 are satisfied and that service level guarantees are met…”).
Regarding claim 12, it is a machine claim whose limitations are substantially the same as those of claim 4. Accordingly, it is rejected for substantially the same reasons.
Claims 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Check et al. Pub. No. US 2016/0147687 Al (hereafter Check) in view of Konik et al. Pub. No. US 2014/0173614 Al (hereafter Konik) as applied to claims 1-3, 5-6, 8-11, 13-14, and 16-20 above, and further in view of Bert et al. Pub. No. US 2014/0229941 Al (hereafter Bert).
Regarding claim 7, Check and Konik teach the method of claim 1, and Check further teaches wherein the scheduling period is a first scheduling period of a plurality of scheduling periods, the method further comprising ([0019] “…The execution time of the engines may thus be made up of multiple time slices, one after the other…”, Note: The time slices are the scheduling periods).
Check and Konik fail to teach scheduling a first virtual function after a
second virtual function if a first number of a first plurality of jobs submitted by the first virtual function within the plurality of scheduling periods is more than a second number of a second plurality of jobs submitted by the second virtual function within the plurality of scheduling periods.
In analogous art Bert teaches scheduling a first virtual function
after a second virtual function if a first number of a first plurality of jobs submitted by the first virtual function within the plurality of scheduling periods is more than a second number of a second plurality of jobs submitted by the second virtual function within the plurality of scheduling periods ([0034] “…A user
may want to give a higher priority to a particular virtual function, so that the particular virtual function will be the first virtual function to process commands … For example, if VMl (virtual machine 1) has 256 maximum process commands and VM2 has 128 maximum process commands, the user can set a first number of process commands (e.g., 16 process commands) for VF1, and a second number of process commands (e.g., 8 commands) for VF2. Also, in this example, VMl has priority over VM2, so VMl will pull 16 process commands from VF1 and then priority shifts to VF2 to process 8 process commands. Then, priority will shift back to VF1 to process its next 16 process commands…”, Note: A virtual function with more commands (jobs) can be processed after another virtual function that has less commands when a user gives that virtual function with less commands a higher priority to process).
It would have been obvious to a person having ordinary skill in the art prior to the
effective filing date of the claimed invention to have modified Check and Konik to incorporate the teachings of Bert to process commands of a particular virtual function faster than another virtual function (Bert [0034] “…In this manner, the SR-IOV firmware will process VF1 commands faster than VF2 commands.”).
Regarding claim 15, it is a machine claim whose limitations are substantially the same as those of claim 7. Accordingly, it is rejected for substantially the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. In particular, US 20140245300 A1 is cited because it discloses allocating credits to virtual functions. In addition, US 9491112 B1 is cited because it discloses accumulating unused credits in a resource credit balance for use in other time intervals.
THIS ACTION IS MADE FINAL. 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.
Examiner respectfully requests, in response to this Office action, support be
shown for language added to any original claims on amendment and any new claims.
That is, indicate support for newly added claim language by specifically pointing to
page(s) and line number(s) in the specification and/or drawing figure(s). This will assist
Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 CFR 1.111 (c).
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUSTIN CHE-CHUN TONG whose telephone number is (703)756-1737. The examiner can normally be reached Monday-Thursday: 7:30 AM to 5:00 PM EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y Blair can be reached on (571)270-1014. 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.C.T./Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights