DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
In the event a determination of the status of the application as subject to AIA 35 U.S.C. 102, 103, and 112 (or as subject to pre-AIA 35 U.S.C. 102, 103, and 112) is incorrect, any correction of the statutory basis for a rejection will not be considered a new ground of rejection if the prior art relied upon and/or the rationale supporting the rejection, would be the same under either status.
Notice of Claim Interpretation
Claims in this application are not interpreted under 35 U.S.C. 112(f) unless otherwise noted in an office action.
Priority
PCT Rule 4.11(a) states
“If:
(i) the applicant intends to make an indication under Rule 49bis.1(a) or (b) of the wish that the international application be treated, in any designated State, as an application for a patent of addition, certificate of addition, inventor’s certificate of addition or utility certificate of addition; or
(ii) the applicant intends to make an indication under Rule 49bis.1(d) of the wish that the international application be treated, in any designated State, as an application for a continuation or a continuation-in-part of an earlier application;
the request shall so indicate and shall indicate the relevant parent application or parent patent or other parent grant.
This application is the United States national stage of international application PCT/CN2021/075779 under 35 U.S.C. 371. This application also includes an indication that this application is a continuation of international application PCT/CN2021/075779. Therefore, this application fails to comply with PCT Rule 4.11(a) because the indication is not to a relevant parent application, parent patent, or other parent grant, but rather the indication is to this very application.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Stearns et al. (US 2017/0308303) in view of Challenger et al. (US 6,643,754) and Joglekar et al. (US 2007/0130364).
In regards to claim 1, Sterns teaches a method implemented by one or more processors of a storage engine, the method comprising:
receiving data including a plurality of records from a client device (“The storage system 102 may receive data transactions (e.g., requests to write and/or read data) from one or more of the hosts 104, and take an action such as reading, writing, or otherwise accessing the requested data.”, paragraph 0019);
generating a plurality of record headers for the plurality of records (“The contents includes an example header 510 according to one embodiment.”, paragraph 0043; “Per-extent there is a unique identifier (extent ID) and a length indication. The extent ID does not have to be the full identifier, but should be enough of the identifier to properly identify the extent within the block.”, paragraph 0049);
sending the group of record headers of the plurality of record headers to a storage device to cause the storage device to consecutively store the group of record headers as a whole at a beginning part of a data sector of the storage device (“In this example the contents of the storage block are read left to right and top to bottom, and header 510 placed at the beginning of the storage block.”, paragraph 0043; See also figure 4; “Storage block 402 includes an in-line descriptor, and when read from left to right, the in-line descriptor is configured as a footer (rather than a header). However, the scope of embodiments includes configuring in-line descriptors as either headers or footers as appropriate.”, paragraph 0039); and
sending a subset of payload data of one or more records associated with the group of record headers to the storage device to cause the storage device to store the one or more records after the group of record headers in the data sector of the storage device (“User data 520 includes the data extents themselves.”, paragraph 0043; “A Continuation Block is a storage block that does not contain the head of a new object and contains the continuation of a data extent whose head is in a previous storage block, an example of which is storage block 404 of FIG. 3.”, paragraph 0047), wherein all record headers that are stored in the data sector are stored in the beginning part of the data sector and located before payload data of all records that are stored in the data sector (“In this example the contents of the storage block are read left to right and top to bottom, and header 510 placed at the beginning of the storage block.”, paragraph 0043; See also figure 4; “Storage block 402 includes an in-line descriptor, and when read from left to right, the in-line descriptor is configured as a footer (rather than a header). However, the scope of embodiments includes configuring in-line descriptors as either headers or footers as appropriate.”, paragraph 0039).
Sterns fails to explicitly teach creating a scatter-gather list including a plurality of entries, the plurality of entries including at least a first single entry pointing to a start address of a group of record headers of the plurality of record headers, consecutive entries pointing to respective start addresses of one or more records associated with the group of record headers, and a second single entry pointing to a start address of a padding data buffer;
sending the group of record headers as a whole in a single data transfer; and
sending the subset of payload data after the group of record headers are sent to the storage device and are stored consecutively in the data sector of the storage device.
Sterns teaches different orderings for sending the subset of payload data and sending the group of record headers to the storage device and storing the group of record headers consecutively in the data sector of the storage device (“Action 1030 includes storing the descriptor within the particular block. However, it should be noted that the scope of embodiments is not limited to any particular sequence of events for storing either the in-line descriptor or the data within a storage block. Various embodiments store the data and the in-line descriptor in the block in a single write operation.”, paragraph 0063). There are thirteen possible orders of the steps in figure 9, including orderings where multiple steps are performed simultaneously. Of those thirteen, eight violate the causal relationship between steps 1020 and 1030 because the descriptor must be generated before it is stored. Of the five remaining orderings, one is 1020 followed by 1030 followed by 1010. This ordering meets the claim limitation. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to try each of the five remaining orderings including the one that meets the claim limitations with a reasonable expectation of success.
Sterns fails to explicitly teach creating a scatter-gather list including a plurality of entries, the plurality of entries including at least a first single entry pointing to a start address of a group of record headers of the plurality of record headers, consecutive entries pointing to respective start addresses of one or more records associated with the group of record headers, and a second single entry pointing to a start address of a padding data buffer; and
sending the group of record headers as a whole in a single data transfer.
Challenger teaches sending the group of record headers as a whole in a single data transfer (“To minimize disk operations, these header fields can be maintained in contiguous bytes of disk storage. In this way, the headers can be updated efficiently, such as by a single block write or by multiple writes but with little movement of disk heads, b is added to the head of the free list.”, Col. 9, lines 11-16) in order to permit efficient updates (id.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Sterns with Challenger to include sending the group of record headers as a whole in a single data transfer in order to permit efficient updates (id.).
Stern in view of Challenger fails to teach creating a scatter-gather list including a plurality of entries, the plurality of entries including at least a first single entry pointing to a start address of a group of record headers of the plurality of record headers, consecutive entries pointing to respective start addresses of one or more records associated with the group of record headers, and a second single entry pointing to a start address of a padding data buffer. Joglekar teaches creating a scatter-gather list including a plurality of entries, the plurality of entries including at least a first single entry pointing to a start address of a group of record headers of the plurality of record headers, consecutive entries pointing to respective start addresses of one or more records associated with the group of record headers, and a second single entry pointing to a start address of a padding data buffer (“The iSCSI stack may also create a scatter-gather list (SGL) with scatter-gather elements (SGEs) pointing to the header, the data, any markers in the data, and pad bytes.”, paragraph 0029) to enable a network component to determine integrity validation values (paragraph 0014). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Sterns with Challenger and Joglekar to include creating a scatter-gather list including a plurality of entries, the plurality of entries including at least a first single entry pointing to a start address of a group of record headers of the plurality of record headers, consecutive entries pointing to respective start addresses of one or more records associated with the group of record headers, and a second single entry pointing to a start address of a padding data buffer to enable a network component to determine integrity validation values (id.).
In regards to claim 2, Sterns further teaches that sending the group of record headers of the plurality of record headers to the storage device to cause the storage device to store the group of record headers consecutively in the data sector of the storage device is performed through a single data transfer between the storage engine and the storage device (“Various embodiments store the data and the in-line descriptor in the block in a single write operation.”, paragraph 0063).
In regards to claim 3, Sterns further teaches storing the plurality of record headers and the plurality of records in a memory of the storage engine (“In an embodiment, write data may be received from one or more hosts 104 and momentarily stored in a write-back cache of the storage system 102, e.g. using LBAs before being stored to devices 106.”, paragraph 0027).
In regards to claim 7, Sterns further teaches that generating the plurality of record headers for the plurality of records is performed after receiving the data including the plurality of records from the client device (“At action 1010, the storage controller stores a first data extent on a physical medium.”, paragraph 0059; “Action 1020 includes generating a descriptor of the first data extent.”, paragraph 0060).
Claims 4 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Stearns et al. (US 2017/0308303) in view of Challenger et al. (US 6,643,754), Joglekar et al. (US 2007/0130364), and Gissin et al. (US 2018/0157445).
In regards to claim 4, Stearns in view of Challenger and Joglekar teaches claim 3. Stearns in view of Challenger and Joglekar fails to teach storing the scatter-gather list in the memory of the storage engine. Gissin teaches storing the scatter-gather list in a memory of the storage engine (“Step S102: After receiving the write command, the network adapter 201 in the target 200 obtains a length that is of the to-be-stored data and that is carried in the write command”, paragraph 0028) in order “to resolve a problem of a complex processing mechanism caused by buffering a data read/write command when a storage space of a network adapter memory in a target is insufficient” (paragraph 0020). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stearns with Challenger, Joglekar, and Gissin to include storing the scatter-gather list in a memory of the storage engine in order “to resolve a problem of a complex processing mechanism caused by buffering a data read/write command when a storage space of a network adapter memory in a target is insufficient” (id.).
In regards to claim 5, Stearns in view of Challenger and Joglekar teaches claim 1. Stearns in view of Challenger and Joglekar fails to teach locating the group of record headers in the memory of the storage engine based at least in part on the scatter-gather list prior to sending the group of record headers to the storage device); or
locating the one or more records in the memory of the storage engine based at least in part on the scatter-gather list prior to sending the one or more records to the storage device.
Gissin teaches locating the group of record headers in the memory of the storage engine based at least in part on the scatter-gather list prior to sending the group of record headers to the storage device (“the network adapter 401 writes the to-be-stored data into the network adapter memory 4012”, paragraph 0097); or
locating the one or more records in the memory of the storage engine based at least in part on the scatter-gather list prior to sending the one or more records to the storage device (“the network adapter 401 writes the to-be-stored data into the network adapter memory 4012”, paragraph 0097)
in order “to resolve a problem of a complex processing mechanism caused by buffering a data read/write command when a storage space of a network adapter memory in a target is insufficient” (paragraph 0020).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stearns with Challenger, Joglekar, and Gissin to include locating the group of record headers in the memory of the storage engine based at least in part on the scatter-gather list prior to sending the group of record headers to the storage device); or
locating the one or more records in the memory of the storage engine based at least in part on the scatter-gather list prior to sending the one or more records to the storage device
in order “to resolve a problem of a complex processing mechanism caused by buffering a data read/write command when a storage space of a network adapter memory in a target is insufficient” (id.).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Stearns et al. (US 2017/0308303) in view of Challenger et al. (US 6,643,754), Joglekar et al. (US 2007/0130364), Gissin et al. (US 2018/0157445), and Barrus (US 2015/0106579).
In regards to claim 6, Stearns further teaches that the plurality of record headers and the plurality of records are stored in one or more sectors of the storage device (“FIG. 4 is an illustration of contents of an example storage block according to one embodiment. The contents includes an example header 510 according to one embodiment. For instance, header 510 could be used in the embodiment of FIG. 3 to implement in-line descriptors 412-414. In this example the contents of the storage block are read left to right and top to bottom, and header 510 placed at the beginning of the storage block. User data 520 includes the data extents themselves.”, paragraph 0043).
Stearns in view of view of Challenger, Joglekar, and Gissin fails to teach that the padding data buffer is configured to provide padding data for logical block alignment at an end of a last sector of the one or more sectors of the storage device. Barrus teaches that the padding data buffer is configured to provide padding data for logical block alignment at an end of a last sector of the one or more sectors of the storage device (“If the data objects 310 do not fill all the space of the data field 220, the session 200 may comprise an alignment padding zone 330 at the end of data field 220 to occupy space between the data objects 310 and a natural alignment boundary.”, paragraph 0046) in order to occupy space to a natural alignment boundary (id.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stearns with Challenger, Joglekar, Gissin, and Barrus such that the padding data buffer is configured to provide padding data for logical block alignment at an end of a last sector of the one or more sectors of the storage device in order to occupy space to a natural alignment boundary (id.).
Claims 8 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Stearns et al. (US 2017/0308303) in view of Challenger et al. (US 6,643,754), Joglekar et al. (US 2007/0130364), and Jung et al. (KR 2020/0120113) as supported by its translation.
In regards to claim 8, Stearns in view of Challenger and Joglekar teaches claim 1. Stearns in view of Challenger and Joglekar fails to teach temporarily storing the plurality of record headers consecutively in a memory of the storage engine before each of the plurality of record headers is sent to the storage device and is successfully stored in the storage device. Jung as supported by its translation teaches temporarily storing the plurality of record headers consecutively in a memory of the storage engine (“As described above, the controller 130 may include a write buffer 306, and the write buffer 306 writes the data corresponding to the program command provided from the host 102 to the memory block before programming the data. Can be stored temporarily. The ring buffer 404 may refer to a write buffer 306 that buffers data in the ring buffer method.”, page 7, paragraph 6; “Unlike the ring buffer method, the controller 130 normally programs the data buffered in the scatter gather buffer 506 into the memory block, regardless of the order in which the scatter gather buffer 506 is buffered”, page 8, paragraph 7) before each of the plurality of record headers is sent to the storage device and is successfully stored in the storage device (“In both the ring buffer method and the scatter-gather method, data that is program-failed may not be deleted from the write buffer 306.”, page 7, paragraph 3) which “can provide a more improved program speed compared to the normal program operation” (page 6, paragraph 1). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stearns with Challenger, Joglekar, and Jung as supported by its translation to include temporarily storing the plurality of record headers consecutively in a memory of the storage engine before each of the plurality of record headers is sent to the storage device and is successfully stored in the storage device which “can provide a more improved program speed compared to the normal program operation” (id.).
In regards to claim 9, Jung as supported by its translation further teaches deleting the plurality of record headers from the memory of the storage engine after each of the plurality of record headers is sent to the storage device and is successfully stored in the storage device (“The controller 130 may delete the buffered data from the ring buffer 404 when the memory device 150 normally programs the data buffered in the ring buffer 404 into a memory block.”, page 7, paragraph 8).
Claims 10, 12-14, and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Stearns et al. (US 2017/0308303) in view of Challenger et al. (US 6,643,754) and Jang et al. (US 2019/0332283).
In regards to claim 10, Sterns teaches one or more processor readable media storing executable instructions (“Accordingly, it is understood that any operation of the computing system according to the aspects of the present disclosure may be implemented by the computing system using corresponding instructions stored on or in a non-transitory computer readable medium accessible by the processing system.”, paragraph 0067) that, when executed by one or more processors of a storage device, cause the one or more processors to perform acts (“The main CPU executes computer readable code to perform most of the actions described herein.”, paragraph 0051) comprising:
receiving a plurality of record headers associated with a plurality of records (“The contents includes an example header 510 according to one embodiment.”, paragraph 0043; “Per-extent there is a unique identifier (extent ID) and a length indication. The extent ID does not have to be the full identifier, but should be enough of the identifier to properly identify the extent within the block.”, paragraph 0049) from a storage engine (storage controllers 108, figure 1);
consecutively storing the plurality of record headers as a whole in a beginning part of a sector of the storage device, wherein all record headers that are stored in the data sector are stored in the beginning part of the data sector (“In this example the contents of the storage block are read left to right and top to bottom, and header 510 placed at the beginning of the storage block.”, paragraph 0043; See also figure 4; “Storage block 402 includes an in-line descriptor, and when read from left to right, the in-line descriptor is configured as a footer (rather than a header). However, the scope of embodiments includes configuring in-line descriptors as either headers or footers as appropriate.”, paragraph 0039);
receiving the plurality of records from the storage engine (“User data 520 includes the data extents themselves.”, paragraph 0043); and
storing the plurality of records after the plurality of record headers in the sector of the storage device (“In this example the contents of the storage block are read left to right and top to bottom, and header 510 placed at the beginning of the storage block.”, paragraph 0043; See also figure 4).
Sterns fails to explicitly teach receiving the plurality of record headers as a whole in a single data transfer;
receiving the plurality of records from the storage engine after the plurality of record headers are consecutively stored in the sector of the storage device; and
writing a pointer indicating a start offset of a first record of the plurality of records into a metadata area located at an end of the sector of the storage device.
Sterns teaches different orderings for receiving the plurality of records from the storage engine and storing the plurality of record headers consecutively in the sector of the storage device (“Action 1030 includes storing the descriptor within the particular block. However, it should be noted that the scope of embodiments is not limited to any particular sequence of events for storing either the in-line descriptor or the data within a storage block. Various embodiments store the data and the in-line descriptor in the block in a single write operation.”, paragraph 0063). There are thirteen possible orders of the steps in figure 9, including orderings where multiple steps are performed simultaneously. Of those thirteen, eight violate the causal relationship between steps 1020 and 1030 because the descriptor must be generated before it is stored. Of the five remaining orderings, one is 1020 followed by 1030 followed by 1010. This ordering meets the claim limitation. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to try each of the five remaining orderings including the one that meets the claim limitations with a reasonable expectation of success.
Sterns fails to explicitly teach receiving the plurality of record headers as a whole in a single data transfer; and
writing a pointer indicating a start offset of a first record of the plurality of records into a metadata area located at an end of the sector of the storage device.
Challenger teaches receiving the plurality of record headers as a whole in a single data transfer (“To minimize disk operations, these header fields can be maintained in contiguous bytes of disk storage. In this way, the headers can be updated efficiently, such as by a single block write or by multiple writes but with little movement of disk heads, b is added to the head of the free list.”, Col. 9, lines 11-16) in order to permit efficient updates (id.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Sterns with Challenger to include receiving the plurality of record headers as a whole in a single data transfer in order to permit efficient updates (id.).
Sterns in view of Challenger fails to teach writing a pointer indicating a start offset of a first record of the plurality of records into a metadata area located at an end of the sector of the storage device. Jang teaches writing a pointer indicating a start offset of a first record of the plurality of records into a metadata area located at an end of the sector of the storage device (“Further, the controller 110 may store the second offset OF2 of the storage region ST of the second physical page PPN2 in the spare region SP of the second physical page PPN2. For example, the second offset OF2 may be 4.”, paragraph 0056; See also figure 8) in order to scan and read a plurality of data in parallel (paragraph 0081). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Sterns with Challenger and Jang to include writing a pointer indicating a start offset of a first record of the plurality of records into a metadata area located at an end of the sector of the storage device in order to scan and read a plurality of data in parallel (id.).
In regards to claim 12, Sterns further teaches the acts further comprising:
receiving additional one or more record headers associated with additional one or more records from the storage engine (“The storage system 102 may receive data transactions (e.g., requests to write and/or read data) from one or more of the hosts 104, and take an action such as reading, writing, or otherwise accessing the requested data.”, paragraph 0019; “The contents includes an example header 510 according to one embodiment.”, paragraph 0043); and
storing the additional one or more record headers at a beginning part of a sector (“In this example the contents of the storage block are read left to right and top to bottom, and header 510 placed at the beginning of the storage block.”, paragraph 0043) that immediately follows the sector storing the plurality of records (“The last data extent in a block may spill into the next or many more blocks.”, paragraph 0047).
In regards to claim 13, Sterns further teaches the acts further comprising:
receiving the additional one or more records from the storage engine (“The storage system 102 may receive data transactions (e.g., requests to write and/or read data) from one or more of the hosts 104, and take an action such as reading, writing, or otherwise accessing the requested data.”, paragraph 0019; “User data 520 includes the data extents themselves.”, paragraph 0043); and
storing the additional one or more records after the additional one or more record headers in the sector that immediately follows the sector storing the plurality of records (“In this example the contents of the storage block are read left to right and top to bottom, and header 510 placed at the beginning of the storage block.”, paragraph 0043; See also figure 4).
In regards to claim 14, Jang further teaches the acts further comprising storing a start offset of a first record of the additional one or more records at a metadata area of the sector that immediately follows the sector storing the plurality of records (“Further, the controller 110 may store the third offset OF3 of the storage region ST of the third physical page PPN3 in the spare region SP of the third physical page PPN3. For example, the third offset OF3 may be 5.”, paragraph 0058).
In regards to claim 16, Sterns further teaches that the plurality of record headers associated with the plurality of records is received from the storage engine through the single data transfer between the storage engine and the storage device (“Various embodiments store the data and the in-line descriptor in the block in a single write operation.”, paragraph 0063).
In regards to claim 17, Sterns teaches a storage engine comprising:
one or more processors (“Specifically, a storage controller, such as one of the storage controllers 108 of FIG. 1, may include a main CPU as well as a processor included in an input output controller.”, paragraph 0051); and
memory storing executable instructions (“Accordingly, it is understood that any operation of the computing system according to the aspects of the present disclosure may be implemented by the computing system using corresponding instructions stored on or in a non-transitory computer readable medium accessible by the processing system.”, paragraph 0067) that, when executed by the one or more processors, cause the one or more processors to perform acts (“The main CPU executes computer readable code to perform most of the actions described herein.”, paragraph 0051) comprising:
obtaining a portion of data including a plurality of consecutive record headers from a beginning part of a sector that includes a record to be obtained in a storage device, wherein the plurality of consecutive record headers is stored consecutively in the sector of the storage device, and a plurality of records associated with the plurality of consecutive record headers is stored after the plurality of consecutive record headers, wherein all record headers that are stored in the data sector are stored in the beginning part of the data sector (“Processes in the storage controller use the block address to identify a storage block and then read the block as a whole in a single read operation, including user data and in-line descriptors. After having read the contents of the block, the processes may then parse the in-line descriptors to find the location of the first byte of the particular data extent.”, paragraph 0040; “Per-extent there is a unique identifier (extent ID) and a length indication. The extent ID does not have to be the full identifier, but should be enough of the identifier to properly identify the extent within the block.”, paragraph 0049; “In this example the contents of the storage block are read left to right and top to bottom, and header 510 placed at the beginning of the storage block.”, paragraph 0043; See also figure 4; “Storage block 402 includes an in-line descriptor, and when read from left to right, the in-line descriptor is configured as a footer (rather than a header). However, the scope of embodiments includes configuring in-line descriptors as either headers or footers as appropriate.”, paragraph 0039);
selecting a record header corresponding to the record to be obtained from the plurality of consecutive record headers (“After having read the contents of the block, the processes may then parse the in-line descriptors to find the location of the first byte of the particular data extent.”); and
obtaining the record to be obtained from the sector based at least in part on a record size included in the record header corresponding to the record to be obtained (“The storage system 102 executes the data transactions on behalf of the hosts 104 by writing, reading, or otherwise accessing data on the relevant storage devices 106.”, paragraph 0033).
Sterns fails to explicitly teach obtaining the portion of data after the plurality of consecutive record headers is received as a whole in a single data transfer from a storage engine; and
obtaining a pointer indicating a start offset of a first record written in a metadata area located at an end of the sector of the storage device.
Sterns teaches different orderings for obtaining the portion of data and receiving the plurality of consecutive record headers (“Action 1030 includes storing the descriptor within the particular block. However, it should be noted that the scope of embodiments is not limited to any particular sequence of events for storing either the in-line descriptor or the data within a storage block. Various embodiments store the data and the in-line descriptor in the block in a single write operation.”, paragraph 0063). There are thirteen possible orders of the steps in figure 9, including orderings where multiple steps are performed simultaneously. Of those thirteen, eight violate the causal relationship between steps 1020 and 1030 because the descriptor must be generated before it is stored. Of the five remaining orderings, one is 1020 followed by 1030 followed by 1010. This ordering meets the claim limitation. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to try each of the five remaining orderings including the one that meets the claim limitations with a reasonable expectation of success.
Sterns fails to explicitly teach that the plurality of consecutive record headers is received as a whole in a single data transfer from a storage engine; and
obtaining a pointer indicating a start offset of a first record written in a metadata area located at an end of the sector of the storage device.
Challenger teaches that the plurality of consecutive record headers is received as a whole in a single data transfer from a storage engine (“To minimize disk operations, these header fields can be maintained in contiguous bytes of disk storage. In this way, the headers can be updated efficiently, such as by a single block write or by multiple writes but with little movement of disk heads, b is added to the head of the free list.”, Col. 9, lines 11-16) in order to permit efficient updates (id.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Sterns with Challenger such that the plurality of consecutive record headers is received as a whole in a single data transfer from a storage engine in order to permit efficient updates (id.).
Sterns in view of Challenger fails to teach obtaining a pointer indicating a start offset of a first record written in a metadata area located at an end of the sector of the storage device. Jang teaches obtaining a pointer indicating a start offset of a first record written in a metadata area located at an end of the sector of the storage device (“Further, the controller 110 may store the second offset OF2 of the storage region ST of the second physical page PPN2 in the spare region SP of the second physical page PPN2. For example, the second offset OF2 may be 4.”, paragraph 0056; See also figure 8) in order to scan and read a plurality of data in parallel (paragraph 0081). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Sterns with Challenger and Jang to include obtaining a pointer indicating a start offset of a first record written in a metadata area located at an end of the sector of the storage device in order to scan and read a plurality of data in parallel (id.).
In regards to claim 18, Sterns further teaches that obtaining the record to be obtained from the sector comprises:
obtaining metadata from the sector of the storage device (“After having read the contents of the block, the processes may then parse the in-line descriptors to find the location of the first byte of the particular data extent.”), the metadata including the start offset of the first record in the sector (“The Initial Offset field determines the boundary between a data extent continued from the prior storage block and the first data extent starting in this block.”, paragraph 0048); and
beginning from the start offset of the first record in the sector, reading an amount of data equal to the record size if the record to be obtained is the first record (“Per-extent there is a unique identifier (extent ID) and a length indication. … . The length field allows for arbitrary sized extents, such as might be expected with compression”, paragraph 0049; “The block address of the first extent is added with the cumulative lengths of the prior extents to determine the full block address of an extent during segment processing.”, paragraph 0054).
In regards to claim 19, Sterns further teaches that obtaining the record to be obtained from the sector comprises:
obtaining metadata from the sector of the storage device (“After having read the contents of the block, the processes may then parse the in-line descriptors to find the location of the first byte of the particular data extent.”), the metadata including the start offset of the first record stored in the sector (“The Initial Offset field determines the boundary between a data extent continued from the prior storage block and the first data extent starting in this block.”, paragraph 0048);
obtaining one or more record headers before the record header corresponding to the record to be obtained (“Per-extent there is a unique identifier (extent ID) and a length indication. … . The length field allows for arbitrary sized extents, such as might be expected with compression”, paragraph 0049);
calculating a start offset of the record to be obtained in the sector based on a sum of the start offset of the first record and respective one or more record sizes included in the one or more record headers (“The block address of the first extent is added with the cumulative lengths of the prior extents to determine the full block address of an extent during segment processing.”, paragraph 0054); and
beginning from the start offset of the record to be obtained in the sector, reading an amount of data equal to the record size included in the record header corresponding to the record to be obtained (“Per-extent there is a unique identifier (extent ID) and a length indication. … . The length field allows for arbitrary sized extents, such as might be expected with compression”, paragraph 0049; “The block address of the first extent is added with the cumulative lengths of the prior extents to determine the full block address of an extent during segment processing.”, paragraph 0054).
In regards to claim 20, Stearns further teaches that selecting the record header corresponding to the record to be obtained from the plurality of consecutive record headers comprises finding the record header corresponding to the record to be obtained from the plurality of consecutive record headers based on identifying information of the record to be obtained (“Per-extent there is a unique identifier (extent ID) and a length indication. The extent ID does not have to be the full identifier, but should be enough of the identifier to properly identify the extent within the block.”, paragraph 0049; “The block address of the first extent is added with the cumulative lengths of the prior extents to determine the full block address of an extent during segment processing.”, paragraph 0054).
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Stearns et al. (US 2017/0308303) in view of Challenger et al. (US 6,643,754), Jang et al. (US 2019/0332283), and Barrus (US 2015/0106579).
In regards to claim 15, Stearns in view of Challenger and Jang teaches claim 13. Stearns in view of Challenger and Jang fails to teach the acts further comprising:
receiving padding data from the storage engine; and
storing the padding data after the additional one or more records in the sector that immediately follows the sector storing the plurality of records.
Barrus teaches the acts further comprising:
receiving padding data from the storage engine (“If the data objects 310 do not fill all the space of the data field 220, the session 200 may comprise an alignment padding zone 330 at the end of data field 220 to occupy space between the data objects 310 and a natural alignment boundary.”, paragraph 0046); and
storing the padding data after the additional one or more records in the sector that immediately follows the sector storing the plurality of records (“If the data objects 310 do not fill all the space of the data field 220, the session 200 may comprise an alignment padding zone 330 at the end of data field 220 to occupy space between the data objects 310 and a natural alignment boundary.”, paragraph 0046)
in order to occupy space to a natural alignment boundary (id.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stearns with Challenger, Jang, and Barrus to include the acts further comprising:
receiving padding data from the storage engine; and
storing the padding data after the additional one or more records in the sector that immediately follows the sector storing the plurality of records
in order to occupy space to a natural alignment boundary (id.).
Response to Arguments
Applicant's arguments filed 14 November 2025 have been fully considered but they are not persuasive.
Applicant continues to fail to comply with PCT Rule 4.11(a). Applicant needs to decide that this application is either a United States national stage of international application PCT/CN2021/075779 under 35 U.S.C. 371 or a continuation of international application PCT/CN2021/075779. It cannot be both.
In regards to the arguments regarding Sterns, Sterns teaches “Storage block 402 includes an in-line descriptor, and when read from left to right, the in-line descriptor is configured as a footer (rather than a header). However, the scope of embodiments includes configuring in-line descriptors as either headers or footers as appropriate.” (paragraph 0039). Thus, Sterns is not limited to the footer embodiment shown in figure 3 but also includes purely header embodiments as explained in paragraph 0039. Since Sterns envisions both embodiments, one of ordinary skill would be motivated to make the obviousness combinations to teach the claims.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NATHAN SADLER whose telephone number is (571)270-7699. The examiner can normally be reached Monday - Friday 8am - 5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Reginald Bragdon can be reached at (571)272-4204. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Nathan Sadler/Primary Examiner, Art Unit 2139 6 March 2026