DETAILED ACTION
This action is in response to the application filed on 1/5/2024.
Claims 1-20 are pending in this application.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claims 2-7 and 12-20 are objected to because of the following informalities:
Claim 2, lines 2-3, “a” before “default” and “lower” should be --the--, respectively. Claim 4 has a similar issue.
Claim 3, line 4, --the-- should be inserted before “adjusted”
Claim 5 “single-level cell” should be --a single-level cell--. Claims 12 and 16 have a similar issue.
Claim 16, line 3, before “to”, insert --configured--.
Claim 19:
at line 4, “that adjusted size” should be --that the adjusted size--.
At lines 5-6, “a default bit density” should be --the default bit density--.
Dependent claims 4, 6, 7, 13-15, 18 and 20 do not overcome the deficiency of the base
claim and, therefore, are objected for the same reasons as the base claims.
Appropriate correction is required.
Claim Interpretation
5. The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
6. The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
7. This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “processing device” in claim 16.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 103
8. 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.
9. Claims 1, 8, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Narasimhan et al. (US Patent Application Publication 2020/0356357 A1) in view of Heller et al. (US Patent Application Publication 2016/0335001 A1).
As to claim 1, Narasimhan teaches a method comprising:
receiving a size of an update file from a host using wireless communication (see e.g. Figs.3 and 5C and associated text, e.g. [0045]- an operating system of an information handling system may receive a firmware update via a wireless connection and [0048]- Firmware update location information may, for example, include a logical block address for the firmware update, a cylinder head sector for the firmware update, a device path to the memory on which the firmware update is stored, such as a device path of a hard drive, one or more non-uniform memory access (NUMA) nodes at which the firmware update is stored, a size of the firmware update),
selecting an amount of memory for the update file based on the size to reallocate (see e.g. [0046]- a memory may be selected for storage of the firmware update. For example, an OS of the information handling system may select a memory for storage of the firmware update, [0047]-If a system memory is selected, an OS firmware update driver may request an allocation of memory for storage from an OS memory manager and may store the firmware update in the allocated memory, and [0057]- the OS may determine whether storage of a firmware update on a system memory, such as a system main memory, across one or more reboots is supported. The OS may further determine whether there is sufficient space available on the system memory to store the firmware update; if, at step 514, a determination is made that storage of the firmware update on the system memory is supported, the OS may, at step 516, obtain a memory allocation of one or more portions of the system memory, such as one or more NUMA nodes, for storage of the firmware update from an OS memory manager) and programming the update file using the memory reallocated (see e.g. [0057]- At step 518, the OS may store the firmware update in the allocated memory and may update location information for the firmware update in a firmware memory).
Narasimhan does not specifically teach selecting the amount of memory to reallocate from a default bit density to a lower bit density than the default bit density or using the memory reallocated to the lower bit density.
In an analogous art of allocating memory, however, Heller teaches selecting an amount of memory to reallocate from a default bit density (e.g. TLC) to a lower bit density than the default bit density (e.g. MLC or SLC) and using the memory reallocated to the lower bit density (see e.g. [0025]- SLC may typically be programmed at 100 MB/sec, MLC at 60 MB/sec, and TLC at 30 MB/sec. In this regard, the storage device may analyze the data stream for the bandwidth, and determine, based on the bandwidth, whether to use the TLC blocks as SLC blocks or as MLC blocks. For example, in response to determining that the bandwidth for the data stream is 80 MB/sec (one example of throughput), the data storage device may program the TLC blocks as SLC blocks (since SLC blocks can be programmed at 100 MB/sec). As another example, in response to determining that the bandwidth for the data stream is 50 MB/sec, the data storage device may program the TLC blocks as MLC blocks (since MLC blocks can be programmed at 60 MB/sec) and [0028]- in response to determining to write to the section of memory at the bit(s)-per-cell different from the designated bit(s)-per-cell, writing to the section of memory at the bit(s)-per-cell different from the designated bit(s)-per-cell).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Narasimhan to incorporate/implement the limitations as taught by Heller in order to provide a more efficient method/system of configuring memory to store large amounts of data for the purpose of optimizing performance.
As to claim 1, Narasimhan teaches a non-transitory computer-readable storage medium comprising instructions that, when executed by a processing device (see [0016] and [0085]), cause the processing device to:
receiving a size of an update file from a host using wireless communication (see e.g. Figs.3 and 5C and associated text, e.g. [0045]- an operating system of an information handling system may receive a firmware update via a wireless connection and [0048]- Firmware update location information may, for example, include a logical block address for the firmware update, a cylinder head sector for the firmware update, a device path to the memory on which the firmware update is stored, such as a device path of a hard drive, one or more non-uniform memory access (NUMA) nodes at which the firmware update is stored, a size of the firmware update),
select an amount of memory for the update file based on the size to reallocate (see e.g. [0046]- a memory may be selected for storage of the firmware update. For example, an OS of the information handling system may select a memory for storage of the firmware update, [0047]-If a system memory is selected, an OS firmware update driver may request an allocation of memory for storage from an OS memory manager and may store the firmware update in the allocated memory, and [0057]- the OS may determine whether storage of a firmware update on a system memory, such as a system main memory, across one or more reboots is supported. The OS may further determine whether there is sufficient space available on the system memory to store the firmware update; if, at step 514, a determination is made that storage of the firmware update on the system memory is supported, the OS may, at step 516, obtain a memory allocation of one or more portions of the system memory, such as one or more NUMA nodes, for storage of the firmware update from an OS memory manager) and program a first portion of the update file using the memory reallocated (see e.g. [0057]- At step 518, the OS may store the firmware update in the allocated memory and may update location information for the firmware update in a firmware memory).
Narasimhan does not specifically teach selecting the amount of memory to reallocate from a default bit density to a lower bit density than the default bit density or using the memory reallocated to the lower bit density.
In an analogous art of allocating memory, however, Heller teaches selecting an amount of memory to reallocate from a default bit density (e.g. TLC) to a lower bit density than the default bit density (e.g. MLC or SLC) and using the memory reallocated to the lower bit density (see e.g. [0025]- SLC may typically be programmed at 100 MB/sec, MLC at 60 MB/sec, and TLC at 30 MB/sec. In this regard, the storage device may analyze the data stream for the bandwidth, and determine, based on the bandwidth, whether to use the TLC blocks as SLC blocks or as MLC blocks. For example, in response to determining that the bandwidth for the data stream is 80 MB/sec (one example of throughput), the data storage device may program the TLC blocks as SLC blocks (since SLC blocks can be programmed at 100 MB/sec). As another example, in response to determining that the bandwidth for the data stream is 50 MB/sec, the data storage device may program the TLC blocks as MLC blocks (since MLC blocks can be programmed at 60 MB/sec) and [0028]- in response to determining to write to the section of memory at the bit(s)-per-cell different from the designated bit(s)-per-cell, writing to the section of memory at the bit(s)-per-cell different from the designated bit(s)-per-cell).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Narasimhan to incorporate/implement the limitations as taught by Heller in order to provide a more efficient method/system of configuring memory to store large amounts of data for the purpose of optimizing performance.
As to claim 16, Narasimhan teaches a system (see Fig.1 and associated text) comprising: a plurality of memory devices and a processing device, operatively coupled with the plurality of memory devices (see e.g. [0030]-[0035]), to:
receive a size of an update file from a host using wireless communication (see e.g. Figs.3 and 5C and associated text, e.g. [0045]- an operating system of an information handling system may receive a firmware update via a wireless connection and [0048]- Firmware update location information may, for example, include a logical block address for the firmware update, a cylinder head sector for the firmware update, a device path to the memory on which the firmware update is stored, such as a device path of a hard drive, one or more non-uniform memory access (NUMA) nodes at which the firmware update is stored, a size of the firmware update),
select an amount of memory for the update file based on the size to reallocate (see e.g. [0046]- a memory may be selected for storage of the firmware update. For example, an OS of the information handling system may select a memory for storage of the firmware update, [0047]-If a system memory is selected, an OS firmware update driver may request an allocation of memory for storage from an OS memory manager and may store the firmware update in the allocated memory and [0057]- the OS may determine whether storage of a firmware update on a system memory, such as a system main memory, across one or more reboots is supported. The OS may further determine whether there is sufficient space available on the system memory to store the firmware update; if, at step 514, a determination is made that storage of the firmware update on the system memory is supported, the OS may, at step 516, obtain a memory allocation of one or more portions of the system memory, such as one or more NUMA nodes, for storage of the firmware update from an OS memory manager), and
program a first portion of the update file to the memory reallocated (see e.g. [0057]- At step 518, the OS may store the firmware update in the allocated memory and may update location information for the firmware update in a firmware memory).
Narasimhan does not specifically teach selecting the amount of memory to reallocate from a default bit density to a lower bit density than the default bit density or using the memory reallocated to the lower bit density, wherein the default bit density is a triple-level cell, quad-level cell, or octo-level cell to the lower bit density or wherein the lower bit density is single-level cell.
In an analogous art of allocating memory, however, Heller teaches selecting an amount of memory to reallocate from a default bit density (e.g. TLC) to a lower bit density than the default bit density (e.g. MLC or SLC) and using the memory reallocated to the lower bit density (see e.g. [0025]- SLC may typically be programmed at 100 MB/sec, MLC at 60 MB/sec, and TLC at 30 MB/sec. In this regard, the storage device may analyze the data stream for the bandwidth, and determine, based on the bandwidth, whether to use the TLC blocks as SLC blocks or as MLC blocks. For example, in response to determining that the bandwidth for the data stream is 80 MB/sec (one example of throughput), the data storage device may program the TLC blocks as SLC blocks (since SLC blocks can be programmed at 100 MB/sec). As another example, in response to determining that the bandwidth for the data stream is 50 MB/sec, the data storage device may program the TLC blocks as MLC blocks (since MLC blocks can be programmed at 60 MB/sec) and [0028]- in response to determining to write to the section of memory at the bit(s)-per-cell different from the designated bit(s)-per-cell, writing to the section of memory at the bit(s)-per-cell different from the designated bit(s)-per-cell), wherein the default bit density is a triple-level cell, quad-level cell, or octo-level cell and wherein the lower bit density is single-level cell (see e.g. [0015]- a group of memory cells in the storage device may be assigned as single-level cells (SLC), whereby a single bit (logic “0” or logic “1”) is stored in a respective cell. As another example, another group of memory cells in the storage device may be assigned as multiple-level cells (MLC), whereby two bits are stored in a respective cell (e.g., logic “00”, logic “01”, logic “10” and logic “11”). As still another example, a group of memory cells in the storage device may be assigned as triple-level cells (TLC), whereby three bits are stored in a respective cell (e.g., logic “000”, logic “001”, logic “010”, etc.).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Narasimhan to incorporate/implement the limitations as taught by Heller in order to provide a more efficient method/system of configuring memory to store large amounts of data for the purpose of optimizing performance.
Allowable Subject Matter
10. Claims 2-7, 9-15 and 17-20 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
11. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Zhou (US Patent Application Publication 2022/0100406 A1) discloses a hard disk control method and a related device that includes converting a data storage mode of a first sub-area in a first storage area from a first mode to a second mode. Liang et al. (US Patent Application Publication 2020/0401515 A1) discloses systems and methods for adapting garbage collection (GC) operations in a memory device to a pattern of host accessing the device.
12. Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHENECA SMITH whose telephone number is (571)270-1651. The examiner can normally be reached Mon-Fri 8:00AM-4:30PM 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, Hyung S Sough can be reached at 571-272-6799. 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.
/CHENECA SMITH/Examiner, Art Unit 2192
/S. SOUGH/SPE, Art Unit 2192