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 .
This Office Action is in response to Applicant's Amendment and Remarks filed on 4/8/2026. This Action is made FINAL.
Claim 17 was canceled.
Claims 1-16, 18-20 are pending for examination.
Response to Arguments
(A) Applicant’s arguments, see pages 6-8, filed “claim 1 is amended to recite features based on the embodiment of Figure 6 of Applicant's specification: In Figure 6, an energy management unit 132 receives both battery data 610 from the BMS 141 and driving data 620 from an autonomous driving controller 131, then processes the battery data and driving data together to generate energy management data 625, and then provides the energy management data 630 to the autonomous driving controller and/or provides the energy management data 640 to the BMS. Notably, the energy management unit 132 in Figure 6 is shown as being separate from the BMS 141. This can be seen even more clearly in Figure 2 of the application, in which the BMS 141 is included in a battery 140, while the autonomous driving controller 131 and the energy management unit 132 are included in a computing system 130 that is separate from the battery 140. This is because "as the diversification of energy management functions increases and more advanced energy management calculations are required, the processing capacity of the BMS may reach a limit." (Applicant's specification, paragraph [0003].) Thus, to overcome this processing limitation, the specification teaches that a "computing system 130 having a relatively high computational processing capability compared to a management module (e.g., a BMS 141 in FIG. 2) of the battery 140 may perform the energy management function" and that "energy management of the vehicle 100 may be performed more stably and smoothly." (Applicant's specification, paragraph [0052].)” on 4/8/2026, with respect to the rejection(s) of claim(s) 1-4 and 14-15 under 35 U.S.C. § 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn.
As to point (A), upon further consideration, a new ground(s) of rejection is made in view of DIVEKAR (US20220185115A1).
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-4, 6-8, 13-16 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by DIVEKAR (US20220185115A1)
Regarding claim 1, DIVEKAR teaches A computing system comprising:
at least one processor operatively coupled to a battery management system (BMS) for managing a battery of a vehicle, wherein the at least one processor is separate from the BMS(DIVEKAR: Para 79 “the main compute 1235 may correspond to main compute 1135 of FIG. 11 and implement primary autonomy arrangement 1136 of FIG. 11 to control the autonomous vehicle in an autonomous or semi-autonomous manner. And although illustrated in FIG. 12 as part of the high voltage power domain 1230, the main compute 1235 may instead be part of a low voltage power domain (e.g., a third low voltage power domain (not shown) separate from the first and second low voltage domains 1210 a and 1210 b). In certain embodiments, parts or components of the high voltage power domain 1235 may be powered, either entirely or partially, by low voltage power supplied by one or more of the low voltage power domains 1210 a and/or 1210 b. For instance, a battery management system (BMS, not shown) that manages the charging and discharging of the high voltage power source 1231 may be powered by the first low voltage power domain 1210 a and/or the second low voltage power domain 1210 b”) and is configured to:
control autonomous driving of the vehicle(DIVEKAR: Para 34 “Processor 304 is arranged to send instructions to and to receive instructions from or for various components such as propulsion system 308, navigation system 312, sensor system 324, power system 332, and control system 336. Propulsion system 308, or a conveyance system, is arranged to cause autonomous vehicle 101 to move, e.g., drive. For example, when autonomous vehicle 101 is configured with a multi-wheeled automotive configuration as well as steering, braking systems and an engine, propulsion system 308 may be arranged to cause the engine, wheels, steering, and braking systems to cooperate to drive. In general, propulsion system 308 may be configured as a drive system with a propulsion engine, wheels, treads, wings, rotors, blowers, rockets, propellers, brakes, etc. The propulsion engine may be a gas engine, a turbine engine, an electric motor, and/or a hybrid gas and electric engine”; Para 39 “control system 336 may cooperate with processor 304 to determine where autonomous vehicle 101 may safely travel, and to determine the presence of objects in a vicinity around autonomous vehicle 101 based on data, e.g., results, from sensor system 324. In other words, control system 336 may cooperate with processor 304 to effectively determine what autonomous vehicle 101 may do within its immediate surroundings. Control system 336 in cooperation with processor 304 may essentially control power system 332 and navigation system 312 as part of driving or conveying autonomous vehicle 101”);
acquire driving data from at least one sensor included in vehicle(DIVEKAR: Para 35 “Navigation system 312 may control propulsion system 308 to navigate autonomous vehicle 101 through paths and/or within unstructured open or closed environments. Navigation system 312 may include at least one of digital maps, street view photographs, and a global positioning system (GPS) point. Maps, for example, may be utilized in cooperation with sensors included in sensor system 324 to allow navigation system 312 to cause autonomous vehicle 101 to navigate through an environment”; Para 39 “control system 336 may cooperate with processor 304 to determine where autonomous vehicle 101 may safely travel, and to determine the presence of objects in a vicinity around autonomous vehicle 101 based on data, e.g., results, from sensor system 324. In other words, control system 336 may cooperate with processor 304 to effectively determine what autonomous vehicle 101 may do within its immediate surroundings. Control system 336 in cooperation with processor 304 may essentially control power system 332 and navigation system 312 as part of driving or conveying autonomous vehicle 101”);
acquire battery data from the BMS(DIVEKAR: Para 56 “a determination is made as to whether the onboard power source is providing sufficient power. That is, it is determined whether the onboard power source is providing enough low voltage power to effectively power systems that the LVPDU is expected to power. If the determination is that the onboard power source provides sufficient power, the LVPDU continues to provide power using the onboard power source in step 809”; Para 57 “Alternatively, if it is determined in step 813 that the onboard power source is not providing sufficient power, the implication is that there may be a performance issue with the onboard power source. By way of example, the onboard power source may effectively be non-functional. Accordingly, process flow moves from step 813 to a step 817 in which the LVPDU switches from providing power using the onboard power source to providing power using a battery arrangement, or a plurality of backup batteries”);
generate energy management data based on a combination of the acquired battery data and the acquired driving data(DIVEKAR: Para 37 “Power system 332 is arranged to provide power to autonomous vehicle 101. Power may be provided as electrical power, gas power, or any other suitable power, e.g., solar power or battery power. In one embodiment, power system 332 may include a main power source, and an auxiliary power source that may serve to power various components of autonomous vehicle 101 and/or to generally provide power to autonomous vehicle 101 when the main power source does not have the capacity to provide sufficient power. It should be appreciated that power system 332 may generally include an LVPDU and/or sources which may provide power to the LVPDU, e.g., to a power source onboard the LVPD”; Para 39 “control system 336 may cooperate with processor 304 to determine where autonomous vehicle 101 may safely travel, and to determine the presence of objects in a vicinity around autonomous vehicle 101 based on data, e.g., results, from sensor system 324. In other words, control system 336 may cooperate with processor 304 to effectively determine what autonomous vehicle 101 may do within its immediate surroundings. Control system 336 in cooperation with processor 304 may essentially control power system 332 and navigation system 312 as part of driving or conveying autonomous vehicle 101”; Para 39 “control system 336 may cooperate at least with processor 304, propulsion system 308, navigation system 312, sensor system 324, and power system 332 to allow vehicle 101 to operate autonomously. That is, autonomous vehicle 101 is able to operate autonomously through the use of an autonomy system that effectively includes, at least in part, functionality provided by propulsion system 308, navigation system 312, sensor system 324, power system 332, and control system 336”; Para 56 “a determination is made as to whether the onboard power source is providing sufficient power. That is, it is determined whether the onboard power source is providing enough low voltage power to effectively power systems that the LVPDU is expected to power. If the determination is that the onboard power source provides sufficient power, the LVPDU continues to provide power using the onboard power source in step 809”; Para 57 “Alternatively, if it is determined in step 813 that the onboard power source is not providing sufficient power, the implication is that there may be a performance issue with the onboard power source. By way of example, the onboard power source may effectively be non-functional. Accordingly, process flow moves from step 813 to a step 817 in which the LVPDU switches from providing power using the onboard power source to providing power using a battery arrangement, or a plurality of backup batteries” i.e. operation of a battery arrangement, or a plurality of backup batteries (energy management data) based on the ability to providing sufficient power (acquired battery data) for driving or conveying autonomous vehicle (acquired driving data)); and
at least one of:
provide at least a portion of the generated energy management data to the BMS(DIVEKAR: Para 92 “the ECU 1314 a of the first LVPDU 1310 a may be configured to monitor various operating conditions within the high voltage power domain, the first low voltage power domain, and/or the second low voltage power domain to control the input power switch 1311 a of the first LVPDU 1310 a. Similarly, the ECU 1314 b of the second LVPDU 1310 b may control the input power switch 1311 b of the second LVPDU 1310 b. In the example illustrated in FIG. 13, the first ECU 1314 a may generate one or more of: (i) control signal IPS1-DISC-1 to disconnect the input power switch 1311 a of the first LVPDU 1310 a from the DC-DC converter 1345, and (ii) control signal IPS2_DISC-1 to disconnect the input power switch 1311 b of the second LVDPU 1310 b from the DC-DC converter 1345”; Para 93 “the first and second ECU's 1314 a and 1314 b may establish a communication link 1313 to exchange sensor data and status information. The communication link may be implemented as, for example, an I2C bus, a controller area network (CAN) bus, and the like. In addition, requests to control input power switches 1311 a and 1311 b (or any other aspects of the LVPDU) may be transmitted over the communication link 1313”); or
control the autonomous driving of the vehicle based on at least a portion of the generated energy management data(DIVEKAR: Para 56 “a determination is made as to whether the onboard power source is providing sufficient power. That is, it is determined whether the onboard power source is providing enough low voltage power to effectively power systems that the LVPDU is expected to power. If the determination is that the onboard power source provides sufficient power, the LVPDU continues to provide power using the onboard power source in step 809”; Para 57 “Alternatively, if it is determined in step 813 that the onboard power source is not providing sufficient power, the implication is that there may be a performance issue with the onboard power source. By way of example, the onboard power source may effectively be non-functional. Accordingly, process flow moves from step 813 to a step 817 in which the LVPDU switches from providing power using the onboard power source to providing power using a battery arrangement, or a plurality of backup batteries”; Para 63 “The ability for backup batteries of an LVPDU to essentially take over providing power in the event that a primary power source of the LVPDU is no longer providing power, or is providing insufficient power, is crucial to ensure that a vehicle which includes the LVPDU may continue to operate safely. As such, periodically testing the backup batteries to effectively ensure that the backup batteries are functional increases the likelihood that a vehicle may continue to operate safely in the event that the primary power source ceases to operate as expected. That is, batteries may be tested, e.g., cold tested, to determine if the batteries are in working condition”; i.e. The ability for backup batteries of an LVPDU to essentially take over providing power (based on at least a portion of the generated energy management data) ensure that a vehicle which includes the LVPDU may continue to operate safely(control the autonomous driving of the vehicle)).
Regarding claim 2, DIVEKAR teaches wherein the energy management data includes at least one of battery state diagnosis data, battery lifetime prediction data, battery operation control data, battery charging/discharging control data, or vehicle control data (DIVEKAR: Para 56 “a determination is made as to whether the onboard power source is providing sufficient power. That is, it is determined whether the onboard power source is providing enough low voltage power to effectively power systems that the LVPDU is expected to power. If the determination is that the onboard power source provides sufficient power, the LVPDU continues to provide power using the onboard power source in step 809”; Para 57 “Alternatively, if it is determined in step 813 that the onboard power source is not providing sufficient power, the implication is that there may be a performance issue with the onboard power source. By way of example, the onboard power source may effectively be non-functional. Accordingly, process flow moves from step 813 to a step 817 in which the LVPDU switches from providing power using the onboard power source to providing power using a battery arrangement, or a plurality of backup batteries”)
Regarding claim 3, DIVEKAR teaches The computing system of claim 1, wherein the one or more energy management services includes at least one of a service for providing a diagnosis result obtained by diagnosing state of the battery of the vehicle, or a service for providing a life analysis result of the battery of the vehicle(DIVEKAR: Para 101 “the ECU 1414 a may monitor various information relating, for example, the output the DC-DC converter, the health of the first low voltage power domain, the health of the second low voltage power domain, the health of the high voltage battery, etc. For example, ECU 1414 a may generate control signal IPS1_DISC-1 to disconnect the input power switch 1411 a of the first LVPDU 1410 a and/or control signal IPS2_DISC-1 to disconnect the input power switch 1411 b of the second LVPDU 1410 b based at least in part on one or more of: output current of the DC-DC converter (DC-DC_Current), output voltage of the DC-DC converter (DC-DC Voltage), a temperature of the DC-DC converter (DC-DC_Temp), a status of the high voltage battery HV_Battery_Status, a status of the high voltage power domain (HV_PD_Status), a status of the first low voltage power domain (LV_PD_1_Status), a status of the first low voltage backup battery (LV_Battery_1_Status), a status of the second low voltage power domain (LV_PD_2_Status), a status of the second low voltage backup battery (LV_Battery_2_Status), and the like”; Para 104 “the output of one or more DC-DC converters (e.g., DC-DC converter 1245 of FIG. 12 or DC-DC converter 1345 of FIG. 13) and/or the health of various components of the high voltage power domain may be monitored to identify a fault condition”).
Regarding claim 4, DIVEKAR teaches The computing system of claim 1, wherein the at least one processor is configured to execute the first program to: provide the at least a portion of the generated energy management data to the BMS(DIVEKAR: Para 92 “the ECU 1314 a of the first LVPDU 1310 a may be configured to monitor various operating conditions within the high voltage power domain, the first low voltage power domain, and/or the second low voltage power domain to control the input power switch 1311 a of the first LVPDU 1310 a. Similarly, the ECU 1314 b of the second LVPDU 1310 b may control the input power switch 1311 b of the second LVPDU 1310 b. In the example illustrated in FIG. 13, the first ECU 1314 a may generate one or more of: (i) control signal IPS1-DISC-1 to disconnect the input power switch 1311 a of the first LVPDU 1310 a from the DC-DC converter 1345, and (ii) control signal IPS2_DISC-1 to disconnect the input power switch 1311 b of the second LVDPU 1310 b from the DC-DC converter 1345”; Para 93 “the first and second ECU's 1314 a and 1314 b may establish a communication link 1313 to exchange sensor data and status information. The communication link may be implemented as, for example, an I2C bus, a controller area network (CAN) bus, and the like. In addition, requests to control input power switches 1311 a and 1311 b (or any other aspects of the LVPDU) may be transmitted over the communication link 1313”).
Regarding claim 6, DIVEKAR teaches The computing system of claim 1, wherein the at least one processor is further configured to: control the autonomous driving of the vehicle based on the acquired driving data and the at least a portion of the generated energy management data(DIVEKAR: Para 56 “a determination is made as to whether the onboard power source is providing sufficient power. That is, it is determined whether the onboard power source is providing enough low voltage power to effectively power systems that the LVPDU is expected to power. If the determination is that the onboard power source provides sufficient power, the LVPDU continues to provide power using the onboard power source in step 809”; Para 57 “Alternatively, if it is determined in step 813 that the onboard power source is not providing sufficient power, the implication is that there may be a performance issue with the onboard power source. By way of example, the onboard power source may effectively be non-functional. Accordingly, process flow moves from step 813 to a step 817 in which the LVPDU switches from providing power using the onboard power source to providing power using a battery arrangement, or a plurality of backup batteries”; Para 63 “The ability for backup batteries of an LVPDU to essentially take over providing power in the event that a primary power source of the LVPDU is no longer providing power, or is providing insufficient power, is crucial to ensure that a vehicle which includes the LVPDU may continue to operate safely. As such, periodically testing the backup batteries to effectively ensure that the backup batteries are functional increases the likelihood that a vehicle may continue to operate safely in the event that the primary power source ceases to operate as expected. That is, batteries may be tested, e.g., cold tested, to determine if the batteries are in working condition”; i.e. The ability for backup batteries of an LVPDU to essentially take over providing power (based on at least a portion of the generated energy management data) ensure that a vehicle which includes the LVPDU may continue to operate safely(control the autonomous driving of the vehicle)).
Regarding claim 7, DIVEKAR teaches The computing system of claim 6, wherein the driving data includes at least one of:
object data indicating a surrounding environment of the vehicle(DIVEKAR: Para 39 “control system 336 may cooperate with processor 304 to determine where autonomous vehicle 101 may safely travel, and to determine the presence of objects in a vicinity around autonomous vehicle 101 based on data, e.g., results, from sensor system 324. In other words, control system 336 may cooperate with processor 304 to effectively determine what autonomous vehicle 101 may do within its immediate surroundings. Control system 336 in cooperation with processor 304 may essentially control power system 332 and navigation system 312 as part of driving or conveying autonomous vehicle 101”); and
behavior data indicating a motion of the vehicle.
Regarding claim 8, DIVEKAR teaches The computing system of claim 6, wherein the at least one processor is configured to:
generate component control data for controlling transmission of the driving data from the at least one sensor of the vehicle based on the acquired battery data (DIVEKAR: Para 86 “the SDA 1240 may be powered by both the first LVPDU 1211 a and the second LVPDU 1211 b. In other words, the SDA 1240 may span both the first low voltage power domain 1210 a and the second low voltage power domain 1210 b. The first computing of the SDA 1240 may be powered by the first LVDU 1211 a and the second computing assembly of the SDA 1240 may be powered by the second LVDU 1211 b. The first computing assembly may process the sensor data generated by the sensors 1212 a to 1219 a. And the second computing assembly may process the sensor data generated by sensors 1212 b to 1218 b. In this manner, even if one of the low voltage power domains fails, sensor data from the still-functioning sensors may be processed and used to implement one or more of: primary autonomy functionalities, parallel autonomy functionalities, failover autonomy functionalities, and/or teleoperations functionalities”; Para 110 “if the second fault condition (e.g., a fault condition within one of the low voltage power domains) is detected, one of the LVPDUs may be disconnected from the one or more DC-DC converters at step 1507. For example, if a fault is detected within the first low voltage power domain, the first LVPDU may be disconnected to isolate the fault and prevent the fault from affecting components within the high voltage power domain or the second low voltage power domain. Similarly, if a fault is detected within the second low voltage power domain, the second LVPDU may be disconnected from the one or more DC-DC converters. In response to detecting the second fault condition, the faulted low voltage power domain may also be disconnected from its low voltage backup battery to prevent, for example, a short circuit condition in the faulted low voltage power domain from draining the low voltage backup battery or causing dangerous temperature conditions”; Para 113 “the vehicle may comprise two sets of sensors, a first set of sensors powered by the first low voltage power domain and a second set of sensors powered by the second low voltage power domain. Under normal operations (e.g., step 1501), the vehicle may operate in an autonomous or semi-autonomous manner using data generated by both the first set of sensors and the second set of sensors. At step 1509, if the detected second fault condition corresponds to a fault of within the first low voltage power domain, the vehicle may be configured to operate (e.g., to perform an autonomous safe stop) while the first set of sensors are inoperable or non-functional due to the detected second fault condition. Similarly, if the detected second fault condition corresponds to a fault of within the second low voltage power domain, the vehicle may be configured to operate (e.g., to perform an autonomous safe stop) while the second set of sensors are inoperable or non-functional due to the detected second fault condition”); and
transmit the generated component control data to the at least one sensor of the vehicle(DIVEKAR: Para 110 “if the second fault condition (e.g., a fault condition within one of the low voltage power domains) is detected, one of the LVPDUs may be disconnected from the one or more DC-DC converters at step 1507. For example, if a fault is detected within the first low voltage power domain, the first LVPDU may be disconnected to isolate the fault and prevent the fault from affecting components within the high voltage power domain or the second low voltage power domain. Similarly, if a fault is detected within the second low voltage power domain, the second LVPDU may be disconnected from the one or more DC-DC converters. In response to detecting the second fault condition, the faulted low voltage power domain may also be disconnected from its low voltage backup battery to prevent, for example, a short circuit condition in the faulted low voltage power domain from draining the low voltage backup battery or causing dangerous temperature conditions”; Para 113 “the vehicle may comprise two sets of sensors, a first set of sensors powered by the first low voltage power domain and a second set of sensors powered by the second low voltage power domain. Under normal operations (e.g., step 1501), the vehicle may operate in an autonomous or semi-autonomous manner using data generated by both the first set of sensors and the second set of sensors. At step 1509, if the detected second fault condition corresponds to a fault of within the first low voltage power domain, the vehicle may be configured to operate (e.g., to perform an autonomous safe stop) while the first set of sensors are inoperable or non-functional due to the detected second fault condition. Similarly, if the detected second fault condition corresponds to a fault of within the second low voltage power domain, the vehicle may be configured to operate (e.g., to perform an autonomous safe stop) while the second set of sensors are inoperable or non-functional due to the detected second fault condition”).
Regarding claim 13, DIVEKAR teaches The computing system of claim 1, wherein the BMS is included in the battery of the vehicle(DIVEKAR: Para 79 “a battery management system (BMS, not shown) that manages the charging and discharging of the high voltage power source 1231 may be powered by the first low voltage power domain 1210 a and/or the second low voltage power domain 1210 b”).
Regarding claim 14, DIVEKAR teaches The computing system of claim 1, wherein the at least one processor is included in the vehicle(DIVEKAR: Para 33 “An autonomous vehicle 101 includes a processor 304, a propulsion system 308, a navigation system 312, a sensor system 324, a power system 332, a control system 336, and a communications system 340. It should be appreciated that processor 304, propulsion system 308, navigation system 312, sensor system 324, power system 332, and communications system 340 are all coupled to a chassis or body of autonomous vehicle 101”)
Regarding claim 15, DIVEKAR teaches The computing system of claim 14, wherein the at least one processor is included in a system-on-a-chip that is configured to both control autonomous driving of the vehicle and generate the energy management data (DIVEKAR: Para 39 “control system 336 may cooperate with processor 304 to determine where autonomous vehicle 101 may safely travel, and to determine the presence of objects in a vicinity around autonomous vehicle 101 based on data, e.g., results, from sensor system 324. In other words, control system 336 may cooperate with processor 304 to effectively determine what autonomous vehicle 101 may do within its immediate surroundings. Control system 336 in cooperation with processor 304 may essentially control power system 332 and navigation system 312 as part of driving or conveying autonomous vehicle 101”; Para 77 “the parallel autonomy arrangement 1113 and/or the failover autonomy arrangement 1114 may be implemented by four general-purpose processors or systems on a chip (SoCs)”).
Regarding claim 16, DIVEKAR teaches A vehicle comprising: a battery including a battery management system (BMS); and the computing system of claim 1(DIVEKAR: Para 79 “a battery management system (BMS, not shown) that manages the charging and discharging of the high voltage power source 1231 may be powered by the first low voltage power domain 1210 a and/or the second low voltage power domain 1210 b”; Para 39 “, control system 336 may cooperate with processor 304 to determine where autonomous vehicle 101 may safely travel, and to determine the presence of objects in a vicinity around autonomous vehicle 101 based on data, e.g., results, from sensor system 324. In other words, control system 336 may cooperate with processor 304 to effectively determine what autonomous vehicle 101 may do within its immediate surroundings. Control system 336 in cooperation with processor 304 may essentially control power system 332 and navigation system 312 as part of driving or conveying autonomous vehicle 101”; Para 33 “An autonomous vehicle 101 includes a processor 304, a propulsion system 308, a navigation system 312, a sensor system 324, a power system 332, a control system 336, and a communications system 340. It should be appreciated that processor 304, propulsion system 308, navigation system 312, sensor system 324, power system 332, and communications system 340 are all coupled to a chassis or body of autonomous vehicle 101”).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 5, 9-11, 18-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over DIVEKAR (US20220185115A1) in view of Cho (US20190006724A1).
In regards to claim 5, DIVEKAR teaches The computing system of claim 4.
Yet DIVEKAR do not explicitly teach wherein the at least a portion of the generated energy management data includes first BMS control data that controls a battery data transmission period of the BMS, based on a temperature of the battery identified through the acquired battery data.
However, in the same field of endeavor, Cho teaches wherein the at least a portion of the generated energy management data includes first BMS control data that controls a battery data transmission period of the BMS, based on a temperature of the battery identified through the acquired battery data (Cho: Para 20 “the master BMS setting a next wake-up time of a second slave BMS based on the first temperature data; the second slave BMS switching from the sleep mode to the wake-up mode when a wake-up time set thereto by the master BMS is reached; and the second slave BMS measuring a temperature of a second battery module from among a plurality of battery modules, during a wake-up period that is defined as a period from a latest time point of switching to the wake-up mode to a time point of re-switching to the sleep mode”; Para 21 “the setting of the next wake-up time of the second slave BMS may include setting a time equivalent to a sum of a current time and a first set time period as a next wake-up time of the second slave BMS, when the temperature of the first battery module is lower than a first set temperature”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify The computing system of DIVEKAR with the feature of wherein the at least a portion of the generated energy management data includes first BMS control data that controls a battery data transmission period of the BMS, based on a temperature of the battery identified through the acquired battery data disclosed by Cho. One would be motivated to do so for the benefit of “power consumption that occurs when a BMS unnecessarily enters the wake-up mode may be reduced” (Cho: Para 23).
In regards to claim 9, the DIVEKAR teaches The computing system of claim 8, and Cho further teaches wherein the component control data controls a driving data transmission period of the at least one sensor of the vehicle and is based on a temperature of the battery identified through the acquired battery data(Cho: Para 20 “the master BMS setting a next wake-up time of a second slave BMS based on the first temperature data; the second slave BMS switching from the sleep mode to the wake-up mode when a wake-up time set thereto by the master BMS is reached; and the second slave BMS measuring a temperature of a second battery module from among a plurality of battery modules, during a wake-up period that is defined as a period from a latest time point of switching to the wake-up mode to a time point of re-switching to the sleep mode”; Para 21 “the setting of the next wake-up time of the second slave BMS may include setting a time equivalent to a sum of a current time and a first set time period as a next wake-up time of the second slave BMS, when the temperature of the first battery module is lower than a first set temperature”). The Examiner supplies the same rationale for the combination of references DIVEKAR and Cho as in Claim 5 above.
In regards to claim 10, DIVEKAR teaches The computing system of claim 6, and Cho further teaches wherein the at least one processor is further configured to provide the at least a portion of the generated energy management data to the BMS, and wherein the at least a portion of the generated energy management data provided to the BMS includes second BMS control data for controlling battery data transmission of the BMS based on the acquired driving data (Cho: Para 53 “The controller 300 is configured to generate driving data notifying a driving status of the electric vehicle 1. For example, the driving data may include information indicating driving velocity, a geographical location, outside temperature, rotating speed of the motor 10, location of an accelerator pedal, location of a brake pedal, and whether there is a passenger in the electric vehicle 1. The M-BMS 220 may receive the driving data from the controller 300 via the communication network”; Para 54 “The M-BMS 220 may determine whether a predetermined event is happening based on the driving data. The event is determined in advance through a preliminary experiment, etc., to be appropriate for the S-BMS 210 to enter the wake-up mode. For example, a state in which the rotation of the motor 10 is completely stopped or the electric vehicle 1 is turned off may be one example of the event. The M-BMS 220 may identify whether the electric vehicle 1 is turned off based on the driving data. The M-BMS 220 may generate the setting data during the predetermined event is happening”; Para 68 “at a certain time point during the predetermined event occurs, a next wake-up time of one (210-1) of the S-BMSs 210-1 to 210-3 is set in advance whereas next wake-up times for the other S-BMSs 210-2 and 210-3 are not set yet, the M-BMS 220 may determine the next wake-up time of at least one of the S-BMSs 210-2 and 210-3 based on first temperature data transmitted from the first S-BMS 210-1”). The Examiner supplies the same rationale for the combination of references DIVEKAR and Cho as in Claim 5 above.
In regards to claim 11, the combination of DIVEKAR and Cho teaches The computing system of claim 10, and Cho further teaches wherein the second BMS control data controls at least one of: a battery data transmission period of the BMS(Cho: Para 68 “at a certain time point during the predetermined event occurs, a next wake-up time of one (210-1) of the S-BMSs 210-1 to 210-3 is set in advance whereas next wake-up times for the other S-BMSs 210-2 and 210-3 are not set yet, the M-BMS 220 may determine the next wake-up time of at least one of the S-BMSs 210-2 and 210-3 based on first temperature data transmitted from the first S-BMS 210-1”).The Examiner supplies the same rationale for the combination of references DIVEKAR and Cho as in Claim 5 above.
In regards to claim 18, DIVEKAR teaches The vehicle of claim 16, and Cho further teaches wherein the at least one processor is configured to:
generate sensor control data for controlling transmission of the driving data from the sensor based on the acquired battery data(Cho: Para 20 “the master BMS setting a next wake-up time of a second slave BMS based on the first temperature data; the second slave BMS switching from the sleep mode to the wake-up mode when a wake-up time set thereto by the master BMS is reached; and the second slave BMS measuring a temperature of a second battery module from among a plurality of battery modules, during a wake-up period that is defined as a period from a latest time point of switching to the wake-up mode to a time point of re-switching to the sleep mode”); and
transmit the generated sensor control data to the sensor(Cho: Para 20 “the master BMS setting a next wake-up time of a second slave BMS based on the first temperature data; the second slave BMS switching from the sleep mode to the wake-up mode when a wake-up time set thereto by the master BMS is reached; and the second slave BMS measuring a temperature of a second battery module from among a plurality of battery modules, during a wake-up period that is defined as a period from a latest time point of switching to the wake-up mode to a time point of re-switching to the sleep mode”).. The Examiner supplies the same rationale for the combination of references Marcoux, DIVEKAR, and Cho as in Claim 5 above.
In regards to claim 19, the combination of DIVEKAR and Cho teaches The vehicle of claim 18, and Cho further teaches wherein the at the sensor control data controls a driving data transmission period of the sensor based on a temperature of the battery identified through the acquired battery data(Cho: Para 20 “the master BMS setting a next wake-up time of a second slave BMS based on the first temperature data; the second slave BMS switching from the sleep mode to the wake-up mode when a wake-up time set thereto by the master BMS is reached; and the second slave BMS measuring a temperature of a second battery module from among a plurality of battery modules, during a wake-up period that is defined as a period from a latest time point of switching to the wake-up mode to a time point of re-switching to the sleep mode”). The Examiner supplies the same rationale for the combination of references Marcoux, DIVEKAR, and Cho as in Claim 5 above.
Claim 12, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over DIVEKAR (US20220185115A1) in view of Robbins (US20200171960A1).
In regards to claim 12, DIVEKAR teaches The computing system of claim 1.
Yet DIVEKAR do not explicitly teach wherein the at least one processor is configured to:
transmit the generated energy management data to a data management server; and
receive an energy management software update from the data management server, wherein the energy management software update is based on energy management data from computing systems of other autonomous vehicles.
However, in the same field of endeavor, Robbins teaches wherein the at least one processor is configured to:
transmit the generated energy management data to a data management server (Robbins: Para 19 “The external device 24 can be any type of device that allows data to be inputted or outputted from the vehicle control system 14. To set forth just a few non-limiting examples, the external device 24 can be a handheld device, another computer, a server, a printer, a display, an alarm, an illuminated indicator, a keyboard, a mouse, mouse button, or a touch screen display”; Para 51 “The vehicle control system monitors various voltages reported over CAN from the BMS and Motor Controller”); and
receive an energy management software update from the data management server, wherein the energy management software update is based on energy management data from computing systems of other autonomous vehicles(Robbins: Para 43 “the Visage system is able to perform Over the Air (OTA) updates of vehicle components. In particular, the BMS can be updated, which has internal software rules that prevent updating when the pack main output is connected”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify The computing system of DIVEKAR with the feature of wherein the at least one processor is configured to execute the second program to: transmit the generated energy management data to a data management server; and receive an energy management software update from the data management server, wherein the energy management software update is based on energy management data from computing systems of other autonomous vehicles disclosed by Robbins. One would be motivated to do so for the benefit of “permits over the air communication, such as but not limited to software updates for the various devices of the vehicle 12” (Robbins: Para 27).
In regards to claim 20, DIVEKAR teaches The vehicle of claim 16.
Yet DIVEKAR do not explicitly teach a communication module configured to communicate with an external electronic device,
wherein the at least one processor is configured to:
transmit the generated energy management data to a data management server using the communication module; and
receive an energy management software update from the data management server, and wherein the energy management software update is based on energy management data from computing systems of other autonomous vehicles.
However, in the same field of endeavor, Robbins teaches a communication module configured to communicate with an external electronic device(Robbins: Para 18 “the vehicle control system 14 includes a processing device 16, an input/output device 18, a memory 20, and an operating logic 22. Furthermore, as illustrated, the vehicle control system 14 can communicate with one or more external devices 24, as discussed below. The input/output device 18 can be any type of device that allows the vehicle control system 14 to communicate with the external device 24 and/or to otherwise receive/communicate instructions and/or information”),
wherein the at least one processor is configured to:
transmit the generated energy management data to a data management server using the communication module(Robbins: Para 19 “The external device 24 can be any type of device that allows data to be inputted or outputted from the vehicle control system 14. To set forth just a few non-limiting examples, the external device 24 can be a handheld device, another computer, a server, a printer, a display, an alarm, an illuminated indicator, a keyboard, a mouse, mouse button, or a touch screen display”; Para 51 “The vehicle control system monitors various voltages reported over CAN from the BMS and Motor Controller”); and
receive an energy management software update from the data management server, and wherein the energy management software update is based on energy management data from computing systems of other autonomous vehicles(Robbins: Para 43 “the Visage system is able to perform Over the Air (OTA) updates of vehicle components. In particular, the BMS can be updated, which has internal software rules that prevent updating when the pack main output is connected”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify The vehicle of DIVEKAR with the feature of a communication module configured to communicate with an external electronic device, wherein the at least one processor is configured to execute the second program to: transmit the generated energy management data to a data management server using the communication module; and receive an energy management software update from the data management server, and wherein the energy management software update is based on energy management data from computing systems of other autonomous vehicles disclosed by Robbins. One would be motivated to do so for the benefit of “permits over the air communication, such as but not limited to software updates for the various devices of the vehicle 12” (Robbins: Para 27).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Grimes (US20160096438A1) disclosed A vehicle off-board charger includes a charger component that receives power from an external power source and transfers the received power to a vehicle, and a gateway that communicates with the vehicle via a vehicle connection, receives controller area network (CAN) information from a vehicle controller, and in response to the CAN information indicating charge complete or fault detected, ceases the transfer of power of the charger component.
Marcoux (US20160187432A1) disclosed the management of the charging of an electric storage battery, in particular the management of the charging of a battery for an electric and/or hybrid motor vehicle. Such batteries can be of the lithium-ion type, for example. They generally comprise a plurality of electric accumulators, also referred to as cells. Each cell has an electrochemical system capable of being recharged up to a maximum no-load voltage, and then delivering an electrical current at a voltage which is initially slightly less than the maximum no-load voltage, which then decreases, at constant current intensity, until the next step of recharging of the battery. The batteries are generally controlled by an electronic battery control system (BMS—“battery management system”) that controls for example the battery recharge phases in order to bring the battery to the desired voltage at the end of recharging without causing overheating of the battery and preventing any of the cells from reaching a significantly higher or significantly lower level of charge compared with the other battery cells.
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 WENYUAN YANG whose telephone number is (571)272-5455. The examiner can normally be reached Monday - Thursday 9:00AM-5:00PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hitesh Patel can be reached at (571) 270-5442. 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.
/W.Y./Examiner, Art Unit 3667
/Hitesh Patel/Supervisory Patent Examiner, Art Unit 3667
6/29/26
Prosecution Insights