DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claims 1, 4, 7, 12-16, and 19-21 are pending. Claims 1, 7, 14, 16, 19, and 20 have been amended as per Applicants' request. Claims 5, 6, 8-11, 17, 22, and 23 have been canceled as per Applicants' request.
Papers Submitted
It is hereby acknowledged that the following papers have been received and placed of record in the file:
Amended Claims as filed on March 23, 2026
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4, 12-14, 16, 19, 20, and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over IZHAR (US 2023/0161499) (hereinafter Izhar) (published May 25, 2023) in view of MALAKAPALLI et al. (US 2022/0137835) (hereinafter Malakapalli) (published May 05, 2022).
Regarding Claims 1, 19, and 20, taking claim 1 as exemplary, Izhar discloses a data processing method, being applied to a storage server, the storage server comprising a network interface card and a solid-state drive, and
“In operation, NVMe-oF™ bridge device 204 receives NVMe-oF™ capsules from remote initiators 208, 209, terminates the NVMe-oF™ capsules, and forwards these as NVMe™ commands to SSD devices (e.g., 220) that are connected to the PCIe ports 210 of bridge 204. When deploying an NVMe™ JBOF solution, it is typical to deploy multiple SSDs in enclosure 202 such as to aggregate bandwidth capability to support the storage needs of multiple servers, here, NVMe-oF™ initiators 208, 209, while scaling memory capacity. It is common for storage enclosure 202 to be oversubscribed, i.e., the maximum bandwidth of fabric ports 205 is lower than the maximum bandwidth of all the underlying SSDs (e.g., 220)” (Izhar [0031])
“As an example, a typical NVMe-oF™ bridge may include a 100 GbE Ethernet port on the fabric side and may need to support 24 NVMe™ SSDs on the NVMe™ port that, e.g., connect to the bridge using a PCIe fan-out switch” (Izhar [0039] the Ethernet port is the NIC)
the solid-state drive comprising a controller memory buffer, a controller, a flash memory device, and an internal direct random access memory, the internal direct random access memory comprising the controller memory buffer, the method comprising:
“FIG. 6 illustrates comparative default read/write and CMB-based data flows within an SSD according to embodiments of the present disclosure. As depicted, SSD 600 may comprise SSD controller 602, NAND flash memory devices 610, and internal direct random access memory (DRAM) 604 that comprises CMB 608” (Izhar [0046])
receiving, by the network interface card, a data operation command which is sent by a host, the data operation command carrying input/output data;
“In operation, NVMe-oF™ bridge device 204 receives NVMe-oF™ capsules from remote initiators 208, 209, terminates the NVMe-oF™ capsules, and forwards these as NVMe™ commands to SSD devices (e.g., 220) that are connected to the PCIe ports 210 of bridge 204” (Izhar [0031] see fig. 2 remote initiators are the host, the NVMe commands are the data operation commands, and the input/output data would be the address information included in the commands)
“As an example, a typical NVMe-oF™ bridge may include a 100 GbE Ethernet port on the fabric side and may need to support 24 NVMe™ SSDs on the NVMe™ port that, e.g., connect to the bridge using a PCIe fan-out switch” (Izhar [0039] the Ethernet port is the NIC from which the commands received from the host)
sending the input/output data to the solid-state drive according to the data operation command by the network interface card; and
“In operation, NVMe-oF™ bridge device 204 receives NVMe-oF™ capsules from remote initiators 208, 209, terminates the NVMe-oF™ capsules, and forwards these as NVMe™ commands to SSD devices (e.g., 220) that are connected to the PCIe ports 210 of bridge 204” (Izhar [0031] the forwarded NVMe commands includes the input/output data of the address information)
“As an example, a typical NVMe-oF™ bridge may include a 100 GbE Ethernet port on the fabric side and may need to support 24 NVMe™ SSDs on the NVMe™ port that, e.g., connect to the bridge using a PCIe fan-out switch” (Izhar [0039] the Ethernet port is the NIC from which input/output data is forwarded to the SSD)
operating on the controller memory buffer according to the input/output data by the solid- state drive,
“CMB-based data flow 630 that utilizes CMB 608 may comprise, for example, an NVMe™ read operation by which a host may submit a read command to the submission queue of SSD controller 602. In one or more embodiments, e.g., when the bridge programs a DMA engine of a fabric port (not shown in FIG. 6), unlike in existing designs in which a memory data pointer points to the DDR local address, the pointer may point to an address range in CMB 608 as the data is not written to the cache and DDR (shown in FIG. 7) of the bridge. SSD controller 602 may read the data from NAND devices 610 and, instead of sending the data over PCIe bus 614 to a host memory address, SSD controller 602 may write the data to any number of buffers in CMB 608” (Izhar [0048])
when the data operation command is a data read command, the input/output data includes address information, and the operating on the controller memory buffer according to the input/output data by the solid-state drive comprises:
“CMB-based data flow 630 that utilizes CMB 608 may comprise, for example, an NVMe™ read operation by which a host may submit a read command to the submission queue of SSD controller 602. In one or more embodiments, e.g., when the bridge programs a DMA engine of a fabric port (not shown in FIG. 6), unlike in existing designs in which a memory data pointer points to the DDR local address, the pointer may point to an address range in CMB 608 as the data is not written to the cache and DDR (shown in FIG. 7) of the bridge. SSD controller 602 may read the data from NAND devices 610 and, instead of sending the data over PCIe bus 614 to a host memory address, SSD controller 602 may write the data to any number of buffers in CMB 608” (Izhar [0048] the read operation/command includes the pointer to the address range which is to be operated on)
receiving, by the controller, the address information and sending the address information to the internal direct random access memory;
“SSD controller 602 may communicate with a host over bus 614, e.g., using a Peripheral Component Interconnect Express (PCI Express or PCIe) bus standard” (Izhar [0047])
“CMB-based data flow 630 that utilizes CMB 608 may comprise, for example, an NVMe™ read operation by which a host may submit a read command to the submission queue of SSD controller 602” (Izhar [0048] the read operation/command includes the address information of the CMB)
determining a target address corresponding to the controller memory buffer according to the address information by the internal direct random access memory, wherein the controller memory buffer comprises at least one buffer unit;
“In one or more embodiments, e.g., when the bridge programs a DMA engine of a fabric port (not shown in FIG. 6), unlike in existing designs in which a memory data pointer points to the DDR local address, the pointer may point to an address range in CMB 608 as the data is not written to the cache and DDR (shown in FIG. 7) of the bridge” (Izhar [0048] the address range of the CMB comprises at least one buffer unit)
reading target data from the target address corresponding to the controller memory buffer by the internal direct random access memory;
“once the data is written to CMB 608, SSD controller 602 may communicate to the host that the data has been read and is now available to be read from CMB 608. Unlike the default data flow, once the data has been written to CMB 608, SSD 600 may be viewed as having completed the I/O transfer, even if, subsequent to the transfer, the data is read by the host, e.g., over PCIe bus 614” (Izhar [0049])
wherein the reading target data from the target address corresponding to the controller memory buffer by the internal direct random access memory comprises: determining a first target buffer unit from the at least one buffer unit according to the target address by the internal direct random access memory; and
“CMB-based data flow 630 that utilizes CMB 608 may comprise, for example, an NVMe™ read operation by which a host may submit a read command to the submission queue of SSD controller 602. In one or more embodiments, e.g., when the bridge programs a DMA engine of a fabric port (not shown in FIG. 6), unlike in existing designs in which a memory data pointer points to the DDR local address, the pointer may point to an address range in CMB 608 as the data is not written to the cache and DDR (shown in FIG. 7) of the bridge. SSD controller 602 may read the data from NAND devices 610 and, instead of sending the data over PCIe bus 614 to a host memory address, SSD controller 602 may write the data to any number of buffers in CMB 608” (Izhar [0048] the read operation/command includes the pointer to the address of a location in the CMB)
reading the target data from the first target buffer unit by the internal direct random access memory;
“once the data is written to CMB 608, SSD controller 602 may communicate to the host that the data has been read and is now available to be read from CMB 608. Unlike the default data flow, once the data has been written to CMB 608, SSD 600 may be viewed as having completed the I/O transfer, even if, subsequent to the transfer, the data is read by the host, e.g., over PCIe bus 614” (Izhar [0049])
wherein, when the data operation command is a data write command, the input/output data includes data to be written and corresponding write address information, and the operating on the controller memory buffer according to the input/output data by the solid- state drive comprises:
“A host write command that points the SSD controller 602 to buffer(s) in CMB 608 comprising the I/O data may be sent to the submission queue of SSD controller 602” (Izhar [0050])
receiving, by the controller, the data to be written and the corresponding write address information and sending the data to be written and the corresponding write address information to the internal direct random access memory;
“The host I/O data payload may be written to an available CMB 608. A host write command that points the SSD controller 602 to buffer(s) in CMB 608 comprising the I/O data may be sent to the submission queue of SSD controller 602” (Izhar [0050] the host command includes the data and address and is forwarded to the CMB)
determining an address to be written corresponding to the controller memory buffer according to the corresponding write address information by the internal direct random access memory; and
“The host I/O data payload may be written to an available CMB 608. A host write command that points the SSD controller 602 to buffer(s) in CMB 608 comprising the I/O data may be sent to the submission queue of SSD controller 602” (Izhar [0050] the location in the CMB is pointed to by the write command)
writing the data to be written to the address to be written corresponding to the controller memory buffer by the internal direct random access memory comprising:
“The host I/O data payload may be written to an available CMB 608. A host write command that points the SSD controller 602 to buffer(s) in CMB 608 comprising the I/O data may be sent to the submission queue of SSD controller 602” (Izhar [0050])
determining a second target buffer unit from the at least one buffer unit according to the address to be written by the internal direct random access memory; and writing the data to be written into the second target buffer unit by the internal direct random access memory; and
“A host write command that points the SSD controller 602 to buffer(s) in CMB 608 comprising the I/O data may be sent to the submission queue of SSD controller 602” (Izhar [0050] multiple buffers can be determined)
“SSD controller 602 may write the data to any number of buffers in CMB 608” (Izhar [0048])
wherein the method further comprising: obtaining, by the internal direct random access memory, written data from the controller memory buffer and sending the written data to the flash memory device; and storing, by the flash memory device, the written data.
“Conversely, during an NVMe™ write operation, in one or more embodiments CMB 608 may be used in the following manner: The host I/O data payload may be written to an available CMB 608. A host write command that points the SSD controller 602 to buffer(s) in CMB 608 comprising the I/O data may be sent to the submission queue of SSD controller 602. SSD controller 602 may then read the data from CMB 608 and write it to NAND devices 610” (Izhar [0050])
But does not explicitly state the controller comprising a first register and a second register, the first register and the second register being configured to describe different attribute information of the controller memory buffer, wherein the first register defines a location of the controller memory buffer, the second register defines a size of the controller memory buffer, and first attribute information corresponding to the first register and second attribute information corresponding to the second register are set to indicate that the controller supports the controller memory buffer, the first register is Controller Memory Buffer Location or the second register is Controller Memory Buffer Size, wherein the operating on the controller memory buffer is performed in response to the first attribute information and the second attribute information being set to indicate that the controller supports the controller memory buffer.
Malakapalli and Izhar discloses the controller comprising a first register and a second register, the first register and the second register being configured to describe different attribute information of the controller memory buffer,
“For example, in NVMe, the CMB is defined by a NVMe controller register CMBLOC which defines the PCI address location of the start of the CMB and a controller register CMB SZ which is the size of the CMB” (Malakapalli [0062])
wherein the first register defines a location of the controller memory buffer, the second register defines a size of the controller memory buffer, and first attribute information corresponding to the first register and second attribute information corresponding to the second register are set to indicate that the controller supports the controller memory buffer, the first register is Controller Memory Buffer Location or the second register is Controller Memory Buffer Size,
“For example, in NVMe, the CMB is defined by a NVMe controller register CMBLOC which defines the PCI address location of the start of the CMB and a controller register CMB SZ which is the size of the CMB” (Malakapalli [0062] by setting/having information in these two registers it is implied that the controller supports the use of controller memory buffer)
wherein the operating on the controller memory buffer is performed in response to the first attribute information and the second attribute information being set to indicate that the controller supports the controller memory buffer,
“For example, in NVMe, the CMB is defined by a NVMe controller register CMBLOC which defines the PCI address location of the start of the CMB and a controller register CMB SZ which is the size of the CMB” (Malakapalli [0062] by setting/having information in these two registers it is implied that the controller supports the use of controller memory buffer)
“Existing default data flow, i.e., non-CMB-enabled data flow, comprises SSD controller 602 using DMA to exchange data with the host memory, internally buffer the data, and write it to non-volatile media, e.g., NAND flash memory 610” (Izhar [0047])
“In contrast, in one or more embodiments of the present disclosure, CMB-based data flow 630 that utilizes CMB 608 may comprise, for example, an NVMe™ read operation by which a host may submit a read command to the submission queue of SSD controller 602” (Izhar [0048] CMB-based data flow would be used if the registers CMBLOC and CMB SZ indicates that there is a CMB buffer available)
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the registers of CMBLOC and CMBSZ in Malakapalli with the system of Izhar. The CMBLOC and CMBSZ are registers defined in the NVMeoF specification. The motivation for the combination would be improve compatibility when accessing the command memory buffer of the SSD by using the NVMeoF standard.
Regarding Claims 4 and 21, Izhar further discloses further comprising: sending the target data to the controller by the internal direct random access memory;
“In the NVMe™ protocol, once the SSD host (here, the NVMe-oF™ bridge device) sends a command to the SSD controller, the SSD has full ownership of the memory buffers that were sent to the SSD controller during the command phase. The SSD controller may fetch the data payload, e.g., in any order, from the host memory buffer locations where that data resides” (Izhar [0038])
sending the target data to the network interface card as a read completion message by the controller; and
“The SSD controller DMAs the data payload and writes the data payload to the bridge's memory. Once the data phase is complete, the SSD controller communicates a completion message, allowing the bridge device to RDMA the data from bridge memory to the initiator memory space. The data I/O operation completes when the bridge device writes the completion status capsule to the initiator” (Izhar [0037] see fig. 2 the sending of data to the initiator is via the fabric ports)
returning the read completion message to the host by the network interface card.
“Once the data phase is complete, the SSD controller communicates a completion message, allowing the bridge device to RDMA the data from bridge memory to the initiator memory space. The data I/O operation completes when the bridge device writes the completion status capsule to the initiator” (Izhar [0037] see fig. 2 the sending of data to the initiator is via the fabric ports)
Regarding Claim 12, Izhar further discloses wherein the sending the input/output data to the solid-state drive according to the data operation command by the network interface card comprises: sending the input/output data to a Peripheral Component Interconnect Express (PCIe) switching unit according to the data operation command by the network interface card; and sending the input/output data to the solid-state drive by the PCIe switching unit.
“NVMe-oF™ bridge device 204 receives NVMe-oF™ capsules from remote initiators 208, 209, terminates the NVMe-oF™ capsules, and forwards these as NVMe™ commands to SSD devices (e.g., 220) that are connected to the PCIe ports 210 of bridge 204” (Izhar [0031] see fig.2 communication via the path fabric ports to NVMeoF bridge to PCIe ports to SSD)
“In operation, SSD controller 602 may communicate with a host over bus 614, e.g., using a Peripheral Component Interconnect Express (PCI Express or PCIe) bus standard” (Izhar [0047])
Regarding Claim 13, Izhar further discloses wherein the operating on the controller memory buffer according to the input/output data by the solid-state drive comprises: in response to the input/output data being data carried by the data read command, reading data from the controller memory buffer according to the input/output data by the solid-state drive.
“CMB-based data flow 630 that utilizes CMB 608 may comprise, for example, an NVMe™ read operation by which a host may submit a read command to the submission queue of SSD controller 602. In one or more embodiments, e.g., when the bridge programs a DMA engine of a fabric port (not shown in FIG. 6), unlike in existing designs in which a memory data pointer points to the DDR local address, the pointer may point to an address range in CMB 608 as the data is not written to the cache and DDR (shown in FIG. 7) of the bridge. SSD controller 602 may read the data from NAND devices 610 and, instead of sending the data over PCIe bus 614 to a host memory address, SSD controller 602 may write the data to any number of buffers in CMB 608” (Izhar [0048])
“once the data is written to CMB 608, SSD controller 602 may communicate to the host that the data has been read and is now available to be read from CMB 608. Unlike the default data flow, once the data has been written to CMB 608, SSD 600 may be viewed as having completed the I/O transfer, even if, subsequent to the transfer, the data is read by the host, e.g., over PCIe bus 614” (Izhar [0049] data is read from the CMB and transferred to the host)
Regarding Claim 14, Izhar further discloses wherein the operating on the controller memory buffer according to the input/output data by the solid-state drive comprises: in response to the input/output data being data carried by a data write command, writing data into the controller memory buffer according to the input/output data by the solid-state drive.
“CMB-based data flow 630 that utilizes CMB 608 may comprise, for example, an NVMe™ read operation by which a host may submit a read command to the submission queue of SSD controller 602. In one or more embodiments, e.g., when the bridge programs a DMA engine of a fabric port (not shown in FIG. 6), unlike in existing designs in which a memory data pointer points to the DDR local address, the pointer may point to an address range in CMB 608 as the data is not written to the cache and DDR (shown in FIG. 7) of the bridge. SSD controller 602 may read the data from NAND devices 610 and, instead of sending the data over PCIe bus 614 to a host memory address, SSD controller 602 may write the data to any number of buffers in CMB 608” (Izhar [0048])
Regarding Claim 16, Malakapalli further discloses wherein the corresponding write address information comprises an address block to be written related to the address to be written.
“The write request includes a logical address (e.g., LBA) of the new data” (Malakapalli [0065])
Claim 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Izhar (published May 25, 2023) and Malakapalli (published May 05, 2022) as applied to claim 1 above, and further in view of Kachare et al. (US 2019/0108158) (hereinafter Kachare) (published April 11, 2019).
Regarding Claim 7, the combination of Izhar and Malakapalli disclosed the method of claim 1 and further discloses sending the write completion message to the network interface card by the controller; and returning the write completion message to the host by the network interface card.
“Once the data transfer is complete, SSD controller 602 may send a completion message to the host” (Izhar [0050] see fig. 2 the communication to the host/initiator from the SSD is via the fabric ports/NIC)
But does not explicitly state generating a write completion message and sending the write completion message to the controller.
Izhar and Kachare discloses generating a write completion message and sending the write completion message to the controller.
“Once the data transfer is complete, SSD controller 602 may send a completion message to the host” (Izhar [0050])
“The backend SSD generates a completion entry (CE) corresponding to the NVMe command and sends it to the bridge device. Then, the bridge device parses the CE and intelligently forwards the CE to the NSC processor of the bridge device” (Kachare [0035])
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the generation of a completion entry at the SSD with the system in combination of Izhar and Malakapalli. The motivation for doing so would be to improve management efficiency of the SSD by knowing when the data transfer is completed and therefore would be able to schedule other tasks.
Claim 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Izhar (published May 25, 2023) and Malakapalli (published May 05, 2022) as applied to claim 1 above, and further in view of NVM Command Set Specification Revision 1.0c (https://nvmexpress.org/wp-content/uploads/NVM-Express-NVM-Command-Set-Specification-1.0c-2022.10.03-Ratified-1.pdf) (hereinafter NVM spec) (published October 3rd 2022).
Regarding Claim 15, the combination of Izhar and Malakapalli disclosed the method of claim 1, but does not explicitly state wherein the address information comprises address block information and internal address information.
Izhar and NVM spec wherein the address information comprises address block information and internal address information.
“CMB-based data flow 630 that utilizes CMB 608 may comprise, for example, an NVMe™ read operation by which a host may submit a read command to the submission queue of SSD controller 602. In one or more embodiments, e.g., when the bridge programs a DMA engine of a fabric port (not shown in FIG. 6), unlike in existing designs in which a memory data pointer points to the DDR local address, the pointer may point to an address range in CMB 608 as the data is not written to the cache and DDR (shown in FIG. 7) of the bridge” (Izhar [0048] NVMe read operations includes a data pointer (DPTR) and starting LBA (SLBA) field which would be the address block information and internal address information, and the pointer points to address range of CMB is considered internal address information)
“Data Pointer (DPTR): This field specifies the start of the data buffer. Refer to the Common Command Format figure in the NVM Express Base Specification for the definition of this field” (NVM spec page 33)
“Starting LBA (SLBA): This field indicates the 64-bit address of the first logical block addressed by this command. Command Dword 10 contains bits 31:00; Command Dword 11 contains bits 63:32” (NVM spec page 33)
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the use of data pointer and starting LBA for a read command in NVM spec with the system of the combination of Izhar and Malakapalli. The motivation for the combination would be to improve compatibility when accessing the NVM storage by using the NVMe standard and be in compliance with the standard.
Response to Arguments
Claim Rejections - 35 U.S.C. § 101
Applicant’s arguments, see page 13 of remarks, filed March 23, 2026, with respect to claim 20 have been fully considered and are persuasive. The 35 U.S.C. § 101 rejection of claim 20 has been withdrawn.
Claim Rejections - 35 U.S.C. §§ 102 and 103
Applicant’s arguments, see page 13 of remarks, filed March 23, 2026, with respect to the rejection(s) of claim(s) 1, 19, and 20 under 35 U.S.C. § 102 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of IZHAR (US 2023/0161499) and MALAKAPALLI et al. (US 2022/0137835).
Applicant's arguments filed March 23, 2026 have been fully considered but they are not persuasive.
Applicant Argues:
a) (page 14 bottom) The Examiner's analysis equates Izhar's "NVMe-oF bridge device" and its "fabric ports" to the claimed "storage server" and "network interface card." This conflation overlooks the fundamental architectural distinction. The claimed "NIC" is a component of a direct-attached storage server, while Izhar's "bridge device" is an independent intermediary entity performing protocol translation, command forwarding, and centralized buffering. One skilled in the art would not find it obvious to apply teachings specifically designed to optimize an external bridge device's memory bottleneck to a different, direct-attached server architecture for the purpose of fine-grained internal CMB management.
With respect to (a), Izhar states in paragraph [0039] “a typical NVMe-oF™ bridge may include a 100 GbE Ethernet port on the fabric side” which clearly shows that the bridge includes an Ethernet port and Ethernet ports are used as a network interface. In response to applicant's argument that NIC in the claims is different from the bridge device of Izhar, a recitation of the intended use of the claimed invention must result in a structural difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure is capable of performing the intended use, then it meets the claim.
b) (page 15 top) Izhar Does Not Disclose the "Internal Direct Random Access Memory" Performing the Active Management Functions as Claimed.
Claim 1 explicitly recites that the "internal direct random access memory" performs several active management operations: "determining a target address," "determining a first/second target buffer unit," and reading/writing data from/to that specifically determined unit. This assigns an active, logic-based address resolution and resource scheduling role to the internal memory.
Izhar describes an SSD 600 containing an "internal direct random access memory (DRAM) 604 that comprises CMB 608" (see paragraph [0047] and Fig. 6 of Izhar). However, Izhar consistently attributes the action of moving and operating on data to the "SSD controller 602." For example, "SSD controller 602 may read the data from NAND devices 610 and... write the data to any number of buffers in CMB 608" (see paragraph [0048] of Izhar). Nowhere does Izhar describe or suggest that the "internal DRAM" itself performs the determinative steps of "determining" addresses or target buffer units. The Examiner's mapping of Izhar's "SSD controller" functions to the claimed "internal direct random access memory" is inaccurate and does not account for this distinct claimed feature.
With respect to (b), Applicant appears to assert that the claimed “internal direct random access memory” performs the functions of “determining a target address,” “determining a first/second target buffer unit,” and “reading/writing data from/to that specifically determined unit” in an active, decision-making sense. However, this characterization is not supported. It is well understood that any memory device, including DRAM, performs address decoding in response to externally supplied address and control signals. In this sense, the memory necessarily “identifies” or “determines” the physical location associated with a given address in order to carry out a read or write operation. Such functionality is intrinsic to memory operation and occurs passively in response to inputs from a controller. However, this address decoding does not constitute an active determination of a “target address” or “target buffer unit” in the sense of selecting among alternatives or performing higher-level management functions. Those functions, such as deciding which address to access or which buffer unit to use, are conventionally performed by a controller (as disclosed in Izhar), not by the memory itself. Accordingly, under a broadest reasonable interpretation, the claimed “determining” steps reasonably encompass the address identification performed by memory during standard read/write operations. To the extent Applicant intends the claims to require active, logic-based decision-making by the memory itself, such a requirement is neither explicitly recited nor supported by the claim language.
c) (page 15 middle) Izhar Fails to Disclose or Suggest the Claimed "Determining a Target Buffer Unit" Mechanism Based on Address Information.
A pivotal feature of claim 1 is that the CMB comprises "at least one buffer unit," and for read/write operations, the internal DRAM must "determine a first target buffer unit" or "a second target buffer unit" from this plurality of units "according to the target address" or "the address to be written." This defines a specific address-based, dynamic buffer selection and resource mapping mechanism within the CMB.
With respect to (c), Applicant asserts that Izhar fails to disclose or suggest “determining a target buffer unit” based on address information, particularly where such determination is allegedly performed by the internal DRAM. As discussed above in with respect to (b), a memory device performs address decoding to identify the physical location corresponding to an input address. Where a memory (such as the CMB in Izhar) comprises multiple buffer units or regions, the decoding of the supplied address necessarily results in the selection of a particular buffer unit or memory region associated with that address. In this sense, the memory “determines” a target buffer unit according to the address, albeit passively and in response to externally supplied signals.
Thus, under a broadest reasonable interpretation, the claimed step of “determining a target buffer unit … according to the target address” reads on the operation of memory addressing, where different addresses correspond to different buffer units or regions within the memory. No additional active or higher-level selection logic within the memory itself is required by the claim language.
To the extent Applicant contends that the claims require a dynamic, logic-based buffer selection mechanism performed by the DRAM itself, independent of a controller, such a requirement is not explicitly recited in the claims. Nor does the claim language distinguish between passive address-based selection in memory operation and active decision-making logic. Accordingly, the Examiner’s interpretation that Izhar’s disclosed system, in which the controller provides addresses and the memory correspondingly accesses the associated buffer unit, satisfies the claimed limitation is reasonable.
Furthermore, Izhar discloses that the SSD controller directs data to and from buffers within the CMB, which necessarily involves providing address information corresponding to specific buffer units. The resulting selection of a buffer unit based on the provided address is an consequence of standard memory operation, and therefore meets the claimed “determining” limitation under a broadest reasonable interpretation.
d) (page 16 top) The Examiner's Rejection Overlooks the "Register Configuration as an Enabling Condition" Feature, Which is Not Disclosed by Izhar.
Claim 1 includes the feature that the SSD controller comprises first and second registers describing CMB attributes, and the operation on the CMB is performed "in response to" these registers being set to indicate controller support for the CMB. This establishes a conditional, hardware-software handshake that is a prerequisite for CMB operations, enhancing control and reliability.
The Examiner's analysis for claim 1 (point 12 in the OA) does not address whether Izhar discloses this "register-based enablement" feature. Applicant has reviewed Izhar and confirms that it nowhere describes configuring controller registers to enable/disable CMB operations or using such configuration as a conditional trigger for performing operations on the CMB. This feature alone distinguishes claim 1 from Izhar and contributes to the non-obviousness of the claimed invention.
With respect to (d), regarding the “register configuration as an enabling condition” feature, the Examiner notes that this limitation is rendered obvious by the combination of Izhar and Malakapalli. Malakapalli discloses registers that store information describing characteristics of the controller memory buffer (CMB), including, for example, its location and size. Such registers necessarily indicate the presence and availability of the CMB to the system. As a result, these registers provide configuration information that enables a controller or host to recognize and utilize the CMB. Izhar, on the other hand, discloses data flow operations involving both CMB and non-CMB paths in paragraphs [0047-0048], including transferring data to and from buffers within the CMB under control of the SSD controller. Thus, Izhar teaches the use of the CMB for data operations once it is available within the system. It would have been obvious to a person of ordinary skill in the art at the time of the invention to utilize the register-based CMB information taught by Malakapalli in the system of Izhar such that the controller performs CMB-related operations when the registers indicate the presence and configuration of the CMB. In such a combination, the registers effectively serve as an enabling condition when the registers include valid CMB information (e.g., location and size), which indicates that the CMB is supported and available, and the controller correspondingly utilizes the CMB data path as taught by Izhar. Therefore, the claimed feature of performing operations on the CMB “in response to” registers indicating support for the CMB represents no more than the predictable use of known configuration mechanisms (registers describing memory resources) to control known data flow operations (use of CMB), which would have been obvious to one of ordinary skill in the art. Furthermore, the claim does not require any specific or unconventional “handshake” protocol beyond the presence of register information indicating CMB support. Under a broadest reasonable interpretation, the claimed conditional operation is satisfied by the conventional use of configuration registers to indicate available hardware resources and to guide controller behavior accordingly.
Conclusion
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SIDNEY LI whose telephone number is (571)270-5967. The examiner can normally be reached Monday to Friday 10:00 AM to 6:00 PM.
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, Arpan P Savla can be reached at (571) 272-1077. 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.
/S.L./Examiner, Art Unit 2137
/Arpan P. Savla/Supervisory Patent Examiner, Art Unit 2137
Prosecution Insights