DETAILED ACTION
Remarks
Applicant’s amendment and response dated 12/30/2025 has been provided in response to the 10/2/2025 Office Action which rejected claims 1-10, wherein claims 1 and 6 have been amended. Thus, claims 1-10 remain pending in this application and have been fully considered by the examiner.
Applicant’s arguments with respect to claims have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Claim Objections
Claims 1-10 are objected to because of the following informalities:
“the requested hardware configuration” in lines 17-18 of claims 1 and 6 lacks proper antecedent basis.
Claim 5, line 3, after “implement”, replace “a” with --the--.
Claim 10, line 1, replace “an” with --the--.
Claims 2-4 and 7-9 depend on the objected claims and inherit the same issue.
Appropriate correction is required.
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-10 are rejected under 35 U.S.C. 103 as being unpatentable over Hoffman et al. (US Patent Application Publication 2015/0007155 A1) in view of Benisty et al. (US Patent Application Publication 2019/0286581 A1) and Kim (US Patent Application Publication 2020/0012490 A1).
As to claim 1, Hoffman teaches a method for managing a memory area (e.g. memory 36) of an electronic control unit (e.g. module 22) of a motor vehicle (e.g. vehicle 12, see Figs.1 and 2 and associated text), said electronic control unit comprising a microcontroller (e.g. processor 38), and a memory area (e.g. memory 36), said microcontroller being configured to receive, from an external software maintenance tool (e.g. controller 20), a request to update an application installed in a space of the memory area (e.g. old files 34) with a target application (e.g. new file 50, see e.g. [0014]- facilitating updates by replacing, modifying, re-flashing, re-configuring, re-calibrating or otherwise manipulating computer-readable instructions, software, code or other logically executing or logically controllable features of the module 22 according to the files or other data provided from the server 14 and [0020]- the controller 20, for example, may be configured to retrieve the identifying information by the logger 46 and to communicate this information to the server 14 in order to query the server 14 or to otherwise facilitate identifying whether one or more of the modules 22 require one or more of the old files 34 to be updated; In the event an update is desirable, the server 14 can provide corresponding instructions and/or the necessary files to the controller 20 to facilitate the desired update) and to execute instructions contained in a bootloader module implemented by said microcontroller and instructions of the application contained in the space of the memory area (See e.g. [0021]- Instructions may be provided from the controller 20 to facilitate replacing the old file 34 and/or the module 20 may include a boot loader or other application sufficient to facilitate the update upon receipt of the new file 50), said method comprising:
receiving a first request for updating the installed application from a first set of control instructions (e.g. new file 50, see e.g. [0014]- facilitating updates by replacing, modifying, re-flashing, re-configuring, re-calibrating or otherwise manipulating computer-readable instructions, software, code or other logically executing or logically controllable features of the module 22 according to the files or other data provided from the server 14 and [0020]- the controller 20, for example, may be configured to retrieve the identifying information by the logger 46 and to communicate this information to the server 14 in order to query the server 14 or to otherwise facilitate identifying whether one or more of the modules 22 require one or more of the old files 34 to be updated; In the event an update is desirable, the server 14 can provide corresponding instructions and/or the necessary files to the controller 20 to facilitate the desired update), with said first set of control instructions being configured to be implemented with the current hardware configuration of the electronic control unit (see e.g. [0015]- These modules 22 may be originally manufactured with files sufficient to direct their operation, [0020]- the logger 46 may be configured to keep track of the files, versions of the files or other representations (identifications, revisions, etc.) of the files in order to track the currently installed files and [0049]- The SWID and/or the UUID may include information regarding a class of hardware, which may be crossed-referenced with other information to facilitate the update according to hardware limitations or other restrictions associated with the module, such as protocol requirements, signaling limitations, etc),
implementing the first set of control instructions by the bootloader module following the reception of said first request (see e.g. [0015]- These modules 22 may be originally manufactured with files sufficient to direct their operation);
invalidating (e.g. deleting/replacing) the first set of control instructions following modification of the current hardware configuration (See e.g. [0021]- A first update 54 is shown to correspond with the new file 50 provided from the controller 20 being stored within the module memory 36 in place of one of the old files 34, i.e., one of the old files 34 is deleted and replaced with the new file 50. Instructions may be provided from the controller 20 to facilitate replacing the old file 34 and/or the module 20 may include a boot loader or other application sufficient to facilitate the update upon receipt of the new file 50),
resetting the bootloader module (See Fig.7 and associated text, e.g. [0048]- Reference 182 relates to a controller or other device tasked with facilitating the update of a module powering on or otherwise entering a mode of operation amenable to being updated. Reference 184 relates to a controller reboot triggering entry into Reference 182; Reference 198 relates to installing a secondary boot loader on the module or other construct on the module to enable it to perform the update while replacing its previous operating system or other controlling mechanism,)
receiving a second request for updating the installed application from a second set of control instructions with said second set of control instructions being configured to be implemented with the modified hardware configuration of the electronic control unit (See e.g. [0050]- Reference 194 relates to the controller entering a module programming mode. The module programming mode may relate to the controller testing communications or otherwise assessing whether the module is ready to be updated; Reference 196 relates to subsequently unlocking module security limitations, exchanging keys or enabling other security measures to allow the module memory to be updated, e.g., a code or other certificate may be required before the module will allow itself to be updated) and implementing the second set of control instructions by the bootloader module following the reception of said second request (see e.g. [0050]- The secondary bootloader may operate in place of a primary operating system (OS) previously operating on the module, e.g., the primary OS may require alteration according to the update specified within the agenda such that the secondary bootloader may be temporarily used in order to permit the primary OS to be updated. The secondary bootloader may include instructions or other operands sufficient to facilitate controlling the module or otherwise enabling the module updating operations and to validate the update of the application in order to implement it during the next boot (See e.g. [0060]- Reference 230 relates to confirming module validity following completion of the desired operations. The validity determination may include the controller and/or the server testing the module or performing other operations associated with assessing whether the programming phase has been successful. Reference 232 relates to resetting the module in the event the programming is confirmed, which may include rebooting or otherwise instructing the module to cease operating according to the secondary boot loader and begin operating according to its primary OS).
Hoffman teaches the electronic control unit (see Fig.1 and associated text, e.g. [0015]), does not specifically teach a plurality of hardware registers, with the hardware registers being adapted to be placed in various positions defining the current hardware configuration, modifying the current hardware configuration so as to make it identical to the requested hardware configuration for installing the update of the installed application, or with the second set of control instructions being configured to check that the hardware configuration requested by the application update is identical to the modified hardware configuration.
In an analogous art of updating software/firmware, however, Benisty teaches a plurality of hardware registers (see Fig.1, 116 and associated text, e.g. [0034]- the data storage controller 106 controls access by the host to physical memory registers 116 within the data storage controller 106, with the hardware registers being adapted to be placed in various positions defining the current hardware configuration (see e.g.[0040]- The hardware registers of the data storage controller are configured based in the specifications and requirements of Version 1), modifying the current hardware configuration so as to make the current hardware configuration identical to a requested hardware configuration for installing an update of the installed application (See e.g. Figs.2-4 and associated text, e.g.[0040]- To accommodate any changes to the registers within Version 2, the software (and/or firmware) of the data storage controller is designed or modified to addresses the changes in the hardware registers from Version 1 to Version 2. For example, the software may employ lookup tables of the like that provide a software version of the configuration of the hardware registers as specified in Version 2. That is, to accommodate Version 2, the software of the data storage controller emulates the hardware registers of Version 2 (even though the actual hardware of the data storage controller remains unchanged from its original version and [0049]- If the revisions can be accommodated, as determined at decision block 406, the engineers/designers modify the software/firmware of the device, at block 408, to emulate the operations of any revised hardware registers and configure an arbiter (or multiplexer) to route corresponding host register transaction requests to the processor) and with a second set of control instructions (e.g. Version 2) being configured to check that the hardware configuration requested by the application update is identical to the modified hardware configuration (see e.g. [0041]- if a transaction is received from a host (where the host is programmed in accordance with Version 2) and the transaction is directed to a hardware register that was reserved in Version 1, the transaction will be routed to the processor of the data storage controller by the arbiter (since it is considered a special transaction); if the register is no longer marked as reserved in Version 2, but now has been given a function, i.e. a change has been made to that particular register from Version 1 to Version 2, the software will cause the data storage controller to respond by performing whatever function has been specified by Version 2 (by, for example, returning the latest stored values from that register if the transaction was read transaction). Hence the software will cause the data storage controller to respond in the same manner as if the hardware of the data storage controller had been modified in accordance with Version 2 and the transaction had been sent via hardware to a hardware register configured in accordance with Version 2. In either case, the emulation operations of the software/firmware of the data storage controller are transparent to the host, which will receive the appropriate response as if the hardware registers of the data storage controller were configured in accordance with Version 2).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method/system of Hoffman to incorporate/implement the limitations as taught by Benisty in order to provide a more efficient and cost-effective method/system of updating software/hardware configurations of devices to accommodate new features as they are developed.
Hoffman in view of Benisty teaches the first set of control instructions (see e.g. [0015]), but does not specifically teach adjusting one or more of the plurality of hardware registers so as to make the current hardware configuration identical to the requested hardware configuration.
In an analogous art of updating software/firmware, however, Kim teaches adjusting one or more of a plurality of hardware registers so as to make a current hardware configuration identical to a requested hardware configuration (See e.g. Figs. 2A and 6 and associated text, e.g. [0096]- The firmware generator 250 may change the firmware such that the register setting information and the firmware execution code branch information are reflected thereto according to the revision result), [0097]- as shown in FIG. 2A, the register setting information may include the register names R1 to Rn, addresses (e.g., start address and offset), an attribute (i.e., whether being readable/writable (R/W)), a register description (or function), and a reset value. Further, the register setting information may include a detailed description and a reset value assigned to each bit with respect to each of the registers R1 to Rn, [0098]- the firmware (i.e., binary file) may include the register setting information and the firmware execution code branch information for each flag attribute. The changed firmware may be stored with the flag attribute information).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method/system of Hoffman in view of Benisty to incorporate/implement the limitations as taught by Kim in order to provide a more efficient method/system of managing firmware product revisions as they are released.
As to claim 2, Benisty further teaches wherein with the first set of control instructions comprising a command library (e.g. lookup table) configured to modify the hardware registers, said library is implemented when the first set of control instructions is executed (See e.g. [0040]- The hardware registers of the data storage controller are configured based in the specifications and requirements of Version 1. To accommodate any changes to the registers within Version 2, the software (and/or firmware) of the data storage controller is designed or modified to addresses the changes in the hardware registers from Version 1 to Version 2. For example, the software may employ lookup tables of the like that provide a software version of the configuration of the hardware registers as specified in Version 2. That is, to accommodate Version 2, the software of the data storage controller emulates the hardware registers of Version 2 (even though the actual hardware of the data storage controller remains unchanged from its original version).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method/system of Hoffman to incorporate/implement the limitations as taught by Benisty in order to provide a more efficient and cost-effective method/system of updating software/hardware configurations of devices to accommodate new features as they are developed.
As to claim 3, Hoffman also teaches with the second set of control instructions allowing the first set of control instructions to be deleted, the method comprises a step of deleting the first set of control instructions (See e.g. [0021]- A first update 54 is shown to correspond with the new file 50 provided from the controller 20 being stored within the module memory 36 in place of one of the old files 34, i.e., one of the old files 34 is deleted and replaced with the new file 50).
As to claim 4, Hoffman also teaches wherein invalidating the first set of control instructions involves reactivating the bootloader module so that said bootloader module completes the update of the application (see e.g. [0060]- reference 232 relates to resetting the module in the event the programming is confirmed, which may include rebooting or otherwise instructing the module to cease operating according to the secondary boot loader and begin operating according to its primary OS).
As to claim 5, Hoffman teaches a non-transitory computer program product comprising a set of program code instructions that, when executed by one or more processors, configure the one or more processors to implement a method as claimed in claim 1 (see e.g. [0028] - The method may be embodied in non-transitory computer-readable medium or computer-program product of the controller, server, module and/or other feature, having computer-readable instructions, operable with a processor or other element, sufficient to facilitate controlling the controller, server, etc. to achieve or otherwise undertake the operations contemplated herein).
As to claim 6, the limitations of claim 6 are substantially similar to the limitations of method claim 1, and therefore, it is rejected for the reasons stated above.
As to claim 7, the limitations of claim 7 are substantially similar to the limitations of method claim 2, and therefore, it is rejected for the reasons stated above.
As to claim 8, the limitations of claim 8 are substantially similar to the limitations of method claim 3, and therefore, it is rejected for the reasons stated above.
As to claim 9, the limitations of claim 9 are substantially similar to the limitations of method claim 4, and therefore, it is rejected for the reasons stated above.
As to claim 10, Hoffman also teaches a motor vehicle comprising an electronic control unit as claimed in claim 6 (see Fig.1 and associated text).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHENECA SMITH whose telephone number is (571)270-1651. The examiner can normally be reached Mon-Fri 8:00AM-4:30PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hyung S Sough can be reached at 571-272-6799. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHENECA SMITH/Examiner, Art Unit 2192
/S. Sough/SPE, Art Unit 2192
Prosecution Insights