DETAILED ACTION
This Action is responsive to the RCE filed on 03/04/2026.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/04/2026 has been entered.
Claim Status
Claims 1-20 are amended. Claims 1-20 are pending and have been examined.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 02/04/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 4-5, 7, 11-12, 14-15, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Gao et al. (US 20220300193 A1)(cited by examiner in previous action)(hereafter referred to as Gao) further in view of Kondapalli et al. (US 20180314449 A1)(cited by examiner in previous action)(hereafter referred to as Kondapalli) and Subramanian et al. (US 20180074725 A1)(cited by examiner in previous action)(hereafter referred to as Subramanian ‘725).
Regarding Claim 1,
Gao discloses the following limitations:
A method implemented by a processor executing instructions out of a memory (¶0259) for a storage operating system (Fig. 4A // ¶0264), the method comprising:
receiving (¶0160), from a client (Storage Controller Applications 324 + 326, Fig. 3C // Host Devices 378a, Fig. 3E // ¶¶0159-160; 0225), a write request for writing data to a volume (“upon receiving a request to write data, initiate a write of the data to its attached EBS volume as well as a write of the data to its local storage” [0160]) that represents both first storage within a performance storage tier (Type 1 Storage Class Memory 418, Fig. 4B) and second storage within a capacity storage tier (Type 2 Storage Class Memory 420, Fig. 4B) (“The mode selector 408 receives mode selection information (see FIG. 5), and selects from available write paths 412 for data writing … On one write path 422, data is written to type 1 storage class memory 418 … On another write path 426, data is written to the type 2 storage class memory 420, but not to or from the type 1 storage class memory 418 … the type 1 storage class memory 418 is SLC flash memory, and the type 2 storage class memory 420 is QLC flash memory” [0264-266] // Fig. 4B) – As shown in Fig. 4B, a processor writes data into either Type 1 (SLC) Storage Class Memory 418 (via write path 422) or into Type 2 (QLC) Storage Class Memory 420 (via write path 426). Accordingly, examiner considers Types 1 Storage Class Memory 418 and Type 2 Storage Class Memory 420 as “first storage within a performance storage tier” and “second storage within a capacity storage tier”, respectively--;
wherein the performance storage tier provides lower latency data access than the capacity storage tier and the capacity storage tier provides data storage at a lower expense than the performance storage tier (“the characterization of memory types may be thought of or abstracted to a relatively quick medium, e.g., SLC, and a relatively slower medium, e.g., MLC, TLC, QLC, PLC, or other future multi-level cell NAND types” [0284] // “Data is first written in SLC mode to provide persistence, then the data is migrated, or garbage collected, from the SLC portion to the QLC portion of the storage class memory 406. During the migration, deep compression, deduplication or other transformation operations can be performed on the data before it is stored in the QLC flash memory” [0266]) – SLC flash cells are characterized as “relatively quick” (i.e., “provides lower latency data access”); whereas QLC flash cells store compressed, deduplicated data in quad-level type cells (i.e., QLC cells store more data per memory cell; i.e., “provides data storage at a lower expense” than SLC cells)--
determining that a bypass write mode is enabled for the volume in which the bypass write mode allows bypassing of the performance storage tier by directly assigning the data to the capacity storage tier (“The mode selector 408 receives mode selection information 410 (see Fig. 5), and selects from among available write paths 412, for data writing … On one write path 422, data is written to type 1 storage class memory 418 … On another write path 426, data is written to the type 2 storage class memory 420, but not to or from the type 1 storage class memory 418” [0264-265] // Fig. 4B // Fig. 5 // ¶¶0269-280) – As shown in Fig. 4B and detailed in ¶¶0264-265, a processor receives mode selection information 410 (e.g., including Memory Characteristics 510, Memory Configuration 512, Data Formatting Operations 518, and/or Data Characteristics 522; see Fig. 5 // ¶¶0269-280) and subsequently selects one of plural write paths (e.g., including write paths 422 and 426) to write the data into storage class memory 406. In a write path 426, data is written directly into type 2 storage class memory 420 (i.e., “bypassing of the performance storage tier”). Examiner considers a processor using mode selection information 410 to select a write path 426 for writing data as “determining that a bypass write mode is enabled for the volume” targeted by a write request-- ;
… and
sending … the data … to the capacity storage tier (“Data is then written, according to the selected write path” [0264])
Gao is silent regarding the following limitations:
the data is stored in a transfer data structure in the performance storage tier by assigning a location identifier for the capacity storage tier as a primary reference for the data to the volume or the client, bypassing assignment of a location identifier for the performance storage tier as the primary reference for the data to the volume or the client; and
sending … the data in the transfer data structure, to the performance storage tier
However, Kondapalli discloses the following limitations:
the data is stored (Fig. 3, step 306) in a transfer data structure (Staging Area 414, Fig. 4A // “a TLOG file” [0055]) in the performance storage tier (First Storage Tier 412, Fig. 4A) by assigning (Fig. 3, step 308) a location identifier (“a second storage tier location identifier” [0055]) for the capacity storage tier as a primary reference for the data to the volume or the client (“At 306, the data is stored … into a staging area of the first storage tier. The staging area may be storage space within the first storage tier that is designated for data that is to be stored into the second storage tier. For example, the data is written into a staging file, such as a TLOG file … a second storage tier identifier … is assigned to the data within the staging area, at 308 … for referencing the data” [0055[) – As shown in Kondapalli Figs. 3 and 4A, data is written to a storage system 404 into either a first storage tier 412 or into a second storage tier 418, similar to how data is written into the storage system of Gao Fig. 4B into either Type 1 Storage Class Memory 418 or Type 2 Storage Class Memory 420. As clarified in Kondapalli Fig. 3 steps 306 and 308, data which is written into the second storage tier 418 is initially staged in a TLOG file in a staging area of first storage tier 412 (step 306) and is assigned a second storage tier location identifier (step 308) while located within the staging area.--
bypassing assignment of a location identifier for the performance storage tier as the primary reference for the data to the volume or the client (“A file system hosting the data … is not provided with the first storage tier location identifier as a primary reference for identifying the data. Instead, a second storage tier location identifier … is assigned” [0055]) – As specified in ¶0055, assignment of a second storage tier location identifier is instead of (i.e., effectively “bypass[es] assignment” of) a first storage tier location identifier despite being located in the first storage tier--; and
sending (Fig. 3, step 310) … the data in the transfer data structure, to the capacity storage tier (“At 310, the data is destaged from the staging area to the second storage tier” [0057])
Gao and Kondapalli are considered analogous to the claimed invention because they all relate to the same field of ingesting data into a storage system comprising at least a first storage tier and a second storage tier. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gao with the teachings of Kondapalli and realize a method of assigning a second storage tier location identifier to data which is stored in a transfer data structure located within a first storage tier. Doing so enables a file system to reference data according to a format usable by the second tier without making additional changes to the data after destaging even though the data is not yet stored to the second storage tier, saving resources, time, and delay, as disclosed in Kondapalli ¶¶0055; 0013-14: “The second storage tier location identifier is provided to the file system … for referencing the data even though the data is not yet stored to the second storage tier.” [0055] // “a substantial amount of resources, time, and delay may be introduced when data is stored within the first storage tier for access by a file system using a storage format of the first storage tier … The file system must be updated to utilize the storage format of the second storage tier for each of the cold data blocks now stored within the second storage tier … The second storage tier location identifier may be provided to the file system. In this way, the data can be destaged to the second storage tier … in a consistent manner without the need to change how the file system references the data because the file system was already configured to utilize the second storage tier location identifier.” [0013-14]
Although Kondapalli ¶0057 discloses that a set of objects is built on the second storage tier before destaging data into the second storage tier, Kondapalli is silent regarding building a set of objects in the transfer data structure in the first storage tier for data to be destaged into the second storage tier. Specifically, the combined teachings of Gao and Kondapalli are silent regarding the following limitations:
building a set of objects for the data in which the data is stored in a transfer data structure in the performance storage tier …
sending the set of objects … to the capacity storage tier
However, Subramanian ‘725 discloses the following limitations:
building (Fig. 5C, step B526) a set of objects (“a plurality of data chunks/blocks” [0092]) for the data in which the data is stored in a transfer data structure (“a transfer data structure (TLOG)” [0013] // TLOG 512, Fig. 5A) in the performance storage tier (Performance Tier 112, Fig. 5A)(“When data has to be written to the capacity tier 128, an object is built to include a plurality of data chunks/blocks” [0092] // “When data has to be moved from a performance tier to a capacity tier, the data is first buffered using the TLOG” [0023]) – As shown in Fig. 5C and detailed in ¶0092, an object including a plurality of data chunks/blocks is “built” each time data is written to a capacity tier 128. As clarified in ¶0023, data is first buffered (i.e., is “stored”) in a TLOG data structure (e.g., TLOG 512, Fig. 5A) before being moved to the capacity tier 128.-- …
sending (Fig. 5C, step B530) the set of objects… to the capacity storage tier (Capacity Tier 128, Fig. 5A )(“After one or more objects have been built, the object with its data is transferred to the capacity tier 128” [0092]).
Gao, Kondapalli, and Subramanian ‘725 are considered analogous to the claimed invention because they all relate to the same field of determining a storage tier for received write request data. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gao and Kondapalli with the teachings of Subramanian ‘725 and realize a method of building and sending a set of data objects from a transfer data structure to a second storage tier. Doing so would enable assembly of multiple objects for one or more volumes at the same time by providing a buffer space for data as objects are being built, improving the efficiency of consistency point (CP) write operations, as disclosed in Subramanian ‘725 ¶¶ 0081-82 // 0109: “A consistency point (CP) module 510 is used to manage CP operations … The CP module 510 then pushes the information regarding the dirty data into a TLOG metadata structure 512 … The TLOG 512 enables data to be buffered while an object is still being created” [0081-82] // “In another aspect, TLOG 512 enables assembly of multiple objects at the same time, for one or more volumes. This is again efficient for a CP write operation.” [0109]
Regarding Claim 2,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 2. The combined teachings of Gao, Kondapalli, and Subramanian ‘725 disclose the following limitations:
The method of claim 1, wherein the bypass write mode allows the assigning of the location identifier for the capacity storage tier as the primary reference for the data and bypassing without first separately storing the data elsewhere in the performance storage tier providing a different location identifier for the performance storage tier as the primary reference for the data to the volume or the client (Kondapalli, “At 306, the data is stored (e.g., from within memory of a storage system, such as a storage controller or node that received a write request from a client to write the data into the multi-tier storage environment) into a staging area” [0055] // Figs. 2 + 4A + 4B // ¶0029) – As taught in Kondapalli ¶0055 and shown in Figs. 4A + 4B, data 402 written into the staging area 414 is received from a data server node 404 (see Fig. 2 + ¶0029) and is subsequently destaged into second storage tier 418. One of ordinary skill in the art would understand such a process takes place without storing data 402 in first tier storage 416 (i.e., “without first separately storing the data elsewhere in the performance storage tier”)
Regarding Claim 4,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 4. The combined teachings of Gao, Kondapalli, Subramanian ‘725 disclose the following limitations:
The method of claim 1, further comprising: freeing data blocks in the transfer data structure used for the data for future use after the set of objects is sent to the capacity storage tier (Subramanian ‘725, “the object with its data is transferred to the capacity tier 128 … The storage policy of the capacity tier 128 may dictate that the storage operation be verified, before freeing up the space used by the transferred object at TLOG.” [0092])
Regarding Claim 5,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 5. The combined teachings of Gao, Kondapalli, and Subramanian ‘725 disclose the following limitations:
The method of claim 1, wherein the first storage (Gao, Type 1 Storage Class Memory 418, Fig. 4B) is physical storage (Gao, “the type 1 storage class memory 418 is SLC flash memory” [0266]) and the second storage (Gao, Type 2 Storage Class Memory 420, Fig. 4B) is object based storage (Gao, “the type 2 storage class memory 420 is QLC flash memory” [0266] // ¶0318) – As shown in Gao Fig. 4B and detailed in ¶0266, Type 1 Storage Class Memory can include SLC Flash cells, which examiner considers as “physical storage”. As further shown in Fig. 4B, storage class memory can include QLC Flash cells, which stores data in a format of objects (see ¶0318), which examiner considers as “object based storage”-- and
wherein building the set of objects comprises: allocating a first set of data blocks in the transfer data structure in the physical storage (Kondapalli, First Storage Tier 412, Fig. 4A) for an object of the set of objects (Subramanian ‘725, Fig. 5C, step 5C // Fig. 5D) – As previously discussed (see Claim 1 limitation mappings above) and as disclosed in Subramanian ‘725 Figs. 5C + 5D, an object which includes a plurality of blocks is held in a TLOG (located in First Storage Tier 412; i.e., “in the physical storage”). Examiner considers the blocks of object in the TLOG as “a first set of data blocks”--; and
allocating a second set of data blocks (Kondapalli, “an object” [0057] // “one or more object pages” [0048]) in the object based storage for the object (Kondapalli, “At 310, the data is destaged … In an example where the second storage tier is a remote object store, an object is created within the second storage tier to comprise the data” [0057])
Regarding Claim 7,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 7. The combined teachings of Gao, Kondapalli, and Subramanian ‘725 disclose the following limitations:
The method of claim 1, wherein determining that the bypass write mode is enabled comprises: determining whether an attribute in a volume information data structure (Gao, Mode Selection Information 410, Figs. 4A + 5) associated with the volume (Subramanian ‘725, “Volume information (volinfo) and file system information (fsinfo) blocks specify the layout of information in the file system … Each logical volume (file system) has an fsinfo block” [0040]) indicates that the bypass write mode is enabled for the volume (Gao, Fig. 4A // ¶0264) – As previously discussed (see Claim 1 limitation mappings above) and as detailed in Gao, mode selection information 410 (i.e., “an attribute in a volume information data structure”; see also Gao Fig. 5) indicates that bypass mode is enabled for a volume (see Fig. 4A // ¶0264). As clarified in Subramanian ‘725 ¶0040, “volume information” and “file system information” associated with “each logical volume” (i.e., “a volume information data structure associated with the volume”) stores information relating to the volume.
Regarding Claim 11,
Gao discloses the following limitations:
A computing device comprising:
a memory containing a machine-readable medium comprising machine executable code having instructions stored thereon (¶0259); and
a processor coupled to the memory, the processor configured to execute the machine executable code to (¶0259):
receive, (¶0160), from a client (Storage Controller Applications 324 + 326, Fig. 3C // Host Devices 378a, Fig. 3E // ¶¶0159-160; 0225), a write request for writing data to a volume (“upon receiving a request to write data, initiate a write of the data to its attached EBS volume as well as a write of the data to its local storage” [0160]) that represents both storage within a performance storage tier (Type 1 Storage Class Memory 418, Fig. 4B) and a capacity storage tier (Type 2 Storage Class Memory 420, Fig. 4B) (“The mode selector 408 receives mode selection information (see FIG. 5), and selects from available write paths 412 for data writing … On one write path 422, data is written to type 1 storage class memory 418 … On another write path 426, data is written to the type 2 storage class memory 420, but not to or from the type 1 storage class memory 418 … the type 1 storage class memory 418 is SLC flash memory, and the type 2 storage class memory 420 is QLC flash memory” [0264-266] // Fig. 4B) – As shown in Fig. 4B, a processor writes data into either Type 1 (SLC) Storage Class Memory 418 (via write path 422) or into Type 2 (QLC) Storage Class Memory 420 (via write path 426). Accordingly, examiner considers Types 1 Storage Class Memory 418 and Type 2 Storage Class Memory 420 as “a performance storage tier” and “a capacity storage tier”, respectively--;
wherein the performance storage tier provides lower latency data access than the capacity storage tier and the capacity storage tier provides data storage at a lower expense than the performance storage tier (“the characterization of memory types may be thought of or abstracted to a relatively quick medium, e.g., SLC, and a relatively slower medium, e.g., MLC, TLC, QLC, PLC, or other future multi-level cell NAND types” [0284] // “Data is first written in SLC mode to provide persistence, then the data is migrated, or garbage collected, from the SLC portion to the QLC portion of the storage class memory 406. During the migration, deep compression, deduplication or other transformation operations can be performed on the data before it is stored in the QLC flash memory” [0266]) – SLC flash cells are characterized as “relatively quick” (i.e., “provides lower latency data access”); whereas QLC flash cells store compressed, deduplicated data in quad-level type cells (i.e., QLC cells store more data per memory cell; i.e., “provides data storage at a lower expense” than SLC cells)--
determine that a bypass write mode is enabled for the volume in which the bypass write mode allows bypassing of the performance storage tier by directly assigning the data to the capacity storage tier (“The mode selector 408 receives mode selection information 410 (see Fig. 5), and selects from among available write paths 412, for data writing … On one write path 422, data is written to type 1 storage class memory 418 … On another write path 426, data is written to the type 2 storage class memory 420, but not to or from the type 1 storage class memory 418” [0264-265] // Fig. 4B // Fig. 5 // ¶¶0269-280) – As shown in Fig. 4B and detailed in ¶¶0264-265, a processor receives mode selection information 410 (e.g., including Memory Characteristics 510, Memory Configuration 512, Data Formatting Operations 518, and/or Data Characteristics 522; see Fig. 5 // ¶¶0269-280) and subsequently selects one of plural write paths (e.g., including write paths 422 and 426) to write the data into storage class memory 406. In a write path 426, data is written directly into type 2 storage class memory 420 (i.e., “bypassing of the performance storage tier”). Examiner considers a processor using mode selection information 410 to select a write path 426 for writing data as “determining that a bypass write mode is enabled for the volume” targeted by a write request-- ;
…
send … to the capacity storage tier (“Data is then written, according to the selected write path” [0264]) – As clarified in ¶0264, write request data is written to a storage tier based on the selected write path.--; …
Gao is silent regarding the following limitations:
the data is stored in a transfer data structure in the performance storage tier by assigning a location identifier for the capacity storage tier as a primary reference for the data to the volume or the client, bypassing assignment of a location identifier for the performance storage tier as the primary reference for the data to the volume or the client; …
send … the data in the transfer data structure, to the capacity storage tier
However, Kondapalli discloses the following limitations:
the data is stored (Fig. 3, step 306) in a transfer data structure (Staging Area 414, Fig. 4A // “a TLOG file” [0055]) in the performance storage tier (First Storage Tier 412, Fig. 4A) by assigning (Fig. 3, step 308) a location identifier (“a second storage tier location identifier” [0055]) for the capacity storage tier as a primary reference for the data to the volume or the client (“At 306, the data is stored … into a staging area of the first storage tier. The staging area may be storage space within the first storage tier that is designated for data that is to be stored into the second storage tier. For example, the data is written into a staging file, such as a TLOG file … a second storage tier identifier … is assigned to the data within the staging area, at 308 … for referencing the data” [0055[) – As shown in Kondapalli Figs. 3 and 4A, data is written to a storage system 404 into either a first storage tier 412 or into a second storage tier 418, similar to how data is written into the storage system of Gao Fig. 4B into either Type 1 Storage Class Memory 418 or Type 2 Storage Class Memory 420. As clarified in Kondapalli Fig. 3 steps 306 and 308, data which is written into the second storage tier 418 is initially staged in a TLOG file in a staging area of first storage tier 412 (step 306) and is assigned a second storage tier location identifier (step 308) while located within the staging area.--
bypassing assignment of a location identifier for the performance storage tier as the primary reference for the data to the volume or the client (“A file system hosting the data … is not provided with the first storage tier location identifier as a primary reference for identifying the data. Instead, a second storage tier location identifier … is assigned” [0055]) – As specified in ¶0055, assignment of a second storage tier location identifier is instead of (i.e., effectively “bypass[es] assignment” of) a first storage tier location identifier despite being located in the first storage tier--; and
send (Fig. 3, step 310) … the data in the transfer data structure, to the capacity storage tier (“At 310, the data is destaged from the staging area to the second storage tier” [0057])
Gao and Kondapalli are considered analogous to the claimed invention because they all relate to the same field of ingesting data into a storage system comprising at least a first storage tier and a second storage tier. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gao with the teachings of Kondapalli and realize a method of assigning a second storage tier location identifier to data which is stored in a transfer data structure located within a first storage tier. Doing so enables a file system to reference data according to a format usable by the second tier without making additional changes to the data after destaging even though the data is not yet stored to the second storage tier, saving resources, time, and delay, as disclosed in Kondapalli ¶¶0055; 0013-14: “The second storage tier location identifier is provided to the file system … for referencing the data even though the data is not yet stored to the second storage tier.” [0055] // “a substantial amount of resources, time, and delay may be introduced when data is stored within the first storage tier for access by a file system using a storage format of the first storage tier … The file system must be updated to utilize the storage format of the second storage tier for each of the cold data blocks now stored within the second storage tier … The second storage tier location identifier may be provided to the file system. In this way, the data can be destaged to the second storage tier … in a consistent manner without the need to change how the file system references the data because the file system was already configured to utilize the second storage tier location identifier.” [0013-14]
Although Kondapalli ¶0057 discloses that a set of objects is built on the second storage tier before destaging data into the second storage tier, Kondapalli is silent regarding building a set of objects in the transfer data structure in the first storage tier for data to be destaged into the second storage tier. Specifically, the combined teachings of Gao and Kondapalli are silent regarding the following limitations:
build a set of objects for the data in which the data is stored in a transfer data structure in the performance storage tier;
generate the set of objects using the data in the transfer data structure and an object staging data structure;
send the set of objects to the capacity storage tier; and
free data blocks in the transfer data structure used for the data for future use after the set of objects is sent to the capacity storage tier.
However, Subramanian ‘725 discloses the following limitations:
build (Fig. 5C, step B526) a set of objects (“a plurality of data chunks/blocks” [0092]) for the data in which the data is stored in a transfer data structure (“a transfer data structure (TLOG)” [0013] // TLOG 512, Fig. 5A) in the performance storage tier (Performance Tier 112, Fig. 5A)(“When data has to be written to the capacity tier 128, an object is built to include a plurality of data chunks/blocks” [0092] // “When data has to be moved from a performance tier to a capacity tier, the data is first buffered using the TLOG” [0023]) – As shown in Fig. 5C and detailed in ¶0092, an object including a plurality of data chunks/blocks is “built” each time data is written to a capacity tier 128. As clarified in ¶0023, data is first buffered (i.e., is “stored”) in a TLOG data structure (e.g., TLOG 512, Fig. 5A) before being moved to the capacity tier 128.--;
generate the set of objects using the data in the transfer data structure and an object staging data structure (Object Staging Data Structure 532, Fig. 5D)(“Fig. 5C shows a process for building and tracking an object for the capacity tier 128 using an object staging data structure and the TLOG 512” [0091] // Fig. 5D) – As detailed in ¶0091 and shown in Fig. 5D, a set of objects (e.g., built during step B526 of Fig. 5C) are built using both an Object Staging Data Structure 532 and a TLOG 512--;
send (Fig. 5C, step B530) the set of objects to the capacity storage tier (Capacity Tier 128, Fig. 5A)(“After one or more objects have been built, the object with its data is transferred to the capacity tier 128” [0092]) –; and
free data blocks in the transfer data structure used for the data for future use after the set of objects is sent to the capacity storage tier (“the object with its data is transferred to the capacity tier 128 … The storage policy of the capacity tier 128 may dictate that the storage operation be verified, before freeing up the space used by the transferred object at TLOG.” [0092])
Gao, Kondapalli, and Subramanian ‘725 are considered analogous to the claimed invention because they all relate to the same field of determining a storage tier for received write request data. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gao and Kondapalli with the teachings of Subramanian ‘725 and realize a method of building and sending a set of data objects from a transfer data structure to a second storage tier. Doing so would enable assembly of multiple objects for one or more volumes at the same time by providing a buffer space for data as objects are being built, improving the efficiency of consistency point (CP) write operations, as disclosed in Subramanian ‘725 ¶¶ 0081-82 // 0109: “A consistency point (CP) module 510 is used to manage CP operations … The CP module 510 then pushes the information regarding the dirty data into a TLOG metadata structure 512 … The TLOG 512 enables data to be buffered while an object is still being created” [0081-82] // “In another aspect, TLOG 512 enables assembly of multiple objects at the same time, for one or more volumes. This is again efficient for a CP write operation.” [0109]
Regarding Claim 12,
The same motivation to combine provided in Claim 11 is equally applicable to Claim 12. The combined teachings of Gao, Kondapalli, and Subramanian ‘725 disclose the following limitations:
The computing device of claim 11, wherein the bypass write mode allows the assigning of the location identifier for the capacity storage tier as the primary reference for the data without first separately storing the data elsewhere in the performance storage tier providing a different location identifier for the performance storage tier as the primary reference for the data to the volume or the client(Kondapalli, “At 306, the data is stored (e.g., from within memory of a storage system, such as a storage controller or node that received a write request from a client to write the data into the multi-tier storage environment) into a staging area” [0055] // Figs. 2 + 4A + 4B // ¶0029) – As taught in Kondapalli ¶0055 and shown in Figs. 4A + 4B, data 402 written into the staging area 414 is received from a data server node 404 (see Fig. 2 + ¶0029) and is subsequently destaged into second storage tier 418. One of ordinary skill in the art would understand such a process takes place without storing data 402 in first tier storage 416 (i.e., “without first separately storing the data elsewhere in the first storage tier”)
Regarding Claim 14,
The same motivation to combine provided in Claim 11 is equally applicable to Claim 14. The combined teachings of Gao, Kondapalli, and Subramanian ‘725 disclose the following limitations:
The computing device of claim 11, wherein the processor is further configured to determine that the bypass write mode is enabled by determining whether an attribute in a volume information data structure (Gao, Mode Selection Information 410, Figs. 4A + 5) associated with the volume (Subramanian ‘725, “Volume information (volinfo) and file system information (fsinfo) blocks specify the layout of information in the file system … Each logical volume (file system) has an fsinfo block” [0040]) indicates that the bypass write mode is enabled for the volume (Gao, Fig. 4A // ¶0264) – As previously discussed (see Claim 11 limitation mappings above) and as detailed in Gao, mode selection information 410 (i.e., “an attribute in a volume information data structure”; see also Gao Fig. 5) indicates that bypass mode is enabled for a volume (see Fig. 4A // ¶0264). As clarified in Subramanian ‘725 ¶0040, “volume information” and “file system information” associated with “each logical volume” (i.e., “a volume information data structure associated with the volume”) stores information relating to the volume.
Regarding Claim 15,
The same motivation to combine provided in Claim 11 is equally applicable to Claim 15. The combined teachings of Gao, Kondapalli, and Subramanian ‘725 disclose the following limitations:
The computing device of claim 11 (see Claim 11 limitation mappings above), wherein the transfer data structure (Subramanian ‘725, TLOG 512, Fig. 5A // Kondapalli, Staging Area 414, Fig. 4A) is a staging file (Kondapalli, “a staging file, such as a TLOG file” [0055]) that resides on an aggregate belonging to the performance storage tier (Kondapalli, First Storage Tier 412, Fig. 4A // “A storage aggregate” [0001]) – As clarified in Kondapalli ¶0001, storage devices comprise a storage aggregate.
Regarding Claim 17,
The same motivation to combine provided in Claim 11 is equally applicable to Claim 17. The combined teachings of Gao, Kondapalli, Subramanian ‘725 disclose the following limitations:
The computing device of claim 11 (see Claim 11 limitation mappings above), wherein the object staging data structure (Subramanian ‘725, Object Staging Data Structure 532, Fig. 5D) maps a location identifier (Subramanian ‘725, TLOG FBN 532D, Fig. 5D // ¶¶0035;0094) for the data in the transfer data structure to a different location identifier (Subramanian ‘725, PVBN, Fig. 5D // ¶0075)) for the data (Subramanian ‘725, “When the object has not completely been created and/or the object has net been stored at the capacity tier 128 yet, then in block B636, the object staging data structure 532 is used to obtain the TLOG FBN. The TLOG FBN then provides the PVBN for the data associated with the request.” [0105] // Fig. 5D) – As disclosed in Subramanian ‘725 ¶0105 and as shown in Fig. 5D, an object staging data structure includes a TLOG FBN, which in turn maps to an associated PVBN for the object. – in the capacity storage tier (Kondapalli, “a second storage tier location identifier” [0055])
Regarding Claim 18,
Gao discloses the following limitations:
A non-transitory machine-readable medium having stored thereon instructions for performing a method comprising machine-executable code which, when executed by at least one machine, causes the at least one machine to (¶0259):
receive, (¶0160), from a client (Storage Controller Applications 324 + 326, Fig. 3C // Host Devices 378a, Fig. 3E // ¶¶0159-160; 0225), a write request for writing data to a volume (“upon receiving a request to write data, initiate a write of the data to its attached EBS volume as well as a write of the data to its local storage” [0160]) that represents both storage within a performance storage tier (Type 1 Storage Class Memory 418, Fig. 4B) and a capacity storage tier (Type 2 Storage Class Memory 420, Fig. 4B) (“The mode selector 408 receives mode selection information (see FIG. 5), and selects from available write paths 412 for data writing … On one write path 422, data is written to type 1 storage class memory 418 … On another write path 426, data is written to the type 2 storage class memory 420, but not to or from the type 1 storage class memory 418 … the type 1 storage class memory 418 is SLC flash memory, and the type 2 storage class memory 420 is QLC flash memory” [0264-266] // Fig. 4B) – As shown in Fig. 4B, a processor writes data into either Type 1 (SLC) Storage Class Memory 418 (via write path 422) or into Type 2 (QLC) Storage Class Memory 420 (via write path 426). Accordingly, examiner considers Types 1 Storage Class Memory 418 and Type 2 Storage Class Memory 420 as “a performance storage tier” and “a capacity storage tier”, respectively--;
wherein the performance storage tier provides lower latency data access than the capacity storage tier and the capacity storage tier provides data storage at a lower expense than the performance storage tier (“the characterization of memory types may be thought of or abstracted to a relatively quick medium, e.g., SLC, and a relatively slower medium, e.g., MLC, TLC, QLC, PLC, or other future multi-level cell NAND types” [0284] // “Data is first written in SLC mode to provide persistence, then the data is migrated, or garbage collected, from the SLC portion to the QLC portion of the storage class memory 406. During the migration, deep compression, deduplication or other transformation operations can be performed on the data before it is stored in the QLC flash memory” [0266]) – SLC flash cells are characterized as “relatively quick” (i.e., “provides lower latency data access”); whereas QLC flash cells store compressed, deduplicated data in quad-level type cells (i.e., QLC cells store more data per memory cell; i.e., “provides data storage at a lower expense” than SLC cells)--
determine that an attribute (types 510 + 512 + 518 + 522, Fig. 5 // ¶0269) in a volume information data structure (Mode Selection Information 410, Fig. 5 // ¶0269) … indicates that a bypass write mode is enabled for the volume in which the bypass write mode allows bypassing of the performance storage tier by directly assigning the data to the capacity storage tier (“The mode selector 408 receives mode selection information 410 (see Fig. 5), and selects from among available write paths 412, for data writing … On one write path 422, data is written to type 1 storage class memory 418 … On another write path 426, data is written to the type 2 storage class memory 420, but not to or from the type 1 storage class memory 418” [0264-265] // Fig. 4B // Fig. 5 // ¶¶0269-280) – As shown in Fig. 4B and detailed in ¶¶0264-265, a processor receives mode selection information 410 (e.g., including Memory Characteristics 510, Memory Configuration 512, Data Formatting Operations 518, and/or Data Characteristics 522; see Fig. 5 // ¶¶0269-280) and subsequently selects one of plural write paths (e.g., including write paths 422 and 426) to write the data into storage class memory 406. In a write path 426, data is written directly into type 2 storage class memory 420 (i.e., “bypassing of the performance storage tier”). Examiner considers a processor using mode selection information 410 to select a write path 426 for writing data as “determining that a bypass write mode is enabled for the volume” targeted by a write request--;
… and
send … the data … to the capacity storage tier (“Data is then written, according to the selected write path” [0264]) – As clarified in ¶0264, write request data is written to a storage tier based on the selected write path.--
Gao is silent regarding the following limitations:
the data is stored in a transfer data structure in the performance storage tier by assigning a location identifier for the capacity storage tier as a primary reference for the data to the volume or the client, bypassing assignment of a location identifier for the performance storage tier as the primary reference for the data to the volume or the client; …
send … the data in the transfer data structure, to the capacity storage tier
However, Kondapalli discloses the following limitations:
the data is stored (Fig. 3, step 306) in a transfer data structure (Staging Area 414, Fig. 4A // “a TLOG file” [0055]) in the performance storage tier (First Storage Tier 412, Fig. 4A) by assigning (Fig. 3, step 308) a location identifier (“a second storage tier location identifier” [0055]) for the capacity storage tier as a primary reference for the data to the volume or the client (“At 306, the data is stored … into a staging area of the first storage tier. The staging area may be storage space within the first storage tier that is designated for data that is to be stored into the second storage tier. For example, the data is written into a staging file, such as a TLOG file … a second storage tier identifier … is assigned to the data within the staging area, at 308 … for referencing the data” [0055[) – As shown in Kondapalli Figs. 3 and 4A, data is written to a storage system 404 into either a first storage tier 412 or into a second storage tier 418, similar to how data is written into the storage system of Gao Fig. 4B into either Type 1 Storage Class Memory 418 or Type 2 Storage Class Memory 420. As clarified in Kondapalli Fig. 3 steps 306 and 308, data which is written into the second storage tier 418 is initially staged in a TLOG file in a staging area of first storage tier 412 (step 306) and is assigned a second storage tier location identifier (step 308) while located within the staging area.--
bypassing assignment of a location identifier for the performance storage tier as the primary reference for the data to the volume or the client (“A file system hosting the data … is not provided with the first storage tier location identifier as a primary reference for identifying the data. Instead, a second storage tier location identifier … is assigned” [0055]) – As specified in ¶0055, assignment of a second storage tier location identifier is instead of (i.e., effectively “bypass[es] assignment” of) a first storage tier location identifier despite being located in the first storage tier--; and
send (Fig. 3, step 310) … the data in the transfer data structure, to the capacity storage tier (“At 310, the data is destaged from the staging area to the second storage tier” [0057])
Gao and Kondapalli are considered analogous to the claimed invention because they all relate to the same field of ingesting data into a storage system comprising at least a first storage tier and a second storage tier. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gao with the teachings of Kondapalli and realize a method of assigning a second storage tier location identifier to data which is stored in a transfer data structure located within a first storage tier. Doing so enables a file system to reference data according to a format usable by the second tier without making additional changes to the data after destaging even though the data is not yet stored to the second storage tier, saving resources, time, and delay, as disclosed in Kondapalli ¶¶0055; 0013-14: “The second storage tier location identifier is provided to the file system … for referencing the data even though the data is not yet stored to the second storage tier.” [0055] // “a substantial amount of resources, time, and delay may be introduced when data is stored within the first storage tier for access by a file system using a storage format of the first storage tier … The file system must be updated to utilize the storage format of the second storage tier for each of the cold data blocks now stored within the second storage tier … The second storage tier location identifier may be provided to the file system. In this way, the data can be destaged to the second storage tier … in a consistent manner without the need to change how the file system references the data because the file system was already configured to utilize the second storage tier location identifier.” [0013-14]
Although Kondapalli ¶0057 discloses that a set of objects is built on the second storage tier before destaging data into the second storage tier, Kondapalli is silent regarding building a set of objects in the transfer data structure in the first storage tier for data to be destaged into the second storage tier. Specifically, the combined teachings of Gao and Kondapalli are silent regarding the following limitations:
a volume information data structure associated with the volume
build a set of objects for the data in which the data is stored in a transfer data structure in the performance storage tier; and
send the set of objects, which includes the data in the transfer data structure, to the capacity storage tier
However, Subramanian ‘725 discloses the following limitations:
a volume information data structure associated with the volume (“Volume information (volinfo) and file system information (fsinfo) blocks specify the layout of information in the file system … Each logical volume (file system) has an fsinfo block” [0040])
build (Fig. 5C, step B526) a set of objects (“a plurality of data chunks/blocks” [0092]) for the data in which the data is stored in a transfer data structure (“a transfer data structure (TLOG)” [0013] // TLOG 512, Fig. 5A) in the performance storage tier (Performance Tier 112, Fig. 5A)(“When data has to be written to the capacity tier 128, an object is built to include a plurality of data chunks/blocks” [0092] // “When data has to be moved from a performance tier to a capacity tier, the data is first buffered using the TLOG” [0023]) – As shown in Fig. 5C and detailed in ¶0092, an object including a plurality of data chunks/blocks is “built” each time data is written to a capacity tier 128. As clarified in ¶0023, data is first buffered (i.e., is “stored”) in a TLOG data structure (e.g., TLOG 512, Fig. 5A) before being moved to the capacity tier 128.--; and
send (Fig. 5C, step B530) the set of objects, which includes the data in the transfer data structure, to the capacity storage tier (Capacity Tier 128, Fig. 5A)(“After one or more objects have been built, the object with its data is transferred to the capacity tier 128” [0092])
Gao, Kondapalli, and Subramanian ‘725 are considered analogous to the claimed invention because they all relate to the same field of determining a storage tier for received write request data. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gao and Kondapalli with the teachings of Subramanian ‘725 and realize a method of building and sending a set of data objects from a transfer data structure to a second storage tier. Doing so would enable assembly of multiple objects for one or more volumes at the same time by providing a buffer space for data as objects are being built, improving the efficiency of consistency point (CP) write operations, as disclosed in Subramanian ‘725 ¶¶ 0081-82 // 0109: “A consistency point (CP) module 510 is used to manage CP operations … The CP module 510 then pushes the information regarding the dirty data into a TLOG metadata structure 512 … The TLOG 512 enables data to be buffered while an object is still being created” [0081-82] // “In another aspect, TLOG 512 enables assembly of multiple objects at the same time, for one or more volumes. This is again efficient for a CP write operation.” [0109]
Claims 3, 10, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Gao further in view of Kondapalli, Subramanian ‘725, and a foreign reference authored by Robles et al. (EP2270693A1)(published 2011)(cited by examiner in previous action)(hereafter referred to as Robles).
Regarding Claim 3,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 3. The combined teachings of Gao, Kondapalli, and Subramanian ‘725 disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above),
Kondapalli and Subramanian ‘725 are silent regarding determining available space in a TLOG before writing to the TLOG. Specifically, the combined teachings of Gao, Kondapalli, and Subramanian ‘725 are silent regarding the following limitations:
determining that space is available for the data in the transfer data structure prior to storing the data in the transfer data structure.
However, Robles discloses the following limitations:
determining (Fig. 4, step 426 ‘Yes’) that space is available for the data in the transfer data structure (“the file” [0081]) prior to storing (Fig. 4, step 412 ‘Yes’) the data in the transfer data structure (“If there is another pending file access request, in step 426, the file may be extended again if the pending request is a file write request and if there is not at least sufficient file space to complete the next write operation” [0085])) – Examiner considers writing data into a file as shown in Robles Fig. 4 as analogous to writing data into a TLOG as disclosed in Subramanian ‘725. As shown in Robles Fig. 4 and detailed in ¶0085, a data storage manager first checks whether “sufficient file space” is available (step 426) before completing a write operation on the file (step 412).
Gao, Kondapalli, Subramanian ‘725, and Robles are all considered analogous to the claimed invention because they all relate to the same field of managing the storage of host data into flash memory. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gao, Kondapalli, and Subramanian ‘725 with the teachings of Robles and realize a method of determining whether space is available in a transfer data structure prior to storing data in the transfer data structure. Doing so would enable a host cache storage system index to be updated whenever a file size is extended to accommodate a write operation, achieving necessary synchronization between a host and an embedded file system sharing a same non-volatile memory, as disclosed in Robles ¶¶0004; 0080: “the embedded processor shares the memory with the host, and utilizes a separate, additional file system, interfaced with the memory control software, to manage its data storage and retrieval. Synchronization between the host and an embedded processor file system is necessary when a host file system and an embedded processor file system are operated in parallel with one another to control shared access to a memory within a non-volatile memory card.” [0004] // “The data read or write operation in 408 does not trigger an update to the embedded cached storage system index 166, because the operation does not increase the size of the file. If enough space is not available, the write fails, and the file will be extended again in step 422 before the write is attempted again. Therefore, the host cached storage system index 146 is not made obsolete by a write operation using the embedded file system 164 in step 408.” [0080]
Regarding Claim 10,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 10. The combined teachings of Gao, Kondapalli, and Subramanian ‘725 disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above),
Kondapalli and Subramanian ‘725 is silent regarding determining available space in a TLOG before writing to (i.e., building objects in) the TLOG. Specifically, the combined teachings of Gao, Kondapalli, and Subramanian ‘725 are silent regarding the following limitations:
determining that space is unavailable in the transfer data structure for the data prior to building the set of objects; and sending a retriable error message to the client.
However, Robles discloses the following limitations:
determining (Fig. 4, step 426 ‘No’) that space is unavailable in the transfer data structure (“the file” [0085]) for the data prior to building (Fig. 4, step 408) the set of objects (“If the operation completed is a write operation, then control passes from step 410 to step 426, where the algorithm checks if sufficient file space was allocated for the write operation. If not, then control passes to step 422 … followed by 408” [0081]) – Examiner considers writing data into a file as shown in Robles Fig. 4 as analogous to building objects in a TLOG as disclosed in Subramanian ‘725. As shown in Robles Fig. 4 and detailed in ¶0081, a storage manager requests a file be extended (see step 422) after determining (see step 426) there is insufficient file space available for writing to a file (see step 408)--;
and sending (Fig. 4, step 422) a retriable error message to the client (“the host file system 144 is used to extend the file again” [0081] // Fig. 4) – As shown in Fig. 4 and detailed in ¶0081, in order to extend the size of a file after determining insufficient space for a write operation to the file, a storage manager 162 requests a host file system 144 (i.e., “the client”) extend the size of a file. Examiner considers requesting a host file system extend the size of a file as “sending a retriable error message” to the host file system.
Gao, Kondapalli, Subramanian ‘725, and Robles are all considered analogous to the claimed invention because they all relate to the same field of managing the storage of host data into flash memory. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gao, Kondapalli, and Subramanian ‘725 with the teachings of Robles and realize a method of determining whether space is available in a transfer data structure prior to storing data in the transfer data structure. Doing so would enable a host cache storage system index to be updated whenever a file size is extended to accommodate a write operation, achieving necessary synchronization between a host and an embedded file system sharing same non-volatile memory, as disclosed in Robles ¶¶0004; 0080: “the embedded processor shares the memory with the host, and utilizes a separate, additional file system, interfaced with the memory control software, to manage its data storage and retrieval. Synchronization between the host and an embedded processor file system is necessary when a host file system and an embedded processor file system are operated in parallel with one another to control shared access to a memory within a non-volatile memory card.” [0004] // “The data read or write operation in 408 does not trigger an update to the embedded cached storage system index 166, because the operation does not increase the size of the file. If enough space is not available, the write fails, and the file will be extended again in step 422 before the write is attempted again. Therefore, the host cached storage system index 146 is not made obsolete by a write operation using the embedded file system 164 in step 408.” [0080]
Regarding Claim 16,
The same motivation to combine provided in Claim 11 is equally applicable to Claim 16. The combined teachings of Gao, Kondapalli, and Subramanian ‘725 disclose the following limitations:
The computing device of claim 11 (see Claim 11 limitation mappings above),
The combined teachings of Gao, Kondapalli, and Subramanian ‘725 are silent regarding the following limitations:
send a retriable error message to the client when space is unavailable in the transfer data structure for the data.
However, Robles discloses the following limitations:
send (Fig. 4, step 422) a retriable error message to the client when space is unavailable (Fig. 4, step 426 ‘No’) in the transfer data structure for the data (“If the operation completed is a write operation, then control passes from step 410 to step 426, where the algorithm checks if sufficient file space was allocated for the write operation. If not, then control passes to step 422, where the host file system 144 is used to extend the file again” [0081] // Fig. 4) – Examiner considers writing data into a file as shown in Robles Fig. 4 as analogous to writing data into a TLOG as disclosed in Subramanian ‘725. As shown in Robles Fig. 4 and detailed in ¶0081, a storage manager 162 sends a request to a host file system (step 422; i.e., to “the client”) after determining (step 426) that sufficient file space is not available for writing to the file. Examiner considers requesting a host file system extend the size of a file as “send[ing] a retriable error message” to the host file system.
Gao, Kondapalli, Subramanian ‘725, and Robles are all considered analogous to the claimed invention because they all relate to the same field of managing the storage of host data into flash memory. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gao, Kondapalli, and Subramanian ‘725 with the teachings of Robles and realize a method of determining whether space is available in a transfer data structure prior to storing data in the transfer data structure. Doing so would enable a host cache storage system index to be updated whenever a file size is extended to accommodate a write operation, achieving necessary synchronization between a host and an embedded file system sharing a same non-volatile memory, as disclosed in Robles ¶¶0004; 0080: “the embedded processor shares the memory with the host, and utilizes a separate, additional file system, interfaced with the memory control software, to manage its data storage and retrieval. Synchronization between the host and an embedded processor file system is necessary when a host file system and an embedded processor file system are operated in parallel with one another to control shared access to a memory within a non-volatile memory card.” [0004] // “The data read or write operation in 408 does not trigger an update to the embedded cached storage system index 166, because the operation does not increase the size of the file. If enough space is not available, the write fails, and the file will be extended again in step 422 before the write is attempted again. Therefore, the host cached storage system index 146 is not made obsolete by a write operation using the embedded file system 164 in step 408.” [0080]
Claims 6 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Gao further in view of Kondapalli, Subramanian ‘725 and Katsuragi et al. (US 20060064550 A1)(cited by examiner in previous action)(hereafter referred to as Katsuragi).
Regarding Claim 6,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 6. The combined teachings of Gao, Kondapalli, and Subramanian ‘725 disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above), wherein determining that the bypass write mode is enabled comprises: determining whether … a volume information data structure (Gao, Mode Selection Information 410, Figs. 4A + 5) associated with the volume (Subramanian ‘725, “Volume information (volinfo) and file system information (fsinfo) blocks specify the layout of information in the file system … Each logical volume (file system) has an fsinfo block” [0040]) indicates that the bypass write mode is enabled for the volume (Gao, Fig. 4A // ¶0264) – As previously discussed (see Claim 1 limitation mappings above) and as detailed in Gao, mode selection information 410 (i.e., “a volume information data structure”; see also Gao Fig. 5) indicates that bypass mode is enabled for a volume (see Fig. 4A // ¶0264). As clarified in Subramanian ‘725 ¶0040, “volume information” and “file system information” associated with “each logical volume” (i.e., “a volume information data structure associated with the volume”) stores information relating to the volume.
The combined teachings of Gao, Kondapalli, and Subramanian ‘725 are silent regarding the following limitations:
a flag in a volume information data structure associated with the volume
However, Katsuragi discloses the following limitations:
a flag (“write-through flag” [0101]) in a volume information data structure (Write-Through Flag Management Table T2, Fig. 6b) associated with the volume (“Therefore, in the event of an abnormality in the cache memory 130, provided that the write-through flag has not been set to off, a write access operation directed to that LDEV will be processed by means of a write-through method” [0107] // Figs. 1a – 1c // ¶¶0061-67) – As shown in Figs. 1a – 1c and described in ¶0107, a “write-through flag” associated with a given logical volume (LDEV) indicates during a cache failure that a redundant copy of host data should be written to a volume in storage (Volume 6A, Fig. 1b) as opposed to another region of cache (Second Cache 5, Fig. 1a). Examiner accordingly considers the write-through flag table T2 disclosed in Katsuragi Fig. 6b as analogous to Mode Selection Information 410 disclosed in Gao Fig. 5 because both are information used to inform a write path for a given write operation (i.e., “a volume information data structure”).
Gao, Kondapalli, Subramanian ‘725, and Katsuragi are all considered analogous to the claimed invention because they all relate to the same field of determining a write mode for host write data in systems comprising plural storage tiers. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gao, Kondapalli, and Subramanian ‘725 with the teachings of Katsuragi and realize a method of using a flag in a volume information data structure to determine a write mode for a volume. Doing so would enable a write mode to be preset on an individual volume basis, amounting to improved usability over conventional storage systems, as disclosed in Katsuragi ¶¶0007-08: “In a conventional storage device, it is possible to switch between a write-through method and an after-write method for the storage device as a whole, but it is not possible, for example, to set write methods individually for units specified by the user, for instance, different methods cannot be applied respectively to different logical volumes, and therefore usability is poor. Therefore, one object of the present invention is to provide a storage device and a write processing method for a storage device whereby any one of a plurality of processing modes for write access can be applied respectively and individually to prescribed units.” [0007-08]
Regarding Claim 13,
The same motivation to combine provided in Claim 11 is equally applicable to Claim 13. The combined teachings of Gao, Kondapalli, and Subramanian ‘725 disclose the following limitations:
The computing device of claim 11 (see Claim 11 limitation mappings above), wherein the processor is further configured to determine that the bypass write mode is enabled by determining that… (Gao, Mode Selection Information 410, Figs. 4A + 5) associated with the volume (Subramanian ‘725, “Volume information (volinfo) and file system information (fsinfo) blocks specify the layout of information in the file system … Each logical volume (file system) has an fsinfo block” [0040]) indicates that the bypass write mode is enabled for the volume (Gao, Fig. 4A // ¶0264) – As previously discussed (see Claim 11 limitation mappings above) and as detailed in Gao, mode selection information 410 indicates that bypass mode is enabled for a volume (see Fig. 4A // ¶0264). As clarified in Subramanian ‘725 ¶0040, “volume information” and “file system information” associated with “each logical volume” (i.e., “associated with the volume”) stores information relating to the volume.
The combined teachings of Gao, Kondapalli, and Subramanian ‘725 are silent regarding the following limitations:
a flag associated with the volume
However, Katsuragi discloses the following limitations:
a flag (“write-through flag” [0101]) associated with the volume (“Therefore, in the event of an abnormality in the cache memory 130, provided that the write-through flag has not been set to off, a write access operation directed to that LDEV will be processed by means of a write-through method” [0107] // Figs. 1a – 1c // ¶¶0061-67) – As shown in Figs. 1a – 1c and described in ¶0107, a “write-through flag” associated with a given logical volume (LDEV) indicates during a cache failure that a redundant copy of host data should be written to a volume in storage (Volume 6A, Fig. 1b) as opposed to another region of cache (Second Cache 5, Fig. 1a). Examiner accordingly considers the write-through flag table T2 disclosed in Katsuragi Fig. 6b as analogous to Mode Selection Information 410 disclosed in Gao Fig. 5 because both are information used to inform a write path for a given write operation (i.e., “a volume information data structure”).
Gao, Kondapalli, Subramanian ‘725, and Katsuragi are all considered analogous to the claimed invention because they all relate to the same field of determining a write mode for host write data in systems comprising plural storage tiers. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gao, Kondapalli, and Subramanian ‘725 with the teachings of Katsuragi and realize a method of using a flag in a volume information data structure to determine a write mode for a volume. Doing so would enable a write mode to be preset on an individual volume basis, amounting to improved usability over conventional storage systems, as disclosed in Katsuragi ¶¶0007-08: “In a conventional storage device, it is possible to switch between a write-through method and an after-write method for the storage device as a whole, but it is not possible, for example, to set write methods individually for units specified by the user, for instance, different methods cannot be applied respectively to different logical volumes, and therefore usability is poor. Therefore, one object of the present invention is to provide a storage device and a write processing method for a storage device whereby any one of a plurality of processing modes for write access can be applied respectively and individually to prescribed units.” [0007-08]
Claims 8-9 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Gao further in view of Kondapalli, Subramanian ‘725 and Nagasaka (US 20230161504 A1)(cited by examiner in previous action)(hereafter referred to as Nagasaka).
Regarding Claim 8,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 8. The combined teachings of Gao, Kondapalli, and Subramanian ‘725 disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above), further comprising: initiating throttling of incoming data to the transfer data structure in response to an amount of storage space in the transfer data structure that is used (Subramanian ‘725, “In yet another aspect, the TLOG 412 may be used as a throttling mechanism to manage flow control. For example, when write operations to the capacity tier 128 are slow, the TLOG 512 will fill up quickly and may be used to provide feedback to throttle the rate at which data is being tiered.” [0111]) – As taught in Subramanian ‘725 ¶0111, the amount of space in a TLOG is used as a mechanism to throttle (i.e., “initiating throttling”) the rate at which “data is being tiered” (e.g., storing data in the TLOG; i.e., “incoming data to the transfer data structure”)
The combined teachings of Gao, Kondapalli, and Subramanian ‘725 are silent regarding the following limitations:
initiating throttling … in response to an amount of storage space in the transfer data structure that is used exceeding a start throttle threshold
However, Nagasaka discloses the following limitations:
initiating throttling … in response to an amount of storage space in the transfer data structure (“the first submission queue”, [Claim 2]) that is used exceeding a start throttle threshold (“start throttling the acquisition of requests from the first submission queue in a case where the number of requests stored in the first submission queue exceeds a first threshold” [Claim 2] // Fig. 1 // ¶0102) – Examiner considers a submission queue (e.g., Submission Queue 221 of Nagasaka Fig. 1) as analogous to a TLOG 512 as disclosed in Subramanian ‘725 Fig. 5A because both are data structures used to facilitate the transfer of data into storage. As detailed in Nagasaka Claim 2 (see also ¶0102), throttling is initiated when the number of requests stored in a submission queue exceeds a first threshold (i.e., “a start throttle threshold”).
Gao, Kondapalli, Subramanian ‘725, and Nagasaka are all considered analogous to the claimed invention because they all relate to the same field of staging host data before storage into a flash memory. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gao, Kondapalli, and Subramanian ‘725 with the teachings of Nagasaka and realize a start throttle threshold for a transfer data structure. Doing so would enable transfer data structures to be individually throttled based on their individual capacities, enabling improved balance of utilization of submission queues and FIFO areas, as disclosed in Nagasaka ¶0071: “In order to strike a balance of the numbers of host commands to be processed in the controller 4 among the submission queues 221, for example, it is conceivable to control throttling of host commands acquired from the corresponding submission queue 221 in accordance with the number of NAND commands stored in each of the FIFO areas 41.” [0071]
Regarding Claim 9,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 9. The combined teachings of Gao, Kondapalli, and Subramanian ‘725 disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above), further comprising: halting throttling of incoming data to the transfer data structure in response to an amount of storage space in the transfer data structure that is used (Subramanian ‘725, “In yet another aspect, the TLOG 412 may be used as a throttling mechanism to manage flow control. For example, when write operations to the capacity tier 128 are slow, the TLOG 512 will fill up quickly and may be used to provide feedback to throttle the rate at which data is being tiered.” [0111]) – As taught in Subramanian ‘725 ¶0111, the amount of space in a TLOG is used as a mechanism to throttle (i.e., “halting throttling”) the rate at which “data is being tiered” (e.g., storing data in the TLOG; i.e., “incoming data to the transfer data structure”)
The combined teachings of Gao, Kondapalli, and Subramanian ‘725 are silent regarding the following limitations:
halting throttling … in response to an amount of storage space in the transfer data structure that is used falling below a stop throttle threshold
However, Nagasaka discloses the following limitations:
halting throttling … in response to an amount of storage space in the transfer data structure (“the first submission queue”, [Claim 2]) that is used falling below a stop throttle threshold (“not throttling of acquisition of requests from the first submission queue in a case where the number of requests stored in the first submission queue is equal to or less than the first threshold” [Claim 2] // Fig. 1 // ¶0091) – Examiner considers a submission queue (e.g., Submission Queue 221 of Nagasaka Fig. 1) as analogous to a TLOG 512 as disclosed in Subramanian ‘725 Fig. 5A because both are data structures used to facilitate the transfer of data into storage. As detailed in Nagasaka Claim 2 (see also ¶0091), throttling is halted when the number of requests stored in a submission queue is below a first threshold (i.e., “a stop throttle threshold”).
Gao, Kondapalli, Subramanian ‘725, and Nagasaka are all considered analogous to the claimed invention because they all relate to the same field of staging host data before storage into a flash memory. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gao, Kondapalli, and Subramanian ‘725 with the teachings of Nagasaka and realize a start throttle threshold for a transfer data structure. Doing so would enable transfer data structures to be individually throttled based on their individual capacities, enabling improved balance of utilization of submission queues and FIFO areas, as disclosed in Nagasaka ¶0071: “In order to strike a balance of the numbers of host commands to be processed in the controller 4 among the submission queues 221, for example, it is conceivable to control throttling of host commands acquired from the corresponding submission queue 221 in accordance with the number of NAND commands stored in each of the FIFO areas 41.” [0071]
Regarding Claim 19,
The same motivation to combine provided in Claim 18 is equally applicable to Claim 19. The combined teachings of Gao, Kondapalli, and Subramanian ‘725 disclose the following limitations:
The non-transitory machine-readable medium of claim 18 (see Claim 18 limitation mappings above), wherein the machine-executable code which, when executed by the at least one machine, further causes the at least one machine to initiate throttling of incoming data to the transfer data structure in response to an amount of storage space in the transfer data structure that is used (Subramanian ‘725, “In yet another aspect, the TLOG 412 may be used as a throttling mechanism to manage flow control. For example, when write operations to the capacity tier 128 are slow, the TLOG 512 will fill up quickly and may be used to provide feedback to throttle the rate at which data is being tiered.” [0111]) – As taught in Subramanian ‘725 ¶0111, the amount of space in a TLOG is used as a mechanism to throttle (i.e., “initiate throttling”) the rate at which “data is being tiered” (e.g., storing data in the TLOG; i.e., “incoming data to the transfer data structure”)
The combined teachings of Gao, Kondapalli, and Subramanian ‘725 are silent regarding the following limitations:
initiate throttling … in response to an amount of storage space in the transfer data structure that is used exceeding a start throttle threshold.
However, Nagasaka discloses the following limitations:
initiate throttling … in response to an amount of storage space in the transfer data structure (“the first submission queue”, [Claim 2]) that is used exceeding a start throttle threshold (“start throttling the acquisition of requests from the first submission queue in a case where the number of requests stored in the first submission queue exceeds a first threshold” [Claim 2] // Fig. 1 // ¶0102) – Examiner considers a submission queue (e.g., Submission Queue 221 of Nagasaka Fig. 1) as analogous to a TLOG 512 as disclosed in Subramanian ‘725 Fig. 5A because both are data structures used to facilitate the transfer of data into storage. As detailed in Nagasaka Claim 2 (see also ¶0102), throttling is initiated when the number of requests stored in a submission queue exceeds a first threshold (i.e., “a start throttle threshold”).
Gao, Kondapalli, Subramanian ‘725, and Nagasaka are all considered analogous to the claimed invention because they all relate to the same field of staging host data before storage into a flash memory. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gao, Kondapalli, and Subramanian ‘725 with the teachings of Nagasaka and realize a start throttle threshold for a transfer data structure. Doing so would enable transfer data structures to be individually throttled based on their individual capacities, enabling improved balance of utilization of submission queues and FIFO areas, as disclosed in Nagasaka ¶0071: “In order to strike a balance of the numbers of host commands to be processed in the controller 4 among the submission queues 221, for example, it is conceivable to control throttling of host commands acquired from the corresponding submission queue 221 in accordance with the number of NAND commands stored in each of the FIFO areas 41.” [0071]
Regarding Claim 20,
The same motivation to combine provided in Claim 18 is equally applicable to Claim 20. The combined teachings of Gao, Kondapalli, and Subramanian ‘725 disclose the following limitations:
The non-transitory machine-readable medium of claim 18 (see Claim 18 limitation mappings above), wherein the machine-executable code which, when executed by the at least one machine, further causes the at least one machine to halt throttling of incoming data to the transfer data structure in response to an amount of storage space in the transfer data structure that is used (Subramanian ‘725, “In yet another aspect, the TLOG 412 may be used as a throttling mechanism to manage flow control. For example, when write operations to the capacity tier 128 are slow, the TLOG 512 will fill up quickly and may be used to provide feedback to throttle the rate at which data is being tiered.” [0111]) – As taught in Subramanian ‘725 ¶0111, the amount of space in a TLOG is used as a mechanism to throttle (i.e., “halt throttling”) the rate at which “data is being tiered” (e.g., storing data in the TLOG; i.e., “incoming data to the transfer data structure”)
The combined teachings of Gao, Kondapalli, and Subramanian ‘725 are silent regarding the following limitations:
halt throttling … in response to an amount of storage space in the transfer data structure that is used falling below a stop throttle threshold.
However, Nagasaka discloses the following limitations:
halt throttling … in response to an amount of storage space in the transfer data structure (“the first submission queue”, [Claim 2]) that is used falling below a stop throttle threshold (“not throttling of acquisition of requests from the first submission queue in a case where the number of requests stored in the first submission queue is equal to or less than the first threshold” [Claim 2] // Fig. 1 // ¶0091) – Examiner considers a submission queue (e.g., Submission Queue 221 of Nagasaka Fig. 1) as analogous to a TLOG 512 as disclosed in Subramanian ‘725 Fig. 5A because both are data structures used to facilitate the transfer of data into storage. As detailed in Nagasaka Claim 2 (see also ¶0091), throttling is halted when the number of requests stored in a submission queue is below a first threshold (i.e., “a stop throttle threshold”).
Gao, Kondapalli, Subramanian ‘725, and Nagasaka are all considered analogous to the claimed invention because they all relate to the same field of staging host data before storage into a flash memory. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gao, Kondapalli, and Subramanian ‘725 with the teachings of Nagasaka and realize a start throttle threshold for a transfer data structure. Doing so would enable transfer data structures to be individually throttled based on their individual capacities, enabling improved balance of utilization of submission queues and FIFO areas, as disclosed in Nagasaka ¶0071: “In order to strike a balance of the numbers of host commands to be processed in the controller 4 among the submission queues 221, for example, it is conceivable to control throttling of host commands acquired from the corresponding submission queue 221 in accordance with the number of NAND commands stored in each of the FIFO areas 41.” [0071]
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
With respect to applicant’s argument located within the final paragraph of the 2nd page of Remarks (numbered as page 9) continuing through the 3rd page of Remarks (numbered as page 10), which recites:
“In ¶¶ [0159]-[0160] of Gao relied upon by the Examiner, the undersigned notes the Amazon Elastic Block Store (EBS) volumes are not being used as a "performance storage tier" or a "capacity storage tier," as now recited, but rather are being used in place of Non-Volatile Random Access Memory (NVRAM). See, e.g., Gao at [0160]. … Regardless, non- storage class memory would not be considered by those skilled in the art to be part of the recited performance storage tier or the recited capacity storage tier. Rather, in the context of storage systems (and consistent with the usage model described by Gao), NVRAM is typically used as a high-speed, persistent buffer to instantly store incoming write data and critical metadata so as to prevent data loss during power outages. … For at least these reasons, independent claim 1 (as amended) and its dependent claims, which add further features, are thought to be clearly distinguishable over the Examiner's proposed combination of Gao, Kondapalli, and Subramanian.”
Examiner has fully considered the aforementioned argument but finds it moot in view of the updated mappings of the independent claims to the Gao reference. Applicant argues that examiner’s mapping of Non-Storage Class Memory 404 of Gao Fig. 4A to a claimed “storage tier” is improper because non-storage classes of memory would be considered to one of ordinary skill in the art as a type of “memory” as opposed to a type of “storage”. Examiner notes that the aforementioned argument is moot in view of the current mappings to Gao, which map the claimed “performance storage tier” to Type 1 Storage Class Memory 418 of Gao Fig. 4B and which map the claimed “capacity storage tier” to Type 2 Storage Class Memory 420. See 35 U.S.C. 103 rejections above for additional details. The updated mappings of independent claims to the Gao reference was necessitated by the instant amendments.
With respect to applicant’s argument located within the final paragraph of the 3rd page of Remarks (numbered as page 10), which recites:
“With respect to the above-quoted "determining" features, for the former version of these features (prior to the amendments proposed herein), the Examiner relied on Gao at 1 [0264], [0269]-[0280], FIG. 4A, and FIG. 5. As evidenced by FIG. 4A of Gao, the bypass write path 416 does not bypass any storage class memory (e.g., storage class memory 406) that might represent or be part of a performance storage tier or a capacity storage tier. Rather, the write path 416 bypasses non-storage class memory (e.g., non-storage class memory 404), which as noted above would not be part of a performance storage tier or a capacity storage tier of a storage system. As such, the bypassing described by Gao cannot be reasonably equated with "bypassing of the performance storage tier" as now recited. For at least this additional reason, independent claim 1 (as amended) and its dependent claims, which add further features, are thought to be clearly distinguishable over the Examiner's proposed combination of Gao, Kondapalli, and Subramanian.”
Examiner has fully considered the aforementioned argument but finds it moot in view of the updated mappings of the independent claims to the Gao reference. Applicant argues that examiner’s mapping of write path 416 of Gao Fig. 4A to the claimed concept of “bypassing of the performance storage tier” is improper because bypassing of Non-Storage Class Memory 404 cannot be considered as bypassing of a “storage” tier. Examiner notes that the aforementioned argument is moot in view of the current mappings to Gao, which map the claimed concept of “bypassing of the performance storage tier” to a write path 426 of Gao Fig. 4B, which as shown bypasses a Type 1 Storage Class Memory 418 and instead writes data into a Type 2 Storage Class Memory 420. See 35 U.S.C. 103 rejections above for additional details.
Applicant’s arguments located within the 4-5th pages of Remarks (numbered as pages 11-12) with respect to dependent claims are moot for the same reasoning discussed above with respect to the independent claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JULIAN SCOTT MENDEL whose telephone number is (703)756-1608. The examiner can normally be reached M-F 10am - 4pm 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, Rocío del Mar Pérez-Vélez can be reached on 571-270-5935. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.S.M./Examiner, Art Unit 2133
/SEAN D ROSSITER/Primary Examiner, Art Unit 2133
Prosecution Insights