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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/26/2025 has been entered.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 8, and 15 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Likewise claims 5-7, 9, 12, 16-18, and 21-29 are rejected under 112(b) at least by their dependency on claims 1, 8 and 15.
Examiner notes that Applicant’s disclosure does not appear to include language which can be readily mapped to the claimed features. For example, the disclosure does not appear to include the term “data structure” of claims 1, 8, and 15. Paragraphs 39 and 46 mention the term “structure”, but do not seem to be referring to the same “data structure” as the claims. Examiner recommends replacing the term “data structure” with “vulnerability correlation map,” if that is the intended meaning.
Examiner reminds Applicant that claim language should be consistent with Applicant’s original disclosure. (see 37 CFR 1.75 (a), (d) (1) The claim or claims must conform to the invention as set forth in the remainder of the specification and the terms and phrases used in the claims must find clear support or antecedent basis in the description so that the meaning of the terms in the claims may be ascertainable by reference to the description).
Claim Objections
Claim 29 is objected to because of the following informalities: claim 29 reads “…maintaining the updated data structure at each of the error correction code engine and the at least one other error correction code engine.” But should read: “… maintaining the updated data structure at the error correction code engine and the at least one other error correction code engine.” Appropriate correction is required.
Claim Rejections - 35 USC § 103
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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1, 5-9, 12, 15, 16, 23-27, and 29 are rejected under 35 U.S.C. 103 as being unpatentable over Russell (US Publication No. 2018/0052615) in view of Freking (US Publication No. 2009/0132876).
Regarding claim 1, Russell discloses a system comprising:
a stacked memory [Fig. 1, stacked die system 10];
and a plurality of error correction engines to detect vulnerabilities in the stacked memory [fig. 1, memory controllers (MCs) 22, 32, and 42; fig. 2, memory controller contains error detection and correction logic 130, meaning that the memory controllers are error correction engines that can detect vulnerabilities using error detection and correction logic],
coordinate vulnerabilities detected across tiers of the stacked memory [Fig. 3: an error (vulnerability) is detected in operation 154 (“bit error detected?”), information about the error is transmitted to another tier the stacked memory in operation 162 (“send bit error indication and location to stacked dies above and below current die level”).], …
and correct the at least one of the vulnerabilities [Fig. 3: correct bit error in operation 158.]
However, Russell does not explicitly disclose wherein:
[errors are coordinated across stacked memory] using a data structure that is maintained and updated by the plurality of error correction code engines
In the analogous art of error correction, Freking teaches:
[vulnerabilities are coordinated across stacked memory] using a data structure that is maintained and updated by the plurality of error correction code engines [Fig. 2: error logging unit 104 contained within a memory controller 106. Fig. 4: operation 182, receive error message -> operation 187, increment error count for rank and chip id element in error counter bank].
Freking teaches an error logging unit within a memory controller, that in response to any detected error, will update the error counter bank (data structure). Therefore, one of ordinary skill in the art would find it obvious to incorporate the error logging unit in each of the memory controllers described by Russell, such that when a memory controller detects an error (or receives communication indicating a detected error), the error logging unit would update. Errors are then effectively coordinated between memory controllers by communicating information about an error (as taught by Russell), and information about those errors is maintained in a data structure (as taught by Freking). Also the data structure is maintained and updated by both memory controllers in response to an error being detected by either controller.
It would have been obvious to one of ordinary skill in the art, having the teachings of Russell and Freking before them, before the effective filing date of the claimed invention to incorporate the error logging unit (taught by Freking) into the system for coordinated error detection (taught by Russell), to allow for benefits such as: quicker detection of errors in memory chips or ranks (Freking, para. 4).
Regarding claim 5, the combination of Russell and Freking discloses the system of claim 1. Russell further discloses:
wherein error correction code engines disposed on different tiers of the stacked memory are communicably coupled [Fig. 1, memory controllers (error correction code engines) 22, 32, 42 are disposed on different dies (tiers) 14, 16, 18 of stacked memory 10. Each memory controller is able to communicate with the other memory controllers of system 10 (paragraph 0012, lines 11-12).]
And add bits to data stored in the stacked memory that are based on the original bits of the data. [For a write operation the received write data is provided by MC 32 to error detection and correction logic 130 which determines ECC bits for the write data. The write data and the ECC bits are provided to memory device 34 as Din0-DinN in which a first portion of the N+1 bits is the write data and a remaining portion of the N+1 bits is the ECC value (para. 17). It is well understood in the art that error correction bits are determined based off of the data they are encoding.]
Regarding claim 6, the combination of Russell and Freking discloses the system of claim 5. Russell further discloses:
wherein the coordination of the vulnerabilities includes a first error correction code engine communicating with a second error correction code engine. [Bit error (vulnerability) information is coordinated by a first memory controller (error correction code engine) detecting an error and communicating information about that error to at least one other memory controller (paragraph 22, lines 1-8).]
Regarding claim 7, the combination of Russell and Freking discloses the system of claim 1. Russell further discloses:
wherein at least one engine of the plurality of error correction code engines is disposed between tiers of the stacked memory. [Fig. 1, observe that memory controller 32 (error correction code engine) is disposed between dies (tiers) 14 and 18 of stacked memory 10.]
Regarding claim 8, Russell discloses a method comprising: detecting, by an error correction code engine within a stacked memory, a vulnerability in a tier of the stacked memory [Fig. 1, memory controllers 22, 32, and 42 are within stacked memory 10; fig. 2, memory controller contains error detection and correction logic 130, making it an error correction code engine; error detection and correction logic 130 uses the ECC portion of the sensed data to determine if an error exists in the data portion of the sensed data (paragraph 21, lines 3-5).]
coordinating the vulnerability with at least one other error correction code engine in at least one other tier of the stacked memory; [Fig. 3: an error (vulnerability) is detected by a memory controller (error correction code engine) in operation 154 (“bit error detected?”) and information about the error is transmitted to a memory controller of at least one other portion of the stacked memory (paragraph 0022, lines 4-8) in operation 162 (“send bit error indication and location to stacked dies above and below current die level”).] …
and correcting the vulnerability [operation 158 (fig. 3) correct bit error.]
However, Russell does not explicitly disclose:
[errors are coordinated across stacked memory] using a data structure that is maintained and updated by the error correction engine and the at least one other error correction code engine
In the analogous art of error correction, Freking teaches:
[errors are coordinated across stacked memory] using a data structure that is maintained and updated by the error correction engine and the at least one other error correction code engine [Fig. 2: error logging unit 104 contained within a memory controller 106. Fig. 4: operation 182, receive error message -> operation 187, increment error count for rank and chip id element in error counter bank].
Freking teaches an error logging unit within a memory controller, that in response to any detected error, will update the error counter bank (data structure). Therefore, one of ordinary skill in the art would find it obvious to incorporate the error logging unit in each of the memory controllers described by Russell, such that when a memory controller detects an error (or receives communication indicating a detected error), the error logging unit would update. Errors are then effectively coordinated between memory controllers by communicating information about an error (as taught by Russell), and information about those errors is maintained in a data structure (as taught by Freking). Also the data structure is maintained and updated by both memory controllers in response to an error being detected by either controller.
It would have been obvious to one of ordinary skill in the art, having the teachings of Russell and Freking before them, before the effective filing date of the claimed invention to incorporate the error logging unit (taught by Freking) into the system for coordinated error detection (taught by Russell), to allow for benefits such as: quicker detection of errors in memory chips or ranks (Freking, para. 4).
Regarding claim 9, the combination of Russell and Freking discloses the method of claim 8. Claim 9 recites limitations similar to those presented in claim 5, and is rejected accordingly.
Regarding claim 12, the combination of Russell and Freking discloses the system of claim 8. Russell further discloses:
wherein the tier of the stacked memory and the at least one other tier of the stacked memory correspond to different memory dies. [Fig. 3, observe that the data read is in a first stacked die (operation 152: read memory location in stacked die), an error is detected within that first die (operation 154: bit error detected?), and the vulnerability is coordinated to a different die than the first one (operation 162: send bit error indication and location to stacked dies above and below current die level).]
Regarding claim 15, Russell discloses a system comprising: a stacked memory comprising a plurality of dies [fig. 1, stacked memory 10 comprising dies 14, 16, and 18];
a first error correction code engine associated with a first die of the plurality of dies [fig. 1, memory controller 22 associated with first die 18]; and a second error correction code engine associated with a second die of the plurality of dies [Fig. 1, memory controller 32 associated with second die 16. These memory controllers are error correction code engines because they contain error detection and correction logic 130 (fig. 2).],
wherein the first error correction code engine and the second error correction code engine are configured to coordinate at least one vulnerability detected for at least one of the first die or the second die of the plurality of dies [Fig. 3: an error (vulnerability) is detected within the first die by a first memory controller (error correction code engine) in operation 154 (“bit error detected?”) and information about the error is transmitted to a memory controller of at least one other portion of the stacked memory (paragraph 0022, lines 4-8) in operation 162 (“send bit error indication and location to stacked dies above and below current die level”).]
In the analogous art of error correction, Freking teaches:
[errors are coordinated across stacked memory] using a data structure that is maintained and updated by both of the first error correction engine and the second error correction code engine [Fig. 2: error logging unit 104 contained within a memory controller 106. Fig. 4: operation 182, receive error message -> operation 187, increment error count for rank and chip id element in error counter bank].
Freking teaches an error logging unit within a memory controller, that in response to any detected error, will update the error counter bank (data structure). Therefore, one of ordinary skill in the art would find it obvious to incorporate the error logging unit in each of the memory controllers described by Russell, such that when a memory controller detects an error (or receives communication indicating a detected error), the error logging unit would update. Errors are then effectively coordinated between memory controllers by communicating information about an error (as taught by Russell), and information about those errors is maintained in a data structure (as taught by Freking). Also the data structure is maintained and updated by both memory controllers in response to an error being detected by either controller.
It would have been obvious to one of ordinary skill in the art, having the teachings of Russell and Freking before them, before the effective filing date of the claimed invention to incorporate the error logging unit (taught by Freking) into the system for coordinated error detection (taught by Russell), to allow for benefits such as: quicker detection of errors in memory chips or ranks (Freking, para. 4).
Regarding claim 16, the combination of Russell and Freking discloses the system of claim 15. Russel further teaches:
wherein the first error correction code engine is configured to detect a vulnerability associated with the first die of the plurality of dies. [Memory controllers contain error detection and correction logic 130 (fig. 2). Because the first memory controller (MC 22, fig. 1) (first error correction engine) is disposed on the first die (die 18, fig. 1), it is configured to detect a vulnerability (using error detection and correction logic 130) associated with the first die of the plurality of dies (dies 18, 16, and 14 of stacked memory 10, fig. 1).]
Regarding claim 23, the combination of Russell and Freking teaches the system of claim 1. Russell further teaches:
Wherein the tiers of the stacked memory include respective monitors configured to monitor conditions of the stacked memory, and at least one error correction code engine of the plurality of error correction code engines generates the [error indication] based on the monitored conditions. [Fig. 3: Memory controllers (error correction engines) detect bit errors in step 154 (monitoring conditions). In response to a bit error being detected, the error correction code engine sends bit error indication and location to stacked dies above and below current die level (step 162).]
Freking teaches:
[in response to an error indication] generates the data structure [Fig. 2: error logging unit 104 contained within a memory controller 106. Fig. 4: operation 182, receive error message -> operation 187, increment error count for rank and chip id element in error counter bank].
It would have been obvious to one of ordinary skill in the art, having the teachings of Russell and Freking before them, before the effective filing date of the claimed invention to incorporate the error logging unit (taught by Freking) into the system for coordinated error detection (taught by Russell), to allow for benefits such as: quicker detection of errors in memory chips or ranks (Freking, para. 4).
Regarding claim 24, the combination of Russell and Freking teaches the system of claim 1. Freking further teaches:
Wherein the data structure comprises an [location of an error]. [Fig. 5, error location list 160].
Russell teaches:
[a location of an error can be used as] a vulnerability correlation map that correlates the vulnerabilities horizontally and vertically through the stacked memory [fig. 1: scrub region 58 shows how an error location (38) is correlated horizontally and vertically.]
It would have been obvious to one of ordinary skill in the art, having the teachings of Russell and Freking before them, before the effective filing date of the claimed invention to incorporate the error logging unit (taught by Freking) into the system for coordinated error detection (taught by Russell), to allow for benefits such as: quicker detection of errors in memory chips or ranks (Freking, para. 4).
Regarding claim 25, the combination of Russell and Freking teaches the system of claim 1. Freking further teaches:
Wherein the data structure comprises an [location of an error]. [Fig. 5, error location list 160].
Russell teaches:
[a location of an error can be used as] a vulnerability correlation map that relates bits associated with the vulnerabilities to other bits across the tiers of the stacked memory [fig. 1: scrub region 58 shows how an error location (38) is correlated to bits on other tiers.]
It would have been obvious to one of ordinary skill in the art, having the teachings of Russell and Freking before them, before the effective filing date of the claimed invention to incorporate the error logging unit (taught by Freking) into the system for coordinated error detection (taught by Russell), to allow for benefits such as: quicker detection of errors in memory chips or ranks (Freking, para. 4).
Regarding claim 26, the combination of Russell and Freking teaches the system of claim 1. Freking further teaches:
Wherein the data structure comprises [locations of errors]. [Fig. 5, error location list 160].
Russell teaches:
[a location of an error can be used as] a vulnerability correlation map [fig. 1: scrub region 58 shows how an error location (38) is correlated horizontally and vertically.]
Freking teaches an error logging unit within a memory controller, that in response to any detected error, will update the error counter bank (data structure). Therefore, one of ordinary skill in the art would find it obvious to incorporate the error logging unit in each of the memory controllers described by Russell, such that when a memory controller detects an error (or receives communication indicating a detected error), the error logging unit would update. This means that the data structure would contain errors detected by memory controllers from multiple different tiers of memory.
It would have been obvious to one of ordinary skill in the art, having the teachings of Russell and Freking before them, before the effective filing date of the claimed invention to incorporate the error logging unit (taught by Freking) into the system for coordinated error detection (taught by Russell), to allow for benefits such as: quicker detection of errors in memory chips or ranks (Freking, para. 4).
Regarding claim 27, the combination of Russell and Freking teaches the method of claim 8. Freking further teaches:
Updating the data structure at the error correction code engine responsive to detecting the vulnerability. [Fig. 2: error logging unit 104 contained within a memory controller 106. Fig. 4: operation 182, receive error message -> operation 187, increment error count for rank and chip id element in error counter bank].
It would have been obvious to one of ordinary skill in the art, having the teachings of Russell and Freking before them, before the effective filing date of the claimed invention to incorporate the error logging unit (taught by Freking) into the system for coordinated error detection (taught by Russell), to allow for benefits such as: quicker detection of errors in memory chips or ranks (Freking, para. 4).
Regarding claim 29, the combination of Russell and Freking teaches the method of claim 27. The combination of Russell and Freking teaches:
Maintaining the updated data structure at each of the error correction code engine and the at least one other error correction code engine.
Freking teaches an error logging unit within a memory controller, that in response to any detected error, will update the error counter bank (data structure). Therefore, one of ordinary skill in the art would find it obvious to incorporate the error logging unit in each of the memory controllers described by Russell, such that when a memory controller detects an error (or receives communication indicating a detected error), the error logging unit would update. Errors are then effectively coordinated between memory controllers by communicating information about an error (as taught by Russell), and information about those errors is maintained in a data structure (as taught by Freking). The data structure would be maintained and updated by both memory controllers in response to an error being detected by either controller.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Russell (US Publication No. 2018/0052615) in view of Freking (US Publication No. 2009/0132876) and Morita (US Publication No. 2010/0194718).
Regarding claim 21, the combination of Russell and Freking discloses the system of claim 1. Russell further teaches:
Wherein the plurality of error correction code engines includes an error correction code engine arranged at a bottom tier of the stacked memory that is between another tier of the stacked memory and a processor [fig. 1, memory controller 42 is considered to be an error correction engine and is arranged at a bottom a bottom tier of the stacked memory and is in between another tier (tier 16) and a processor (CPU 52).]
And the error correction code engine at the bottom tier is configured to detect the [errors] in the bottom tier [fig. 3, operation 154: bit error detected?].
However, the combination of Russell and Freking does not explicitly disclose wherein:
[the errors are] voltage variations or temperature variations.
In the analogous art of error correction, Morita teaches:
[the errors are] voltage variations or temperature variations. [a circuit that detects variations (deviations, errors) in output voltages… in real time (para. 232)]
It would have been obvious to one of ordinary skill in the art, having the teachings of Russell, Freking, and Morita before them, before the effective filing date of the claimed invention to incorporate the error detection engine detecting voltage variation errors (taught by Morita) into each memory controller in the system for coordinated error detection (taught by Russell), to allow for benefits such as: detecting and correcting voltage errors in real time, instead of retroactively (Morita, para 232).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACK K BARNETT whose telephone number is (571)270-0431. The examiner can normally be reached M-Th 8-5, F 8-4 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, Mark Featherstone can be reached at 571-270-3750. 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.
/JACK KENSINGTON BARNETT/Examiner, Art Unit 2111
/MARK D FEATHERSTONE/Supervisory Patent Examiner, Art Unit 2111