DETAILED ACTION
Claims 1-20 are pending.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This final office action is in response to the applicant’s response received on 12/04/2025, for the non-final office action mailed on 09/10/2025.
Examiner’s Notes
Examiner has cited particular columns and line numbers, paragraph numbers, or figures in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant, in preparing the responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Response to Arguments
Applicant's arguments filed 12/04/2025 have been fully considered but they are not persuasive.
Applicant argues Komano doesn’t teach “using partial data comprised in firmware data as test data to perform a test process,” see applicant’s remarks pp. 5-7. Examiner respectfully disagrees as Komano further teaches in paragraph [0063], “For this reason, in the present. modification, the distribution server 120 transmits modified reference data (an example of “fifth data”) generated on the basis of the reference data, instead of the reference data in the second embodiment described above, to the update control apparatus 10. The modified reference data is a value calculated from the reference data, such as a hash value of the reference data, and partial data of the reference data” showing how partial data is being used and paragraph [0064], “In the present modification, when the update control apparatus 10 receives verification data, such as a message authentication code of the updated firmware, from the terminal 20, the update control apparatus 10 generates modified verification data (an example of “seventh data”), on the basis of the verification data received from the terminal 20, by the same method as the method for generating modified reference data from the reference data. The verification unit 14 of the update control apparatus 10 verifies whether the update result received from the terminal 20 is proper data, on the basis of whether the generated modified verification data agrees with the modified reference data received from the distribution server 120. In this manner, the update control apparatus 10 can correctly verify whether the update result received from the terminal 20 is proper data.” Showing update results and verification data which are partial data coming for the update data received in the terminal, the verification data is the test data which is partial data coming from the update data.
Applicant further argues Komano doesn’t teach “performing a parameter adjustment process on the at least one of the access parameter by the control terminal when the comparison result indicates a mismatching condition,” see applicant’s remarks pp. 7-8. Examiner respectfully disagrees as Komano teaches in paragraph [0077] “After the update control apparatus 10 receives the pieces of update data from the distribution server 120, the update control apparatus 10 changes the state of the automobile equipped with the in-vehicle network system 100 to the “firmware update mode”, in the same manner as the first embodiment. The update control apparatus 10 generates update control information, if necessary, and transmits the pieces of update data to the respective terminals 20, to instruct the terminals 20 to update the firmware, on the basis of the update control information (Step S404)” and paragraph [0079], “When the update control apparatus 10 receives the update result and verification data from each of the terminals 20, the update control apparatus 10 generates integrated verification data received from pieces of verification data received from the terminals 20, and verifies whether all the update results received from the terminals 20 is proper data, on the basis of whether the generated integrated verification data agrees with the integrated reference data received from the distribution server 120. At this time, in the present embodiment, when it is determined that some of the update results are improper data, the update control apparatus 10 can identify a terminal 20 corresponding to an update result that is improper data, using the pieces of verification data received from the respective terminals 20 and the digests received from the distribution server 120” the state of the automobile is the access parameter that is being adjusted based on success/failure of the update results.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 4-6, 11 and 14-16 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Komano et al. (US-PGPUB-NO: 2019/0056925 A1) hereinafter Komano.
As per claim 1, Komano teaches a firmware update method (see Komano paragraph [0011], “According to an embodiment, an update control apparatus is to control update of software in a terminal connected to a network”) having firmware update troubleshooting mechanism used in an electronic system (see Komano paragraph [0011], “The processor is configured to: receive update data to update the software from the server using the first communication circuit; transmit the update data to the terminal using the second communication circuit; receive an update result indicating whether update of the software has succeeded, together with verification data, from the terminal using the second communication circuit; and verify, using the verification data, whether the update result is proper data”), comprising: using partial data comprised in firmware data as test data to perform a test process by a control terminal to transmit the test data to a processing terminal, so as to write the test data to a firmware storage terminal by using a control interface of the processing terminal according to a setting of a plurality of access parameters (see Komano paragraph [0019], “The control unit 13 receives update data from the distribution server 120 using the vehicle external communication unit 11. The control unit 13 transmits the update data received from the distribution server 120 to the terminal 20 using the vehicle internal communication unit 12, and receives the update result described above from the terminal 20 together with the verification data. The update result and the verification data received by the control unit 13 from the terminal 20 are transferred to the verification unit 14”), read the written test data from the firmware storage terminal through the control interface and compare the written test data and the test data to generate a comparison result (see Komano paragraph [0020], “The verification unit 14 verifies, using the verification data received from the control unit 13, whether the update result received from the terminal 20 together with the verification data is proper data. Examples of the verification data include a message authentication code (MAC) generated by the terminal 20 on the basis of the update result using a secret key (shared key) shared with the update control apparatus 10, and a digital signature generated by the terminal 20 on the basis of the update result using a secret key, and verifiable with the update control apparatus 10 using a public key of the terminal 20”); performing a parameter adjustment process on at least one of the access parameters by the control terminal when the comparison result indicates a mismatching condition (see Komano paragraph [0024], “The control unit 13 may control the state of the automobile on which the in-vehicle network system 100 is mounted, in accordance with success/failure of update and/or restoration of the firmware in the terminal 20. For example, when update of the firmware in the terminal 20 is executed, the control unit 13 may perform control to change the state of the automobile to “firmware update mode” first, return the state of the automobile to “travelling possible mode” when update and/or restoration of the firmware in the terminal 20 succeeds, and change the state of the automobile to “abnormal mode” when update and/or restoration of the firmware in the terminal 20 ends in failure”); performing the test process by using the partial data again by the control terminal after the parameter adjustment process finishes being performed, such that the parameter adjustment process is further performed again when the comparison result still indicates the mismatching condition (see Komano paragraph [0023], “A result of verification of the update result with the verification unit 14 is transferred to the control unit 13. When the control unit 13 receives a verification result indicating that the update result is not proper data from the verification unit 14, that is, when the verification unit 14 determines that the update result transmitted from the terminal 20 is not proper data, the control unit 13 may execute update of firmware in the terminal 20 again, or execute restoration of the firmware in the terminal 20 or a plurality of terminals 20. When update of the firmware is executed again, the control unit 13 retransmits update data received from the distribution server 120 to the terminal 20 using the vehicle internal communication unit 12. When restoration of the firmware is executed, the control unit 13 transmits restoration data to restore the firmware before update to the terminal 20 using the vehicle internal communication unit 12”); and transmitting the firmware data to the processing terminal by the control terminal when the comparison result indicates a matching condition, so as to write the firmware data to the firmware storage terminal by using the control interface according to the setting of the access parameters adjusted by the parameter adjustment process (see Komano paragraph [0060], “When the update control apparatus 10 receives the update result and verification data from the terminal 20, the update control apparatus 10 verifies whether the update result received from the terminal 20 is proper data, on the basis of whether the verification data received from the terminal 20 agrees with the reference data received from the distribution server 120. Thereafter, the update control apparatus 10 recognizes the states of firmware updates in the respective terminals 20, on the basis of the update result verified as proper data, and transmits the overall update result to the distribution server 120 (Step S306), changes the state of the automobile to the “traveling possible mode” or “abnormal mode”, and/or performs other operation in accordance with the states. These are the same as those in the first embodiment, and detailed explanation thereof is omitted”).
As per claim 4, Komano teaches further comprising: using the firmware data as the test data to perform the test process by the control terminal to generate a firmware comparison result when the comparison result generated by using the partial data as the test data to perform the test process indicates the matching condition (see Komano paragraph [0036], “Each of the terminals 20 that have received the update data from the update control apparatus 10 performs processing to update the firmware stored in itself using the update data, and transmits an update result indicating whether the update of the firmware has succeeded to the update control apparatus 10. At this time, each of the terminals 20 generates verification data to verify in the update control apparatus 10 whether the update result is proper data, and transmits the verification data to the update control apparatus 10, together with the update result (Step S105). When the firmware is updated, each of the terminals 20 may use the firmware verification information, to check whether the updated firmware to be newly stored is proper”); performing the parameter adjustment process on at least one of the access parameters by the control terminal when the firmware comparison result indicates the mismatching condition (see Komano paragraph [0038], “By contrast, when any improper update result exists, the update control apparatus 10 may execute the firmware update of the terminal 20 again, or execute restoration of the firmware in the terminal 20, or a plurality of terminals 20 including other terminals 20 performing operations in cooperation with the terminal 20, as described later. Thereafter, the update control apparatus 10 may change the state of the automobile to the “traveling possible mode” or the “abnormal mode”, in accordance with success/failure of the update and/or restoration of the firmware. The “abnormal mode” is a mode indicating that update of the firmware has ended in failure, and promoting the owner of the automobile to have the automobile inspected at the dealer. In the “abnormal mode”, the automobile may be controlled to be prevented from traveling, or controlled to be enabled to travel, with some functions restricted. In this state, the update control apparatus 10 may transmit an overall update result indicating that some or all of the pieces of update data has not been applied, to the distribution server 120”); performing the test process by using the firmware data again by the control terminal after the parameter adjustment process finishes being performed, such that the parameter adjustment process is further performed again when the firmware comparison result still indicates the mismatching condition (see Komano paragraph [0039], “When the terminal 20 has failed to update the firmware, the update control apparatus 10 may execute the update of the firmware in the terminal 20 again, or try to restore the firmware. When the firmware can be built with only the update data, the update control apparatus 10 may retransmit the update data to the terminal 20 that has failed to update the firmware, to execute the update again”); and storing the access parameters to a parameter storage circuit when the firmware comparison result indicates the matching condition (see Komano paragraph [0042], “When the update control apparatus 10 receives update data from the distribution server 120, first, the update control apparatus 10 changes the state of the automobile from the “traveling possible state” to the “firmware update mode” (Step S201). Thereafter, the update control apparatus 10 transmits the update data received from the distribution server 120 to the terminal 20 being a target of firmware update (Step S202). Thereafter, the update control apparatus 10 receives an update result and verification data from the terminal 20 to which the update data has been transmitted (Step S203), and verifies whether the update result is proper data using the received verification data (Step S204). The processing from Step S202 to Step S204 is processing performed repeatedly for each of the terminals 20 being targets of firmware update”).
As per claim 5, Komano teaches further comprising: determining that the firmware data fails to be updated to the firmware storage terminal by the control terminal when the control terminal determines that the access parameters are not able to be further adjusted and when the comparison result still indicates the mismatching condition (see Komano paragraph [0039], “As another example, when the update data includes only a difference from the firmware of the previous version and the firmware cannot be built with only the update data, the update control apparatus 10 may restore the firmware in the terminal 20 using the restoration data, and thereafter retransmit the update data to the terminal 20. As another example, the update control apparatus 10 may request the distribution server 120 to transmit new update data enabling new firmware to be built, and transfer the new update data to the terminal 20”).
As per claim 6, Komano teaches further comprising: performing an activation process by the processing terminal to read the access parameters from the parameter storage circuit to configure the control interface and read the firmware data from the firmware storage terminal according to the access parameters through the control interface to further perform the subsequent activation process (see Komano paragraph [0040], “The restoration data is data enabling the firmware of the previous version to be built. The restoration data may be requested by the update control apparatus 10 from the distribution server 120 as required, transmitted from the distribution server 120 to the update control apparatus 10 together with the update data, or transmitted from the distribution server 120 to the update control apparatus 10 at a timing different from the firmware update. The restoration data may be data enabling the firmware of the previous version to be built alone, or data including only a difference from the firmware of the new version, and not enabling the firmware of the old version to be built alone but enabling the version of the firmware to be returned from the new version to the old version”).
As per claims 11 and 14-16, these are the electronic system claims to firmware update method claims 1 and 4-6, respectively. Therefore, it is rejected for the same reasons as above. Komano further teaches a firmware storage terminal (see Komano paragraph [0030], “The storage area may be secured in the update control apparatus 10, or in a storage device connected with the update control apparatus 10 through the network bus 30”); a processing terminal comprising a control interface (see Komano paragraph [0014], “The in-vehicle network system 100 has a structure in which an update control apparatus 10 and a plurality of terminals 20 are connected through a network bus 30”) and a control terminal, configured to execute a burning program, to further execute a firmware update method (see Komano paragraph [0019], “The control unit 13 receives update data from the distribution server 120 using the vehicle external communication unit 11. The control unit 13 transmits the update data received from the distribution server 120 to the terminal 20 using the vehicle internal communication unit 12, and receives the update result described above from the terminal 20 together with the verification data. The update result and the verification data received by the control unit 13 from the terminal 20 are transferred to the verification unit 14”).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be
Claim(s) 2, 8, 12 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Komano (US-PGPUB-NO: 2019/0056925 A1), in further view of Vaysman et al. (US-PGPUB-NO: 2014/0185388 A1) hereinafter Vaysman.
As per claim 2, Komano does not explicitly teach wherein the access parameters at least comprise a slew rate, a driving ability and a clock frequency, the firmware update method further comprising: setting the slew rate to be a maximum slew rate, the driving ability to be a minimum driving ability and the clock frequency to be a maximum clock frequency by the control terminal when the test process is performed for the first time; and performing at least one of decreasing the slew rate, increasing the driving ability and decreasing the clock frequency by the control terminal during the parameter adjustment process. However, Vaysman teaches wherein the access parameters at least comprise a slew rate, a driving ability (see Vaysman paragraph [0033], “The first phase optimization in block 704 determines an optimal drive strength for driving an I/O. In other words, a determination is made as to whether an output driver for an I/O device drive a particular load. In block 706, the second phase of drive strength optimization may include a signal quality analysis or data signal quality optimization. A slew rate level (V/nanosecond) of a data signal can be measured by the memory controller and compared with a target value. The slew rate value may be in the specified limits for a certain data signal speed. If the slew rate value is lower than the low limit, the signal may not be good enough to be recognized by the memory/host and it should be improved”) and a clock frequency (see Vaysman paragraph [0039], “The optimal drive strength that is determined as discussed above may be an input along with a configuration parameter that results in an output that is the maximum data frequency or maximum data transfer speed. In one example, the configuration parameter may include the number of dies for a memory device”), the firmware update method further comprising: setting the slew rate to be a maximum slew rate, the driving ability to be a minimum driving ability and the clock frequency to be a maximum clock frequency by the control terminal when the test process is performed for the first time; and performing at least one of decreasing the slew rate, increasing the driving ability and decreasing the clock frequency by the control terminal during the parameter adjustment process (see Vaysman paragraph [0040], “A particular device (or product configuration) may have a table (e.g. Table 1) generated at development that reveals the maximum data frequency for a range of drive strengths and slew rates. The slew rates are utilized along with the drive strength in FIG. 10 to identify the maximum transfer speed. As shown in Table 1, there are four values of drive strength and six values of slew rate. For each combination of drive strength and slew rate, there is a maximum data transfer speed (also referred to as data frequency and identified as F.sub.n in Table 1 to illustrate different values) that can be referenced from the table. Accordingly, the optimization of drive strength may be utilized for determining a maximum data transfer rate for a particular memory system. In alternative embodiments, there may be other parameters other than slew rate that are utilized with drive strength to identify the maximum data transfer rate”).
Komano and Vaysman are analogous art because they are in the same field of endeavor of firmware implementation. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Komano’s teaching of an update control apparatus to control update of software in a terminal connected to a network with Vaysman’s teaching of optimizing the drive strength of a memory controller input/output device to incorporate controlling the slew rate , drive capacity and frequency in order to optimize power delivery via network, see Vaysman paragraph [0004], “It may be desirable to implement a system and method for optimizing and improving high level transfer of data in a memory system. A self-learning mechanism may determine the required drive strength ("DS") value depending on a system configuration and operating conditions. The system configuration may include the number of NAND dies and the types of substrate or printed circuit boards. The operating conditions may include process, voltage and temperature variations. Accordingly, the optimization process may dynamically update the drive strength of I/O devices for changes to the system configuration or changes to the operating conditions. The optimization may be based on a measurement of the supply voltage or power delivery network.”
As per claim 8, Komano modified with Vaysman teaches further comprising: writing the access parameters to a plurality of access registers related to the control interface by the processing terminal to configure the control interface so as to access the firmware storage terminal (see Vaysman paragraph [0043], “FIG. 12 is a block diagram of one hardware implementation of the proposed algorithm in a memory controller. In particular, the memory controller 118 may be utilized for determining drive strength values. The power supply voltage VDD is provided to the memory controller 118 and a VDD noise undershoot peak measurement module 1202 measures the undershoot peak. As discussed with respect to FIG. 9, the undershoot peak may be utilized to determine a drive strength. The measurement results processing 1204 may perform the algorithm of FIG. 8 in order to identify the optimal drive strength based on the measured undershoot of the power supply. The drive strength value may be stored in the drive strength register 1206 for future reference”).
As per claims 12 and 18, these are the electronic system claims to firmware update method claims 2 and 8, respectively. Therefore, they are rejected for the same reasons as above.
Claim(s) 7, 9, 10, 17, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Komano (US-PGPUB-NO: 2019/0056925 A1), in further view of Abdulhamid et al. (US-PGPUB-NO: 2024/0005004 A1) hereinafter Abdulhamid.
As per claim 7, Komano does not explicitly teach wherein the parameter storage circuit is a one-time programming memory (OTP ROM) or an eFuse comprised by the processing terminal, or configured to be a part of the firmware storage terminal. However, Abdulhamid teaches wherein the parameter storage circuit is a one-time programming memory (OTP ROM) or an eFuse comprised by the processing terminal, or configured to be a part of the firmware storage terminal (see Abdulhamid paragraph [0033], “The hardware switches may read one or more efuses of efuse array 220 which may operate as additional ROM and/or hardware coded values for boot modes. Furthermore, power inputs 260 may include an efuse over-voltage pin that is configured to provide voltage sufficient to blow efuses for programming. The efuses or efuse array 220 may be implemented as EPROM, EEPROM, FLASH, or other non-volatile or one-time programmable memory”).
Komano and Abdulhamid are analogous art because they are in the same field of endeavor of firmware implementation. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Komano’s teaching of an update control apparatus to control update of software in a terminal connected to a network with Abdulhamid’s teaching of pathing a boot process to incorporate the use of e-fuse to provide the necessary failover or secure booting options, see Abdulhamid paragraph [0031], “Once more advanced operations are running to check the validity of code and provide software-level security measures, then the TMM or SMpro processor 124 may access RAM or non-trusted components of the SoC 100. The TMM may also output authentication failure flags or indicators and/or boot failure indicators to the baseboard management controller off-chip in the event that errors occur. As will be discussed in more detail with reference to FIG. 2, the efuse array 220 may provide the necessary instructions for fail over or secure boot options that enable external re-programming. Upon a successful authentication and power-on of the hardware switches, the bootstrap controller 210 or hardware switches therein may output a particular boot state. The TMM or bootstrap controller 210 may use/read this boot state to enable or disable functions and may operate different ROM/EEPROM/RAM code/instructions based on the boot state.”
As per claim 9, Komano modified with Abdulhamid teaches wherein the test process further comprises: performing erasing on the firmware storage terminal through the control interface by the control terminal (see Abdulhamid paragraph [0037], “The RAM 240 is illustrated with valid patches 321 and 325 appended to the boot process code and keys 315 as an example. Other positions for the patches in memory is contemplated as shown in FIG. 4A-4B. Indeed, each patch may include a memory address or index that corresponds to a position in RAM 240 that is fixed or predictable due to the immutable nature of the boot process. Upon power-on, the original ROM embedded in silicon at manufacture may be copied in total by the bootstrap controller 210 into the RAM 240 as originally designed. The bootstrap controller 210 may then copy the patches into RAM 240 to overwrite or skip sections of the original ROM instructions so that the patch is executed instead” in which overwriting is interpreted as erasing); loading the test data to a data storage circuit further comprised by the processing terminal by the control terminal (see Abdulhamid paragraph [0032], “In FIG. 2, the security processor 201 is illustrated along with the bootstrap controller 210 thereon. The bootstrap controller 210 and the security processor 201 may be dedicated silicon components on the SoC 100. The security processor 201 may host RAM 240 as on-board memory for boot or the RAM 240 may be a trusted part of memory 121. The ROM 230 may contain one or more instructions for the boot process and one or more certificates for signing and authenticating firmware during boot. That is, as noted above, the trusted elements of the SoC 100 may be authenticated via these certificates stored in ROM 230. The ROM 230 may contain instructions that are processed by the bootstrap controller 210 to initiate boot and firmware execution. These instructions may be loaded from ROM 230 into RAM 240 by the bootstrap controller 210 before being executed by the bootstrap controller 210 or security processor 201”); writing the test data from the data storage circuit to the firmware storage terminal through the control interface by the control terminal (see Abdulhamid paragraph [0034], “Upon boot, the bootstrap controller 210 and security processor 201 may be supplied with power. The bootstrap controller 210 may then access the ROM 230 via direct memory access (DMA) and may transfer the contents of the ROM 230 directly to RAM 240 for execution. One advantage of this read and transfer before the main boot is that after transfer of the trusted, immutable contents of ROM 230, the instructions in RAM 240 may be patched before execution. The patches for the ROM 230 may be stored in the efuse array 220 which may be programmed after manufacture, and which is secure and immutable after programming. The patches may be configured to replace or bypass one or more instructions or certificates of ROM 230”); and reading the firmware storage terminal through the control interface to perform comparison on read data and the test data to generate the comparison result by the control terminal (see Abdulhamid paragraph [0034], “The bootstrap controller 210 may apply a patch by copying ROM 230 to RAM 240, reading the patch from the efuse array 220, and writing the patch to RAM 240 before executing the boot process. This process of applying the patch is described in more detail with respect to FIG. 6. These steps are taken very early in the boot process or essentially upon power-on of the bootstrap controller 210”).
As per claim 10, Komano modified with Abdulhamid teaches wherein the firmware storage terminal is a flash memory or an erasable programmable read only memory (EPROM), the control interface is a serial peripheral interface (SPI) or a I2C interface (see Abdulhamid paragraph [0027], “In FIG. 1, a system on a chip (SoC) 100 is illustrated with a set of central processing units (CPUs) 101 and a system control processor 120 that handles many of the utility functions of the SoC 100. The SoC 100 may include more than the illustrated four CPUs (e.g., 50 CPUs, 80 CPUs, or 120+ CPUs). The CPUs 101 are connected to system control processor 120 via a mesh interconnect 111 that forms a high-speed bus connecting each of the CPUs 101 to each other and connecting to other on-chip resources including memory (e.g., L3 cache), PCIe interfaces, I2C bus connections off chip, and other resources. Specifically, the mesh interconnect 111 may individually connect to the SMpro processor 124, the PMpro processor 123, input/output (I/O) ports 122 and memory 121 of the system control processor 120. The mesh interconnect 111, an I2C interface, or other connections may connect the system control processor 120 to CPUs 101 and other hardware of the SoC 100”).
As per claims 17, 19 and 20, these are the electronic system claims to firmware update method claims 7, 9 and 10, respectively. Therefore, they are rejected for the same reasons as above.
Allowable Subject Matter
Claims 3 and 13 are 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
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ok et al. (US-PGPUB-NO: 2019/0180837 A1) teaches built-in self-test circuit.
Thakkar et al. (US-PGPUB-NO: 2014/0293886 A1) teaches devices and methods for facilitating automated configuration of communication interfaces.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LENIN PAULINO whose telephone number is (571)270-1734. The examiner can normally be reached Week 1: Mon-Thu 7:30am - 5:00pm Week 2: Mon-Thu 7:30am - 5:00pm and Fri 7:30am - 4:00pm 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, Bradley Teets can be reached at (571) 272-3338. 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.
/LENIN PAULINO/Examiner, Art Unit 2197 /BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197