DETAILED ACTION
This action is responsive to the Applicant’s response filed 12/22/25.
As indicated in Applicant’s response, claims 9, 17 have been amended, and claims 14-15 cancelled. Claims 1-13, 16-29 are pending a next office action.
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.
Claims 1-7, 9-10, 16-20, 24-26 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Tasher et al, TW 1676116, (translation), 11-01-2019, 20 pgs (herein Tasher) in view of Rosner et al, USPubN: 2020/0301698 (herein Rosner)
As per claims 1 and 2, Tasher discloses a system, comprising: memory including a first physical address space (first data, first physical storage, physical address space - top pg. 3) and a second physical address space (second data, physical storage, location address space - top pg. 3);
a memory mapper coupled to the memory, the memory mapper configured to convert logical addresses to physical addresses (mapping is performed ... between physical address ... and the logical address - top pg. 3; address mapper 88 maps the logical address LA1 to physical address PA1, address mapper ... to map address LA1 to ... address PA2 - pg. 11-12); and
a processor coupled to the memory mapper (mapper 88- bottom pg. 13), the processor configured to:
execute a first resource using a first logical address mapped by the memory mapper to the first
physical address space (version stored in SEC_1P, the mapper maps address LA1 to ... address PA1 - top pg. 12); and
executing a firmware update resource (stored data typically includes ... operating system boot
code, firmware - middle pg. 7; host 28 includes ... boot loader function, firmware - pg. 6);
cause a second resource to be stored in the second physical address space (updated version APP 1 to PA2 of ... location SEC_2P - bottom pg. 14 – Note1: update version stored at PA2 prior to be remapped reads on execution of an update as a second resource at PA2 to be soon remapped – see remaps - top pg. 15 - to LAl at which the first resource was logically allocated);
remap the first logical address to the second physical address space (version ... stored in memory
SEC _2P ... accessed by the address mapper and ... map the logical address LAl to the physical
address PA2 - middle pg. 12) using the memory mapper (see above);
execute the second resource using the first logical address (writes the update version ... to SEC_lP by using mapper to map logical address LA2 to the physical address PAl - middle pg.12; map the logical addresses LAl and LA2 to the corresponding ... PAl and PA2 - bottom pg. 13).
A) Tasher does not explicitly disclose processor and memory configured to
remap the first logical address to the second physical address while the processor is executing a firmware update resource
wherein the memory further includes a third physical address configured to store the firmware update resource.
Downloaded update versions of respective applications in Tasher are stored with memory chip associated with FPGA (pg. 13), according to which, different versions are identifiable with their labels in sections of a non-volatile memory such that downloaded content can be stored in a compact disc or serial bus storage from a provider, the respective updated version (APPl, VERl, or APP2, VER2) acquired to replace the current APP version stored at one of the location (pg. 8) after proper security key check (pg. 9); hence updated versions being stored in first, second or third physical address is recognized.
Storing downloaded firmware for updates verification and for subsequent logical-to-physical address remap is shown in Rosner disclosure of an over-the-air update (Fig. IA; Fig. 9-10), where the downloaded firmware can be stored as images at different physical locations (para 0027, 0037) of a non-volatile memory of a host system, according to which, the host controller accesses the firmware in non-volatile memory array by a LA[Wingdings font/0xE0]PA (para 0029-0031) remap using a remap data structure (Fig. 3-4; para 0049-0050), and so, in the sense that the firmware images are stored as different locations or physical array or pools to be cycled by the remapping process (Figs. 6-7).
Hence executing firmware update per a OTA mode while effecting a remap – referred herein as (*) - using different physical locations – as in Rosner - at which a firmware has been stored on a host system entails memory of the OTA update provided as to include a firmware update resource at a first, a second, and third physical address.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective
filing date of the invention to implement the update remap in Tasher so that the remap is effectuated while update is being performed - as per (*) - on basis of downloaded update onto a host storage such as in Rosner firmware update in the sense that host storage designated for such firmware update can include one or more firmware update resources at a third physical address among other physical addresses- as shown in Rosner; because
firmware contains drivers or utility SW that are required for handling functionalities of a large number of processor or OS devices, and applications, and provision of remote download in
conjunction with physical storage at a receiving host in form of multiple storage locations or structured memory addresses along with pre-arranged meta-information, or labeling as set forth
above, would provide operational flexibility to a host controller in being able to secure downloaded update instances in well-defined locations, to differentiate between versions of update in accordance to their address identification and usage, to seek and fetch a specific version at the indicated meta-location, to validate/verify it against security/integrity attack prior to its use, to remedy to a faulty version whose location is to be remapped, to manage relevant metadata and re-organize versions of firmware thus stored before and after each update in order to consolidate their status for further corrective rewrites, for a back-up duplicate role or recovery purposes in case of installation faults.
B) Nor does Tasher explicitly disclose
processor executing the second resource after the remap LA2 to LA1 as processor to execute the second resource using the first logical address in a first mode of operation; and thereafter, execute the second resource using the first logical address in a second mode of operation.
Rosner discloses a firmware update process that starts with accessing a firmware image by a
controller executing a instruction that makes a new mapped location live, by way of programming a
logical-to-physical mapping LA_FW=PAy (para 0035-0039) instruction that stores remapping information into a remap data structure (Fig. 1A, 1B, 1C) and makes the newly acquired FW image at PAy live while rendering the old firmware at PAx invalid. Thus, a LA➔PA mapping instance supporting a mode of operation as part of a update process so to activate a new FW in rendering its newly mapped address valid while invalidating the old FW physical address is recognized.
Further, Rosner discloses that once the new image becomes valid can be used for the immediate FW update but can remain so ( valid new entry) even in response to other predetermined conditions: a new power up reset or when a predetermined value is being written into a configurator register of the memory system, or memory device receiving a different instruction (para 0040)
Hence, use of remapping LA1➔PA2 to render active a mapped LA at a new physical address can be used for a different mode of operation after that of the firmware update, including operations affected by a power reset, by a new value written to configurator register, or a different instruction received into a instruction memory of the system, as shown in Rosner.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective
filing date of the invention to implement a memory mapper so that a LA-to-PA mapping operation
directed to execute a newly acquired (second) resource can be employed not just for logically
activating execution of the second resource from its new physical location in a firmware update
mode as in Rosner; but also for supporting one or more modes of operations (second mode) that also operate on the mapped location (of the second resource), subsequent to the initial use of the LA-PA mapping- as shown in Rosner from above; because
configuring a mapper so to afford immediate and extended use over the very state of a memory address mapping (per a LA-PA mechanism as set forth above) would enable selection at first a specific physical location of choice by the system with which to store resource for a destined
execution (in support for a specific mode of operation such as FW download and configuration for
update), and accordingly, so long as the location of resources set by said LA-PA mechanism has not
been altered, the resulting physical address of the resource can be extended for secure access by
additional operations or I/O calls by the host OS, even under a given mode of operation different
from the initial update mode of the host runtime, and so, without having the system to verify each
time on programming pointer reference with respect to the physical locations at which a resource
set under a previous logical mapping (e.g. firmware) is still available or accessible - e.g. for
realizing a given but different mode of operation such as power reset sequence, advent of new value
written to configurator register, or receipt of a different instruction into the system instruction
memory, as illustrated in Rosner - so to minimize unnecessary delay by the system in fulfilling a mode of operation the urgency of which most often necessitates prompt resolution.
As per claims 3-4, Tasher discloses system of claim 1, wherein the processor is configured to
perform an authentication of the second resource (signature of APPl, step 100, step 112, receives an updated version APP l ', security key KEYl ... calculate signature on APPl' and VERl ', VERI' ➔ VERI- pg.13-14; top pg. 15) before remapping the first logical address to the second physical address space;
perform an integrity validation of the second resource (replaces the current version with the
received version ... only after confirming the integrity and authenticity of the received version -
pg.12) before remapping the first logical address to the second physical address space.
As per claims 5-6, Tasher discloses system of claim 1, wherein the processor is configured to perform a functional validation of the second resource (security key KEYl ... calculate signature on APPl' and VERl', VERl' ➔ VERI- pg. 14; top pg. 15; pg. 11; verify that only updates ... true and newer than the currently stored copy will be installed - pg. 7) before remapping the first logical address to the second physical address space.
wherein the processor is configured to:
before remapping the first logical address to the second physical address space (refer to claim 1), execute a validation resource using a second logical address to perform the functional validation of the second resource at the second physical address space (security key KEY 1 ... calculate
signature on APPl' and VERl', VERl'➔VERl - pg.13-14; top pg. 15; write updated version ... with a security key ... verifying ... against their respective signatures ... checking that the version identifier ... is newer than the version ... currently used version - bottom pg. 11); and
in response to a successful functional validation of the second resource (only after confirming the
integrity and authenticity of the received version - pg. 12), remap the first logical
address to the second physical address space (refer to claim l; exchanges logical-physical address mappings to replace the stored data with updated versions - pg. 11).
As per claim 7, Tasher does not explicitly disclose system of claim 1, wherein the processor is configured to remap the first logical address from the second physical address space back to the first physical address space in response to a fault during execution of the second resource.
In Tasher, as LAl (logical address of the current code) is being mapped to PAl (current physical address of the code prior to update) before an update is triggered (pg. 12) and that a successful update is expected to remap LAl to the new physical location PA2 (where a update resides) and LA2 (logical addr. of the update) to the old physical location PAl (middle pg. 12), it is self-evident or obvious that an unsuccessful or faulty update should be reversed in order to perform roll-back; that is, a corrective remap should bring the original logical addresses LAl and LA2 back to their respective physical addresses of PAl and PA2; meaning that first logical address (LAl) from the
second physical address (PA2) is to be remapped back to the first physical address (PAl) as part of a roll back.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective
filing date of the invention to implement control of the memory remap in Tasher such that processor
thereof would be configured to remap the first logical address (LAl) from the second physical
address (PA2) back to the first physical address (PAl) in response to a fault during execution of
the second resource - as set forth above; because
a incomplete process not accomplishing logical-to-physical translation of addresses by a memory remap underlying memory section rewrites as set forth above cannot be left in the state of improper logical-to-physical addresses conversion as this indirection effect can create dire runtime pointer crash at the lower level I/O or BIOS of the operating system, whereas a successful rollback that properly remaps software entity from its current logical memory address to its initial physical address would at least reset the system back to their restored known or seemingly status-quo state.
As per claim 9, Tasher discloses system of claim 1, wherein the first logical address mapped to the first physical address space corresponds to a first instruction of the first resource (first data,
first physical storage, physical address space - top pg. 3; LAl is used to read currently installed APPl - pg. 12 - Note2: a range of physical address covering span of software bytes reads on start of physical memory of the software being a first address pointing to the first byte or instruction of that software resource memory range; see most significant bit SEC_IP and SEC_2P of the physical address space - bottom pg. 12), and the first logical address mapped to the second physical address space corresponds to a first instruction of the second resource (second data, physical storage, location address space - top pg. 3; updated version of APP1 (or APP2) - pg. 8; refer to Note2).
As per claim 10, Tasher does not explicitly disclose system of claim 1, wherein a size of the first physical address space is different from a size of the second physical address space.
However, since a second physical address space is destined to receive updated version of the
current version residing in the first physical address space, the size difference between the update version and the current version is largely expected since an update cannot be identical in size and functional scope to its original version as construed from version differential check in Tasher (see VER1’ ➔ VERl - pg. 8); that is, size of the second physical address space being different to accommodate a update version of the content previous assigned to the first address space is
recognized.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective
filing date of the invention to configure or pre-allocate physical address space in Tasher system so that a size of the first physical address space is different from a size of the second physical address space; because the second address space is specifically destined to accommodate storage of a update version (VERl ') to a current version (VERl) for which the update is to replace, so to necessarily improve upon the version currently residing in the first address space.
As per claim 16, Tasher discloses system of claim 1 wherein the processor is configured to remap the first logical address (refer to claim 1) to the second physical address space by:
providing an address in the second physical address space (map the logical address LA1 to ... PA2 - pg. 12) to the memory mapper (mapper 88 – pg. 13); and
asserting a swap signal to cause (remaps the logical-physical address exchange for the role between the two storage spaces - pg. 5) the memory mapper to select a conversion of the first logical
address to the address in the second physical address space (exchange step 216 - pg. 15) instead of a conversion of the first logical address to an address in the first physical address space.
As per claims 17-18, Tasher discloses an integrated circuit (IC integrated circuit - pg. 13; l2C, IDE - pg. 6), comprising: a memory mapper (mapper 88 – pg. 13) configured to convert logical addresses to physical addresses; and a processor coupled to the memory mapper, the processor configured to:
execute a first resource using a first logical address mapped by the memory mapper to a first
physical address of a memory (refer to claim 1); and
while executing a firmware update resource:
remap (refer to rationale A of claim 1) the first logical address to a second physical address of a second resource (refer to claim 1) using the memory mapper;
execute the second resource using the first logical address (refer to claim 1) in a first mode of operation (refer to rationale B of claim 1); and
execute the second resource using the first logical address in a second mode of operation (refer to rationale B of claim 1)
wherein the IC comprises the memory coupled to (refer to claim 1) the memory mapper (memory controller ... using the address mapper 88 - pg. 12).
As per claims 19-20, Tasher discloses IC of claim 17, wherein the processor is configured to perform an authentication, an integrity validation, or a functional validation of the second resource before remapping (refer to claims 3, 4, 5 from above) the first logical address to the second physical address;
wherein the processor is configured to:
perform an authentication (refer to claim 3), an integrity validation (refer to claim 4), or a functional validation of the second resource (refer to claim 5 or 6 ) after configuring the memory mapper to remap (see before remapping from above) the first logical address to the second physical address;
while executing the firmware update resource, remap (see above) the first logical address back to the first physical address in response to a fault (refer to rationale of claim 6 and 7) of the authentication, integrity validation, or functional validation of the second resource; and
execute the first resource using the first logical address (refer to remap to the first physical address in claim 7).
As per claim 24, Tasher discloses a method, comprising:
executing, by a processor, a first resource using a first logical address mapped to a first
physical address of a memory (refer to claim 1); and
while executing a firmware update resource (refer to rationale A of claim 1) by the processor: remapping the first logical address to a second physical address of the memory (refer to claim 1);
executing, by the processor, a second resource (refer to claim 1) in a first mode of operation (refer to rationale B of claim 1) using the first logical address; and
executing by the processor, the second resource in a second mode of (refer to rationale B of claim 1) operation using the first logical address.
As per claim 25, Tasher discloses method of claim 24, further executing, by the processor, a third resource that performs an authentication, an integrity validation, or a functional validation of the second resource (refer to claims 3-5) before remapping the first logical address to the second
physical address (refer to claim 6).
As per claim 26, Tasher discloses method of claim 24, further comprising:
while executing the firmware update resource by the processor, remapping the first logical address back to the first physical address in response to a fault (refer to rationale of claim 7) of the authentication, integrity validation, or functional validation of the second resource; and
executing, by the processor, the first resource (refer to claim 1) from the first logical address.
D) Tasher does not explicitly disclose
executing, by the processor, a third resource that performs an authentication, an integrity
validation, or a functional validation of the second resource after remapping the first logical
address to the second physical address.
Physical address spaces in Tasher non-volatile memory system are all protected against writes and reads, against which a signature key authentication is to be performed to lock or unlock a storage element for one such J/0 (e.g. write protection, write command includes a corresponding command signature ... security key - pg. 3; pg. 8-9).
In Tasher update scenario, via use of a mapper, redirecting a first logical address (LAl) of the current resource (APPl or VER) to the second physical address (PA2 - bottom pg. 14) destined to receive the updated version of the resource necessarily entails writing the update version (VER') to PA2 via consecutive writes of the update version (APP2) to load physical address space PA2 as part of remap scenario which performs dual mapping of Lal [Wingdings font/0xE0]PA2 and LA2 [Wingdings font/0xE0]PAl (pg.3; LAl, LA2 to map/remap PA2, and PAl - pg. 12). Since each completed write (of a update code) to an address of the second physical storage (PA2) has to be followed with a command signature key associated with permitting (UNLOCK) a next write, performing a authentication (pg. 14-15) that permits each write to overwrite current code in a physical space to load a update entails executing a third resource that performs for each write an authentication, an integrity validation check after each individual instance of remapping of the first logical address to the second physical address - referred herein as (**).
Therefore, based on protection against writes to unlock each attempt to overwrite data in a
protected physical address space in Tasher, it would have been obvious for one of ordinary skill in
the art before the effective filing date of the invention to implement mapper operation in Tasher
so that after each instance of remapping address as part of loading update version into its second
physical address space, the controller is also configured to perform an authentication, an
integrity validation, or a functional validation of the second resource after remapping the first
logical address to the second physical address per (**) as set forth above; because
configuring physical space per effect of overwriting physical memory space in which a current version is stored and protected against write necessitates for each write permission for existing content to be replaced with operation that fulfill a proper signature key validation and configuring a controller to support remap of physical address space by replacing a existing protected resource with new version thereof as set forth in Tasher with controller unlock/lock effect of systematically validating any attempt to write or overwrite physical address space of a protected non-volatile storage in Tasher would ensure that non-authorized writes directed at the physical storage space would be locked away or prevented, which in turn would prepare code loaded in a physical storage (destined for deployment of update) with a measure of guarantee against injected vulnerability issues or malicious data tampering.
Claims 8 is/are rejected under§ 35 U.S.C. 103 as being unpatentable over Tasher et al, TW
1676116, (translation), 11-01-2019, 20 pgs (herein Tasher) in view of Rosner et al, USPubN:
2020/0301698 (herein Rosner) further in view of Barczak et al, USPubN: 2023/0139729 (herein
Barczak)
As per claim 8, Tasher does not explicitly disclose system of claim 1, wherein the processor is configured to cause freeing of memory locations associated with the first resource after remapping the first logic address to the second physical address space.
Barczak discloses translation layer associated with flash memory representing blocks exposed for virtual machines implementation, the translation layer to map logical addresses of virtual machines to physical addresses in the non-volatile memory (para 0034), the translation layer equipped with formation of a mapping table that map logical address with actual clusters in the non-volatile cache (para 0044) such that a check of a entry in the table indicative of a logical block address being unrepresented by a cluster will have for effect to free (para 0043) the cluster from the
mapping followed with updating the table as part of managing free chunks (Fig. 6; Deallocate clusters 704 - Fig. 7) in the non-volatile cache (para 0041); hence, memory resources unused in
accordance with mapping of logical addresses to their physical address being subjected to deallocation or free release by a controller is recognized.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective
filing date of the invention to implement resources reclaiming associated with a memory mapping
underlying software update in Tasher so that the controller associated with remapping between
logical addresses and physical addresses of respective section of memory being rewritten would be
configured to deallocate unused resources or perform freeing of memory locations associated with
the first resource after remapping the first logic address to the second physical address, the
freeing based on logical resources that has not corresponding physical resource therefor as in
Barczak; because
freeing of previously allocated resources that are no longer logically bound with execution of code under coordination of a memory mapper as in Tasher would increase the pool of reusable memory while reducing size of physical resources to be monitored and managed by the system in relation to continual control that check states of newly introduced resources and make adjusts to dynamic changes or logical reallocation of resources in non-volatile memory.
Claims 11 is/are rejected under§ 35 U.S.C. 103 as being unpatentable over Tasher et al, TW
1676116, (translation), 11-01-2019, 20 pgs (herein Tasher) in view of Rosner et al, USPubN:
2020/0301698 (herein Rosner) and further in view of Talagata et al, USPubN: 2013/0332660 (herein
Talagata)
As per claim 11, Tasher does not explicitly disclose system of claim 1, wherein the second resource is a duplicate of the first resource.
Talagata discloses management and extension of non-volatile memory/media for
checkpointing purposes, including controller command to increment references to a same block via a
duplicate write (Fig. 3G) using an index that may reference duplicated data (para 0169) stored as
different location of the media, where extension of the memory includes a module configure to map
copies or clones of data/object, range or the like in response to mmap commands for the same data,
the extension module by way of the clone functionality configured to update, merge or make
modifications to the copies etc. in response to a checkpoint trigger event (para 0107), the
management of extended memory pages to support logical-to-physical (L2P) mapping and tracking
whether the stored bits have been modified, referenced in predefined periods (para 0080); hence
configuration of additional features to clone and duplicate stored data or updates thereof to
accommodate checkpointing or L2P mapping is recognized.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective
filing date of the invention to implement Tasher' s controller system so that a stored resource
such as an updated version can be referenced by one index to more than one location(s) via a
duplicate write command, or via a extension module that copies the stored resource into a clone at
a different location of a non-volatile memory - as in Talagata; because
duplicate copy provided as multiple referencing directed at a same data may mitigate exposure time required for unlocking a memory location to permit a given operation by the controller over data at that location; whereas a clone established a copy of the same data at a different location can boost parallel action of a validation scheme by a non-volatile memory controller, which in part can also reduce wait time imposed upon the systematic process to track or verify integrity of all addresses of identified sectors that would be required to be L2P mapped for some update, checkpointing or data synchronization purposes.
Claims 12, 22-23 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Tasher et
al, TW 1676116, (translation), 11-01-2019, 20 pgs (herein Tasher) in view of Rosner et al, USPubN:2020/0301698 (herein Rosner) and further in view of Seater et al, USPubN: 2020/0257517 (herein Seater)
As per claim 12, Tasher does not explicitly disclose system of claim 1, wherein
C) the processor includes a reset input, wherein the processor is configured to reset responsive to an assertion of the reset input, and wherein the processor is configured to remap the first logical address to the second physical address space and use the second resource while the reset input of the processor remains de-asserted.
Seater discloses firmware update in terms of a host device receiving a notification of a firmware update based on which, an associated memory logic controller triggers a Reset via a Assert signal to cause the host device to power-down and enable a subsequent power-up to reach a stable level, upon which a de-assert Reset signal is provided by the logic controller to indicate that a proper
Reset and power up has been completed without fail, thereafter the device can execute operations
related to the updated firmware (para 0029)
Thus, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement processor controller upon a notification to update firmware so that a reset input is invoked as part of sequence actions taken by the controller, according to which, the processor is configured to reset responsive to an assertion of the reset input, and further configured to invoke a mapper to remap the first logical address to the second physical address as part of the update sequence that uses the second resource (update firmware) to replace a first resource(firmware) while the reset input of the processor remains de-asserted - as shown in Seater Reset assert followed with DEASSERT signal; because
reset assert followed immediately by a Reset Deassert represents a stable situation where a current host is regenerated with sufficient power and stabilized state throughout all layers and components associated with the system in regard to conducting operations or making further manipulation on the state of data as well as protected blocks in non-volatile memory, since a de-asserted Reset will be indicative the host system in a stable state for sustaining operations that require sufficient energy to activate software and I/O transactions and can only be disrupted by asynchronous events as unlikely as fault-induced interruption.
As per claims 22-23, Tasher discloses IC of claim 17, wherein the processor includes a reset input,
wherein the processor is configured to reset responsive to an assertion of the reset input, and wherein the processor is configured to remap the first logical address to the second physical address while the reset input of the processor remains deasserted;
(refer to rationale C of claim 12)
wherein the IC further includes a reset input, and wherein the processor is configured to remap the first logical address to the second physical address while the reset input of the IC remains deasserted (refer to rationale C of claim 12)
Claims 13, 27 is/are rejected under§ 35 U.S.C. 103 as being unpatentable over Tasher et al, TW 1676116, (translation), 11-01-2019, 20 pgs (herein Tasher) in view of Rosner et al, USPubN:
2020/0301698 (herein Rosner) and further in view of Zamir et al, USPubN: 2019/0164610 (herein
Zamir)
As per claim 13, Tasher does not explicitly disclose system of claim 1, wherein the processor is configured to execute instructions based on a clock, and wherein the processor is configured to remap the first logic address to the second physical address space within 1 clock cycle of the clock.
Zamir discloses initializing a logical to physical (L2P) map of logical address space (para 0033) according to a physical memory space which includes a first single-port and a second single-port memory being written with fresh data at respective single-port during the initial mapping period
followed by subsequent writing of fresh data (Figure 16; para 0104) on a clock cycle to whichever
of the first or second single-port memory is not busy with a read command during that clock cycle (para 0109). Hence, the remapping associated with a logical to physical translation by a memory mapper so that each L2P operation during the initial mapping is directed to a respective port of physical memory space so that data being written thereto is within one cycle of clock is recognized.
Hence, as remapping (exchange step 216 - pg. 15) a second resource (update version) to a first physical address (of a current resource) requires loading of data into that said first physical
address space via a write (e.g. writing step 108: write the received data item APP1 to the physical
address PAI - pg. 13-14), it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement time-based configuration for initializing a
remapping by a L2P mapper in Tasher so that controller software therefor is configured to execute
instructions based on a clock, thereby to remap the first logic address to the second physical address within 1 clock cycle of the clock according to initializing technique of mapping in Zamir; because
use of a mapping technique that relies on available and non-busy port of each target address space to map within each clock cycle would require low energy/bias for initializing each entry writing onto single port of a physical address space, the low bias of said write operation due to
exploitation of non-busy port within each a clock cycle averting thereby any contention with any ongoing operation (e.g. a read) that might block a write operation on a same physical address.
As per claim 27, Tasher discloses method of claim 24, wherein remapping the first logic address to the second physical address occurs within 1 clock cycle of a clock of the processor.
(all of which having been addressed in claim 13)
Claims 21 is/are rejected under§ 35 U.S.C. 103 as being unpatentable over Tasher et al, TW
1676116, (translation), 11-01-2019, 20 pgs (herein Tasher). in view of Rosner et al, USPubN:
2020/0301698 (herein Rosner) further in view of Bohannon et al, USPubN: 2002/0091718 (herein
Bohannon)
As per claim 21, Tasher does not explicitly disclose IC of claim 20, wherein, in response to a success of the authentication, integrity validation, or functional validation of the second resource, the processor is configured to change a rollback protection value.
Tasher discloses a package that include a prevention against a verification failure in form of a
rollback check (receives a verification identifier ... a complete update "package" ... and subsequent "rollback protection" - pg. 11)
Bohannon discloses protected region of physical storage under checkpointing, preventive Precheck and recovery system provided with implementation of codeword Scheme (Fig. 3) associated with update of contents (e.g. images ) in the database, where a flag under an applied codeword can be used to indicate a rollback between a begin and end point of a physical update (para 0096) which include possibility of an UNDO or REDO action (para 0098-0099, 0101), such that if modification of a region covered by a codeword results in no rollback where rollback is not occurring, the flag can be dispensed (para 0105); hence rollback protection in form of codeword flag being adjusted with discard of a flag in case of a update operation deemed successful is recognized.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement rollback protection associated with a update package in Tasher' s system so that the control processor in response to a success of the authentication, integrity validation, or functional validation of the second resource, is configured to change a rollback protection value - per a flag remove as set forth in Bohannon when there has been no occurrence of rollback happening; because
performing an authentication, an integrity validation, or a functional validation of the second
resource after remapping the first logical address to the second physical address coupled with roll-back flag setting as a form of programmatic means would enable a extra layer of precaution added to the host system prior for the system to allow ultimate access to the set of physical memory space following a L2P redirection, such that in case of no-fault incurred as part of validating state of recently mapped to physical address, clearing a roll-back (by setting the flag to another value) as set forth above would enable instant disarm the rollback mechanism, which in turn would obviate extraneous resources or effort by the system to initiate recovery of a memory payload to its previous stable state along with the costly undoing of all existing memory references required as part of a physical and logical memory operational roll-back.
Claims 28-29 is/are rejected under§ 35 U.S.C. 103 as being unpatentable over Tasher et al, TW 1676116, (translation), 11-01-2019, 20 pgs (herein Tasher) in view of Rosner et al, USPubN:
2020/0301698 (herein Rosner) further in view of Hutchison et al, USPubN: 2015/0052616 (herein Hutchison) and Cole Jean-Pierre, CA 3231605, 04-6-2023, 127 pgs (herein ColeJP)
As per claims 28-29, Tasher discloses system of claim 1, wherein the processor is configured to perform a first validation of the second resource prior to the remap of the first logical address.
(refer to claims 3, 4, 5).
Tasher does not explicitly disclose
(i) wherein the processor is configured to perform a second validation of the second resource between the execution of the second resource in the first mode of operation and the execution of the second resource in the second mode of operation.
(ii) wherein the first mode of operation corresponds to a reduced functionality mode with respect to the second mode of operation
As for (ii)
Firmware update similar to Tasher or Rosner is disclosed in the mobile/OTA based firmware update by ColeJP in which, prior to activating the update process, a command is directed to put the target device into a "safe" mode with limited operational capabilities (pg. 46, pg. 68) to reduce opportunities of threaded conflicts while freeing up resources for the installation, where resources downloaded for the update undergo integrity checks (pg. 77), e.g. via command from the controller to validate OTA transferred programming data (pg. 50) before the acquired data can be rewritable to one-time programmable memory destined for the update. Hence, first mode of operation for a FW update carried out in a reduced functionality mode as opposed to a full mode is recognized.
As for (i)
Improving chances of access to successfully validated volatile memory respective a given mode of operation of a kernel is disclosed in Hutchison's secure OS using snapshot of the system from storage to invoke a secure reboot using a trusted monitor (TM) in the intended context of loading resources associated with a Windows Safe mode (para 0062, 0086) by the system for security reasons, where need of the validation of the memory is particularly more pronounced when the system performs transition from and to a protected mode (Fig. 1) due to potentially affected regions such as volatile memory of the executing OS (para 0080) according to which, if the validation fails, a trusted monitor responsible for securing a trusted mode of operation can reject access (para 0090) to the resources under consideration for use by the secure OS. Hence, invoking a validation (Fig. 3) prior to using volatile memory resources under a trusted monitor to ensure secure memory states required for transitioning in and out of protected modes of operation by the system entails that use of validation to deny access for memory resources targeted for transition between a restrictively safe mode - safe mode of FW update - and a less safe mode of operation is recognized.
In other words, invoking a validation directed to memory storing downloaded resources as in ColeJP when the system is directed to transit from a FW update in safe mode to a unprotected mode using the same memory resource would have been obvious.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement validation of physical memory in the context of a memory mapping scenario in Tasher so that, during a update operation, subsequent to a first validation of resource due to a first L2P mapping to activate the resource at a second physical address, the processor is configured to further perform a second validation of the second resource between an execution (of the second resource) in the first mode of operation - such as the safe mode of OTA
update in ColeJP - and an execution (of the second resource) in the second mode of operation – per the transition out of protected mode as shown in Hutchison validation from above; because
transition between mode of operations can give way to dangling memory referencing, or undefined I/O, unsecure access by the outside source of infringement to data integrity, or an unbounded status of parameters and/or code calling, such as subsequent to a change of mode such as transit by the system from a secure mode to a unsecure mode, chance of vulnerability and fault in memory state would become more pronounced and instituting a proper validation to check memory state before a mode execution and after a mode execution would be one measure to avert the insecurity threat to active memory space or integrity of their content; e.g. invoking a status check before a safe mode of update- as in ColeJP - utilizes a L2P mapped resource and invoking a second status check prior to remapping the resource to its earlier physical address as shown above would be ensuring that the same resource is integral and consistent in content before and after the transition between a unsafe mode and a safe mode of operation.
Response to Arguments
Applicant's arguments filed 12/22/25 have been fully considered but they are not persuasive. Following are the Examiner’s observations in regard thereto.
(A) Applicants have submitted that using different storage space to enable reading of one version of data item for a first space, and writing another version in a second space to replace a default version initially stored in Tasher cannot teach or suggest, remapping first logical address to a second physical address while executing firmware update by the processor, and executing a second resource in the first mode using the first logical address, and executing the second resource in a second mode using the first logical address (Applicants Remarks pg. 9)
The rejection has pointed out how Tasher performs remap where a first logical address (LA1) is mapped to resource at a second physical address, enabling content at the second physical address (PA2) to be executed as result of the remapping. In regard to executing the second resource at the second physical address pointed by the remapping, per either a first mode of operation or a second mode of operation, the prosecution has proffered Rosner to evidence that remapping LA1➔PA2 to render active a mapped LA at a new physical address can be exercised forward in different modes of operation, first or second mode, using prima facie prongs of a 103 rationale with motivation to combine Rosner approach with the remapping by Tasher. The allegation made on Tasher from above, from a prima facie case standpoint, does not appear to discuss how the teachings by Rosner fail to render executing a resource pointed by a LA1 after a remap LA1 [Wingdings font/0xE0] PA2 in more than one mode of operations (e.g. a FW update mode) obvious (as per the Rationale B of claim 1). Hence, the prima facie case of obviousness as effectuated will stand until otherwise overcome, dismissed via a proper case of rebut by the Applicant, which is not same as merely discussing Tasher as a single reference taken separate from a combination of teachings as presented by the Office Action.
(B) All other claims rejections have not been seen as being objected by the Applicant; thus, their rejected state will stand.
In all, the claims as submitted will stand rejected as set forth above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tuan A Vu whose telephone number is (571) 272-3735. The examiner can normally be reached on 8AM-4:30PM/Mon-Fri.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Chat Do can be reached on (571)272-3721.
The fax phone number for the organization where this application or proceeding is assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571-272-3609.
Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 Group receptionist: 571-272-2100.
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 http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/Tuan A Vu/
Primary Examiner, Art Unit 2193
January 24, 2026