CTNF 19/181,923 CTNF 90978 DETAILED ACTION 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. Response to Application This office action is in response to the Application filed on 05/29/2025. Claims 1-20 are presented for examination. Drawings The drawings submitted on 05/29/2025 are accepted. Specification 06-31 AIA The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 In the event a determination of the status of the application as subject to AIA 35 U.S.C. 102, 103, and 112 (or as subject to pre-AIA 35 U.S.C. 102, 103, and 112) is incorrect, any correction of the statutory basis for a rejection will not be considered a new ground of rejection if the prior art relied upon and/or the rationale supporting the rejection, would be the same under either status. 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 set forth in Graham v. John Deere Co. , 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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-20-02-aia AIA This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. 07-21-aia AIA Claim s 1-6, 10-15 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Benisty (US 2021/0240641 A1) in view of Palmer (US 2024/0061767 A1) . Regarding independent claims 1 and 10 , taking claim 1 as exemplary analysis, Benisty discloses A method, comprising: receiving, in a memory sub-system, a command to identify information about the memory sub-system … and receiving, in the memory sub-system, an access command with an embedded sub block descriptor ([0002], “Commands, such as read commands and write commands, are placed by host software into a submission queue and are fetched by the data storage device for execution”; Fig. 1, “NVMe Command Accelerators 126.”; Fig. 2B, “SGL POINTER” and “SGL DESCRIPTORS”; [0004], “A SGL descriptor associated with the data is fetched”; Fig. 3, “FIRST SGL SEGMENT IN SQ ENTRY,” “SGL DATA BLOCK DESCRIPTORS.”) ; Benisty teaches receiving, in the memory sub-system, an access command with an embedded sub block descriptor. However, Benisty does not expressly teach specifying a sub block granularity level for the sub block access. In an analogous art of memory space management, Palmer teaches providing, by the memory sub-system, structured data indicating that the memory sub-system supports sub block access and specifying a sub block granularity level for the sub block access; and receiving, in the memory sub-system, an access command with an embedded sub block descriptor ( Palmer teaches communicating logical address granularity capability information between a memory subsystem and host system, as shown in [0002], “The memory subsystem can provide memory usability capacity information and supported logical address granularity information”; Fig. 2, operations 220–240 (“Send the usable capacity information”; “Read supported granularity information”; “Send the supported granularity information”) [0021], “ The memory sub-system can provide the supported logical address granularity information in response to receiving the request for the supported logical address granularity information”; Fig. 3, “Logical Address Granularity 350” including “4 KB” and “512 B.” Thus, Palmer disclose providing structured capability data that indicates support for a particular granularity of memory operations (write granularity parameter) from the memory subsystem to the host. It would have been obvious to one of ordinary skill to extend the capability set of an NVMe memory subsystem such as Benisty ’s device to include a property indicating support for operations at a sub-block granularity, and to include a field specifying the granularity value, because Palmer recognize the advantages of informing the host of the device’s operational granularity and pass such parameters in identify-like structured data. Replacing Palmer ’s “minimum write size” with “sub-block access granularity” is a predictable use of Palmer ’s technique to a closely related parameter (size or unit at which the device can operate); and doing so in structured identify data is directly taught by Palmer . Incorporating Palmer ’s granularity capability advertisement into Benisty ’s NVMe/SGL framework permit hosts to issue commands targeting smaller portions of logical blocks with known supported granularity. Under KSR, this would be a simple substitution of one known parameter for another within a known configuration interface to achieve the predictable result of host-device coordination on granularity. Regarding independent claim 10 , Claim recites substantially the same limitations as in claim 1, and is therefore rejected for the same reasons set forth in the analysis of claim 1. Additionally, Benisty in fig. 1 teaches A memory sub-system (Fig. 1, memory sub-system 100, Data storage device 102), comprising: a host interface (Fig. 1, Host interface 101) configured to operate on a computer bus ([0026], PCIe fabric); non-volatile memory cell ([0031]); and a controller ( Fig. 1, storage device controller 110; [0032] ) configured to …. Regarding independent claim 19 , Benisty discloses A non-transitory computer storage medium storing instructions which, when executed in a memory sub-system, cause the memory sub-system to perform a method ( [0002], [0004], [ 0028], Processor 130 executes instructions of the computer-readable program code of the firmware and/or software. Storage controller 110 implements the processes described herein by execution of instructions by the processor 130, by hardware, or by combinations thereof ), comprising: receiving, in the memory sub-system from a host system, an access command with a sub block descriptor embedded within the access command ( [0002] "Commands, such as read commands and write commands, are placed by host software into a submission queue and are fetched by the data storage device for execution."; [0004] "A SGL descriptor associated with the data is fetched."; Fig. 2B illustrates "SGL POINTER" and "SGL DESCRIPTORS." Fig. 3 illustrates: "FIRST SGL SEGMENT IN SQ ENTRY" and "SGL DATA BLOCK DESCRIPTORS." These disclosures teach receiving an access command containing an embedded descriptor used to define a subset of data associated with the command ); Benisty teaches determining the characteristics of the data region specified by the descriptor as shown in [0004] "Whether the SGL descriptor is a SGL bit bucket descriptor or a SGL data block descriptor is determined." Fig. 2B further shows SGL descriptors containing: "PHYSICAL ADDRESSES + SIZES." Palmer teaches that logical-address space may be subdivided according to logical-address granularity and address length information. Fig. 3 discloses "Starting Address," "Address Length," "Logical Address Granularity." A person of ordinary skill in the art would have recognized that the address and size information of Benisty's descriptor may be interpreted according to Palmer's disclosed logical-address granularity to identify a portion of a logical block rather than an entire logical block. Thus, the combination of Benisty and Palmer taches and determining, based on the sub block descriptor provided within the access command, a portion of a logical block identified by the access command. Regarding claims 2 and 11 , the combination of Benisty and Palmer further teaches determining, based on the sub block descriptor provided within the access command, a portion of a logical block identified by the access command ( Benisty [0004], “Whether the SGL descriptor is a SGL bit bucket descriptor or a SGL data block descriptor is determined”; Benisty Fig. 5, operation 530, “DETERMINE WHETHER THE SGL DESCRIPTOR IS A SGL BIT BUCKET DESCRIPTOR.”) ; and performing, by the memory sub-system, an operation on the portion of the logical block according to an opcode specified by the access command ( Benisty [0004], “The modified TLP is transferred to the host”; Benisty Fig. 5, operations 550–560, “GENERATE A MODIFIED TLP,” “TRANSFER THE MODIFIED TLP TO THE HOST.” ) ; wherein the structured data includes a field for scatter gather lists (SGL) support; and an indication that the memory sub-system supports the sub block access and the sub block granularity level are provided within the field for SGL support (Palmer [0021], “supported logical address granularity information”; Palmer Fig. 2, operations 220–240. It would have been obvious to place the granularity-support indication within an existing SGL-support capability field because SGL-related capability structures conventionally advertise optional transfer capabilities ). Regarding claims 3 and 12 , the combination of Benisty and Palmer further teaches wherein the command to identify information and the structured data are in accordance with a standard for non-volatile memory express (NVMe) (Benisty [0002], “NVM Express (NVMe) is an interface protocol between a host and a data storage device”; Benisty [0002], “NVMe data structures”; Benisty Fig. 1, “NVMe Command Accelerators 126.” ); the indication is provided in bit 22 of the field for SGL support; and the sub block granularity level is specified in bit 23 to bit 26 of the field for SGL support (Palmer teaches communicating granularity information within protocol structures as shown in [0021], “The memory subsystem can provide the supported logical address granularity information to the host system.” The particular recitation that “the indication is provided in bit 22” and “the sub block granularity level is specified in bit 23 to bit 26” would have been obvious as a matter of routine protocol-field allocation and design choice because assigning unused/reserved bits in an NVMe capability field to represent new capabilities merely involves predictable encoding implementation. Choosing particular bit positions (bit 22 and bits 23–26) within a known capability field to encode additional related capabilities (support and granularity) is a design detail well within the routine skill of the ordinary artisan, especially where the field already relates to SGL support, and NVMe explicitly reserves bits for vendor or future use. No new functionality arises from the choice of exact bits; it is merely specifying implementation details for a straightforward extension of Palmer ’s technique to the specific SGL support field recognized in NVMe and used in Benisty ’s context ). Regarding claims 4 and 13 , the combination of Benisty and Palmer further teaches wherein the structured data includes a field for vendor specific information; and an indication that the memory sub-system supports the sub block access and the sub block granularity level are provided within the field for vendor specific information (Palmer [0021], “supported logical address granularity information”; Palmer Fig. 2, operations 220–240. NVMe identify structures provide vendor-specific fields/bytes specifically for adding proprietary capabilities. Palmer states that the indication of write granularity and related command structures are “improvements to or otherwise additions to an access protocol, such as NVMe,” and implies that such extensions can be implemented within vendor-specific or reserved regions. It would have been obvious to place such granularity information into a vendor-specific field because vendor-specific fields are conventionally used to advertise implementation-specific capabilities prior to standardization. ). Regarding claims 5 and 14 , the combination of Benisty and Palmer further teaches wherein the sub block descriptor specifies an offset and a length; and the portion is determined based on the offset, the length, and the sub block granularity level ( Palmer Fig. 3, “Starting Address 320,” “Address Length 330,” “Logical Address Granularity 350.” Palmer explicitly describes write commands specifying a starting LBA and a length L, and the device comparing the total size to a write granularity parameter. Benisty additionally teaches descriptor entries including addresses and sizes. Benisty Fig. 2B, “PHYSICAL ADDRESSES + SIZES.” It would have been straightforward for a person of ordinary skill to define a “sub-block descriptor” that includes an offset within the logical block and a length, and to compute the affected portion as a function of offset, length, and the known device granularity parameter (sub-block granularity level), exactly like existing mapping of LBAs and lengths to physical page or block boundaries. This is a routine arithmetic interpretation of descriptor parameters, not a patentably distinct concept) Regarding claims 6 and 15 , the combination of Benisty and Palmer further teaches wherein the access command is in accordance with a standard for non-volatile memory express (NVMe) (Benisty [0002], “NVM Express (NVMe) is an interface protocol”; Benisty Fig. 2B, “SGL POINTER”; Benisty Fig. 3, “FIRST SGL SEGMENT IN SQ ENTRY.” Benisty in [0002] describes an NVMe-compliant data storage device (memory sub-system) that supports standard NVMe administrative commands, including commands for “querying the feature set of the storage device,” “creating and modifying various types of queues,” and similar configuration and identify-type operations. Benisty explicitly operates “under the NVMe protocol” and explains that “NVMe data structures, such as submission queues, completion queues, Physical Region Page (PRP) entries, scatter gather lists (SGLs), and data buffers are stored in host memory” and that NVMe includes “administrative commands” for configuration ); and the sub block descriptor is specified in a field of data pointer(Benisty Fig. 2B, “SGL POINTER”; Benisty [0002], “scatter gather lists (SGLs)”). Regarding claim 20 , the combination of Benisty and Palmer further teaches performing, by the memory sub-system, an operation on the portion of the logical block according to an opcode specified by the access command ( Benisty teaches processing read/write commands according to the command received from the host. Benisty [0002] "Commands, such as read commands and write commands, are placed by host software into a submission queue and are fetched by the data storage device for execution."; [0004] teaches processing the command according to the descriptor type and performing corresponding transfer operations) ; wherein the operation is performed to transfer, between the memory sub-system and a memory of a host system, data of the portion of the logical block without transferring, between the memory sub-system and the memory of the host system, data of the logical block outside of the block ( Benisty teaches descriptor-directed transfer of data associated with the descriptor-specified memory region. See Fig. 2B: "PHYSICAL ADDRESSES + SIZES." Benisty in Fig. 5 teaches fetching a descriptor associated with the requested data and transferring data according to that descriptor. Palmer teaches operations performed according to logical-address granularity and address-length information corresponding to a selected portion of logical address space rather than an entire logical block. Palmer Fig. 3. It would have been obvious to a person of ordinary skill in the art to transfer only the granularity-defined portion identified by the descriptor because doing so reduces unnecessary data movement, decreases host-interface bandwidth consumption, lowers latency, and improves transfer efficiency when only a subset of a logical block is required. Such advantages are recognized goals in storage-system design and represent the predictable result of combining Palmer's partial-block granularity access with Benisty's descriptor-based transfer mechanism) . 07-21-aia AIA Claim s 7-9 and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Benisty (US 2021/0240641 A1) in view of Palmer (US 2024/0061767 A1) and further in view of Olcay (US 2016/0291867 A1) . Regarding claims 7 and 16 , the combination of Benisty and Palmer further teaches wherein the sub block descriptor further specifies an identifier of the sub block descriptor, including a type and a sub type (Benisty [0004], “Whether the SGL descriptor is a SGL bit bucket descriptor or a SGL data block descriptor is determined”; Benisty Fig. 5, operation 530). Benisty teaches descriptor classification and descriptor type information. However does not expressly teach an identifier . Olcay teaches structured descriptor metadata and descriptor fields usable for descriptor identification as shown in Fig. 3: Descriptor Flags 320 Descriptor 322-1 Descriptor 322-2 Descriptor 322-3 Descriptor 322-4; Fig. 2: Descriptor Fields 240 Pointer Fields 242; [0004]: "maintaining a dynamic descriptor list"; [0005]: "DMA descriptors"; [0015]: "Data and metadata DMA descriptors are handled with the same engine" Benisty teaches descriptor type information: "bit bucket descriptor" or "data block descriptor"; Olcay teaches descriptor metadata fields and descriptor flags usable for identifying descriptor classes: Descriptor Flags 320, Descriptor Fields 240. It would have been obvious to implement the descriptor identification mechanism using a type field and subtype field within the descriptor metadata to facilitate differentiation among descriptor classes and processing behaviors. Regarding claims 8 and 17 , the combination of Benisty, Palmer and Olcay further teaches wherein the type has a predetermined value of 6h; the sub block descriptor has a predetermined size of 16 bytes; and the identifier of the sub block descriptor is configured in byte 15 of the sub block descriptor (Benisty teaches predefined SGL descriptor structures. See Fig. 3, “SGL DESCRIPTOR 320”; [0004], “SGL bit bucket descriptor.” Olcay teaches defined descriptor-field layouts and metadata structures as shown in Fig. 3, “Descriptor Flags 320,” “Descriptor 322-1,” “Descriptor 322-2,” “Descriptor Tail Pointer 308.” The particular limitations that “the type has a predetermined value of 6h,” “the sub block descriptor has a predetermined size of 16 bytes,” and “the identifier ... is configured in byte 15” would have been obvious matters of routine protocol encoding and descriptor-layout design because specific byte sizes, byte offsets, and numerical identifier values are conventional implementation choices made during protocol definition). Regarding claims 9 and 18 , the combination of Benisty, Palmer and Olcay further teaches wherein the sub block descriptor further specifies a memory address to access a memory of a host system to transfer data for the portion of the logical block (Benisty Fig. 2B, “PHYSICAL ADDRESSES + SIZES”; [0002], “SGLs ... are stored in host memory”; Fig. 1, “HOST MEMORY 160.” ). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRACY C CHAN whose telephone number is (571)272-9992. The examiner can normally be reached on Monday - Friday 10 AM to 6 PM EST. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, TIM VO can be reached on (571)272-3642. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /TRACY C CHAN/Primary Examiner, Art Unit 2138 Application/Control Number: 19/181,923 Page 2 Art Unit: 2138 Application/Control Number: 19/181,923 Page 3 Art Unit: 2138 Application/Control Number: 19/181,923 Page 4 Art Unit: 2138 Application/Control Number: 19/181,923 Page 5 Art Unit: 2138 Application/Control Number: 19/181,923 Page 6 Art Unit: 2138 Application/Control Number: 19/181,923 Page 7 Art Unit: 2138 Application/Control Number: 19/181,923 Page 8 Art Unit: 2138 Application/Control Number: 19/181,923 Page 9 Art Unit: 2138 Application/Control Number: 19/181,923 Page 10 Art Unit: 2138 Application/Control Number: 19/181,923 Page 11 Art Unit: 2138 Application/Control Number: 19/181,923 Page 12 Art Unit: 2138 Application/Control Number: 19/181,923 Page 13 Art Unit: 2138
Prosecution Insights