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-24 are pending.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on August 18, 2025 and April 07, 206 is/are in compliance with the provisional of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claim 16 is objected to under 37 CFR 1.75 as being a substantial duplicate of claim 15. When two claims in an application are duplicates or else are so close in content that they both cover the same thing, despite a slight difference in wording, it is proper after allowing one claim to object to the other as being a substantial duplicate of the allowed claim. See MPEP § 608.01(m).
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 3, 7, 8, 11, and 12 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Koufaty et al. (US 2021/0374087) (hereinafter Koufaty) (published December 02, 2021).
Regarding Claim 1, Koufaty discloses a host system comprising: a communication interface; and
“System 100 includes processor 105, controller hub 115, and system memory 110 coupled to controller hub 115” (Koufaty [0018] controller hub can be the communication interface)
at least one processing device configured to:
“Processor 105 includes any processing element, such as a microprocessor, a host processor, an embedded processor, a co-processor, or other processor. Processor 105 is coupled to controller hub 115 through front-side buses (FSB) 106, respectively” (Koufaty [0018])
send, via the communication interface to a memory sub-system, a command configured to determine whether at least one shared work queue (SWQ) is supported by the memory sub-system; and
“Offload device 125 includes any internal or external device or component to be coupled to an electronic system, such as an I/O device, a Network Interface Controller (NIC), an add-in card, an audio processor, a network processor, a hard-drive, a storage device, a CD/DVD ROM, a monitor, a printer, a mouse, a keyboard, a router, a portable storage device, a Firewire device, a Universal Serial Bus (USB) device, a scanner, an accelerator device, a field programmable gate array (FPGA), an application specific integrated circuit, and other input/output devices” (Koufaty [0023] offload device is a memory sub-system)
“In the illustrative embodiment, each entry in the table 600 has a device handle identifier (DHI), one or more domain identifiers (such as a PASID or BDF identifier), and, in some embodiments, additional context information such as a trusted bit or whether a particular feature or set of features is supported by a particular device 125 or device context. For example, in some embodiments, a device 125 may not support PASID” (Koufaty [0049] the entry associated with the DHI show if feature are supported or not)
“In another example, the device 125 may include an indication of a queue pair, a dedicated work queue, a shared work queue, a work command, etc., associated with a DHI” (Koufaty [0067] shared work queue is a feature that is associated with the DHI)
“For example, the controller hub 115 may send and/or receive a message with an enabling bit at a particular location indicating that the controller hub 115 and/or the connected device 125 supports using DHIs. In the illustrative embodiment, the controller hub 115 informs the device 125 of the allowed range of DHI values in block 704” (Koufaty [0068] command sent to inform devices that DHI is supported and the response of DHI ALLOC will identify if SWQ is supported)
receive a response from the memory sub-system indicating that the SWQ is supported.
“In another example, the device 125 may include an indication of a queue pair, a dedicated work queue, a shared work queue, a work command, etc., associated with a DHI” (Koufaty [0067])
“The controller hub 115 may receive a device handle allocation (DHI ALLOC) message in block 708” (Koufaty [0069] the DHI ALLOC will indicate that shared work queue is supported)
Regarding Claim 3, Koufaty further discloses wherein the response identifies at least one resource provided by the memory sub-system for use of the SWQ.
“In the illustrative embodiment, each entry in the table 600 has a device handle identifier (DHI), one or more domain identifiers (such as a PASID or BDF identifier), and, in some embodiments, additional context information such as a trusted bit or whether a particular feature or set of features is supported by a particular device 125 or device context. For example, in some embodiments, a device 125 may not support PASID. In such embodiments, the PASID in the table 600 may be zero, or a separate bit in the host device handle table entry may indicate that PASID is not supported” (Koufaty [0049] paragraph [0576] of specification identifies whether the use of PASID is supported is a resource)
Regarding Claim 7, Koufaty further discloses wherein the response indicates that use of an address space identifier is supported.
“The device allocation message may indicate, e.g., a DHI to allocate (e.g., an n-bit number), a bus/device/function (BDF) identifier, a processor address space identifier (PASID), and a trusted bit value” (Koufaty [0070] PASID is set to a value to indicate that it is supported)
Regarding Claim 8, Koufaty further discloses wherein: the memory sub-system is configured to, in response to receiving the command, provide data in a data buffer that describes the SWQ; and
“the controller hub 115 receives the device handle allocation and device handle deallocation messages from software, such as, for example, through writes to memory mapped I/O (MMIO) registers. In that case, the controller hub 115 processes these messages in the same manner as if they came from the device” (Koufaty [0069] the MMIO registers would be the buffer)
“In block 716, the controller hub 115 allocates a DHI to the device 125 based on the device allocation message. The device allocation message may indicate, e.g., a DHI to allocate (e.g., an n-bit number), a bus/device/function (BDF) identifier, a processor address space identifier (PASID), and a trusted bit value” (Koufaty [0070])
the processing device is further configured read the data provided in the data buffer.
“the controller hub 115 receives the device handle allocation and device handle deallocation messages from software, such as, for example, through writes to memory mapped I/O (MMIO) registers. In that case, the controller hub 115 processes these messages in the same manner as if they came from the device” (Koufaty [0069] when the messages are processed it is being read)
Regarding Claim 11, Koufaty discloses a memory sub-system comprising: a host interface; and
“In use, in some embodiments, the offload device 125 (or any other device connected to the processor 105, such as the graphics accelerator 130) may support different domains” (Koufaty [0025] see fig. 1 the offload device is the memory-subsystem, the host interface is the port 126 on the offload device)
at least one controller configured to:
“The device message processor 504, which may be implemented as hardware, firmware, software, and/or any suitable combination thereof, is configured to control device handle table allocations and deallocations on the device 125 and to use the device handle table information when sending ordinary transactions on the link 119” (Koufaty [0059])
operate in either of a first mode in which commands are received via a submission queue and without using a shared work queue, or a second mode in which commands are received in at least one shared work queue (SWQ) with or without using the submission queue; and
“In the illustrative embodiment, each entry in the table 600 has a device handle identifier (DHI), one or more domain identifiers (such as a PASID or BDF identifier), and, in some embodiments, additional context information such as a trusted bit or whether a particular feature or set of features is supported by a particular device 125 or device context. For example, in some embodiments, a device 125 may not support PASID” (Koufaty [0049] the entry associated with the DHI show if feature are supported or not)
“For example, the transaction manager 510 may send the message to a particular virtual function, a queue pair, a dedicated work queue, a shared work queue, a work command, etc. In the illustrative embodiment, the domain identifier may be a BDF identifier and/or a PASID” (Koufaty [0067] shared work queue is a feature being used in offload device)
receive, via the host interface, a first command configured to determine whether an SWQ interface is supported.
“In another example, the device 125 may include an indication of a queue pair, a dedicated work queue, a shared work queue, a work command, etc., associated with a DHI” (Koufaty [0067])
“For example, the controller hub 115 may send and/or receive a message with an enabling bit at a particular location indicating that the controller hub 115 and/or the connected device 125 supports using DHIs. In the illustrative embodiment, the controller hub 115 informs the device 125 of the allowed range of DHI values in block 704” (Koufaty [0068] command sent to inform devices that DHI is supported and the response of DHI ALLOC will identify if SWQ is supported)
“The controller hub 115 may receive a device handle allocation (DHI ALLOC) message in block 708” (Koufaty [0069] the DHI ALLOC will indicate that shared work queue is supported)
Regarding Claim 12, Koufaty further discloses wherein the controller is further configured to send,
in reply to the first command, a response indicating that the SWQ interface is supported.
“In another example, the device 125 may include an indication of a queue pair, a dedicated work queue, a shared work queue, a work command, etc., associated with a DHI” (Koufaty [0067])
“For example, the controller hub 115 may send and/or receive a message with an enabling bit at a particular location indicating that the controller hub 115 and/or the connected device 125 supports using DHIs. In the illustrative embodiment, the controller hub 115 informs the device 125 of the allowed range of DHI values in block 704” (Koufaty [0068] command sent to inform devices that DHI is supported and the response of DHI ALLOC will identify if SWQ is supported)
“The controller hub 115 may receive a device handle allocation (DHI ALLOC) message in block 708” (Koufaty [0069] the DHI ALLOC will indicate that shared work queue is supported)
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.
Claim 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Koufaty (published December 02, 2021) as applied to claim 1 above, and further in view of Rajgopal et al. (US 2021/0064278) (hereinafter Rajgopal) (published March 04, 2021).
Regarding Claim 2, Koufaty disclosed the system of claim 1, but does not explicitly state wherein the command is a get feature command.
Rajgopal and Koufaty discloses wherein the command is a get feature command.
“the I/O expander 113 is configured to support SET Feature and GET Feature commands, including the SET Feature and GET Feature commands issued with the Feature Addresses listed in Table 2 below … TABLE 2 Feature Address Description … 80h-FFh Vendor Specific” (Rajgopal [0026])
“In another example, the device 125 may include an indication of a queue pair, a dedicated work queue, a shared work queue, a work command, etc., associated with a DHI” (Koufaty [0067] shared work queue can be a vendor specific feature)
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 get and set feature commands for vendor specific features as disclosed in Rajgopal with the system in Koufaty. The motivation for doing so would be to have a reliable way using the NVMe standard to check for vendor specific features such as shared work queue.
Claims 4-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Koufaty (published December 02, 2021) as applied to claim 3 above, and further in view of SANKARAN et al. (US 2019/0347125) (hereinafter Sankaran) (published November 14, 2019).
Regarding Claim 4, Koufaty disclosed the system of claim 3, but does not explicitly state wherein the identified resource includes an address of the SWQ.
Sankaran discloses wherein the identified resource includes an address of the SWQ.
“The device driver for the device is responsible for reporting/enumerating the SWQ capability, the number of SWQs supported and the corresponding SWQ_REG addresses to software through appropriate software interfaces. The driver may also optionally report the depth of the SWQ supported for software tuning or informational purposes (although this is not required for functional correctness)” (Sankaran [0745])
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the details of shared work queues disclosed in Sankaran with the system in Koufaty. The motivation for doing so would be for more efficient access of the shared work queue by knowing where it is located, the size, and the amount that can be used.
Regarding Claim 5, Koufaty disclosed the system of claim 3, but does not explicitly state wherein the identified resource includes a number of SWQs provided by the memory sub-system.
Sankaran discloses wherein the identified resource includes a number of SWQs provided by the memory sub-system.
“The device driver for the device is responsible for reporting/enumerating the SWQ capability, the number of SWQs supported and the corresponding SWQ_REG addresses to software through appropriate software interfaces. The driver may also optionally report the depth of the SWQ supported for software tuning or informational purposes (although this is not required for functional correctness)” (Sankaran [0745])
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the details of shared work queues disclosed in Sankaran with the system in Koufaty. The motivation for doing so would be for more efficient access of the shared work queue by knowing where it is located, the size, and the amount that can be used.
Regarding Claim 6, Koufaty disclosed the system of claim 3, but does not explicitly state
Sankaran discloses wherein the identified resource includes a size of each SWQ provided by the memory sub-system.
“The device driver for the device is responsible for reporting/enumerating the SWQ capability, the number of SWQs supported and the corresponding SWQ_REG addresses to software through appropriate software interfaces. The driver may also optionally report the depth of the SWQ supported for software tuning or informational purposes (although this is not required for functional correctness)” (Sankaran [0745])
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the details of shared work queues disclosed in Sankaran with the system in Koufaty. The motivation for doing so would be for more efficient access of the shared work queue by knowing where it is located, the size, and the amount that can be used.
Claims 9, 10, and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Koufaty (published December 02, 2021) as applied to claims 8 and 11 above, and further in view of KACHARE et al. (US 2021/0089477) (hereinafter Kachare) (published March 25, 2021).
Regarding Claim 9, Koufaty disclosed the system of claim 8, but does not explicitly state wherein the command includes a pointer to the data buffer.
Kachare discloses wherein the command includes a pointer to the data buffer.
“In various embodiments, the host computing device's driver may first allocate a buffer in the host memory. In such an embodiment, it may then create a tunneling message receive command that includes a pointer to the allocated buffer and the size of the buffer” (Kachare [0072])
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the allocation of a buffer in the memory disclosed in Kachare with the system in Koufaty. The motivation for doing so would be for more control by designating a specific location of where the received data should be placed.
Regarding Claim 10, Koufaty disclosed the system of claim 8, but does not explicitly state wherein the processing device is further configured to allocate a portion of main memory to the data buffer.
Kachare discloses wherein the processing device is further configured to allocate a portion of main memory to the data buffer.
“In various embodiments, the host computing device's driver may first allocate a buffer in the host memory. In such an embodiment, it may then create a tunneling message receive command that includes a pointer to the allocated buffer and the size of the buffer” (Kachare [0072])
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the allocation of a buffer in the memory disclosed in Kachare with the system in Koufaty. The motivation for doing so would be for more control by designating a specific location of where the received data should be placed.
Regarding Claim 13, Koufaty disclosed the system of claim 11, but does not explicitly state wherein the controller is further configured to change operation from the first mode to the second mode in response to receiving a second command from a host system.
Kachare and Koufaty discloses wherein the controller is further configured to change operation from the first mode to the second mode in response to receiving a second command from a host system.
“In the illustrated embodiment, the system 200 may include one or more command submission queues (SQs) 211” (Kachare [0049] with the inclusion of the submission queues the first mode is when the SWQ is disabled and the second mode is when the SWQ is enabled)
“The message may be part of a coherent protocol such as CXL.cache or a non-coherent protocol such as CXL input/output (CXL.io). In some embodiments, the message may be referred to as a flit. The controller hub 115 may receive a device handle allocation (DHI ALLOC) message in block 708. The controller hub 115 may receive a device handle deallocation (DHI DEALLOC) message in block 710” (Koufaty [0069] the mode is changed by removing the device allocation and then adding a new allocation with new configuration)
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine use of submission queues disclosed in Kachare with the system in Koufaty. The motivation for doing so would be for better performance by load leveling of traffic spikes, decoupling the host from the device, increased reliability by retrying from queue rather than resending command, etc.
Claims 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Koufaty (published December 02, 2021) and Kachare (published March 25, 2021) as applied to claim 13 above, and further in view of Rajgopal (published March 04, 2021) and Sankaran (published November 14, 2019).
Regarding Claim 14, the combination of Koufaty and Kachare disclosed the system of claim 13, but does not explicitly state wherein the second command is configured to set operating parameters for the SWQ.
Rajgopal discloses the use of a command to set operating parameters
“the I/O expander 113 is configured to support SET Feature and GET Feature commands, including the SET Feature and GET Feature commands issued with the Feature Addresses listed in Table 2 below … TABLE 2 Feature Address Description … 80h-FFh Vendor Specific” (Rajgopal [0026])
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 set feature command for vendor specific features as disclosed in Rajgopal with the system in combination of Koufaty and Kachare. The motivation for doing so would be to have a reliable way using the NVMe standard to check for vendor specific features such as shared work queue.
Sankanran discloses the operating parameters for the SWQ.
“In one implementation, the work queue capabilities register (WQCAP) 10810 specifies capabilities of the work queues such as support for dedicated and/or shared modes of operation, the number of engines, the number of work queues. Table C below lists various parameters and values which may be configured” (Sankanran [0440] the operating parameters of the SWQ would be set by the SET Feature command of Rajgopal)
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the operating parameters of the shared work queues disclosed in Sankaran with the system in combination of Koufaty, Kachare, and Rajgopal. The motivation for doing so would be for more optimal access of the shared work queue by configuring parameters of where it is located, the size, and the amount that can be used to meet the demands of the application.
Claims 15 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Koufaty (published December 02, 2021) as applied to claim 11 above, and further in view of Rajgopal (published March 04, 2021) and Sankaran (published November 14, 2019).
Regarding Claims 15 and 16, Koufaty disclosed the system of claim 11, but does not explicitly state wherein the controller is further configured to: receive a set feature command from a host system; in response to receiving the set feature command, send a reply to the host system indicating a failure to enable the SWQ.
Rajgopal and Koufaty discloses wherein the controller is further configured to: receive a set feature command from a host system;
“the I/O expander 113 is configured to support SET Feature and GET Feature commands, including the SET Feature and GET Feature commands issued with the Feature Addresses listed in Table 2 below … TABLE 2 Feature Address Description … 80h-FFh Vendor Specific” (Rajgopal [0026])
“In another example, the device 125 may include an indication of a queue pair, a dedicated work queue, a shared work queue, a work command, etc., associated with a DHI” (Koufaty [0067] shared work queue can be a vendor specific feature)
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 get and set feature commands for vendor specific features as disclosed in Rajgopal with the system in Koufaty. The motivation for doing so would be to have a reliable way using the NVMe standard to check for vendor specific features such as shared work queue.
Rajgopal, Koufaty, and Sankaran discloses in response to receiving the set feature command, send a reply to the host system indicating a failure to enable the SWQ.
“the I/O expander 113 is configured to support SET Feature and GET Feature commands, including the SET Feature and GET Feature commands issued with the Feature Addresses listed in Table 2 below … TABLE 2 Feature Address Description … 80h-FFh Vendor Specific” (Rajgopal [0026] the SET Feature command would be used to configure the device)
“In another example, the device 125 may include an indication of a queue pair, a dedicated work queue, a shared work queue, a work command, etc., associated with a DHI” (Koufaty [0067] shared work queue is the vendor specific feature to be configured)
“If any of these checks fail, the WQ is not enabled and the error code is recorded in the WQ Error Code field of the WQ Config register 3500. These checks may be performed in any order. Thus an indication of one type of error does not imply that there are not also other errors. The same configuration errors may result in different error codes at different times or with different versions of the device. If none of the checks fail, the device is enabled and the WQ Enabled field is set to 1” (Sankaran [0584] the checking of the work queue in paragraphs [0578-0583] would be performed before the indication for support of a shared work queue in DHI of Koufaty would be returned and if the checking fails the reply would be the WQ error code)
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the error code for work queue disclosed in Sankaran with the system in combination of Koufaty and Rajgopal. The motivation for doing so would be for more efficient memory accesses by know if the work queues are unsupported and would not be used commands that require that feature.
Claims 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rajgopal (published March 04, 2021) in view of Koufaty (published December 02, 2021).
Regarding Claim 17, Rajgopal discloses a host system comprising: a communication interface; and
“The host system 120 can be connected to the memory sub-system 110 via a physical host interface” (Rajgopal [0018])
at least one controller configured to:
“While the example memory sub-system 110 in FIG. 1 has been illustrated as including the controller 115, in another embodiment of the present disclosure, a memory sub-system 110 may not include a controller 115, and instead rely upon external control (e.g., provided by an external host, or by a processor or controller separate from the memory sub-system)” (Rajgopal [0020])
send, via the communication interface to a memory sub-system, a command to configure the memory sub-system.
“In general, the controller 115 can receive commands or operations, including ONFI commands such as SET Feature and GET Feature commands, from the host system 120 and can convert the commands or operations into instructions or appropriate commands to achieve the desired access to the memory components 112-1 to 112-N” (Rajgopal [0021])
But does not explicitly state a command to configure at least one shared work queue (SWQ) of the memory sub-system.
Rajgopal and Koufaty discloses a command to configure at least one shared work queue (SWQ) of the memory sub-system.
“the I/O expander 113 is configured to support SET Feature and GET Feature commands, including the SET Feature and GET Feature commands issued with the Feature Addresses listed in Table 2 below … TABLE 2 Feature Address Description … 80h-FFh Vendor Specific” (Rajgopal [0026])
“In another example, the device 125 may include an indication of a queue pair, a dedicated work queue, a shared work queue, a work command, etc., associated with a DHI” (Koufaty [0067] shared work queue can be a vendor specific feature)
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the shared work queue of Koufaty with the system in Rajgopal. The motivation for doing so would be to increase the efficiency of the system through the offloading of commands to the shared work queue.
Regarding Claim 18, Rajgopal further discloses wherein the command is a set feature command.
“In general, the controller 115 can receive commands or operations, including ONFI commands such as SET Feature and GET Feature commands, from the host system 120 and can convert the commands or operations into instructions or appropriate commands to achieve the desired access to the memory components 112-1 to 112-N” (Rajgopal [0021])
Regarding Claim 19, Rajgopal and Koufaty further discloses wherein the command is configured to disable the SWQ.
“The “SET Feature” command (that writes EFh to a command register) is a mechanism to modify settings of a target feature of a drive, and the “GET Feature” command (that writes EEh to a command register) is a mechanism used to determine the current settings of a target feature of a drive” (Rajgopal [0021] the SET Feature would be used to modify the feature to be disabled)
“In another example, the device 125 may include an indication of a queue pair, a dedicated work queue, a shared work queue, a work command, etc., associated with a DHI” (Koufaty [0067] shared work queue is the vendor specific feature)
Regarding Claim 20, Rajgopal and Koufaty further discloses wherein the command is configured to enable the SWQ.
“The “SET Feature” command (that writes EFh to a command register) is a mechanism to modify settings of a target feature of a drive, and the “GET Feature” command (that writes EEh to a command register) is a mechanism used to determine the current settings of a target feature of a drive” (Rajgopal [0021] the SET Feature would be used to modify the feature to be enable)
“In another example, the device 125 may include an indication of a queue pair, a dedicated work queue, a shared work queue, a work command, etc., associated with a DHI” (Koufaty [0067] shared work queue is the vendor specific feature)
Claims 21-24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rajgopal (published March 04, 2021) and Koufaty (published December 02, 2021) as applied to claim 20 above, and further in view of Sankaran (published November 14, 2019).
Regarding Claim 21, the combination of Rajgopal and Koufaty disclosed the system of claim 20, but does not explicitly state wherein the controller is further configured to receive, from the memory sub-system in reply to the command, an indication that enablement of the SWQ failed.
Rajgopal, Koufaty, and Sankaran discloses wherein the controller is further configured to receive, from the memory sub-system in reply to the command, an indication that enablement of the SWQ failed.
“the I/O expander 113 is configured to support SET Feature and GET Feature commands, including the SET Feature and GET Feature commands issued with the Feature Addresses listed in Table 2 below … TABLE 2 Feature Address Description … 80h-FFh Vendor Specific” (Rajgopal [0026] the SET Feature command would be used to configure the device)
“In another example, the device 125 may include an indication of a queue pair, a dedicated work queue, a shared work queue, a work command, etc., associated with a DHI” (Koufaty [0067] shared work queue is the vendor specific feature to be configured)
“If any of these checks fail, the WQ is not enabled and the error code is recorded in the WQ Error Code field of the WQ Config register 3500. These checks may be performed in any order. Thus an indication of one type of error does not imply that there are not also other errors. The same configuration errors may result in different error codes at different times or with different versions of the device. If none of the checks fail, the device is enabled and the WQ Enabled field is set to 1” (Sankaran [0584] the checking of the work queue in paragraphs [0578-0583] would be performed before the indication for support of a shared work queue in DHI of Koufaty would be returned and if the checking fails the reply would be the WQ error code)
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the error code for work queue disclosed in Sankaran with the system in combination of Rajgopal and Koufaty. The motivation for doing so would be for more efficient memory accesses by know if the work queues are unsupported and would not be used commands that require that feature.
Regarding Claim 22, Sankanran further discloses wherein the failure is due to the memory sub-system not supporting use of an address space identifier.
“One implementation of the DSA performs the following checks at the time the Enable bit in the Device Enable register is set to 1: Bus Master Enable is 1. The combination of PASID, ATS, and PRS capabilities is valid. (See Table 6-3 in section 6.1.3.) The sum of the WQ Size fields of all the WQCFG registers is not greater than Total WQ Size. For each GRPCFG register, the WQs and Engines fields are either both 0 or both non-zero. Each WQ for which the Size field in the WQCFG register is non-zero is in one group. Each WQ for which the Size field in the WQCFG register is zero is not in any group. Each engine is in no more than one group” (Sankaran [0569-0576])
“If any of these checks fail, the device is not enabled and the error code is recorded in the Error Code field of the Device Enable register. These checks may be performed in any order. Thus an indication of one type of error does not imply that there are not also other errors. The same configuration errors may result in different error codes at different times or with different versions of the device. If none of the checks fail, the device is enabled and the Enabled field is set to 1” (Sankaran [0577] if the system does not support PASID, the PASID would not be valid and the check would fail resulting in an error code)
Regarding Claim 23, the combination of Rajgopal and Koufaty disclosed the system of claim 20, but does not explicitly state wherein the command indicates that the memory sub-system is to ignore any address space identifier provided in commands sent to the SWQ.
Sankaran discloses wherein the command indicates that the memory sub-system is to ignore any address space identifier provided in commands sent to the SWQ.
“Use of Batch descriptors allows DSA clients to submit multiple work descriptors using a single ENQCMD, ENQCMDS, or MOVDIR64B instruction and can potentially improve overall throughput” (Sankaran [0545])
“The PASID 3803 and the U/S flag of the Batch descriptor are used for all descriptors in the batch. The PASID and U/S fields 3810 in the descriptors in the batch are ignored. Each work descriptor in the batch can specify a completion record address 3804, just as with directly submitted work descriptors” (Sankaran [0547] see Fig. 38 the PASID in field 3810 is ignored)
Regarding Claim 24, the combination of Rajgopal and Koufaty disclosed the system of claim 20, but does not explicitly state wherein the command indicates that the memory sub-system is to use any address space identifier provided in commands sent to the SWQ.
Sankaran discloses wherein the command indicates that the memory sub-system is to use any address space identifier provided in commands sent to the SWQ.
“Use of Batch descriptors allows DSA clients to submit multiple work descriptors using a single ENQCMD, ENQCMDS, or MOVDIR64B instruction and can potentially improve overall throughput” (Sankaran [0545])
“The PASID 3803 and the U/S flag of the Batch descriptor are used for all descriptors in the batch. The PASID and U/S fields 3810 in the descriptors in the batch are ignored. Each work descriptor in the batch can specify a completion record address 3804, just as with directly submitted work descriptors” (Sankaran [0547] see Fig. 38 the PASID 3803 used for the batch)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
KUMAR et al. (US 2019/0370050) discloses input/output devices using shared work queues
TIAN et al. (US 2021/0004334) discloses shared work queue as a type of submission node
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