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 .
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.
Priority
Applicant’s claim for the benefit of prior-filed application 63/651,876 under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
All claims are examined with an effective filing date of May 24, 2024.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on September 23, 2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Examiner notes for clarity of record that the copy of the international search report and written opinion attached with the IDS is illegible. While the IDS indicates that the report is stricken, the information within has been considered, and a legible copy has been provided with this office action and cited on the attached PTO-892.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Objections
Claim 8 is objected to because of the following informalities:
Claim 8, line 3, recites “detaching”, but should recite “detach” for grammatical correctness.
Appropriate correction is required.
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-25 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.
Claims 1, 15, and 20 recite, using claim 1 for example language, “determine whether to transition from the management mode to the second firmware mode based at least in part on the management mode supporting the one or more verification operations”. However, this leads to an issue of indefiniteness, as it is unclear whether the determination whether to transition is based on the management mode’s supporting the verification operations (i.e. one result if the management mode supports verification, and a different result if the management mode does not support verification), or if the verification operations affect how the determination results. Based on the earlier recitation “wherein the management mode supports one or more verification operations” and later dependent claims providing further detail on how the circuitry determines whether to transition to the second mode or not, while no amended language is suggested here, the latter interpretation is utilized in examination of the claim.
The dependent claims are rejected due to their dependence on one of the independent claims identified above.
Claims 3 and 22 recite, using claim 3 for example language, “based at least in part on the command”, but “the command” lacks proper antecedent basis, as this is the first time “the command” is recited in either parent claim 1 or claim 3 (and similar for claim 22). For the purpose of examination, it is assumed this recites “a command”.
Claim 11 recites “based at least in part on identifying that the mode switch information”. This claim limitation appears to be unfinished, as there is no recitation of what about the mode switch information is identified, leaving the claim limitation indefinite, as it is unclear what information identified would sufficiently read upon the claim. For the purpose of examination, it is assumed this recites “identifying the mode switch information”, as this would leave the general scope of identifying the mode switch information while removing the “that” clause that introduces indefiniteness.
Claim 16 recites “herein the one or more indications comprise a threshold time period”. However, one or more indications typically refers to signals or some form of information, not a time period. While no amended language is provided, it is assumed the claim is reciting that the one more indications are related to a threshold time period.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim 1, 3, 9-14, 20, and 22 are rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by Orlando et al. (US 2023/0274002)
Regarding claim 1, Orlando teaches a memory system (Fig. 5, where “FIG. 5 illustrates an example of an environment 500 including a discrete computing device in the form of a host device 505 and a memory device 510 configured to communicate over a communication interface,” [0035]), comprising:
one or more memory devices (Fig. 5, memory device 510 containing memory array 520); and
processing circuitry coupled with the one or more memory devices and configured to cause the memory system to (“The environment 500 may be an example of FIG. 4 in which the first computing device 410 and the second computing device 480 may be components of a host device 505. In these examples, the various components, such as the memory controller 515 of the memory device 510 may authenticate with other components of the host device 505 via the methods disclosed herein,” [0035] where with reference to Fig. 4, “First computing device 410 may include a firmware layer 422, a layer zero code 414, a DICE layer 412, and a firmware updater 416 (which may be part of the DICE layer 412, or the firmware layer 422). In some examples, the firmware update process may be done inside firmware 422 and the cryptographic validation performed by the firmware updater 416. Firmware layer 422 may be an example of updatable device firmware 122 of FIG. 1. Firmware layer 422 may provide low-level control of the hardware of the device and in some examples may manage the device. In some examples, additional layers above the firmware layer 422 may be present and may utilize interfaces to the hardware provided by the firmware. In other examples, the firmware layer 422 may provide the software instructions to control the device, e.g., perform operations specified by the memory controller 515 of FIG. 5,” [0034]; as seen in Fig. 5, memory controller 515 connected to the memory devices contains the control layers referenced):
operate in a first firmware mode of the memory system, the first firmware mode associated with a first command set for accessing the memory system (“the firmware layer 422 may provide the software instructions to control the device, e.g., perform operations specified by the memory controller 515 of FIG. 5,” [0034], where [0038] clarifies that this firmware is used to access the memory array);
receive an indication of a second firmware mode for the memory system, the second firmware mode associated with a second command set for accessing the memory system that is different than the first command set (“The operations of FIG. 2 may be performed by the device, for example, in a secure field firmware update process (e.g., a firmware update component 190 of FIG. 1), implemented by, for example, a firmware update component 190. At operation 210, the firmware update process on a device is started. For example, another device issues a firmware update command and supplies an updated firmware object,” [0025]);
transition, based at least in part on the first command set being different than the second command set, from the first firmware mode to a management mode associated with a reduced command set relative to the first command set and the second command set (“This may cause the device to go into a firmware update mode where other operations are suspended,” [0025]), wherein the management mode supports one or more verification operations associated with a transition from the first firmware mode to the second firmware mode (Figs. 2 and 3 demonstrate a process to authenticate the firmware in a DICE or layer 0 code to authenticate the firmware before updating it, see also [0025-0031]); and
determine whether to transition from the management mode to the second firmware mode based at least in part on the management mode supporting the one or more verification operations (Figs. 2 and 3 demonstrate a process to authenticate the firmware in a DICE or layer 0 code to authenticate the firmware before updating it, see also [0025-0031].
Regarding claim 3, Orlando teaches the memory system of claim 1, wherein the processing circuitry is further configured to cause the memory system to:
perform the one or more verification operations according to the management mode (“Upon first boot after the update, a firmware update checker (e.g., firmware update check component 140), compares a measurement of the firmware object that is booted (e.g., the firmware security descriptor 120) with the value stored in the secure storage device (e.g., register 135). If the values match, the alias certificate may be regenerated (e.g., via a regeneration signal), and the boot continues. If the values do not match, then the alias certificate may not be regenerated, and the system may have an authenticity failure because the key and the certificate do not match. The system may take steps to alert a user, management device, or the like of the failure. In some examples, the device may halt and may refuse to load the invalid firmware,” [0023], see also [0030,0031]);
receive, based at least in part on the one or more verification operations, a second indication of the first firmware mode, wherein determining whether to transition from the management mode to the second firmware mode is further based at least in part on the command (“Upon first boot after the update, a firmware update checker (e.g., firmware update check component 140), compares a measurement of the firmware object that is booted (e.g., the firmware security descriptor 120) with the value stored in the secure storage device (e.g., register 135). If the values match, the alias certificate may be regenerated (e.g., via a regeneration signal), and the boot continues. If the values do not match, then the alias certificate may not be regenerated, and the system may have an authenticity failure because the key and the certificate do not match. The system may take steps to alert a user, management device, or the like of the failure. In some examples, the device may halt and may refuse to load the invalid firmware,” [0023], see also [0030,0031]); and
transition from the management mode to the first firmware mode based at least in part on the second indication ([0023] and [0031] refer to halting operations to prevent loading the updated firmware; necessarily, this would cause the device to revert to the previous version of the firmware, reading on this limitation).
Regarding claim 9, Orlando teaches the memory system of claim 1, wherein the processing circuitry is further configured to cause the memory system to:
store mode switch information that indicates a mode switch between the first firmware mode and the second firmware mode based at least in part on the second command set being different than the first command set (“If the authenticity feature is enabled, then at operation 230, the system may measure the newly installed firmware object or images. For example, a cryptographic hash of the image, such as the firmware security descriptor 120. At operation 235 the measurements may be written into one or more secure storage devices, such as one or more secure registers of the device. The secure storage device may be any non-volatile memory that may be protected from access,” [0028] and [0030,0031] describe how this value is utilized to verify the updated firmware and notably is left empty if the firmware is not updated; this teaches that a value stored in this register indicates the mode switch to the updated firmware, reading on the limitation of the claim).
Regarding claim 10, Orlando teaches the memory system of claim 9, wherein the processing circuitry is further configured to cause the memory system to:
receive, after receiving the indication of the second firmware mode, a reset command (“Once the secure storage devices are written with the measurement, the firmware update process is completed at operation 240 and the device is reset at operation 245,” [0028]); and
determine, based at least in part on the reset command, that the mode switch information indicates the mode switch, wherein transitioning from the first firmware mode to the management mode is based at least in part on identifying the mode switch information (“FIG. 3 illustrates an authenticity check method 300 according to some examples of the present disclosure. After the device resets at operation 310 (continuing, in some examples, from operation 245 of FIG. 2), the device enters the secure boot stage 315,” [0029], with [0030,0031] describing the mode switch information being utilized to verify the updated firmware before utilizing it in the device).
Regarding claim 11, Orlando teaches the memory system of claim 9, wherein the processing circuitry is further configured to cause the memory system to:
modify a value of the mode switch information based at least in part on transitioning from the first firmware mode to the management mode, wherein the modified mode switch information indicates that the memory system is operating in the management mode (in the process described in the claim 9 rationale citing to [0028], the register is only written to in the firmware update mode, see “At operation 210, the firmware update process on a device is started. For example, another device issues a firmware update command and supplies an updated firmware object. This may cause the device to go into a firmware update mode where other operations are suspended,” [0025]; necessarily, the ability to write a value to the register during measuring the updated firmware is necessarily indicative that the memory system is operating in the reduced update mode, reading on the limitation).
Regarding claim 12, Orlando teaches the memory system of claim 11, wherein the processing circuitry is further configured to cause the memory system to:
transition from a first power state to a second power state based at least in part on an asynchronous power loss at the memory system, the second power state greater than the first power state (“At operation 210, the firmware update process on a device is started. For example, another device issues a firmware update command and supplies an updated firmware object. This may cause the device to go into a firmware update mode where other operations are suspended. In some examples, the device may reboot to enter this mode,” [0025], teaching that the device reboots; while the device reboots, power is momentarily lost, and so necessarily the rebooted state operates at a higher power state); and
operate in the management mode after transitioning from the first power state to the second power state based at least in part on modifying the mode switch information (as the reboot occurs in operation 210, then the update mode is utilized after rebooting, see also [0025], as the update mode includes the process of Figs. 2 and 3, including the recording of values into the register as cited in [0028] and discussed in the claims 9 and 11 rationales, then the operation of the update mode is necessarily based at least in part on this modification of the register value).
Regarding claim 13, Orlando teaches the memory system of claim 9, wherein the mode switch information is stored to non-volatile memory of the memory system (“At operation 235 the measurements may be written into one or more secure storage devices, such as one or more secure registers of the device. The secure storage device may be any non-volatile memory that may be protected from access. Examples include one or more registers, fuses, e-fuses, anti-fuses, replay-protected memory blocks (RPMB), flash memory cells, magnetic memory cells, or the like,” [0028]).
Regarding claim 14, Orlando teaches the memory system of claim 1, wherein operating in the management mode comprises suspending one or more flash translation layer modules of the memory system, synchronizing one or more write cursors of the memory system, updating block retirement information of the memory system, resetting a logical-to-physical mapping for the memory system, resetting data stored to one or more datastores of the memory system, setting one or more datastore states of the memory system, flushing one or more portions of data to non-volatile memory of the memory system, or any combination thereof (as cited in the claim 1 rationale, [0025] provides that “This may cause the device to go into a firmware update mode where other operations are suspended,” where operations of the memory controller include accessing the memory array and providing a translation layer, see [0038], so suspending other operations includes suspending the translation layer, reading on the limitation of the claim).
Claim 20 recites a method claim identical to the functional configuration of the processing circuitry of claim 1 and may therefore be rejected according to the same rationale of claim 1.
Claim 22 is rejected according to the same rationale of claim 3.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 2, 7, 8, 15-19, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Orlando in view of Watt (US 11,099,828, as provided in applicant’s IDS).
Regarding claim 2, Orlando teaches the memory system of claim 1, wherein the processing circuitry is further configured to cause the memory system to:
perform the one or more verification operations according to the management mode (Orlando Figs. 2 and 3);
Orlando fails to teach wherein the processing circuitry is further configured to:
receive, based at least in part on the one or more verification operations and a threshold time period, a command to adjust one or more namespaces associated with the first firmware mode, wherein determining whether to transition from the management mode to the second firmware mode is further based at least in part on the command;
adjust the one or more namespaces based at least in part on the command; and
transition from the management mode to the second firmware mode based at least in part on adjusting the one or more namespaces.
Watt’s disclosure is related to providing updates to firmware and as such comprises analogous art in the same field of endeavor.
As part of this disclosure, Watt discloses how as part of a firmware update process in Figs. 3A and 3B, the memory system blocks are analyzed for whether any adjustments are needed. In particular, when a namespace format is required, the firmware update system may make the namespace inaccessible in order to reformat the metadata with the updated metadata structure such that the resulting metadata block is compatible with the updated firmware, see Col. 15, Lines 9-35.
An obvious modification can be identified: incorporating Watt’s process of iterating through a memory array and ensuring that namespaces are properly formatted for a resulting firmware into Orlando’s firmware verification process. Such a modification reads upon the limitation of the claim, as Watt’s process of checking and reformatting metadata for proper namespace formats reads upon the reception of the command and performing the command of adjusting namespaces, and as the result in Orlando’s process is to verify updated firmware, then the end result of verifying the updated firmware is based on adjusting the namespaces.
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to incorporate Watt’s disclosure of adjusting block formatting, including adjusting namespaces and making them momentarily inaccessible to reformat them, into Orlando’s process of updating and verifying firmware for accessing memory systems, as this ensures that any updated and verified firmware can properly interact/interface with the memory system.
Regarding claim 7, Orlando teaches the memory system of claim 1, but fails to teach wherein, to determine whether to transition from the management mode to the second firmware mode, the processing circuitry is configured to cause the memory system to:
determine to transition from the management mode to the second firmware mode based at least in part on an absence of namespaces in the memory system, wherein the one or more verification operations comprise a namespace identification operation.
Watt’s disclosure is related to providing updates to firmware and as such comprises analogous art in the same field of endeavor.
As part of this disclosure, Watt discloses how as part of a firmware update process in Figs. 3A and 3B, the memory system blocks are analyzed for whether any adjustments are needed. In particular, when a namespace format is required, the firmware update system may make the namespace inaccessible in order to reformat the metadata with the updated metadata structure such that the resulting metadata block is compatible with the updated firmware, see Col. 15, Lines 9-35.
An obvious modification can be identified: incorporating Watt’s process of iterating through a memory array and ensuring that namespaces are properly formatted for a resulting firmware into Orlando’s firmware verification process. Such a modification reads upon the limitation of the claim, as Watt’s process of checking whether a namespace format is required teaches identifying namespaces, and making them inaccessible if they are necessarily means that the existing namespaces could not properly utilize the firmware, i.e. there is an absence of namespaces compatible with the updated firmware.
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to incorporate Watt’s disclosure of adjusting block formatting, including adjusting namespaces and making them momentarily inaccessible to reformat them, into Orlando’s process of updating and verifying firmware for accessing memory systems, as this ensures that any updated and verified firmware can properly interact/interface with the memory system.
Regarding claim 8, Orlando teaches the memory system of claim 1, but fails to teach wherein the processing circuitry is further configured to cause the memory system to:
detaching, based at least in part on the one or more verification operations and in accordance with operating in the management mode, one or more namespaces from the memory system, wherein determining whether to transition from the management mode to the second firmware mode is based at least in part on detaching the one or more namespaces.
Watt’s disclosure is related to providing updates to firmware and as such comprises analogous art in the same field of endeavor.
As part of this disclosure, Watt discloses how as part of a firmware update process in Figs. 3A and 3B, the memory system blocks are analyzed for whether any adjustments are needed. In particular, when a namespace format is required, the firmware update system may make the namespace inaccessible in order to reformat the metadata with the updated metadata structure such that the resulting metadata block is compatible with the updated firmware, see Col. 15, Lines 9-35.
An obvious modification can be identified: incorporating Watt’s process of iterating through a memory array and ensuring that namespaces are properly formatted for a resulting firmware into Orlando’s firmware verification process. Such a modification reads upon the limitation of the claim, as Watt’s process of rendering namespaces temporarily inaccessible to reformat them reads upon detaching them.
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to incorporate Watt’s disclosure of adjusting block formatting, including adjusting namespaces and making them momentarily inaccessible to reformat them, into Orlando’s process of updating and verifying firmware for accessing memory systems, as this ensures that any updated and verified firmware can properly interact/interface with the memory system.
Regarding claim 15, Orlando teaches a host system (Fig. 4, system environment 400, where “the authentication environment 400 may be a host device and the first computing device 410 and the second computing device 480 may be one or more components of the host device. For example, the first computing device 410 may be a memory device and the second computing device 480 may be a processor,” [0032]), comprising:
one or more interfaces comprising one or more signal paths operable for communications with one or more memory systems (Fig. 4, interface 485, where “First computing device 410 may use the alias, or other key, along with the alias certificate to authenticate 490 with the second computing device 480 across an interface 485… For example, the first computing device 410 may be a memory device and the second computing device 480 may be a processor,” [0032], where Fig. 5 shows memory device more clearly); and
processing circuitry coupled with the one or more interfaces and configured to cause the host system to (Fig. 4, comping device 480 disclosed in [0032] to be a processor):
transmit, to a memory system of the one or more memory systems, an indication of a first firmware mode for subsequent operations by the memory system, wherein the first firmware mode is associated with a first command set for accessing the memory system that is different than a second command set for accessing the memory system according to a second firmware mode used by the memory system prior to transmitting the indication of the first firmware mode (““The operations of FIG. 2 may be performed by the device, for example, in a secure field firmware update process (e.g., a firmware update component 190 of FIG. 1), implemented by, for example, a firmware update component 190. At operation 210, the firmware update process on a device is started. For example, another device issues a firmware update command and supplies an updated firmware object,” [0025], where ““First computing device 410 may include a firmware layer 422, a layer zero code 414, a DICE layer 412, and a firmware updater 416 (which may be part of the DICE layer 412, or the firmware layer 422). In some examples, the firmware update process may be done inside firmware 422 and the cryptographic validation performed by the firmware updater 416. Firmware layer 422 may be an example of updatable device firmware 122 of FIG. 1. Firmware layer 422 may provide low-level control of the hardware of the device and in some examples may manage the device. In some examples, additional layers above the firmware layer 422 may be present and may utilize interfaces to the hardware provided by the firmware. In other examples, the firmware layer 422 may provide the software instructions to control the device, e.g., perform operations specified by the memory controller 515 of FIG. 5,” [0034], where [0038] clarifies that this firmware is used to access the memory array, teaching that the original firmware reads upon the second firmware mode and the updated firmware reads upon the first firmware mode);
monitor for one or more indications associated with a management mode of the memory system, wherein the management mode is associated with a reduced command set for accessing the memory system during a firmware mode transition (“This may cause the device to go into a firmware update mode where other operations are suspended,” [0025], Figs. 2 and 3 demonstrate a process to authenticate the firmware in a DICE or layer 0 code to authenticate the firmware before updating it, see also [0025-0031]; based on the verification operations, an alert may be sent by the memory system if the authentication of the updated firmware fails, see [0023]); and
Orlando fails to teach the host system configured to:
determine, based at least in part on the one or more indications, whether to transmit, to the memory system, a command to adjust a plurality of namespaces of the memory system and complete the firmware mode transition to the first firmware mode for the subsequent operations.
Watt’s disclosure is related to providing updates to firmware and as such comprises analogous art in the same field of endeavor.
As part of this disclosure, Watt discloses how as part of a firmware update process in Figs. 3A and 3B, the memory system blocks are analyzed for whether any adjustments are needed. In particular, when a namespace format is required, the firmware update system may make the namespace inaccessible in order to reformat the metadata with the updated metadata structure such that the resulting metadata block is compatible with the updated firmware, see Col. 15, Lines 9-35.
An obvious modification can be identified: incorporating Watt’s process of iterating through a memory array and ensuring that namespaces are properly formatted for a resulting firmware into Orlando’s firmware verification process. Such a modification reads upon the limitation of the claim, as Watt’s process of checking and reformatting metadata for proper namespace formats reads upon the command to adjust the namespaces, and as this is part of the verification process, then the result is that the firmware mode transition will complete transition.
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to incorporate Watt’s disclosure of adjusting block formatting, including adjusting namespaces and making them momentarily inaccessible to reformat them, into Orlando’s process of updating and verifying firmware for accessing memory systems, as this ensures that any updated and verified firmware can properly interact/interface with the memory system.
Regarding claim 16, the combination of Orlando and Watt teaches the host system of claim 15, wherein the one or more indications comprise a threshold time period (the time to alert a user is related to a failure to attestation in Orlando, see [0023], so necessarily when the firmware update mode finishes, then a time period has elapsed, reading on a threshold time), and the processing circuitry is further configured to cause the host system to:
transmit, based at least in part on an absence of signaling from the memory system during the threshold time period, the command to adjust the plurality of namespaces of the memory system and complete the firmware mode transition to the first firmware mode for the subsequent operations (following the rationale of claim 15, Orlando [0023] only provides an alert if the attestation fails, so then the continuation of the process to transition the firmware finishes if there are no signals received, i.e. an absence of signaling, reading on the limitation of the claim).
Regarding claim 17, the combination of Orlando and Watt teaches the host system of claim 15, wherein the processing circuitry is further configured to cause the host system to:
receive, based at least in part on monitoring for the one or more indications, a second indication that the memory system does not support the first firmware mode (“Upon first boot after the update, a firmware update checker (e.g., firmware update check component 140), compares a measurement of the firmware object that is booted (e.g., the firmware security descriptor 120) with the value stored in the secure storage device (e.g., register 135). If the values match, the alias certificate may be regenerated (e.g., via a regeneration signal), and the boot continues. If the values do not match, then the alias certificate may not be regenerated, and the system may have an authenticity failure because the key and the certificate do not match. The system may take steps to alert a user, management device, or the like of the failure. In some examples, the device may halt and may refuse to load the invalid firmware,” [0023], see also [0030,0031]); and
transmit, based at least in part on receiving the second indication, a third indication of the first firmware mode for the subsequent operations by the memory system ([0023] and [0031] refer to halting operations to prevent loading the updated firmware; necessarily, this would cause the device to revert to the previous version of the firmware, reading on this limitation).
Regarding claim 18, the combination of Orlando and Watt teaches the host system of claim 15, wherein the processing circuitry is further configured to cause the host system to:
transmit, after transmitting the indication of the first firmware mode, a second command to reset the memory system (“Once the secure storage devices are written with the measurement, the firmware update process is completed at operation 240 and the device is reset at operation 245,” [0028]), wherein monitoring for the one or more indications associated with the management mode is based at least in part on the second command (“FIG. 3 illustrates an authenticity check method 300 according to some examples of the present disclosure. After the device resets at operation 310 (continuing, in some examples, from operation 245 of FIG. 2), the device enters the secure boot stage 315,” [0029], with [0030,0031] describing the mode switch information being utilized to verify the updated firmware before utilizing it in the device, with the alert of [0023] relating to the failure of attestation in this step).
Regarding claim 19, the combination of Orlando and Watt teaches the host system of claim 15, wherein the command to adjust the plurality of namespaces of the memory system indicates to delete the plurality of namespaces of the memory system (following the rationale of claim 15, Watt provides the ability to temporarily render namespaces inaccessible in order to reformat them, reading on deleting the namespaces, as the previous format is deleted/no longer valid).
Claim 21 is rejected according to the same rationale of claim 2.
Claims 4-6 and 23-25 are rejected under 35 U.S.C. 103 as being unpatentable over Orlando in view of Harada et al. (US 2019/0377569).
Regarding claim 4, Orlando teaches the memory system of claim 1, but fails to teach wherein, to determine whether to transition from the management mode to the second firmware mode, the processing circuitry is configured to cause the memory system to:
determine, based at least in part on the one or more verification operations and in accordance with operating in the management mode, whether a quantity of available blocks in the memory system satisfies a threshold quantity associated with the transition to the second firmware mode.
Examiner does note that Orlando does disclose storing information related to firmware in non-volatile memory including flash memory cells, see [0028], where [0042,0043] disclose arranging flash memory cells in units such as blocks.
Harada’s disclosure relates to updating firmware, and as such comprises analogous art in the same field of endeavor.
As part of this disclosure, Harada discloses determining whether or not sufficient space exists in a destination for the post-update firmware, see Fig. 3 step 103 and [0098].
An obvious modification can be identified: incorporating Harada’s disclosure to check whether there is sufficient space in the destination for firmware related information into Orlando’s process. Such a modification reads upon the limitation of the claim.
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to incorporate Harada’s process of checking for sufficient space into Orlando’s firmware authentication process, as this can provide another way to check if a firmware is authorized/authenticated and make sure that an update doesn’t interrupt the normal operation of the memory system.
Regarding claim 5, the combination of Orlando and Harada teaches the memory system of claim 4, wherein the processing circuitry is further configured to cause the memory system to:
determine that the quantity of available blocks satisfies the threshold quantity (following the rationale of claim 4, Harada Fig. 3 step 103 yes branch shows a determination that there is sufficient space); and
transition from the management mode to the second firmware mode based at least in part on a command and the quantity of available blocks satisfying the threshold quantity (following the yes branch, Harada Fig. 3 continues with Harada’s verification process; this teaches that when incorporated into Orlando’s verification process, then a determination that there is sufficient space leads to continuation of the other verification steps, which can ultimately lead to the transition to the updated firmware).
Regarding claim 6, the combination of Orlando and Harada teaches the memory system of claim 4, wherein the processing circuitry is further configured to cause the memory system to:
determine that the quantity of available blocks does not satisfy the threshold quantity (following the claim 4 rationale, Harada Fig. 3, step 103 no branch is a determination that there is insufficient space for the firmware);
transmit, based at least in part on determining that the quantity of available blocks does not satisfy the threshold quantity, a second indication that the memory system does not support the transition from the first firmware mode to the second firmware mode (“If the post-update firmware is determined to have an abnormality, processing is performed that returns the execution result of the post-update firmware to a former state, restarts the optical access device, and the like,” Harada [0097] teaches that as a consequence of the no branch, the goal is to return the firmware to the previous version, based on Orlando [0023], this is similar to when authentication fails and the system alerts a user/management device and also halts/refuses to load the invalid firmware, with the alerting reading on the transmission specifically);
receive, based at least in part on transmitting the second indication, a third indication of the first firmware mode (“If the post-update firmware is determined to have an abnormality, processing is performed that returns the execution result of the post-update firmware to a former state, restarts the optical access device, and the like,” Harada [0097] teaches that as a consequence of the no branch, the goal is to return the firmware to the previous version, based on Orlando [0023], this is similar to when authentication fails and the system alerts a user/management device and also halts/refuses to load the invalid firmware, where there is necessarily an indication received to also return to the previous version of the firmware); and
transition from the management mode to the first firmware mode based at least in part on the third indication (“If the post-update firmware is determined to have an abnormality, processing is performed that returns the execution result of the post-update firmware to a former state, restarts the optical access device, and the like,” Harada [0097] teaches that as a consequence of the no branch, the goal is to return the firmware to the previous version, based on Orlando [0023], this is similar to when authentication fails and the system alerts a user/management device and also halts/refuses to load the invalid firmware).
Claims 23-25 are rejected according to the same rationale of claims 4-6.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Jayarchandran et al. (US 12,455,967), Narasimhan et al. (US 2020/0356357), and Suryanarayana et al. (US 2023/0112734) disclose checking for available space for firmware updates,
Chen et al. (US 2011/0119662, as disclosed in applicant’s IDS) discloses verifying updated firmware,
Lakkakula et al. (US 2023/0195899) discloses verifying firmware versions when executing on a platform,
Zhao et al. (CN 117707436) discloses switching firmware modes for operating SSD command sets, including where one mode includes managing namespaces.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AARON D HO whose telephone number is (469)295-9093. The examiner can normally be reached Mon-Fri 8:00-4:00 CT.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Reginald Bragdon can be reached at (571)272-4204. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
/A.D.H./Examiner, Art Unit 2139
/REGINALD G BRAGDON/Supervisory Patent Examiner, Art Unit 2139
Prosecution Insights