CTFR 17/703,245 CTFR 98896 DETAILED ACTION This Action is responsive to the Amendments filed on 03/10/2026. Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Claim Status Claims 1-2, 4-11, 13-18, and 20-25 are amended. Claims 26 and 27 are newly presented. Claims 1-2, 4-11, 13-18, and 20-27 are pending and have been examined. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-23-aia AIA 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. 07-21-aia AIA Claim s 1-2, 8-11, 17-18, 23, and 27 are rejected under 35 U.S.C. 103 as being unpatentable over Kirkpatrick et al. (US 20200073559 A1)(cited by examiner in previous action)(hereafter referred to as Kirkpatrick ) further in view of Jain (US 20190114255 A1)(cited by examiner in previous action)(hereafter referred to as Jain ) . Regarding Claim 1, Kirkpatrick discloses the following limitations: A device, comprising: interface circuitry (Communications Resources 310, Fig. 3B) to communicate with a plurality of storage devices (Storage Drives 171A-171E, Fig. 4)(“The communications resources 310 … facilitate data communications between components within the storage systems as well as computing devices that are outside of the storage system.” [0118]) ; and processing circuitry (“processing logic” [0139]) to: receive (Fig. 6, block 604) a request to write a data object (“data from a plurality of sources” [0140] // Compressed Data 504, Fig. 5) to a storage system (System 400, Fig. 4)(“At block 604, processing logic receives data from a plurality of sources. In one embodiment, the data may be associated with processing a dataset and the dataset may include multiple file systems and associated metadata” [0140]) , wherein the data object comprises a set (“cblocks” [0136] // Subsets 506-510, Fig. 5) of data elements (“processing logic may write the received data in subsets (e.g., cblocks) 506, 508, 510.” [0136] // Fig. 5) – As shown in Fig. 5 and detailed in ¶0136, received data is comprised of plural data subsets (“cblocks”)-- , and wherein the storage system is organized into blocks (“segments” [0125]) and shards (“allocation units” [0125]) , wherein the blocks are organized into subblocks (“shards” [0129])(Fig. 4 // “Write groups may be RAID-protect and write the data in segments (e.g., SEGIO 407) that consists of allocation units (e.g., allocation units 404A, 404E)” [0125] // “In one embodiment, storage controllers may designate an AU in a segment as a column of, for example, 1-megabyte shards (e.g., shards 402A-E)” [0129] // ¶¶0125-133) – As shown in Fig. 4 and detailed in ¶¶0125-133, several units of data (e.g., “segments”; see SEGIO 407, “allocation units”; see Allocation Unit 404A, and “shards”; see Shard 402A) are employed by a storage system in order to distribute data across a plurality of storage drives. As additionally shown in Fig. 4 and detailed in ¶0129, segments are comprised of shards. Examiner accordingly considers the segments and allocation units of Kirkpatrick Fig. 4 as reading on the claimed concept of “ blocks ” and “ shards ”, respectively, because each corresponds to a distinct unit of data organization in a storage system. Examiner additionally notes that the segments of Kirkpatrick Fig. 4 are comprised of shards. Examiner accordingly considers the concept of a shard as taught in Kirkpatrick as reading on the claimed concept of a “ subblock ” as recited in Claim 1.-- , wherein the shards (Kirkpatrick, “allocation units”) comprise corresponding subblocks (Kirkpatrick, “shards”) from different blocks (Kirkpatrick, “segments”)(Fig. 4 // “ Corresponding shards in each of a segment’s AUs may collectively be called a SEGIO (e.g., SEGIO 407” [0129]) – As shown in Fig. 4 and detailed in ¶0129, allocation units are comprised of corresponding shards (e.g., Shards 402A and 403A) from different segments (e.g., Segments 407 and 405)-- , and wherein the blocks, the subblocks, and the shards are distributed across the plurality of storage devices (Storage Drives 171A-E, Fig. 4 // “Write groups may RAID-protect data in segments … located on a subset of the storage drives 171A-E within a write group” [0125]) – As shown in Fig. 4, segments, allocation units, and shards are each distributed across Storage Drives 171A-E-- ; determine (Fig. 6, blocks 606 + 608) a storage layout for the data object (“At block 606, processing logic determines a plurality of subsets of the data such that each subset is capable of being written in parallel … At block 608, processing logic maps each subset of the plurality of subsets to an available allocation unit” [0141] // Fig. 5) – As detailed in ¶0141, received data is divided into subsets (“cblocks”; see ¶0136) (block 606) which are subsequently mapped (block 608) to particular allocation units in memory (see also Fig. 5) . In this case, examiner considers the process of dividing a dataset (e.g., Compressed Data 504 of Fig. 5) into a set of cblocks and mapping each cblock to an allocation unit as “ determin[ing] a storage layout ” for received data-- , wherein the storage layout arranges the set of data elements across a set of blocks, subblocks, and shards (Figs. 4 - 6) – As discussed above, during step 610, cblocks (i.e., “ the set of data elements ”) are mapped to respective allocation units (i.e., are “ arrang[ed] across a set of … shards ”). As discussed above and shown in Fig. 4, allocation units are comprised both of segments and shards. One of ordinary skill in the art would accordingly understand that assigning and writing subsets of data to respective allocation units would effectively place a subset in each of a respective allocation unit, a respective segment, and a respective shard (e.g., data located within Shard 402A of Storage Drive 171A is placed in a respective shard (402A); segment (407), and allocation unit (404A); i.e., “ arrang[ed] across as set of blocks, subblocks, and shards ”) , and wherein the storage layout … to align individual data elements of the set of data elements within block, subblock, and shard boundaries (“The controllers may manage the SSD’s LBA space in blocks of logically contiguous LBAs called allocation units (AUs) … Storage controllers may align AUs with SSDs’ internal storage organization to optimize performance and minimize wear … A segment may consist of several AUs, each on a different SSD … An AU in a segment may be located on any AU boundary in its SSD’s LBA space ” [0126-127] // “storage controllers designate a shard as a column of logical pages that align with SSD flash pages ” [0130]) – As taught in ¶0126, storage controllers designate allocation units (i.e., “ shards ”) such that the allocation units align to “internal storage organization” of an underlying SSD. In this context, the internal storage organization of the SSD effectively establish boundaries for AUs (i.e., “ shard boundaries” ). As clarified in ¶0127, segments (i.e., “ blocks ”) are comprised of individual AUs, each of which are located on “any AU boundary in its SSD’s LBA space”. In this context, examiner considers the collective AU boundaries which form a segment as “ block … boundaries ”. Finally, as detailed in ¶0130, storage controllers designate shards (i.e., “ subblocks ”) in order to align with “SSD flash pages”. In this context, the size SSD flash pages effectively establish boundaries for shards (i.e., “ subblock … boundaries ”). One of ordinary skill in the art would accordingly understand the data organized into cblocks and assigned to AUs of Fig. 6 would be aligned within AU boundaries in an SSD LBA space (due to storage controller AU designation described in ¶¶0126-127) and would additionally be aligned within SSD flash page boundaries (due to storage controller shard designation described in ¶0130) (i.e., the cblocks are “ align[ed] ” “ within block, subblock, and shard boundaries ”)-- ; and write (Fig. 6, block 610) , via the interface circuitry (¶¶0104; 0114; 0118; 0140) , the data object to the storage system based on the storage layout (“at block 610, processing logic writes the plurality of subsets to the plurality of allocation units in parallel.” [0141]) – As shown in Fig. 6, after determining respective subsets and assigning allocation units for the subsets, the received data is subsequently written to the assigned allocation units. One of ordinary skill in the art would understand that such writing of data to an allocation unit in a storage device would take place using the communication resources 310 of Fig. 3B, which as previously discussed facilitates data communication between components of the storage system. Although Kirkpatrick ¶0137 discloses that allocation units (i.e., to which cblocks are assigned during block 608 of Fig. 6) are “fill[ed] with subsets” prior to being written to storage drives (i.e., during block 610), Kirkpatrick is silent regarding a particular method employed in order to fill an allocation unit with data. Specifically, Kirkpatrick is silent regarding the following limitations: the storage layout is padded to align individual data elements of the set of data elements within block, subblock, and shard boundaries However, Jain discloses the following limitations: the storage layout is padded (Fig. 7, step 706) to align individual data elements of the set of data elements within block, subblock, and shard boundaries (“If it is instead determined at step 704 that the initial LBA is not aligned within an FMU boundary, then at step 706 the data is pre-padded (e.g., with dummy data)” [0073] // “a flash management unit (“FMU”) is a smallest data chunk that the host 102 can use to … write to the non-volatile memory 124” [0025] // Figs. 5 + 6) – As shown in Jain Figs. 5 + 6 and taught in ¶0025, data chunks (i.e. 1 st and 2 nd data of Fig. 6) are written into non-volatile memory in units of an “FMU”, similar to how data is written into the storage system of Kirkpatrick Fig. 4 only after an allocation unit fills with data (see Kirkpatrick ¶0137) . Examiner accordingly considers the concept of an “FMU” as taught in Jain as analogous to the concept of an “allocation unit” as taught in Kirkpatrick because both correspond to an amount of data written at once into non-volatile memory. In this case, examiner considers the FMU boundaries shown in Jain Fig. 5 as analogous to the AU boundaries in an SSD’s LBA space as taught in Kirkpatrick ¶¶0126-127 (i.e., “ block ” and “ shard boundaries ”). In addition, as shown in Jain Fig. 6, write data can be comprised of individual portions (i.e., 1 st data and 2 nd data), which is analogous to how data written into the storage system of Kirkpatrick is comprised of individual “cblocks”. As taught in Jain ¶0025, a single FMU can be sized according to a single page of flash memory. In such an embodiment, an FMU boundary would additionally correspond to page boundaries (i.e., analogous to “SSD flash pages” as disclosed in Kirkpatrick ¶0130; i.e., additionally analogous to “ subblock boundaries ”). As disclosed in Jain ¶0073 and Fig. 7, data is first “pre-padded” to fill an entire FMU with data (i.e., “ padded to align ” the data “ within ” FMU boundaries). Kirkpatrick and Jain are considered analogous to the claimed invention because they all relate to the same field of formatting and aligning data prior to non-volatile storage. 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 Kirkpatrick with the teachings of Jain and realize a device which uses data padding to align data within local memory unit boundaries. Doing so is a conventional solution to a common problem addressed which requires unaligned write data be made compatible with storage in non-volatile memory, as disclosed in Jain ¶¶0002-03: “An FMU is the minimal addressable logical unit of memory that can be addressed. Since a partial FMU cannot be written to, data that a host wants to store in the non-volatile memory may sometimes need to be pre-padded and/or post-padded before the data is stored in the non-volatile memory … When the initial LBA is unaligned with a boundary of one of the FMUs, then the controller of the storage device may need to pre-pad the data (e.g., with dummy data) before the data to be written in response to the write command is stored within the non-volatile memory of the storage device.” [0002-03] Regarding Claim 2, The same motivation to combine provided in Claim 1 is equally applicable to Claim 2. The combined teachings of Kirkpatrick and Jain disclose the following limitations: The device of Claim 1, wherein the set of blocks, subblocks, and shards comprises one or more blocks, a plurality of subblocks, and a plurality of shards. (Kirkpatrick, Fig. 4 // ¶¶0125-131) – As shown in Kirkpatrick Fig. 4, data is organized across plural segments (e.g., SEGIO 407 + Segment 405), plural shards (e.g., Shards 402 and 403), and plural allocation units (e.g., Allocation Units 404A-404E). Regarding Claim 8, The same motivation to combine provided in Claim 1 is equally applicable to Claim 8. The combined teachings of Kirkpatrick and Jain disclose the following limitations: The device of Claim 1, wherein the storage layout further arranges the data object into a plurality of parts, wherein each part comprises a different subset of the set of data elements. (Kirkpatrick, “At block 606, processing logic determines a plurality of subsets … in one embodiment, the plurality of subsets may be serially written in the case where processing logic fills a first allocation unit before writing the next allocation unit” [0141] // Jain, 1 st + 2 nd data, Fig. 6) – As discussed in Kirkpatrick ¶0141, formatted data can be serially written to memory in units of full allocation units. As clarified in Jain Fig. 6, streams of data are divided are received as district units of data (see, e.g., 1 st and 2 nd data; i.e., “ parts ”) based on what order in the data stream they are received. One of ordinary skill in the art would understand that each portion of a data stream (i.e., written serially to memory and effectively divided temporally into parts) would comprise different data. Regarding Claim 9, The same motivation to combine provided in Claim 1 is equally applicable to Claim 9. The combined teachings of Kirkpatrick and Jain disclose the following limitations: The device of Claim 1, wherein the device is: a data storage server (Kirkpatrick, “System 100 includes a number of computing devices 164. Computing devices (also referred to as “client devices” herein) may be for example, a server in a data center , … or the like” [0024]) ; an edge data storage appliance; or (see MPEP 2140.03) an edge cloud server Regarding Claim 27, The same motivation to combine provided in Claim 1 is equally applicable to Claim 27. The combined teachings of Kirkpatrick and Jain disclose the following limitations: The device of Claim 1, wherein the set of data elements comprises a plurality of logical data elements (Kirkpatrick, “cblocks” [0136]) , wherein the logical data elements are independently processable units of the data object. (Kirkpatrick, “processing logic may write received data in subsets (e.g., cblocks) 506, 508, 510. Subsets may be subject to 3D RAID such that they are recoverable, while continuing to write the next subset. To increase throughput, more than one subset may be written in parallel with other subsets.” [0136] // Fig. 5) – As taught in Kirkpatrick , compressed data 504 (i.e., “ the set of data elements ”) is comprised of “cblocks” which are individually recoverable and which may be written in parallel with other cblocks (i.e., cblocks are “ independently processable ”)--. Regarding Claim 10, Kirkpatrick discloses the following limitations: At least one non-transitory machine-readable storage medium (¶0039) having instructions (¶0039) stored thereon, wherein the instructions, when executed on processing circuitry, cause the processing circuitry to (¶0039) : receive (Fig. 6, block 604) a request to write a data object (“data from a plurality of sources” [0140] // Compressed Data 504, Fig. 5) to a storage system (System 400, Fig. 4)(“At block 604, processing logic receives data from a plurality of sources. In one embodiment, the data may be associated with processing a dataset and the dataset may include multiple file systems and associated metadata” [0140]) , wherein the data object comprises a set (“cblocks” [0136] // Subsets 506-510, Fig. 5) of data elements (“processing logic may write the received data in subsets (e.g., cblocks) 506, 508, 510.” [0136] // Fig. 5) – As shown in Fig. 5 and detailed in ¶0136, received data is comprised of plural data subsets (“cblocks”)-- , and wherein the storage system is organized into blocks (“segments” [0125]) and shards (“allocation units” [0125]) , wherein the blocks are organized into subblocks (“shards” [0129])(Fig. 4 // “Write groups may be RAID-protect and write the data in segments (e.g., SEGIO 407) that consists of allocation units (e.g., allocation units 404A, 404E)” [0125] // “In one embodiment, storage controllers may designate an AU in a segment as a column of, for example, 1-megabyte shards (e.g., shards 402A-E)” [0129] // ¶¶0125-133) – As shown in Fig. 4 and detailed in ¶¶0125-133, several units of data (e.g., “segments”; see SEGIO 407, “allocation units”; see Allocation Unit 404A, and “shards”; see Shard 402A) are employed by a storage system in order to distribute data across a plurality of storage drives. As additionally shown in Fig. 4 and detailed in ¶0129, segments are comprised of shards. Examiner accordingly considers the segments and allocation units of Kirkpatrick Fig. 4 as reading on the claimed concept of “ blocks ” and “ shards ”, respectively, because each corresponds to a distinct unit of data organization in a storage system. Examiner additionally notes that the segments of Kirkpatrick Fig. 4 are comprised of shards. Examiner accordingly considers the concept of a shard as taught in Kirkpatrick as reading on the claimed concept of a “ subblock ” as recited in Claim 10.-- , wherein the shards (Kirkpatrick, “allocation units”) comprise corresponding subblocks (Kirkpatrick, “shards”) from different blocks (Kirkpatrick, “segments”)(Fig. 4 // “ Corresponding shards in each of a segment’s AUs may collectively be called a SEGIO (e.g., SEGIO 407” [0129]) – As shown in Fig. 4 and detailed in ¶0129, allocation units are comprised of corresponding shards (e.g., Shards 402A and 403A) from different segments (e.g., Segments 407 and 405)-- , and wherein the blocks, the subblocks, and the shards are distributed across a plurality of storage devices (Storage Drives 171A-E, Fig. 4 // “Write groups may RAID-protect data in segments … located on a subset of the storage drives 171A-E within a write group” [0125]) – As shown in Fig. 4, segments, allocation units, and shards are each distributed across Storage Drives 171A-E-- ; determine (Fig. 6, blocks 606 + 608) a storage layout for the data object (“At block 606, processing logic determines a plurality of subsets of the data such that each subset is capable of being written in parallel … At block 608, processing logic maps each subset of the plurality of subsets to an available allocation unit” [0141] // Fig. 5) – As detailed in ¶0141, received data is divided into subsets (“cblocks”; see ¶0136) (block 606) which are subsequently mapped (block 608) to particular allocation units in memory (see also Fig. 5) . In this case, examiner considers the process of dividing a dataset (e.g., Compressed Data 504 of Fig. 5) into a set of cblocks and mapping each cblock to an allocation unit as “ determin[ing] a storage layout ” for received data-- , wherein the storage layout arranges the set of data elements across a set of blocks, subblocks, and shards (Figs. 4 - 6) – As discussed above, during step 610, cblocks (i.e., “ the set of data elements ”) are mapped to respective allocation units (i.e., are “ arrang[ed] across a set of … shards ”). As discussed above and shown in Fig. 4, allocation units are comprised both of segments and shards. One of ordinary skill in the art would accordingly understand that assigning and writing subsets of data to respective allocation units would effectively place a subset in each of a respective allocation unit, a respective segment, and a respective shard (e.g., data located within Shard 402A of Storage Drive 171A is placed in a respective shard (402A); segment (407), and allocation unit (404A); i.e., “ arrang[ed] across as set of blocks, subblocks, and shards ”) , and wherein the storage layout … to align individual data elements of the set of data elements within block, subblock, and shard boundaries (“The controllers may manage the SSD’s LBA space in blocks of logically contiguous LBAs called allocation units (AUs) … Storage controllers may align AUs with SSDs’ internal storage organization to optimize performance and minimize wear … A segment may consist of several AUs, each on a different SSD … An AU in a segment may be located on any AU boundary in its SSD’s LBA space ” [0126-127] // “storage controllers designate a shard as a column of logical pages that align with SSD flash pages ” [0130]) – As taught in ¶0126, storage controllers designate allocation units (i.e., “ shards ”) such that the allocation units align to “internal storage organization” of an underlying SSD. In this context, the internal storage organization of the SSD effectively establish boundaries for AUs (i.e., “ shard boundaries” ). As clarified in ¶0127, segments (i.e., “ blocks ”) are comprised of individual AUs, each of which are located on “any AU boundary in its SSD’s LBA space”. In this context, examiner considers the collective AU boundaries which form a segment as “ block … boundaries ”. Finally, as detailed in ¶0130, storage controllers designate shards (i.e., “ subblocks ”) in order to align with “SSD flash pages”. In this context, the size SSD flash pages effectively establish boundaries for shards (i.e., “ subblock … boundaries ”). One of ordinary skill in the art would accordingly understand the data organized into cblocks and assigned to AUs of Fig. 6 would be aligned within AU boundaries in an SSD LBA space (due to storage controller AU designation described in ¶¶0126-127) and would additionally be aligned within SSD flash page boundaries (due to storage controller shard designation described in ¶0130) (i.e., the cblocks are “ align[ed] ” “ within block, subblock, and shard boundaries ”)-- ; and write (Fig. 6, block 610) the data object to the storage system based on the storage layout (“at block 610, processing logic writes the plurality of subsets to the plurality of allocation units in parallel.” [0141]) – As shown in Fig. 6, after determining respective subsets and assigning allocation units for the subsets, the received data is subsequently written to the assigned allocation units. One of ordinary skill in the art would understand that such writing of data to an allocation unit in a storage device would take place using the communication resources 310 of Fig. 3B, which as previously discussed facilitates data communication between components of the storage system. Although Kirkpatrick ¶0137 discloses that allocation units (i.e., to which cblocks are assigned during block 608 of Fig. 6) are “fill[ed] with subsets” prior to being written to storage drives (i.e., during block 610), Kirkpatrick is silent regarding a particular method employed in order to fill an allocation unit with data. Specifically, Kirkpatrick is silent regarding the following limitations: the storage layout is padded to align individual data elements of the set of data elements within block, subblock, and shard boundaries However, Jain discloses the following limitations: the storage layout is padded (Fig. 7, step 706) to align individual data elements of the set of data elements within block, subblock, and shard boundaries (“If it is instead determined at step 704 that the initial LBA is not aligned within an FMU boundary, then at step 706 the data is pre-padded (e.g., with dummy data)” [0073] // “a flash management unit (“FMU”) is a smallest data chunk that the host 102 can use to … write to the non-volatile memory 124” [0025] // Figs. 5 + 6) – As shown in Jain Figs. 5 + 6 and taught in ¶0025, data chunks (i.e. 1 st and 2 nd data of Fig. 6) are written into non-volatile memory in units of an “FMU”, similar to how data is written into the storage system of Kirkpatrick Fig. 4 only after an allocation unit fills with data (see Kirkpatrick ¶0137) . Examiner accordingly considers the concept of an “FMU” as taught in Jain as analogous to the concept of an “allocation unit” as taught in Kirkpatrick because both correspond to an amount of data written at once into non-volatile memory. In this case, examiner considers the FMU boundaries shown in Jain Fig. 5 as analogous to the AU boundaries in an SSD’s LBA space as taught in Kirkpatrick ¶¶0126-127 (i.e., “ block ” and “ shard boundaries ”). In addition, as shown in Jain Fig. 6, write data can be comprised of individual portions (i.e., 1 st data and 2 nd data), which is analogous to how data written into the storage system of Kirkpatrick is comprised of individual “cblocks”. As taught in Jain ¶0025, a single FMU can be sized according to a single page of flash memory. In such an embodiment, an FMU boundary would additionally correspond to page boundaries (i.e., analogous to “SSD flash pages” as disclosed in Kirkpatrick ¶0130; i.e., additionally analogous to “ subblock boundaries ”). As disclosed in Jain ¶0073 and Fig. 7, data is first “pre-padded” to fill an entire FMU with data (i.e., “ padded to align ” the data “ within ” FMU boundaries). Kirkpatrick and Jain are considered analogous to the claimed invention because they all relate to the same field of formatting and aligning data prior to non-volatile storage. 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 Kirkpatrick with the teachings of Jain and realize a device which uses data padding to align data within local memory unit boundaries. Doing so is a conventional solution to a common problem addressed which requires unaligned write data be made compatible with storage in non-volatile memory, as disclosed in Jain ¶¶0002-03: “An FMU is the minimal addressable logical unit of memory that can be addressed. Since a partial FMU cannot be written to, data that a host wants to store in the non-volatile memory may sometimes need to be pre-padded and/or post-padded before the data is stored in the non-volatile memory … When the initial LBA is unaligned with a boundary of one of the FMUs, then the controller of the storage device may need to pre-pad the data (e.g., with dummy data) before the data to be written in response to the write command is stored within the non-volatile memory of the storage device.” [0002-03] Regarding Claim 11, The same motivation to combine provided in Claim 10 is equally applicable to Claim 11. The combined teachings of Kirkpatrick and Jain disclose the following limitations: The storage medium of Claim 10, wherein the set of blocks, subblocks, and shards comprises one or more blocks, a plurality of subblocks, and a plurality of shards. (Kirkpatrick, Fig. 4 // ¶¶0125-131) – As shown in Kirkpatrick Fig. 4, data is organized across plural segments (e.g., SEGIO 407 + Segment 405), plural shards (e.g., Shards 402 and 403), and plural allocation units (e.g., Allocation Units 404A-404E). Regarding Claim 17, The same motivation to combine provided in Claim 10 is equally applicable to Claim 17. The combined teachings of Kirkpatrick and Jain disclose the following limitations: The storage medium of Claim 10, wherein the storage layout further arranges the data object into a plurality of parts, wherein each part comprises a different subset of the set of data elements. (Kirkpatrick, “At block 606, processing logic determines a plurality of subsets … in one embodiment, the plurality of subsets may be serially written in the case where processing logic fills a first allocation unit before writing the next allocation unit” [0141] // Jain, 1 st + 2 nd data, Fig. 6) – As discussed in Kirkpatrick ¶0141, formatted data can be serially written to memory in units of full allocation units. As clarified in Jain Fig. 6, streams of data are divided are received as district units of data (see, e.g., 1 st and 2 nd data; i.e., “ parts ”) based on what order in the data stream they are received. One of ordinary skill in the art would understand that each portion of a data stream (i.e., written serially to memory and effectively divided temporally into parts) would comprise different data. Regarding Claim 18, A method, comprising: receiving (Fig. 6, block 604) a request to write a data object (“data from a plurality of sources” [0140] // Compressed Data 504, Fig. 5) to a storage system (System 400, Fig. 4)(“At block 604, processing logic receives data from a plurality of sources. In one embodiment, the data may be associated with processing a dataset and the dataset may include multiple file systems and associated metadata” [0140]) , wherein the data object comprises a set (“cblocks” [0136] // Subsets 506-510, Fig. 5) of data elements (“processing logic may write the received data in subsets (e.g., cblocks) 506, 508, 510.” [0136] // Fig. 5) – As shown in Fig. 5 and detailed in ¶0136, received data is comprised of plural data subsets (“cblocks”)-- , and wherein the storage system is organized into blocks (“segments” [0125]) and shards (“allocation units” [0125]) , wherein the blocks are organized into subblocks (“shards” [0129])(Fig. 4 // “Write groups may be RAID-protect and write the data in segments (e.g., SEGIO 407) that consists of allocation units (e.g., allocation units 404A, 404E)” [0125] // “In one embodiment, storage controllers may designate an AU in a segment as a column of, for example, 1-megabyte shards (e.g., shards 402A-E)” [0129] // ¶¶0125-133) – As shown in Fig. 4 and detailed in ¶¶0125-133, several units of data (e.g., “segments”; see SEGIO 407, “allocation units”; see Allocation Unit 404A, and “shards”; see Shard 402A) are employed by a storage system in order to distribute data across a plurality of storage drives. As additionally shown in Fig. 4 and detailed in ¶0129, segments are comprised of shards. Examiner accordingly considers the segments and allocation units of Kirkpatrick Fig. 4 as reading on the claimed concept of “ blocks ” and “ shards ”, respectively, because each corresponds to a distinct unit of data organization in a storage system. Examiner additionally notes that the segments of Kirkpatrick Fig. 4 are comprised of shards. Examiner accordingly considers the concept of a shard as taught in Kirkpatrick as reading on the claimed concept of a “ subblock ” as recited in Claim 18.-- , wherein the shards (Kirkpatrick, “allocation units”) comprise corresponding subblocks (Kirkpatrick, “shards”) from different blocks (Kirkpatrick, “segments”)(Fig. 4 // “ Corresponding shards in each of a segment’s AUs may collectively be called a SEGIO (e.g., SEGIO 407” [0129]) – As shown in Fig. 4 and detailed in ¶0129, allocation units are comprised of corresponding shards (e.g., Shards 402A and 403A) from different segments (e.g., Segments 407 and 405)-- , and wherein the blocks, the subblocks, and the shards are distributed across the plurality of storage devices (Storage Drives 171A-E, Fig. 4 // “Write groups may RAID-protect data in segments … located on a subset of the storage drives 171A-E within a write group” [0125]) – As shown in Fig. 4, segments, allocation units, and shards are each distributed across Storage Drives 171A-E-- ; determining (Fig. 6, blocks 606 + 608) a storage layout for the data object (“At block 606, processing logic determines a plurality of subsets of the data such that each subset is capable of being written in parallel … At block 608, processing logic maps each subset of the plurality of subsets to an available allocation unit” [0141] // Fig. 5) – As detailed in ¶0141, received data is divided into subsets (“cblocks”; see ¶0136) (block 606) which are subsequently mapped (block 608) to particular allocation units in memory (see also Fig. 5) . In this case, examiner considers the process of dividing a dataset (e.g., Compressed Data 504 of Fig. 5) into a set of cblocks and mapping each cblock to an allocation unit as “ determin[ing] a storage layout ” for received data-- , wherein the storage layout arranges the set of data elements across a set of blocks, subblocks, and shards (Figs. 4 - 6) – As discussed above, during step 610, cblocks (i.e., “ the set of data elements ”) are mapped to respective allocation units (i.e., are “ arrang[ed] across a set of … shards ”). As discussed above and shown in Fig. 4, allocation units are comprised both of segments and shards. One of ordinary skill in the art would accordingly understand that assigning and writing subsets of data to respective allocation units would effectively place a subset in each of a respective allocation unit, a respective segment, and a respective shard (e.g., data located within Shard 402A of Storage Drive 171A is placed in a respective shard (402A); segment (407), and allocation unit (404A); i.e., “ arrang[ed] across as set of blocks, subblocks, and shards ”) , and wherein the storage layout … to align individual data elements of the set of data elements within block, subblock, and shard boundaries (“The controllers may manage the SSD’s LBA space in blocks of logically contiguous LBAs called allocation units (AUs) … Storage controllers may align AUs with SSDs’ internal storage organization to optimize performance and minimize wear … A segment may consist of several AUs, each on a different SSD … An AU in a segment may be located on any AU boundary in its SSD’s LBA space ” [0126-127] // “storage controllers designate a shard as a column of logical pages that align with SSD flash pages ” [0130] // ) – As taught in ¶0126, storage controllers designate allocation units (i.e., “ shards ”) such that the allocation units align to “internal storage organization” of an underlying SSD. In this context, the internal storage organization of the SSD effectively establish boundaries for AUs (i.e., “ shard boundaries” ). As clarified in ¶0127, segments (i.e., “ blocks ”) are comprised of individual AUs, each of which are located on “any AU boundary in its SSD’s LBA space”. In this context, examiner considers the collective AU boundaries which form a segment as “ block … boundaries ”. Finally, as detailed in ¶0130, storage controllers designate shards (i.e., “ subblocks ”) in order to align with “SSD flash pages”. In this context, the size SSD flash pages effectively establish boundaries for shards (i.e., “ subblock … boundaries ”). One of ordinary skill in the art would accordingly understand the data organized into cblocks and assigned to AUs of Fig. 6 would be aligned within AU boundaries in an SSD LBA space (due to storage controller AU designation described in ¶¶0126-127) and would additionally be aligned within SSD flash page boundaries (due to storage controller shard designation described in ¶0130) (i.e., the cblocks are “ align[ed] ” “ within block, subblock, and shard boundaries ”)-- ; and writing (Fig. 6, block 610) the data object to the storage system based on the storage layout (“at block 610, processing logic writes the plurality of subsets to the plurality of allocation units in parallel.” [0141]) – As shown in Fig. 6, after determining respective subsets and assigning allocation units for the subsets, the received data is subsequently written to the assigned allocation units. One of ordinary skill in the art would understand that such writing of data to an allocation unit in a storage device would take place using the communication resources 310 of Fig. 3B, which as previously discussed facilitates data communication between components of the storage system. Although Kirkpatrick ¶0137 discloses that allocation units (i.e.., to which cblocks are assigned during block 608 of Fig. 6) are “fill[ed] with subsets” prior to being written to storage drives (i.e., during block 610), Kirkpatrick is silent regarding a particular method employed in order to fill an allocation unit with data. Specifically, Kirkpatrick is silent regarding the following limitations: the storage layout is padded to align individual data elements of the set of data elements within block, subblock, and shard boundaries However, Jain discloses the following limitations: the storage layout is padded (Fig. 7, step 706) to align individual data elements of the set of data elements within block, subblock, and shard boundaries (“If it is instead determined at step 704 that the initial LBA is not aligned within an FMU boundary, then at step 706 the data is pre-padded (e.g., with dummy data)” [0073] // “a flash management unit (“FMU”) is a smallest data chunk that the host 102 can use to … write to the non-volatile memory 124” [0025] // Figs. 5 + 6) – As shown in Jain Figs. 5 + 6 and taught in ¶0025, data chunks (i.e. 1 st and 2 nd data of Fig. 6) are written into non-volatile memory in units of an “FMU”, similar to how data is written into the storage system of Kirkpatrick Fig. 4 only after an allocation unit fills with data (see Kirkpatrick ¶0137) . Examiner accordingly considers the concept of an “FMU” as taught in Jain as analogous to the concept of an “allocation unit” as taught in Kirkpatrick because both correspond to an amount of data written at once into non-volatile memory. In this case, examiner considers the FMU boundaries shown in Jain Fig. 5 as analogous to the AU boundaries in an SSD’s LBA space as taught in Kirkpatrick ¶¶0126-127 (i.e., “ block ” and “ shard boundaries ”). In addition, as shown in Jain Fig. 6, write data can be comprised of individual portions (i.e., 1 st data and 2 nd data), which is analogous to how data written into the storage system of Kirkpatrick is comprised of individual “cblocks”. As taught in Jain ¶0025, a single FMU can be sized according to a single page of flash memory. In such an embodiment, an FMU boundary would additionally correspond to page boundaries (i.e., analogous to “SSD flash pages” as disclosed in Kirkpatrick ¶0130; i.e., additionally analogous to “ subblock boundaries ”). As disclosed in Jain ¶0073 and Fig. 7, data is first “pre-padded” to fill an entire FMU with data (i.e., “ padded to align ” the data “ within ” FMU boundaries). Kirkpatrick and Jain are considered analogous to the claimed invention because they all relate to the same field of formatting and aligning data prior to non-volatile storage. 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 Kirkpatrick with the teachings of Jain and realize a device which uses data padding to align data within local memory unit boundaries. Doing so is a conventional solution to a common problem addressed which requires unaligned write data be made compatible with storage in non-volatile memory, as disclosed in Jain ¶¶0002-03: “An FMU is the minimal addressable logical unit of memory that can be addressed. Since a partial FMU cannot be written to, data that a host wants to store in the non-volatile memory may sometimes need to be pre-padded and/or post-padded before the data is stored in the non-volatile memory … When the initial LBA is unaligned with a boundary of one of the FMUs, then the controller of the storage device may need to pre-pad the data (e.g., with dummy data) before the data to be written in response to the write command is stored within the non-volatile memory of the storage device.” [0002-03] Regarding Claim 23, A system, comprising: a plurality of storage devices (Storage Drives 171A-171E, Fig. 4) ; and a data storage server (Processing Resources 312, Fig. 3B // ¶¶0110; 0119) to: receive (Fig. 6, block 604) a request to write a data object (“data from a plurality of sources” [0140] // Compressed Data 504, Fig. 5) to a storage system (System 400, Fig. 4)(“At block 604, processing logic receives data from a plurality of sources. In one embodiment, the data may be associated with processing a dataset and the dataset may include multiple file systems and associated metadata” [0140]) , wherein the data object comprises a set (“cblocks” [0136] // Subsets 506-510, Fig. 5) of data elements (“processing logic may write the received data in subsets (e.g., cblocks) 506, 508, 510.” [0136] // Fig. 5) – As shown in Fig. 5 and detailed in ¶0136, received data is comprised of plural data subsets (“cblocks”)-- , and wherein the storage system is organized into blocks (“segments” [0125]) and shards (“allocation units” [0125]) , wherein the blocks are organized into subblocks (“shards” [0129])(Fig. 4 // “Write groups may be RAID-protect and write the data in segments (e.g., SEGIO 407) that consists of allocation units (e.g., allocation units 404A, 404E)” [0125] // “In one embodiment, storage controllers may designate an AU in a segment as a column of, for example, 1-megabyte shards (e.g., shards 402A-E)” [0129] // ¶¶0125-133) – As shown in Fig. 4 and detailed in ¶¶0125-133, several units of data (e.g., “segments”; see SEGIO 407, “allocation units”; see Allocation Unit 404A, and “shards”; see Shard 402A) are employed by a storage system in order to distribute data across a plurality of storage drives. As additionally shown in Fig. 4 and detailed in ¶0129, segments are comprised of shards. Examiner accordingly considers the segments and allocation units of Kirkpatrick Fig. 4 as reading on the claimed concept of “ blocks ” and “ shards ”, respectively, because each corresponds to a distinct unit of data organization in a storage system. Examiner additionally notes that the segments of Kirkpatrick Fig. 4 are comprised of shards. Examiner accordingly considers the concept of a shard as taught in Kirkpatrick as reading on the claimed concept of a “ subblock ” as recited in Claim 23.-- , wherein the shards (Kirkpatrick, “allocation units”) comprise corresponding subblocks (Kirkpatrick, “shards”) from different blocks (Kirkpatrick, “segments”)(Fig. 4 // “ Corresponding shards in each of a segment’s AUs may collectively be called a SEGIO (e.g., SEGIO 407” [0129]) – As shown in Fig. 4 and detailed in ¶0129, allocation units are comprised of corresponding shards (e.g., Shards 402A and 403A) from different segments (e.g., Segments 407 and 405)-- , and wherein the blocks, the subblocks, and the shards are distributed across a plurality of storage devices (Storage Drives 171A-E, Fig. 4 // “Write groups may RAID-protect data in segments … located on a subset of the storage drives 171A-E within a write group” [0125]) – As shown in Fig. 4, segments, allocation units, and shards are each distributed across Storage Drives 171A-E-- ; determine (Fig. 6, blocks 606 + 608) a storage layout for the data object (“At block 606, processing logic determines a plurality of subsets of the data such that each subset is capable of being written in parallel … At block 608, processing logic maps each subset of the plurality of subsets to an available allocation unit” [0141] // Fig. 5) – As detailed in ¶0141, received data is divided into subsets (“cblocks”; see ¶0136) (block 606) which are subsequently mapped (block 608) to particular allocation units in memory (see also Fig. 5) . In this case, examiner considers the process of dividing a dataset (e.g., Compressed Data 504 of Fig. 5) into a set of cblocks and mapping each cblock to an allocation unit as “ determin[ing] a storage layout ” for received data-- , wherein the storage layout arranges the set of data elements across a set of blocks, subblocks, and shards (Figs. 4 - 6) – As discussed above, during step 610, cblocks (i.e., “ the set of data elements ”) are mapped to respective allocation units (i.e., are “ arrang[ed] across a set of … shards ”). As discussed above and shown in Fig. 4, allocation units are comprised both of segments and shards. One of ordinary skill in the art would accordingly understand that assigning and writing subsets of data to respective allocation units would effectively place a subset in each of a respective allocation unit, a respective segment, and a respective shard (e.g., data located within Shard 402A of Storage Drive 171A is placed in a respective shard (402A); segment (407), and allocation unit (404A); i.e., “ arrang[ed] across as set of blocks, subblocks, and shards ”) , and wherein the storage layout … to align individual data elements of the set of data elements within block, subblock, and shard boundaries (“The controllers may manage the SSD’s LBA space in blocks of logically contiguous LBAs called allocation units (AUs) … Storage controllers may align AUs with SSDs’ internal storage organization to optimize performance and minimize wear … A segment may consist of several AUs, each on a different SSD … An AU in a segment may be located on any AU boundary in its SSD’s LBA space ” [0126-127] // “storage controllers designate a shard as a column of logical pages that align with SSD flash pages ” [0130]) – As taught in ¶0126, storage controllers designate allocation units (i.e., “ shards ”) such that the allocation units align to “internal storage organization” of an underlying SSD. In this context, the internal storage organization of the SSD effectively establish boundaries for AUs (i.e., “ shard boundaries” ). As clarified in ¶0127, segments (i.e., “ blocks ”) are comprised of individual AUs, each of which are located on “any AU boundary in its SSD’s LBA space”. In this context, examiner considers the collective AU boundaries which form a segment as “ block … boundaries ”. Finally, as detailed in ¶0130, storage controllers designate shards (i.e., “ subblocks ”) in order to align with “SSD flash pages”. In this context, the size SSD flash pages effectively establish boundaries for shards (i.e., “ subblock … boundaries ”). One of ordinary skill in the art would accordingly understand the data organized into cblocks and assigned to AUs of Fig. 6 would be aligned within AU boundaries in an SSD LBA space (due to storage controller AU designation described in ¶¶0126-127) and would additionally be aligned within SSD flash page boundaries (due to storage controller shard designation described in ¶0130) (i.e., the cblocks are “ align[ed] ” “ within block, subblock, and shard boundaries ”)-- ; and write (Fig. 6, block 610) the data object to the storage system based on the storage layout (“at block 610, processing logic writes the plurality of subsets to the plurality of allocation units in parallel.” [0141]) – As shown in Fig. 6, after determining respective subsets and assigning allocation units for the subsets, the received data is subsequently written to the assigned allocation units. One of ordinary skill in the art would understand that such writing of data to an allocation unit in a storage device would take place using the communication resources 310 of Fig. 3B, which as previously discussed facilitates data communication between components of the storage system. Although Kirkpatrick ¶0137 discloses that allocation units (i.e., to which cblocks are assigned during block 608 of Fig. 6) are “fill[ed] with subsets” prior to being written to storage drives (i.e., during block 610), Kirkpatrick is silent regarding a particular method employed in order to fill an allocation unit with data. Specifically, Kirkpatrick is silent regarding the following limitations: the storage layout is padded to align individual data elements of the set of data elements within block, subblock, and shard boundaries However, Jain discloses the following limitations: the storage layout is padded (Fig. 7, step 706) to align individual data elements of the set of data elements within block, subblock, and shard boundaries (“If it is instead determined at step 704 that the initial LBA is not aligned within an FMU boundary, then at step 706 the data is pre-padded (e.g., with dummy data)” [0073] // “a flash management unit (“FMU”) is a smallest data chunk that the host 102 can use to … write to the non-volatile memory 124” [0025] // Figs. 5 + 6) – As shown in Jain Figs. 5 + 6 and taught in ¶0025, data chunks (i.e. 1 st and 2 nd data of Fig. 6) are written into non-volatile memory in units of an “FMU”, similar to how data is written into the storage system of Kirkpatrick Fig. 4 only after an allocation unit fills with data (see Kirkpatrick ¶0137) . Examiner accordingly considers the concept of an “FMU” as taught in Jain as analogous to the concept of an “allocation unit” as taught in Kirkpatrick because both correspond to an amount of data written at once into non-volatile memory. In this case, examiner considers the FMU boundaries shown in Jain Fig. 5 as analogous to the AU boundaries in an SSD’s LBA space as taught in Kirkpatrick ¶¶0126-127 (i.e., “ block ” and “ shard boundaries ”). In addition, as shown in Jain Fig. 6, write data can be comprised of individual portions (i.e., 1 st data and 2 nd data), which is analogous to how data written into the storage system of Kirkpatrick is comprised of individual “cblocks”. As taught in Jain ¶0025, a single FMU can be sized according to a single page of flash memory. In such an embodiment, an FMU boundary would additionally correspond to page boundaries (i.e., analogous to “SSD flash pages” as disclosed in Kirkpatrick ¶0130; i.e., additionally analogous to “ subblock boundaries ”). As disclosed in Jain ¶0073 and Fig. 7, data is first “pre-padded” to fill an entire FMU with data (i.e., “ padded to align ” the data “ within ” FMU boundaries). Kirkpatrick and Jain are considered analogous to the claimed invention because they all relate to the same field of formatting and aligning data prior to non-volatile storage. 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 Kirkpatrick with the teachings of Jain and realize a device which uses data padding to align data within local memory unit boundaries. Doing so is a conventional solution to a common problem addressed which requires unaligned write data be made compatible with storage in non-volatile memory, as disclosed in Jain ¶¶0002-03: “An FMU is the minimal addressable logical unit of memory that can be addressed. Since a partial FMU cannot be written to, data that a host wants to store in the non-volatile memory may sometimes need to be pre-padded and/or post-padded before the data is stored in the non-volatile memory … When the initial LBA is unaligned with a boundary of one of the FMUs, then the controller of the storage device may need to pre-pad the data (e.g., with dummy data) before the data to be written in response to the write command is stored within the non-volatile memory of the storage device.” [0002-03] . 07-21-aia AIA Claim s 4, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kirkpatrick further in view of Jain and Verrilli et al. (US 20210351789 A1)(hereafter referred to as Verrilli ) . Regarding Claim 4, The same motivation to combine provided in Claim 1 is equally applicable to Claim 4. The combined teachings of Kirkpatrick and Jain disclose the following limitations: The device of Claim 1 (see Claim 1 limitation mappings above) , wherein the processing circuitry to write, via the interface circuitry, the data object to the storage system based on the storage layout is further to: write metadata associated with the data object to the storage system (Kirkpatrick, “Data and metadata is stored by a set of underlying storage layouts that are optimized for varying workload patterns and storage devices.” [0081]) Although Kirkpatrick ¶0078 teaches that metadata accompanying data objects describe “attributes” of the accompanying data object, Kirkpatrick and Jain are silent regarding the following limitations: wherein the metadata indicates a location of padding within the storage layout of the data object. However, Verrilli discloses the following limitations: wherein the metadata (“map metadata” [0041]) indicates a location of padding within the storage layout of the data object (“As part of a compression operation, the compression engine may generate a map metadata 142 … the map metadata 142 may map locations of zero and non-zero words of uncompressed data block 122 ” [0041] // ¶0033) – As taught in Verrilli ¶0041, metadata (map metadata 142) associated with a data object (uncompressed data block 122) identifies the location of “zero words” (data having a value of 0 [see ¶0033]; i.e., “ a location of padding ”) with the associated data object. Kirkpatrick, Jain, and Verrilli are considered analogous to the claimed invention because they all relate to the same field of formatting data objects prior to storage in non-volatile 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 Kirkpatrick and Jain with the teachings of Verrilli and realize a device which writes metadata including a location of padding within a layout of a data object. Doing so enables decompression of compressed data blocks, thereby enabling a storage system to realize improved storage efficiency by leveraging stack compression for recurrent neural network wights, as disclosed in Verrilli [Abstract; ¶0002]: “Stack compression refers to compression of data in one or more dimensions. For uncompressed data blocks that are very sparse, i.e., data blocks that contain many zeros, stack compression can be effective. In stack compression, uncompressed data is compressed into compressed data block by removing one or more zero words from the uncompressed data. A map metadata that maps the zero words of the uncompressed data block is generated during compression. With the use of the map metadata, the compressed data block can be decompressed to restore the uncompressed data block.” [Abstract] // “In a neural network (NN), data with many zeros tend to be processed … There can also be numerous zeros if the network is pruned .For example, in pruned recurrent neural networks, close to 90% of the weights can be pruned.” [0002] Regarding Claim 13, The same motivation to combine provided in Claim 10 is equally applicable to Claim 13. The combined teachings of Kirkpatrick and Jain disclose the following limitations: The storage medium of Claim 10 (see Claim 10 limitation mappings above) , wherein the instructions that cause the processing circuitry to write the data object to the storage system based on the storage layout further cause the processing circuitry to: write metadata associated with the data object to the storage system (Kirkpatrick, “Data and metadata is stored by a set of underlying storage layouts that are optimized for varying workload patterns and storage devices.” [0081]) Although Kirkpatrick ¶0078 teaches that metadata accompanying data objects describe “attributes” of the accompanying data object, Kirkpatrick and Jain are silent regarding the following limitations: wherein the metadata indicates a location of padding within the storage layout of the data object. However, Verrilli discloses the following limitations: wherein the metadata (“map metadata” [0041]) indicates a location of padding within the storage layout of the data object (“As part of a compression operation, the compression engine may generate a map metadata 142 … the map metadata 142 may map locations of zero and non-zero words of uncompressed data block 122 ” [0041] // ¶0033) – As taught in Verrilli ¶0041, metadata (map metadata 142) associated with a data object (uncompressed data block 122) identifies the location of “zero words” (data having a value of 0 [see ¶0033]; i.e., “ a location of padding ”) with the associated data object. Kirkpatrick, Jain, and Verrilli are considered analogous to the claimed invention because they all relate to the same field of formatting data objects prior to storage in non-volatile 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 Kirkpatrick and Jain with the teachings of Verrilli and realize a device which writes metadata including a location of padding within a layout of a data object. Doing so enables decompression of compressed data blocks, thereby enabling a storage system to realize improved storage efficiency by leveraging stack compression for recurrent neural network wights, as disclosed in Verrilli [Abstract; ¶0002]: “Stack compression refers to compression of data in one or more dimensions. For uncompressed data blocks that are very sparse, i.e., data blocks that contain many zeros, stack compression can be effective. In stack compression, uncompressed data is compressed into compressed data block by removing one or more zero words from the uncompressed data. A map metadata that maps the zero words of the uncompressed data block is generated during compression. With the use of the map metadata, the compressed data block can be decompressed to restore the uncompressed data block.” [Abstract] // “In a neural network (NN), data with many zeros tend to be processed … There can also be numerous zeros if the network is pruned .For example, in pruned recurrent neural networks, close to 90% of the weights can be pruned.” [0002] Regarding Claim 20, The same motivation to combine provided in Claim 18 is equally applicable to Claim 20. The combined teachings of Kirkpatrick and Jain disclose the following limitations: The method of Claim 18 (see Claim 18 limitation mappings above) , further comprising: writing metadata associated with the data object to the storage system (Kirkpatrick, “Data and metadata is stored by a set of underlying storage layouts that are optimized for varying workload patterns and storage devices.” [0081]) Although Kirkpatrick ¶0078 teaches that metadata accompanying data objects describe “attributes” of the accompanying data object, Kirkpatrick and Jain are silent regarding the following limitations: wherein the metadata indicates a location of padding within the storage layout of the data object. However, Verrilli discloses the following limitations: wherein the metadata (“map metadata” [0041]) indicates a location of padding within the storage layout of the data object (“As part of a compression operation, the compression engine may generate a map metadata 142 … the map metadata 142 may map locations of zero and non-zero words of uncompressed data block 122 ” [0041] // ¶0033) – As taught in Verrilli ¶0041, metadata (map metadata 142) associated with a data object (uncompressed data block 122) identifies the location of “zero words” (data having a value of 0 [see ¶0033]; i.e., “ a location of padding ”) with the associated data object. Kirkpatrick, Jain, and Verrilli are considered analogous to the claimed invention because they all relate to the same field of formatting data objects prior to storage in non-volatile 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 Kirkpatrick and Jain with the teachings of Verrilli and realize a device which writes metadata including a location of padding within a layout of a data object. Doing so enables decompression of compressed data blocks, thereby enabling a storage system to realize improved storage efficiency by leveraging stack compression for recurrent neural network wights, as disclosed in Verrilli [Abstract; ¶0002]: “Stack compression refers to compression of data in one or more dimensions. For uncompressed data blocks that are very sparse, i.e., data blocks that contain many zeros, stack compression can be effective. In stack compression, uncompressed data is compressed into compressed data block by removing one or more zero words from the uncompressed data. A map metadata that maps the zero words of the uncompressed data block is generated during compression. With the use of the map metadata, the compressed data block can be decompressed to restore the uncompressed data block.” [Abstract] // “In a neural network (NN), data with many zeros tend to be processed … There can also be numerous zeros if the network is pruned .For example, in pruned recurrent neural networks, close to 90% of the weights can be pruned.” [0002] 07-21-aia AIA Claim s 5, 14, 21, and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Kirkpatrick further in view of Jain and Keating et al. (US 20220360783 A1)(cited by examiner in previous action)(hereafter referred to as Keating ) . Regarding Claim 5, The same motivation to combine provided in Claim 1 is equally applicable to Claim 5. The combined teachings of Kirkpatrick and Jain disclose the following limitations: The device of Claim 1, wherein the set of data elements (Kirkpatrick, “data from a plurality of sources” [0140] // Compressed Data 504, Fig. 5) … are aligned within the block, subblock, and shard boundaries (see Claim 1 limitation mappings above) – As previously discussed with respect to Claim 1, Kirkpatrick discloses that data received from multiple sources are formatted to align within block, subblock, and shard boundaries. Although Kirkpatrick suggests that storage systems can be applied in “picture archiving and communication systems (‘PACS’) applications”, Kirkpatrick and Jain do not explicitly disclose the following limitations: the set of data elements comprises a set of images, wherein individual images are aligned However, Keating discloses the following limitations: the set of data elements (“an output data stream” [0011]) comprises a set of images (“image data representing one or more pictures” [0008]) , wherein individual images are aligned (“to apply the constraint to each output data unit representing a slice and to each output data unit representing a tile, and to provide padding data, for each output data unit which does not meet the constraint, so as to increase the size in bytes of that output data unit in order to meet the constraint.” [0011]) – As taught in Keating ¶¶0008 and 0011; “image data” is formatted into “an output data stream” whereby each output data unit is padded to meet a constraint. See also Fig. 4 . Kirkpatrick, Jain, and Keating are considered analogous to the claimed invention because they all relate to the same field of formatting sets of data elements prior to storage in non-volatile 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 Kirkpatrick and Jain with the teachings of Keating and realize a set of data elements including image data, whereby each image is aligned within block and shard boundaries. Aligning a set of images within block and shard boundaries would enable improved efficiency in encoding/compressing the image data prior to storage, as disclosed in Keating ¶0104: “At a basic level, an image to be compressed is considered as an array of blocks or regions of sampled. The splitting of an image into such blocks and regions can be carried out by a decision tree … In some examples, the resulting blocks or regions have sizes … This in itself can allow for an improved encoding efficiently because samples representing or following similar image features would tend to be grouped together … The result of the division of the image into such blocks or regions is (in at least the present example) that each sample of an image is allocated to one, and only one, such block or region.” [0104] Regarding Claim 14, The same motivation to combine provided in Claim 10 is equally applicable to Claim 14. The combined teachings of Kirkpatrick and Jain disclose the following limitations: The storage medium of Claim 10, wherein the set of data elements (Kirkpatrick, “data from a plurality of sources” [0140] // Compressed Data 504, Fig. 5) … are aligned within the block, subblock, and shard boundaries (see Claim 10 limitation mappings above) – As previously discussed with respect to Claim 10, Kirkpatrick discloses that data received from multiple sources are formatted to align within block, subblock, and shard boundaries. Although Kirkpatrick suggests that storage systems can be applied in “picture archiving and communication systems (‘PACS’) applications”, Kirkpatrick and Jain do not explicitly disclose the following limitations: the set of data elements comprises a set of images, wherein individual images are aligned However, Keating discloses the following limitations: the set of data elements (“an output data stream” [0011]) comprises a set of images (“image data representing one or more pictures” [0008]) , wherein individual images are aligned (“to apply the constraint to each output data unit representing a slice and to each output data unit representing a tile, and to provide padding data, for each output data unit which does not meet the constraint, so as to increase the size in bytes of that output data unit in order to meet the constraint.” [0011]) – As taught in Keating ¶¶0008 and 0011; “image data” is formatted into “an output data stream” whereby each output data unit is padded to meet a constraint. See also Fig. 4 . Kirkpatrick, Jain, and Keating are considered analogous to the claimed invention because they all relate to the same field of formatting sets of data elements prior to storage in non-volatile 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 Kirkpatrick and Jain with the teachings of Keating and realize a set of data elements including image data, whereby each image is aligned within block and shard boundaries. Aligning a set of images within block and shard boundaries would enable improved efficiency in encoding/compressing the image data prior to storage, as disclosed in Keating ¶0104: “At a basic level, an image to be compressed is considered as an array of blocks or regions of sampled. The splitting of an image into such blocks and regions can be carried out by a decision tree … In some examples, the resulting blocks or regions have sizes … This in itself can allow for an improved encoding efficiently because samples representing or following similar image features would tend to be grouped together … The result of the division of the image into such blocks or regions is (in at least the present example) that each sample of an image is allocated to one, and only one, such block or region.” [0104] Regarding Claim 21, The same motivation to combine provided in Claim 18 is equally applicable to Claim 21. The combined teachings of Kirkpatrick and Jain disclose the following limitations: The method of Claim 18, wherein the set of data elements (Kirkpatrick, “data from a plurality of sources” [0140] // Compressed Data 504, Fig. 5) … are aligned within the block, subblock, and shard boundaries (see Claim 18 limitation mappings above) – As previously discussed with respect to Claim 18, Kirkpatrick discloses that data received from multiple sources are formatted to align within block, subblock, and shard boundaries. Although Kirkpatrick suggests that storage systems can be applied in “picture archiving and communication systems (‘PACS’) applications”, Kirkpatrick and Jain do not explicitly disclose the following limitations: the set of data elements comprises a set of images, wherein individual images are aligned However, Keating discloses the following limitations: the set of data elements (“an output data stream” [0011]) comprises a set of images (“image data representing one or more pictures” [0008]) , wherein individual images are aligned (“to apply the constraint to each output data unit representing a slice and to each output data unit representing a tile, and to provide padding data, for each output data unit which does not meet the constraint, so as to increase the size in bytes of that output data unit in order to meet the constraint.” [0011]) – As taught in Keating ¶¶0008 and 0011; “image data” is formatted into “an output data stream” whereby each output data unit is padded to meet a constraint. See also Fig. 4 . Kirkpatrick, Jain, and Keating are considered analogous to the claimed invention because they all relate to the same field of formatting sets of data elements prior to storage in non-volatile 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 Kirkpatrick and Jain with the teachings of Keating and realize a set of data elements including image data, whereby each image is aligned within block and shard boundaries. Aligning a set of images within block and shard boundaries would enable improved efficiency in encoding/compressing the image data prior to storage, as disclosed in Keating ¶0104: “At a basic level, an image to be compressed is considered as an array of blocks or regions of sampled. The splitting of an image into such blocks and regions can be carried out by a decision tree … In some examples, the resulting blocks or regions have sizes … This in itself can allow for an improved encoding efficiently because samples representing or following similar image features would tend to be grouped together … The result of the division of the image into such blocks or regions is (in at least the present example) that each sample of an image is allocated to one, and only one, such block or region.” [0104] Regarding Claim 24, The same motivation to combine provided in Claim 23 is equally applicable to Claim 24. The combined teachings of Kirkpatrick and Jain disclose the following limitations: The system of Claim 23, wherein the set of data elements (Kirkpatrick, “data from a plurality of sources” [0140] // Compressed Data 504, Fig. 5) … are aligned within the block, subblock, and shard boundaries (see Claim 18 limitation mappings above) – As previously discussed with respect to Claim 18, Kirkpatrick discloses that data received from multiple sources are formatted to align within block, subblock, and shard boundaries. Although Kirkpatrick suggests that storage systems can be applied in “picture archiving and communication systems (‘PACS’) applications”, Kirkpatrick and Jain do not explicitly disclose the following limitations: the set of data elements comprises a set of images, wherein individual images are aligned However, Keating discloses the following limitations: the set of data elements (“an output data stream” [0011]) comprises a set of images (“image data representing one or more pictures” [0008]) , wherein individual images are aligned (“to apply the constraint to each output data unit representing a slice and to each output data unit representing a tile, and to provide padding data, for each output data unit which does not meet the constraint, so as to increase the size in bytes of that output data unit in order to meet the constraint.” [0011]) – As taught in Keating ¶¶0008 and 0011; “image data” is formatted into “an output data stream” whereby each output data unit is padded to meet a constraint. See also Fig. 4 . Kirkpatrick, Jain, and Keating are considered analogous to the claimed invention because they all relate to the same field of formatting sets of data elements prior to storage in non-volatile 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 Kirkpatrick and Jain with the teachings of Keating and realize a set of data elements including image data, whereby each image is aligned within block and shard boundaries. Aligning a set of images within block and shard boundaries would enable improved efficiency in encoding/compressing the image data prior to storage, as disclosed in Keating ¶0104: “At a basic level, an image to be compressed is considered as an array of blocks or regions of sampled. The splitting of an image into such blocks and regions can be carried out by a decision tree … In some examples, the resulting blocks or regions have sizes … This in itself can allow for an improved encoding efficiently because samples representing or following similar image features would tend to be grouped together … The result of the division of the image into such blocks or regions is (in at least the present example) that each sample of an image is allocated to one, and only one, such block or region.” [0104] 07-21-aia AIA Claim s 6-7, 15-16, 22, and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Kirkpatrick further in view of Jain and Maeda et al. (US 20160259580 A1)(cited by examiner in previous action)(hereafter referred to as Maeda ) . Regarding Claim 6, The same motivation to combine provided in Claim 1 is equally applicable to Claim 6. The combined teachings of Kirkpatrick and Jain disclose the following limitations: The device of Claim 1 (see Claim 1 limitation mappings above) , The combined teachings of Kirkpatrick and Jain do not explicitly disclose the following limitations: wherein the processing circuitry to determine the storage layout for the data object is further to: determine the block, subblock, and shard boundaries for the data object, wherein the block, subblock, and shard boundaries are determined based on: a size of the data object; a number of shards on the storage system; and a maximum block size on the storage system However, Maeda discloses the following limitations: processing circuitry (CPU 211, Fig. 2) … to (¶0080 // Fig. 5) determine the block, subblock, and shard boundaries for the data object (“The calculation unit 505 calculates a boundary adjustment value … The boundary adjustment value is a size of padding data added to the writing request data in order to match a writing size with a stripe boundary (stripe size)” [0092] // Figs. 1 + 3) – As shown in Maeda Figs. 1 and 3, a storage environment 100 (see Fig. 1) logically organizes data into a plurality of “data groups” (e.g., D1 – D3 and P, Fig. 1) and “address units” (see Fig. 3) striped across storage devices (e.g., S1-S4, Fig. 1), which examiner considers analogous to the storage environments disclosed in Kirkpatrick Fig. 4 (which organizes data into each of shards, segments, and allocation units) and Jain Fig. 5 ( which logically organizes data into a plurality of FMUs). As previously discussed with respect to Claim 1 (see Claim 1 limitation mappings above) , the storage environment of Jain pre-pads host write data in order to align the write data within logical memory unit boundaries (see also Jain Fig. 7, steps 706 + 720 // ¶0073) . Accordingly, examiner considers calculation of a size of padding data to be added to “writing request data”, as detailed in Maeda ¶0092, as calculating “ the block, subblock, and shard boundaries for the data object ”-- wherein the block, subblock, and shard boundaries are determined based on: a size of the data object (“a writing request size” [0092]) ; a number of shards on the storage system (“the number of data disks” [0092]) ; and a maximum block size on the storage system (“the stripe depth” [0092]; ¶0041)(“The calculation unit 505 calculates a boundary adjustment value and a stripe depth based on a writing request size and the number of data disks . The writing request size is a size of data (writing target data) which is requested to be written … The stripe depth is a size of data which is distributed and written to each data disk through striping, and is a size of a region (strip) storing data per disk in a single stripe.” [0092] // Fig. 1) – As disclosed in Maeda ¶0092, parameters including “a writing request size” (i.e., “ a size of the data object ”), “the number of data disks”, and “the stripe depth” are used to calculate the boundary adjustment value. As shown in Fig. 1 , each data disk includes a data group. Accordingly, examiner considers “the number of data disks” as reading on the claimed concept of “ a number of shards on the storage system ”. As detailed in ¶0092, “the stripe depth” corresponds to the size of a region, on each disk, storing a single stripe of data. Accordingly, examiner considers “the stripe depth” as reading on the claimed concept of “ a maximum block size on the storage system ”. Kirkpatrick, Jain, and Maeda are all considered analogous to the claimed invention because they all relate to the same field of formatting sets of data elements to include padding prior to storage. 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 Kirkpatrick and Jain with the teachings of Maeda and realize a method of determining block and shard boundaries for a data object based on a size of the data object, a number of shards, and a maximum block size. Doing so would enable data to be written to a storage device to be formatted with padding data according to predetermined stripe size, improving the performance of storage device configurations using parity by decreasing write penalty (WP), as disclosed in Maeda ¶¶0035; 0042: “in a case of RAID level using parity, such as RAID 5 or 6, if a size of data to be written to a disk does not match a stripe size, reading from the disk called a write penalty (WP) occurs in order to generate parity” [0035] // “The padding data is dummy data for adjustment given to the writing target data in order to match a size to be written with a stripe boundary (stripe size). Specifically, for example, the storage control device 101 calculates a stripe depth and a size of padding data so that “a size of writing target data + a size of padding data” matches “the number of data disks x a stripe depth” [0042] Regarding Claim 7, The same motivation to combine provided in Claim 6 is equally applicable to Claim 7. The combined teaching of Kirkpatrick, Jain, and Maeda disclose the following limitations: The device of Claim 6, wherein the processing circuitry to determine the storage layout for the data object is further to: determine a size for a last block of the data object (Jain, “the end of the data to be written” [0055] // Tail portion of 1 st data, Fig.6) , wherein the size for the last block is less than the maximum block size (Maeda, “the stripe depth” [0041]) , and wherein the size for the last block is inflated based on padding inserted in the storage layout (Jain, “when the end of the data to be written in response to the write command is unaligned with a boundary of one of the FMUs, then the controller 122 of the storage device 120 may need to post-pad the data (e.g., with dummy data) before the data written in response to the write command” [0055] // Fig. 6) – As shown in Jain Fig. 6 and detailed in ¶0055, the end of write command data is “post-padded” in order to align with an FMU boundary. One of ordinary skill in the art would understand that post-padding the end of write command data would cause the size of data to become “ inflated ”. As previously discussed (see Claim 6 limitation mappings above) , the “stripe depth” disclosed in Maeda corresponds to a size of a data region on a disk amounting to a “full stripe”. Accordingly, one of ordinary skill in the art would understand that the end of write command data disclosed in Jain (i.e., the size of the “Tail portion of 1 st data” shown in Jain Fig. 6) would have a size that is less than “ the maximum block size ”. Regarding Claim 15, The same motivation to combine provided in Claim 10 is equally applicable to Claim 15. The combined teachings of Kirkpatrick and Jain disclose the following limitations: The storage medium of Claim 10 (see Claim 10 limitation mappings above) , The combined teachings of Kirkpatrick and Jain do not explicitly disclose the following limitations: wherein the instructions that cause the processing circuitry to determine the storage layout for the data object further cause the processing circuitry to: determine the block, subblock, and shard boundaries for the data object, wherein the block, subblock, and shard boundaries are determined based on: a size of the data object; a number of shards on the storage system; and a maximum block size on the storage system However, Maeda discloses the following limitations: processing circuitry (CPU 211, Fig. 2) to (¶0080 // Fig. 5) determine the block, subblock, and shard boundaries for the data object (“The calculation unit 505 calculates a boundary adjustment value … The boundary adjustment value is a size of padding data added to the writing request data in order to match a writing size with a stripe boundary (stripe size)” [0092] // Figs. 1 + 3) – As shown in Maeda Figs. 1 and 3, a storage environment 100 (see Fig. 1) logically organizes data into a plurality of “data groups” (e.g., D1 – D3 and P, Fig. 1) and “address units” (see Fig. 3) striped across storage devices (e.g., S1-S4, Fig. 1), which examiner considers analogous to the storage environments disclosed in Kirkpatrick Fig. 4 (which organizes data into each of shards, segments, and allocation units) and Jain Fig. 5 ( which logically organizes data into a plurality of FMUs). As previously discussed with respect to Claim 10 (see Claim 10 limitation mappings above) , the storage environment of Jain pre-pads host write data in order to align the write data within logical memory unit boundaries (see also Jain Fig. 7, steps 706 + 720 // ¶0073) . Accordingly, examiner considers calculation of a size of padding data to be added to “writing request data”, as detailed in Maeda ¶0092, as calculating “ the block, subblock, and shard boundaries for the data object ”-- wherein the block, subblock, and shard boundaries are determined based on: a size of the data object (“a writing request size” [0092]) ; a number of shards on the storage system (“the number of data disks” [0092]) ; and a maximum block size on the storage system (“the stripe depth” [0092]; ¶0041)(“The calculation unit 505 calculates a boundary adjustment value and a stripe depth based on a writing request size and the number of data disks . The writing request size is a size of data (writing target data) which is requested to be written … The stripe depth is a size of data which is distributed and written to each data disk through striping, and is a size of a region (strip) storing data per disk in a single stripe.” [0092] // Fig. 1) – As disclosed in Maeda ¶0092, parameters including “a writing request size” (i.e., “ a size of the data object ”), “the number of data disks”, and “the stripe depth” are used to calculate the boundary adjustment value. As shown in Fig. 1 , each data disk includes a data group. Accordingly, examiner considers “the number of data disks” as reading on the claimed concept of “ a number of shards on the storage system ”. As detailed in ¶0092, “the stripe depth” corresponds to the size of a region, on each disk, storing a single stripe of data. Accordingly, examiner considers “the stripe depth” as reading on the claimed concept of “ a maximum block size on the storage system ”. Kirkpatrick, Jain, and Maeda are all considered analogous to the claimed invention because they all relate to the same field of formatting sets of data elements to include padding prior to storage. 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 Kirkpatrick and Jain with the teachings of Maeda and realize a method of determining block and shard boundaries for a data object based on a size of the data object, a number of shards, and a maximum block size. Doing so would enable data to be written to a storage device to be formatted with padding data according to predetermined stripe size, improving the performance of storage device configurations using parity by decreasing write penalty (WP), as disclosed in Maeda ¶¶0035; 0042: “in a case of RAID level using parity, such as RAID 5 or 6, if a size of data to be written to a disk does not match a stripe size, reading from the disk called a write penalty (WP) occurs in order to generate parity” [0035] // “The padding data is dummy data for adjustment given to the writing target data in order to match a size to be written with a stripe boundary (stripe size). Specifically, for example, the storage control device 101 calculates a stripe depth and a size of padding data so that “a size of writing target data + a size of padding data” matches “the number of data disks x a stripe depth” [0042] Regarding Claim 16, The same motivation to combine provided in Claim 15 is equally applicable to Claim 16. The combined teaching of Kirkpatrick, Jain, and Maeda disclose the following limitations: The storage medium of Claim 15, wherein instructions that cause the processing circuitry to determine the storage layout for the data object further cause the processing circuitry to: determine a size for a last block of the data object (Jain, “the end of the data to be written” [0055] // Tail portion of 1 st data, Fig.6) , wherein the size for the last block is less than the maximum block size (Maeda, “the stripe depth” [0041]) , and wherein the size for the last block is inflated based on padding inserted in the storage layout (Jain, “when the end of the data to be written in response to the write command is unaligned with a boundary of one of the FMUs, then the controller 122 of the storage device 120 may need to post-pad the data (e.g., with dummy data) before the data written in response to the write command” [0055] // Fig. 6) – As shown in Jain Fig. 6 and detailed in ¶0055, the end of write command data is “post-padded” in order to align with an FMU boundary. One of ordinary skill in the art would understand that post-padding the end of write command data would cause the size of data to become “ inflated ”. As previously discussed (see Claim 15 limitation mappings above) , the “stripe depth” disclosed in Maeda corresponds to a size of a data region on a disk amounting to a “full stripe”. Accordingly, one of ordinary skill in the art would understand that the end of write command data disclosed in Jain (i.e., the size of the “Tail portion of 1 st data” shown in Jain Fig. 6) would have a size that is less than “ the maximum block size ”. Regarding Claim 22, The same motivation to combine provided in Claim 18 is equally applicable to Claim 22. The combined teachings of Kirkpatrick and Jain disclose the following limitations: The method of Claim 18 (see Claim 18 limitation mappings above) , The combined teachings of Kirkpatrick and Jain do not explicitly disclose the following limitations: wherein determining the storage layout for the data object comprises: determining the block, subblock, and shard boundaries for the data object, wherein the block, subblock, and shard boundaries are determined based on: a size of the data object; a number of shards on the storage system; and a maximum block size on the storage system However, Maeda discloses the following limitations: determining the block, subblock, and shard boundaries for the data object (“The calculation unit 505 calculates a boundary adjustment value … The boundary adjustment value is a size of padding data added to the writing request data in order to match a writing size with a stripe boundary (stripe size)” [0092] // Figs. 1 + 3) – As shown in Maeda Figs. 1 and 3, a storage environment 100 (see Fig. 1) logically organizes data into a plurality of “data groups” (e.g., D1 – D3 and P, Fig. 1) and “address units” (see Fig. 3) striped across storage devices (e.g., S1-S4, Fig. 1), which examiner considers analogous to the storage environments disclosed in Kirkpatrick Fig. 4 (which organizes data into each of shards, segments, and allocation units) and Jain Fig. 5 ( which logically organizes data into a plurality of FMUs). As previously discussed with respect to Claim 18 (see Claim 18 limitation mappings above) , the storage environment of Jain pre-pads host write data in order to align the write data within logical memory unit boundaries (see also Jain Fig. 7, steps 706 + 720 // ¶0073) . Accordingly, examiner considers calculation of a size of padding data to be added to “writing request data”, as detailed in Maeda ¶0092, as calculating “ the block, subblock, and shard boundaries for the data object ”-- wherein the block, subblock, and shard boundaries are determined based on: a size of the data object (“a writing request size” [0092]) ; a number of shards on the storage system (“the number of data disks” [0092]) ; and a maximum block size on the storage system (“the stripe depth” [0092]; ¶0041)(“The calculation unit 505 calculates a boundary adjustment value and a stripe depth based on a writing request size and the number of data disks . The writing request size is a size of data (writing target data) which is requested to be written … The stripe depth is a size of data which is distributed and written to each data disk through striping, and is a size of a region (strip) storing data per disk in a single stripe.” [0092] // Fig. 1) – As disclosed in Maeda ¶0092, parameters including “a writing request size” (i.e., “ a size of the data object ”), “the number of data disks”, and “the stripe depth” are used to calculate the boundary adjustment value. As shown in Fig. 1 , each data disk includes a data group. Accordingly, examiner considers “the number of data disks” as reading on the claimed concept of “ a number of shards on the storage system ”. As detailed in ¶0092, “the stripe depth” corresponds to the size of a region, on each disk, storing a single stripe of data. Accordingly, examiner considers “the stripe depth” as reading on the claimed concept of “ a maximum block size on the storage system ”. Kirkpatrick, Jain, and Maeda are all considered analogous to the claimed invention because they all relate to the same field of formatting sets of data elements to include padding prior to storage. 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 Kirkpatrick and Jain with the teachings of Maeda and realize a method of determining block and shard boundaries for a data object based on a size of the data object, a number of shards, and a maximum block size. Doing so would enable data to be written to a storage device to be formatted with padding data according to predetermined stripe size, improving the performance of storage device configurations using parity by decreasing write penalty (WP), as disclosed in Maeda ¶¶0035; 0042: “in a case of RAID level using parity, such as RAID 5 or 6, if a size of data to be written to a disk does not match a stripe size, reading from the disk called a write penalty (WP) occurs in order to generate parity” [0035] // “The padding data is dummy data for adjustment given to the writing target data in order to match a size to be written with a stripe boundary (stripe size). Specifically, for example, the storage control device 101 calculates a stripe depth and a size of padding data so that “a size of writing target data + a size of padding data” matches “the number of data disks x a stripe depth” [0042] The combined teachings of Kirkpatrick, Jain, and Maeda additionally disclose the following limitations: determining a size for a last block of the data object (Jain, “the end of the data to be written” [0055] // Tail portion of 1 st data, Fig.6) , wherein the size for the last block is less than the maximum block size (Maeda, “the stripe depth” [0041]) , and wherein the size for the last block is inflated based on padding inserted in the storage layout (Jain, “when the end of the data to be written in response to the write command is unaligned with a boundary of one of the FMUs, then the controller 122 of the storage device 120 may need to post-pad the data (e.g., with dummy data) before the data written in response to the write command” [0055] // Fig. 6) – As shown in Jain Fig. 6 and detailed in ¶0055, the end of write command data is “post-padded” in order to align with an FMU boundary. One of ordinary skill in the art would understand that post-padding the end of write command data would cause the size of data to become “ inflated ”. As discussed above, the “stripe depth” disclosed in Maeda corresponds to a size of a data region on a disk amounting to a “full stripe”. Accordingly, one of ordinary skill in the art would understand that the end of write command data disclosed in Jain (i.e., the size of the “Tail portion of 1 st data” shown in Jain Fig. 6) would have a size that is less than “ the maximum block size ”. Regarding Claim 25, The same motivation to combine provided in Claim 23 is equally applicable to Claim 25. The combined teachings of Kirkpatrick and Jain disclose the following limitations: The system of Claim 23 (see Claim 23 limitation mappings above) , The combined teachings of Kirkpatrick and Jain do not explicitly disclose the following limitations: wherein the data storage server to determine the storage layout for the data object is further to: determine the block, subblock, and shard boundaries for the data object, wherein the block, subblock, and shard boundaries are determined based on: a size of the data object; a number of shards on the storage system; and a maximum block size on the storage system However, Maeda discloses the following limitations: determine the block, subblock, and shard boundaries for the data object (“The calculation unit 505 calculates a boundary adjustment value … The boundary adjustment value is a size of padding data added to the writing request data in order to match a writing size with a stripe boundary (stripe size)” [0092] // Figs. 1 + 3) – As shown in Maeda Figs. 1 and 3, a storage environment 100 (see Fig. 1) logically organizes data into a plurality of “data groups” (e.g., D1 – D3 and P, Fig. 1) and “address units” (see Fig. 3) striped across storage devices (e.g., S1-S4, Fig. 1), which examiner considers analogous to the storage environments disclosed in Kirkpatrick Fig. 4 (which organizes data into each of shards, segments, and allocation units) and Jain Fig. 5 ( which logically organizes data into a plurality of FMUs). As previously discussed with respect to Claim 23 (see Claim 23 limitation mappings above) , the storage environment of Jain pre-pads host write data in order to align the write data within logical memory unit boundaries (see also Jain Fig. 7, steps 706 + 720 // ¶0073) . Accordingly, examiner considers calculation of a size of padding data to be added to “writing request data”, as detailed in Maeda ¶0092, as calculating “ the block, subblock, and shard boundaries for the data object ”-- wherein the block, subblock, and shard boundaries are determined based on: a size of the data object (“a writing request size” [0092]) ; a number of shards on the storage system (“the number of data disks” [0092]) ; and a maximum block size on the storage system (“the stripe depth” [0092]; ¶0041)(“The calculation unit 505 calculates a boundary adjustment value and a stripe depth based on a writing request size and the number of data disks . The writing request size is a size of data (writing target data) which is requested to be written … The stripe depth is a size of data which is distributed and written to each data disk through striping, and is a size of a region (strip) storing data per disk in a single stripe.” [0092] // Fig. 1) – As disclosed in Maeda ¶0092, parameters including “a writing request size” (i.e., “ a size of the data object ”), “the number of data disks”, and “the stripe depth” are used to calculate the boundary adjustment value. As shown in Fig. 1 , each data disk includes a data group. Accordingly, examiner considers “the number of data disks” as reading on the claimed concept of “ a number of shards on the storage system ”. As detailed in ¶0092, “the stripe depth” corresponds to the size of a region, on each disk, storing a single stripe of data. Accordingly, examiner considers “the stripe depth” as reading on the claimed concept of “ a maximum block size on the storage system ”. Kirkpatrick, Jain, and Maeda are all considered analogous to the claimed invention because they all relate to the same field of formatting sets of data elements to include padding prior to storage. 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 Kirkpatrick and Jain with the teachings of Maeda and realize a method of determining block and shard boundaries for a data object based on a size of the data object, a number of shards, and a maximum block size. Doing so would enable data to be written to a storage device to be formatted with padding data according to predetermined stripe size, improving the performance of storage device configurations using parity by decreasing write penalty (WP), as disclosed in Maeda ¶¶0035; 0042: “in a case of RAID level using parity, such as RAID 5 or 6, if a size of data to be written to a disk does not match a stripe size, reading from the disk called a write penalty (WP) occurs in order to generate parity” [0035] // “The padding data is dummy data for adjustment given to the writing target data in order to match a size to be written with a stripe boundary (stripe size). Specifically, for example, the storage control device 101 calculates a stripe depth and a size of padding data so that “a size of writing target data + a size of padding data” matches “the number of data disks x a stripe depth” [0042] The combined teachings of Kirkpatrick, Jain, and Maeda additionally disclose the following limitations: determine a size for a last block of the data object (Jain, “the end of the data to be written” [0055] // Tail portion of 1 st data, Fig.6) , wherein the size for the last block is less than the maximum block size (Maeda, “the stripe depth” [0041]) , and wherein the size for the last block is inflated based on padding inserted in the storage layout (Jain, “when the end of the data to be written in response to the write command is unaligned with a boundary of one of the FMUs, then the controller 122 of the storage device 120 may need to post-pad the data (e.g., with dummy data) before the data written in response to the write command” [0055] // Fig. 6) – As shown in Jain Fig. 6 and detailed in ¶0055, the end of write command data is “post-padded” in order to align with an FMU boundary. One of ordinary skill in the art would understand that post-padding the end of write command data would cause the size of data to become “ inflated ”. As discussed above, the “stripe depth” disclosed in Maeda corresponds to a size of a data region on a disk amounting to a “full stripe”. Accordingly, one of ordinary skill in the art would understand that the end of write command data disclosed in Jain (i.e., the size of the “Tail portion of 1 st data” shown in Jain Fig. 6) would have a size that is less than “ the maximum block size ” . 07-21-aia AIA Claims 26 is r ejected under 35 U.S.C. 103 as being unpatentable over K irkpatrick further in view of Jain and Leidel (US 20200012447 A1)(hereafter referred to as Leidel ). R egarding Claim 26, The same motivation to combine provided in Claim 1 is equally applicable to Claim 27. The combined teachings of Kirkpatrick and Jain disclose the following limitations: The device of Claim 1 (see Claim 1 limitation mappings above) , wherein padding is selectively inserted (Jain, Fig. 6) – As previously discussed (see Claim 1 limitation mappings above) and as taught in Jain Fig. 6, padding is applied when 1 st or 2 nd data does not align to an FMU boundary (i.e., “ padding is selectively inserted ”)— Although Jain Fig. 6 shows that padding can be inserted either before (i.e., “pre-padding”) or after (i.e., “post-padding”) an individual data element, the combined teachings of Kirkpatrick and Jain do not appear to explicitly disclose an embodiment whereby padding is inserted specifically between “adjacent” data element of a set of data elements. Specifically, Kirkpatrick and Jain do not explicitly disclose the following limitations: padding is selectively inserted between adjacent data elements of the set of data elements to prevent the individual data elements from spanning multiple shards . However, Leidel discloses the following limitations: padding is selectively inserted between adjacent data elements of the set of data elements to prevent the individual data elements from spanning multiple shards. (Fig. 1A // “FIG. 1A shows the byte-based memory elements 130, 132, and 134 as being back-padded such that the padding portions 121, 123, and 125 are logically to the right of their respective data portions 120, 122, and 124” [0022]) – As shown in Leidel Fig. 1A, a memory allocation 136 (i.e., “ a storage layout ”) organizes data within equal-sized memory elements 130, 132, and 134; similar to how data of Jain Fig. 6 is organized within equal-sized FMUs. Examiner accordingly considers the memory elements 130, 132, and 134 of Leidel Fig. 1A as analogous to the claimed concept of “ shards ”. As taught in Leidel, in a “byte-based alignment” type of memory layout inserts padding (e.g., padding 121, 123, and 125) in between adjacent data elements (e.g., data elements 122, 122, and 124) such that the layout is aligned into equal-sized memory elements 130, 132, and 134 (i.e., having “an integer number of bytes”; see ¶0012). As further shown in Fig. 1C, the byte-based alignment layout is in contrast to a non-byte-based alignment layout whereby data elements 122-124 are adjacent without padding in between. Accordingly, inserting padding between data elements 120, 122, and 124 as shown in Fig. 1A “ prevent[s] ” a particular data element (e.g., 122) from “ spanning multiple shards ” (i.e., from spanning multiple memory elements 130, 132, or 134). Kirkpatrick, Jain, and Leidel are considered analogous to the claimed invention because they all relate to the same field of formatting and aligning write data prior to non-volatile storage. 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 Kirkpatrick and Jain with the teachings of Leidel and realize a storage layout which inserts padding in between adjacent memory elements. Organizing data in a byte-aligned format enables storage devices to perform memory transactions at a byte level as opposed to at a bit level, improving processing efficiency by reducing a number of memory transactions required to operate on data, as disclosed in Leidel ¶0012: “If a memory element is defined to have a quantity of data bits corresponding to a data value where the bit length of the memory element does not equal an integer quantity of bytes, then an OS may pad out the memory element by adding bits to the memory element such that the bit length is equal to an integer number of bytes. Thus, memory requests may be made based on byte-based alignment” [0012] . Response to Arguments 07-37 AIA Applicant's arguments filed 11/17/2025 with respect to the 35 U.S.C. 103 rejections of Claims 1-2, 4-11, 13-18, and 20-25 have been fully considered but they are not persuasive. With respect to applicant’s argument located within the final paragraph of the 2 nd page of remarks continuing to the 3 rd page of remarks, which recites: “Jain ’s padding mechanism is directed to device-level write alignment rather than aligning individual data elements of a data object within block, subblock, and shard boundaries. Jain explains that padding is used to satisfy flash memory write constraints when write commands are not aligned with flash management unit (FMU) boundaries. Specifically, Jain states that “[s]ince a partial FMU cannot be written to, data that a host wants to store in the non-volatile memory may sometimes need to be pre-padded and/or post-padded before the data is stored.” Jain ¶ 2. Jain further explains that when “the initial LBA is unaligned with a boundary of one of the FMUs, then a controller of the storage device may need to pre-pad the data … before the data … is stored.” Jain ¶ 3. Thus, Jain pads data so that write operations comply with flash memory alignment requirements at the hardware level. For example, in Jain , each write command specifies data of a specified length to be written to memory, and padding may be applied to the beginning or the end of that data to align the entire set of data within FMU boundaries . See, e.g., Jain ¶¶ 72-77. However, Jain has no disclosure of applying padding to align individual data elements of the specified data in the write command within any boundaries, much less within block, subblock, and shard boundaries . Accordingly, neither Kirkpatrick nor Jain , whether alone or in combination, have any disclosure of determining a storage layout for a data object , where the storage layout is padded to align individual data elements of the set of data elements within block, subblock, and shard boundaries .” Examiner has fully considered the aforementioned argument but does not find it persuasive. Applicant argues that the combined teachings of Kirkpatrick and Jain fail to disclose the claimed concept of “ determine a storage layout for the data object … wherein the storage layout is padded to align individual data elements of the set of data elements within block, subblock, and shard boundaries ” at least because Jain provides no disclosure of applying padding to align individual data elements of specified data of a write command “within any boundaries”, let alone within “ block, subblock, and shard boundaries ” as recited in the independent claims as amended. Examiner notes that applicant’s argument appears to mischaracterize the outstanding 35 U.S.C. 103 rejection of independent claims over Kirkpatrick further in view of Jain . In addition, examiner respectfully disagrees with applicant’s characterization of the Jain reference. Finally, examiner notes that applicant’s arguments appear to read in features of the disclosed invention which are not required by the claims as currently presented. First, examiner notes that the outstanding rejection relies on Kirkpatrick , not on Jain , for disclosing the claimed concept of “ a storage layout ” which “ align[s] individual data elements within block, subblock, and shard boundaries ” (see 12/10/2025 Non-Final Rejection, pgs. 5-6). Examiner relies on Jain merely for the disclosure that padding is a technique used for a layout of write data which is aligned within a storage boundary (see 12/10/2025 Non-Final Rejection, pgs. 7-8). Next, examiner respectfully disagrees with applicant’s characterization that Jain “has no disclosure of applying padding” to align individual data elements of specified data within a write command “within any boundaries”. As taught in Jain ¶0073 and as shown in Fig. 6, when the initial LBA of 1 st data is not aligned within an FMU boundary, the data is “pre-padded” with dummy data so that the front portion of 1 st data becomes aligned within the FMU boundary. Examiner considers the aforementioned pre-padding of 1 st data as an example of a layout which applies “ padding ” to an individual element (e.g., 1 st data) of write data in order to align the individual element within a storage boundary (e.g., an FMU). Therefore, combining the teaching of a layout which applies padding to align an individual data elements within a storage boundary, as taught in Jain , to the storage layout of Kirkpatrick whereby data is aligned within each of block, subblock, and shard boundaries, results in a storage layout which: 1) aligns individual data elements within each of block, subblock, and shard boundaries (per Kirkpatrick) ; and 2) applies padding to an individual data element to align the individual data element within a storage boundary (per Jain ). Such a storage layout reads on the claimed concept of a “ storage layout ” which is “ padded to align individual data elements of the set of data elements within block, subblock, and shard boundaries ”, under the BRI of the claimed invention. Nothing in the claims as currently presented precludes such an interpretation of the independent claims as currently presented. Finally, examiner notes that applicant’s arguments appear to read in features of the disclosed invention which are not required under the BRI of the independent claims as currently presented. Applicant’s arguments appear to suggest that the claimed limitation “ the storage layout is padded to align individual data elements of the set of data elements within block, subblock, and shard boundaries ” as currently presented requires consideration be taken for each individual data element of a plurality of data elements contained within the layout as part of a padding process applied to a storage layout (i.e., padding the storage layout is a process applied to each data element of the set of data elements which are not aligned within storage boundaries). Further, applicant’s arguments suggest that the aforementioned padding process require consideration be taken for each organizational storage boundary in the storage system (i.e., padding the storage layout is a process which requires each of block boundaries, subblock boundaries, and shard boundaries be taken into consideration for purposes of alignment). However, examiner notes that the independent claims as currently presented to not require each individual element of the set of data elements be considered during the padding process; and further does not specify how the padding process relates to block, subblock, and shard boundaries of the underlying storage system. Instead, applicant chooses to use passive language to describe a result of a padding process applied to a layout. Therefore, examiner maintains the combined teachings of Kirkpatrick and Jain disclose the claimed concept of “ the storage layout is padded to align individual data elements of the set of data elements within block, subblock, and shard boundaries ” as currently presented. With respect to applicant’s argument located within the 2 nd paragraph of the 3 rd page of remarks, which recites: “Moreover, the cited combination would not have been obvious to one of ordinary skill in the art. In particular, the references address different problems at different layers of a storage system. Kirkpatrick involves distributing subsets of data across storage drives to improve parallelism in a storage system. Kirkpatrick ¶¶ 21, 136. Jain , by contrast, addresses hardware constraints of flash memory devices by padding data in write commands to align the data within flash management unit (FMU) boundaries. See, e.g., Jain ¶¶ 2-3. Because Jain ’s padding is tied specifically to flash memory write alignment constraints, a person of ordinary skill in the art would not have been motivated to modify Kirkpatrick ’s distributed storage system to incorporate Jain ’s device-level padding technique in order to align individual data elements of a data object within block, subblock, and shard boundaries . In fact, neither Jain nor Kirkpatrick has any disclosure of aligning individual data elements of a data object within storage boundaries of any type . At best, if Kirkpatrick were modified based on Jain’s padding functionality, Kirkpatrick would pre- or post-pad data from a write request to align the data as a whole within the boundaries of a flash management unit (FMU). See, e.g., Kirkpatrick ¶ 35, Jain ¶¶ 2-3.” Examiner has fully considered the aforementioned argument but does not find it persuasive. Applicant appears to argue that combining Kirkpatrick and Jain as recited in the outstanding prior art rejections would not have been obvious at least because the two references “address different problems at different layers of a storage system.” Examiner respectfully disagrees, and notes that one of ordinary skill in the art would have recognized that Kirkpatrick and Jain belong to the same field of endeavor, specifically the field of formatting and aligning write data prior to non-volatile storage. Therefore, use of Kirkpatrick and Jain in a 103 obviousness rejection is proper because both prior art are analogous to the claimed invention. Whether or not Kirkpatrick and Jain address different problems does not preclude their use in an obviousness rejection. See MPEP 2141.01(a) . Conclusion 07-40 AIA Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL . See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure : Arulambalam et al. (US 20070250737 A1) – Discloses a storage system organized into chunks, stripes, and SSUs ( see Fig. 4 ) whereby padding is inserted to fill out an entire SSU before storing data to memory (see Fig. 6) 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 /ROCIO DEL MAR PEREZ-VELEZ/Supervisory Patent Examiner, Art Unit 2133 Application/Control Number: 17/703,245 Page 2 Art Unit: 2133 Application/Control Number: 17/703,245 Page 3 Art Unit: 2133 Application/Control Number: 17/703,245 Page 4 Art Unit: 2133 Application/Control Number: 17/703,245 Page 5 Art Unit: 2133 Application/Control Number: 17/703,245 Page 6 Art Unit: 2133 Application/Control Number: 17/703,245 Page 7 Art Unit: 2133 Application/Control Number: 17/703,245 Page 8 Art Unit: 2133 Application/Control Number: 17/703,245 Page 9 Art Unit: 2133 Application/Control Number: 17/703,245 Page 10 Art Unit: 2133 Application/Control Number: 17/703,245 Page 11 Art Unit: 2133 Application/Control Number: 17/703,245 Page 12 Art Unit: 2133 Application/Control Number: 17/703,245 Page 13 Art Unit: 2133 Application/Control Number: 17/703,245 Page 14 Art Unit: 2133 Application/Control Number: 17/703,245 Page 15 Art Unit: 2133 Application/Control Number: 17/703,245 Page 16 Art Unit: 2133 Application/Control Number: 17/703,245 Page 17 Art Unit: 2133 Application/Control Number: 17/703,245 Page 18 Art Unit: 2133 Application/Control Number: 17/703,245 Page 19 Art Unit: 2133 Application/Control Number: 17/703,245 Page 20 Art Unit: 2133 Application/Control Number: 17/703,245 Page 21 Art Unit: 2133 Application/Control Number: 17/703,245 Page 22 Art Unit: 2133 Application/Control Number: 17/703,245 Page 23 Art Unit: 2133 Application/Control Number: 17/703,245 Page 24 Art Unit: 2133 Application/Control Number: 17/703,245 Page 25 Art Unit: 2133 Application/Control Number: 17/703,245 Page 26 Art Unit: 2133 Application/Control Number: 17/703,245 Page 27 Art Unit: 2133 Application/Control Number: 17/703,245 Page 28 Art Unit: 2133 Application/Control Number: 17/703,245 Page 29 Art Unit: 2133 Application/Control Number: 17/703,245 Page 30 Art Unit: 2133 Application/Control Number: 17/703,245 Page 31 Art Unit: 2133 Application/Control Number: 17/703,245 Page 32 Art Unit: 2133 Application/Control Number: 17/703,245 Page 33 Art Unit: 2133 Application/Control Number: 17/703,245 Page 34 Art Unit: 2133 Application/Control Number: 17/703,245 Page 35 Art Unit: 2133 Application/Control Number: 17/703,245 Page 36 Art Unit: 2133 Application/Control Number: 17/703,245 Page 37 Art Unit: 2133 Application/Control Number: 17/703,245 Page 38 Art Unit: 2133 Application/Control Number: 17/703,245 Page 39 Art Unit: 2133 Application/Control Number: 17/703,245 Page 40 Art Unit: 2133 Application/Control Number: 17/703,245 Page 41 Art Unit: 2133 Application/Control Number: 17/703,245 Page 42 Art Unit: 2133 Application/Control Number: 17/703,245 Page 43 Art Unit: 2133 Application/Control Number: 17/703,245 Page 44 Art Unit: 2133 Application/Control Number: 17/703,245 Page 45 Art Unit: 2133 Application/Control Number: 17/703,245 Page 46 Art Unit: 2133 Application/Control Number: 17/703,245 Page 47 Art Unit: 2133 Application/Control Number: 17/703,245 Page 48 Art Unit: 2133 Application/Control Number: 17/703,245 Page 49 Art Unit: 2133 Application/Control Number: 17/703,245 Page 50 Art Unit: 2133 Application/Control Number: 17/703,245 Page 51 Art Unit: 2133 Application/Control Number: 17/703,245 Page 52 Art Unit: 2133 Application/Control Number: 17/703,245 Page 53 Art Unit: 2133 Application/Control Number: 17/703,245 Page 54 Art Unit: 2133 Application/Control Number: 17/703,245 Page 55 Art Unit: 2133 Application/Control Number: 17/703,245 Page 56 Art Unit: 2133
Prosecution Insights