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 .
Response to Amendment
This office action is in response to the amendment filed on 04/14/2026.
Claims 1-20 are presented for further examination.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Malwankar et al. (US 10,241,722; hereinafter Malwankar) in view of Riska et al. (US 2009/0132754; hereinafter Riska).
Regarding independent claims 1, 12, and 20, taking claim 1 as exemplary analysis,
Malwankar teaches An apparatus (Fig. 1; claim 1, method; claim 19, A non-transitory computer readable storage medium having instructions that, when executed by a processing device of a storage server that manages a plurality of solid state storage devices (SSDs), cause the processing device to), comprising: a plurality of non-volatile memory modules (Fig. 6, SSD 150a~z); and scheduling module (Fig. 1, Management Module 115 & background operations manager 109; col. 6, line 57 – col. 7, line 14, The management module 115 may additionally generate and manage a background operation schedule for the SSDs 150A-Z. Management module 115 may determine the background operation schedule based on a particular array configuration and/or based on information about the SSDs) separate from the plurality of non-volatile memory modules (Fig. 1, SSDs 150A~Z are separate from Management Module 115 & background operations manager 109; col. 6, line 57- col. 7, line 14.
Malwankar clearly discloses a scheduling module (background operations manager 109 and management module 115) located in the storage system controller / storage server, which is separate from the plurality of SSDs 150 (the non-volatile memory modules). The SSDs are distinct drives/enclosures, while the scheduler resides in the upstream controller that manages multiple drives) and operatively coupled to the plurality of non-volatile memory modules (Fig. 1, Management Module 115 coupled to SSDs 150A~Z), the scheduling module configured to:
analyze a set of storage operations to be performed on the plurality of non-volatile memory modules (col. 12, ll. 40-42, when read module 257 receives a request to read data from an SSD, it can first determine the SSD on which the data is stored); and
coordinate a time period for a set of background operations to be performed by a first non-volatile memory module of the plurality of non-volatile memory modules (
col. 6, ll. 59-67 & col. 7, ll. 1-20, Management module 115 may determine the background operation schedule based on a particular array configuration and/or based on information about the SSDs, such as maximum amounts of time for them to complete background operation operations, a minimum frequency for performing background operations, and so on. In some implementations, management module 115 may receive one or more attributes associated with a background operation to be executed by an SSD. For example, management module 115 may receive the duration of a background operation for a particular SSD. Management module 115 may also receive a maximum time interval for executing the background operation (e.g., the maximum amount of time between performing garbage collection operations, which may be equivalent to the minimum frequency for performing the garbage collection operations). Based on this information, management module 115 may allocate a time window for each SSD 150A-Z.).
Malwankar teaches coordinate a time period for a set of background operations based on attributes associated with a background operation including background operation being delayed for a threshold time (col. 11, ll. 50-67, To generate the schedule, scheduling module 261 may receive from an SSD one or more attributes 274 associated with a background operation to be executed by the SSD...the attributes 274 may include a duration of the background operation and/or a maximum interval between background operations (or a minimum frequency of background operations)), however, Malwankar does not expressly teach determine the background operation schedule based on the set of storage operations.
In an analogous art of memory operation scheduling, Riska teaches analyze a set of storage operations to be performed on the plurality of non-volatile memory modules (
[0028], User service requests are also referred to herein as “foreground” requests. Foreground requests are scheduled with a higher priority that “background” requests that are generated internally in the data storage device 134; [0030], The cumulative data histogram 154 comprises a distribution of past lengths of idle times between successive foreground user service requests); and
coordinate a time period for a set of background operations to be performed by a first non-volatile memory module of the plurality of non-volatile memory modules based on the set of storage operations ([0033], The schedule circuit 160 schedules background service requests 162 following a user service request (such as user service request 142) after a time delay that is controlled by the schedule circuit 160 as a schedule function 168 of the cumulative data histogram 154 and a calculated maximum length 164 of a busy time of the background service request 162. In case a user foreground job arrives before the maximum background busy time is reached, the algorithm allows the current background job to finish, but no additional background jobs are started).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention was made, with the teachings of Malwankar and Riska before them, to incorporate Riska’s scheduling background service requests based on idle times between successive foreground requests because of higher priorities to meet user requests and foreground service average performance target (Riska [0034]-[0035]).
Regarding claim(s) 2 and 13, the combination of Malwankar and Riska further teaches wherein to coordinate the time period the processing device is further configured to: determine a schedule based on one or more of the set of storage operations and the set of background operations (Riska [0033], The schedule circuit 160 schedules background service requests 162 following a user service request (such as user service request 142) after a time delay that is controlled by the schedule circuit 160 as a schedule function 168 of the cumulative data histogram 154 and a calculated maximum length 164 of a busy time of the background service request 162).
Regarding claim(s) 3 and 14, the combination of Malwankar and Riska further teaches wherein to coordinate the time period the processing device is further configured to: transmit a token to the first non-volatile memory module, wherein the token grants the first non-volatile memory module permission to perform the set of background operations during the time period (Malwankar, col. 12, ll. 17-35, scheduling module 261 may send the notification to the SSD at the start of the time window, where the SSD is to perform the background operation responsive to receiving the notification. Thus, scheduling module 261 can send a notification each time a background operation is to be performed based on the generated schedule).
Regarding claim(s) 4 and 15, the combination of Malwankar and Riska further teaches wherein to coordinate the time period the processing device is further configured to: transmit a message to the first non-volatile memory module indicating the time period (Malwankar, col. 12, ll. 17-35, scheduling module 261 may send the notification to the SSD at the start of the time window, where the SSD is to perform the background operation responsive to receiving the notification. Thus, scheduling module 261 can send a notification each time a background operation is to be performed based on the generated schedule. In some implementations, scheduling module 261 may send a notification to the SSD that includes the schedule of multiple time windows allocated to the SSD for performing background operations. In this implementation, scheduling module 261 may send the notification to the SSD prior to the first time window in the schedule so that the SSD may perform the background operations according to the time windows in the schedule).
Regarding claim(s) 5 and 16, the combination of Malwankar and Riska further teaches wherein the time period is based on a requested time period received from the first non-volatile memory module (Malwankar, col. 11, ll. 50-67, To generate the schedule, scheduling module 261 may receive from an SSD one or more attributes 274 associated with a background operation to be executed by the SSD...the attributes 274 may include a duration of the background operation and/or a maximum interval between background operations (or a minimum frequency of background operations)).
Regarding claim(s) 6, the combination of Malwankar and Riska further teaches wherein the processing device is located on a first storage node of a storage system and the plurality of non-volatile memory modules are located on a second storage node of the storage system (Malwankar, Fig. 1, I/O controller is on a first node; SSD is on a second node).
Regarding claim(s) 7 and 17, the combination of Malwankar and Riska further teaches wherein the first non-volatile memory module refrains from performing the set of background operations until the time period (Malwankar, col. 7, ll. 15-17, Each SSD 150A-Z performs background operations during their allotted time windows, and refrains from performing background operations outside of the allotted time windows).
Regarding claim(s) 8, the combination of Malwankar and Riska further teaches wherein the set of background operations are performed by the first non-volatile memory module outside of the time period when the set of background operations have been delayed for a threshold time (Riska discusses trade-offs in background task urgency, priority-based scheduling and preemption ([0028], [0030]-[0035], [0050]-[0055]).
Malwankar’s system monitors ongoing operations and can adjust for high-priority maintenance needs (col. 6 lines 30-55). A POSITA would recognize the benefit of urgent overrides in a real-world storage system).
Regarding claim(s) 9, the combination of Malwankar and Riska further teaches wherein the set of background operations are performed by the first non-volatile memory module outside of the time period when the set of background operations have been delayed for a threshold time (Malwankar col. 11, ll. 50-67, To generate the schedule, scheduling module 261 may receive from an SSD one or more attributes 274 associated with a background operation to be executed by the SSD...the attributes 274 may include a duration of the background operation and/or a maximum interval between background operations (or a minimum frequency of background operations)).
Regarding claim(s) 10 and 18, the combination of Malwankar and Riska further teaches wherein the processing device is further configured to: receive a message indicating the set of background operations from first non-volatile memory module (Riska [0032], background service requests 162 and calculated busy time lengths 164 associated with each background service request 162); and determine the time period based on the message ([0033], The schedule circuit 160 schedules background service requests 162 following a user service request (such as user service request 142) after a time delay that is controlled by the schedule circuit 160 as a schedule function 168 of the cumulative data histogram 154 and a calculated maximum length 164 of a busy time of the background service request 162).
Regarding claim(s) 11 and 19, the combination of Malwankar and Riska further teaches wherein the processing device is further configured to: coordinate a second time period for a second set of background operations to be performed by a first non-volatile memory module based on the set of storage operations (Riska, [0052], The algorithm distinguishes between infinite amount of background work (for example repeating background media scans) and finite amount of background work), wherein the set of background operations are for a first schedulable unit of the first non-volatile memory module and the second set of background operations are for a second schedulable unit of the first non-volatile memory module (Riska, [0053], For infinite amount of background work, the goal is to complete as much as possible background work. So the tuple (IW, TE) is chosen to maximize the amount of work that can be accomplished; [0054], For finite amount of background work, the goal is to complete the required amount of work as fast as possible. This means that the tuple (IW, TE) should be the one that ensure work completion with the shortest amount of IW).
Response to arguments
APPLICANT’S ARGUMENTS – independent claims 1, 12 and 20:
Malwankar fails to teach or suggest this limitation. The Examiner cites Malwankar as disclosing scheduling background operations (see Malwankar, col. 6, 11. 59-67; col. 7, 11. 1-20), and allocating time windows based on background operation characteristics (col. 11, 11. 50-67). However, Malwankar explicitly determines scheduling based on attributes of background operations such as duration and frequency (col. 11, 11. 50-67), not based on a set of storage operations to be performed. Further, Malwankar's management module operates within the storage system controller and assigns schedules to individual drives (col. 12, 11. 17-35). There is no teaching of a scheduling module that is separate from the memory modules and that coordinates execution across multiple modules. Riska similarly fails to cure these deficiencies. Riska describes initiating background operations based on idle time between foreground requests and statistical workload characteristics (see Riska [0030], [0033]). Riska's scheduling is reactive and triggered by detected idle periods rather than based on analysis of a set of storage operations to be performed. Additionally, neither reference teaches coordination across a plurality of non- volatile memory modules as required by the claims. Malwankar assigns schedules to individual drives (col. 12, 11. 17-35) without coordinating across multiple devices, and Riska similarly operates at the level of a single device or controller ( [0033]). The amended claims now require coordination across multiple modules by a separate scheduling module, which is not disclosed or suggested in the cited art. The claimed coordination of a time period is also not taught or suggested. Malwankar allocates schedules based on operation characteristics (col. 11, 11. 50-67) but does not disclose coordinated time periods enforced across multiple modules, and Riska relies on detecting idle time ( [0033]) rather than assigning or coordinating execution windows. The cited art therefore fails to disclose or suggest the claimed coordination of time periods… there is no teaching or suggestion in either reference that would lead one of ordinary skill in the art to modify Malwankar to include a scheduling module separate from the memory modules that coordinates time periods across multiple modules based on a set of storage operations. The rejection therefore relies on impermissible hindsight reconstruction using Applicants' disclosure.
RESPONSE TO APPLICANT’S ARGUMENTS
Applicant’s arguments have been carefully considered but are not persuasive.
1. Malwankar Teaches Analysis of Storage Operations and Coordination of Time Periods
Applicant argues that Malwankar only schedules based on background operation attributes (duration, frequency) and not on “a set of storage operations to be performed.” This is incorrect. Malwankar’s background operations manager/scheduling module operates in the context of ongoing host I/O (storage operations) and explicitly takes the current and expected foreground workload into account when generating and assigning background schedules. The system proactively schedules background windows to minimize interference with host reads/writes — the very definition of basing the coordination on the set of storage operations. (See Malwankar, col. 6, ll. 59–67; col. 7, ll. 1–20; col. 8, ll. 30–55; col. 9, ll. 10–40.) The fact that Malwankar also considers background characteristics (duration, frequency) does not negate that it further bases scheduling decisions on the host/storage operation workload. A reference is not required to teach every limitation in isolation; the combination with Riska strengthens the analysis of foreground patterns.
2. Separate Scheduling Module
Fig. 1, SSDs 150A~Z are separate from Management Module 115 & background operations manager 109; col. 6, line 57- col. 7, line 14.
Malwankar clearly discloses a scheduling module (background operations manager 109 and management module 115) located in the storage system controller / storage server, which is separate from the plurality of SSDs 150 (the non-volatile memory modules). The SSDs are distinct drives/enclosures, while the scheduler resides in the upstream controller that manages multiple drives. This satisfies the “separate from the plurality of non-volatile memory modules” limitation. Applicant’s narrow interpretation that the scheduler must be on an entirely different physical node is not required by the claim language.
3. Coordination Across a Plurality of Modules
Malwankar explicitly teaches array-level / multi-SSD management where the central scheduler assigns background schedules across multiple SSDs to optimize overall system performance and avoid simultaneous background activity that would degrade host I/O. The system coordinates which drives perform background work and when, including the use of RAID reconstruction when one drive is in background mode. This constitutes coordination across a plurality of modules. (See Figs. 1-2, col. 4, ll. 24–67, col. 6-7)
Riska supplements this by teaching sophisticated workload analysis (histogram of idle times between foreground requests) for determining when background work should occur, which a POSITA would naturally apply to Malwankar’s multi-drive scheduler for improved results.
4. “Coordinated Time Periods” and Enforcement
Applicant asserts that neither reference teaches “coordinated time periods.” This is unpersuasive.
Malwankar discloses generating and distributing schedules that include specific time windows/slots during which individual SSDs are permitted (and expected) to perform background operations. The SSDs operate according to the assigned windows. (col. 11, ll. 50–67; col. 7–8.)
Riska teaches determining precise timing and duration of background busy periods based on analysis of foreground activity.
The combination clearly suggests coordinated, assigned time periods across modules. The claims do not require “enforcement” mechanisms beyond what is taught; the references render obvious modules that follow the centrally coordinated schedule.
No motivation to combine / hindsight
Both Malwankar and Riska address the same problem: minimizing interference between foreground I/O and background operations.
Riska provides a known solution: scheduling operations in appropriate time periods.
Applying this to Malwankar would improve system performance, reduce contention and enhance predictability. This is a classic KSR-compliant combination: applying a known technique to improve a similar system. No hindsight is required.
Amended Claims
To the extent the claims have been amended to emphasize “coordination across multiple modules by a separate scheduling module,” the combination of Malwankar (multi-SSD central scheduler) and Riska (advanced workload-aware timing) still reads on the claims. The amendments do not introduce new distinctions sufficient to overcome the rejection.
APPLICANT’S ARGUMENTS – claims 3 and 14:
Applicant’s arguments regarding claim 3 have been fully considered but are not persuasive.
Response to Argument on the “Token” Limitation
Applicant argues that neither Malwankar nor Riska teaches or suggests “transmit[ting] a token to the first non-volatile memory module, wherein the token grants the first non-volatile memory module permission to perform the set of background operations during the time period.”
This argument is unpersuasive for the following reasons:
Malwankar explicitly discloses that the scheduling module sends a notification to the SSD at the start of the scheduled time window, and that the SSD is configured to perform the background operation responsive to receiving the notification (Malwankar, col. 12, ll. 17-35). This notification directly grants the SSD permission to proceed with the background operations during the coordinated time period and effectively instructs the SSD that it may now execute the scheduled background work. The claimed “token” is a specific implementation of a permission-granting control message. In the field of computer systems and scheduling, a token is a well-known mechanism for granting temporary permission or access rights to a resource or operation. Sending a notification that triggers and authorizes the performance of background operations during a specific window is functionally equivalent to transmitting a token that grants permission. It would have been obvious to a person of ordinary skill in the art to implement Malwankar’s notification as a “token” (or any similar permission-granting message) because:
Tokens (or permission messages) are a standard, routine way to implement coordinated scheduling and mutual exclusion in distributed or multi-component systems.
The result would have been predictable — the SSD would only perform background operations when it receives the authorizing token/notification during its assigned window.
No unexpected results are alleged or apparent.
Riska further supports the use of intelligent, workload-driven decisions for when to authorize background work, which a POSITA would naturally apply when designing the content and timing of Malwankar’s notifications/tokens. The claimed “explicit control protocol” and “enforcement of coordinated execution windows” are taught by Malwankar’s centralized scheduler that distributes time-window-specific notifications to which the SSDs respond by performing (or refraining from) background operations. The label “token” does not patentably distinguish over the prior art’s disclosure of a permission-granting notification tied to a scheduled time period. The combination of Malwankar’s multi-SSD scheduling architecture (with explicit notifications tied to time windows) and Riska’s workload-analysis techniques for determining when such windows should occur fully renders obvious the subject matter of claims 3 and 14.
APPLICANT’S ARGUMENTS – claims 4 and 15:
Applicant’s arguments regarding claim 4 have been fully considered but are not persuasive.
Response to Argument on the “Transmit a Message Indicating the Time Period”
Applicant contends that Malwankar does not disclose transmitting a message that explicitly defines a start and end time for background operations, and that the cited art uses only implicit or internally determined scheduling. This argument is unpersuasive for several reasons:
First, claim 4 does not require that the message “explicitly defines a start and end time.” The claim merely recites “transmit a message to the first non-volatile memory module indicating the time period.” This is a broad limitation that is satisfied by any message that conveys or identifies when the background operations are permitted or scheduled to occur. Malwankar teaches exactly this: “scheduling module 261 may send the notification to the SSD at the start of the time window, where the SSD is to perform the background operation responsive to receiving the notification.” “In some implementations, scheduling module 261 may send a notification to the SSD that includes the schedule of multiple time windows allocated to the SSD for performing background operations. In this implementation, scheduling module 261 may send the notification to the SSD prior to the first time window in the schedule so that the SSD may perform the background operations according to the time windows in the schedule.”(Malwankar, col. 12, ll. 17-35)
Sending a notification that identifies specific time windows (or a full schedule of such windows) in advance clearly constitutes transmitting a message indicating the time period during which the SSD is permitted to perform background operations. The SSD then executes according to the communicated schedule. This meets the claim language.
Second, the fact that Malwankar’s scheduler also considers background operation characteristics does not negate the disclosure of communicating scheduled time periods. The reference expressly teaches proactive, advance communication of the schedule from the central scheduling module to the individual SSDs.
Riska supplements Malwankar by teaching detailed, workload-aware determination of when background operations should be performed (via histogram analysis of foreground idle times).
A person of ordinary skill would have found it obvious to communicate the resulting time periods via the notification/schedule message already taught by Malwankar.
Additionally, the claimed mechanism is not “fundamentally different” from Malwankar’s teaching. Both involve a separate scheduling entity deciding when background work should occur and communicating that decision to the memory module(s) so the module can act accordingly. Applicant’s attempt to import unrecited limitations (such as “explicit start and end time” in every message, or mandatory “enforcement” protocol) is improper. The claim only requires a message indicating the time period.
For these reasons, and those previously set forth with respect to independent claim 1, the combination of Malwankar and Riska renders obvious the subject matter of claims 4 and 15.
APPLICANT’S ARGUMENTS – claims 7 and 17:
Applicant’s arguments have been fully considered but are not persuasive.
Response to Argument on the “Refrains from Performing” Limitation
Applicant asserts that neither Malwankar nor Riska teaches or suggests “enforcing a restriction” or a “prohibition” that prevents background operations from executing outside the coordinated time window, and that the cited art lacks centralized control and enforcement. This argument is unpersuasive because it attempts to import unrecited limitations into the claim.
Claim 7 does not require any specific “enforcement mechanism,” “prohibition,” centralized policing, or technical implementation details that actively block operations. It simply requires that the first non-volatile memory module refrains from performing the background operations until the coordinated time period. Malwankar expressly discloses this limitation:
“Each SSD 150A-Z performs background operations during their allotted time windows, and refrains from performing background operations outside of the allotted time windows.”(Malwankar, col. 7, ll. 15-17)
This is a direct teaching that the SSDs (non-volatile memory modules) follow the schedule established by the separate scheduling module and refrain from executing background operations outside their assigned time windows. The reference thus teaches the exact behavior recited in claim 7. The fact that Malwankar achieves this coordinated behavior through the SSDs operating according to the centrally provided schedule is sufficient. When a reference teaches that modules perform operations during allotted windows and refrain outside those windows, it satisfies the claim language. Applicant’s arguments regarding the lack of an explicit “enforcement mechanism” are irrelevant because no such mechanism is claimed. Riska further supports the overall obviousness by teaching intelligent workload-based decisions for when background operations should (and should not) be performed, which a person of ordinary skill would apply when implementing the scheduled, restrained behavior already taught in Malwankar.
APPLICANT’S ARGUMENTS – claims 10 and 18:
Applicant’s arguments have been fully considered but are not persuasive.
Response to Argument on Bidirectional Communication / Message Reception
Applicant argues that the cited references do not disclose bidirectional communication, receiving requests from memory modules for scheduling, or a “negotiation or coordination protocol.” This argument is unpersuasive because it imports unrecited limitations into the claim. Claim 10 does not require “requests for permission,” “negotiation,” a formal “protocol,” or any specific type of bidirectional handshake. It merely requires that the processing device/scheduling module is configured to:
Receive a message indicating the set of background operations from the first non-volatile memory module; and
Determine the time period based on that message.
Riska teaches both elements: Riska discloses a schedule circuit that receives background service requests 162 (messages indicating pending background operations) along with calculated busy time lengths 164 associated with each request (Riska, para. [0032]). The schedule circuit then determines/schedules the time period for executing those background service requests based on the received information, using the cumulative data histogram and the reported busy time lengths (Riska, para. [0033]).This constitutes receiving a message indicating the set of background operations and determining the coordinated time period based on that message.
Malwankar further supports this: Malwankar’s SSDs report attributes and characteristics of pending or required background operations (e.g., duration, frequency, type) to the central scheduling module, which uses that information when generating the overall schedule (Malwankar, col. 11, ll. 50-67). This reporting from the memory modules to the separate scheduling module provides the necessary input for time-period coordination.
The combination of Malwankar’s centralized architecture (where modules communicate background needs/attributes to the scheduler) with Riska’s explicit disclosure of receiving background service requests and using them to schedule execution times fully renders obvious the subject matter of claim 10. Applicant’s characterization of the claimed feature as requiring a sophisticated “negotiation or coordination protocol” is not supported by the claim language. The claim is satisfied by the routine exchange of background operation information from the memory module to the scheduling module, followed by the scheduler’s determination of an appropriate time window — precisely what the combination of references teaches.
APPLICANT’S ARGUMENTS – claims 11 and 19:
Applicant’s arguments have been fully considered but are not persuasive.
Response to Argument on “Schedulable Units”
Applicant argues that neither Malwankar nor Riska teaches coordination at the granularity of “schedulable units” (e.g., dies) within a single memory module, and that both references operate only at the whole-device level. This argument is unpersuasive for multiple reasons:
First, claim 11 does not recite “dies” or any specific hardware structure. It uses the broad term “schedulable unit” of the first non-volatile memory module. This encompasses any distinguishable portion of a memory module that can be scheduled for background operations independently or semi-independently (e.g., different background tasks, different regions, different work queues, or different internal resources).
Riska explicitly teaches scheduling multiple distinct background operations (or sets of background operations) with different parameters and goals on the same device:
Riska distinguishes between different types of background work — for example, infinite background work (such as repeating media scans) versus finite background work (para. [0052]).
For each type, Riska calculates different scheduling tuples (IW, TE) — idle wait time and execution time — with different optimization goals: maximizing work for infinite tasks versus completing finite tasks as quickly as possible (see [0053]–[0054]).
The schedule circuit applies these differing time periods to the respective background service requests on the same storage device.
This directly maps to coordinating a first time period for a first set of background operations on a first schedulable unit and a second (different) time period for a second set on a second schedulable unit of the same module. Malwankar provides the overarching architecture of a separate scheduling module that coordinates time windows across resources based on storage operations. It would have been obvious to a person of ordinary skill in the art to apply this coordination at the sub-module level (different schedulable units within one SSD), because:
Modern solid-state drives contain significant internal parallelism (multiple dies, planes, channels, LUNs), which are routinely managed as independent or semi-independent schedulable units.
Applying Riska’s differentiated scheduling policies (different (IW, TE) tuples for different classes of background work) to different internal units within Malwankar’s multi-module system yields the predictable benefit of finer-grained control over latency and throughput.
A POSITA would have been motivated to extend the scheduling to internal schedulable units to achieve better performance isolation and efficiency inside high-parallelism flash modules — a well-known design goal in storage systems. Applicant’s narrow reading that coordination must be limited to entire devices only is not supported by the claim language and is contrary to the teachings of the references. For the reasons set forth above and in previous responses regarding the independent claims, the combination of Malwankar and Riska renders obvious the subject matter of claims 11 and 19.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. 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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRACY C CHAN whose telephone number is (571)272-9992. The examiner can normally be reached on Monday - Friday 10 AM to 6 PM EST.
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, TIM VO can be reached on (571)272-3642. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/TRACY C CHAN/ Primary Examiner, Art Unit 2138
Prosecution Insights