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 .
Information Disclosure Statement
As required by M.P.E.P. ' 609 (C), the applicant's submission of the Information Disclosure Statement dated January 17th, 2025, is acknowledged by the examiner and the cited references have been considered in the examination of the claims now pending. As required by M.P.E.P. ' 609 C(2), a copy of the PTOL-1449 initialed and dated by the examiner is attached to the instant office action.
Claim Interpretation
The examiner has considered a Double Patenting rejection, however even though the claims of the parent patent appear to be close to the present application, the present claims provide a different scope and different limitations that vary to such a degree as to prevent the examiner from making a rational Double Patenting rejection.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claims 21-25, 30-35 and 40 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Kumar et al. [US2021/0349840]. Kumar teaches system, apparatus and methods for handling consistent memory transactions according to a CXL protocol.
Regarding claim 21, Kumar teaches a memory device [Kumar figure 1, feature 100] comprising:
a checker module configured to receive a first command and a first request type [Kumar abstract “…The interface may receive a consistent memory request having a type indicator to indicate a type of consistency to be applied to the consistent memory request.…”], receive a second command and a second request type [Kumar paragraph 0028, last lines “…first storage 210 is configured as a consistent request queue having a plurality of entries 212.sub.0-n, each having multiple fields to store information associated with a particular consistent memory transaction…”(Where the plurality of entries in the request queue would imply that a second command having a second type can be received and placed in the queue…”] from a host [Kumar paragraph 0026, middle lines “…may schedule for execution consistent requests from platforms 110…”] using a first CXL protocol [Kumar paragraph 0045, all lines “…coherent accelerator devices and/or smart adapter devices to couple to CPUs 510 by way of potentially multiple communication protocols, a plurality of interconnects 530a1-b2 may be present. In an embodiment, each interconnect 530 may be a given instance of a CXL...” and paragraph 0013, first lines “…multiple specific communication protocols (including CXL.memory, CXL.cache memory and CXL.io)…”], and determine a first priority of the first command and a first priority of the second command based on the first request type and the second request type, respectively, or a command source of the first command and the second command [Kumar paragraph 0029, most lines “…each entry 212 includes an identifier field 214 to store an identifier of the consistent request, which may be in the form of a unique identifier. Each entry 212 further includes a priority field 216 to store a priority indication, which may be one of multiple levels, e.g., low, medium and high in one embodiment. A consistency type field 218 may store a type of consistency, such as one of the consistency types shown above in Table 1. Finally, each entry 212 may have a request field 219 to store request information…” and figure 2, feature 214, 216, 218, 219 for 2120-212n];
an accelerator [Kumar figure 5, features 550a/550b] configured to transmit a first signal including an address and additional data for a first function of the accelerator to the checker module [Kumar paragraph 0012, first lines “…CXL-connected devices such as central processing units (CPUs), accelerators or so forth can issue consistent memory (e.g., read and write) transactions according to an instruction set architecture (ISA)…”(The examiner has determined the read and write would be a signal and it’s implied that a read and write would have to carry the addresses for the commands as well as the data for the commands, thus reading on the limitations.)];
a command generator configured to generate an internal command for memory operation based on the first command, the second command, and the address [Kumar paragraph 0023, middle lines “…hub 120 may be configured to receive incoming memory transactions, which in some cases may take the form of CXL.memory transactions. Furthermore, when a request is a consistent memory request according to the CXL.memory protocol, hub 120 may handle the request with an appropriate level of consistency…” and paragraph 0039, middle lines “…a consistent memory write transaction may be implemented as an ISA instruction having the general form of STORE_COND <address>, where one of multiple different consistency operations can be performed based on a value written in a predetermined register…”(Where the transactions read on the generated internal commands.)];
a memory controller [Kumar paragraph 0024, middle lines “…request scheduler 128 may be implemented as a hardware circuit, e.g., as a microcontroller or other programmable processing circuit to perform scheduling of memory requests including consistent memory transactions according to a CXL.memory protocol…”] configured to schedule the internal command in a command queue based on the first priority of the first command the first priority of the second command [Kumar abstract, last lines “…A request scheduler coupled to the interface may receive the consistent memory request and schedule it for execution according to the type of consistency, based at least in part on a priority of the consistent memory request and one or more pending consistent memory requests…”]; and
a memory [Kumar paragraph 0021, middle lines “…Pooled memories 130.sub.0,1 may include corresponding dual inline memory modules (DIMMs) or memory drives, which may be the targets of at least certain memory requests, including consistent memory transactions as described herein…”] configured to operate based on the command queue [Kumar paragraph 0025, middle lines “…hub 120 also includes a consistent request queue 124. Queue 124 may be a given storage having entries to store information associated with consistent memory requests, namely pending consistent transactions…”].
Regarding claim 22, as per claim 21, Kumar teaches the checker module is configured to determine the first priority of the second command to be higher than the first priority of the first command based on the command source of the first command and the second command [Kuman paragraph 0029, middle lines “…Each entry 212 further includes a priority field 216 to store a priority indication, which may be one of multiple levels, e.g., low, medium and high in one embodiment…” and paragraph 0033, first lines “…Instead if the transaction is not to be directly executed, such as where the consistent memory transaction is of a lower priority and/or a lower level consistency, control passes to diamond 340 to later determine whether the transaction is selected for execution…”(Where the directly executed has a higher priority if the other priority is considered to be low and thus reads on the claim.)].
Regarding claim 23, as per claim 21, Kumar teaches the first command corresponds to the address [Kumar paragraph 0039, middle lines “…a consistent memory write transaction may be implemented as an ISA instruction having the general form of STORE_COND <address>, where one of multiple different consistency operations can be performed based on a value written in a predetermined register…” and paragraph 0012, first lines “…CXL-connected devices such as central processing units (CPUs), accelerators or so forth can issue consistent memory (e.g., read and write) transactions according to an instruction set architecture (ISA)…”(The examiner has determined the read and write would be a signal and it’s implied that a read and write would have to carry the addresses for the commands as well as the data for the commands, thus reading on the limitations.)] .
Regarding claim 24, as per claim 21, Kumar teaches the first request type and the second request type are substantially the same [Kumar paragraph 0012, first lines “…CXL-connected devices such as central processing units (CPUs), accelerators or so forth can issue consistent memory (e.g., read and write) transactions…” and paragraph 0022, middle lines “…an application 115.sub.0 may issue memory requests such as read or write requests…”(When giving the word type it’s BRI, both request types mention having similar read and write request types.)].
Regarding claim 25, as per claim 21, the checker module is configured to determine the first priority of the second command to be higher than the first priority of the first command based on the first request type and the second request type [Kuman paragraph 0029, middle lines “…Each entry 212 further includes a priority field 216 to store a priority indication, which may be one of multiple levels, e.g., low, medium and high in one embodiment…” and paragraph 0033, first lines “…Instead if the transaction is not to be directly executed, such as where the consistent memory transaction is of a lower priority and/or a lower level consistency, control passes to diamond 340 to later determine whether the transaction is selected for execution…”(Where the directly executed has a higher priority if the other priority is considered to be low and thus reads on the claim.)]..
Regarding claims 30 and 40, Kumar teaches a memory device [Kumar figure 1, feature 100] comprising:
an accelerator [Kumar figure 5, features 550a/550b] configured to transmit a first signal including an additional data and an address [Kumar paragraph 0012, first lines “…CXL-connected devices such as central processing units (CPUs), accelerators or so forth can issue consistent memory (e.g., read and write) transactions according to an instruction set architecture (ISA)…”(The examiner has determined the read and write would be a signal and it’s implied that a read and write would have to carry the addresses for the commands as well as the data for the commands, thus reading on the limitations.)];
a controller [Kumar paragraph 0024, middle lines “…request scheduler 128 may be implemented as a hardware circuit, e.g., as a microcontroller or other programmable processing circuit to perform scheduling of memory requests including consistent memory transactions according to a CXL.memory protocol…”] configured to receive the first signal, receive a plurality of commands and a plurality of request types [Kumar paragraph 0029, most lines “…each entry 212 includes an identifier field 214 to store an identifier of the consistent request, which may be in the form of a unique identifier. Each entry 212 further includes a priority field 216 to store a priority indication, which may be one of multiple levels, e.g., low, medium and high in one embodiment. A consistency type field 218 may store a type of consistency, such as one of the consistency types shown above in Table 1. Finally, each entry 212 may have a request field 219 to store request information…”] from a host [Kumar paragraph 0026, middle lines “…may schedule for execution consistent requests from platforms 110…”] using a first protocol among a plurality of CXL protocols [Kumar paragraph 0045, all lines “…coherent accelerator devices and/or smart adapter devices to couple to CPUs 510 by way of potentially multiple communication protocols, a plurality of interconnects 530a1-b2 may be present. In an embodiment, each interconnect 530 may be a given instance of a CXL...” and paragraph 0013, first lines “…multiple specific communication protocols (including CXL.memory, CXL.cache memory and CXL.io)…”], generate an internal command for memory operation based on the plurality of commands and the address [Kumar paragraph 0023, middle lines “…hub 120 may be configured to receive incoming memory transactions, which in some cases may take the form of CXL.memory transactions. Furthermore, when a request is a consistent memory request according to the CXL.memory protocol, hub 120 may handle the request with an appropriate level of consistency…” and paragraph 0039, middle lines “…a consistent memory write transaction may be implemented as an ISA instruction having the general form of STORE_COND <address>, where one of multiple different consistency operations can be performed based on a value written in a predetermined register…”(Where the transactions read on the generated internal commands.)], and generate a command queue by scheduling the internal command based on the plurality of request types [Kumar abstract, last lines “…A request scheduler coupled to the interface may receive the consistent memory request and schedule it for execution according to the type of consistency, based at least in part on a priority of the consistent memory request and one or more pending consistent memory requests…”]; and
a memory [Kumar paragraph 0021, middle lines “…Pooled memories 130.sub.0,1 may include corresponding dual inline memory modules (DIMMs) or memory drives, which may be the targets of at least certain memory requests, including consistent memory transactions as described herein…”] configured to operate based on the command queue [Kumar paragraph 0025, middle lines “…hub 120 also includes a consistent request queue 124. Queue 124 may be a given storage having entries to store information associated with consistent memory requests, namely pending consistent transactions…”].
Regarding claim 31, as per claim 30, Kumar teaches the controller is further configured to receive a first command corresponding to the accelerator [Kumar paragraph 0012, first lines “…CXL-connected devices such as central processing units (CPUs), accelerators or so forth can issue consistent memory (e.g., read and write) transactions…”] and receive a second command among the plurality of commands corresponding to the memory from the host [Kumar paragraph 0022, middle lines “…an application 115.sub.0 may issue memory requests such as read or write requests…”].
Regarding claim 32, as per claim 30, Kumar teaches the controller is configured to determine a priority of the second command to be higher than a priority of the first command [Kuman paragraph 0029, middle lines “…Each entry 212 further includes a priority field 216 to store a priority indication, which may be one of multiple levels, e.g., low, medium and high in one embodiment…” and paragraph 0033, first lines “…Instead if the transaction is not to be directly executed, such as where the consistent memory transaction is of a lower priority and/or a lower level consistency, control passes to diamond 340 to later determine whether the transaction is selected for execution…”(Where the directly executed has a higher priority if the other priority is considered to be low and thus reads on the claim.)].
Regarding claim 33, as per claim 30, Kumar teaches the controller is further configured to receive a first request type corresponding to the accelerator [Kumar paragraph 0012, first lines “…CXL-connected devices such as central processing units (CPUs), accelerators or so forth can issue consistent memory (e.g., read and write) transactions…”] and receive a second request type among the plurality of request types corresponding to the memory from the host [Kumar paragraph 0022, middle lines “…an application 115.sub.0 may issue memory requests such as read or write requests…”].
Regarding claim 34, as per claim 30, Kumar teaches the controller is further configured to receive a first command corresponding to the first request type and receive a second command among the plurality of commands corresponding to the second request type and determine a priority of the second command to be higher than a priority of the first command [Kumar paragraph 0029, most lines “…each entry 212 includes an identifier field 214 to store an identifier of the consistent request, which may be in the form of a unique identifier. Each entry 212 further includes a priority field 216 to store a priority indication, which may be one of multiple levels, e.g., low, medium and high in one embodiment. A consistency type field 218 may store a type of consistency, such as one of the consistency types shown above in Table 1. Finally, each entry 212 may have a request field 219 to store request information…”].
Regarding claim 35, as per claim 30, Kumar teaches the first request type and the second request type are substantially the same [Kumar paragraph 0012, first lines “…CXL-connected devices such as central processing units (CPUs), accelerators or so forth can issue consistent memory (e.g., read and write) transactions…” and paragraph 0022, middle lines “…an application 115.sub.0 may issue memory requests such as read or write requests…”(When giving the word type it’s BRI, both request types mention having similar read and write request types.)].
Allowable Subject Matter
Claims 26-29 and 36-39 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Horwich et al. [US2021/0374080] Horwich teaches CXL protocol with different priorities.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ERIC CARDWELL whose telephone number is (571)270-1379. The examiner can normally be reached on Monday - Friday 10-6pm 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, Reginald Bragdon can be reached on (571) 272-4204. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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 http://pair-direct.uspto.gov. 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.
/ERIC CARDWELL/Primary Examiner, Art Unit 2139