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 .
Claims 1-20 are pending in this office correspondence.
Drawings
The Drawings filed on 12/19/2023 have been acknowledged.
Priority
Acknowledgment is made of applicant’s claim for a foreign priority under 35 U.S.C. 119 (a)-(d) from Korean Intellectual Property Office patent application No. 10-2022-0182166, filed on December 22, 2022.
Information Disclosure Statement
The information disclosure statement IDS submitted on 12/19/2023 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Content of Specification
The title of the invention, “STORAGE DEVICE AND OPERATING METHOD THEREOF”, is not fully descriptive of the invention. The instant application describes a storage device for loading and executing custom firmware in the form of an add-on to the main firmware in an execution area and an operating method thereof. Hence, the Examiner requests a new title that is clearly indicative of the invention to which the claims are directed.
The specification disclosure is objected to because of the following informalities:
a) The instant specification paragraph [0082] refers to “operation S270”, Fig. 6 and paragraph [0077] identify the operation of Fig. 6 as S210 through S260.
As per paragraph [0082], it seems that the operation completion signal corresponding to S260 rather than S270, either this reference needs correction or Fig. 6 should be corrected.
b) The instant specification paragraph [0074] refers to “…, receive custom firmware from the host buffer memory 130”, which it seems should read “host buffer memory 210” as confirmed in Fig. 5, Para. [0072] since the host buffer memory is element 210.
On the other hand, element 130 is the buffer memory inside the storage device of Fig. 4.
Correction is requested.
Claim Objections
Claims 1, 9 and 20 are objected to because of the following informalities:
Claim 1 recites the following language on line (8): “load custom firmware, which are configured in a form of ...” (Emphasis Added)
The aforementioned claim seems to have a typing mistake missing of the conjunction word “which are”, which seems to read instead “which is configured”.
For claim examination purposes, the examiner will interpret the above claim language to read as follows: “load custom firmware, which is configured in a form of ...” (Emphasis Added)
Claim 9 recites the following language: “The storage device of claim 1, wherein the storage device is configured to communicate with the host device according a predetermined protocol, which comprises at least one of ...” (Emphasis Added)
The aforementioned claim seems to have a typing mistake missing the conjunction word “to” that was supposed to follow the recited word “according”, for which the examiner requests a correction to add the missing conjunction word.
For claim examination purposes, the examiner will interpret the above claim language to read as follows: “The storage device of claim 1, wherein the storage device is configured to communicate with the host device according to a predetermined protocol, ...” (Emphasis Added)
Claim 20 recites the following language: “The host-storage system of claim 16, wherein the storage device is configured to communicate with the host device according a Non Volatile Memory Express (NVMe) protocol, ...” (Emphasis Added)
The aforementioned claim seems to have a typing mistake missing the conjunction word “to” that was supposed to follow the recited word “according”, for which the examiner requests a correction to add the missing conjunction word.
For claim examination purposes, the examiner will interpret the above claim language to read as follows: “The host-storage system of claim 16, wherein the storage device is configured to communicate with the host device according to a Non Volatile Memory Express (NVMe) protocol, ...” (Emphasis Added)
Appropriate correction is required.
Claim Rejections - 35 USC § 112 (b)
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 8, 12 and 16-20 are rejected under 35 U.S.C. 112(b), 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 pre-AIA the applicant regards as the invention.
Claim 8, recites the following limitation (line 5): “the nonvolatile memory.” (Emphasis Added)
However, claim 1, from which claim 8 depends through claim 7, recites “at least one nonvolatile memory.” (Emphasis Added)
The aforementioned independent claim recites the following definitive limitation – “the plurality of Pods …” (Emphasis Added)
There is insufficient antecedent basis for definitive form of “the nonvolatile memory”, and it is unclear whether the limitation refers to the previously recited “at least one nonvolatile memory” or to a different nonvolatile memory, hence the aforementioned claim is rejected under 35 U.S.C. 112(b) for indefiniteness.
For the purpose of application examination, the “the nonvolatile memory” is interpreted as “the at least one nonvolatile memory.”
Claim 12 recites “the nonvolatile memory” on lines (3, 5, 6 and 7), however claim 11, from which claim 12 depends from, recites “at least one nonvolatile memory.”
There is insufficient antecedent basis for definitive form of “the nonvolatile memory”, and it is unclear whether the limitation refers to the previously recited “at least one nonvolatile memory” or to a different nonvolatile memory, hence the aforementioned claim is rejected under 35 U.S.C. 112(b) for indefiniteness.
For the purpose of application examination, the “the nonvolatile memory” is interpreted as “the at least one nonvolatile memory.”
Claim 16 recites “a storage device comprising at least one nonvolatile memory” on lines (4). Emphasis Added)
But then, the aforementioned claim recites “in the nonvolatile memory” on line (8).
There is insufficient antecedent basis for definitive form of “the nonvolatile memory”, and it is unclear whether the limitation refers to the previously recited “at least one nonvolatile memory” or to a different nonvolatile memory, hence the aforementioned claim is rejected under 35 U.S.C. 112(b) for indefiniteness.
For the purpose of application examination, the “the nonvolatile memory” is interpreted as “the at least one nonvolatile memory.”
Claims 17-20 are rejected as their dependency is from a rejected base claim 16.
Proper correction is required.
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 11 and 12-14 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US Patent Publication (US-11379024-B2) issued to Agrawal et. al (hereinafter as “AGRAWAL”).
Regarding claim 11, AGRAWAL teaches a method of operating a storage device including at least one nonvolatile memory (AGRAWAL Fig.2, Col.5, line (60): “FIG. 2 depicts an example of a memory module 24 including different types of memory devices 26. In particular, the memory module 24 includes one or more non-volatile memory devices 32 and one or more volatile memory devices 34.”; and
col.6, line (2): “…, the non-volatile memory devices 32 may be implemented as flash (e.g., NAND) memory, …, the non-volatile memory devices 32 may provide storage class memory (SCM), …”; and
Col. 2, line (30): “…, the memory device stores the input data, the output data, data indicating the executable instructions, or any combination thereof”,
the examiner notes to that the memory module 24 with it memory controller 30 stores data for client device, see col.5, line (3)), the method comprising:
verifying a validity of custom firmware based on at least one of a checksum method, a hash function method, an electronic signature method, and a message authentication code (MAC) method (AGRAWAL Fig.3A/3B, Col.8, line (59): “A firmware commit (e.g., activation) command instructs the memory controller 30 to verify a signature of the firmware image 58 stored in the volatile memory device 34”; and
Col.9, line (12): “If the memory slots 52 match, the memory controller 30 may continue on to verify an image header and a signature and/or perform cyclic redundancy check (CRC) operations.”; and
Col.10, line (17): “…, the memory controller 30 may continue on to verify the image header and signature of the firmware image 58, such a cryptographic hash or a digital signature. Furthermore, in some embodiments, the memory controller 30 performs a CRC operation on the firmware image 58 stored in the memory slot 52 to verify suitable writing occurred.”,
the examiner notes that the reference discloses that the firmware image 58 downloaded from the client device is a firmware image supplied to the storage device to update its firmware, i.e. the claimed custom firmware, and that a CRC is a checksum method, a cryptographic hash is a hash function method and a digital signature that is an electronic signature to that of a message authentication code);
loading the custom firmware into an execution region based on a verification of the validity of the custom firmware (AGRAWAL Fig. 3A-B, Col. 9, line (18): “If the verification succeeds, the memory controller 30 may load the firmware image 58 into execution memory 54.”); and
executing the custom firmware loaded in the execution region (AGRAWAL Col. 3, line (18): “The firmware image is executed from the execution memory.”).
Regarding claim 12, AGRAWAL teaches the limitations of claim 11.
Further, AGRAWAL teaches wherein the loading of the custom firmware into the execution region comprises:
determining whether to store the custom firmware in the nonvolatile memory before loading the custom firmware into the execution region (AGRAWAL Fig.4, col.10, line (39): “At block 88, the memory controller 30 may write the firmware image 58 into the non-volatile memory device 32. ... Other suitable combinations of timing may be permitted via these system and methods of the memory controller 30. …, the firmware image 58 may be completely written to the execution memory 54 before writing is initiated of the firmware image 58 into the non-volatile memory device 32.”; and
Col.2, line (66): “In this way, the firmware may be moved from a host device to a file system storage area (FSA) of a memory slot within volatile memory to non-volatile memory and back to execution memory within the volatile memory.”; and
Col.10, line (51): “Other suitable combinations of timing may be permitted via these system and methods of the memory controller 30. For example, the firmware image 58 may be completely written to the execution memory 54 before writing is initiated of the firmware image 58 into the non-volatile memory device 32.”,
the examiner note that the reference discloses bother alternatives of the claim, storing the firmware image in the nonvolatile memory and then loading it back into the execution memory, or writing it to the execution memory without first storing it in the nonvolatile memory, which that to determine the storage alternative); and
loading the custom firmware from the nonvolatile memory into the execution region after storing the custom firmware in the nonvolatile memory when the custom firmware is stored in the nonvolatile memory (AGRAWAL Fig. 3A-B, Col. 9, lines (18-20): “If the verification succeeds, the memory controller 30 may load the firmware image 58 into execution memory 54.”, the examiner notes to also see Col. 8, line (63) to Col. 9, line (2) and Col. 10, lines (28-38), and Fig. 4, element (86)).
Regarding claim 13, AGRAWAL teaches the limitations of claim 11.
Further, AGRAWAL teaches wherein the storage device further includes a buffer memory (AGRAWAL Fig. 2, Col.6, line (60): “…, the memory controller 30 may include buffer memory 38, for example, to provide temporary data storage. ..., the buffer memory 38 may include static random-access memory (SRAM)…”; and
Col.8, line (48): “One buffer may store the firmware image 58 which has been activated and/or committed by the client device 12, and the second buffer is to keep the firmware images 58 which have been downloaded but not committed by the client device 12.”), wherein the verifying the validity of the custom firmware comprises:
receiving a firmware image download command from a host device according to a protocol (AGRAWAL Fig. 1-2, Col.8, line (53): “…, a firmware download command may initiate a transfer of data of the firmware image 58 from the client device 12 to the first buffer of the volatile memory device 34.”; and
Col.8, line (28): “…, a host controller interface and/or storage protocol used to transfer data between enterprise and client systems (e.g., between remote computing devices 11 and client devices 12), such as non-volatile memory express (NVMe)”,
the examiner notes that the reference discloses that the client device 12 issues the firmware download command is a host device);
receiving the custom firmware for the firmware image download command from the buffer memory (AGRAWAL Col.8, line (1): “Before firmware may be suitably used after a warm reset operation of the client device 12 (e.g., host device), the firmware is to be stored into execution memory 54. To do so, the memory controller 30 may write a firmware image from an image buffer 56 of the client device 12 and into the buffer memory 38. The memory controller 30 may store the firmware image from the buffer memory 38 into a memory slot 52.”; and
Col. 8, line (59): “A firmware commit (e.g., activation) command instructs the memory controller 30 to verify a signature of the firmware image 58 stored in the volatile memory device 34 (e.g., a buffer of the volatile memory device 34). After verification of the signature of the firmware image 58, the memory controller 30 may use a file system storage area (FSA) to store the firmware image 58 in execution memory 54 of the volatile memory device 34. The FSA may correspond or include one or more of the memory slots 52, such as the memory slot 52C.”,
the examiner notes that the reference discloses that the image is placed in the buffer for the volatile memory device 34 by the download command and is read from the buffer/buffer memor8 for verification and loading); and
verifying the custom firmware (AGRAWAL Fig. 2, Fig. 3A/3B, Col. 8, line (59): “A firmware commit (e.g., activation) command instructs the memory controller 30 to verify a signature of the firmware image 58 stored in the volatile memory device 34 (e.g., a buffer of the volatile memory device 34).”; and
Col.10, line (3): “…, the memory controller 30 may verify data integrity of the firmware image 58 before proceeding with the process 80. To be valid and have suitable data integrity, a written firmware image 58 may be verified to have its data start at offset zero, be contiguous, and not include any overlapping regions of data. In this way, after storing the firmware image 58 into the memory slot 52, the memory controller 30 may verify a signature of the written firmware image 58.”).
Regarding claim 14, AGRAWAL teaches the limitations of claim 11.
Further, AGRAWAL teaches wherein the verifying the validity of the custom firmware comprises:
receiving a firmware image download command from a host device according to a protocol (AGRAWAL Fig. 1-2, Col. 8, line (53): “…, a firmware download command may initiate a transfer of data of the firmware image 58 from the client device 12 to the first buffer of the volatile memory device 34.”; and
Col. 8, lines (28): “…, a host controller interface and/or storage protocol used to transfer data between enterprise and client systems (e.g., between remote computing devices 11 and client devices 12), such as non-volatile memory express (NVMe)”,
the examiner notes that the reference discloses that the download command initiates a transfer using a protocol such as NVMe);
receiving the custom firmware for the firmware image download command from a host buffer memory of the host device (AGRAWAL Col. 8, line (1): “…, the memory controller 30 may write a firmware image from an image buffer 56 of the client device 12 and into the buffer memory 38.”; and
Col. 9, line (60): “…, the memory controller 30 may transmit an updated image from the image buffer 56 to the volatile memory device 34. A controller of the client device 12 may write the firmware image 58 to the image buffer 56 in response to determining to transmit the firmware commit request.”
, the examiner notes that the reference discloses that the image buffer 56 of the client device 12 is a host buffer memory of the host device); and
verifying the custom firmware (AGRAWAL Fig. 2, Fig. 3A/3B, Col. 8, line (59): “A firmware commit (e.g., activation) command instructs the memory controller 30 to verify a signature of the firmware image 58 stored in the volatile memory device 34 (e.g., a buffer of the volatile memory device 34).”; and
Col.9, line (12): “If the memory slots 52 match, the memory controller 30 may continue on to verify an image header and a signature and/or perform cyclic redundancy check (CRC) operations.”; and
Col.10, line (17): “…, the memory controller 30 may continue on to verify the image header and signature of the firmware image 58, such a cryptographic hash or a digital signature. Furthermore, in some embodiments, the memory controller 30 performs a CRC operation on the firmware image 58 stored in the memory slot 52 to verify suitable writing occurred.”).
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 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 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5-10, 16-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Publication (US-10572166-B1) issued to Douglass et. al (hereinafter as “DOUGLASS”), and in view of US Patent Publication (US-7814261-B2) issued to Lee (hereinafter as “LEE”).
Regarding claim 1, DOUGLASS teaches a storage device configured to communicate with a host device (the examiner notes that DOUGLASS in Fig. 1/Fig. 2, and in Col. 2, lines (30-58); and in Col. 5, line (2), discloses a solid state storage media card 140, an SSD, coupled through a PCIs interface 142 to a host controller 120 that issues NVMe commands to the card), the storage device comprising:
at least one nonvolatile memory (the examiner notes that DOUGLASS in Fig. 1, Col. 2, lines (37-46); and Col. 4, lines (1-12), discloses flash memory devices 152, i.e. NAND flash deices for user data, and SPI flash memory 170); and
a memory controller comprising an execution region (DOUGLASS Fig. 2, Col. 4, lines (1-36): “Each processor core 150 includes random access memory (RAM) 153 which comprises volatile memory for storage of firmware 154 executed by the corresponding core.”,
the examiner notes that the reference discloses processor cores 150 (Core0-Core-2), each including RAM 153, together with SRAM 162, DRAM 148 and the loader firmware 146 in SPI flash 170, from the card’s controller; the core RAM 152/153 and SRAM 162 being the execution region from which the firmware is executed), the memory controller configured to:
control a firmware load operation of the at least one nonvolatile memory (DOUGLASS Fig.1/Fig.2, Col. 4, lines (28-43): “The SPI flash memory 170 includes the firmware 146 shown in FIG.1, including multiple firmware components that perform different functions. In the depicted embodiment, these firmware components include SFLoader 172, NVMeLoader 174, and LiveLoader 176. These firmware components are executed by one of the processor cores 150 to provide the functionality described herein. For example, one of the processor cores 150 may be predetermined to be the core to execute the firmware components stored in the SPI flash 170. The SFLoader 172 is responsible for initializing and/or testing the DRAM 148 and loading the NVMeLoader 174 into RAM (e.g., RAM 152 within a processor core 150) and validating the NVMeLoader (e.g., performing a checksum).”,
the examiner notes that the reference discloses the SFLoader 172 stored in SPI flash 170 loads the VNMeLoader 174 from the SPI flash into RAM and validates it to that claimed of a load operation of the nonvolatile memory),
receive a commit command from the host device (DOUGLASS Fig. 1, Col. 4, line (64)-Col. 5, line (2): “…, the host controller 120 transmits NVMe commands to the solid state storage media card 140 to implement this functionality. The commands may include, …, a firmware download command and a firmware activation command.”; and
Col. 6, line (27-46): “…, an activation command may be provided by the host controller to the media card to specify a desired behavior for executing the newly downloaded firmware.”,
the examiner notes that the reference discloses that the host controller issues NVMe commands including a firmware activation command to that claimed of receiving a commit command. Examiner further notes that the NVMe firmware activation command is the NVMe Firmware Commit Command as known in the “NVM Express Rev. 1.0-1.4” industry standard, which is attached for reference),
execute the custom firmware in the execution region based on the commit command (DOUGLAS Fig.1/Fig.2, col.5, lines (8-14): “The downloaded firmware is stored in DRAM 148. …, the firmware stored in DRAM 148 comprises a plurality of segments 182, 184, 186, 188, 190, and 192 as shown. ... LiveLoader 176 then copies the segments 188-192 to the RAM 152”; and
Col. 6, lines (32-37): “…, the activation command may include an activation value that specifies that the retrieved firmware is to be executed without waiting for a reset of the solid state storage media card. This latter type of activation is a live update of the firmware …”; and
Col. 6, lines (42-46): “…, LiveLoader 176 modifies the program counter of the processor core(s) 150 to begin execution of the new firmware at the memory address of the new firmware in volatile memory.”,
the examiner notes that reference discloses a downloaded firmware stored in DRAM 148 to that of a custom firmware).
However, DOUGLASS does not explicitly teach load custom firmware, which are configured in a form of an add-on to main firmware, into the execution region.
But LEE teaches load custom firmware, which are configured in a form of an add-on to main firmware, into the execution region (LEE Fig.1A/1B, Fig.2, Col.3, line (33): “The firmware code area 106a stores a firmware code for executing the optical drive.”; and
Col.3, lines (4-7): “The dynamic allocation area 100a is used to store, execute, and delete a firmware operation module (e.g., a code for debugging an optical drive and a code for controlling the optical drive) received from a host.”; and
Col.3, lines (65-66): “…, the necessary firmware operation module is loaded to the dynamic allocation area 100a, …”; and
Col.4, lines (1-6): “…, in response to the module execution command from the host, the optical drive loads the dynamic module execution code stored in the dynamic module execution code area 104a to the dynamic allocation area 100a and executes the firmware operation module using the dynamic module execution code”,
the examiner notes that the reference discloses a storage drive whose flash memory holds a firmware code 106a that runs the drive, i.e. the main firmware, and a separate “dynamic allocation area 100a”, see Fig.1A, that receives and stores another firmware operation module code, i.e. add-on firmware to the main firmware.
Further, the examiner notes that LEE discloses that this add-on firmware is stored separately in Col.3, lines (1-3): “…, the dynamic module may be stored separately in the flash memory and optionally loaded at a run time.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of DOUGLASS (disclosing methods for firmware download in a solid state storage system) to include the teachings of LEE (disclosing methods for dynamically loading firmware operations), and arrive at a method to manage the loading of additional add-on firmware as needed for additional functionality. One of ordinary skill in the art would have been motivated to make this combination because when adding development functions utilizing additional firmware, such as debugging firmware code modules that consumes limited firmware space in the user environment, whereas downloading such module only when required, and executing these modules and then discarding them, thereby maximizing the efficiency of the firmware area and lets firmware with various function to be installed in a limited space area as needed, as recognized by (LEE Abstract, Col.1, lines (41-66), Col.4, lines (9-19)). In addition, the references of DOUGLASS and LEE teach features that are directed to analogous art and they are directed to the same field of endeavor of firmware loading and execution management.
Regarding claim 2, the combination of DOUGLASS and LEE teaches the limitations of claim 1. Further, DOUGLASS teaches wherein the memory controller is further configured to:
receive a firmware image download command from the host device (DOUGLASS Fig.1, Col.4, lines (66): “The commands may include, for example, a firmware download command and a firmware activation command. The firmware download command specifies a path to storage accessible by the solid state storage media card that stores the firmware to be downloaded (e.g., storage within the host controller 120 as shown in FIG. 1).”; and
Co.6, line (8): “The first command may be a firmware download command in accordance with the NVMe protocol.”); and
determine whether to store the custom firmware in the at least one nonvolatile memory based on the firmware image download command (DOUGLASS Fig.1, col.3, line (5): “The solid state storage media card responds to the firmware download command by retrieving a copy of the specified firmware using the specified path. The downloaded firmware is stored in DRAM 148.”; and
Col.5, line (26): “The firmware downloaded from the host controller 120 into the DRAM 148 and then into the RAM 152 of the individual cores is not also stored in non-volatile memory and thus will not survive a power cycle or reset of the solid state storage media card 140.”; and
Col.3, line (39): “The firmware is executed by one or more of the processor cores 150 without ever having been stored in non-volatile storage within the solid state storage media card.”,
the examiner notes the reference discloses that the memory controller responds to the firmware command by storing the received firmware in the volatile memory only and note in the nonvolatile memory, i.e. it determines as claimed, based on the firmware image download command, whether the custom firmware is stored in the nonvolatile memory.).
Regarding claim 3, the combinations of DOUGLASS and LEE teach the limitations of claim 1. Further, LEE teaches wherein the execution region comprises a first region in which the main firmware is loaded and a second region in which the custom firmware is loaded, and wherein the second region is separated from the first region (LEE Fig.1A/1B, Fig.2, Co.2, line (63): “A flash memory of FIG. 1A includes at least a dynamic allocation area 100a, a dynamic module loading code area 102a, a dynamic module execution code area 104a, and a firmware code area 106a.”; and
Col.3, line (33): “The firmware code area 106a stores a firmware code for executing the optical drive.”; and
Col.3, lines (4): “The dynamic allocation area 100a is used to store, execute, and delete a firmware operation module (e.g., a code for debugging an optical drive and a code for controlling the optical drive) received from a host.”; and
Col.3, lines (1): “…, the dynamic module may be stored separately in the flash memory and optionally loaded at a run time.”; and
Col.3, lines (65-66): “…, the necessary firmware operation module is loaded to the dynamic allocation area 100a, …”,
the examiner notes that the reference discloses that the firmware operation module is loaded into and executed from the dynamic allocation area 100a, which is an area separate from the firmware code area 106a that stores the firmware code for the drive, i.e the main firmware).
Regarding claim 5, the combinations of DOUGLASS and LEE teach the limitations of claim 1. Further, DOUGLASS teaches comprising a buffer memory, which is physically provided inside the storage device (DOUGLASS Fig.2, col.2, line (46): “Each solid state storage media card also includes one or more processor cores 150, volatile memory 148 (e.g., dynamic random access memory, DRAM) 148, non-volatile memory 144, and an interface 142.”), wherein the memory controller is further configured to:
receive the custom firmware from the buffer memory DOUGLASS Fig.1/Fig.2, col.5, line (7): “The downloaded firmware is stored in DRAM 148. …, the firmware stored in DRAM 148 comprises a plurality of segments 182, 184, 186, 188, 190, and 192 as shown. ... LiveLoader 176 then copies the segments 188-192 to the RAM 152 of the corresponding processor code 150”,
the examiner notes that the DRAM 148 on the media card is a buffer memory physically provided inside the storage device from which the customer firmware is received);
load the custom firmware into the execution region (DOUGLASS Fig.2, col.6, line (13): “At 206, the method further includes copying the downloaded firmware from the first volatile memory to a second volatile memory within a processor core of the solid state storage media card 140.”); and
execute the custom firmware in the execution region based on the commit command (DOUGLAS Col. 6, line (19): “At 208, the method includes executing the firmware from the second volatile memory of the processor core.”; and
Col. 6, line (32): “…, LiveLoader 176 modifies the program counter of the processor core(s) 150 to begin execution of the new firmware at the memory address of the new firmware in volatile memory.”).
Regarding claim 7, the combinations of DOUGLASS and LEE teach the limitations of claim 1. Further, DOUGLASS teaches wherein the memory controller is further configured to:
receive the custom firmware from a host buffer memory included in the host device (DOUGLASS Fig.1, Col.2, line (63): “The host controller 120 also may include storage for host firmware 124 and media card firmware 126, …”; and
Fig.1, col.5, line (1): “The firmware download command specifies a path to storage accessible by the solid state storage media card that stores the firmware to be downloaded (e.g., storage within the host controller 120 as shown in FIG. 1). The solid state storage media card responds to the firmware download command by retrieving a copy of the specified firmware using the specified path.”,
the examiner note the reference discloses that the storage within the host controller 120 that holds the media card firmware 126 for retrieval by the storage device is a host buffer memory included in this host device. Furthermore, LEE teaches that the firmware operation modile is tored in the host and loaded to the drive on the host’s loading command is disclosed in LEE Fi.2, col.3, line (52): “A firmware operation module in Fig. 2 is stored in a host”);
load the custom firmware into the execution region (DOUGLASS Fig.1/Fig.2, col.5, lines (14-16): “LiveLoader 176 then copies the segments 188-192 to the RAM 152 of the corresponding processor core 150 as indicated by the dashed lines. Some of the firmware and/or data to be used by a given processor core 150 may be stored in SRAM 162.”; and
col.6, lines (14-19): “At 206, the method further includes copying the downloaded firmware from the first volatile memory to a second volatile memory within a processor core of the solid state storage media card 140. This operation may include transferring execution to LiveLoader 176 so that LiveLoader 176 can copy the firmware between the volatile memory locations.”); and
execute the custom firmware in the execution region based on the commit command (DOUGLASS Fig.1/Fig.2, col.6, line (19): “At 208, the method includes executing the firmware from the second volatile memory of the processor core.”; and
col.6, line (32): “…, the activation command may include an activation value that specifies that the retrieved firmware is to be executed without waiting for a reset of the solid state storage media card. This latter type of activation is a live update of the firmware in that a change is made from the execution of one firmware copy to another without power cycling or resetting the solid state storage media card. Once the new firmware is provided to the solid state storage media card and the various segments of the firmware are parsed and loaded into the volatile memories as described above, LiveLoader 176 modifies the program counter of the processor core(s) 150 to begin execution of the new firmware at the memory address of the new firmware in volatile memory.”).
Regarding claims (6 and 8), the aforementioned claims recite similar limitations to claim 2, wherein the customer firmware received from the buffer memory and from the host buffer memory being addressed in (claims 5 and 7), therefore these claims are rejected for similar reasons as mentioned above.
Regarding claim 9, the combinations of DOUGLASS and LEE teach the limitations of claim 1. Further, DOUGLASS teaches wherein the storage device is configured to communicate with the host device according a predetermined protocol, which comprises at least one of a Non Volatile Memory Express (NVMe) protocol and an NVMe over Fabric protocol (DOUGLASS Fig.1, col.4, lines (59): “…, the host controller 120 issues Non-Volatile Memory Express (NVMe) protocol commands over a PCIe interface to each solid state storage media card 140.”).
Regarding claim 10, the combinations of DOUGLASS and LEE teach the limitations of claim 1. Further, LEE teaches wherein the custom firmware comprises at least one of dynamic thermal throttling (DTT) firmware, Acceleration firmware, Debug firmware, Test firmware, and Logging firmware (LEE Fig.1A/1B, Fig.2, Col.3, line (33): “The firmware code area 106a stores a firmware code for executing the optical drive.”; and
Col.3, lines (4-7): “The dynamic allocation area 100a is used to store, execute, and delete a firmware operation module (e.g., a code for debugging an optical drive and a code for controlling the optical drive) received from a host.”).
Regarding claim 16, DOUGLASS teaches a host-storage system (DOUGLASS Fig.1, col.2, line (24): “As shown in the example of FIG. 1, the storage system 110 includes a host controller 120 coupled to one or more solid state storage media cards 140”) comprising:
a host device configured to generate a firmware image download command and a commit command (DOUGLASS Fig.1, col.4, line (58): “…, he host controller 120 issues Non-Volatile Memory Express (NVMe) protocol commands over a PCIe interface to each solid state storage media card 140. ... The commands may include, for example, a firmware download command and a firmware activation command.”; and
Col.6, line (26): “…, an activation command may be provided by the host controller to the media card to specify a desired behavior for executing the newly downloaded firmware.”,
the examiner note that the reference discloses a host controller (element 120), i.e. a host device, that generates an NVMe firmware download activation command is the NVMe Firmware Commit command, which was known in the “NVM Express Rev. 1.4” industry standard, which is attached for reference); and
a storage device comprising at least one nonvolatile memory (DOUGLASS Fig.1, col.2, line (37): “Each solid state storage media card 140 includes one more flash memory devices 152 into which user data can be stored. ... Each solid state storage media card also includes one or more processor cores 150, volatile memory 148 (e.g., dynamic random access memory, DRAM) 148, non-volatile memory 144, and an interface 142.”), wherein the storage device is configured to:
receive the firmware image download command from the host device (DOUGLASS col.5, line (1): “The firmware download command specifies a path to storage accessible by the solid state storage media card that stores the firmware to be downloaded (e.g., storage within the host controller 120 as shown in FIG. 1). The solid state storage media card responds to the firmware download command by retrieving a copy of the specified firmware using the specified path. The downloaded firmware is stored in DRAM 148.”),
receive the commit command from the host device (DOUGLASS col.6, line (32): “Alternatively, the activation command may include an activation value that specifies that the retrieved firmware is to be executed without waiting for a reset of the solid state storage media card.”), and
load the custom firmware into an execution region of the storage device (DOUGLAS Fig.1/Fig.2, col.5, line (8): “The downloaded firmware is stored in DRAM 148. …, the firmware stored in DRAM 148 comprises a plurality of segments 182, 184, 186, 188, 190, and 192 as shown. ... LiveLoader 176 then copies the segments 188-192 to the RAM 152”; and
Col. 6, line (32): “…, the activation command may include an activation value that specifies that the retrieved firmware is to be executed without waiting for a reset of the solid state storage media card. This latter type of activation is a live update of the firmware …”; and
Col. 6, line (42): “…, LiveLoader 176 modifies the program counter of the processor core(s) 150 to begin execution of the new firmware at the memory address of the new firmware in volatile memory.”,
the examiner notes that reference discloses a downloaded firmware stored in DRAM 148 to that of a custom firmware).
However, DOUGLASS does not explicitly teach determine whether to store custom firmware, which is configured in a form of an add-on to main firmware, in the nonvolatile memory based on the firmware image download command.
But LEE teaches determine whether to store custom firmware, which is configured in a form of an add-on to main firmware, in the nonvolatile memory based on the firmware image download command (LEE Fig.1A/1B, Fig.2, Col.3, line (33): “The firmware code area 106a stores a firmware code for executing the optical drive.”; and
Col.3, lines (4-7): “The dynamic allocation area 100a is used to store, execute, and delete a firmware operation module (e.g., a code for debugging an optical drive and a code for controlling the optical drive) received from a host.”; and
Col.3, lines (65-66): “…, the necessary firmware operation module is loaded to the dynamic allocation area 100a, …”; and
Col.4, lines (1-6): “…, in response to the module execution command from the host, the optical drive loads the dynamic module execution code stored in the dynamic module execution code area 104a to the dynamic allocation area 100a and executes the firmware operation module using the dynamic module execution code”,
the examiner notes that the reference discloses a storage drive whose flash memory holds a firmware code 106a that runs the drive, i.e. the main firmware, and a separate “dynamic allocation area 100a”, see Fig.1A, that receives and stores another firmware operation module code, i.e. add-on firmware to the main firmware.
Further, the examiner notes that LEE discloses that this add-on firmware is stored separately in Col.3, lines (1-3): “…, the dynamic module may be stored separately in the flash memory and optionally loaded at a run time.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of DOUGLASS (disclosing methods for firmware download in a solid state storage system) to include the teachings of LEE (disclosing methods for dynamically loading firmware operations), and arrive at a method to manage the loading of additional add-on firmware as needed for additional functionality. One of ordinary skill in the art would have been motivated to make this combination because when adding development functions utilizing additional firmware, such as debugging firmware code modules that consumes limited firmware space in the user environment, whereas downloading such module only when required, and executing these modules and then discarding them, thereby maximizing the efficiency of the firmware area and lets firmware with various function to be installed in a limited space area as needed, as recognized by (LEE Abstract, Col.1, lines (41-66), Col.4, lines (9-19)). In addition, the references of DOUGLASS and LEE teach features that are directed to analogous art and they are directed to the same field of endeavor of firmware loading and execution management.
Regarding claim 17, the combination of DOUGLASS and LEE teaches the limitations of claim 16. Further, DOUGLASS teaches wherein the storage device further comprises a buffer memory, and wherein the storage device is further configured to receive the custom firmware from the buffer memory (DOUGLASS Fig.2, line (7): “…, the firmware stored in DRAM 148 comprises a plurality of segments 182, 184, 186, 188, 190, and 192 as shown. Segments 188, 190, and 192 are to be executed by corresponding processor cores Core0, Core1, and Core2. LiveLoader 176 then copies the segments 188-192 to the RAM 152 of the corresponding processor core 150 as indicated by the dashed lines.”,
the examiner notes that the reference discloses that the DRAM 148 on the media card is a buffer memory of the storage device from which the customer firmware is received and copied into the execution region.
Additionally, LEE discloses in Fig.1A/1B, Fig.2, Col.3, line (33): “The firmware code area 106a stores a firmware code for executing the optical drive.”; and
Col.3, lines (4-7): “The dynamic allocation area 100a is used to store, execute, and delete a firmware operation module (e.g., a code for debugging an optical drive and a code for controlling the optical drive) received from a host.”; and
Col.3, lines (65-66): “…, the necessary firmware operation module is loaded to the dynamic allocation area 100a, …”; and
Col.4, lines (1-6): “…, in response to the module execution command from the host, the optical drive loads the dynamic module execution code stored in the dynamic module execution code area 104a to the dynamic allocation area 100a and executes the firmware operation module using the dynamic module execution code”,
the examiner notes that the reference discloses a storage drive whose flash memory holds a firmware code 106a that runs the drive, i.e. the main firmware, and a separate “dynamic allocation area 100a”, see Fig.1A, that receives and stores another firmware operation module code, i.e. add-on firmware to the main firmware.
Further, the examiner notes that LEE discloses that this add-on firmware is stored separately in Col.3, lines (1-3): “…, the dynamic module may be stored separately in the flash memory and optionally loaded at a run time.”).
Regarding claim 18, the combination of DOUGLASS and LEE teaches the limitations of claim 16. Further, DOUGLASS teaches wherein the host device comprises a host buffer memory, wherein the storage device is further configured to receive the custom firmware from the host buffer memory (DOUGLASS Fig.1, col.2, line (63): “The host controller 120 also may include storage for host firmware 124 and media card firmware 126, …”; and
Col.3, line (29): “The host controller 120 may store multiple copies of media card firmware 126 and serve the appropriate version to a given solid state storage media card 140.”; and
Fig.1/Fig.2, col.5, line (1): “The firmware download command specifies a path to storage accessible by the solid state storage media card that stores the firmware to be downloaded (e.g., storage within the host controller 120 as shown in FIG. 1). The solid state storage media card responds to the firmware download command by retrieving a copy of the specified firmware using the specified path.”,
the examiner notes that the reference discloses that the storage within the host controller 120 that holds the media card firmware 126 for retrieval by the storage device of a host buffer memory.).
Regarding claim 20, the combinations of DOUGLASS and LEE teach the limitations of claim 16. Further, LEE teaches wherein the storage device is configured to communicate with the host device according a Non Volatile Memory Express (NVMe) protocol, wherein the custom firmware comprises at least one of dynamic thermal throttling (DTT) firmware, Acceleration firmware, Debug firmware, Test firmware, and Logging firmware (LEE Col.3, lines (4-7): “The dynamic allocation area 100a is used to store, execute, and delete a firmware operation module (e.g., a code for debugging an optical drive and a code for controlling the optical drive) received from a host.”; and
Fig. 1, Col.4, line (58): “…, the host controller 120 issues Non-Volatile Memory Express (NVMe) protocol commands over a PCIe interface to each solid state storage media card 140.”).
Claims 4 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Publication (US-10572166-B1) issued to Douglass et. al (hereinafter as “DOUGLASS”), in view of US Patent Publication (US-7814261-B2) issued to Lee (hereinafter as “LEE”), and in view of US Patent Publication (US-7962684-B2) issued to Struk et. al (hereinafter as “STRUK”).
Regarding claim 4, the combination of DOUGLASS and LEE teach the limitations of claim 1.
However, the combination of DOUGLASS and LEE does not explicitly teach wherein the execution region comprises a first region in which the main firmware is loaded and a second region in which the custom firmware is loaded, wherein the first region comprises the second region.
But STRUK teaches the execution region comprises a first region in which the main firmware is loaded and a second region in which the custom firmware is loaded, wherein the first region comprises the second region (STRUK Fig.1, col.2, lines (23-25): “Memory controller 104 itself comprises a processor and an executable random access memory ("RAM")”; and
Col.2, lines (34-36): “The firmware that runs a memory storage device is broken up into overlays appropriately sized to fit into a RAM to be executed.”; and
Col.2, lines (11-13): “firmware overlay is a program segment called into memory when required by an overlay manager.”; and
Col.3, lines (11-50): “ORAM 130 may be a discrete RAM or a region within a larger RAM allocated to overlays. Data 138, and free space 139 are also present in ORAM 130. Data 138 may be either dynamic or static. Dynamic data is allocated for temporary usage. The most frequent use of dynamic data is a temporary buffer. Static data is a concrete block of variables that is initialized with concrete values.”; and
Fig.1B/1C, Col.5, lines (34-45, 60-67): “FIG. 1C is a flowchart describing an embodiment of overlay management at a high level. In step 200 the system checks the OMT to see if an overlay with a called function is in ORAM.”,
the examiner notes that the reference discloses that the firmware is broken up into overlays wherein an overlay being a program segment. Further, the reference discloses that the controller RAM contains a main code region 120 holding the resident code and tables and an overlay ORAM 130 into which overlays are loaded from flash on demand and from which they are executed; and consequently the RAM allocated to firmware execution, i.e. the claimed first region, comprises the overlay region, i.e. the claimed second region, into which additional code is loaded and executed.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination teachings of DOUGLASS (disclosing methods for firmware download in a solid state storage system) and the teachings of LEE (disclosing methods for dynamically loading firmware operations), to include the teachings of STRUK (disclosing methods for on-demand code storage controller) and arrive at a method to manage the loading of additional add-on firmware as needed in different parts of memory. One of ordinary skill in the art would have been motivated to make this combination because when providing this dynamic memory allocation functionality enables a constrained memory RAM controller to be shared between resident code and code loaded when required without dedicating a separate physical memory, as recognized by (STRUK Col.2, lines (34-42), Col.3, lines (44-50)). In addition, the references of DOUGLASS, LEE and STRUK teach features that are directed to analogous art and they are directed to the same field of endeavor of firmware loading and execution management.
Regarding claim 19, the combination of DOUGLASS and LEE teaches the limitations of claim 16.
However, the combination of DOUGLASS and LEE does not explicitly teach wherein the execution region comprises a first region in which the main firmware is loaded and a second region in which the custom firmware is loaded, wherein the first region comprises the second region.
But STRUK teaches wherein the execution region comprises a first region in which the main firmware is loaded and a second region in which the custom firmware is loaded, wherein the first region comprises the second region (STRUK Fig.1, col.2, lines (23-25): “Memory controller 104 itself comprises a processor and an executable random access memory ("RAM")”; and
Col.2, lines (34-36): “The firmware that runs a memory storage device is broken up into overlays appropriately sized to fit into a RAM to be executed.”; and
Col.2, lines (11-13): “firmware overlay is a program segment called into memory when required by an overlay manager.”; and
Col.3, lines (11-50): “ORAM 130 may be a discrete RAM or a region within a larger RAM allocated to overlays. Data 138, and free space 139 are also present in ORAM 130. Data 138 may be either dynamic or static. Dynamic data is allocated for temporary usage. The most frequent use of dynamic data is a temporary buffer. Static data is a concrete block of variables that is initialized with concrete values.”; and
Fig.1B/1C, Col.5, lines (34-45, 60-67): “FIG. 1C is a flowchart describing an embodiment of overlay management at a high level. In step 200 the system checks the OMT to see if an overlay with a called function is in ORAM.”,
the examiner notes that the reference discloses that the firmware is broken up into overlays wherein an overlay being a program segment. Further, the reference discloses that the controller RAM contains a main code region 120 holding the resident code and tables and an overlay ORAM 130 into which overlays are loaded from flash on demand and from which they are executed; and consequently the RAM allocated to firmware execution, i.e. the claimed first region, comprises the overlay region, i.e. the claimed second region, into which additional code is loaded and executed.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination teachings of DOUGLASS (disclosing methods for firmware download in a solid state storage system) and the teachings of LEE (disclosing methods for dynamically loading firmware operations), to include the teachings of STRUK (disclosing methods for on-demand code storage controller) and arrive at a method to manage the loading of additional add-on firmware as needed in different parts of memory. One of ordinary skill in the art would have been motivated to make this combination because when providing this dynamic memory allocation functionality enables a constrained memory RAM controller to be shared between resident code and code loaded when required without dedicating a separate physical memory, as recognized by (STRUK Col.2, lines (34-42), Col.3, lines (44-50)). In addition, the references of DOUGLASS, LEE and STRUK teach features that are directed to analogous art and they are directed to the same field of endeavor of firmware loading and execution management.
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over US Patent Publication (US-11379024-B2) issued to Agrawal et. al (hereinafter as “AGRAWAL”), and in view of US Patent Publication (US-8706955-B2) issued to Fai et. al (hereinafter as “FAI”).
Regarding claim 15, AGRAWAL teaches the limitations of claim 11.
However, AGRAWAL does not explicitly teach wherein the custom firmware comprises at least one of dynamic thermal throttling (DTT) firmware, Acceleration firmware, Debug firmware, Test firmware, and Logging firmware.
But FAI teaches wherein the custom firmware comprises at least one of dynamic thermal throttling (DTT) firmware, Acceleration firmware, Debug firmware, Test firmware, and Logging firmware (FAI col.3, lines (17-22): “…, if an error is encountered with a memory device, a host device can cause the memory device to reboot using debug firmware (provided by the host to the memory device) instead of with operational firmware that was used when the error was encountered.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of AGRAWAL (disclosing methods for firmware image download and verification) to include the teachings of FAI (disclosing methods for firmware debug and testing), and arrive at a method to enable a host device rung diagnostics or testing code. One of ordinary skill in the art would have been motivated to make this combination because when adding a host device can run diagnostics or manufacturing test code in place of/or in addition to its operational firmware when an error is countered or when a new hardware is installed, thereby applying AGRAWAL’s fast and verified activation of firmware with predictable results, as recognized by (FAI Col.3, lines (41-30)). In addition, the references of DOUGLASS and LEE teach features that are directed to analogous art and they are directed to the same field of endeavor of firmware execution management.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Vlaiko et al.; (US-20170242606-A1); “Methods for storage device writes its active firmware code to the NVMe host memory buffer and, on resume, reads it back from the buffer into the SRAM after a validity check.”
Subramanian et al.; (US-11106457-B1); “Methods for updating firmware runtime components stored in volatile memory and used immediately.”
Scales et al.; (US-5535355-A); “Methods for a storage device controller executing either prestored firmware or user-defined firmware loaded into RAM from a medium.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Zuheir A Mheir whose telephone number is (571)272-4151. The examiner can normally be reached on Monday - Friday 9:00 - 5:00.
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, Pierre Vital can be reached on (571)272-4215. 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 https://ppair-my.uspto.gov/pair/PrivatePair. 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.
09/18/2026
/ZUHEIR A MHEIR/Patent Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights