Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This is the initial office action based on the application filed on December 16th, 2023, which claims 1-20 are presented for examination.
Status of Claims
3. Claims 1-20 are pending, of which claims, of which claim 1, 14 and 15 are in independent form.
Priority
4. No priority has been considered for this application
Information Disclosure Statement
5. Information disclosure statement filed on 12/21/2023, has been reviewed and considered by Examiner.
The Office's Note:
6. The Office has cited particular paragraphs / columns and line numbers in the reference(s) applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim(s), other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing 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 cited passages as taught by the prior art or relied upon by the Examiner.
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.
7. Claims 1-10 and 14-20 are rejected under 35 U.S.C. 103 as being unpatentable over Yan (US 20260030112– hereinafter Yan) and further in view of David (US 20200174779 – hereinafter David – IDS of records).
Claim 1 rejected, Yan teaches a program update method of a mobile object by acquiring new program from a server device via a network, the method comprising (Yan, abstract and summary):
(i) determining by the mobile object whether a predetermined abnormal condition is met or not, and when it is determined that the predetermined abnormal condition is met, sending a signal indicating abnormality from the mobile object to the server device (Yan, US 20260030112, para [0076-0086], Fig. 1 is a diagram of an application scenario in which OTA update of a vehicle fails. Para [0134], S104: The OTA server obtains status information of the vehicle when the first OTA update fails. Para [0135-0139], In this embodiment of this disclosure, in S103, when the vehicle fails to perform the first OTA update on the first component based on the first update package, the OTA server may obtain the status information of the vehicle, to repair and update (namely, second OTA update) the first component. Para [0140-0141], In an implementation, the OTA server may receive the log information of the first OTA update sent by the OTA system of the vehicle, to obtain the status information of the vehicle. The log information is log information recorded in a process in which the OTA manager performs the first OTA update on the first component, and may include an update process execution action, an execution result, update task failure prompt information, and the like. The OTA server may obtain the status information of the vehicle by extracting the log information of the OTA update, and may further determine the status information of the first component and the status information of the second component.);
(ii) determining by the server device whether a purge process is required or not based on the received signal indicating abnormality, and when it is determined that the purge process is required, sending a purge instruction from the server device to the mobile object (Yan, fig. 5 and para [0142-0145], S105: The OTA server determines first indication information based on the status information of the vehicle, and sends the first indication information to the vehicle. Para [0169-0177], obtain the second update package by using the OTA server after the vehicle receives the first indication information in S106 and before the vehicle performs the second OTA update on the first component based on the second update package in S107. Para [0178-0180], perform data flashing on a system of the second component based on the update file, to repair and update the second component.);
Yan does not explicitly teach
(iii) according to the received purge instruction, by the mobile object, deleting a data stored in a memory device equipped with the mobile object regarding update of a program of an electronic control unit equipped with the mobile object
However, David teaches
(iii) according to the received purge instruction, by the mobile object, deleting a data stored in a memory device equipped with the mobile object regarding update of a program of an electronic control unit equipped with the mobile object (David, US 20200174779, para [0039-0045], the OTA updater device 108 manages the update process and causes the newly installed software to be copied to the backup location on the vehicle in order to provide the ability to revert or “roll back” to the version stored at the backup location in the event of, for example, an error or interruption during a future software update. Para [0062-0063], he component that was not successfully updated may be rolled back to a backup software version. Para [0051-0055], the OTA updater device 108 manages the update process and causes the newly installed software to also be copied to the backup location on the vehicle if the update is successful. The copying of the newly installed software to the backup location may involve overwriting a previously stored backup version. If, on the other hand, an interruption or error is detected during installation of the current update, installation of the current update can be suspended and a previously stored backup version of the software can be installed.).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate David into Yan to provide an error-resilient over-the-air software updating method that uses a local backup approach in which a backup software version, which is previously stored in the vehicle and checked for validity, is automatically reinstalled in the event that errors or interruptions occur during over-the-air software updates. Allows the vehicle to be more error-resilient and self-healing with respect to software problems, because user interaction is not required and the vehicle need not be driven to a service center to correct the software problems, thus avoiding altered itineraries and corresponding costs in terms of delays and fuel consumption. Ensures that the error resilience and self-healing aspects of the updating method improves vehicle autonomy.as suggested by David (See abstract and summary).
Claim 2 is rejected for the reasons set forth hereinabove for claim 1, Yan and David teach the program update method of the mobile object according to claim 1, wherein the step (ii) determines whether the purge process is required or not by using the number of times the server device has received the signal indicating abnormality from the mobile object or by using frequency the server device has received the signal indicating abnormality from the mobile object (David, fig. 4 and para [0058-0060], If the installation of the update fails or is interrupted, the installation may be retried at block 408 (e.g., up to a specified number of attempts, such as 5 attempts). If the installation cannot be completed successfully (e.g., if a specified number of attempts has been reached without success, or if a user has canceled the update process), the method proceeds to block 409, where the OTA updater device cancels installation of the software update.).
Claim 3 is rejected for the reasons set forth hereinabove for claim 2, Yan and David teach the program update method of the mobile object according to claim 2, wherein the step (ii) uses a threshold value to be compared with the number of times, and wherein the threshold value is varied depending on a model of the mobile object (David, fig. 4 and para [0058-0060], If the installation of the update fails or is interrupted, the installation may be retried at block 408 (e.g., up to a specified number of attempts, such as 5 attempts). If the installation cannot be completed successfully (e.g., if a specified number of attempts has been reached without success, or if a user has canceled the update process), the method proceeds to block 409, where the OTA updater device cancels installation of the software update.).
Claim 4 is rejected for the reasons set forth hereinabove for claim 3, Yan and David teach the program update method of the mobile object according to claim 3, wherein the step (ii) determines whether the server device has continuously received the signal indicating abnormality from the mobile object the number of times defined by the threshold value (David, fig. 4 and para [0058-0059], If the installation of the update fails or is interrupted, the installation may be retried at block 408 (e.g., up to a specified number of attempts, such as 5 attempts). If the installation cannot be completed successfully (e.g., if a specified number of attempts has been reached without success, or if a user has canceled the update process), the method proceeds to block 409, where the OTA updater device cancels installation of the software update.).
Claim 5 is rejected for the reasons set forth hereinabove for claim 1, Yan and David teach the program update method of the mobile object according to claim 1, wherein the predetermined abnormal condition is met when the mobile object does not receive a configuration information from the electronic control unit, which is subject to the current program update, when the mobile object is powered on(Yan, para [0075-0080], During the OTA update of the vehicle, if the core component is abnormal (for example, the battery is faulty or the T-box is restarted), data flashing of a system of a to-be-updated component is interrupted, or an upper-layer application of the to-be-updated component is damaged. As a result, a system function of the to-be-updated component is damaged and cannot be normally used. In addition, even if the core component is recovered to be normal, because the system function of the to-be-updated component is damaged and cannot be normally used, the OTA system of the vehicle cannot determine whether the to-be-updated component meets the update condition, that is, the OTA system of the vehicle cannot accurately detect whether the vehicle still meets the update condition of the OTA update, and cannot perform the OTA update (repair and update) of the vehicle again. Consequently, the vehicle whose OTA update fails cannot be repaired.).
Claim 6 is rejected for the reasons set forth hereinabove for claim 5, Yan and David teach the program update method of the mobile object according to claim 5, wherein the mobile object waits the configuration information from the electronic control unit for a predetermined amount of time before determining that the predetermined abnormal condition is met (Yan, para [0126-0130], the first component is an IVI system. Because update time of the IVI system is long, if power of the vehicle is low before the update, the vehicle may lose power in an update process, resulting in an update failure. Therefore, the first update condition needs to include that the battery power is greater than a first threshold. The first update condition corresponding to the IVI system may include: The IVI system enables an update authorization state, the update package is in position, the update package passes verification, the vehicle mode is an update mode, the battery power is greater than the first threshold, or the like. David, para [0063-0065], the steps of retrieving and installing the backup software version may be delayed if user input is received from an HMI device (e.g., within a set time period after providing the corresponding notification) indicating the user's desire to retry the installation process before rolling back to a previous version.).
Claim 7 is rejected for the reasons set forth hereinabove for claim 6, Yan and David teach the program update method of the mobile object according to claim 6, wherein the predetermined amount of time is varied according to an instruction from the server device (David, para [0063-0065], the steps of retrieving and installing the backup software version may be delayed if user input is received from an HMI device (e.g., within a set time period after providing the corresponding notification) indicating the user's desire to retry the installation process before rolling back to a previous version.)..
Claim 8 is rejected for the reasons set forth hereinabove for claim 5, Yan and David teach the program update method of the mobile object according to claim 5, wherein the mobile object determines whether the predetermined abnormal condition is met or not every time the mobile object is powered on(David, para [0046-0047], In some embodiments, the OTA updater device 108 receives information that can be used to determine the vehicle state conditions from other components of the vehicle 106 via the vehicle communication bus to determine whether the vehicle 106 is ready to be updated and that it is safe for the update to proceed. Non-limiting and non-exclusive examples of vehicle state conditions that may be monitored to determine whether installation is ready to begin include whether the HMI device 214 of the vehicle has been actuated for a threshold amount of time, whether the engine of the vehicle 106 is off, whether an ignition key of the vehicle 106 is in an “on” position, whether a battery voltage of the vehicle 106 meets a battery voltage threshold to allow for successful updating, whether a wireless signal strength detected by the OTA updater device 108 meets a signal strength threshold, whether the vehicle speed is zero, and whether a parking brake of the vehicle 106 is set.).
Claim 9 is rejected for the reasons set forth hereinabove for claim 5, Yan and David teach the program update method of the mobile object according to claim 5, wherein powering on the mobile object includes turning on an ignition of the mobile object or powering on by pressing a brake pedal of the mobile object(David, para [0046-0050], In some embodiments, the OTA updater device 108 receives information that can be used to determine the vehicle state conditions from other components of the vehicle 106 via the vehicle communication bus to determine whether the vehicle 106 is ready to be updated and that it is safe for the update to proceed. Non-limiting and non-exclusive examples of vehicle state conditions that may be monitored to determine whether installation is ready to begin include whether the HMI device 214 of the vehicle has been actuated for a threshold amount of time, whether the engine of the vehicle 106 is off, whether an ignition key of the vehicle 106 is in an “on” position, whether a battery voltage of the vehicle 106 meets a battery voltage threshold to allow for successful updating, whether a wireless signal strength detected by the OTA updater device 108 meets a signal strength threshold, whether the vehicle speed is zero, and whether a parking brake of the vehicle 106 is set.).
Claim 10 is rejected for the reasons set forth hereinabove for claim 1, Yan and David teach the program update method of the mobile object according to claim 1, wherein when the predetermined abnormal condition is met, performing a notice by the mobile object to a user that the current program update is suspended (David, para [0058-0059], At block 410, the OTA updater device 108 retrieves a backup software version from a storage medium in the on-board computer system. At block 412, the OTA updater device 108 installs the backup software version on the updatable electronic component. As with other installations and updates, the installation of the backup software version may be monitored and validated. If the installation of the backup software version fails, the installation may be retried (e.g., up to a specified number of attempts, such as 5 attempts). If the installation of the update and the backup software version both fail, and the updatable electronic component becomes nonfunctional, the vehicle computer system may notify the operator about the problem (e.g., via an operator interface in the vehicle). The vehicle computer system may also determine whether the vehicle is operational or must be towed to a service center. If assistance is needed, the vehicle computer system may send a notification to a remote computer system, instruct the operator to call a service center, or take some other action.).
Claim 14 rejected, Yan teaches a program update system comprising (Yan, abstract and summary):
a server device (Yan, fig. 2, OTA server 200 and para [0088-0089]; and
a mobile object, wherein the mobile object comprises (Yan, fig. 2, Vehicle 100 and para [0087]):
an acquisition processor acquiring new program from the server deice via a network (Yan, fig. 2, OTA system 120 and para [0087-0089], A communication connection may be established between the vehicle 100 and the OTA server 200 through a vehicle cloud channel 300, to establish a networking communication link used to implement an OTA function. The vehicle cloud channel 300 may include, for example, an instruction channel for OTA task information, and a data transmission channel for downloading an update package. Para [0099-0102], FIG. 3A and FIG. 3B, the OTA system 120 in the vehicle 100 may include an OTA main control module 121, an update agent (UA) module 122, a vehicle function system 123, and the like.), and
a rewriting control processor performing a rewriting control of rewriting a program of an electronic control unit equipped with the mobile object, the rewriting being performed by using the acquired new program during drive of the mobile object is disabled (Yan, para [0082-0084], The first update condition may further include a condition associated with the OTA system, a condition associated with vehicle safety, and the like. For example, a PEPS update package is in position, the PEPS update package passes verification, a vehicle mode is an update mode, a vehicle gear is in a P (P) gear, an ACC gear is in an OFF gear, a high-voltage charging status is uncharged, and battery power meets an update requirement.),
the rewriting control processor determining whether a predetermined abnormal condition is met or not, and when it is determined that the predetermined abnormal condition is met, sending a signal indicating abnormality from the mobile object to the server device(Yan, US 20260030112, para [0076-0086], Fig. 1 is a diagram of an application scenario in which OTA update of a vehicle fails. Para [0134-0139], S104: The OTA server obtains status information of the vehicle when the first OTA update fails. Para [0135-0139], In this embodiment of this disclosure, in S103, when the vehicle fails to perform the first OTA update on the first component based on the first update package, the OTA server may obtain the status information of the vehicle, to repair and update (namely, second OTA update) the first component. Para [0140-0141], In an implementation, the OTA server may receive the log information of the first OTA update sent by the OTA system of the vehicle, to obtain the status information of the vehicle. The log information is log information recorded in a process in which the OTA manager performs the first OTA update on the first component, and may include an update process execution action, an execution result, update task failure prompt information, and the like. The OTA server may obtain the status information of the vehicle by extracting the log information of the OTA update, and may further determine the status information of the first component and the status information of the second component.),
wherein the server device comprises a program update control processor determining whether a purge process is required or not based on the received signal indicating abnormality, and when it is determined that the purge process is required, sending a purge instruction from the server device to the mobile object (Yan, fig. 5 and para [0142-0145], S105: The OTA server determines first indication information based on the status information of the vehicle, and sends the first indication information to the vehicle. Para [0169-0177], obtain the second update package by using the OTA server after the vehicle receives the first indication information in S106 and before the vehicle performs the second OTA update on the first component based on the second update package in S107. Para [0178-0185], perform data flashing on a system of the second component based on the update file, to repair and update the second component.), and
Yan does not explicitly teach
wherein the rewriting control processor of the mobile object, according to the received purge instruction, deletes a data stored in a memory device equipped with the mobile object regarding update of the program of the electronic control unit equipped with the mobile object
However, David teaches
wherein the rewriting control processor of the mobile object, according to the received purge instruction, deletes a data stored in a memory device equipped with the mobile object regarding update of the program of the electronic control unit equipped with the mobile object(David, US 20200174779, para [0039-0045], the OTA updater device 108 manages the update process and causes the newly installed software to be copied to the backup location on the vehicle in order to provide the ability to revert or “roll back” to the version stored at the backup location in the event of, for example, an error or interruption during a future software update. Para [0062-0063], he component that was not successfully updated may be rolled back to a backup software version. Para [0051], the OTA updater device 108 manages the update process and causes the newly installed software to also be copied to the backup location on the vehicle if the update is successful. The copying of the newly installed software to the backup location may involve overwriting a previously stored backup version. If, on the other hand, an interruption or error is detected during installation of the current update, installation of the current update can be suspended and a previously stored backup version of the software can be installed.).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate David into Yan to provide an error-resilient over-the-air software updating method that uses a local backup approach in which a backup software version, which is previously stored in the vehicle and checked for validity, is automatically reinstalled in the event that errors or interruptions occur during over-the-air software updates. Allows the vehicle to be more error-resilient and self-healing with respect to software problems, because user interaction is not required and the vehicle need not be driven to a service center to correct the software problems, thus avoiding altered itineraries and corresponding costs in terms of delays and fuel consumption. Ensures that the error resilience and self-healing aspects of the updating method improves vehicle autonomy.as suggested by David (See abstract and summary).
Claim 15 rejected, Yan teaches a mobile object comprising (Yan, abstract and summary):
an acquisition processor acquiring new program from a server deice via a network (Yan, fig. 2, OTA system 120 and para [0087-0089], A communication connection may be established between the vehicle 100 and the OTA server 200 through a vehicle cloud channel 300, to establish a networking communication link used to implement an OTA function. The vehicle cloud channel 300 may include, for example, an instruction channel for OTA task information, and a data transmission channel for downloading an update package. Para [0099-0102], FIG. 3A and FIG. 3B, the OTA system 120 in the vehicle 100 may include an OTA main control module 121, an update agent (UA) module 122, a vehicle function system 123, and the like.); and
a rewriting control processor performing a rewriting control of rewriting a program of an electronic control unit equipped with the mobile object, the rewriting being performed by using the acquired new program during drive of the mobile object is disabled(Yan, para [0082-0084], The first update condition may further include a condition associated with the OTA system, a condition associated with vehicle safety, and the like. For example, a PEPS update package is in position, the PEPS update package passes verification, a vehicle mode is an update mode, a vehicle gear is in a P (P) gear, an ACC gear is in an OFF gear, a high-voltage charging status is uncharged, and battery power meets an update requirement.),
the rewriting control processor determining whether a predetermined abnormal condition is met or not, and when it is determined that the predetermined abnormal condition is met, sending a signal indicating abnormality from the mobile object to the server device to cause a program update control processor of the server device to determine whether a purge process is required or not based on the received signal indicating abnormality, and to send a purge instruction from the server device to the mobile object when it is determined that the purge process is required(Yan, US 20260030112, para [0076-0086], Fig. 1 is a diagram of an application scenario in which OTA update of a vehicle fails. Para [0134-0139], S104: The OTA server obtains status information of the vehicle when the first OTA update fails. Para [0135-0139], In this embodiment of this disclosure, in S103, when the vehicle fails to perform the first OTA update on the first component based on the first update package, the OTA server may obtain the status information of the vehicle, to repair and update (namely, second OTA update) the first component. Para [0140-0141], In an implementation, the OTA server may receive the log information of the first OTA update sent by the OTA system of the vehicle, to obtain the status information of the vehicle. The log information is log information recorded in a process in which the OTA manager performs the first OTA update on the first component, and may include an update process execution action, an execution result, update task failure prompt information, and the like. The OTA server may obtain the status information of the vehicle by extracting the log information of the OTA update, and may further determine the status information of the first component and the status information of the second component. Yan, fig. 5 and para [0142-0145], S105: The OTA server determines first indication information based on the status information of the vehicle, and sends the first indication information to the vehicle. Para [0169-0177], obtain the second update package by using the OTA server after the vehicle receives the first indication information in S106 and before the vehicle performs the second OTA update on the first component based on the second update package in S107. Para [0178], perform data flashing on a system of the second component based on the update file, to repair and update the second component.), and
Yan does not explicitly teach
wherein the rewriting control processor of the mobile object, according to the received purge instruction, deletes a data stored in a memory device equipped with the mobile object regarding update of the program of the electronic control unit equipped with the mobile object
However, David teaches
wherein the rewriting control processor of the mobile object, according to the received purge instruction, deletes a data stored in a memory device equipped with the mobile object regarding update of the program of the electronic control unit equipped with the mobile object(David, US 20200174779, para [0039-0045], the OTA updater device 108 manages the update process and causes the newly installed software to be copied to the backup location on the vehicle in order to provide the ability to revert or “roll back” to the version stored at the backup location in the event of, for example, an error or interruption during a future software update. Para [0062-0063], he component that was not successfully updated may be rolled back to a backup software version. Para [0051], the OTA updater device 108 manages the update process and causes the newly installed software to also be copied to the backup location on the vehicle if the update is successful. The copying of the newly installed software to the backup location may involve overwriting a previously stored backup version. If, on the other hand, an interruption or error is detected during installation of the current update, installation of the current update can be suspended and a previously stored backup version of the software can be installed.).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate David into Yan to provide an error-resilient over-the-air software updating method that uses a local backup approach in which a backup software version, which is previously stored in the vehicle and checked for validity, is automatically reinstalled in the event that errors or interruptions occur during over-the-air software updates. Allows the vehicle to be more error-resilient and self-healing with respect to software problems, because user interaction is not required and the vehicle need not be driven to a service center to correct the software problems, thus avoiding altered itineraries and corresponding costs in terms of delays and fuel consumption. Ensures that the error resilience and self-healing aspects of the updating method improves vehicle autonomy.as suggested by David (See abstract and summary).
Claim 16 is rejected for the reasons set forth hereinabove for claim 15, Yan and David teach the mobile object according to claim 15, wherein the predetermined abnormal condition is met when the mobile object does not receive a configuration information from the electronic control unit, which is subject to the current program update, when the mobile object is powered on (Yan, para [0075-0080], During the OTA update of the vehicle, if the core component is abnormal (for example, the battery is faulty or the T-box is restarted), data flashing of a system of a to-be-updated component is interrupted, or an upper-layer application of the to-be-updated component is damaged. As a result, a system function of the to-be-updated component is damaged and cannot be normally used. In addition, even if the core component is recovered to be normal, because the system function of the to-be-updated component is damaged and cannot be normally used, the OTA system of the vehicle cannot determine whether the to-be-updated component meets the update condition, that is, the OTA system of the vehicle cannot accurately detect whether the vehicle still meets the update condition of the OTA update, and cannot perform the OTA update (repair and update) of the vehicle again. Consequently, the vehicle whose OTA update fails cannot be repaired.). .
Claim 17 is rejected for the reasons set forth hereinabove for claim 16, Yan and David teach the mobile object according to claim 16, wherein the mobile object waits the configuration information from the electronic control unit for a predetermined amount of time before determining that the predetermined abnormal condition is met after the mobile object is powered on (Yan, para [0126-0130], the first component is an IVI system. Because update time of the IVI system is long, if power of the vehicle is low before the update, the vehicle may lose power in an update process, resulting in an update failure. Therefore, the first update condition needs to include that the battery power is greater than a first threshold. The first update condition corresponding to the IVI system may include: The IVI system enables an update authorization state, the update package is in position, the update package passes verification, the vehicle mode is an update mode, the battery power is greater than the first threshold, or the like. David, para [0063], the steps of retrieving and installing the backup software version may be delayed if user input is received from an HMI device (e.g., within a set time period after providing the corresponding notification) indicating the user's desire to retry the installation process before rolling back to a previous version.).
Claim 18 is rejected for the reasons set forth hereinabove for claim 16, Yan and David teach the mobile object according to claim 16, wherein the predetermined amount of time is varied according to an instruction from the server device (David, para [0063-0065], the steps of retrieving and installing the backup software version may be delayed if user input is received from an HMI device (e.g., within a set time period after providing the corresponding notification) indicating the user's desire to retry the installation process before rolling back to a previous version.)..
Claim 19 is rejected for the reasons set forth hereinabove for claim 16, Yan and David teach the mobile object according to claim 16, wherein the mobile object determines whether the predetermined abnormal condition is met or not every time the mobile object is powered on (David, para [0046-0047], In some embodiments, the OTA updater device 108 receives information that can be used to determine the vehicle state conditions from other components of the vehicle 106 via the vehicle communication bus to determine whether the vehicle 106 is ready to be updated and that it is safe for the update to proceed. Non-limiting and non-exclusive examples of vehicle state conditions that may be monitored to determine whether installation is ready to begin include whether the HMI device 214 of the vehicle has been actuated for a threshold amount of time, whether the engine of the vehicle 106 is off, whether an ignition key of the vehicle 106 is in an “on” position, whether a battery voltage of the vehicle 106 meets a battery voltage threshold to allow for successful updating, whether a wireless signal strength detected by the OTA updater device 108 meets a signal strength threshold, whether the vehicle speed is zero, and whether a parking brake of the vehicle 106 is set.).
Claim 20 is rejected for the reasons set forth hereinabove for claim 16, Yan and David teach the mobile object according to claim 16, wherein powering on the mobile object includes turning on an ignition of the mobile object or powering on by pressing a brake pedal of the mobile object(David, para [0046-0050], In some embodiments, the OTA updater device 108 receives information that can be used to determine the vehicle state conditions from other components of the vehicle 106 via the vehicle communication bus to determine whether the vehicle 106 is ready to be updated and that it is safe for the update to proceed. Non-limiting and non-exclusive examples of vehicle state conditions that may be monitored to determine whether installation is ready to begin include whether the HMI device 214 of the vehicle has been actuated for a threshold amount of time, whether the engine of the vehicle 106 is off, whether an ignition key of the vehicle 106 is in an “on” position, whether a battery voltage of the vehicle 106 meets a battery voltage threshold to allow for successful updating, whether a wireless signal strength detected by the OTA updater device 108 meets a signal strength threshold, whether the vehicle speed is zero, and whether a parking brake of the vehicle 106 is set.).
8. Claims 11-13 are rejected under 35 U.S.C. 103 as being unpatentable over Yan (US 20260030112– hereinafter Yan), in view of David (US 20200174779 – hereinafter David – IDS of records) and further in view of Moeller (US 20160371076 – hereinafter Moeller).
With respect to claim 11, Yan and David do not explicitly teach all limitations of claim 11.
However, Moeller teaches.
Claim 11 is rejected for the reasons set forth hereinabove for claim 3, Yan and David teach the program update method of the mobile object according to claim 3, wherein the server device sends a campaign information to all mobile objects belonging to one campaign group, and the one campaign group corresponds to a specific one model of the mobile object (Moeller, US 20160371076, fig. 10 and para [0142-0145], Window 1031 comprises fields to name the update package (Name), to assign a recall number to the update package (Recall Number), to assign a technical bulletin number or numbers to the update package (Technical Bulletin), select a Vehicle Group, select a Download Schedule for downloading the update package, select an Install Schedule for installing the update package, determining whether the update release should be deployed in smaller sections and selecting the number of smaller sections (Stagger Release), selecting the percentage of completion that each stage must reach before the next stage begins (Completion Threshold), and set the maximum amount of time each stage should require to reach its threshold.) .
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Moeller into Yan and David to enable performing wireless remote update of software to the car ECUs in a simple and cost effective manner as suggested by Moeller (See abstract and summary).
Claim 12 is rejected for the reasons set forth hereinabove for claim 11, Yan and David teach the program update method of the mobile object according to claim 11, further comprises:(iv)updating the threshold value based on result of program update among the mobile objects belonging to the one campaign group (Moeller, fig. 10 and para [0142-0145], Window 1031 comprises fields to name the update package (Name), to assign a recall number to the update package (Recall Number), to assign a technical bulletin number or numbers to the update package (Technical Bulletin), select a Vehicle Group, select a Download Schedule for downloading the update package, select an Install Schedule for installing the update package, determining whether the update release should be deployed in smaller sections and selecting the number of smaller sections (Stagger Release), selecting the percentage of completion that each stage must reach before the next stage begins (Completion Threshold), and set the maximum amount of time each stage should require to reach its threshold.) .
Claim 13 is rejected for the reasons set forth hereinabove for claim 1, Yan and David teach the program update method of the mobile object according to claim 1, wherein the server device sends a campaign information to all mobile objects belonging to one campaign group, the one campaign group corresponds to a specific one model of the mobile object, and wherein the step (ii) determines whether other mobile object belonging to the one campaign group sent the signal indicating abnormality to the server device (Moeller, fig. 10 and para [0142-0145], Window 1031 comprises fields to name the update package (Name), to assign a recall number to the update package (Recall Number), to assign a technical bulletin number or numbers to the update package (Technical Bulletin), select a Vehicle Group, select a Download Schedule for downloading the update package, select an Install Schedule for installing the update package, determining whether the update release should be deployed in smaller sections and selecting the number of smaller sections (Stagger Release), selecting the percentage of completion that each stage must reach before the next stage begins (Completion Threshold), and set the maximum amount of time each stage should require to reach its threshold. Yan, fig. 5 and para [0142-0145], S105: The OTA server determines first indication information based on the status information of the vehicle, and sends the first indication information to the vehicle. Para [0169-0177], obtain the second update package by using the OTA server after the vehicle receives the first indication information in S106 and before the vehicle performs the second OTA update on the first component based on the second update package in S107. Para [0178], perform data flashing on a system of the second component based on the update file, to repair and update the second component).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Moeller into Yan and David to enable performing wireless remote update of software to the car ECUs in a simple and cost effective manner as suggested by Moeller (See abstract and summary).
Inquiry
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUY KHUONG THANH NGUYEN whose telephone number is (571)270-7139. The examiner can normally be reached Monday - Friday 0800-1630.
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, Lewis Bullock can be reached at 5712723759. 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.
/DUY KHUONG T NGUYEN/ Primary Examiner, Art Unit 2199