DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. Claims 1–20 are pending for examination in the reply filed on 11/14/2025.
Examiner’s Remarks
3. Examiner refers to and explicitly cites particular pages, sections, figures, paragraphs or columns and lines in the references as applied to Applicant’s claims to the extent practicable to streamline prosecution.
Although the cited portions of the references are representative of the best teachings in the art and are applied to meet the specific limitations of the claims, other uncited but related teachings of the references may be equally applicable as well. It is respectfully requested that, in preparing responses to the rejections, the Applicant fully considers not only the cited portions of the references, but also the references in their entirety, as potentially teaching, suggesting or rendering obvious all or one or more aspects of the claimed invention.
Abbreviations
4. Where appropriate, the following abbreviations will be used when referencing Applicant’s submissions and specific teachings of the reference(s):
i. figure / figures: Fig. / Figs.
ii. column / columns: Col. / Cols.
iii. page / pages: p. / pp.
References Cited
5. (A) Dutta et al., US 2024/0195870 A1 (“Dutta”).
(B) Martin et al., US 10,254,970 B1 (“Martin”).
(C) Kathmann et al., US 2012/0303913 A1 (“Kathmann”)
(D) Maciocco et al., US 2021/0014133 A1 (“Maciocco”).
Dutta, Kathmann, and Maciocco were cited in the previous Office action.
Notice re prior art available under both pre-AIA and AIA
6. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 of this title, 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.
A.
7. Claims 1–7 and 10–20 are rejected under 35 U.S.C. 103 as being unpatentable over (A) Dutta in view of (B) Martin and (C) Kathmann.
See “References Cited” section, above, for full citations of references.
8. Regarding claim 1, (A) Dutta teaches/suggests the invention substantially as claimed, including:
“A method comprising:
providing, by a storage system, a first storage resource for use by an application on a container system, the first storage resource satisfying a first storage profile of a storage provision request”
(¶ 21: issue a request to provision a storage volume on a storage array;
¶ 22: issue a request to create, update, or delete a storage volume, where the request contains information of characteristics relating to the storage volume. In response to a request to create the storage volume, the fleet storage provider can provision the storage volume on a storage array (or multiple storage arrays) of the fleet of storage arrays in response to the request;
¶ 27: An entity (such as a user, a program, or a machine) can request that a storage volume ( or multiple storage volumes) be provisioned in a fleet of storage arrays. “Provisioning” a storage volume in a fleet of storage arrays can refer to creating the storage volume and configuring the storage volume such that the storage volume is ready to store data and to receive requests to access data;
¶¶ 64–67: The input information supplied with a request to create a storage volume can include the following information … the input information can further include a parameter that represents a quantity of storage volumes ( of the respective application type and storage volume size) to be provisioned, where the “quantity” can be 1 or more than 1;
¶¶ 69–71: In response to the input information, the intent-based provisioning logic generates a workload profile that includes one or more characteristics of a workload to be performed with respect to the storage volume that is to be provisioned. The workload profile can include any or some combination of the following information: a rate of I/O operations, which can be expressed as IOPS, a read/write ratio, an I/O size, and so forth. As noted above, the workload profile represents an I/O pattern of the workload for the storage volume.
Based on the intent expressed by the input information, the intent-based provisioning logic 150 can recommend a selected placement of the storage volume on one or more storage arrays of the fleet of storage arrays;
¶ 37: control plane 108 can issue requests to create, update, and/or delete storage volumes 114 for use by programs running in the containers 112;
¶ 38: Mounting a storage volume to a container or pod can refer to making available the storage volume for use by programs running in the containers 112 of the compute nodes 110;
¶ 55: The container application 302 can be used to access data stored at the fleet of storage arrays).
“the first storage profile defining one or more characteristics of a volume included in the storage provision request”
(¶ 22: issue a request to create, update, or delete a storage volume, where the request contains information of characteristics relating to the storage volume. In response to a request to create the storage volume, the fleet storage provider can provision the storage volume on a storage array (or multiple storage arrays) of the fleet of storage arrays in response to the request).
Dutta teaches “application is running on the container system” (¶ 38: Mounting a storage volume to a container or pod can refer to making available the storage volume for use by programs running in the containers 112 of the compute nodes 110).
Dutta does not teach “determining, by the storage system, a second storage profile that optimizes usage of data storage by the application; and
providing, by the storage system … a second storage resource for use by the application, the second storage resource satisfying the second storage profile.”
(B) Martin however teaches or suggests:
“determining, by the storage system, a second storage profile that optimizes usage of data storage by the application, the second storage profile different from the first storage profile”
(Col. 13, lines 42–60: The data portions may also be automatically relocated or moved to a different storage tier as the work load and observed performance characteristics for the data portions change over time … take into account how “busy” the data portions are in combination with defined capacity limits and defined performance limits (e.g., such as I/O throughput or I/Os per unit of time, response time, utilization, and the like) associated with a storage tier in order to evaluate which data to store on drives of the storage tier.
Promotion may refer to movement of data from a first storage tier to a second storage tier where the second storage tier is characterized as having devices of higher performance than devices of the first storage tier;
Col. 24, lines 1–5: As the I/O workload may change dynamically over time, the data storage optimizer may continuously evaluate and perform data movement optimizations between different storage tiers as needed responsive to such changing workloads);
“providing, by the storage system … a second storage resource for use by the application, the second storage resource satisfying the second storage profile”
(Col. 13, lines 42–60: The data portions may also be automatically relocated or moved to a different storage tier as the work load and observed performance characteristics for the data portions change over time … take into account how “busy” the data portions are in combination with defined capacity limits and defined performance limits (e.g., such as I/O throughput or I/Os per unit of time, response time, utilization, and the like) associated with a storage tier in order to evaluate which data to store on drives of the storage tier.
Promotion may refer to movement of data from a first storage tier to a second storage tier where the second storage tier is characterized as having devices of higher performance than devices of the first storage tier).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of (B) Martin with those of (A) Dutta to automatically migrate data between different storage tiers. The motivation or advantage to do so is to manage the storage of data based on changing storage and/or workload performances and data requirements/metrics.
Dutta and Martin do not teach “providing, by the storage system and while the application
is running on the container system, a second storage resource for use …”
(C) Kathmann, in the context of Dutta and Martin’s teachings, teaches or suggests:
“providing, by the storage system and while the application is running on the container system, a second storage resource for use …”
(¶ 6: A write request to write data to the source physical storage location is received prior to or during the migrating. The write request is serviced contemporaneously with the migrating;
¶ 25: concurrent access to the data in the LFS from multiple processes running on multiple, tightly coupled computer systems is supported throughout the migration progress;
¶ 42: FIG. 5 depicts a process flow of a first phase of a migration in accordance with an embodiment. During this phase, data is copied from the source volume to the target volume as quickly as possible without disrupting runtime I/O to the source volume or the target volume;
¶ 43: While the copying in block 506 is being performed, block 508 is performed to monitor I/Os to the source volume).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of (C) Kathmann with those of Dutta and Martin to support the concurrent access of data by the applications during data migration. The motivation or advantage to do so is to provide automated, transparent file migration without disrupting (suspending) real-time data access.
9. Regarding claim 2, Dutta, Martin, and Kathmann teach or suggest:
“moving, while the application is running on the container system, data associated with the application from the first storage resource to the second storage resource”
(Dutta, ¶ 38: Mounting a storage volume to a container or pod can refer to making available the storage volume for use by programs running in the containers 112 of the compute nodes 110;
Martin, Col. 13, lines 42–60: The data portions may also be automatically relocated or moved to a different storage tier as the work load and observed performance characteristics for the data portions change over time;
Kathmann, ¶¶ 6, 25, 42, and 43, teaching concurrent access to the data throughout the migration progress).
10. Regarding claim 3, Dutta, Martin, and Kathmann teach or suggest:
“moving, based on the usage of data storage by the application and while the application is running on the container system, data associated with the application between the first storage resource and the second storage resource”
(Dutta, ¶ 38: Mounting a storage volume to a container or pod can refer to making available the storage volume for use by programs running in the containers 112 of the compute nodes 110;
Martin, Col. 13, lines 42–60: The data portions may also be automatically relocated or moved to a different storage tier as the work load and observed performance characteristics for the data portions change over time;
Col. 7, lines 17–24: the migration rule management module 340 may manage which attributes of the volumes and the storage tiers are to be monitored. For example, a user may specify I/O latency, I/O errors, and throughput as attributes of the volumes to be monitored. Accordingly, migration of the data stored within the tiers may be based on these monitored attributes;
Kathmann, ¶¶ 6, 25, 42, and 43, teaching concurrent access to the data throughout the migration progress).
11. Regarding claim 4, Martin teaches or suggests:
“wherein the determining the second storage profile is based on a user-defined policy”
(Col .28, lines 46–51: A user may be allowed to specify whether to have the SP's performance goals modified in accordance with a selection of faster or cheaper. If the user selects faster, the SP performance goal 50 target percentage range may be modified from 50-70% to 90-95%;
Col. 36, lines 44–55: SP performance goals may be set by the user).
12. Regarding claim 5, Martin teaches or suggests:
“wherein the determining the second storage profile is based on monitoring usage of the first storage resource”
(Col. 13, lines 42–60: The data portions may also be automatically relocated or moved to a different storage tier as the work load and observed performance characteristics for the data portions change over time;
Col. 51, lines 1–17: SG Performance: Look for SGs that are missing their performance objections. SGs may be ranked with respect to performance violations … In this case, processing may be performed to produce a vector to move one or more data portions of SG1 to a higher performance SP that will result in SG1 increasing the observed percentage of I/Os having an RT less than 2 ms).
13. Regarding claim 6, Martin teaches or suggests:
“wherein the determining the second storage profile is based on a characteristic of the application”
(Col. 28, lines 53–62: Performance criteria for each SG may be vary with each application and may be based on the particular customized performance expectations or requirements of each application;
Col. 54, lines 1–5: Acquisition of high performance resources (higher expected RT objectives) may be driven by the SG or application’s performance targets and may drive promotion of data portions).
14. Regarding claim 7, Dutta and Martin teaches or suggests:
“wherein the determining the second storage profile is further based on an additional characteristic of an additional application running on the container system, where the additional characteristic is similar to the characteristic”
(Dutta, ¶ 38: teaching programs running in the containers of the compute nodes using storage volumes;
Martin, Col. 51, lines 1–17: SG Performance: Look for SGs that are missing their performance objections. SGs may be ranked with respect to performance violations … In this case, processing may be performed to produce a vector to move one or more data portions of SG1 to a higher performance SP that will result in SG1 increasing the observed percentage of I/Os having an RT less than 2 ms;
Col. 59, lines 2–14: determine whether the cumulative response time distribution for all SPs being managed is within a stable range (as may be expressed using the percentage range for an SP) while also satisfying the performance goals of the current applications or SGs;
Col. 60, lines 64–67: As applications attempt to add or move data portions into an SP, preference for data movement may be given to the data portions having one of the preferred I/O types specified for the particular target SP over other data portions).
15. Regarding claim 10, Dutta and Martin teach or suggest:
“wherein the determining the second storage profile is based on historical usage of data
storage by the application”
(Dutta, ¶ 71: historical workload information can be collected for storage arrays deployed at various different sites, such as at sites of different enterprises. A monitoring system can track various characteristics of workloads executed in the storage systems, including application type, storage volume size, IOPS, read/write ratio, I/O size, and so forth.
Martin, Col. 13, lines 42–60: The data portions may also be automatically relocated or moved to a different storage tier as the work load and observed performance characteristics for the data portions change over time … take into account how “busy” the data portions are in combination with defined capacity limits and defined performance limits (e.g., such as I/O throughput or I/Os per unit of time, response time, utilization, and the like) associated with a storage tier in order to evaluate which data to store on drives of the storage tier;
Col. 27, lines 25–45: storage tiers and SPs may be classified using criteria including the expected average RT … to obtain information regarding performance of such external PDs in terms of expected average RT. For example, the second data storage system may obtain such estimates based on observed measurements obtained in connection with actually sending I/Os to the external data storage system;
Col. 28, lines 25–28: Multiple tiers may be so defined based on different expected average RTs, RT ranges, and the like).
16. Regarding claim 11, Dutta and Martin teach or suggest:
“wherein the first storage resource is associated with a first storage pool of storage resources and the second storage resource is associated with a second storage pool of storage resources different from the first storage pool”
(Dutta, ¶ 10–12: Storage arrays can have different features. For example, storage arrays may include different types of storage devices, where some storage arrays can employ disk-based storage devices, while other storage arrays can employ solid-state drives or other types of storage devices …
Storage arrays with different features such as those noted above are of different storage types. In other words, a first storage array of a first storage type has a first collection of features (a single feature or multiple features) that differs from a second collection of features (a single feature or multiple features) of a second storage array of a second storage type different from the first storage type;
Martin, Col. 51, lines 1–17: SG Performance: Look for SGs that are missing their performance objections. SGs may be ranked with respect to performance violations … In this case, processing may be performed to produce a vector to move one or more data portions of SG1 to a higher performance SP that will result in SG1 increasing the observed percentage of I/Os having an RT less than 2 ms;
Fig. 8A and Col. 21, lines 51–55: three storage pools 712, 714 and 716 with each such pool representing a storage pool of a different storage tier).
17. Regarding claim 12, Dutta, Martin, and Kathmann teach or suggest:
“the storage provision request comprises a volume provision request”
(Dutta, ¶ 21: issue a request to provision a storage volume on a storage array;
¶ 22: issue a request to create, update, or delete a storage volume, where the request contains information of characteristics relating to the storage volume. In response to a request to create the storage volume, the fleet storage provider can provision the storage volume on a storage array (or multiple storage arrays) of the fleet of storage arrays in response to the request;
¶ 27: An entity (such as a user, a program, or a machine) can request that a storage volume ( or multiple storage volumes) be provisioned in a fleet of storage arrays. “Provisioning” a storage volume in a fleet of storage arrays can refer to creating the storage volume and configuring the storage volume such that the storage volume is ready to store data and to receive requests to access data;
¶¶ 64–67: The input information supplied with a request to create a storage volume can include the following information … the input information can further include a parameter that represents a quantity of storage volumes ( of the respective application type and storage volume size) to be provisioned, where the “quantity” can be 1 or more than 1)
“the providing the first storage resource comprises providing a storage volume associated with the first storage resource;”
(Dutta, ¶ 27: An entity (such as a user, a program, or a machine) can request that a storage volume ( or multiple storage volumes) be provisioned in a fleet of storage arrays. “Provisioning” a storage volume in a fleet of storage arrays can refer to creating the storage volume and configuring the storage volume such that the storage volume is ready to store data and to receive requests to access data. A storage volume can be provisioned on one or more storage arrays, which means that data of the storage volume is physically stored in the one or more storage arrays);
“the providing the second storage resource comprises associating the storage volume with the second storage resource”
(Martin, Col. 10, lines 40–44: a host side logical device or volume is mapped to one or more data storage system logical devices as presented to the host;
Fig. 4 and Col. 15, lines 14–17: storage system 151 may include a storage array 124 having multiple directors 130-132 and multiple storage volumes (LUNs, LVs, logical devices or VOLUMES 0-3) 110-113;
Kathmann, ¶¶ 46–47: Before migration, volume 2 in the mapping 204 is mapped to physical volume 206d and volume 1 in the mapping 204 is mapped to physical volume 206b. During migration volume 1 in the mapping 204 has two simultaneous mappings-one is to physical volume 206b and another is to a subset of physical volume 206d. This mapping is implemented via control information maintained for volume 1 in the mapping. Depending on the state of the migration, runtime I/O will use one or another of these two mappings when issuing physical I/O for a logical I/O to volume 1 in the mapping 204).
18. Regarding claim 13, Dutta and Martin teach or suggest:
“the storage provision request comprises a volume provision request”
(Dutta, ¶ 21: issue a request to provision a storage volume on a storage array;
¶ 22: issue a request to create, update, or delete a storage volume, where the request contains information of characteristics relating to the storage volume. In response to a request to create the storage volume, the fleet storage provider can provision the storage volume on a storage array (or multiple storage arrays) of the fleet of storage arrays in response to the request;
¶ 27: An entity (such as a user, a program, or a machine) can request that a storage volume ( or multiple storage volumes) be provisioned in a fleet of storage arrays. “Provisioning” a storage volume in a fleet of storage arrays can refer to creating the storage volume and configuring the storage volume such that the storage volume is ready to store data and to receive requests to access data;
¶¶ 64–67: The input information supplied with a request to create a storage volume can include the following information … the input information can further include a parameter that represents a quantity of storage volumes ( of the respective application type and storage volume size) to be provisioned, where the “quantity” can be 1 or more than 1)
“the providing the first storage resource comprises providing a first storage volume associated with the first storage resource;”
(Dutta, ¶ 27: An entity (such as a user, a program, or a machine) can request that a storage volume ( or multiple storage volumes) be provisioned in a fleet of storage arrays. “Provisioning” a storage volume in a fleet of storage arrays can refer to creating the storage volume and configuring the storage volume such that the storage volume is ready to store data and to receive requests to access data. A storage volume can be provisioned on one or more storage arrays, which means that data of the storage volume is physically stored in the one or more storage arrays);
“the providing the second storage resource comprises providing a second storage volume associated with the second storage resource”
(Martin, Col. 10, lines 40–44: a host side logical device or volume is mapped to one or more data storage system logical devices as presented to the host;
Fig. 4 and Col. 15, lines 14–17: storage system 151 may include a storage array 124 having multiple directors 130-132 and multiple storage volumes (LUNs, LVs, logical devices or VOLUMES 0-3) 110-113;
Kathmann, ¶¶ 46–47: Before migration, volume 2 in the mapping 204 is mapped to physical volume 206d and volume 1 in the mapping 204 is mapped to physical volume 206b. During migration volume 1 in the mapping 204 has two simultaneous mappings-one is to physical volume 206b and another is to a subset of physical volume 206d. This mapping is implemented via control information maintained for volume 1 in the mapping. Depending on the state of the migration, runtime I/O will use one or another of these two mappings when issuing physical I/O for a logical I/O to volume 1 in the mapping 204).
19. Regarding claims 14–18, they are the corresponding system claims reciting similar limitations of commensurate scope as the method of claims 1–2 and 4–6, respectively. Therefore, they are rejected on the same basis as claims 1–2 and 4–6 above, including the following rationale:
Dutta teaches or suggests: “one or more memories storing computer-executable
instructions; and one or more processors to execute the computer-executable instructions to: …”
(Fig. 5 and ¶¶ 83–85: hardware processor and storage medium storing machine-readable instructions executable on the hardware processor).
20. Regarding claims 19–20, they are the corresponding computer program product claims reciting similar limitations of commensurate scope as the method of claims 1–2, respectively. Therefore, they are rejected on the same basis as claims 1–2.
B.
21. Claims 8 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over (A) Dutta in view of (B) Martin and (C) Kathmann, as applied to claim 6 above, and further in view of (D) Maciocco.
22. Regarding claim 8, Dutta, Martin, and Kathmann do not teach “wherein the characteristic of the application comprises a microservice of the application.”
(D) Maciocco however teaches or suggests: “wherein the characteristic of the application comprises a microservice of the application”
(¶ 102: the edge nodes 712. That is, the instructions of FIG. 10 assign microservices of an application for execution by different ones of the edge nodes 712 to implement the application in a distributed manner across those ones of the edge nodes 712. Further, the edge nodes 712 and/or their associated edge clusters 714 have different performance capabilities. In other words, in this example, different ones of the edge nodes 712 are better at different tasks from the other ones of the edge nodes 712. As such, microservices can be assigned to different ones of the edge nodes 712 based on capabilities of the edge nodes 712 satisfying requirements of the microservices).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of (D) Maciocco with those of Dutta, Martin, and Kathmann to implement a (distributed) application as microservices. The motivation or advantage to do so is to implement and allow for the application to execute in a distributed manner across different nodes/containers with specific performance requirements.
23. Regarding claim 9, Dutta, Martin, Kathmann, and Maciocco teach or suggest:
“moving, while the application is running on the container system, data associated with the microservice from the first storage resource to the second storage resource”
(Dutta, ¶ 38: Mounting a storage volume to a container or pod can refer to making available the storage volume for use by programs running in the containers 112 of the compute nodes 110;
Martin, Col. 13, lines 42–60: The data portions may also be automatically relocated or moved to a different storage tier as the work load and observed performance characteristics for the data portions change over time … take into account how “busy” the data portions are in combination with defined capacity limits and defined performance limits (e.g., such as I/O throughput or I/Os per unit of time, response time, utilization, and the like) associated with a storage tier in order to evaluate which data to store on drives of the storage tier.
Promotion may refer to movement of data from a first storage tier to a second storage tier where the second storage tier is characterized as having devices of higher performance than devices of the first storage tier;
Col. 24, lines 1–5: As the I/O workload may change dynamically over time, the data storage optimizer may continuously evaluate and perform data movement optimizations between different storage tiers as needed responsive to such changing workloads;
Kathmann, ¶¶ 6, 25, 42, and 43, teaching concurrent access to the data throughout the migration progress
Maciocco, ¶ 102, teaching microservices).
Response to Arguments
24. Applicant’s arguments with respect to the claims have been considered but are moot because the arguments do not apply to any of the newly applied teachings or references being used in the current rejection.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BENJAMIN C WU whose telephone number is (571)270-5906. The examiner can normally be reached Monday through Friday, 8:30 A.M. to 5:00 P.M..
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, Aimee J. Li can be reached on (571)272-4169. 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.
/BENJAMIN C WU/Primary Examiner, Art Unit 2195
February 19, 2026