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 .
DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 11/11/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1 - 10 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 negated by the manner in which the invention was made.
Claim(s) 1, 2, 5, 9, & 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Harata (US 2021/0255805 A1) in view of Paterson (US 2019/0073011 A1).
Regarding Claim 1:
Harata discloses: A vehicle control system comprising: (Harata discloses in at least Paragraph 0280 a vehicle program rewriting system corresponding to a vehicle electronic control system)
a plurality of ECUs (Electronic Control Units) for controlling each of a plurality of function units mounted on a vehicle, the plurality of ECUs each comprising a non-volatile program memory and a vehicle control processor that controls at least one of the function units by executing a program stored in the program memory; and (Harata discloses in at least Paragraphs 0280 & 0291 wherein a vehicle may include a plurality of ECUs [electronic control units/vehicle control units] configured to perform vehicle control functionalities through the use of application programs installed on said units [i.e. by executing a program stored in the program storage unit]. At least Paragraphs 0292 & 0293 of Harata disclose wherein the functionalities controlled by the ECUs include door systems, displays, air conditioning, engine systems, braking systems, and the like [i.e. function unit(s) installed in the vehicle]. At least Paragraph 0296 of Harata discloses wherein the ECUs may contain flash memory corresponding to non-volatile memory [i.e. a non-volatile program storage unit], as well as a CPU [i.e. a processor] as disclosed in at least Paragraph 0306)
a master control processor which is connected with a plurality of the vehicle control processor, wherein the master control processor includes a non-volatile master memory, stores writing data for writing the program to the program memory in the master memory, (Harata discloses in at least Paragraph 0278 a vehicle master device [i.e. a master control processor] that includes a device that is configured to acquire, store, and distribute update data to rewrite target ECUs [i.e. write data for writing a program to a program memory]. At least Paragraphs 0288 & 0289 of Harata further discloses wherein the master device is communicatively coupled to the ECUs of the vehicle in order to write data to target ECUs [i.e. a master control processor is connected with the vehicle control processor]. At least Paragraph 0305 of Harata discloses wherein the master device includes a DCM [data communication module] with flash memory [i.e. non-volatile memory as set forth in at least Paragraph 0296 of Harata] to download and store distribution packages [i.e. writing data])
transmits a wake-up request which is a signal requesting to wake-up to the vehicle control processor of a target ECU that is at least one of the plurality of ECUs to which the program is written, (Harata discloses in at least Paragraph 0682 wherein a wake-up request is made [i.e. a signal requesting to wake-up is transmitted] to a rewrite target ECU [i.e. a target ECU that is at least one of the plurality of ECUs to which the program is written] that is currently in the sleep state via the central gateway [CGW] which is part of the vehicle master device as disclosed in at least Paragraph 0288)
instructs the vehicle control processor which responds to make transition to a first mode as an action mode for program writing, (Harata discloses in at least Paragraph 1096 wherein in response to the receipt of a wake up instruction, the target ECU [i.e. the vehicle control processor which responds to the wake-up request] is caused to transition into a wireless program update mode as an internal state [i.e. a first mode as an action mode for program writing])
executes a writing process of writing the program to the program memory provided to the vehicle control processor, on which transition to the first mode occurs, based on the writing data, (Harata discloses in at least Paragraphs 0374 & 0375 wherein the vehicle master device distributes write data to the target ECU and instructs the rewrite target ECU to write the write data [i.e. a writing process of writing the program to the program memory provided to the vehicle control processor… based on the writing data]. At least Paragraph 1096 of Harata further discloses wherein the installation of a program update, including the writing of the program to the rewrite target ECU, takes place following the instruction of the rewrite target ECU to wake up and transition to the wireless program update mode [i.e. the writing process is executed on the vehicle control processor, on which transition to the first mode occurs]. The above steps are further set forth in Figure 227 of Harata, below)
PNG
media_image1.png
464
682
media_image1.png
Greyscale
Harata however appears to be silent regarding:
Wherein the master control processor determines whether a response to the wake-up request is received from the vehicle control processor of the target ECU that receives the wake-up request, when determining that the response to the wake-up request is received from the vehicle control processor of the target ECU within a predetermined time,
and when determining that the response to the wake-up request is not received within the predetermined time, generates result data indicating a writing error, and stores the result data in the master memory.
However Paterson teaches wherein a sending device may transmit a wakeup request to a receiving device to trigger a state change from a sleep state to a wake state, with a timeout function being utilized to determine if the transfer between states of the receiving device was successful.
Wherein the master control processor determines whether a response to the wake-up request is received from the vehicle control processor of the target ECU that receives the wake-up request, when determining that the response to the wake-up request is received from the vehicle control processor of the target ECU within a predetermined time, (However Paterson teaches in at least Paragraphs 0043 & 0066 wherein a sender device [i.e. master control processor] may transmit a wakeup request to transfer a receiver device in a second power domain [i.e. a target ECU that receives the wake-up request] into an awake state from a sleep state, with a message handling unit bridging the connection between the two units. At least Paragraph 0069 of Paterson further teaches wherein a wakeup request is sent to the receiver from the sender, which may transmit back in return an awake signal indicating that the receiving unit is awake [i.e. a response to the wake-up request received from the target ECU that receives the wake-up request]. At least Paragraph 0070 of Paterson teaches wherein a timeout condition is evaluated, to determine if a certain period of time has elapsed since sending the wakeup request without an indication being provided that the receiver has not woken up [i.e. determining that the response to the wake-up request is received from the vehicle control processor of the target ECU within a predetermined time], the above sequence of steps being depicted in at least Figure 4 of Paterson, below. If the receiver does wake up, at least Paragraph 0071 of Paterson teaches wherein writing of a message to the receiver storage area takes place [i.e. executes a writing process of writing the program to the program memory])
PNG
media_image2.png
398
640
media_image2.png
Greyscale
and when determining that the response to the wake-up request is not received within the predetermined time, generates result data indicating a writing error, and stores the result data in the master memory. (However Paterson teaches in at least Paragraph 0070 wherein in the event that a timeout condition has arisen, in which a certain period of time has elapsed since sending the wakeup request without the receiver indicating that it has woken up, an error condition is returned at the sender device [i.e. when determining that the response to the wake-up request is not received within the predetermined time, result data indicating a writing error is generated] such that the sender can determine that the message send request has failed and can retry later, with at least Paragraphs 0058 & 0061 of Paterson teaching wherein the sender may store in memory the access readiness state of the receiver [i.e. the writing error result data is stored in sender/master memory])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the present claimed invention to have modified the disclosure of Harata by incorporating the determination of if a receiving device has transitioned into an awake state in response to a wakeup signal, and the return of an error indication if it has not, following a predetermined time interval elapsing without an awake response as taught by Paterson.
The motivation to do so is that, as acknowledged by Paterson in at least Paragraphs 0043 & 0070, it may be recognized when despite sending a wakeup request, the receiving device has not woken up to be capable of or otherwise ready for receiving the data transfer, improving the transfer of data by ensuring the target unit will receive the data transmitted, and returning an error message signaling the sending unit to retry later if the unit has not awakened.
Regarding Claim 2:
The vehicle control system according to claim 1, wherein the writing data include the program which is written to the program memory and association data which associate the program with the vehicle control processor, and the master control processor performs the writing process for the vehicle control processor in accordance with the association data.
Harata discloses in at least Paragraph 1183 wherein group information for ECUs having update targets are generated, including ECU IDs to identify the specific device and type of ECU [i.e. association data] as disclosed in at least Paragraph 1167 of Harata. At least Paragraph 1194 of Harata discloses wherein ECU IDs may be included in a rewrite environment information, which is subsequently utilized in generating a distribution package, as disclosed in at least Paragraph 1202 of Harada. The distribution package is then unpackaged and utilized by the master device to transfer update data to each respective ECU. Thus, the writing process is performed by the master control unit in accordance with the association data.
Regarding Claim 5:
The vehicle control system according to claim 1, comprising a connection unit that connects an external device which is present on an outside of the vehicle control system with the master control processor, wherein in a case where a program writing instruction is input from the external device, the master control processor transmits the wake-up request to the vehicle control processor.
Harata discloses in at least Paragraphs 0283 & 0284 wherein a mobile terminal, such as a smartphone or tablet that may be carried by a user [i.e. an external device], configured to perform a procedure relating to the rewriting of a vehicle application program. At least Paragraphs 0364, 0369 & 0370 of Harata further disclose wherein if an update is selected to be performed on the mobile terminal, the mobile terminal notifies the center device of a download request, which transmits the update distribution package to the master device, which initiates a write data process. This may include the wake-up request being made [i.e. transmitted] to a rewrite target ECU [i.e. vehicle control processor] that is currently in the sleep state via the central gateway [CGW] which is part of the vehicle master device, the above configuration being disclosed in at least Paragraphs 0288 & 0682 of Harata [i.e. in a case where a program writing instruction is input from the external device, the master control processor transmits the wake-up request to the vehicle control processor])
Regarding Claim 9:
Harata discloses: A program writing method in (Harata discloses in at least Paragraph 0280 a vehicle program rewriting system corresponding to a vehicle electronic control system, which may be embodied as an application program rewriting procedure [i.e. a method] as disclosed in at least Paragraph 0284)
a plurality of vehicle control processors each of which controls each of a plurality of function units installed in a vehicle by executing a program and a master control unit processor which is connected with each of the plurality of vehicle control processors, the program writing method comprising: (Harata discloses in at least Paragraph 0280 wherein a vehicle may include a plurality of ECUs [electronic control units/vehicle control units] configured to perform vehicle control functionalities through the use of application programs installed on said units. At least Paragraphs 0292 & 0293 of Harata disclose wherein the functionalities controlled by the ECUs include door systems, displays, air conditioning, engine systems, braking systems, and the like [i.e. function unit(s) installed in the vehicle]. At least Paragraph 0296 of Harata discloses wherein the ECUs may contain flash memory corresponding to non-volatile memory [i.e. a non-volatile program storage unit], as well as a CPU [i.e. a processor/plurality of processors] as disclosed in at least Paragraph 0306)
storing writing data for writing the program each of the plurality of vehicle control processors in a non-volatile master memory provided to the master control processor; (Harata discloses in at least Paragraph 0278 a vehicle master device [i.e. a master control processor] that includes a device that is configured to acquire, store, and distribute update data to rewrite target ECUs [i.e. write data for writing a program to a program memory]. At least Paragraphs 0288 & 0289 of Harata further discloses wherein the master device is communicatively coupled to the ECUs of the vehicle in order to write data to target ECUs [i.e. a master control processor is connected with the vehicle control processor]. At least Paragraph 0305 of Harata discloses wherein the master device includes a DCM [data communication module] with flash memory [i.e. non-volatile memory as set forth in at least Paragraph 0296 of Harata] to download and store distribution packages [i.e. writing data])
by the master control processor, transmitting a wake-up request which is a signal requesting to wake-up to the vehicle control processor of a target ECU (Electronic Control Unit) that is at least one of a plurality of ECUs to which the program is written, the plurality of ECUs each respectively including one of the plurality of vehicle control processors; (Harata discloses in at least Paragraph 0682 wherein a wake-up request is made [i.e. a signal requesting to wake-up is transmitted] to a rewrite target ECU [i.e. a target ECU that is at least one of the plurality of ECUs to which the program is written] that is currently in the sleep state via the central gateway [CGW] which is part of the vehicle master device as disclosed in at least Paragraph 0288)
instructing the vehicle control processor which responds to make transition to a first mode as an action mode for program writing; (Harata discloses in at least Paragraph 1096 wherein in response to the receipt of a wake up instruction, the target ECU [i.e. the vehicle control processor which responds to the wake-up request] is caused to transition into a wireless program update mode as an internal state [i.e. an action mode for program writing])
executing a writing process of writing the program to a non-volatile program memory provided to the vehicle control processor on which transition to the first mode occurs. (Harata discloses in at least Paragraphs 0374 & 0375 wherein the vehicle master device distributes write data to the target ECU and instructs the rewrite target ECU to write the write data [i.e. a writing process of writing the program to the program memory provided to the vehicle control processor… based on the writing data]. At least Paragraph 1096 of Harata further discloses wherein the installation of a program update, including the writing of the program to the rewrite target ECU, takes place following the instruction of the rewrite target ECU to wake up and transition to the wireless program update mode [i.e. the writing process is executed on the vehicle control unit, on which transition to the first mode occurs]. The above steps are further set forth in Figure 227 of Harata, above)
Harata however appears to be silent regarding:
determining whether a response to the wake-up request is received from the vehicle control processor of the target ECU that receives the wake-up request; when determines that the response to the wake-up request is received from the vehicle control processor of the target ECU within a predetermined time,
and when determining that the response to the wake-up request is not received within the predetermined time, generating result data indicating a writing error, and storing the result data in the master memory.
However Paterson teaches wherein a sending device may transmit a wakeup request to a receiving device to trigger a state change from a sleep state to a wake state, with a timeout function being utilized to determine if the transfer between states of the receiving device was successful.
determining whether a response to the wake-up request is received from the vehicle control processor of the target ECU that receives the wake-up request; when determines that the response to the wake-up request is received from the vehicle control processor of the target ECU within a predetermined time, (However Paterson teaches in at least Paragraphs 0043 & 0066 wherein a sender device [i.e. master control processor] may transmit a wakeup request to transfer a receiver device in a second power domain [i.e. a target ECU that receives the wake-up request] into an awake state from a sleep state, with a message handling unit bridging the connection between the two units. At least Paragraph 0069 of Paterson further teaches wherein a wakeup request is sent to the receiver from the sender, which may transmit back in return an awake signal indicating that the receiving unit is awake. At least Paragraph 0070 of Paterson teaches wherein a timeout condition is evaluated, to determine if a certain period of time has elapsed since sending the wakeup request without an indication being provided that the receiver has not woken up [i.e. determining that the response to the wake-up request is received from the vehicle control processor of the target ECU within a predetermined time], the above sequence of steps being depicted in at least Figure 4 of Paterson, above. If the receiver does wake up, at least Paragraph 0071 of Paterson teaches wherein writing of a message to the receiver storage area takes place [i.e. executes a writing process of writing the program to the program memory])
and when determining that the response to the wake-up request is not received within the predetermined time, generating result data indicating a writing error, and storing the result data in the master memory. (However Paterson teaches in at least Paragraph 0070 wherein in the event that a timeout condition has arisen, in which a certain period of time has elapsed since sending the wakeup request without the receiver indicating that it has woken up, an error condition is returned at the sender device [i.e. when determining that the response to the wake-up request is not received within the predetermined time, result data indicating a writing error is generated] such that the sender can determine that the message send request has failed and can retry later, with at least Paragraphs 0058 & 0061 of Paterson teaching wherein the sender may store in memory the access readiness state of the receiver [i.e. the writing error result data is stored in sender/master memory])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the present claimed invention to have modified the disclosure of Harata by incorporating the determination of if a receiving device has transitioned into an awake state in response to a wakeup signal, and the return of an error indication if it has not, following a predetermined time interval elapsing without an awake response as taught by Paterson.
The motivation to do so is that, as acknowledged by Paterson in at least Paragraphs 0043 & 0070, it may be recognized when despite sending a wakeup request, the receiving device has not woken up to be capable of or otherwise ready for receiving the data transfer, improving the transfer of data by ensuring the target unit will receive the data transmitted, and returning an error message signaling the sending unit to retry later if the unit has not awakened.
Regarding Claim 10:
Harata discloses: A vehicle manufacturing method comprising: (Harata discloses in at least Paragraph 0280 a vehicle program rewriting system corresponding to a vehicle electronic control system, which may be embodied as an application program rewriting procedure [i.e. a method] as disclosed in at least Paragraph 0284. This may take place in a factory during manufacturing as disclosed at least Paragraphs 0984 & 1023 of Harata [i.e. the process is a manufacturing one])
a providing step of providing, in a vehicle, a plurality of vehicle control processors each of which which includes a non-volatile program memory and controls a function unit installed in the vehicle by executing a program stored in the program memory and a master control processor; (Harata discloses in at least Paragraph 0280 wherein a vehicle may include a plurality of ECUs [electronic control units/vehicle control processors] configured to perform vehicle control functionalities through the use of application programs installed on said units. At least Paragraphs 0292 & 0293 of Harata disclose wherein the functionalities controlled by the ECUs include door systems, displays, air conditioning, engine systems, braking systems, and the like [i.e. function unit(s) installed in the vehicle]. At least Paragraph 0296 of Harata discloses wherein the ECUs may contain flash memory corresponding to non-volatile memory [i.e. a non-volatile program storage uni ], as well as a CPU [i.e. a processor] as disclosed in at least Paragraph 0306)
a wire-connection step of connecting the master control processor with the plurality of vehicle control processors by a communication wire; (Harata discloses in at least Paragraphs 0295 & 0297 wherein when a tool [i.e. master control unit] is connected to a DLC [data link coupler] connector [i.e. a wire connection step by a communication wire], the tool is configured to transfer write data to the CGW, which in turn distributes write data to the target ECUs)
a writing preparation step of transmitting a wake-up request which is a signal requesting to wake-up to the vehicle control processor of a target ECU (Electronic Control Unit) that is at least one of a plurality of ECUs to which the program is written, the plurality of ECUs each respectively including one of the plurality of vehicle control processors, (Harata discloses in at least Paragraph 0682 wherein a wake-up request is made [i.e. a signal requesting to wake-up is transmitted] to a rewrite target ECU [i.e. a target ECU that is at least one of the plurality of ECUs to which the program is written] that is currently in the sleep state via the central gateway [CGW] which is part of the vehicle master device as disclosed in at least Paragraph 0288)
instructing, by the master control processor, the vehicle control processor to make transition to a first mode as an action mode for program writing after the wire-connection step; and (Harata discloses in at least Paragraph 0682 wherein a wake-up request is made [i.e. transmitted] to a rewrite target ECU [i.e. vehicle control unit] that is currently in the sleep state via the central gateway [CGW] through which the tool [i.e. master control processor] transfers write data to via the wired connection. Harata discloses in at least Paragraph 1096 wherein in response to the receipt of a wake up instruction, the target ECU [i.e. the vehicle control unit which responds to the wake-up request] is caused to transition into a wireless program update mode as an internal state [i.e. an action mode for program writing])
a writing step of executing, by the master control processor, a writing process of writing the program to the program memory for the vehicle control processor on which transition to the first mode occurs, (Harata discloses in at least Paragraphs 0374 & 0375 wherein the vehicle master device, controlled by a tool [construed for the purposes of this claim as the master control unit] via a DLC connector, distributes write data to the target ECU and instructs the rewrite target ECU to write the write data [i.e. a writing process of writing the program to the program memory provided to the vehicle control processor… based on the writing data]. At least Paragraph 1096 of Harata further discloses wherein the installation of a program update, including the writing of the program to the rewrite target ECU, takes place following the instruction of the rewrite target ECU to transition to the wireless program update mode [i.e. the writing process is executed on the vehicle control unit, on which transition to the first mode occurs]. The above steps are further set forth in Figure 227 of Harata, above)
Harata however appears to be silent regarding:
determining whether a response to the wake-up request is received from the vehicle control processor of the target ECU that receives the wake-up request, and when determining that the response to the wake-up request is received from the vehicle control processor of the target ECU within a predetermined time,
and when determining that the response to the wake-up request is not received within the predetermined time, generating result data indicating a writing error, and storing the result data in the master memory.
However Paterson teaches wherein a sending device may transmit a wakeup request to a receiving device to trigger a state change from a sleep state to a wake state, with a timeout function being utilized to determine if the transfer between states of the receiving device was successful.
determining whether a response to the wake-up request is received from the vehicle control processor of the target ECU that receives the wake-up request; when determines that the response to the wake-up request is received from the vehicle control processor of the target ECU within a predetermined time, (However Paterson teaches in at least Paragraphs 0043 & 0066 wherein a sender device [i.e. master control processor] may transmit a wakeup request to transfer a receiver device in a second power domain [i.e. a target ECU that receives the wake-up request] into an awake state from a sleep state, with a message handling unit bridging the connection between the two units. At least Paragraph 0069 of Paterson further teaches wherein a wakeup request is sent to the receiver from the sender, which may transmit back in return an awake signal indicating that the receiving unit is awake. At least Paragraph 0070 of Paterson teaches wherein a timeout condition is evaluated, to determine if a certain period of time has elapsed since sending the wakeup request without an indication being provided that the receiver has not woken up [i.e. determining that the response to the wake-up request is received from the vehicle control processor of the target ECU within a predetermined time], the above sequence of steps being depicted in at least Figure 4 of Paterson, above. If the receiver does wake up, at least Paragraph 0071 of Paterson teaches wherein writing of a message to the receiver storage area takes place [i.e. executes a writing process of writing the program to the program memory])
and when determining that the response to the wake-up request is not received within the predetermined time, generating result data indicating a writing error, and storing the result data in the master memory. (However Paterson teaches in at least Paragraph 0070 wherein in the event that a timeout condition has arisen, in which a certain period of time has elapsed since sending the wakeup request without the receiver indicating that it has woken up, an error condition is returned at the sender device [i.e. when determining that the response to the wake-up request is not received within the predetermined time, result data indicating a writing error is generated] such that the sender can determine that the message send request has failed and can retry later, with at least Paragraphs 0058 & 0061 of Paterson teaching wherein the sender may store in memory the access readiness state of the receiver [i.e. the writing error result data is stored in sender/master memory])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the present claimed invention to have modified the disclosure of Harata by incorporating the determination of if a receiving device has transitioned into an awake state in response to a wakeup signal, and the return of an error indication if it has not, following a predetermined time interval elapsing without an awake response as taught by Paterson.
The motivation to do so is that, as acknowledged by Paterson in at least Paragraphs 0043 & 0070, it may be recognized when despite sending a wakeup request, the receiving device has not woken up to be capable of or otherwise ready for receiving the data transfer, improving the transfer of data by ensuring the target unit will receive the data transmitted, and returning an error message signaling the sending unit to retry later if the unit has not awakened.
Claim(s) 3 & 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Harata (US 2021/0255805 A1) in view of Paterson (US 2019/0073011 A1) as applied to claim 1 above, and further in view of Kawamura (US 2017/0026492 A1).
Regarding Claim 3:
The vehicle control system according to claim 1, wherein in a case where a state where a signal from the master control processor is not received continues for a predetermined time period in the first mode, the vehicle control processor makes transition from the first mode to a second mode in which control of the function unit is capable of being started.
Harata discloses in at least Paragraph 0852 wherein a rewrite session [i.e. first mode] may be transitioned to a default session when a generic timeout is generated, the default session being disclosed in at least Paragraph 0851 of Harata to be a state in which vehicle control may be executed [i.e. a second mode in which control of the function unit is capable of being started]. At least Paragraph 0870 of Harata further discloses wherein the default session [i.e. second mode] is transitioned into upon completion of rewrite, which at least Paragraph 0776 of Harata discloses as occurring on completion of program rollback during a failed update. Harata however appears to be silent regarding specific details regarding the conditions causing the timeout to occur.
However Kawamura teaches in at least Paragraph 0064 wherein a control unit, which is part of a TCU [i.e. vehicle control processor] as taught in at least Paragraph 0031, determines if a predetermined time-out period has elapsed since an update is started [i.e. a predetermined time period in the first mode]. If the time-out period expires, the control unit increments a counter, and requests a delivery server [i.e. master control processor] to deliver the update again to attempt to resolve communication failure between the control unit and delivery server that causes the update data to not be acquired [i.e. a state where a signal from the master control unit is not received continues for a predetermined time period]. In the event of the time-out occurring for each retry time interval [i.e. where a signal from the master control processor is not received continues for a predetermined time period in the first mode], the control unit rolls back the software to the version prior to the update and finishes processing [i.e. the vehicle control unit makes transition from the first mode to a second mode in which control of the function unit is capable of being started].
PNG
media_image3.png
588
424
media_image3.png
Greyscale
It would have been obvious to one of ordinary skill in the art before the effective filing date of the present claimed invention to have further modified the combination of Harata and Peterson by incorporating the determination of communication time-out when the vehicle control unit is in an update mode as taught by Kawamura.
The motivation to do so is that, as acknowledged by Kawamura in at least Paragraph 0064, an update with associated update data that cannot be acquired in a predetermined time period may be determined to be unable to be completed, with associated processing being stopped, improving the usability of the vehicle when an update of the vehicle is unable to be fully acquired and completed.
Regarding Claim 4:
The vehicle control system according to claim 3, wherein in a case where transition occurs from the first mode to the second mode, the vehicle control processor notifies that writing of the program does not succeed to the master control processor.
Harata discloses in at least Paragraphs 0754 & 0755 wherein in response to an update failure, a rollback operation is performed and notified to a user through the use of a display [i.e. the vehicle control unit notifies that writing of the program does not succeed to the master control unit]. Harata further discloses in at least Paragraphs 0952 – 0954 wherein upon the completion and activation of an installation, a user is notified [i.e. a notification is provided in a case where transition occurs from the first mode to the second mode].
Claim(s) 6 - 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Harata (US 2021/0255805 A1) in view of Paterson (US 2019/0073011 A1) as applied to claim 5 above, and further in view of Aiba (US 2021/0173628 A1) and Yashiro (US 2014/0088827 A1).
Regarding Claim 6:
The vehicle control system according to claim 5, wherein in a case where a control signal which designates the vehicle control processor and instructs an action of the function unit is [input from the external device] and a case where the vehicle control processor which is designated by the control signal is executing the first mode, the master control processor notifies that a writing process to the vehicle control processor is executed to the external device.
Harata discloses in at least Paragraph 0754 wherein a progress state of rewriting may be displayed on the mobile device [i.e. external device] screen, however appears to be silent regarding providing notification of an ongoing writing process execution when an instruction is issued to control a vehicle function via the external device.
However Aiba teaches in at least Paragraph 0048 wherein in the event that the vehicle is in an update mode [i.e. the first mode is being executed] and an instruction is provided to control the vehicle engine or ignition [i.e. a control signal which designates the vehicle control unit and instructs an action of the function unit is input] driving or operation of the ignition are prohibited, and a monitor is instructed to display a screen for notifying that an update is in progress and the vehicle devices cannot be operated [i.e. the master control unit notifies that a writing process to the vehicle control unit is executed to the external device].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the present claimed invention to have further modified the combination of Harata and Peterson by incorporating the notification of a writing process being performed when a control signal instructs an action of the vehicle as taught by Aiba.
The motivation to do so is that, as acknowledged by Aiba in at least Paragraph 0048, a user may be notified of an in-progress update as the reason for which a vehicle component cannot currently be operated, improving the user understanding of the current functioning of the vehicle.
where a control signal which designates the vehicle control processor and instructs an action of the function unit is input from the external device
However Yashiro teaches in at least Paragraphs 0019 & 0033 a remote control device for a vehicle, implemented on a portable terminal/smartphone device. At least Paragraph 0088 of Yashiro teaches wherein vehicle software updates may be initiated through a vehicle software update menu button in the interface of the mobile device, paralleling the utility of said device in Harata. Further, Harata teaches in at least Paragraphs 0078, 0084, & 0085 a vehicle operation menu configured to allow a user to activate various vehicle functionalities, including general vehicle power, lights, horns, and the like [i.e. vehicle control signals for vehicle functions are input from an external device].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the present claimed invention to have further modified the combination of Harata and Peterson by incorporating the control of a vehicle from a remote terminal as taught by Yashiro.
The motivation to do so is that, as acknowledged by Yashiro in at least Paragraphs 0019 & 0020, the convenience of utilizing control functions of the vehicle may be improved through the integration of such remote functionality.
Regarding Claim 7:
The vehicle control system according to claim 5, wherein in a case where a control signal which designates the vehicle control processor and instructs an action of the function unit is [input from the external device], the master control processor transmits the control signal to the vehicle control processor, and in a case where the control signal is received from the master control processor in the first mode, the vehicle control processor does not execute control which is instructed by the control signal.
Harata does not appear to specifically disclose wherein a control signal is transmitted to the vehicle control processor from an external device, and the vehicle control processor is configured to not execute control instructed by the signal when in the first mode.
However Aiba teaches in at least Paragraph 0048 wherein in the event that the vehicle is in an update mode [i.e. the first mode is being executed] and an instruction is provided to control the vehicle engine or ignition [i.e. a control signal which designates the vehicle control processor and instructs an action of the function unit is input] driving or operation of the ignition are prohibited [i.e. the vehicle control unit does not execute control which is instructed by the control signal].
where a control signal which designates the vehicle control processor and instructs an action of the function unit is input from the external device
However Yashiro teaches in at least Paragraphs 0019 & 0033 a remote control device for a vehicle, implemented on a portable terminal/smartphone device. At least Paragraph 0088 of Yashiro teaches wherein vehicle software updates may be initiated through a vehicle software update menu button in the interface of the mobile device, paralleling the utility of said device in Harata. Further, Harata teaches in at least Paragraphs 0078, 0084, & 0085 a vehicle operation menu configured to allow a user to activate various vehicle functionalities, including general vehicle power, lights, horns, and the like [i.e. vehicle control signals for vehicle functions are input from an external device].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the present claimed invention to have further modified the combination of Harata and Peterson by incorporating the prevention of executing vehicle control when a control signal instructs an action of the vehicle while an update is in progress as taught by Aiba.
The motivation to do so is that, as acknowledged by Aiba in at least Paragraph 0048, a vehicle may be prevented from operating/driving or changing states when currently executing program update, improving the vehicle system by preventing the vehicle from attempting to operate based on a program currently being modified, improving the safety of operation of the vehicle.
Regarding Claim 8:
The vehicle control system according to claim 6, wherein the vehicle control processor is capable of executing plural action modes including the first mode while switching the plural action modes, starts control of the function unit in a case where the control signal is received from the master control processor in a different action mode from the first mode, and does not make transition to the first mode in a case where an instruction to make transition to the first mode is received from the master control processor while control of the function unit is executed.
Harata does not appear to specifically disclose wherein function control is performed when not in the first mode, and the first mode is not transitioned to if the instruction to do so while control of the vehicle functions is being executed.
However Aiba teaches in at least Paragraphs 0046 & 0047 wherein when it has been determined that the vehicle program should be updated, the system is configured to wait until the vehicle has been stopped, and the IG switch has been switched to an off state [i.e. the update mode is not switched to while control of the function unit is executed]. Upon the vehicle being determined to be parked and shut off, the state control unit is configured to transition to the update mode [i.e. transition to the first mode]. Thus, while control of the vehicle is executed, the first [i.e. update] mode is not transitioned into when an instruction is received to do so, and control of the vehicle is carried out according to input control commands when not in the update mode.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the present claimed invention to have further modified the combination of Harata and Peterson by preventing the vehicle from entering an update mode while being controlled as taught by Aiba.
The motivation to do so is that, as acknowledged by Aiba in at least Paragraphs 0046 & 0047, and as would have been obvious to one of ordinary skill in the art before the effective filing date of the present claimed invention, the vehicle may be continued to be operated until it is stopped for a sufficient time to complete the update, improving the usability of the vehicle when updates are pending by minimizing user-perceived downtime of the vehicle.
Conclusion
The following prior art made of record but not relied upon is considered pertinent to the Applicant’s disclosure:
Sakurai (US 11,163,549 B2): Sakurai recites a software update approach for electronic control units of a vehicle, including the determination of if software update data exists in an update database. This assessment is performed via a center apparatus, and if update data is determined to be available, the center apparatus sends software update data to the ECUs.
Satoh (US 11,620,125 B2): Satoh recites a software update device for a vehicle, including the control of the vehicle based on the update. When a software update is set to occur, the vehicle is configured to perform a control to unlock the vehicle door prior to the update occurring, in order to prevent problems occurring in the user interaction with the vehicle when a part of the vehicle operation is limited during software rewrite.
Kwak (US 11,175,835 B2): Kwak recites a storage device including the performance of self-maintenance operations. A controller may signal the device to cause it to exit a power saving mode and enter a maintenance mode, in which state the maintenance operation may be initiated.
Kurosawa (US 2017/0090907 A1): Kurosawa recites a vehicle mounted program writing device, including the use of a relay device waking vehicle mounted control device(s) when a write start command is transferred from an external center to write a program to the vehicle unit.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER RYAN CARDIMINO whose telephone number is (571)272-2759. The examiner can normally be reached M-Th 8:30-5:00.
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, Ramya Burgess can be reached at (571)272-6011. 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.
/CHRISTOPHER R CARDIMINO/Examiner, Art Unit 3661
/RAMYA P BURGESS/Supervisory Patent Examiner, Art Unit 3661
Prosecution Insights