METHOD FOR CHANGING THE MEMORY CONTENT OF A MAIN MEMORY OF A MICROCONTROLLER WITHOUT A SEPARATE MEMORY MANAGEMENT UNIT, USE THEREOF, MICROCONTROLLER AND VEHICLE

§102 §103

DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. Information Disclosure Statement The Information Disclosure Statement filed on 11 April 2025 has been considered by the examiner. Claim Interpretation No claims are interpreted under 35 U.S.C. 112(f). Claim Rejections - 35 USC § 102 The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. Claim(s) 10 and 17 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Rao et al. (U.S. Patent No. 7,472,380). Claim 10: Rao et al. disclose a method for changing memory content of a main memory of a microcontroller without a separate memory management unit, wherein a part of the main memory is occupied by a base firmware, the method comprising [column 1, lines 30-33; column 3, line 35-41 – “Embedded systems (i.e., mobile electronic devices having embedded software/firmware), such as mobile cellular phones, personal digital assistants (PDA's), MP3 players, digital cameras, etc. often contain firmware and/or application software that is either provided by the manufacturers of the electronic devices, telecommunication carriers, or third parties.” … “A device in accordance with an embodiment of the present invention comprises a mobile electronic device having an embedded system capable of employing a component architecture platform (CAP) framework. The device comprises a processor, a reference lookup table management unit, primary memory and secondary memory, and at least one reference lookup table.”]: writing at least one component block into the main memory when the base firmware is inserted into the main memory, wherein the at least one component block comprises memory management information and code components for providing at least one firmware component or at least one application program component [fig. 2B; column 6, lines 30-67 – “FIG. 2B illustrates an exemplary process of generating update packages for updating firmware/software in an embedded system from one version to another version and a process of retrieving and updating the embedded system, in accordance with an embodiment of the present invention. The embedded system may employ a CAP architecture. At block 221, new and old versions of code, such as a collection of code loaded into an embedded system, may be retrieved by a generator environment, for example. The generator environment may determine what modules/component/functions may be added, deleted, or modified between the old and the new versions. Only modules that are added, deleted, or modified may be considered as candidates for inclusion in an update package. At block 223, an update package may be generated and reference lookup table modifications may be determined. Modifications to the reference lookup table may be associated with modules/components/functions that are added, deleted, or modified between the old and new versions. At block 225, an update package may be transferred to the embedded system along with associated reference lookup table modifications. In one embodiment, the update package may comprise the reference lookup table modifications. In another related embodiment, reference lookup table modifications and the update package may be treated as two different but related units of data to be transferred to the embedded system. At block 227, the update agent in the embedded system processes the retrieved update package and associated reference lookup table modifications. The embedded system loads new modules (methods, functions, subroutines, classes, etc.) if any, for the new version of the embedded system being in the update package. The new modules replace existing modules in the embedded system. The update agent in the embedded system also applies modifications to those modules that are to be modified but not replaced. These activities may be only part of an update process facilitated by an update agent in an embedded system.”]; and for changing at least one part of the code components of at least one component block, a processor of the microcontroller processes the memory management information and writes information to be written into the main memory at locations defined by the memory management information, and the memory management information of the changed at least one component block is updated [fig. 2B; column 6, lines 30-67 – “FIG. 2B illustrates an exemplary process of generating update packages for updating firmware/software in an embedded system from one version to another version and a process of retrieving and updating the embedded system, in accordance with an embodiment of the present invention. The embedded system may employ a CAP architecture. At block 221, new and old versions of code, such as a collection of code loaded into an embedded system, may be retrieved by a generator environment, for example. The generator environment may determine what modules/component/functions may be added, deleted, or modified between the old and the new versions. Only modules that are added, deleted, or modified may be considered as candidates for inclusion in an update package. At block 223, an update package may be generated and reference lookup table modifications may be determined. Modifications to the reference lookup table may be associated with modules/components/functions that are added, deleted, or modified between the old and new versions. At block 225, an update package may be transferred to the embedded system along with associated reference lookup table modifications. In one embodiment, the update package may comprise the reference lookup table modifications. In another related embodiment, reference lookup table modifications and the update package may be treated as two different but related units of data to be transferred to the embedded system. At block 227, the update agent in the embedded system processes the retrieved update package and associated reference lookup table modifications. The embedded system loads new modules (methods, functions, subroutines, classes, etc.) if any, for the new version of the embedded system being in the update package. The new modules replace existing modules in the embedded system. The update agent in the embedded system also applies modifications to those modules that are to be modified but not replaced. These activities may be only part of an update process facilitated by an update agent in an embedded system.”]. Claim 17: Rao et al. disclose a microcontroller, comprising: a main memory, wherein the microcontroller does not have a separate memory management unit, wherein a part of the main memory is occupied by a base firmware [column 1, lines 30-33; column 3, line 35-41 – “Embedded systems (i.e., mobile electronic devices having embedded software/firmware), such as mobile cellular phones, personal digital assistants (PDA's), MP3 players, digital cameras, etc. often contain firmware and/or application software that is either provided by the manufacturers of the electronic devices, telecommunication carriers, or third parties.” … “A device in accordance with an embodiment of the present invention comprises a mobile electronic device having an embedded system capable of employing a component architecture platform (CAP) framework. The device comprises a processor, a reference lookup table management unit, primary memory and secondary memory, and at least one reference lookup table.”]; and a processor coupled to the main memory [column 1, lines 30-33; column 3, line 35-41 – “Embedded systems (i.e., mobile electronic devices having embedded software/firmware), such as mobile cellular phones, personal digital assistants (PDA's), MP3 players, digital cameras, etc. often contain firmware and/or application software that is either provided by the manufacturers of the electronic devices, telecommunication carriers, or third parties.” … “A device in accordance with an embodiment of the present invention comprises a mobile electronic device having an embedded system capable of employing a component architecture platform (CAP) framework. The device comprises a processor, a reference lookup table management unit, primary memory and secondary memory, and at least one reference lookup table.”], wherein the microcontroller is configured to write at least one component block into the main memory when the base firmware is inserted into the main memory, wherein the at least one component block comprises memory management information and code components for providing at least one firmware component or at least one application program component [fig. 2B; column 6, lines 30-67 – “FIG. 2B illustrates an exemplary process of generating update packages for updating firmware/software in an embedded system from one version to another version and a process of retrieving and updating the embedded system, in accordance with an embodiment of the present invention. The embedded system may employ a CAP architecture. At block 221, new and old versions of code, such as a collection of code loaded into an embedded system, may be retrieved by a generator environment, for example. The generator environment may determine what modules/component/functions may be added, deleted, or modified between the old and the new versions. Only modules that are added, deleted, or modified may be considered as candidates for inclusion in an update package. At block 223, an update package may be generated and reference lookup table modifications may be determined. Modifications to the reference lookup table may be associated with modules/components/functions that are added, deleted, or modified between the old and new versions. At block 225, an update package may be transferred to the embedded system along with associated reference lookup table modifications. In one embodiment, the update package may comprise the reference lookup table modifications. In another related embodiment, reference lookup table modifications and the update package may be treated as two different but related units of data to be transferred to the embedded system. At block 227, the update agent in the embedded system processes the retrieved update package and associated reference lookup table modifications. The embedded system loads new modules (methods, functions, subroutines, classes, etc.) if any, for the new version of the embedded system being in the update package. The new modules replace existing modules in the embedded system. The update agent in the embedded system also applies modifications to those modules that are to be modified but not replaced. These activities may be only part of an update process facilitated by an update agent in an embedded system.”]; and wherein the processor is configured to, for changing at least one part of the code components of at least one component block, processes the memory management information and writes information to be written into the main memory at locations defined by the memory management information, and the memory management information of the changed at least one component block is updated [fig. 2B; column 6, lines 30-67 – “FIG. 2B illustrates an exemplary process of generating update packages for updating firmware/software in an embedded system from one version to another version and a process of retrieving and updating the embedded system, in accordance with an embodiment of the present invention. The embedded system may employ a CAP architecture. At block 221, new and old versions of code, such as a collection of code loaded into an embedded system, may be retrieved by a generator environment, for example. The generator environment may determine what modules/component/functions may be added, deleted, or modified between the old and the new versions. Only modules that are added, deleted, or modified may be considered as candidates for inclusion in an update package. At block 223, an update package may be generated and reference lookup table modifications may be determined. Modifications to the reference lookup table may be associated with modules/components/functions that are added, deleted, or modified between the old and new versions. At block 225, an update package may be transferred to the embedded system along with associated reference lookup table modifications. In one embodiment, the update package may comprise the reference lookup table modifications. In another related embodiment, reference lookup table modifications and the update package may be treated as two different but related units of data to be transferred to the embedded system. At block 227, the update agent in the embedded system processes the retrieved update package and associated reference lookup table modifications. The embedded system loads new modules (methods, functions, subroutines, classes, etc.) if any, for the new version of the embedded system being in the update package. The new modules replace existing modules in the embedded system. The update agent in the embedded system also applies modifications to those modules that are to be modified but not replaced. These activities may be only part of an update process facilitated by an update agent in an embedded system.”]. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rao et al. (U.S. Patent No. 7,472,380) in view of Uthaicharoenpong et al. (Pub. No. US 2022/0075338). Claim 19: Uthaicharoenpong et al. disclose a device, comprising: at least one microcontroller, which comprises [column 1, lines 30-33; column 3, line 35-41 – “Embedded systems (i.e., mobile electronic devices having embedded software/firmware), such as mobile cellular phones, personal digital assistants (PDA's), MP3 players, digital cameras, etc. often contain firmware and/or application software that is either provided by the manufacturers of the electronic devices, telecommunication carriers, or third parties.” … “A device in accordance with an embodiment of the present invention comprises a mobile electronic device having an embedded system capable of employing a component architecture platform (CAP) framework. The device comprises a processor, a reference lookup table management unit, primary memory and secondary memory, and at least one reference lookup table.”] a main memory, wherein the microcontroller does not have a separate memory management unit, wherein a part of the main memory is occupied by a base firmware [column 1, lines 30-33; column 3, line 35-41 – “Embedded systems (i.e., mobile electronic devices having embedded software/firmware), such as mobile cellular phones, personal digital assistants (PDA's), MP3 players, digital cameras, etc. often contain firmware and/or application software that is either provided by the manufacturers of the electronic devices, telecommunication carriers, or third parties.” … “A device in accordance with an embodiment of the present invention comprises a mobile electronic device having an embedded system capable of employing a component architecture platform (CAP) framework. The device comprises a processor, a reference lookup table management unit, primary memory and secondary memory, and at least one reference lookup table.”]; and a processor coupled to the main memory [column 1, lines 30-33; column 3, line 35-41 – “Embedded systems (i.e., mobile electronic devices having embedded software/firmware), such as mobile cellular phones, personal digital assistants (PDA's), MP3 players, digital cameras, etc. often contain firmware and/or application software that is either provided by the manufacturers of the electronic devices, telecommunication carriers, or third parties.” … “A device in accordance with an embodiment of the present invention comprises a mobile electronic device having an embedded system capable of employing a component architecture platform (CAP) framework. The device comprises a processor, a reference lookup table management unit, primary memory and secondary memory, and at least one reference lookup table.”], wherein the microcontroller is configured to write at least one component block into the main memory when the base firmware is inserted into the main memory, wherein the at least one component block comprises memory management information and code components for providing at least one firmware component or at least one application program component [fig. 2B; column 6, lines 30-67 – “FIG. 2B illustrates an exemplary process of generating update packages for updating firmware/software in an embedded system from one version to another version and a process of retrieving and updating the embedded system, in accordance with an embodiment of the present invention. The embedded system may employ a CAP architecture. At block 221, new and old versions of code, such as a collection of code loaded into an embedded system, may be retrieved by a generator environment, for example. The generator environment may determine what modules/component/functions may be added, deleted, or modified between the old and the new versions. Only modules that are added, deleted, or modified may be considered as candidates for inclusion in an update package. At block 223, an update package may be generated and reference lookup table modifications may be determined. Modifications to the reference lookup table may be associated with modules/components/functions that are added, deleted, or modified between the old and new versions. At block 225, an update package may be transferred to the embedded system along with associated reference lookup table modifications. In one embodiment, the update package may comprise the reference lookup table modifications. In another related embodiment, reference lookup table modifications and the update package may be treated as two different but related units of data to be transferred to the embedded system. At block 227, the update agent in the embedded system processes the retrieved update package and associated reference lookup table modifications. The embedded system loads new modules (methods, functions, subroutines, classes, etc.) if any, for the new version of the embedded system being in the update package. The new modules replace existing modules in the embedded system. The update agent in the embedded system also applies modifications to those modules that are to be modified but not replaced. These activities may be only part of an update process facilitated by an update agent in an embedded system.”]; and wherein the processor is configured to, for changing at least one part of the code components of at least one component block, processes the memory management information and writes information to be written into the main memory at locations defined by the memory management information, and the memory management information of the changed at least one component block is updated [fig. 2B; column 6, lines 30-67 – “FIG. 2B illustrates an exemplary process of generating update packages for updating firmware/software in an embedded system from one version to another version and a process of retrieving and updating the embedded system, in accordance with an embodiment of the present invention. The embedded system may employ a CAP architecture. At block 221, new and old versions of code, such as a collection of code loaded into an embedded system, may be retrieved by a generator environment, for example. The generator environment may determine what modules/component/functions may be added, deleted, or modified between the old and the new versions. Only modules that are added, deleted, or modified may be considered as candidates for inclusion in an update package. At block 223, an update package may be generated and reference lookup table modifications may be determined. Modifications to the reference lookup table may be associated with modules/components/functions that are added, deleted, or modified between the old and new versions. At block 225, an update package may be transferred to the embedded system along with associated reference lookup table modifications. In one embodiment, the update package may comprise the reference lookup table modifications. In another related embodiment, reference lookup table modifications and the update package may be treated as two different but related units of data to be transferred to the embedded system. At block 227, the update agent in the embedded system processes the retrieved update package and associated reference lookup table modifications. The embedded system loads new modules (methods, functions, subroutines, classes, etc.) if any, for the new version of the embedded system being in the update package. The new modules replace existing modules in the embedded system. The update agent in the embedded system also applies modifications to those modules that are to be modified but not replaced. These activities may be only part of an update process facilitated by an update agent in an embedded system.”]. However, Rao et al. do not specifically disclose, the device is a vehicle; In the same field of endeavor, Uthaicharoenpong et al. disclose, the device is a vehicle [pars. 0030-0031 – “Some of the advantages of these techniques are as follows. Commands to activate or deactivate a device can be authenticated to confirm they are authorized and not provided by a malicious actor. Authenticated commands can be evaluated to determine that they won't cause harm to the vehicle. An electronic device can be securely power-cycled after an event such as a firmware update. An electronic device can be quickly powered off if a current spike or similar event is detected, mitigating or preventing electrical damage. The health (functionality) of an electronic device can be monitored based on its measured power draw.”]; It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Rao et al. to include a vehicle, as taught by Uthaicharoenpong et al., in order to allow a vehicle’s firmware to be updated. Allowable Subject Matter Claims 11-16, 18, and 20 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to LARRY T MACKALL whose telephone number is (571)270-1172. The examiner can normally be reached Monday - Friday, 9am-5pm. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Reginald G Bragdon can be reached at (571) 272-4204. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. LARRY T. MACKALL Primary Examiner Art Unit 2131 5 September 2026 /LARRY T MACKALL/Primary Examiner, Art Unit 2139