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 .
CLAIM INTERPRETATION
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
In claim 1, “a hardware engine configured to perform a specific task on the storage device using operational power provided by the storage device”.
In claim 9, “a Global Address Table (GAT) Delta Scan and Eviction (GDSE) hardware engine configured to perform a logical-to-physical flow of search, eviction, and consolidation of logical-to-physical entries”.
In claim 13, “a hardware engine configured to perform a specific task within a given time unit”.
In claim 20, “a hardware engine configured to perform a specific task within a given time unit using operational power provided by the storage device”.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. In particular:
In claim 1, “a hardware engine configured to perform a specific task on the storage device using operational power provided by the storage device” is interpreted to cover a module/processor of a controller [see Figs. 1 and 9] [0021] [0025] [0043], which may be a processor configured to execute software instructions stored on a memory device, or any other combination of hardware and software [0035]. Accordingly, the hardware engine is understood to be computer-implemented and therefore requires algorithm for performing the claimed function [MPEP 2181(II)(B)]. However, a review of the specification yields only a repetition of the function (i.e., 75 recitations of “task” throughout the specification), or only yields an example of specific tasks (“process videos”, “process the video frames” [0027], or “search”, “eviction”, or “consolidation” of L2P entries” [0029]) which may be performed, and not a sequence of steps for performing those tasks, and therefore is not a “sufficient disclosure for an algorithm which, by definition, must contain a sequence of steps.” [MPEP 2181(II)(B) -¶12]. Accordingly, a sufficient algorithm for performing the claimed function was not found.
In claim 9, “a Global Address Table (GAT) Delta Scan and Eviction (GDSE) hardware engine configured to perform a logical-to-physical flow of search, eviction, and consolidation of logical-to-physical entries”, is interpreted to cover a module/processor of a controller [see Figs. 1 and 9] [0021] [0025] [0043], which may be a processor configured to execute software instructions stored on a memory device, or any other combination of hardware and software [0035]. Accordingly, the GDSE is understood to be computer-implemented, and therefore requires an algorithm for performing the claimed functions [MPEP 2181(II)(B)]. However, a review of the specification yields only a repetition of the functions (i.e., “search”, “eviction”, or “consolidation” of L2P entries [0029]) which may be performed, and not a sequence of steps for performing those functions, and therefore is not a “sufficient disclosure for an algorithm which, by definition, must contain a sequence of steps.” [MPEP 2181(II)(B) -¶12]. Accordingly, a sufficient algorithm for performing the claimed function was not found.
In claim 13, “a hardware engine configured to perform a specific task within a given time unit” is interpreted analogously to the analogous limitation from claim 1.
In claim 20, “a hardware engine configured to perform a specific task within a given time unit using operational power provided by the storage device” is interpreted analogously to the analogous limitations from claims 1 and 13.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Objections
Claim 20 is objected to because of the following informalities:
Claim 20 recites, “a hardware engine” after previously reciting “the hardware engine”. Accordingly, the recitation of “a hardware engine” after the recitation of “the hardware engine” should be amended to recite “the hardware engine”.
Appropriate correction is required.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Regarding claims 1, 9, 13 and 20:
"To satisfy the definiteness requirement under 35 U.S.C. 112(b) or 35 U.S.C. 112, second paragraph, the written description must clearly link or associate the corresponding structure, material, or acts to the claimed function. Telcordia Techs., Inc. v. Cisco Systems, Inc., 612 F.3d 1365, 1376, 95 USPQ2d 1673, 1682 (Fed. Cir. 2010). A rejection under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph is appropriate if the written description fails to link or associate the disclosed structure, material, or acts to the claimed function, or if there is no disclosure (or insufficient disclosure) of structure, material, or acts for performing the claimed function. Donaldson, 16 F.3d at 1195, 29 USPQ2d at 1850." [MPEP 2181(III), ¶1]. The claims in the instant application lack a clearly linked structure for performing the claimed functions identified in limitations (a-d) of claims 1, 9, 13 and 20 in the claim interpretation section above and interpreted under 35 U.S.C. §112(f) because the written description does not disclose a sufficient algorithm for performing the claimed function. Accordingly, the claims are indefinite [MPEP 2181(II)(B)-(II)(C)]. "For a computer-implemented 35 U.S.C. 112(f) claim limitation, the specification must disclose an algorithm for performing the claimed specific computer function, or else the claim is indefinite under 35 U.S.C. 112(b)." [MPEP 2181(II)(B) - ¶1].
Regarding claims 1 and 13:
The discussion is based on illustrative claim 1 but applies analogously to claim 13.
Claim 1 recites, “to compare an efficiency of the hardware engine in performing the specific task within a given time unit against the operational power”. However, it is unclear what constitutes the recited, “efficiency”, and how an efficiency is to be compared against the operational power and what result or criterion is produced by that comparison. The specification and dependent claims appear to further confuse the meaning for the recited efficiency by making it dependent on a comparison to a threshold associated with a QoS, a monitored available resource, or a monitored power state, each of which do not define a level of efficiency or provide a clear connection to how one would determine an efficiency based on the named factor. Applicant’s arguments reinforce this confusion as Applicant appears to assert that these metrics readily disclose how one would determine an efficiency, despite the fact that the causal relationship between the claimed metrics and “efficiency” is not disclosed in the claims or the specification. This ambiguity is further confused by the fact that two cases within the claims that affect whether the controller or hardware engine is used to perform the specific task is based on determinations of whether the controller “can” or “cannot” execute the specific task within the given time unit with a given level of efficiency regardless of the comparison against the operational power.
Regarding claim 6:
Claim 6 is indefinite because the conditions recited in claim 6 cannot be resolved with the conditions recited in claim 1. For example, what should occur if the storage device is in the low power mode or first thermal state, but the controller cannot execute the specific task within the given time unit within the given level of efficiency. Alternatively, what happens if the storage device is in the active power mode or second thermal state, but the controller can execute the specific task within the given time unit within the given level of efficiency. In these cases, the limitations of claim 1 and claim 6 are mutually exclusive and cannot be resolved (for example, they require the hardware engine to be switched off and invoked, or they required the hardware engine and the controller to execute the specific task, despite the preamble requiring “selective execution”). Accordingly, the scope of the claim cannot be determined and the claim is indefinite.
Regarding claim 7:
Claim 7 is unclear for reasons analogous to claim 6 because the conditions cannot be resolved, such as whether the hardware engine is invoked or not depending on whether the controller can or cannot execute the specific task as recited in claim 1 in combination with whether the storage device is using the first or second protocol as recited in claim 7). Accordingly, the scope of the claim cannot be determined and the claim is indefinite.
Regarding claim 8:
Claim 8 is unclear for reasons analogous to claims 6 and 7 because the conditions cannot be resolved, such as whether the hardware engine is invoked or not depending on whether the controller can or cannot execute the specific task as recited in claim 1 in combination with whether the storage device is processing I/O with a first or second protocol as recited in claim 8. Accordingly, the scope of the claim cannot be determined and the claim is indefinite.
Regarding claim 10:
Claim 10 recites, “to compare the efficiency of the hardware engine in performing the specific task in the given time unit against the operational power, the controller is configured to evaluate an amount of random workload and a rate of accumulation of logical-to-physical delta entries within a given time window to determine if a workload threshold is reached”. However, it is unclear how the recited evaluation of an amount of random workload and a rate of accumulation of delta entries, for the purposes of determining whether a workload threshold has been reached, constitutes or results in the recited comparison of hardware engine efficiency against operational power. In particular, the claim does not define what relationship exists between the workload threshold and either the recited efficiency or operational power, or how determining that the workload threshold has been reached produces a comparison between those quantities. Therefore, it is unclear what is required by the newly recited limitations as it could either be read as meaning that the efficiency comparison to the operating power is actually not an efficiency comparison to the operating power but is instead a comparison with the workload parameters to the workload threshold, or it could be read as meaning that the workload parameters compared to the workload threshold somehow informs the efficiency comparison to the operational power, although it is unclear how those comparisons are related or would influence each other. Accordingly, the scope of the claim cannot be determined and the claim is indefinite.
Regarding claim 17:
Claim 17 is indefinite for reasons analogous to claim 6. Accordingly, the scope of the claim cannot be determined and the claim is indefinite.
Regarding claim 18:
Claim 18 is indefinite for reasons analogous to claim 7. Accordingly, the scope of the claim cannot be determined and the claim is indefinite.
Regarding claim 19:
Claim 19 is indefinite for reasons analogous to claim 8. Accordingly, the scope of the claim cannot be determined and the claim is indefinite.
Regarding claims 2-12 and 14-19:
Claims 2-12 and 14-19 are rejected for failing to cure the deficiencies of a rejected base claim from which they depend.
Regarding claim 20:
Claim 20 recites, “the specific task”. However, there is insufficient antecedent basis for this limitation in the claim. Furthermore, the claim then later recites “a specific task” and then later yet recites “the specific task” which renders the antecedent basis for the limitation uncertain. Accordingly, the scope of the claim cannot be determined and the claim is indefinite.
Claim Rejections - 35 USC § 112(a)
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claims 1, 13 and 20:
Claims 1, 13 and 20 are rejected for failing to disclose the corresponding structure that performs the entire claimed function for the claim limitations interpreted under 35 USC §112(f) as identified in limitations (a-d) in the claim interpretation section above. As such, the claims lack adequate written description support because “an indefinite, unbounded functional limitation would cover all ways of performing a function and indicate that the inventor has not provided sufficient disclosure to show possession of the invention” [MPEP 2163.03(VI)]. Additionally, the claims are rejected as being indefinite for failing to disclose the corresponding structure for performing the claimed limitations, and accordingly, the claims lack adequate written description [MPEP 2181(II)(B), last ¶].
Regarding claim 1:
Claim 1 lacks adequate written description to support “to compare an efficiency of the hardware engine in performing the specific task in a given time unit against the operational power”.
“Efficiency” ordinarily refers to a ratio of useful output (e.g., work performed) to input (e.g., energy supplied, typically expressed as a percentage). However, the specification never discloses how to determine the efficiency of the hardware engine in performing the specific task in a given time unit or any mechanism or structure for obtaining an efficiency of the hardware engine.
Specifically, the specification does not disclose:
What constitutes the “work” performed by the hardware engine for the specific tasks (e.g., operations completed, data processed, latency reduction, etc.)
What constitutes the corresponding input (e.g., energy consumed, power over time, processing cycles, time, etc.)
Any formula, relationship, or algorithm for calculating efficiency.
Any units or scale by which efficiency is expressed.
Any threshold, baseline, or comparison criteria by which one efficiency value would be considered greater than another.
Any mechanism for measuring the output (such as work performed) or input (such as power consumed), or any description of the structure of the hardware engine whatsoever such that its inputs and outputs could be determined.
Moreover, “efficiency” is a broad term that could encompass numerous materially different metrics (e.g., algorithmic efficiency, efficiency factor, storage efficiency, material efficiency, throughput per watt, operations per joule, latency per unit power, or other performance-to-power ratios). The specification does not identify, which, if any, of those metrics is intended, nor does it provide sufficient guidance to distinguish among them. As such, the specification fails to convey possession of any particular implementation of “efficiency”.
Further, the only discussion of “efficiency” in the specification is circular. For example, paragraph [0026] states that “in determining the efficiency of hardware engine 112 in performing a task, controller 108 may compare the efficiency of hardware engine 112 against the power consumption of hardware engine 112”. This statement presumes that the efficiency is already known and provides no guidance as to how it is derived in the first place.
Finally, the “hardware engine” is effectively described as a black-box. Its structure and functionality are not described in any meaningful way, such that any type of “efficiency” could be inferred from the structure of the “hardware engine” itself, or any way to measure or obtain the efficiency of it.
Accordingly, the specification does not reasonably convey to one of ordinary skill in the art that the inventors were in possession of a method or system capable of determining or comparing “efficiency” as claimed. Rather, the claim recites a desired result, “comparing efficiency”, without describing how the result is achieved or what specific metric is being used. Therefore, “the claim defines the invention in functional language specifying a desired result but the disclosure fails to sufficiently identify how the function is performed or the result is achieved” and the claim language therefore lacks an adequate written description [MPEP 2163.03 (V)].
Claim 1 also lacks written description support for selectively executing the specific task with the controller “when the controller can execute the specific task within the given time unit with a given level of efficiency” and instead invoking the hardware engine to execute the specific task “when the controller cannot execute the specific task within the given time unit with the given level of efficiency” .
Specifically, the specification never discloses how to determine whether a controller can execute a specific task within a given level of efficiency or within a given time unit. There are no disclosed structures or mechanisms for determining the efficiency or time within which the controller can execute the task. For example, one of ordinary skill in the art might wonder how to know, before executing a task, whether that task can be executed within a specific time or efficiency. There are no disclosed structures or mechanisms for predicting a time or efficiency for executing a task, for characterizing a time or efficiency of executing a task, for looking up a time or efficiency for executing a task, or for calculating a time or efficiency for executing a task. There is not even a disclosed structure or mechanism for measuring the amount of power consumed by the controller or storage device. Instead, the specification only discloses in a result-oriented fashion that the controller may determine if it can execute a task at a given level of efficiency, such as in [0029] “If controller 108 determines, that it can execute the L2P flow of search, eviction, and consolidation of L2P entries with a given level of efficiency as GDSE hardware engine 112,controller 108 may switch off GDSE hardware engine 112, even though GDSE hardware engine 112 may be available to perform the tasks being performed by controller 108” and other similar disclosures in [0026], [0028], (240-250) [Fig. 2], (550-560) [Fig. 5], (650) [Fig. 7], (770-780) [Fig. 7].
Accordingly, “the claim defines the invention in functional language specifying a desired result but the disclosure fails to sufficiently identify how the function is performed or the result is achieved” and the claim language therefore lacks an adequate written description [MPEP 2163.03 (V)].
Claim 1 also recites, “invoke the hardware engine to execute the specific task…”. However, the specification fails to disclose how the hardware engine is invoked.
Specifically, the specification does not describe any mechanism or structure for invoking the hardware engine, such as a communication path between the controller and the hardware engine, a mechanism for offloading or transferring the task, a protocol by which the hardware engine recognizes and executes the task, or a mechanism for returning results. Nor does the specification describe how the hardware engine is connected to other components such that its invocation produces a functional result.
Moreover, the hardware engine is recited as a generic component without any disclosed structure, configuration, or operational detail. The specification never discloses what the hardware engine comprises, how it is implemented, or how it is capable of performing the recited task. As such the hardware engine is effectively treated as a block box, which therefore does not provide any guidance to one of ordinary skill in the art on how such a structure could be “invoked”.
At most, the specification merely restates the claimed functionality. For example, paragraph [0043] states that “storage device 104 may include a controller 108 to optimize the power usage on storage device 104 by selectively invoking a hardware engine”, which provides no additional detail as to how the invocation is performed. This deficiency is particularly significant because the purported invention is the mechanism for selectively executing the hardware engine: “there is currently no mechanism for optimizing power usage on the storage device through selective execution of a hardware engine” [0004], and yet the specification does not provide a single description of a mechanism or structure that could be used to selectively execute (invoke) a hardware engine, outside of the result-oriented functional language recited in the claims and repeated in the specification.
Accordingly, “the claim defines the invention in functional language specifying a desired result but the disclosure fails to sufficiently identify how the function is performed or the result is achieved” and the claim language therefore lacks an adequate written description [MPEP 2163.03 (V)].
Regarding claim 3:
Claim 3 recites, “wherein to determine the efficiency of the hardware engine in performing the specific task in the given time unit, the controller is configured to compare at least one threshold defined according to a quality-of-service requirement with a workload”, which therefore requires determining an efficiency based on a comparison between a workload and a threshold. While the specification describes monitoring workload characteristics and making decisions regarding whether or not to invoke a hardware engine based on those workload characteristics, it does not describe how to determine an efficiency metric from a threshold compared to a workload or how the comparison of workload and thresholds yields such a determination. In particular, the specification discusses optimizing power consumption and tradeoffs between controller and hardware execution, but does not disclose how such efficiency is calculated or inferred from the claimed comparison. Accordingly, the specification fails to reasonably convey possession of the claimed determination of efficiency because “the claim defines the invention in functional language specifying a desired result but the disclosure fails to sufficiently identify how the function is performed or the result is achieved” [MPEP 2163.03 (V)].
Regarding claims 4-5 and 10:
Claims 4-5 and 10 recite other comparisons and metrics that are used to determine the efficiency of the hardware engine in performing the specific task, and yet there is no description of how those comparisons or metrics can be used to calculate an efficiency in an analogous fashion to the analysis performed for claim 3. Furthermore, there is no obvious process to convert between the result of the comparisons or the monitored metrics to obtain an efficiency. Accordingly, the specification fails to reasonably convey possession of the claimed determination of efficiency because “the claim defines the invention in functional language specifying a desired result, but the disclosure fails to sufficiently identify how the function is performed or the result is achieved” [MPEP 2163.03 (V)].
Regarding claim 13:
Claim 13 is rejected according to a similar analysis as performed for analogous claim 1.
Regarding claims 14-16:
Claims 14-16 are rejected according to a similar analysis as performed for analogous claims 3-5, respectively.
Regarding claims 2-12 and 14-19:
Claims 2-12 and 14-19 are rejected for failing to cure the deficiencies of a rejected base claim from which they depend.
Claim 3-5, 10 and 14-16 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention.
Regarding claim 3:
Claim 3 recites, “wherein to determine the efficiency of the hardware engine in performing the specific task in the given time unit, the controller is configured to compare at least one threshold defined according to a quality-of-service requirement with a workload”. While the specification describes monitoring workload characteristics (i.e., random vs sequential workload and accumulation of L2P data entries”) and making decisions regarding whether to invoke the hardware engine [0029], it does not disclose a method or algorithm for determining efficiency, particularly as discussed in the specification in terms of power consumption tradeoffs between the using the controller and hardware engine [0001-0007]. Applying the Wands factors, the following considerations indicate that undue experimentation is required:
Breadth of claims: the claims are broad in that they require determining an efficiency for performing any “specific task” performed by a hardware engine without any limit on what that particular task is, such that it encompasses any conceivable task that a storage device may perform. Furthermore, the structure of the “hardware engine” is unconstrained by the claims and is effectively a “black-box” in the specification as its structure, configuration, and nature of operation are not discussed and is therefore broad in scope.
Nature of the invention: The invention relates to performance and power optimization in storage systems, which involves complex interactions between workload characteristics, system architecture (for example the structure and architecture of the controller and hardware engine), and power consumption. Determining an efficiency in such a system is highly context-dependent and would require detailed modeling or empirical characterization for each implementation.
State of the prior art: The specification itself indicates that there is no existing mechanism for optimizing power usage through selective execution of a hardware engine, suggesting that the claimed functionality is not routine or well understood in the art [0004].
Level of one of ordinary skill: Even assuming a high level of skill in the art, such a person would still require guidance to determine how to derive “efficiency” from workload and QoS parameters, as a comparison between workload and QoS parameters would not, by itself, uncover any relationship to power consumption and therefore “efficiency”.
Level of predictability in the art: Across the broad scope of the claims, which include any task that a storage device may perform with both a hardware engine and controller, the outcome is relatively unpredictable with respect to performance and tradeoffs as efficiency depends on many variables including workload patterns, hardware architecture (for example of the controller or hardware engine), system constraints, how easily a task may be parallelized, etc., which may not be known without empirical testing or detailed modeling for each implementation.
Amount of direction provided by the inventor: The specification provides limited guidance. It discloses monitoring workload characteristics (e.g. random vs. sequential workload and accumulated entries), defining a threshold based on QoS requirements, and making decisions regarding whether to invoke the hardware engine based on those monitored characteristics and a threshold. However, the specification does not disclose how to compute or quantify “efficiency” based on this comparison, how to relate workload characteristics or QoS thresholds to power consumption or other efficiency metrics, or how to generalize such determinations to any “specific task” and any “hardware engine” outside of the specific examples discussed with relation to search, eviction, and consolidation performed by a GDSE engine. Accordingly, the direction provided to the full scope of the invention is limited.
The existence of working examples: The specification lacks concrete working examples demonstrating how an efficiency value is determined from the claimed comparison – instead, it merely concludes that it is. Furthermore, it does not provide examples of how an efficiency value could be determined from the claimed comparison across different tasks, workloads, operating conditions, or hardware engine configurations.
The quantity of experimentation needed to make or use the invention based on the content of the disclosure: Given the breadth of the claims and the limited guidance provided, one of ordinary skill in the art would need to develop relationships between workload characteristics and efficiency metrics and validate such relationships across different workloads, system configurations, hardware engine architectures, tasks, and either create a generalized model or empirical testing for each task and hardware engine architecture that is implemented in order to develop a working relationship between a workload an a power consumption that could then be used to determine an efficiency. This would require extensive experimentation, including modeling and empirical testing, rising to the level of undue experimentation to enable the full scope of the invention.
Accordingly, based especially on the breadth of the claims, the lack of direction provided, and the quantity of experimentation needed, along with the other factors, the specification at the time the application was filed, would not have taught one skilled in the art how to make and/or use the full scope of the invention without undue experimentation.
Regarding claims 4, 5 and 10:
Claims 4, 5, and 10 are rejected according to a similar analysis as that performed for claim 3, because like comparing a threshold with a workload as recited in claim 3, monitoring an available resource as claimed in claim 4, monitoring a power mode or power state of the storage device as claimed in claim 5, and evaluating an amount of a random workload and a rate of accumulation of logical-to-physical delta entries within a given time window as claimed in claim 10, do not, by themselves, indicate a relationship between a specific task performed by a hardware engine and the efficiency of the hardware engine in performing that specific task. Accordingly, an analysis of the factors would yield similar determinations for each factor and therefore a similar conclusion that based especially on the breadth of the claims, the lack of direction provided, and the quantity of experimentation needed, along with the other factors, the specification at the time the application was filed, would not have taught one skilled in the art how to make and/or use the full scope of the invention without undue experimentation.
Regarding claims 14-16:
Claims 14-16 are rejected according to a similar analysis as that performed for analogous claims 3-5, respectively.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4, 12, 13 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Application Publication No. US 2022/0398085 A1 (Chen) in view of the paper by Tomoaki Hamano et. al., from the Tokyo Institute of Technology, 10 July 2009, titled “Power-Aware Dynamic Task Scheduling for Heterogeneous Accelerated Clusters” (Hamano).
Regarding claim 1 and analogous claim 13:
Chen discloses:
a storage device (110)
selective execution of a hardware engine (hardware accelerators (215A-N), which may be selectively enabled to perform tasks in place of a CPU (see Figs. 10-23)).
the storage device comprises: a hardware engine configured to perform a specific task on the storage device using operational power provided by the storage device (by disclosing that the hardware accelerators may be programmed with firmware to perform specific tasks on the storage device [Fig. 2] [Figs. 10-23]. The hardware accelerators are electronic devices/chips in the storage system that execute firmware and therefore consume electrical power [0047-0052]).
and a controller configured to (in place of the hardware accelerators, the CPU (controller) can perform the tasks that would normally be offloaded to the hardware accelerators (referred to as “fallback” within the specification [see Figs. 7-23] [0055] [0059]).
and execute the specific task using processing power of the storage device (sometimes, when fallback occurs, the CPU of the storage system performs the workloads that would ordinarily be intended for the hardware accelerators, such as when the hardware accelerator is having its firmware upgraded, which consumes CPU utilization and therefore processing power of the storage device [0047-0049] [0055] [0059] [Fig. 7])
and invoke the hardware engine to execute the specific task (other times, the hardware accelerator is invoked to perform the workloads, such as when the hardware accelerators are not being upgraded with firmware, or when tasks are more CPU intensive, and therefore more efficiently executed on the accelerators rather than the CPU [see Figs. 8-13] [0060-0075]).
Chen does not explicitly disclose, but Hamano teaches:
to optimize power usage on the storage device through selective execution of a hardware engine (by teaching to optimize overall energy consumption for a heterogenous cluster that consists of CPUs and accelerators by dynamically scheduling the tasks in terms of makespan (time to execute the task [pg. 2: Col 2, ¶2]) and energy consumed for each scheduling decision when the given task could be executed by either the CPU or the accelerator [pg. 2: Col 1, ¶2])
to compare an efficiency of the hardware engine in performing the specific task in a given time unit against the operational power (by teaching to compare the efficiency by comparing the energy and makespan of each task according to each scheduling operation (either executing on the hardware accelerator or the CPU) for each task to optimize the overall power consumption and acceleration factor according to the energy-delay product [pg. 1: Col 1, ¶2]. In this way, based on efficiency and the execution time and schedule, an overall power consumption may be determined and the most energy efficient with the lower execution time may be selected [pg. 4: Col 1, ¶¶1-5])
to determine that the controller can execute the specific task within the given time unit with a given level of efficiency and i) keep the hardware engine in an idle state and execute the specific task using processing power of the storage device or ii) switch off the hardware engine and execute the specific task using processing power of the storage device (if the hardware accelerator is not scheduled for execution at a given moment, it will be idle, as see in the power consumption formulas [pg. 3: Col 1, ¶¶1-2 and Formula #2]. This will occur when it is determined that executing the task on the CPU instead of the hardware accelerator leads to a more efficient Energy Delay-Product overall (within a given efficiency), which is determined using the execution time of executing the task on the CPU called busyTime (i.e., within a given time) [pg. 3: Col 2, ¶¶1-3 and Formulas #2-4] [pg. 4: Col 1, ¶1-5])
to determine the controller cannot execute the specific task within the given time unit with the given level of efficiency and invoke the hardware engine to execute the specific task, wherein when the controller invokes the hardware engine the storage device consumes the processing power and the operational power (if the CPU is not scheduled for execution at a given moment, it will be idle, as see in the power consumption formulas [pg. 3: Col 1, ¶¶1-2 and Formulas #2-4]. Therefore, even while using the accelerator instead of the CPU, the CPU will consume power along with the accelerator (i.e., the sum of all power consumption for each processing node (CPU and accelerators), which includes idle as well as busy time). Execution on the accelerator over the CPU will occur when it is determined that executing the task on the hardware accelerator instead of the CPU leads to a more efficient Energy Delay-Product overall (within a given efficiency), which is determined using the execution time of executing the task on the accelerator called busyTime (i.e., within a given time) [pg. 3: Col 2, ¶¶1-3 and Formulas #2-4] [pg. 4: Col 1, ¶1-5]. This may occur because the task cannot be executed on the CPU, in which case it’s busyTime on the CPU would be infinity (i.e., cannot execute the task within the given time unit within the given level of efficiency) [pg. 3: Col 1, last ¶]).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the storage device as taught by Chen to include scheduling and executing the task on the CPU when the efficiency and time of executing the task on the CPU yields a better overall efficiency and power consumption (energy-delay product) and to instead schedule and execute the task on the hardware accelerator when the efficiency and time of executing the task on the CPU does not yield a better overall efficiency and power consumption (energy-delay product) based on comparing the efficiency (energy delay-product) of different schedules with the different power consumptions of executing the task on the hardware accelerator and CPU as represented within the energy delay product from the summation of all energy consumptions of the schedule as taught by Hamano.
One of ordinary skill in the art would have been motivated to make this modification because not all tasks on accelerated on an accelerator, and some may run faster on a CPU, as well as have superior energy consumption if run on the CPU, and so it would be desirable to schedule the tasks to optimize overall energy consumption and throughput in consideration of the heterogenous nature of scheduling the tasks on the CPU vs the accelerator as taught by Hamano in [pg. 1: Col 2, ¶2 – continued onto pg. 2].
Regarding claim 4 and analogous claim 15:
The storage device of claim 1 is made obvious by Chen in view of Hamano (Chen-Hamano).
Chen does not explicitly disclose, but Hamano teaches:
wherein to determine the efficiency of the hardware engine in performing the specific task in the given time unit, the controller is configured to monitor an available resource (by teaching that the scheduling algorithm monitors the number and availability of CPUs and hardware accelerators to determine different permutations of the scheduling according to the different tasks that need to be executed, and then computes the energy efficiency of the schedule according to calculations that monitor the availability of idle time and busy time, according to the power draw of idle and busy periods, to determine the energy-delay product and maximize efficiency in selecting a schedule [pg. 4: Col 1, ¶¶1-5] [pg. 3, Col 2, ¶¶1-4 and Formulas 2-4]).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the storage device as taught by Chen to include scheduling and executing the task on the CPU when the efficiency and time of executing the task on the CPU yields a better overall efficiency and power consumption (energy-delay product) and to instead schedule and execute the task on the hardware accelerator when the efficiency and time of executing the task on the CPU does not yield a better overall efficiency and power consumption (energy-delay product) based on comparing the efficiency (energy delay-product) of different schedules with the different power consumptions of executing the task on the hardware accelerator and CPU as represented within the energy delay product from the summation of all energy consumptions of the schedule based on available CPUs, hardware accelerators, busy and idle time as taught by Hamano.
One of ordinary skill in the art would have been motivated to make this modification because not all tasks on accelerated on an accelerator, and some may run faster on a CPU, as well as have superior energy consumption if run on the CPU, and so it would be desirable to schedule the tasks to optimize overall energy consumption and throughput in consideration of the heterogenous nature of scheduling the tasks on the CPU vs the accelerator as taught by Hamano in [pg. 1: Col 2, ¶2 – continued onto pg. 2].
Regarding claim 12:
The storage device of claim 1 is made obvious by Chen-Hamano.
Chen does not explicitly disclose, but Hamano teaches:
wherein the operational power varies according to a workload associated with the specific task (by teaching that execution of a task will be selected for performance on the accelerator over the CPU when it is determined that executing the task on the hardware accelerator instead of the CPU leads to a more efficient Energy Delay-Product overall (within a given efficiency), which is determined using the execution time of executing the task on the accelerator called busyTime (i.e., within a given time) [pg. 3: Col 2, ¶¶1-3 and Formulas #2-4] [pg. 4: Col 1, ¶1-5]. This may occur because the task cannot be executed on the CPU, in which case it’s busyTime on the CPU would be infinity (i.e., cannot execute the task with the given efficiency in a given amount of time) [pg. 3: Col 1, last ¶]. Each task has its own corresponding execution time, and therefore consumes a different amount of power depending on the length of executing the task (operational power varies according to a workload associated with the specific task) [pg. 3: Col 1, ¶¶2-3]).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the storage device as taught by Chen to include scheduling and executing the task on the CPU when the efficiency and time of executing the task on the CPU yields a better overall efficiency and power consumption (energy-delay product) and to instead schedule and execute the task on the hardware accelerator when the efficiency and time of executing the task on the CPU does not yield a better overall efficiency and power consumption (energy-delay product) based on comparing the efficiency (energy delay-product) of different schedules with the different power consumptions of executing the task on the hardware accelerator and CPU as represented within the energy delay product from the summation of all energy consumptions of the schedule as taught by Hamano.
One of ordinary skill in the art would have been motivated to make this modification because not all tasks on accelerated on an accelerator, and some may run faster on a CPU, as well as have superior energy consumption if run on the CPU, and so it would be desirable to schedule the tasks to optimize overall energy consumption and throughput in consideration of the heterogenous nature of scheduling the tasks on the CPU vs the accelerator as taught by Hamano in [pg. 1: Col 2, ¶2 – continued onto pg. 2].
Claims 2 is rejected under 35 U.S.C. 103 as being unpatentable over Chen in view of Hamano in further view of the paper by Ko Natori et. al., from IEEE Access Vol. 12, 23 August 2024, titled “Power Saving for Hardware Accelerated Applications with Dynamical Processor Switching” (Natori).
Regarding claim 2:
The storage device of claim 1 is made obvious by Chen-Hamano.
Chen does not explicitly disclose, but Natori teaches:
wherein when the hardware engine is in the idle state, the hardware engine consumes power in a base power mode, wherein power consumed in the base power mode is less than the operational power (by teaching that the hardware accelerator may be an FPGA, such as the intel N3000. An FPGA allows a system to meet latency requirements with higher efficiency than a CPU can achieve, and can continue to meet latency requirements under high load when a CPU cannot [pg. 1: Col 2, ¶1]. However, the FPGAs generally don’t have a lot of power saving features, and so their power consumption under heavy load (operational power) may be only slightly higher than under no load (i.e., base power mode) (i.e., power consumed in the base power mode is less than the operational power) [pg. 3: Col 2, ¶¶2-3]. However, a GPU may have more power saving features, and may therefore have lower power consumption at no load (base power mode) compared to under load (operational power)).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the hardware accelerator running the tasks as taught by Chen to be a GPU as taught by Natori.
One of ordinary skill in the art would have been motivated to make this modification because it would allow the CPU to offload tasks to run in a highly parallel and efficient environment where a CPU might not be able to keep up with latency requirements, but have lower power consumption under no load as taught by Natori in [pg. 1: Col 2, ¶1] [pg. 3: Col 2, ¶4]).
Claims 3, 5, 14 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Chen-Hamano in further view of the paper by Ravi Reddy Manumachu et. al., from IEEE Access, Vol. 11, 17 March 2023, titled, “Acceleration of Bi-Objective Optimization of Data-Parallel Applications for Performance and Energy on Heterogeneous Hybrid Platforms” (Manumachu).
Regarding claim 3 and analogous claim 14:
The storage device of claim 1 is made obvious by Chen-Hamano.
Chen does not explicitly disclose, but Manumachu teaches:
wherein to determine the efficiency of the hardware engine in performing the specific task in the given time unit, the controller is configured to compare at least one threshold defined according to a quality-of-service requirement with a workload (by teaching that achieving energy efficiency objectives and response time quality of service requirements is critical to commercial viability of storage system infrastructures [pg. 27227, Col 1, ¶0]. In this respect, they propose a bi-objective optimization problem that determines a pareto-optimal solution for scheduling a workload on heterogenous processors including CPUs and accelerators in order to optimize performance (time) and energy consumption (i.e., quality of service requirements) for a given workload, which can be implemented with a proposed dynamic programming partitioning algorithm HEPOPTADP, or PARHEPOPTA [pg. 27229: Col 1: ¶2 – pg. 27230: Col 1, last ¶]).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the heterogenous dynamic scheduling algorithm as taught by Chen to be HEPOPTADP, or PARHEPOPTA as taught by Manumachu, which controls for quality of service requirements like energy efficiency and response times compared to workloads and different proposed schedules.
One of ordinary skill in the art would have been motivated to make this modification because controlling for these QoS requirements is critical to commercial viability and the HEPOPTADP, or PARHEPOPTA algorithms offer pareto-optimal solutions with lower time complexity than HEPOPT and offer good speedups over other state of the art solutions as taught by Manumachu in [pg. 27230: Col 1, ¶1-9].
Regarding claim 5 and analogous claim 16:
The storage device of claim 1 is made obvious by Chen-Hamano.
Chen does not explicitly disclose, but Manumachu teaches:
wherein to determine the efficiency of the hardware engine in performing the specific task in the given time unit, the controller is further configured to monitor at least one of a power mode and a power state of the storage device (by teaching that the system models the energy consumption by using system-level power measurements (a power state) provided by power meters, as this is considered ground truth, and is the most accurate way to determine the energy consumption, performance and energy profiles, and therefore efficiency, of executing a task [pg. 27227: Col 2, ¶2] [pg. 27228: Col 1, ¶¶2-3] [pg. 27228: Col 2, ¶¶1-5] [pg. 27229: Col 1, ¶¶1-2]).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the determination of power consumption, performance, and efficiency of executing a task on a hardware accelerator as taught by Chen to include determining it with modeling based on system level power meters, which measure the power consumption of the system (a power state) as taught by Manumachu.
One of ordinary skill in the art would have been motivated to make this modification because this method is considered ground truth, and is more accurate and reliable than other predictive models, component level power monitoring, or runtime modeling as taught by Manumachu in [pg. 27228: Col 2, last ¶ - pg. 27229: Col 1, ¶2].
Claims 6 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Chen-Hamano in further view of the paper by Xiang Gao, from IEEE Access Vol. 11, 19 May 2023, titled, “TAS: A Temperature-Aware Scheduling for Heterogenous Computing” (Gao).
Regarding claim 6 and analogous claim 17:
The storage device of claim 1 is made obvious by Chen-Hamano.
Chen does not explicitly disclose, but Gao teaches,
wherein the controller is configured to keep the hardware engine in the idle state and execute the specific task on the controller when the storage device is in a low power mode or a first thermal state or and ii) switch off the hardware engine and execute the specific task on the controller when the storage device is in the low power mode or the first thermal state, and invoke the hardware engine to execute the specific task when the storage device is in an active power mode or a second thermal state (by teaching that if the temperature crosses a threshold, the speeds of the CPU and hardware accelerators may be adjusted, such that the optimal allocation of tasks to the CPU vs hardware accelerators should change to reflect the updated speeds of the CPU and hardware accelerators, accordingly, once the temperature crosses the threshold, the system may assign tasks to the CPU that would have otherwise been assigned to the accelerators, and when the temperature does not cross the threshold, tasks may be assigned to the accelerators [pg. 54777: Col 2, ¶2 – pg. 54780: Col 1, last ¶]).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the allocation of tasks between the CPU and hardware accelerator as taught by Chen-Hamano with the temperature aware scheduling, that adjusts the operating speed and therefore the allocation of tasks between the CPU and hardware accelerator according to whether the temperature of the system has crossed a threshold (i.e., thermal state) as taught by Gao.
One of ordinary skill in the art would have been motivated to make this modification because the temperature aware scheduling leads to higher performance under energy consumption and temperature constraints as taught by Gao in [54780: Col 1, last ¶].
Claims 7, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Chen-Hamano in further view of US Patent Application Publication No. US 2025/0068222 A1 (Muthiah).
Regarding claim 7 and analogous claim 18:
The storage device of claim 1 is made obvious by Chen-Hamano.
Chen-Hamano does not explicitly disclose, but Muthiah teaches:
wherein the storage device operates using multiple protocols and the controller is configured to i) keep the hardware engine in the idle state and execute the specific task on the controller when the storage device is using a first protocol or ii) switch off the hardware engine and execute the specific task on the controller when the storage device is using a first protocol, and invoke the hardware engine to execute the specific task when the storage device is using a second protocol (by teaching that a storage device may be a multi-protocol storage device that can execute a protocol such as PCIe-NVMe, which is resource intensive and uses more complex hardware and logic such as ASIC logics (i.e., hardware accelerator). The storage device may also execute a protocol such as SD, UFS, or USB, which uses minimal hardware and ASIC components. The storage device may then monitor a temperature, and in response to the temperature crossing a temperature threshold, the controller may switch from the resource intensive NVMe protocol, which uses the hardware and ASICs (i.e., hardware accelerator) to instead operate with a less resource intensive protocol, such as SD, UFS, or USB, which uses less hardware and ASICs. While using the less resource intensive protocol, the controller may also switch off some of the hardware components on the storage device and move to a lower-power consuming host-specification [0001-0002] [0006] [Fig. 3] [0017] [0023] [0025]).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the storage device as taught by Chen to include the ability to switch a lower-resource intensive protocol and be able to switch off some of the specialized hardware and hardware accelerators that may be needed to run the higher-resource intensive protocol when a temperature threshold is reached as taught by Muthiah.
One of ordinary skill in the art would have been motivated to make this modification because responding to reaching the temperature threshold by switching to the lower-resource intensive protocol may prevent the storage device from entering the thermal shutdown zone, may still operate within the temperature, and may allow the host to still access the data as taught by Muthiah in [0022-0023] [0025].
Regarding claim 20:
Chen discloses, a method for selective execution of a hardware engine (hardware accelerators (215A-N), which may be selectively enabled to perform tasks in place of a CPU (see Figs. 10-23])), the storage device comprising a controller to execute the method comprising: (by disclosing the CPU (210) controller. Which, in place of the hardware accelerators, the CPU can perform the tasks that would normally be offloaded to the hardware accelerators (referred to as “fallback” within the specification [see Figs. 7-23] [0055] [0059]) receiving a read request on the storage device (by teaching that when reading or retrieving a large file from the storage system, there may be a greater number of decompression workloads, which can occur because of the different requests received to process the different workloads [0076]. The requests may be received from a client by the backup/restore engine, which is an application executed by the CPU [0042-0046] [0052] [0055]) a hardware engine configured to perform a specific task in a given time unit using operational power provided by the storage device (by disclosing that the hardware accelerators may be programmed with firmware to perform specific tasks on the storage device [Fig. 2] [Figs. 10-23]. The hardware accelerators are electronic devices/chips in the storage system that execute firmware and therefore consume electrical power [0047-0052])) and invoking the hardware engine to execute the specific task (sometimes, the hardware accelerator is invoked to perform the workloads, such as when the hardware accelerators are not being upgraded with firmware, or when tasks are more CPU intensive, and therefore more efficiently executed on the accelerators rather than the CPU [see Figs. 8-13] [0060-0075]) and execute the specific task (other times, when fallback occurs, the CPU performs the workloads that would ordinarily be intended for the hardware accelerators, such as when the hardware accelerator is having its firmware upgraded [0055] 0059] [Fig. 7]).
Chen does not explicitly disclose, but Hamano teaches:
a method for optimizing power usage on the storage device through selective execution of a hardware engine (by teaching to optimize overall energy consumption for a heterogenous cluster that consists of CPUs and accelerators by dynamically scheduling the tasks in terms of makespan (time to execute the task [pg. 2: Col 2, ¶2]) and energy consumed for each scheduling decision when the given task could be executed by either the CPU or the accelerator [pg. 2: Col 1, ¶2]) ])
invoking the hardware engine to execute the specific task in response to determining that a threshold for switching to a hardware engine configured to perform a specific task in a gtiven time unit using operational power provided by the storage device (by teaching comparing the energy and makespan of each task according to each scheduling operation (either executing on the hardware accelerator or the CPU, starting with running all tasks on the CPU) for each task to optimize the overall power consumption and acceleration factor according to the energy-delay product [pg. 1: Col 1, ¶2]. In this way, based on the efficiency and the execution time and schedule, an overall power consumption may be determined and the most energy efficient with the lowest execution time may be selected, a task may be switched from the CPU to the accelerator if it is determined that it lowers the EDP from running all tasks on the CPU (a threshold for switching to a hardware engine) [pg. 4: Col 1, ¶¶1-5])
executing the specific task in response to determining i) that the threshold for switching to the hardware engine is not met, ii) that the storage device is not operating in a low power mode, or iii) that the storage device is operating in a first thermal state (if the hardware accelerator is not scheduled for execution at a given moment, it will be idle, as see in the power consumption formulas [pg. 3: Col 1, ¶¶1-2 and Formula #2]. This will occur when it is determined that executing the task on the CPU (and executing the specific task) instead of the hardware accelerator leads to a more efficient Energy Delay-Product overall (that the threshold for switching to the hardware engine is not met), which is determined using the execution time of executing the task on the CPU called busyTime [pg. 3: Col 2, ¶¶1-3 and Formulas #2-4] [pg. 4: Col 1, ¶1-5])
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the storage device as taught by Chen to include scheduling and executing the task on the CPU when the efficiency and time of executing the task on the CPU yields a better overall efficiency and power consumption (energy-delay product) and to instead schedule and execute the task on the hardware accelerator when the efficiency and time of executing the task on the CPU does not yield a better overall efficiency and power consumption (energy-delay product) based on comparing the efficiency of different schedules with the different power consumptions of executing the task on the hardware accelerator and CPU as represented within the energy delay product from the summation of all energy consumptions of the schedule as taught by Hamano.
One of ordinary skill in the art would have been motivated to make this modification because not all tasks on accelerated on an accelerator, and some may run faster on a CPU, as well as have superior energy consumption if run on the CPU, and so it would be desirable to schedule the tasks to optimize overall energy consumption and throughput in consideration of the heterogenous nature of scheduling the tasks on the CPU vs the accelerator as taught by Hamano in [pg. 1: Col 2, ¶2 – continued onto pg. 2].
Chen in view of Hamano does not explicitly disclose, but Muthiah teaches:
determining that the storage device is not operating in a low power mode, or determining that the storage device is operating in a low power mode and determining ii) that the storage device is not operating in a first thermal state, or iii) that the storage device is operating in the first thermal state ((by teaching that a storage device may be a multi-protocol storage device that can execute a protocol such as PCIe-NVMe (in a higher-power consuming host specification – i.e., not operating in a low power mode), which is resource intensive and uses more complex hardware and logic such as ASIC logics (i.e., hardware accelerator). The storage device may also execute a protocol such as SD, UFS, or USB, which uses minimal hardware and ASIC components. The storage device may then monitor a temperature, in an response to the temperature crossing a temperature threshold (determining whether the storage device is operating in the first thermal state or not), the controller may switch from the resource intensive NVMe protocol, which uses the hardware and ASICs (i.e., hardware accelerator) to instead operate with a less resource intensive protocol, such as SD, UFS, or USB, which uses less hardware and ASICs. While using the less resource intensive protocol, the controller may also switch off some of the hardware components on the storage device and move to a lower-power consuming host-specification (determine that the storage device is operating in a low power mode) [0001-0002] [0006] [Fig. 3] [0017] [0023] [0025]).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the storage device as taught by Chen to include the ability to switch a lower-resource intensive protocol and be able to switch off some of the specialized hardware and hardware accelerators in a lower-power consuming host specification that may be needed to run the higher-resource intensive protocol when a temperature threshold is reached (a first thermal state) as taught by Muthiah.
One of ordinary skill in the art would have been motivated to make this modification because responding to reaching the temperature threshold by switching to the lower-resource intensive protocol may prevent the storage device from entering the thermal shutdown zone, may still operate within the temperature, and may allow the host to still access the data as taught by Muthiah in [0022-0023] [0025].
Claims 8 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Chen-Hamano in further view of US Patent Application Publication No. US 2023/0205449 A1 (Jeong) in further view of Muthiah.
Regarding claim 8 and analogous claim 19:
The storage device of claim 1 is made obvious by Chen-Hamano.
Chen does not explicitly disclose, but Jeong teaches, wherein the storage device operates using concurrent protocols (by teaching that the storage device may operate using a multi-protocol host I/F, which may receive requests from the host according to the NVMe protocol [0030], as well as other protocols at the same time, such as USB, SD, or UFS [0052]).
Chen in view of Jeong does not explicitly disclose, but Muthiah teaches, and the controller is configured to i) keep the hardware engine in the idle state and execute the specific task on the controller when the storage device is processing an input/output operation with a first protocol or ii) switch off the hardware engine and execute the specific task on the controller when the storage device is processing an input/output operation with the first protocol, and invoke the hardware engine to execute the specific task when the storage device is processing the input/output operation with a second protocol (by teaching that a storage device may be a multi-protocol storage device that can execute a protocol such as PCIe-NVMe, which is resource intensive and uses more complex hardware and logic such as ASIC logics (i.e., hardware accelerator). The storage device may also execute a protocol such as SD, UFS, or USB, which uses minimal hardware and ASIC components. The storage device may then monitor a temperature, in an response to the temperature crossing a temperature threshold, the controller may switch from the resource intensive NVMe protocol, which uses the hardware and ASICs (i.e., hardware accelerator) to instead operate with a less resource intensive protocol, such as SD, UFS, or USB, which uses less hardware and ASICs. While using the less resource intensive protocol, the controller may also switch off some of the hardware components on the storage device and move to a lower-power consuming host-specification [0001-0002] [0006] [Fig. 3] [0017] [0023] [0025]).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the storage device as taught by Chen in view of Jeong to include the ability to switch off a higher-resource intensive protocol and switch off some of the specialized hardware and hardware accelerators that may be needed to run the higher-resource intensive protocol when a temperature threshold is reached, while still operating the lower-resource intensive protocol as taught by Muthiah.
One of ordinary skill in the art would have been motivated to make this modification because responding to reaching the temperature threshold by switching off the higher-resource intensive protocol may prevent the storage device from entering the thermal shutdown zone, may still operate within the temperature, and may allow the host to still access the data as taught by Muthiah in [0022-0023] [0025].
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Chen-Hamano in further view of Applicant Admitted Prior Art (AAPA).
Regarding claim 9:
Chen doesn’t explicitly disclose, but AAPA teaches, wherein the hardware engine is a Global Address Table (GAT) Delta Scan and Eviction (GDSE) hardware engine configured to perform a logical-to-physical flow of search, eviction, and consolidation of logical-to-physical entries (by teaching in the background of the specification that the GDSE is a hardware engine that may be added to improve the capabilities of a storage device by efficiently performing searching of L2P and evicting of logical to physical delta entries [0002]).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the hardware accelerators executing different tasks and being selectively scheduled to execute the tasks in place of the CPU or have the CPU execute the task as taught by Chen-Hamano to include the functionality of the GDSE hardware engine and the tasks it performs as taught by AAPA.
One of ordinary skill in the art would have been motivated to make this modification because it improves the capabilities of the storage device and can address random workloads better as taught by AAPA in [0002].
Subject Matter Free From Prior Art
The subject matter of claims 10-11 was searched for in the prior art, but not found. Accordingly, a prior art rejection has not been made for claims 10-11. However, claims 10-11 are subject to one or more outstanding 35 USC §112(a) or 112(b) rejections and accordingly are not indicated as allowable.
Response to Amendments/Arguments
Applicant’s arguments regarding the claim interpretation under 35 USC §112(f) on [pgs. 11-12, Remarks filed 03 September 2026 (Rem)] have been considered but are not persuasive.
Applicant argues “hardware engine” is not a generic placeholder because it is “known to those skilled in the art to be a dedicated, physical processing component that is designed to execute specific tasks independently of the controller” and “relies on circuits to perform complex operations instantly”. However, Applicant’s characterization is inconsistent with the disclosed architecture. As shown in [Figs. 1 and 9], hardware engines (112) are depicted as components within controller (108). Therefore, the specification does not support Applicant’s assertion that a “hardware engine” is necessarily a dedicated physical component that operates independently of the controller.
Furthermore, the specification in [0035] indicates that the disclosed processes may be performed by a processor executing software instructions, hardware circuitry, or a combination thereof. Accordingly, the specification does not establish that “hardware engine” denotes a particular dedicated circuit structure distinct from a processor/software implementation. Applicant’s assertion that circuitry performs operations “instantly” likewise does not identify any particular structure and is unsupported by the specification. Although [0035] generally refers to hardware circuitry, Applicant has not identified particular circuitry corresponding to the claimed “hardware engine” and [0025-0030] do not disclose any particular circuit architecture or even that the hardware engine or GDSE are implemented with circuitry despite Applicant’s assertion that the structure is “clearly defined” therein.
Therefore, the components of the “hardware engine” and “GDSE engine” are described function rather than by sufficiently definite structure. Accordingly, the 35 USC §112(f) interpretation is maintained and therefore the 35 USC §112(a) and 35 USC §112(b) rejections that dependent from these interpretations are also maintained.
In response to the amendments, the previous objections to the claims have been withdrawn. However, in response to the amendments to the claims, a new objection has been made to claim 20.
Applicant’s arguments regarding the 35 USC §112(a) rejection have been fully considered, but are not persuasive.
Applicant argues in [pgs. 12-13 and 15-16, Rem] that [0026-0029] disclose the determination of efficiency and comparison against operational power. These passages, however, merely state that efficiency may be considered or identify workload characteristics and thresholds used in deciding whether to use the hardware engine. They do not disclose how the claimed efficiency is determine, derived, measured, or compared to operational power. Therefore, Applicant identifies disclosure of the desired result and other determinations unrelated to the determination of an efficiency, but not a mechanism for achieving that result across the full scope of the claimed invention.
Applicant argues in [pgs. 13-14, Rem] that [0026-0027] provide written description support for mechanisms such that the controller can determine whether it can execute the given task within the given time unit with a given level of efficiency and a mechanism so that the controller can instead invoke hardware engine. Although these paragraphs state that the controller may invoke, switch off, or leave the hardware engine idle depending on certain conditions, they do not disclose how the controller determines that it can or cannot execute a task within the claimed time and efficiency requirements, or how invocation of the hardware engine is actually accomplished. Applicant asserts invocation occurs “automatically” provided the hardware engine is not powered off or idled, however, if invocation occurred “automatically” or by default without an affirmative step by the controller, the controller would not need to affirmatively invoke the hardware engine as claimed and furthermore, this method of invocation is not supported anywhere in the specification. Therefore, Applicant again identifies disclosure of the desired result as well as an undisclosed method of accomplishing the result without identifying disclosed mechanisms for achieving the claimed results across the full scope of the claimed invention.
Applicant argues in [pgs. 14-16, Rem] that [0029] [0031-0032] disclose workload thresholds, available resources, and power states as factors for deciding when a controller vs a hardware engine executes a specific task. However, despite those features being identified in the specification, identifying information that may be monitored or used in unrelated decisions of when to execute a hardware engine does not disclose how that information is used to determine the claimed efficiency or produce the claimed result of comparing the efficiency against the operational power. Applicant’s argument for claim 3 in [pgs. 14-15, Rem] noting that [0029] compares a workload characteristic with a workload threshold is not persuasive. The cited disclosure does not describe how the result of that comparison is used to determine the claimed efficiency of the hardware engine. Applicant’s argument for claims 4-5 in [pg. 15, Rem] noting that the specification discloses monitoring an available resource and a power mode or state is similarly not persuasive. Disclosing that these conditions may be evaluated when deciding whether to evoke the hardware engine does not disclose how they are used to determine the claimed efficiency. Furthermore, Applicant’s argument for claim 10 in [pgs. 15-16] noting that the amount of random workload and rate of accumulation of L2P delta entries may be used to determine whether a workload threshold has been reached is similarly not persuasive. This comparison does not explain how that determination itself establishes the claimed efficiency or how it is compared against operational power. Therefore, Applicant again identifies disclosure of the desired result without identifying disclosed mechanisms for achieving the claimed results across the full scope of the claimed invention.
Applicant’s arguments regarding the 35 USC §112(a) rejections primarily identify passages that recite the claimed functions, desired results, or information considered by the controller in an execution on the controller vs. hardware engine determination. However, they do not identify disclosures of the mechanism or implementation by which the claimed efficiency determinations and comparisons to operational power are actually performed, which is the deficiency that was identified in the 35 USC §112(a) rejection of the previous office action. Accordingly, the 35 USC §112(a) written description rejection is maintained.
Applicant’s arguments regarding the 35 USC §112(a) enablement rejections in [pgs. 16-18, Rem] have been considered, but are not persuasive. Applicant identifies particular examples in [0029] [0031-0032] involving determining whether to invoke a hardware engine based on workload thresholds, resource availability, and power states. However, these examples do not teach how those conditions are used to determine “efficiency” in those particular examples or across the full scope of the claims (which allow for determining the efficiency of any “specific task” performed by a hardware engine). Applicant has not explained how one of ordinary skill could extrapolate a rule from the disclosed examples to determine an “efficiency” of the hardware engine in performing any specific task across the full scope of the claims without developing and validating undisclosed relationships between workload, resources, power and efficiency for each particular implementation. Accordingly, Applicant’s arguments do not overcome the undue-experimentation analysis of the Wands factors set forth in the previous office action (and repeated in this one), and the rejection of claims 3-5 and 10 is maintained. The rejection of claims 14-16 are also maintained for analogous reasons.
Applicant’s arguments regarding the 35 USC §112(b) rejections are persuasive for some of the previous 35 USC §112(b) rejections and accordingly, those rejections have been withdrawn. However, Applicant’s amendments have not resolved how the mutually exclusive or contradictory nature of the limitations of claims 6-8 or 17-19. Accordingly, the rejections of those claims are maintained. Furthermore, the amendments do not resolve the 35 USC §112(b) or 35 USC §112(a) rejections based on the 35 USC §112(f) claim interpretation. Accordingly, those rejections are also maintained. Finally, applicant’s amendments introduce ambiguity with respect to how a comparison of a workload to a workload threshold relates to, could be involved in, or helps perform a comparison of an efficiency to an operational power in claim 10 and introduce ambiguity with respect to “a specific task”/”the specific task” recited in claim 20 and accordingly a new 35 USC §112(b) rejection has also been made.
Applicant argues that Humano does not teach “compar[ing] an efficiency of the hardware engine in performing the specific task within a given time unit against the operational power”. The argument is not persuasive under the broadest reasonable interpretation of the limitation. The claim does not recite a particular mathematical operation, common unit of measurement, ratio, or requirement than an efficiency be numerically compared directly to a power value. Rather, in view of the claim language and disclosure (which signifies that comparing workloads to thresholds, comparing thresholds determined by quality of service requirements with workloads, monitoring power states power states, and monitoring availability of resources can all be used to determine “the efficiency of the hardware engine”, which therefore encompasses a broader scope of values than a literal input/output ratio), the limitation is reasonably interpreted as evaluating the efficiency/performance associated with hardware engine execution in relation to the power expenditure associated with such execution in determining whether the task should be executed by the hardware engine or controller. Humano performs such an evaluation. Humano evaluates alternative CPU/accelerator scheduling using execution time (makespan) and energy consumption and employes an energy-delay product as an optimization metric. Because the energy associated with execution is associated with power consumption over execution time, Humano’s scheduling determination jointly accounts for execution performance (time/efficiency) and the power/energy cost (operational power) per unit of time of accelerator execution. Therefore, Human evaluates the relative efficiency of accelerator execution per unit of time in view of the associated power expenditure when determining whether a task should be assigned to the CPU or accelerator, which renders obvious the broadest reasonable interpretation of the claim.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
The paper by Youngmoon Lee et. al., titled, “Thermal-Aware Scheduling for Integrated CPUs—GPU Platforms” from ACM Transactions on Embedded Computing Systems (TECS), Volume 18, Issue 5s, October 2019, pgs. 91:1-90:25 (Lee) – teaches to schedule tasks between a CPU and an accelerator based on a temperature effect of executing the task on the CPU vs the accelerator and an amount of time needed to execute the task.
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 CURTIS JAMES KORTMAN whose telephone number is (303)297-4404. The examiner can normally be reached Monday through Friday 7:30 AM through 4:00 PM MT.
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, Reginald Bragdon can be reached at (571) 272-4204. 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.
/CURTIS JAMES KORTMAN/ Primary Examiner, Art Unit 2139
Prosecution Insights