Prosecution Insights
Last updated: October 01, 2026
Application No. 18/634,701

MEMORY SYSTEMS, OPERATION METHODS THEREOF, READABLE STORAGE MEDIA, AND SYSTEMS

Final Rejection §103
Filed
Apr 12, 2024
Priority
Nov 30, 2023 — CN 202311647171.9
Examiner
WHEATON, BRADFORD F
Art Unit
2193
Tech Center
2100 — Computer Architecture & Software
Assignee
Yangtze Memory Technologies Co., Ltd.
OA Round
2 (Final)
62%
Grant Probability
Moderate
3-4
OA Rounds
1y 5m
Est. Remaining
73%
With Interview

Examiner Intelligence

Grants 62% of resolved cases
62%
Career Allowance Rate
243 granted / 395 resolved
+6.5% vs TC avg
Moderate +11% lift
Without
With
+11.2%
Interview Lift
resolved cases with interview
Typical timeline
3y 10m
Avg Prosecution
23 currently pending
Career history
425
Total Applications
across all art units

Statute-Specific Performance

§101
18.4%
-21.6% vs TC avg
§103
68.3%
+28.3% vs TC avg
§102
2.1%
-37.9% vs TC avg
§112
8.9%
-31.1% vs TC avg
Black line = Tech Center average estimate • Based on career data from 395 resolved cases

Office Action

§103
DETAILED ACTION Claims 1-20 are pending in the current application. 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 . Response to Arguments Applicant’s arguments, see Remarks, filed 7/16/26, with respect to the rejection of claim 1 under 103 argument have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Mondello et al. (Pub. No. US 2018/0373598 A1) [0012] lines 1-28 and [0019] lines 1-13 which shows that the memory system can have a specific reserve/hidden memory region that stores backup of firmware/second firmware on the device to replace memory content firmware causing the issue where it is seen in the teachings of Yamaoka [0087] lines 1-9, [0095] lines 4-10, [0233] lines 1-3 and [0234] lines 1-6 that in response to firmware not activating and running properly previous firmware still stored and know to work will be started so operations can continue, viewed as load and run firmware two/previous version of firmware where is response to activating the rollback firmware a region storing firmware can be set as writable/overwriting/replacing firmware stored in that region and the teachings of Park [0127] lines 1-8, [0128] lines 1-9, [0131] lines 1-4, [0135] lines 1-9 and [0137] lines 1-8 show the specifics of replacing in its memory slot/location/region update firmware that had issuing running with previously stored firmware that ran correctly and thus together show replacing the first firmware stored in the first memory region with the second firmware after the second firmware stored in the second memory region is loaded and run, wherein the second memory region is invisible to a user and backs up a version of firmware that is being run currently by the memory system. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The 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, 6, 9-10, 12 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Yamaoka et al. (Pub. No. US 2022/0091839 A1) in view of Park (Pub. No. US 2020/0201617 A1) and further in view of Mondello et al. (Pub. No. US 2018/0373598 A1). As to claims 1 and 10 Yamaoka discloses a memory system, comprising: a memory device, comprising a first memory region and a second memory region, wherein the first memory region is different from the second memory region (Yamaoka [0066] lines 1-6 and [0068] lines 1-4; which shows storage/memory with a plurality of different storage regions that can store one piece of firmware each region); and run second firmware stored in the second memory region when first firmware stored in the first memory region fails to be run after the first firmware has been successfully activated and the memory system has rebooted to run the first firmware, wherein the first firmware is firmware that is to be run by the memory system after firmware upgrade, and the second firmware is firmware that is normally run by the memory system before the firmware upgrade (Yamaoka [0066] lines 1-6, [0068] lines 1-4, [0069] lines 1-3, [0087] lines 1-9, [0088] lines 1-8, [0090] lines 1-6,, [0095] lines 4-10, [0233] lines 1-3 and [0234] lines 1-6; which shows a plurality of firmware stored in separate storage/memory regions and in response to failure of new/update firmware, viewed as first firmware stored in firmware memory region stored in its own storage/memory region to run/operate normally after it has been installed and CPU restarted/rebooted viewed as after successful activation, the memory monitor starts/loads/runs/activates alternative firmware in its separate memory region, viewed as second firmware/rollback firmware stored in its own separate memory region and overwrite/replace other firmware stored in other firmware regions once backup/rollback firmware is active). Yamaoka does not specifically disclose a memory controller, coupled with the memory device and configured to: replace the first firmware stored in the first memory region with the second firmware after the second firmware stored in the second memory region is loaded and run. However, Park disclose a memory controller, coupled with the memory device and configured to (Park [0006] lines 1-15 and [0035] lines 1-3; which shows a controller connect/coupled and used to control the memory device): replace the first firmware stored in the first memory region with the second firmware after the second firmware stored in the second memory region is loaded and run (Park [0127] lines 1-8, [0128] lines 1-9, [0131] lines 1-4, [0135] lines 1-9 and [0137] lines 1-8; which shows in response to a firmware update failure copying firmware of past versions that have previously run stored in their own memory block to memory block location where update/upgrade firmware was stored, viewed as replacing first firmware in first memory region/block with second/previous firmware that in light of the teachings of Yamaoka above showing the activating and running of the second firmware in its second/separate region after a failure of the first firmware that can further include after activating overwriting another firmware stored in a separate memory region can together show replace the first firmware stored in the first memory region with the second firmware after the second firmware stored in the second memory region is loaded and run). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Park showing the replacing firmware in different memory regions based on success into the firmware updating while maintaining two different firmware versions in different memory regions of Yamaoka for the purpose of helping to keep firmware secured during updating, as taught by Park [0112] lines 1-5. Yamaoka as modified by Park do not specifically disclose the specifics wherein the second memory region is invisible to a user and backs up a version of firmware that is being run currently by the memory system. However, Mondello discloses the specifics wherein the second memory region is invisible to a user and backs up a version of firmware that is being run currently by the memory system (Mondello [0012] lines 1-28 and [0019] lines 1-13; which shows that the memory system can have a specific reserve/hidden memory region that stores backup of firmware/second firmware on the device to replace memory content firmware causing the issue). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Mondello showing the specifics of hidden memory regions storing backup firmware for use into the using of backup/recovery firmware in different memory region when active firmware in different memory region is problematic of Yamaoka as modified by Park for the purpose of increasing security to limiting how backup firmware data can be accessed as taught by Mondello [0012] lines 20-32. As to claims 3 and 12, Yamaoka does not specifically disclose, however, Park discloses wherein the memory controller is configured to: replace the second firmware stored in the second memory region with the first firmware when the first firmware stored in the first memory region is run successfully (Park [0127] lines 1-8, [0128] lines 1-9 and [0129] lines 1-8; which shows in response to firmware update success update/replace the firmware stored in the second memory block with the updated firmware from the first memory block). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Park showing the replacing firmware in different memory regions based on success into the firmware updating while maintaining two different firmware versions in different memory regions of Yamaoka for the purpose of helping to keep firmware secured during updating, as taught by Park [0112] lines 1-5. As to claims 6 and 15 Yamaoka does not specifically disclose, however, Park discloses wherein the memory device comprises memory blocks, and the second memory region is located in a memory block of the memory blocks that is configured to store code data (Park [0004] lines 4-6 and [0006] lines 1-12; which shows blocks of memory/memory blocks/regions that stores firmware that can be stored as software/code data in memory). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Park showing the replacing firmware in different memory regions based on success into the firmware updating while maintaining two different firmware versions in different memory regions of Yamaoka for the purpose of helping to keep firmware secured during updating, as taught by Park [0112] lines 1-5. As to claim 9, Yamaoka does not specifically disclose, however, Park discloses wherein the memory system comprises a solid state drive (SSD) (Park [0003] lines 1-8; which shows that the storage devices/memory can include solid state drives). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Park showing the replacing firmware in different memory regions based on success into the firmware updating while maintaining two different firmware versions in different memory regions of Yamaoka for the purpose of helping to keep firmware secured during updating, as taught by Park [0112] lines 1-5. Claims 2, 11, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Yamaoka, Park and Mondello as applied to claims 1 and 10 above, and further in view of Dawes et al. (Pub. No. US 2020/0296009 A1). As to claims 2 and 11, Yamaoka as modified by Park and Mondello do not specifically disclose wherein the memory controller is configured to: send an asynchronous event when the first firmware stored in the first memory region fails to be run, wherein the asynchronous event comprises at least a reason why the first firmware fails to be run after reboot. However, Dawes discloses wherein the memory controller is configured to: send an asynchronous event when the first firmware stored in the first memory region fails to be run, wherein the asynchronous event comprises at least a reason why the first firmware fails to be run after reboot (Dawes [0426] lines 1-15, [0485] lines1-3 and [0488] lines 1-6; which shows the system has an asynchronous error status delivery, viewed as sending asynchronous event with error/failure information where the errors can includes firmware upgrade errors where error status that can include associated error code/reason). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Dawes showing asynchronous event delivery into the firmware update events of Yamaoka as modified by Park and Mondello for the purpose of increasing the adaptability of the system and resilience by asynchronous event notifications, as taught by Dawes [0426] lines 1-15. As to claim 18, Yamaoka discloses a system, comprising: a host, configured to (Yamaoka [0052] lines 1-3, [0053] lines 1-12 and [0062] lines 1-4; which shows terminal device with CPU that is used to implement functions commands): send a firmware upgrade command to a memory system (Yamaoka [0066] lines 1-6, [0068] lines 1-4, [0069] lines 1-3 and [0088] lines 1-6; which shows the memory system that stores firmware where the firmware memory can receive an update notification/command for new/update firmware); and in response to the firmware upgrade command, run second firmware stored in a second memory region of the memory system when first firmware stored in a first memory region of the memory system fails to be run after the first firmware has been successfully activated and the memory system has rebooted to run the first firmware wherein the first firmware is firmware that is to be run by the memory system after firmware upgrade, and the second firmware is firmware that is normally run by the memory system before the firmware upgrade (Yamaoka [0066] lines 1-6, [0068] lines 1-4, [0069] lines 1-3, [0087] lines 1-9, [0088] lines 1-8, [0090] lines 1-6,, [0095] lines 4-10, [0233] lines 1-3 and [0234] lines 1-6; which shows a plurality of firmware stored in separate storage/memory regions and in response to failure of new/update firmware, viewed as first firmware stored in firmware memory region stored in its own storage/memory region to run/operate normally after it has been installed and CPU restarted/rebooted viewed as after successful activation, the memory monitor starts/loads/runs/activates alternative firmware in its separate memory region, viewed as second firmware/rollback firmware, firmware normally run before the update/upgrade, stored in its own separate memory region and overwrite/replace other firmware stored in other firmware regions once backup/rollback firmware is active). Yamaoka does not specifically disclose the memory system, coupled with the host and configured to: replace the first firmware stored in the first memory region with the second firmware after the second firmware stored in the second memory region is loaded and run; and replace the second firmware stored in the second memory region with the first firmware when the first firmware stored in the first memory region is run successfully. However, Park discloses the memory system, coupled with the host and configured to: replace the first firmware stored in the first memory region with the second firmware after the second firmware stored in the second memory region is loaded and run (Park [0127] lines 1-8, [0128] lines 1-9, [0131] lines 1-4, [0135] lines 1-9 and [0137] lines 1-8; which shows in response to a firmware update failure copying firmware of past versions that have previously run stored in their own memory block to memory block location where update/upgrade firmware was stored, viewed as replacing first firmware in first memory region/block with second/previous firmware that in light of the teachings of Yamaoka above showing the activating and running of the second firmware in its second/separate region after a failure of the first firmware that can further include after activating overwriting another firmware stored in a separate memory region can together show replace the first firmware stored in the first memory region with the second firmware after the second firmware stored in the second memory region is loaded and run); replace the second firmware stored in the second memory region with the first firmware when the first firmware stored in the first memory region is run successfully (Park [0127] lines 1-8, [0128] lines 1-9 and [0129] lines 1-8; which shows in response to firmware update success update/replace the firmware stored in the second memory block with the updated firmware from the first memory block). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Park showing the replacing firmware in different memory regions based on success into the firmware updating while maintaining two different firmware versions in different memory regions of Yamaoka for the purpose of helping to keep firmware secured during updating, as taught by Park [0112] lines 1-5. Yamaoka as modified by Park do not specifically disclose the specifics wherein the second memory region is invisible to a user and backs up a version of firmware that is being run currently by the memory system. However, Mondello discloses the specifics wherein the second memory region is invisible to a user and backs up a version of firmware that is being run currently by the memory system (Mondello [0012] lines 1-28 and [0019] lines 1-13; which shows that the memory system can have a specific reserve/hidden memory region that stores backup of firmware/second firmware on the device to replace memory content firmware causing the issue). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Mondello showing the specifics of hidden memory regions storing backup firmware for use into the using of backup/recovery firmware in different memory region when active firmware in different memory region is problematic of Yamaoka as modified by Park for the purpose of increasing security to limiting how backup firmware data can be accessed as taught by Mondello [0012] lines 20-32 Yamaoka as modified by Park and Mondello does not specifically disclose send an asynchronous event when the first firmware stored in the first memory region fails to be run, wherein the asynchronous event comprises at least a reason why the first firmware fails to be run after reboot However, Dawes discloses send an asynchronous event when the first firmware stored in the first memory region fails to be run, wherein the asynchronous event comprises at least a reason why the first firmware fails to be run after reboot (Dawes [0426] lines 1-15, [0485] lines1-3 and [0488] lines 1-6; which shows the system has an asynchronous error status delivery, viewed as sending asynchronous event with error/failure information where the errors can includes firmware upgrade errors where error status that can include associated error code/reason). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Dawes showing asynchronous event delivery into the firmware update events of Yamaoka as modified by Park and Mondello for the purpose of increasing the adaptability of the system and resilience by asynchronous event notifications, as taught by Dawes [0426] lines 1-15. As to claim 20, Yamaoka does not specifically disclose, however, Park discloses wherein the memory system comprises a solid state drive (SSD) (Park [0003] lines 1-8; which shows that the storage devices/memory can include solid state drives). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Park showing the replacing firmware in different memory regions based on success into the firmware updating while maintaining two different firmware versions in different memory regions of Yamaoka for the purpose of helping to keep firmware secured during updating, as taught by Park [0112] lines 1-5. Claims 4-5 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Yamaoka, Park and Mondello as applied to claims 3 and 12 above, and further in view of Escofet Via et al. (Pub. No. US 2020/0249934 A1) and further in view of Gavens et al. (Pub. No. US 2008/0109897 A1) As to claims 4 and 13 Yamaoka as modified by Park and Monello do not specifically disclose wherein the memory controller is configured to: obtain a firmware running state of the memory system after the memory system is rebooted; update the firmware running state from a first state to a second state and run the first firmware in the first memory region when the firmware running state is in the first state; and update the firmware running state from the second state to the first state and update the second firmware stored in the second memory region with the first firmware when the first firmware is run successfully. However, Escofet Via discloses update the firmware running state from a first state to a second state and run the first firmware in the first memory region when the firmware running state is in the first state (Escofet Via [0032] lines 1-15 and [0034] lines 1-11; which shows having active firmware memory area and other/free memory areas and being able to update being able to dynamically selecting and transition/updating the different memory areas between active/free viewed as the firmware running state and update/transition the firmware running state, where the active memory area has specific firmware stored and run in the active memory region area thus having a first firmware in a first memory region when the first memory region is the active region/first state). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Escofet Via showing the specifics of updating a firmware stored in a specific region with another firmware, into the firmware update management of Yamaoka as modified by Park and Mondello for the purpose of increasing the adaptability of updating firmware without going offline, as taught by Escofet Via [0001] lines 13-19 and [0039] lines 1-17 Yamaoka as modified by Park, Mondello and Escofet Via do not specifically disclose wherein the memory controller is configured to: obtain a firmware running state of the memory system after the memory system is rebooted; and update the firmware running state from the second state to the first state and update the second firmware stored in the second memory region with the first firmware when the first firmware is run successfully. However, Gavens discloses wherein the memory controller is configured to: obtain a firmware running state of the memory system after the memory system is rebooted (Gavens [0024] lines 1-15, [0028] lines 1-8 and [0034] lines 1-13; which shows in response to reboot associated with the memory system being able to determine the upgrade state of the system, where the upgrade state is used by the phased upgrade controller and firmware selector to select memory locations for primary and second firmware and mode of operation thus viewed as a type of firmware running state of the memory system); and update the firmware running state from the second state to the first state and update the second firmware stored in the second memory region with the first firmware when the first firmware is run successfully (Gavens [0024] lines 1-15, [0028] lines 1-8, [0034] lines 1-13, [0037] lines 1-16 and [0040] lines 15-21; which shows being able to translation from one firmware upgrade state to another based on determine firmware update passes validation and able to run, viewed as update the firmware running state from the second to the first state and in response to that being able to update the other/primary/second firmware version stored, with the updated validated first firmware, the specifics of the first and second firmware stored in individual regions seen specifically disclosed above in the teachings of Yamaoka). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Gavens showing the specifics of updating firmware running state based on firmware update validation information into the firmware updating of Yamaoka as modified by Park, Mondello and Escofet Via for the purpose of improving the efficiency of upgrading firmware by keeping track of firmware update state information to not repeat already completed successful steps if disruption occurs during update, as taught by Gavens [0030] lines 1-11. As to claims 5 and 14 of Yamaoka as modified by Park and Mondello do not specifically disclose, however, Escofet Via discloses wherein the memory controller is configured to: keep the firmware running state in the second state when the first firmware fails to be run (Escofet Via [0032] lines 1-15 and [0034] lines 1-11; which shows being able to switch active memory area for the executing firmware and being able to switch it when incoming/new/upgraded firmware is determined to be stored and valid for execution in the free memory area thus if firmware fails to run, not valid, would maintain the same firmware running state of memory as the active memory area). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Escofet Via showing the specifics of updating a firmware stored in a specific region with another firmware, into the firmware update management of Yamaoka as modified by Park and Mondello for the purpose of increasing the adaptability of updating firmware without going offline, as taught by Escofet Via [0001] lines 13-19 and [0039] lines 1-17 Yamaoka as modified by Park, Mondello and Escofet Via do not specifically disclose re-obtain the firmware running state of the memory system after the memory system is rebooted again, and run the second firmware stored in the second memory region when the firmware running state is in the second state; and update the firmware running state from the second state to the first state and update the first firmware stored in the first memory region with the second firmware when the second firmware stored in the second memory region is run successfully. However, Gavens discloses re-obtain the firmware running state of the memory system after the memory system is rebooted again, and run the second firmware stored in the second memory region when the firmware running state is in the second state (Gavens [0024] lines 1-15, [0026] lines 1-5, [0028] lines 1-8, [0034] lines 1-13, [0036] lines 1-11, [0037] lines 1-16 and [0038] lines 1-20; which shows after another reboot being able to determine if the firmware is valid, determine the upgrade state/mode of the system, where the update state/mode is used by the phased upgrade controller and firmware selector to select/determine memory locations for primary and second firmware and mode of operation for the firmware in those location, viewed as in functional and upgrade mode for the memory area/state, and when state is not valid, update failure, the functional/active/execution firmware memory region is not switch thus execution firmware running in the functional mode stays running in the functional mode and associated active area and is not switched, in light of Escofet Via teachings above for the specifics of active/running memory area and free area/memory state information can together be viewed as showing the specifics of re-obtain the firmware running state of the memory system after the memory system is rebooted again, and run the second firmware stored in the second memory region when the firmware running state is in the second state); and update the firmware running state from the second state to the first state and update the first firmware stored in the first memory region with the second firmware when the second firmware stored in the second memory region is run successfully (Gavens [0018] lines 1-5 [0024] lines 1-15, [0026] lines 1-5, [0028] lines 1-8, [0034] lines 1-13, [0036] lines 1-11, [0037] lines 1-16 and [0038] lines 1-20; which show after upgrade failure of firmware, fallback recovery is performed where primary firmware copy/second firmware is written into the erased location of second firmware copy/first firmware, viewed as updating the first firmware stored in its first memory region with the second firmware from its/second memory region, that in light of Escofet Via teachings above for the specifics of active/running memory area and free area/memory state information and being able to swap/switch between them and the teachings of Yamaoka showing the activating and running backup/rollback/second firmware in its region while making other firmware regions available for rewriting/overwriting can be viewed together as showing update the firmware running state from the second state to the first state and update the first firmware stored in the first memory region with the second firmware when the second firmware stored in the second memory region is run successfully). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Gavens showing the specifics of updating firmware running state based on firmware update validation information into the firmware updating of Yamaoka as modified by Park, Mondello and Escofet Via for the purpose of improving the efficiency of upgrading firmware by keeping track of firmware update state information to not repeat already completed successful steps if disruption occurs during update, as taught by Gavens [0030] lines 1-11. Claims 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Yamaoka, Park and Mondello as applied to claims 1 and 10 above, and further in view of Escofet Via et al. (Pub. No. US 2020/0249934 A1). As to claims 7 and 16 Yamaoka as modified by Park and Mondello do not specifically disclose wherein the memory controller is configured to: update the second firmware stored in the first memory region with the first firmware before the first firmware is run; and send an error message when the update with the first firmware in the first memory region fails, wherein the error message indicates an error state that the first firmware fails to be activated. However, Escofet Via disclose wherein the memory controller is configured to: update the second firmware stored in the first memory region with the first firmware before the first firmware is run; and send an error message when the update with the first firmware in the first memory region fails, wherein the error message indicates an error state that the first firmware fails to be activated (Escofet Via [0039] lines 1-17, [0041] lines 1-14, [0045] lines 1-23 and [0047] lines 1-16; which shows for firmware stored in different memory regions being able to replace a firmware, viewed as second firmware, stored in one/first memory region with an updated version of the firmware, viewed as first firmware, before the update firmware is selected and used to operate the device, viewed as before it is run and the ability to send an error message from the device after it has received the last data packet for the update and attempted to initiate it but not received an acknowledgment signal where the error message indicates a failed firmware upgrade attempt based on fail acknowledgment of activation). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Escofet Via showing the specifics of updating a firmware stored in a specific region with another firmware, into the firmware update management of Yamaoka as modified by Park and Mondello for the purpose of increasing the adaptability of updating firmware without going offline, as taught by Escofet Via [0001] lines 13-19 and [0039] lines 1-17 Claims 8 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Yamaoka, Park, Mondello and Escofet Via as applied to claims 7 and 16 above, and further in view of Wu et al. (Pub. No. US 2022/0121607 A1) As to claims 8 and 17 Yamaoka as modified by Park, Mondello and Escofet Via do not specifically disclose wherein the memory controller is configured to: update the second firmware in the first memory region with the first firmware through a high-speed serial computer extended bus PCIe. However, Wu discloses wherein the memory controller is configured to: update the second firmware in the first memory region with the first firmware through a high-speed serial computer extended bus PCIe (Wu [0008] lines 3-11; which shows the specifics of being able to communicate with memory through a high-speed serial computer extended bus with standard PCIe protocol, with the specifics of update the second firmware in the first memory region with the first firmware seen specifically disclosed above in the teachings of Escofet Via above and together show wherein the memory controller is configured to: update the second firmware in the first memory region with the first firmware through a high-speed serial computer extended bus PCIe). Therefore , it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Wu showing the specifics of communication through a high-speed serial computer extended bus PCIe into the communication with memory of Yamaoka as modified by Park, Mondello and Escofet Via to increase the adaptability and speed of communication of information between system elements, as taught by Wu [0008] lines 3-11. Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Yamaoka, Park, Mondello and Dawes as applied to claim 18 above, and further in view of Escofet Via et al. (Pub. No. US 2020/0249934 A1). As to claim 19 Yamaoka does not specifically disclose, however, Park discloses wherein the host is configured to: download the first firmware from a server and send the downloaded first firmware to the memory system before the memory system runs the first firmware (Park [0004] lines 6-8, [0045] lines 1-3 and [0053] lines 1-8; which shows being able to update/control memory based on request from host that can include the download and sending a firmware update/first firmware from an external device/server to the memory system and thus since it is a new/update to firmware viewed as done before the memory system runs the new/update/first firmware). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Park showing the replacing firmware in different memory regions based on success into the firmware updating while maintaining two different firmware versions in different memory regions of Yamaoka for the purpose of helping to keep firmware secured during updating, as taught by Park [0112] lines 1-5. Yamaoka as modified by Park, Mondello and Dawes do not specifically disclose the memory system is configured to: activate the first firmware, and update with the first firmware in the first memory region when the first firmware is successfully activated; and send an error message to the host when the first firmware fails to be activated, wherein the error message indicates an error state that the first firmware fails to be activated However, Escofet Via disclose the memory system is configured to: activate the first firmware, and update with the first firmware in the first memory region when the first firmware is successfully activated; and send an error message to the host when the first firmware fails to be activated, wherein the error message indicates an error state that the first firmware fails to be activated (Escofet Via [0032] lines 1-15, [0034] lines 1-11 [0039] lines 1-17, [0041] lines 1-14, [0045] lines 1-23 and [0047] lines 1-16; which shows for firmware stored in different memory regions being able to replace a firmware in different memory regions with update/first firmware where the memory regions can be set to active or free, where the active area is the actively running area where once the update/first firmware is confirmed as valid and can execute a firmware switch making it the active memory region and viewed as activate of the first/update firmware thus viewed as update with the first firmware in the first memory region when the first firmware is successfully activated and shows the ability to send an error message from the device after it has received the last data packet for the update and attempted to initiate it but not received an acknowledgment signal where the error message indicates a failed firmware upgrade attempt based on fail acknowledgment of activation, viewed as an error state showing firmware failed to activate). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Escofet Via showing the specifics of updating a firmware stored in a specific region with another firmware, into the firmware update management of Yamaoka as modified by Park, Mondello and Dawes for the purpose of increasing the adaptability of updating firmware without going offline, as taught by Escofet Via [0001] lines 13-19 and [0039] lines 1-17 Conclusion Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRADFORD F WHEATON whose telephone number is (571)270-1779. The examiner can normally be reached Monday-Friday 8:00-5:00 EST. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chat Do can be reached at 571-272-3721. 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. /BRADFORD F WHEATON/Examiner, Art Unit 2193
Read full office action

Prosecution Timeline

Apr 12, 2024
Application Filed
Apr 15, 2026
Non-Final Rejection mailed — §103
Jul 16, 2026
Response Filed
Sep 14, 2026
Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12737177
ISOLATED ENVIRONMENT PROVISIONING IN SERVICE MESH-BASED MICROSERVICES SYSTEMS
3y 8m to grant Granted Sep 15, 2026
Patent 12737276
MULTI-LAYER INTERACTION AND CODE EXAMINER FOR N-TIER ARCHITECTURE APPLICATIONS
3y 1m to grant Granted Sep 15, 2026
Patent 12717700
APPLICATION DEBUGING METHOD AND ELECTRONIC DEVICE
3y 3m to grant Granted Aug 25, 2026
Patent 12705160
MANAGING COMPUTING RESOURCE CONSUMPTION OF SOFTWARE APPLICATIONS USING CONTROL GROUPS TO FACILITATE SAFETY COMPLIANCE
2y 8m to grant Granted Aug 11, 2026
Patent 12699769
DYNAMIC RUNTIME MICRO-SEGMENTATION OF INTERPRETED LANGUAGES
3y 2m to grant Granted Aug 04, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
62%
Grant Probability
73%
With Interview (+11.2%)
3y 10m (~1y 5m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 395 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month