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 .
This action is responding to application papers dated 6/27/2023.
Claims 1-17 are examined and claim 18-20 are withdrawn.
The information disclosure statement filed on 6/27/2023 has been considered.
Claim Objections
Claim 2 is objected to because of the following informalities: per claim 2, it appears that ‘a’ is missing before “persistent memory.” Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 11-17 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Specifically, claims 11-17 are directed to an abstract idea.
Per claim 11, the claim is directed to an idea of itself, mental processes that can be performed in the human mind, or by a human using a pen and paper. The steps of determining and confirming can be performed mentally using a pen and paper through observation, evaluation, judgment, opinion, Under Prong 1.
Under Prong 2, the additional limitations, the first and second microprocessor devices recited as generic computers and the steps of downloading and transferring are mere data gathering/transmitting for the mental steps which are insignificant extra solution activity, using a generic computing component such as the first microprocessor device escribed at a high level of generality for applying or performing the abstract idea and do not indicate any integration of the abstract idea into a practical application as the mental steps are merely applied with a generic computing component(s). See MPEP see MPEP 2106.05(f) /2106.05(h). Therefore, the additional limitations do not integrate the abstract idea into a practical application. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, but for the recitation of generic computer components or insignificant extra solution activities (e.g. processors, devices, program instructions), then it falls within the "Mental Processes" grouping of abstract ideas (2019 PEG step 2A, Prong 1: Abstract idea grouping? Yes, Mental Process). At most, the steps of downloading and transferring are not found to include anything more than what is well-understood, routine, conventional activity in the field. In this case, it is noted that the claimed extra-solution of data gathering or transmitting is acknowledged to be a well-understood, routine, conventional activity court recognized as WURC examples in MPEP 2106.05(d)(ll), for example, data gathering and retrieving, storing data, updating, transmitting, and displaying a result - Symantec, Versata Dev, Content extraction, Electric Power Group). Insignificant extra solution activities or mere instructions to apply an exception using generic computer components cannot provide an inventive concept. Viewing the limitations individually and as a combination, the additional elements merely perform data gathering/transmitting and perform the mental steps using generic computing components as tools without integrating the abstract idea into a practical application. For at least these reasons, claim 11 is not patent eligible.
Per claims 12-17, these claims are directed to the same idea itself as in claim 11, reciting details of the mental steps without adding any other additional element that is significantly more. The step of storing is also an insignificant extra solution activity which is well-understood, routine, conventional activity court recognized as WURC examples in MPEP 2106.05(d)(ll), for example, data gathering and retrieving, storing data, updating, transmitting, and displaying a result - Symantec, Versata Dev, Content extraction, Electric Power Group). Therefore, the claims are rejected for the same reasons as in claim 11.
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.
Claims 1-6, and 8 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Wang et al. (US20240329961, hereafter Wang).
Per claim 1:
Wang teaches:
A system comprising: a motherboard (Wang, see at least [0025] FIG. 1 is a block diagram illustrating an autonomous driving network configuration … autonomous driving vehicle (ADV) 101; [0066] power control SW/HW on board; [0080] perform board power control and system monitoring, as well as performing dual booting to reduce the risk of FOTA failure due to power loss);
a network switch for connecting the motherboard to an autonomous vehicle (AV) ethernet network (Wang, see at least [0025] an autonomous driving network configuration … coupled to servers 103-104 over network 102; [0058] through wired or wireless connections with a known communication protocol (e.g., TCP/IP, ethernet, Wi-Fi, etc.); [0084] In this computer network 700, switch 714 may be powered in the safety power domain 732, while switch 718 and switch 716 are powered in the main power domain 730. In addition to ethernet communications, components may be coupled through configuration ports that allows one device to read or write configurable settings on another device; [0067]; [0078] These devices may be communicatively coupled to each other through their respective ethernet ports either directly or indirectly, to form part of the computer network 700);
a system manager connected to the motherboard for distributing power to the motherboard and the ethernet switch (Wang, see at least [0061] Processing logic 518 may receive firmware 524 to be installed on the target device 504… Processing logic 518 may direct the firmware 524 to the target device through a first network path (e.g., path A) of the computer network 520. In response to detecting a failure to update the target device 504 with the firmware 524, processing logic 518 may direct the firmware 524 to the target device 504 through a second network path (e.g., path B) of the computer network; [0023]; [0067] In some examples, the first network path may comprise a first switch (e.g., switch 526) that is powered by a first power source (e.g., main power 510) and the second network path may comprise a second switch (e.g., switch 528) that is powered by a second power source (e.g., backup power 512); [0076] all FOTA paths (e.g., from a gateway to a target device) are dual redundant (e.g., have two separate paths) and are distributed in two power domains; [[Note that the power sources provide power to the board housing hardware components and network switch and the host/target devices (e.g. MCUs/CPLDs) hold dual roles to serve as a system manager and safehold system for providing perform board power control and system monitoring, as well as performing dual booting to reduce the risk of FOTA failure due to power loss]]);
a safehold system connected to the system manager, wherein the safehold system is powered independently of the system manager (Wang, see at least [0023] The plurality of network components may include one or more of: a main central processing unit (CPU), a safety CPU, a main field programmable processing array (FPGA), a safety FPGA, a main microcontroller unit (MCU), or a safety MCU. In some embodiments, all such components are included. In some embodiments, the main CPU, the main MCU, and the main FPGA are powered by a first power source, and the safety CPU, the safety FPGA, and the safety MCU are powered by a second power source. In some embodiments, the first network path includes a first switch that is powered by the first power source and the second network path includes a second switch that is powered by the second power source; [0080] the MCUs (708, 722) and CPLD (704, 720) may be configured to perform board power control and system monitoring, as well as performing dual booting to reduce the risk of FOTA failure due to power loss. In some examples, each of the main CPU 706, Safety CPU 712, main FPGA 724, safety FPGA 724, main MCU 708, and safety MCU 722 may be configured to serve as a host device (as described with respect to host device 602) and perform a dual boot of a target device with firmware and a backup firmware; Note that the host device connected to the target device corresponds to the safehold system and is powered independently of the target device).
wherein the safehold system obtains from the motherboard a firmware image, provides the firmware image to the system manager, and monitors the system manager to determine whether updating of the firmware image on the system manager was successful (Wang, see at least [0022] Processing logic may further be configured to store, on a host device among the plurality of network components, the firmware and a second firmware of the target device, and in response to detecting the failure, direct the second firmware to the target device through the first network path or through the second network path; [0070]; [0071] processing logic may implement a safety booting option to allow recovery of the target device 614 in response to a failure. Processing logic may include a boot controller 604 to implement dual booting operations on a host device 602. For example, boot controller 604 may store, on host device 602 the firmware 608 and a second firmware 612; [0062], after the firmware is uploaded to the target device 504 and the target device boots, processing logic 518 may check the version number and health of upgraded target device 504 to confirm that the firmware update is successful; [0073];[0080] the MCUs (708, 722) and CPLD (704, 720) may be configured to perform board power control and system monitoring, as well as performing dual booting to reduce the risk of FOTA failure due to power loss. … may be configured to serve as a host device (as described with respect to host device 602) and perform a dual boot of a target device with firmware and a backup firmware; [[Note that the host device checks the update process on a target device]]).
Per claim 2:
Wang teaches: The system of claim 1, wherein the safehold system includes persistent memory and wherein the firmware image obtained from the motherboard is stored in the persistent memory (Wang, see at least [0071] boot controller 604 may store, on host device 602 the firmware 608 and a second firmware 612; [0038] autonomous driving system 300 includes a firmware over-the-air (FOTA) module 360. FOTA module 360 may utilize component settings 362 which may be stored in persistent storage device; [0074] a single boot storage device of the host device 602 may be physically or logically divided into multiple partitions to form storage device 606 and 610…storage device 606 and storage device 610 may be separate hardware devices. Regardless, different firmware versions may be stored separately on host device 602. During booting stage of target device 614, boot controller 604 may monitor target device 614 to determine if target device 614 has failed to boot with firmware 608. If so, boot controller 604 will switch to the storage device 610 and route firmware 612 to target device 614. This may allow target device 614 to recover from a failed firmware update, even if the target operates in a degraded mode (e.g., with a smaller firmware image).[0083], Each MCU and CPLD may support dual booting, such that if a new version of firmware fails for that MCU or CPLD, the backup firmware (e.g., stored in a separate boot partition) is activated to boot the respective MCU or CPLD; Note that the boot storage device itself is persistent because it is storing different versions of firmware to survive across system reboots or power failure).
Per claim 3:
Wang teaches: The system of claim 2, wherein a backup firmware image is stored in the persistent memory (Wang, see at least [0071] boot controller 604 may store, on host device 602 the firmware 608 and a second firmware 612; [0038] autonomous driving system 300 includes a firmware over-the-air (FOTA) module 360. FOTA module 360 may utilize component settings 362 which may be stored in persistent storage device; [0072] Firmware 612 may be referred to as a backup firmware; [0074] a single boot storage device of the host device 602 may be physically or logically divided into multiple partitions to form storage device 606 and 610…storage device 606 and storage device 610 may be separate hardware devices. Regardless, different firmware versions may be stored separately on host device 602. During booting stage of target device 614, boot controller 604 may monitor target device 614 to determine if target device 614 has failed to boot with firmware 608. If so, boot controller 604 will switch to the storage device 610 and route firmware 612 to target device 614. This may allow target device 614 to recover from a failed firmware update, even if the target operates in a degraded mode (e.g., with a smaller firmware image).[0083], Each MCU and CPLD may support dual booting, such that if a new version of firmware fails for that MCU or CPLD, the backup firmware (e.g., stored in a separate boot partition) is activated to boot the respective MCU or CPLD; Note that the firmware and backup firmware are stored in the host boot storage device and its partitions which are persistent memory).
Per claim 4:
Wang teaches: The system of claim 3, wherein the backup firmware image comprises a last known verified firmware image for the system manager (Wang, see at least [0072] Firmware 612 may be referred to as a backup firmware. In some examples, firmware 612 has reduced size and capability relative to the firmware 608. For example, firmware 612 may support only the essential functionalities of the target device. In some examples, firmware 612 is a previous version of the firmware 608. For example, firmware 608 may be version 1.2 while firmware 612 may be a previous version 1.1; [0071]; [0074] If so, boot controller 604 will switch to the storage device 610 and route firmware 612 to target device 614. This may allow target device 614 to recover from a failed firmware update, even if the target operates in a degraded mode (e.g., with a smaller firmware image); Note that the backup firmware is last known verified version used to recover from a failed firmware update).
Per claim 5:
Wang teaches: The system of claim 3, wherein if it is determined that updating of the firmware image on the system manager was not successful, the safehold system provides the backup firmware image to the system manager (Wang, see at least [0072] Firmware 612 may be referred to as a backup firmware. In some examples, firmware 612 has reduced size and capability relative to the firmware 608. For example, firmware 612 may support only the essential functionalities of the target device. In some examples, firmware 612 is a previous version of the firmware 608. For example, firmware 608 may be version 1.2 while firmware 612 may be a previous version 1.1; [0071]; [0074] If so, boot controller 604 will switch to the storage device 610 and route firmware 612 to target device 614. This may allow target device 614 to recover from a failed firmware update, even if the target operates in a degraded mode (e.g., with a smaller firmware image); [0083], Each MCU and CPLD may support dual booting, such that if a new version of firmware fails for that MCU or CPLD, the backup firmware (e.g., stored in a separate boot partition) is activated to boot the respective MCU or CPLD.).
Per claim 6:
Wang teaches: The system of claim 1, wherein subsequent to the providing the firmware image to the system manager, the safehold system determines whether the system manager has successfully communicated with the motherboard and the ethernet switch (Wang, see at least [0062] Processing logic 518 may perform an integrity check to detect that a host device and target device are healthy, or perform a version compatibility check, or perform a data path health check, or a combination of such checks, prior to performing the firmware update. Processing logic 518 may proceed with the firmware update if the one or more checks pass. Similarly, after the firmware is uploaded to the target device 504 and the target device boots, processing logic 518 may check the version number and health of upgraded target device 504 to confirm that the firmware update is successful. If the checks fail after the firmware is uploaded, then processing logic may also direct a different firmware to the target device to try to ‘revive’ the target device; Note that the health check for the upgraded target device to confirm that the update was successful determines whether the target device responds correctly, that is, whether the circuits/power delivery on that chip driven by the MCU/CPLD doing board power control and system monitoring, the switches along the path forwarding traffic, the ethernet port on that device being physically up work correctly. More specifically, the chips on a board must be powered and executing, the board level power control must be delivering correct voltage, the ethernet port on that device must be forwarding packets correctly and the host device running the check must successfully communicate the poll over that path, therefore, a successful response to polling result is by necessity, indirect evidence that the board, its power delivery and all of those underlying links worked. The success implies the whole physical and network chain worked).
Per claim 8:
Wang teaches: The system of claim 1, wherein the system manager comprises a power distribution system (Wang, see at least [0061] Processing logic 518 may receive firmware 524 to be installed on the target device 504… Processing logic 518 may direct the firmware 524 to the target device through a first network path (e.g., path A) of the computer network 520. In response to detecting a failure to update the target device 504 with the firmware 524, processing logic 518 may direct the firmware 524 to the target device 504 through a second network path (e.g., path B) of the computer network; [0023]; [0067] In some examples, the first network path may comprise a first switch (e.g., switch 526) that is powered by a first power source (e.g., main power 510) and the second network path may comprise a second switch (e.g., switch 528) that is powered by a second power source (e.g., backup power 512); [0076] all FOTA paths (e.g., from a gateway to a target device) are dual redundant (e.g., have two separate paths) and are distributed in two power domains; [0073]; [0075] It should be understood that, although shown separately, the target device 614 and the host device 602 may be the same component. In such a case, the host device may perform its own FOTA update; [0080] the MCUs (708, 722) and CPLD (704, 720) may be configured to perform board power control and system monitoring, as well as performing dual booting to reduce the risk of FOTA failure due to power loss. … may be configured to serve as a host device (as described with respect to host device 602) and perform a dual boot of a target device with firmware and a backup firmware; Note that fig. 8 table shows the MCU, CPLD which are power distribution systems and other network counterparts are listed as FOTA target devices with IDS and paths, therefore, they can serve as a host device as well as a target device for firmware update. The dual role that allows the host device to perform its own FOTA update acting as a host or target device).
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.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Wang in view of Deng et al. (CN111708558, hereafter Deng).
Per claim 7:
Wang does not explicitly teach wherein the safehold system comprises a Linux system. Deng teaches such a Linux system (Deng, see at least Fig. 1 and associated texts, because the airborne computer operating linux system, the background operation with sshserver (ssh server), so it can utilize the ssh protocol (SecureShell, The network group of IETF is established by NetworkWorkingGroup, ssh is a security protocol established on the basis of application layer) for data transmission. and the ssh protocol itself comprises encryption, checking and so on, it can safely and completely transmit the firmware data from the ground station to the airborne computer through the network, that is, from the ground station to the unmanned aerial vehicle). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Deng’s Linux system with Wang’s firmware update to modify Wang’s ADV system to combine the Linux system as taught by Deng, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to firmware update. Combining Deng’s functionality with that of Wang results in a system that allows to use a Linux. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to provide a secure, stable and customizable operating system (Deng, see at least Fig. 1 and associated texts, because the airborne computer operating linux system, the background operation with sshserver (ssh server), so it can utilize the ssh protocol (SecureShell, The network group of IETF is established by NetworkWorkingGroup, ssh is a security protocol established on the basis of application layer) for data transmission. and the ssh protocol itself comprises encryption, checking and so on, it can safely and completely transmit the firmware data from the ground station to the airborne computer through the network, that is, from the ground station to the unmanned aerial vehicle).
Claims 9 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Wang in view of Wu et al. (CN 112905212, hereafter Wu).
Per claim 9:
Wang does not explicitly teach wherein the safehold system is connected to the system manager via a serial peripheral interface (SPI) link. Wu teaches wherein the safehold system is connected to the system manager via a serial peripheral interface (SPI) link (Wu, see at least fig. 1 and 2 and associated texts, the first internal communication interface provided by the bus master device includes, but is not limited to, an Inter-Integrated Circuit (Integrated Circuit Bus) interface; SPI interface (Serial Peripheral Interface, Serial Peripheral Interface); CAN (Controller Area Network) interface, through the first internal communication interface and the corresponding bus basic protocol, the bus main device can perform data interaction with other devices in the system; … wherein the operating system 221 for managing and controlling the electronic device 20 of each hardware device and computer program 222, so as to realize the processor 21 the memory 22 mass data 223 operation and processing, which can be Windows Server, Netware; Unix, Linux and so on). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Wu’s SPI with Wang’s firmware update to modify Wang’s ADV system to combine the SPI as taught by Wu, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to firmware update. Combining Wu’s functionality with that of Wang results in a system that allows to use a SPI. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to achieve speed, simplicity and data streaming efficiency (Wu, see at least fig. 1 and 2 and associated texts, the first internal communication interface provided by the bus master device includes, but is not limited to, an Inter-Integrated Circuit (Integrated Circuit Bus) interface; SPI interface (Serial Peripheral Interface, Serial Peripheral Interface); CAN (Controller Area Network) interface, through the first internal communication interface and the corresponding bus basic protocol, the bus main device can perform data interaction with other devices in the system; … wherein the operating system 221 for managing and controlling the electronic device 20 of each hardware device and computer program 222, so as to realize the processor 21 the memory 22 mass data 223 operation and processing, which can be Windows Server, Netware; Unix, Linux and so on).
Per claim 10:
Wang does not explicitly teach wherein the system manager is connected to the motherboard via a universal asynchronous receiver/transmitter (UART) link. Wu teaches wherein the system manager is connected to the motherboard via a universal asynchronous receiver/transmitter (UART) link (Wu, see at least fig. 1 and 2 and associated texts, obtaining the corresponding target format frame. wherein the external communication interface can be a wireless communication interface, such as supporting TCP/IP communication protocol, also can be wired communication interface, such as USART (…universal synchronous/asynchronous serial receiving/transmitter); the external communication interface is mainly used for receiving external device when firmware upgrading or reading firmware data is needed; for example, the PC application program sends the related request to the system internal device; Note that every USART can function as a UART as it has a built-in UART mode). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Wu’s UART with Wang’s firmware update to modify Wang’s ADV system to combine the SPI as taught by Wu, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to firmware update. Combining Wu’s functionality with that of Wang results in a system that allows to use a UART. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to achieve simplicity, hardware flexibility and minimal wiring (Wu, see at least fig. 1 and 2 and associated texts, obtaining the corresponding target format frame. wherein the external communication interface can be a wireless communication interface, such as supporting TCP/IP communication protocol, also can be wired communication interface, such as USART (…universal synchronous/asynchronous serial receiving/transmitter); the external communication interface is mainly used for receiving external device when firmware upgrading or reading firmware data is needed; for example, the PC application program sends the related request to the system internal device; Note that every USART can function as a UART as it has a built-in UART mode).
Claims 11, 12, and 14-17 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. (US20240329961, hereafter Wang) in view of JP2022010389A (hereafter Harada)
Per claim 11:
Wang teaches:
wherein the second microprocessor device distributes power to a motherboard and an ethernet switch and the first microprocessor device is powered independently of the second microprocessor device (Wang, see at least [0066] power control SW/HW on board; [0080] perform board power control and system monitoring, as well as performing dual booting to reduce the risk of FOTA failure due to power loss; [0061]; [0023]; [0067] In some examples, the first network path may comprise a first switch (e.g., switch 526) that is powered by a first power source (e.g., main power 510) and the second network path may comprise a second switch (e.g., switch 528) that is powered by a second power source (e.g., backup power 512); [0076] all FOTA paths (e.g., from a gateway to a target device) are dual redundant (e.g., have two separate paths) and are distributed in two power domains; Note that the power sources provide power to the board housing hardware components and network switch and the host device connected to the target device corresponds to the safehold system and is powered independently of the target device).
downloading an image comprising the firmware update to a persistent memory of the first microprocessor device; transferring the image by the first microprocessor device to the second microprocessor device; determining that the image was successfully installed on the second microprocessor device; and subsequent to the determining, confirming that the second microprocessor device is in communication with the motherboard and an ethernet switch.
(Wang, see at least [0022] Processing logic may further be configured to store, on a host device among the plurality of network components, the firmware and a second firmware of the target device, and in response to detecting the failure, direct the second firmware to the target device through the first network path or through the second network path; [0070]; [0071] processing logic may implement a safety booting option to allow recovery of the target device 614 in response to a failure. Processing logic may include a boot controller 604 to implement dual booting operations on a host device 602. For example, boot controller 604 may store, on host device 602 the firmware 608 and a second firmware 612; [0062], after the firmware is uploaded to the target device 504 and the target device boots, processing logic 518 may check the version number and health of upgraded target device 504 to confirm that the firmware update is successful; [0073];[0080] the MCUs (708, 722) and CPLD (704, 720) may be configured to perform board power control and system monitoring, as well as performing dual booting to reduce the risk of FOTA failure due to power loss. … may be configured to serve as a host device (as described with respect to host device 602) and perform a dual boot of a target device with firmware and a backup firmware; Note that the host device performs the checks the update process on a target device). (Wang, see at least [0062] Processing logic 518 may perform an integrity check to detect that a host device and target device are healthy, or perform a version compatibility check, or perform a data path health check, or a combination of such checks, prior to performing the firmware update. Processing logic 518 may proceed with the firmware update if the one or more checks pass. Similarly, after the firmware is uploaded to the target device 504 and the target device boots, processing logic 518 may check the version number and health of upgraded target device 504 to confirm that the firmware update is successful. If the checks fail after the firmware is uploaded, then processing logic may also direct a different firmware to the target device to try to ‘revive’ the target device; Note that the health check for the upgraded target device to confirm that the update was successful determines whether the target device responds correctly, that is, whether the circuits/power delivery on that chip driven by the MCU/CPLD doing board power control and system monitoring, the switches along the path forwarding traffic, the ethernet port on that device being physically up work correctly. More specifically, the chips on a board must be powered and executing, the board level power control must be delivering correct voltage, the ethernet port on that device must be forwarding packets correctly and the host device running the check must successfully communicate the poll over that path, therefore, a successful response to polling result is by necessity, indirect evidence that the board, its power delivery and all of those underlying links worked. The success implies the whole physical and network chain worked).
Wang does not explicitly teach determining by a first microprocessor device that a firmware update for a second microprocessor device is available. Harada teaches determining by a first microprocessor device that a firmware update for a second microprocessor device is available (FIG. 52-53 and associated texts, When the update suitability determination unit 52c determines that the update data for the vehicle is present by the update presence / absence determination unit 52b, the update suitability determination unit 52c determines whether or not the vehicle state is suitable for updating a program or the like using the distribution package). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Harada’s update availability check with Wang’s firmware update to modify Wang’s ADV system to combine the update availability check, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to firmware update. Combining Harada’s functionality with that of Wang results in a system that allows to check an availability. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to perform a check to see if there is an update available to obtain the update (FIG. 52-53 and associated texts, When the update suitability determination unit 52c determines that the update data for the vehicle is present by the update presence / absence determination unit 52b, the update suitability determination unit 52c determines whether or not the vehicle state is suitable for updating a program or the like using the distribution package).
Per claim 12:
Wang teaches: The method of claim 11, wherein the image is downloaded from an autonomous vehicle (AV) ethernet network via the ethernet switch and the motherboard (Wang, see at least [0025] an autonomous driving network configuration … coupled to servers 103-104 over network 102; [0058] through wired or wireless connections with a known communication protocol (e.g., TCP/IP, ethernet, Wi-Fi, etc.); [0066] power control SW/HW on board; [0080] perform board power control and system monitoring, as well as performing dual booting to reduce the risk of FOTA failure due to power loss; [0061]; [0023]; [0067] In some examples, the first network path may comprise a first switch (e.g., switch 526) that is powered by a first power source (e.g., main power 510) and the second network path may comprise a second switch (e.g., switch 528) that is powered by a second power source (e.g., backup power 512); [0084] In this computer network 700, switch 714 may be powered in the safety power domain 732, while switch 718 and switch 716 are powered in the main power domain 730. In addition to ethernet communications, components may be coupled through configuration ports that allows one device to read or write configurable settings on another device; [0067]; [0069]; [0073]; [0078]; [0036] Based on driving statistics 123, machine learning engine 122 generates or trains a set of rules, algorithms, and/or predictive models 124 for a variety of purposes. Algorithms 124 can then be uploaded on ADVs to be utilized during autonomous driving in real-time).
Per claim 14:
Wang teaches: The method of claim 11, wherein the image comprises a first image, the method further comprising storing a backup image comprising a previous firmware update for the second microprocessor device in the persistent memory (Wang, see at least [0071] boot controller 604 may store, on host device 602 the firmware 608 and a second firmware 612; [0038] autonomous driving system 300 includes a firmware over-the-air (FOTA) module 360. FOTA module 360 may utilize component settings 362 which may be stored in persistent storage device; [0074]; [0083], [0072] Firmware 612 may be referred to as a backup firmware. In some examples, firmware 612 has reduced size and capability relative to the firmware 608. For example, firmware 612 may support only the essential functionalities of the target device. In some examples, firmware 612 is a previous version of the firmware 608. For example, firmware 608 may be version 1.2 while firmware 612 may be a previous version 1.1; Note that the firmware and backup firmware are stored in the host boot storage device and its partitions which are persistent memory).
Per claim 15:
Wang teaches: The method of claim 14, further comprising transferring the backup image by the first microprocessor device to the second microprocessor device if it is determined that the first image was not successfully installed on the second microprocessor device (Wang, see at least [0067] Thus, if the main power 510 fails, a backup FOTA may still be performed through an alternative wireless gateway and alternative network path that is powered separately by backup power 512; [0083] Each MCU and CPLD may support dual booting, such that if a new version of firmware fails for that MCU or CPLD, the backup firmware (e.g., stored in a separate boot partition) is activated to boot the respective MCU or CPLD).
Per claim 16:
Wang teaches: The method of claim 15, further comprising: determining whether the backup image was successfully installed on the second microprocessor device; and subsequent to a determination that the backup image was successfully installed on the second microprocessor device, confirming that the second microprocessor device is in communication with the motherboard and an ethernet switch (Wang, see at least [0022] Processing logic may further be configured to store, on a host device among the plurality of network components, the firmware and a second firmware of the target device, and in response to detecting the failure, direct the second firmware to the target device through the first network path or through the second network path; [0061]; [0023]; [0067] In some examples, the first network path may comprise a first switch (e.g., switch 526) that is powered by a first power source (e.g., main power 510) and the second network path may comprise a second switch (e.g., switch 528) that is powered by a second power source (e.g., backup power 512); [0076] all FOTA paths (e.g., from a gateway to a target device) are dual redundant (e.g., have two separate paths) and are distributed in two power domains; Note that the power sources provide power to the board housing hardware components and network switch [0070]; [0071] processing logic may implement a safety booting option to allow recovery of the target device 614 in response to a failure. Processing logic may include a boot controller 604 to implement dual booting operations on a host device 602. For example, boot controller 604 may store, on host device 602 the firmware 608 and a second firmware 612; [0062], after the firmware is uploaded to the target device 504 and the target device boots, processing logic 518 may check the version number and health of upgraded target device 504 to confirm that the firmware update is successful; [0073];[0080] the MCUs (708, 722) and CPLD (704, 720) may be configured to perform board power control and system monitoring, as well as performing dual booting to reduce the risk of FOTA failure due to power loss. … may be configured to serve as a host device (as described with respect to host device 602) and perform a dual boot of a target device with firmware and a backup firmware; Note that the host device checks the update process on a target device).
Per claim 17:
Wang teaches: The method of claim 14, wherein the backup image comprises a last known verified firmware image for the second microprocessor device (Wang, see at least [0072] Firmware 612 may be referred to as a backup firmware. In some examples, firmware 612 has reduced size and capability relative to the firmware 608. For example, firmware 612 may support only the essential functionalities of the target device. In some examples, firmware 612 is a previous version of the firmware 608. For example, firmware 608 may be version 1.2 while firmware 612 may be a previous version 1.1; [0071]; [0074] If so, boot controller 604 will switch to the storage device 610 and route firmware 612 to target device 614. This may allow target device 614 to recover from a failed firmware update, even if the target operates in a degraded mode (e.g., with a smaller firmware image); Note that the backup firmware is last known verified version used to recover from a failed firmware update).
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Wang in view of Harada and Astarabadi et al. (US 9542195, hereafter Astarabadi)
Per claim 13:
Wang teaches determining integrity or health check of a target device (second microprocessor device) prior to communications between the second microprocessor device and the motherboard and the ethernet switch being successful (Wang, see at least [0070] Processing logic may detect a failure by monitoring the target device 614. For example, processing logic may determine that the FOTA has failed if the power consumption or temperature of the target device satisfy a respective threshold. In another example, processing logic may detect the failure if a heartbeat of the target device 614 is not present, or if the target device 614 is unresponsive to polling. Processing logic may detect the failure based on one or more conditions such as those discussed or a combination thereof; [0062] Processing logic 518 may perform an integrity check to detect that a host device and target device are healthy, or perform a version compatibility check, or perform a data path health check, or a combination of such checks, prior to performing the firmware update; [0073] to help safety monitoring, the boot controller 604 may perform integrity check of a target device before and after the FOTA process. For example, boot controller 604 may obtain the current version of firmware from target device 614 and verify that this version is compatible with firmware 608).
Wang does not explicitly teach the determining includes determining whether a watchdog timer of the second microprocessor device has expired. Astarabadi teaches determining whether a watchdog timer of the second microprocessor device has expired (Astarabadi, see at least fig. 1 and 3 and associated texts, the BMC 110 determines whether the watchdog timer expired). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Astarabadi’s watchdog timer expiration check with Wang’s firmware update to modify Wang’s ADV system to combine the timer check, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to firmware update. Combining Astarabadi’s functionality with that of Wang results in a system that allows to check the watchdog timer. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to ensure system reliability forcing automated recovery or preventing deadlocks (Astarabadi, see at least fig. 1 and 3 and associated texts, the BMC 110 determines whether the watchdog timer expired).
Examiner’s Note
The Examiner has pointed out particular references contained in the prior art of record within the body of this action 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. Applicant, in preparing the response, should consider fully the entire reference 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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
JP 2022180041 is related to software updating while suppressing vehicle battery power consumption;
CN 115576580 is related to firmware upgrading relating to the technical field of automatic driving;
US 20190287409 Is related to fallback task to self-driving systems;
US20210157563 is related to software update and runtime update verification;
CN 113986282 is related to automatic upgrading of automobile instrument.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to INSUN KANG whose telephone number is (571)272-3724. The examiner can normally be reached M-TR 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, Chat Do can be reached at 571-272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/INSUN KANG/Primary Examiner, Art Unit 2193
Prosecution Insights