DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. KR10-2022-0118645, filed on 09/20/2022.
Response to Amendment
This action is in response to amendments and remarks filed on 08/05/2025. The examiner notes the following adjustments to the claims by the applicant: (i) Claims 1, 5, 10, and 15 are amended; and (ii) Claim 4 is cancelled. Therefore, Claims 1-3 and 5-16 are pending examination, in which Claims 1, 10 and 15 are independent claims.
In light of the instant amendments and arguments:
The objection to the drawings for minor informalities is withdrawn.
The objection to Claim 1 for minor informalities is withdrawn.
Further examination resulted in a new rejection of Claims 1-3 and 5-16 under 35 U.S.C. § 103, as detailed below.
THIS ACTION IS MADE FINAL. Necessitated by amendment.
Response to Arguments
Applicant presents the following arguments regarding the previous office action:
To overcome the 35 U.S.C. § 102 and § 103 rejections, the applicant has amended each independent claim to include the additional underlined limitations: "changes in electronic control unit (ECU) mapping…wherein the CCU stores a PNC DB table, wherein at least one ECU required to execute a function in the vehicle, among ECUs of the network configuring unit, is mapped to a group and maintains a latest version by updating the changed PNC DB";
“Claim 1 of the present application seeks to solve this problem by detecting changes in the PNC DB regarding changes in ECU mapping, and by enabling the changed PNC DB to be distributed via OTA. However, the task that Kim attempts to address is merely to ensure that software over the air updating is stably performed by sufficiently considering the vehicle's power supply state. Therefore, the list of software/firmware update target ECUs disclosed in Kim cannot serve as a means to solve the above described problem. Specifically, Applicants submit that Kim fails to disclose or suggest "checking changes in ECU mapping of the PNC DB in real time ... when the PNC DB is changed ”as recited in amended claim 1.”;
“In contrast, as described in the present application (see, i.e., paragraph [0035]), when the mapping information of the PNC DB is changed due to system improvements such as minimization of power loss, the server transmits a PNC DB update event for the customer vehicle and provides the changed PNC DB via OTA in real time. As a result, the system can reduce power loss in electric vehicles (EVs) while maintaining smart car services, thereby enhancing customer satisfaction and securing marketability. Such an effect, i.e., a real-time reflection of system optimization through dynamic ECU- PNC mapping updates, is not attainable based on the disclosure of Kim, which lacks any teaching or suggestion of the claimed monitoring and responsive update mechanism based on PNC DB mapping changes.”.
Applicant's arguments A., B. and C. appear to be directed to the instantly amended subject matter. Accordingly, they have been addressed in the rejections below.
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.
Claims 1-3 and 5 are rejected under 35 U.S.C. §103 as being unpatentable over the combination of Kim (US 11,900,095 B2) and Sinha et al. (US 8,452,465 B1), henceforth Sinha.
Regarding Claim 1, Kim discloses the limitations: an electric vehicle network management system {Fig. 1}, comprising: a database configured to store a partial network cluster database/PNC-DB of various vehicles {vehicle-specific power information 332 and vehicle-specific power information 334, Fig. 3, and “The vehicle-specific ECU power/communication specification information 334 may include vehicle charge target setting information, ECU communication/power information, and communication channel-specific connected ECU information of vehicles. Such information used in the power information server 180 will be described in detail with reference to FIG. 4 and FIG. 5 below.”, Col. 5, Lns. 33-40, note, especially, the selective ECU function in Fig. 5}; a server {OTA server 170, power information server 180, Fig. 1} configured to manage an update and a download of the PNC-DB {software updating, Abstract}, and to check changes of the PNC-DB in real time to transmit an update event through over-the-air (OTA) when the PNC-DB is changed {“performing over-the-air (OTA) software updates”, Abstract}; and a vehicle {100, Fig. 1} configured to download the changed PNC-DB by the OTA when the update event is received from the server {vehicle communication control unit 134 in wireless communication with over-the-air server 170 and power information server 180 in Fig. 1}; wherein the vehicle includes: a domain control unit/DCU configured to download the changed PNC-DB {external communicator 294, Fig. 2, of communication control unit 134, Fig. 1}; and a central communication unit/CCU {internal communicator 292, Fig. 2, of communication control unit 134, Fig. 1} configured to wake up a plurality of electronic control units/ECUs of a network configuring unit {with respect to Figs. 1&5: “The communication channel-specific connected ECU information 506 refers to information indicating communication channels connected to the ECUs 116, respectively, and include information on whether each ECU 116 has a selective wake-up (or partial wake-up) function. In the case where when a particular ECU 116 is activated, only ECUs 116 related to the activated ECU 116 are activated, the activated ECUs 116 have the selective wake-up function. On the other hand, in the case where when a particular ECU 116 is activated, the other ECUs 116 even unrelated to the activated ECU 116 are also activated, the activated ECUs 116 do not have the selective wake-up function. The communication channel-specific connected ECU information 506 is used to confirm whether a particular ECU 116 operates alone or whether a particular ECU 116 needs to operate under a cooperative control with other ECUs 116. This is because power consumption of each ECU 116 needs to be accurately determined…when a cooperative control for other ECUs 116 is required during operation of the particular ECU 116, there is a need to consider power consumptions of the other ECUs 116 operating together as well as a power consumption of the particular ECU 116.”, Col. 8, Lns. 34-60}, the network configuring unit being configured to execute a specific function based on the changed PNC-DB {“Each of the at least one ECU 116 includes a communicator 252, a power unit 254, and an electrical load controller 256. The communicator 252 is provided to communicate with the other devices of the vehicle 100. For example, the communicator 252 may receive an electrical load control signal from the power control unit 132. The power unit 254 receives an electric power from the battery 114 and detects a voltage of the received electric power. The electrical load controller 256 controls an output of an electrical load 258. The electrical load 258 may include any devices that consume the electric power among the devices included in the vehicle 100 according to various exemplary embodiments of the present invention.”, Col. 5, Lns. 52-64}; and wherein the CCU stores a PNC DB table {“As a preparation process for determining the possibility of the OTA software update, the power control unit 132 of the vehicle 100 receives a list of target ECUs 116 of software/firmware updates”, Col.9, Lns. 30-33}, wherein at least one ECU required to execute a function in the vehicle {function associated with ECU5 in Fig. 5}, among ECUs of the network configuring unit, is mapped to a group and maintains a latest version by updating the changed PNC-DB {the tabulated data in Fig. 5 – i.e., 504 and 506 – is stored in communication control unit 134, Fig. 1, after being downloaded from power information server 180, Fig. 3; also, Fig. 6 reflects over-the-air updating of ECUs}.
Kim does not appear to explicitly recite the limitations: to check changes in electronic control unit (ECU) mapping.
However, Sinha explicitly recites the limitations: to check changes in electronic control unit (ECU) mapping {reconfiguring ECU mapping: “FIG. 4 illustrates an exemplary pre-determined mapping strategy that facilitates selection of the on-board reconfiguration strategy 420 by the on-board reconfiguration application 232.”, Col. 7, Lns. 26-29}.
Kim and Sinha are analogous art because they both deal with managing the tasks performed by a vehicle’s electronic control system.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Kim and Sinha before them, to modify the teachings of Kim to include the teachings of Sinha to reassign tasks or functionality to different ECUs in a multiple ECU control system {Fig. 4}.
Regarding Claim 2, the combination of Kim and Sinha discloses all the limitations of Claim 1, as discussed supra. In addition, Kim explicitly recites the limitations: wherein when the update event is received from the server {“performing over-the-air (OTA) software updates”, Abstract}, the DCU notifies the update event through an audio video navigation system/AVN in the vehicle or a mobile application {“OTA warning is output and information on the power status of the vehicle 100 is displayed to allow the driver to recognize the power status of the vehicle 100 related to the OTA software update (622)”, Col. 11, Lns. 41-44 and Fig. 6}.
Regarding Claim 3, the combination of Kim and Sinha discloses all the limitations of Claim 1, as discussed supra. In addition, Kim explicitly recites the limitation: wherein the DCU transmits an update request input from a user and downloads a changed PNC-DB from the server or the database to transmit the CCU {driver is provided with the option to initiate software update immediately or at a later time: “when the driver selects forced execution of the OTA software update in a state where an amount of electric power for completing the OTA software update is satisfied (‘No’ of 612), the power control unit 132 may allow the OTA software update of the vehicle 100 (626)”, Col. 11, Lns. 56-61}.
Regarding Claim 5, the combination of Kim and Sinha discloses all the limitations of Claim 1, as discussed supra. In addition, Kim explicitly recites the limitation: wherein the CCU adds a new PNC-DB group to an existing PNC-DB table {“The vehicle-specific ECU power/communication specification information 334 may include vehicle charge target setting information, ECU communication/power information, and communication channel-specific connected ECU information of vehicles.”, Col. 6, Lns. 33-37} or changes ECU mapping information of the existing PNC-DB group when an improved function of minimization of power loss is added or changed or based on the changed PNC-DB {“performing the OTA software update of the vehicle upon determining that the supply of the electric power higher than the value required to perform the OTA software update of the vehicle is possible”, Col. 9, Lns. 13-17}.
Claims 6-16 are rejected under 35 U.S.C. §103 as being unpatentable over the combination of Kim, Sinha in view of Nickel (US 2016/0224501 A1).
Regarding Claim 6, the combination of Kim and Sinha discloses all the limitations of Claim 1, as discussed supra. The combination of Kim and Sinha does not appear to explicitly recite the limitations: wherein when a PN transceiver is applied to the network configuring unit, the CCU controls selective wake-up in the unit of individual ECUs connected to a CAN bus of a gateway in a B+ power state of the vehicle.
However, Nickel explicitly recites the limitations: wherein when a PN transceiver is applied to the network configuring unit {“FIG. 1 shows a bus system 1 in which messages or signals may be transmitted via the CAN protocol…Subscriber stations 10, 20, 30 may be, for example, control units …subscriber stations 10, 30 each include a communication control device 11, an adaptation device 12, and a transceiver 13. In contrast, subscriber station 20 includes a communication control device 14 and a transceiver 13. Transceivers 13 of subscriber stations 10, 20, 30 are each directly connected to bus line 40, even though this is not illustrated in FIG. 1”, ¶[0030-0032]}, the CCU controls selective wake-up in the unit of individual ECUs connected to a CAN bus of a gateway in a B+ power state of the vehicle {“For assisting with a power-saving functionality in the sense of pretended networking and partial networking, the above-mentioned functions of adaptation device 12 may be integrated into the component of adaptation device 12 to be modified. For this purpose, additional control lines to the outside are possible in order to “wake up” hardware components from a power-saving mode. In addition, buffers may be inserted to be able to relay messages in a delayed manner.”, ¶[0062]}.
The combination of Kim and Sinha along with Nickel are analogous art because they deal with managing the tasks performed by a vehicle’s electronic control system.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Kim, Sinha and Nickel before them, to modify the teachings of the combination of Kim and Sinha to include the teachings of Nickel to increase the signaling speed of changing an ECU from a waking to sleeping mode, and vice versa {¶[0003] and ¶[0064]}.
Regarding Claim 7, the combination of Kim, Sinha and Nickel discloses all the limitations of Claim 6, as discussed supra. In addition, Kim explicitly recites the limitations: wherein a CCU identifies a PNC group specified to perform a requested specific scenario, and transmits the NM request message to only ECUs corresponding to the specified PNC group to be individually activated {selective/partial wake-up functionality described in Col. 8, Lns. 34-60, with respect to Figs. 1&5}.
The combination of Kim and Sinha does not appear to explicitly recite the limitations: wherein when a network management (NM) request message is received through the PN transceiver, and the CCU transmits the NM request message to ECUs to be individually activated.
However, Nickel explicitly recites the limitations: wherein when a network management (NM) request message is received through the PN transceiver {¶[0030-0032]}, and the CCU transmits the NM request message to ECUs to be individually activated {“For assisting with a power-saving functionality in the sense of pretended networking and partial networking, the above-mentioned functions of adaptation device 12 may be integrated into the component of adaptation device 12 to be modified. For this purpose, additional control lines to the outside are possible in order to “wake up” hardware components from a power-saving mode. In addition, buffers may be inserted to be able to relay messages in a delayed manner.”, ¶[0062]}.
Regarding Claim 8, the combination of Kim, Sinha and Nickel discloses all the limitations of Claim 6, as discussed supra. In addition, Kim explicitly recites the limitation: a wake-up event of the network and voltage regulator activation control for the individual ECUs {each of the ECUs 116 in Fig. 1 are represented in Fig. 2 as including a power unit 254 and electrical load controller 256} in the network configuring unit {selective/partial wake-up functionality described in Col. 8, Lns. 34-60, with respect to Figs. 1&5}.
The combination of Kim and Sinha does not appear to explicitly recite the limitation: wherein the PN transceiver detects an NM request message through an NM based selective wake-up function, and supports a wake-up event.
However, Nickel explicitly recites the limitation: wherein the PN transceiver detects an NM request message {¶[0030-0032]} through an NM based selective wake-up function, and supports a wake-up event {adaptation device 12 can be included in subscriber stations 10/20/30 to provide a “power-saving functionality in the sense of pretended networking and partial networking” and “the above-mentioned functions of adaptation device 12 may be integrated into the component of adaptation device 12 to be modified. For this purpose, additional control lines to the outside are possible in order to “wake up” hardware components from a power-saving mode.”, ¶[0062]}.
Regarding Claim 9, the combination of Kim and Sinha discloses all the limitations of Claim 1, as discussed supra. In addition, Kim explicitly recites the limitation: wherein when a PN transceiver is not applied to the network configuring unit {with regard to Figs. 1-2, communication control unit 134 includes a generic external communicator 294, no explicit mention of using a transceiver}, the CCU {134, Figs. 1-2} wakes up all ECUs that are physically connected in the B+ power state of the vehicle {ECUs 116 in Fig. 1 are powered by battery 114 under the control of power control unit 132}, and then controls selective sleep to transmit an NM state message to only ECUs required for the requested function to maintain a non-sleep state {The description in Col. 8, Lns. 34-60, includes allowing each ECU 116 in Fig. 1 to be selectively activated/awake, and includes activating additional ECU(s) to enable the primary ECU, or ECUs, to function properly}.
The combination of Kim and Sinha does not appear to explicitly recite the limitation: wherein of a network configuring unit includes a PN transceiver.
However, Nickel explicitly recites the limitation: wherein of a network configuring unit includes a PN transceiver {transceiver 13, Fig. 1 and ¶[0030-0032], with the power saving aspect described in ¶[0062]}.
Regarding Claim 10, Kim discloses the limitations: a network management method of an electric vehicle in which a partial network is applied to a network configuring unit {Figs. 1-2}, comprising: checking, by a central communication unit {communication control unit 134, Figs. 1-2}, whether to receive an update event {“The vehicle 100 receives a request for determining whether OTA is possible from the OTA server 170 located at a remote position (602). The request for determining whether the OTA software update is possible is a request generated by the OTA server 170 and transmitted to the vehicle 100 according to various exemplary embodiments of the present invention before performing the OTA software update in the case where software or firmware of at least one ECU 116 provided in the vehicle 100 needs to be updated. The vehicle 100 determines whether the OTA software update is possible in response to the request for determining whether the OTA software update is possible”, Col. 9, Lns. 18-29} from a server {OTA server 170, power information server 180, Fig. 1} configured to manage a partial network cluster database (PNC-DB) of various vehicles {vehicle-specific power information 332 and vehicle-specific power information 334, Fig. 3, and “The vehicle-specific ECU power/communication specification information 334 may include vehicle charge target setting information, ECU communication/power information, and communication channel-specific connected ECU information of vehicles. Such information used in the power information server 180 will be described in detail with reference to FIG. 4 and FIG. 5 below.”, Col. 5, Lns. 33-40, note, especially, the selective ECU function in Fig. 5}; notifying, by the central communication unit {134, Figs. 1-2}, that a changed PNC-DB is updated through a vehicle terminal (AVN) or a mobile application when the update event is received {“OTA warning is output and information on the power status of the vehicle 100 is displayed to allow the driver to recognize the power status of the vehicle 100 related to the OTA software update (622)”, Col. 11, Lns. 41-44 and Fig. 6}; updating, by the central communication unit, an existing PNC-DB table by downloading the changed PNC-DB through over-the-air (OTA) of the server when a user approves the update of the PNC-DB {“performing over-the-air (OTA) software updates”, Abstract, and “driver is provided with the option to initiate software update immediately or at a later time: “when the driver selects forced execution of the OTA software update in a state where an amount of electric power for completing the OTA software update is satisfied (‘No’ of 612), the power control unit 132 may allow the OTA software update of the vehicle 100 (626)”, Col. 11, Lns. 56-61}; and selectively waking up, by the central communication unit, an electronic control unit (ECU) by identifying the ECU of a network configuring unit required to execute a specific function based on the updated PNC-DB table {“Each of the at least one ECU 116 includes a communicator 252, a power unit 254, and an electrical load controller 256. The communicator 252 is provided to communicate with the other devices of the vehicle 100. For example, the communicator 252 may receive an electrical load control signal from the power control unit 132. The power unit 254 receives an electric power from the battery 114 and detects a voltage of the received electric power. The electrical load controller 256 controls an output of an electrical load 258. The electrical load 258 may include any devices that consume the electric power among the devices included in the vehicle 100 according to various exemplary embodiments of the present invention.”, Col. 5, Lns. 52-64} when the network configuring unit enters a fuel saving control mode for every PN scenario set in the PNC-DB table {with respect to Figs. 1&5: “The communication channel-specific connected ECU information 506 refers to information indicating communication channels connected to the ECUs 116, respectively, and include information on whether each ECU 116 has a selective wake-up (or partial wake-up) function. In the case where when a particular ECU 116 is activated, only ECUs 116 related to the activated ECU 116 are activated, the activated ECUs 116 have the selective wake-up function. On the other hand, in the case where when a particular ECU 116 is activated, the other ECUs 116 even unrelated to the activated ECU 116 are also activated, the activated ECUs 116 do not have the selective wake-up function. The communication channel-specific connected ECU information 506 is used to confirm whether a particular ECU 116 operates alone or whether a particular ECU 116 needs to operate under a cooperative control with other ECUs 116. This is because power consumption of each ECU 116 needs to be accurately determined…when a cooperative control for other ECUs 116 is required during operation of the particular ECU 116, there is a need to consider power consumptions of the other ECUs 116 operating together as well as a power consumption of the particular ECU 116.”, Col. 8, Lns. 34-60}; and wherein the central communication unit stores a PNC DB table {“ As a preparation process for determining the possibility of the OTA software update, the power control unit 132 of the vehicle 100 receives a list of target ECUs 116 of software/firmware updates”, Col.9, Lns. 30-33}, wherein at least one ECU required to execute a function in the vehicle {function associated with ECU5 in Fig. 5}, among ECUs of the network configuring unit, is mapped to a group and maintains a latest version by updating the changed PNC-DB {the tabulated data in Fig. 5 – i.e., 504 and 506 – is stored in communication control unit 134, Fig. 1, after being downloaded from power information server 180, Fig. 3; also, Fig. 6 reflects over-the-air updating of ECUs}.
Kim does not appear to explicitly recite the limitations: a partial network transceiver is applied to the network configuring unit; comprising real-time changes in the electronic control unit mapping.
However, Sinha explicitly recites the limitations: a changed PNC-DB comprising real-time changes in the electronic control unit mapping is updated through a vehicle terminal (AVN) or a mobile application when the update event is received {reconfiguring ECU mapping: “ FIG. 4 illustrates an exemplary pre-determined mapping strategy that facilitates selection of the on-board reconfiguration strategy 420 by the on-board reconfiguration application 232.”, Col. 7, Lns. 26-29}.
The combination of Kim and Sinha does not appear to explicitly recite the limitation: a partial network transceiver.
However, Nickel explicitly recites the limitation: a partial network transceiver {“FIG. 1 shows a bus system 1 in which messages or signals may be transmitted via the CAN protocol… Subscriber stations 10, 20, 30 may be, for example, control units …subscriber stations 10, 30 each include a communication control device 11, an adaptation device 12, and a transceiver 13. In contrast, subscriber station 20 includes a communication control device 14 and a transceiver 13. Transceivers 13 of subscriber stations 10, 20, 30 are each directly connected to bus line 40, even though this is not illustrated in FIG. 1”, ¶[0030-0032]}.
Regarding Claim 11, the combination of Kim, Sinha and Nickel discloses all the limitations of Claim 10, as discussed supra. In addition, Kim explicitly recites the limitation: wherein the notifying that the changed PNC-DB is updated includes inquiring the user whether to update a PNC-DB for fuel control of the vehicle by means of pop-up {“driver is provided with the option to initiate software update immediately or at a later time: “when the driver selects forced execution of the OTA software update in a state where an amount of electric power for completing the OTA software update is satisfied (‘No’ of 612), the power control unit 132 may allow the OTA software update of the vehicle 100 (626)”, Col. 11, Lns. 56-61 and Fig. 6}.
Regarding Claim 12, the combination of Kim, Sinha and Nickel discloses all the limitations of Claim 10, as discussed supra. In addition, Kim explicitly recites the limitation: wherein the updating of an existing PNC-DB table includes adding a new PNC-DB group to the existing PNC-DB table {506, Fig. 2}, or changing ECU mapping information of the existing PNC-DB group based on the changed PNC-DB {“performing the OTA software update of the vehicle upon determining that the supply of the electric power higher than the value required to perform the OTA software update of the vehicle is possible”, Col. 9, Lns. 13-17}.
Regarding Claim 13, the combination of Kim, Sinha and Nickel discloses all the limitations of Claim 10, as discussed supra. In addition, Kim explicitly recites the limitations: wherein the selectively waking up includes: identifying a PNC group specified to perform a requested specific scenario when an NM request message is received {average battery consumption during parking, Fig. 4}; and transmitting the NM request message to only at least one ECU corresponding to the specified PNC group to individually activate the ECU {The description in Col. 8, Lns. 34-60, includes allowing each ECU 116 in Fig. 1 to be selectively activated/awake, and includes activating additional ECU(s) to enable the primary ECU, or ECUs, to function properly}.
The combination of Kim and Sinha does not appear to explicitly recite the limitation: wherein the PN transceiver receives an NM request message.
However, Nickel explicitly recites the limitation: wherein the PN transceiver {13, Fig. 1} receives an NM request message {¶[0030-0032]; also ¶[0062]}.
Regarding Claim 14, the combination of Kim, Sinha and Nickel discloses all the limitations of Claim 13, as discussed supra. In addition, Kim explicitly recites the limitations: wherein the network-management-state message includes a network bus {CAN in Fig. 2 represents the use of a standard Control Area Network bus, and the associated data transfer protocols} and a destination ID corresponding to an individual ECU on which selective sleep control is performed {selective/partial wake-up functionality described in Col. 8, Lns. 34-60, with respect to Figs. 1&5, where selective sleep of ECUs is evident in channel-specific ECU information table 506 in Fig. 5}.
Regarding Claim 15, Kim discloses the limitations: a network management method {Figs. 1-2} of an electric vehicle {100, Fig. 1} in which a partial network (PN) is not applied to a network configuring unit {with regard to Figs. 1-2, communication control unit 134 includes a generic external communicator 294, no explicit mention of using a transceiver}, comprising: checking, by a central communication unit {communication control unit 134, Figs. 1-2}, whether to receive an update event {“The vehicle 100 receives a request for determining whether OTA is possible from the OTA server 170 located at a remote position (602). The request for determining whether the OTA software update is possible is a request generated by the OTA server 170 and transmitted to the vehicle 100 according to various exemplary embodiments of the present invention before performing the OTA software update in the case where software or firmware of at least one ECU 116 provided in the vehicle 100 needs to be updated. The vehicle 100 determines whether the OTA software update is possible in response to the request for determining whether the OTA software update is possible”, Col. 9, Lns. 18-29} from a server {OTA server 170, power information server 180, Fig. 1} which manages a partial network cluster database (PNC-DB) of various vehicles {vehicle-specific power information 332 and vehicle-specific power information 334, Fig. 3, and “The vehicle-specific ECU power/communication specification information 334 may include vehicle charge target setting information, ECU communication/power information, and communication channel-specific connected ECU information of vehicles. Such information used in the power information server 180 will be described in detail with reference to FIG. 4 and FIG. 5 below.”, Col. 5, Lns. 33-40, note, especially, the selective ECU function in Fig. 5}; notifying, by the central communication unit {134, Figs. 1-2}, that a changed PNC-DB is updated through a vehicle terminal (AVN) or a mobile application when the update event is received {“OTA warning is output and information on the power status of the vehicle 100 is displayed to allow the driver to recognize the power status of the vehicle 100 related to the OTA software update (622)”, Col. 11, Lns. 41-44 and Fig. 6}; updating, by the central communication unit, an existing PNC-DB table by downloading the changed PNC-DB through over-the-air (OTA) of the server when a user approves the update of the PNC-DB {“performing over-the-air (OTA) software updates”, Abstract, and “driver is provided with the option to initiate software update immediately or at a later time: “when the driver selects forced execution of the OTA software update in a state where an amount of electric power for completing the OTA software update is satisfied (‘No’ of 612), the power control unit 132 may allow the OTA software update of the vehicle 100 (626)”, Col. 11, Lns. 56-61}; and controlling, by the central communication unit, selective sleep to transmit an NM state message to only at least one ECU required to execute a specific function based on the updated PNC-DB table to maintain a non-sleep state after waking up all ECUs physically connected {“Each of the at least one ECU 116 includes a communicator 252, a power unit 254, and an electrical load controller 256. The communicator 252 is provided to communicate with the other devices of the vehicle 100. For example, the communicator 252 may receive an electrical load control signal from the power control unit 132. The power unit 254 receives an electric power from the battery 114 and detects a voltage of the received electric power. The electrical load controller 256 controls an output of an electrical load 258. The electrical load 258 may include any devices that consume the electric power among the devices included in the vehicle 100 according to various exemplary embodiments of the present invention.”, Col. 5, Lns. 52-64} when the central communication unit enters a fuel saving control mode for every PN scenario set in the PNC-DB table {with respect to Figs. 1&5: “The communication channel-specific connected ECU information 506 refers to information indicating communication channels connected to the ECUs 116, respectively, and include information on whether each ECU 116 has a selective wake-up (or partial wake-up) function. In the case where when a particular ECU 116 is activated, only ECUs 116 related to the activated ECU 116 are activated, the activated ECUs 116 have the selective wake-up function. On the other hand, in the case where when a particular ECU 116 is activated, the other ECUs 116 even unrelated to the activated ECU 116 are also activated, the activated ECUs 116 do not have the selective wake-up function. The communication channel-specific connected ECU information 506 is used to confirm whether a particular ECU 116 operates alone or whether a particular ECU 116 needs to operate under a cooperative control with other ECUs 116. This is because power consumption of each ECU 116 needs to be accurately determined…when a cooperative control for other ECUs 116 is required during operation of the particular ECU 116, there is a need to consider power consumptions of the other ECUs 116 operating together as well as a power consumption of the particular ECU 116.”, Col. 8, Lns. 34-60} in a B+ power state of the vehicle {ECUs 116 in Fig. 1 are powered by battery 114 under the control of power control unit 132}; and wherein the central communication unit stores a PNC DB table {“As a preparation process for determining the possibility of the OTA software update, the power control unit 132 of the vehicle 100 receives a list of target ECUs 116 of software/firmware updates”, Col.9, Lns. 30-33}, wherein at least one ECU required to execute a function in the vehicle {function associated with ECU5 in Fig. 5}, among ECUs of the network configuring unit, is mapped to a group and maintains a latest version by updating the changed PNC-DB {the tabulated data in Fig. 5 – i.e., 504 and 506 – is stored in communication control unit 134, Fig. 1, after being downloaded from power information server 180, Fig. 3; also, Fig. 6 reflects over-the-air updating of ECUs}.
Kim does not appear to explicitly recite the limitations: a partial network transceiver; and real-time changes in the electronic control unit mapping.
However, Sinha explicitly recites the limitations: real-time changes in the electronic control unit mapping {reconfiguring ECU mapping: “FIG. 4 illustrates an exemplary pre-determined mapping strategy that facilitates selection of the on-board reconfiguration strategy 420 by the on-board reconfiguration application 232.”, Col. 7, Lns. 26-29}.
The combination of Kim and Sinha does not appear to explicitly recite the limitation: a partial network transceiver.
However, Nickel explicitly recites the limitation: a partial network transceiver {“FIG. 1 shows a bus system 1 in which messages or signals may be transmitted via the CAN protocol…Subscriber stations 10, 20, 30 may be, for example, control units…subscriber stations 10, 30 each include a communication control device 11, an adaptation device 12, and a transceiver 13. In contrast, subscriber station 20 includes a communication control device 14 and a transceiver 13. Transceivers 13 of subscriber stations 10, 20, 30 are each directly connected to bus line 40, even though this is not illustrated in FIG. 1”, ¶[0030-0032]}.
Regarding Claim 16, the combination of Kim, Sinha and Nickel discloses all the limitations of Claim 15, as discussed supra. In addition, Kim explicitly recites the limitations: wherein the network-management-state message includes a network bus {CAN in Fig. 2 represents the use of a standard Control Area Network bus, and the associated data transfer protocols} and a destination ID corresponding to an individual ECU on which selective sleep control is performed {selective/partial wake-up functionality described in Col. 8, Lns. 34-60, with respect to Figs. 1&5, where selective sleep of ECUs is evident in channel-specific ECU information table 506 in Fig. 5}.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
KR 101602225 B1 – Reprogramming a vehicle control system that includes a plurality of ECUs, each with an associated transceiver. {“…when errors are found in the ECU map data embedded in the vehicle, It may be necessary to update the ECU map data in order to solve problems that occur later in the ECU map data. In this case, on the basis of the characteristics of the ECU map data including the highly complex and intertwined control variable data, the new ECU map data is designed without modifying the control variable data to become a character, This is called reprogramming, as the update process replaces the data.”, Pg. 1, Ln. 27 through Pg. 2, Ln. 4}.
Roh, H.K., Kim, S.H. and Shin, Y.Y., 2022, October. Efficient initial wake-up methods when using Partial Networking In-Vehicle network. In 2022 27th Asia Pacific Conference on Communications (APCC) (pp. 590-594). IEEE. [Using the Partial Networking approach to reduce energy usage in a vehicle by deactivating any ECUs not needed for current vehicle operation.]
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 RICHARD EDWIN GEIST whose telephone number is (703)756-5854. The examiner can normally be reached Monday-Friday, 9am-6pm.
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, Christian Chace can be reached at (571) 272-4190. 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.
/R.E.G./Examiner, Art Unit 3665
/CHRISTIAN CHACE/Supervisory Patent Examiner, Art Unit 3665