DETAILED ACTION
Remarks
Applicant’s amendment and response dated 5/29/2026 has been provided in response to the 4/6/2026 Office Action which rejected claims 1-20, wherein claims 1, 3, 5, 9, and 15 have been amended and claims 2, 10, and 16 have been cancelled. Thus, claims 1, 3-9,11-15, and 17-20 remain pending in this application and have been fully considered by the examiner.
Applicant’s arguments with respect to claims 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.
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.
Response to Arguments
In response to Applicant’s arguments regarding 101 (See pages 6-8 of Applicant’s
remarks), the Applicant should please see the rejection below for clarification as it will substantially duplicate any response to the arguments in this section. However, the Applicant
should please note that the limitations of the claim, even when taken as an ordered combination,
do not provide steps that confine the abstract idea to a particular useful application. The newly
added limitations of “obtaining task information of an upgrade task when a software function of an in-vehicle component is faulty” and “wherein the task information comprises information about an upgrade strategy associated with a software function status of the in-vehicle component, and the information about the upgrade strategy indicates the in- vehicle component to be upgraded and comprises a preset condition used by the in-vehicle component to omit a pre-upgrade processing procedure or is used by the in-vehicle component to directly enter an upgrade state” can still be performed in the human mind through observation, evaluation, judgement, or opinion with the aid of pen and paper and therefore are still mental processes.
Claim Rejections - 35 USC § 101
4. 35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefore, subject to the conditions and requirements of this title.
Claims 1, 3-9,11-15, and 17-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed
to an abstract idea without significantly more. The analysis specific to Claim 1 is being presented below.
Claim 1 recites:
An upgrade method, comprising:
obtaining task information of an upgrade task when a software function of an in-vehicle component is faulty;
sending the task information of an upgrade task, wherein the task information comprises information about upgrade strategy, wherein the upgrade strategy is associated with a software function status of the in-vehicle component, the information about the upgrade strategy is used to indicate the in-vehicle component to be upgraded and comprises a preset condition used by the in-vehicle component to omit a pre-upgrade processing procedure or is used by the in-vehicle component to directly enter an upgrade state.
Step 1:
The claim falls within a statutory category of being a method.
Step 2A- Prong 1:
The claim recites the limitations of:
obtaining task information of an upgrade task when a software function of an in-vehicle component is faulty;
sending the task information of an upgrade task, wherein the task information comprises information about upgrade strategy, wherein the upgrade strategy is associated with a software function status of the in-vehicle component, the information about the upgrade strategy is used to indicate the in-vehicle component to be upgraded and comprises a preset condition used by the in-vehicle component to omit a pre-upgrade processing procedure or is used by the in-vehicle component to directly enter an upgrade state.
These limitations, as drafted, are processes that, under their broadest reasonable interpretations, cover performance of the limitations in the mind. That is, nothing in the claim elements precludes the step from practically being performed in the mind or with a pen and paper, i.e. “obtaining”, and “sending” can be performed in the human mind through observation, evaluation, judgement, or opinion with the aid of pen and paper. For example, “obtaining…” is comparable to “extracting” and “sending…” is comparable to “redistributing…”. As such, these limitations fall within the “Mental Processes” grouping of abstract ideas.
Step 2A Prong 2:
The claim recites the additional element of “in-vehicle component”, which is recited at a high level of generality, i.e., merely instructions to implement the abstract idea on a generic computer or merely uses a computer as a tool to perform the abstract idea and thus does not integrate the judicial exception into a practical application.
Step 2B:
As discussed with respect to Step 2A Prong 2, the additional elements of “in-vehicle component” merely recites generic computer and computer components, and thus do not amount to significantly more than the judicial exception. The same analysis applies here in 2B, i.e., simply adding extra-solution activity or generic computer components does not integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Therefore, none of the additional elements recite an inventive concept, thus, the claimed invention is patent ineligible under 35 USC 101.
Additionally, claim 3 recites “wherein the obtaining task information of an upgrade task comprises: obtaining a first instruction when the software function of the in-vehicle component is faulty, wherein the first instruction is used to indicate the upgrade strategy of the in-vehicle component; and obtaining the task information of the upgrade task in response to the first instruction”, which is an additional mental process, as discussed above. As such, this claim fails both Step 2A prong 2 and Step 2B and is ineligible.
Additionally, claim 4 recites wherein the method further comprises: sending a second instruction, wherein the second instruction is used to indicate to check a speed and a gear state of a vehicle”, which is an additional mental process, as discussed above. As such, this claim fails both Step 2A prong 2 and Step 2B and is ineligible.
Additionally, claim 5 recites “wherein before sending task the information of an upgrade task, the method further comprises: displaying risk warning information”, which is merely insignificant extra solution activity of presenting data. Thus, this limitation does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea or provide an inventive concept and thus does not amount to significantly more that the abstract idea and “obtaining a first operation of a user for the risk warning information, wherein the first operation is used to indicate that the user allows a server to deliver the task information of the upgrade task,” which is an additional mental process, as discussed above. As such, this claim fails both Step 2A prong 2 and Step 2B and is ineligible.
Additionally, claim 6 recites wherein the first instruction is determined based on a user input, which is an additional mental process, as discussed above. As such, this claim fails both Step 2A prong 2 and Step 2B and is ineligible.
Additionally, claim 7 recites “wherein the method further comprises: obtaining a third instruction, wherein the third instruction is used to indicate that the user allows the server to deliver an upgrade package corresponding to the upgrade task; and sending the upgrade package to the vehicle”, which is an additional mental process, as discussed above. As such, this claim fails both Step 2A prong 2 and Step 2B and is ineligible.
Additionally, claim 8 recites” wherein the method further comprises: signing the task information of the upgrade task based on a first certificate of the vehicle, to obtain the signed task information, wherein the signed task information is used to verify security of the task information”, which is recited at a high level of generality, i.e., merely instructions to implement the abstract idea on a generic computer or merely uses a computer as a tool to perform the abstract idea and thus does not integrate the judicial exception into a practical application. As such, this claim fails both Step 2A prong 2 and Step 2B and is ineligible.
Claim 9 recites:
An upgrade method, comprising:
receiving task information of an upgrade task when a software function of an in-vehicle component is faulty, wherein the task information comprises information about an upgrade strategy associated with a software function status of the in-vehicle component, the information about the upgrade strategy indicates the in-vehicle component to be upgraded and comprises a preset condition used by the in-vehicle component to omit a pre-upgrade processing procedure or is used by the in-vehicle component to directly enter an upgrade state, and
upgrading the in-vehicle component based on the information about the upgrade strategy.
Step 1:
The claim falls within a statutory category of being a method.
Step 2A- Prong 1:
The claim recites the limitations of:
“receiving task information of an upgrade task when a software function of an in-vehicle component is faulty, wherein the task information comprises information about an upgrade strategy associated with a software function status of the in-vehicle component, the information about the upgrade strategy indicates the in-vehicle component to be upgraded and comprises a preset condition used by the in-vehicle component to omit a pre-upgrade processing procedure or is used by the in-vehicle component to directly enter an upgrade state”
These limitations, as drafted, are processes that, under their broadest reasonable interpretations, cover performance of the limitations in the mind. That is, nothing in the claim elements precludes the step from practically being performed in the mind or with a pen and paper, i.e. “receiving” can be performed in the human mind through observation, evaluation, judgement, or opinion with the aid of pen and paper. As such, these limitations fall within the “Mental Processes” grouping of abstract ideas.
Step 2A Prong 2:
The claim recites the additional elements of “in-vehicle component”, and “upgrading the in-vehicle component based on the information about the upgrade strategy”, which recite insignificant extra activity solution and recited at a high level of generality, i.e., merely uses a computer as a tool to perform the abstract idea and thus does not integrate the judicial exception into a practical application.
Step 2B:
As discussed with respect to Step 2A Prong 2, the additional elements of “in-vehicle component” and “upgrading the in-vehicle component based on the information about the upgrade strategy” recite insignificant extra activity solution and are recited at a high level of generality, i.e., merely uses a computer as a tool to perform the abstract idea and thus does not integrate the judicial exception into a practical application. The same analysis applies here in 2B, i.e., simply adding extra-solution activity or generic computer components does not integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Therefore, none of the additional elements recite an inventive concept, thus, the claimed invention is patent ineligible under 35 USC 101.
Additionally, claim 11 recites wherein the method further comprises: receiving a second instruction, wherein the second instruction is used to indicate to check a speed and a gear state of a vehicle, which is an additional mental process, as discussed above. As such, this claim fails both Step 2A prong 2 and Step 2B and is ineligible.
Additionally, claim 12 recites “wherein the upgrading the in-vehicle component based on the information about the upgrade strategy comprises: receive an upgrade package corresponding to the upgrade task; and upgrading the in-vehicle component based on the information about the upgrade strategy and the upgrade package,” which recites insignificant extra activity solution and is recited at a high level of generality, i.e., merely uses a computer as a tool to perform the abstract idea and thus does not integrate the judicial exception into a practical application. As such, this claim fails both Step 2A prong 2 and Step 2B and is ineligible.
Additionally, claim 13 recites “wherein the upgrading the in-vehicle component based on the information about the upgrade strategy comprises: upgrading the in-vehicle component based on the information about the upgrade strategy and a local upgrade package of the vehicle,” which recites insignificant extra activity solution and is recited at a high level of generality, i.e., merely uses a computer as a tool to perform the abstract idea and thus does not integrate the judicial exception into a practical application. As such, this claim fails both Step 2A prong 2 and Step 2B and is ineligible.
Additionally, claim 14 recites “wherein before the upgrading the in-vehicle component based on the information about the upgrade strategy, the method further comprises: verifying a signature of the task information based on a first certificate of the vehicle; and determining that signature verification of the task information is successful”, which are additional mental processes, as discussed above. As such, this claim fails both Step 2A prong 2 and Step 2B and is ineligible.
Claim 15 recites:
An upgrade apparatus, comprising:
a transceiver, configured to receive task information of an upgrade task when a software function of an in-vehicle component is faulty, wherein the task information comprises information about an upgrade strategy, and the information about the upgrade strategy is associated with a software function status of the in-vehicle component, the information about the upgrade strategy indicates the in-vehicle component to be upgraded and comprises a preset condition used by the in-vehicle component to omit a pre-upgrade processing procedure or is used by the in-vehicle component to directly enter an upgrade state; and a processor, configured to upgrade the in-vehicle component based on the information about the upgrade strategy.
Step 1:
The claim falls within a statutory category of being a system.
Step 2A- Prong 1:
The claim recites the limitations of:
“receive task information of an upgrade task when a software function of an in-vehicle component is faulty, wherein the task information comprises information about an upgrade strategy, and the information about the upgrade strategy is associated with a software function status of the in-vehicle component, the information about the upgrade strategy indicates the in-vehicle component to be upgraded and comprises a preset condition used by the in-vehicle component to omit a pre-upgrade processing procedure or is used by the in-vehicle component to directly enter an upgrade state”
These limitations, as drafted, are processes that, under their broadest reasonable interpretations, cover performance of the limitations in the mind. That is, nothing in the claim elements precludes the step from practically being performed in the mind or with a pen and paper, i.e. “receiving” can be performed in the human mind through observation, evaluation, judgement, or opinion with the aid of pen and paper. As such, these limitations fall within the “Mental Processes” grouping of abstract ideas.
Step 2A Prong 2:
The claim recites the additional elements of “in-vehicle component”, “ a transceiver”, “a processor” and “upgrading the in-vehicle component based on the information about the upgrade strategy”, which recites insignificant extra activity solution and are recited at a high level of generality, i.e., merely uses a computer as a tool to perform the abstract idea and thus does not integrate the judicial exception into a practical application.
Step 2B:
As discussed with respect to Step 2A Prong 2, the additional elements of “in-vehicle component”, “ a transceiver”, “a processor” and “upgrading the in-vehicle component based on the information about the upgrade strategy” merely recite insignificant extra activity solution and are recited at a high level of generality, i.e., merely uses a computer as a tool to perform the abstract idea and thus does not integrate the judicial exception into a practical application. The same analysis applies here in 2B, i.e., simply adding extra-solution activity or generic computer components does not integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Therefore, none of the additional elements recite an inventive concept, thus, the claimed invention is patent ineligible under 35 USC 101.
Additionally, claim 17 recites wherein the transceiver is configured to receive a second instruction, wherein the second instruction is used to indicate to check a speed and a gear state of a vehicle, which is an additional mental process, as discussed above. As such, this claim fails both Step 2A prong 2 and Step 2B and is ineligible.
Additionally, claim 18 recites “wherein the transceiver is configured to receive an upgrade package corresponding to the upgrade task, which is an additional mental process, and “the processor is configured to upgrade the in-vehicle component based on the information about the upgrade strategy and the upgrade package”, which recites insignificant extra activity solution and is recited at a high level of generality, i.e., merely uses a computer as a tool to perform the abstract idea and thus does not integrate the judicial exception into a practical application. As such, this claim fails both Step 2A prong 2 and Step 2B and is ineligible.
Additionally, claim 19 recites wherein the processor is configured to upgrade the in-vehicle component based on the information about the upgrade strategy and a local upgrade package of the vehicle, which recites insignificant extra activity solution and is recited at a high level of generality, i.e., merely uses a computer as a tool to perform the abstract idea and thus does not integrate the judicial exception into a practical application. As such, this claim fails both Step 2A prong 2 and Step 2B and is ineligible.
Additionally, claim 20 recites wherein the processor is configured to verify a signature of the task information based on a first certificate of the vehicle; and determine that signature verification of the task information is successful, which are additional mental processes. As such, this claim fails both Step 2A prong 2 and Step 2B and is ineligible.
Claim Rejections - 35 USC § 102
5. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
6. Claims 1, 9, and 15 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Knaut et al. (US Patent Application 2022/0083411 A1).
As to claim 1, Knaut teaches an upgrade method, comprising: obtaining task information of an upgrade task when a software function of an in-vehicle component (e.g. means of transport) is faulty (e.g. troubleshooting operations, see Figs.1-3 and associated text, e.g. [0010]- an “error report” may be a finding of a functional error, such as incomplete charging of a battery and/or a software error and/or a malfunction of a component of the means of transport; Thus, an error report may include a vehicle diagnosis of an error and/or an externally detected error and [0039]- In a first step 100, a receiving of an error report ER from the means of transport 1b is performed on the back-end server 3; The means of transport 1b then generates a configuration specification A comprising a serial number of the display unit and a software version of the display unit. In response thereto, in a fifth step 500, the configuration specification A is sent to and received from the back-end server 3 as a response. On the back-end server 3, in a sixth step 600, an automatic determination of a troubleshooting operation M1-M6 based on the configuration specification A is performed; the software version associated with the error pattern EP2 corresponds to a specific troubleshooting operation M2, which provides for a software update of the software that operates the display unit), sending the task information of the upgrade task, wherein the task information comprises information about an upgrade strategy associated with a software function status of the in-vehicle component (see e.g. [0039]- Accordingly, in a seventh step 700, a sending of the troubleshooting operation M2 to the means of transport 1b is performed. Here a software update is carried out on the means of transport 1b, which solves the error), information about the upgrade strategy indicates the in-vehicle component to be upgraded (See e.g. [0039]- a configuration request representing the union set of configuration requirements K1, K2, which states that a serial number of the display unit is needed and that a software version of the display unit is needed, is automatically generated and sent to the means of transport 1b. The means of transport 1b then generates a configuration specification A comprising a serial number of the display unit and a software version of the display unit. In response thereto, in a fifth step 500, the configuration specification A is sent to and received from the back-end server 3 as a response,) and comprises a preset condition [used by the in-vehicle component to omit a pre-upgrade processing procedure or] is used by the in-vehicle component to directly enter an upgrade state (see e.g. [0022]- the troubleshooting operation may comprise automatically initiating a software update and [0039]- Accordingly, in a seventh step 700, a sending of the troubleshooting operation M2 to the means of transport 1b is performed. Here a software update is carried out on the means of transport 1b, which solves the error).
As to claim 9, Knaut teaches an upgrade method, comprising: receiving task information of an upgrade task when a software function of an in-vehicle component (e.g. means of transport) is faulty (see e.g. [0039]- In a first step 100, a receiving of an error report ER from the means of transport 1b is performed on the back-end server 3; The means of transport 1b then generates a configuration specification A comprising a serial number of the display unit and a software version of the display unit. In response thereto, in a fifth step 500, the configuration specification A is sent to and received from the back-end server 3 as a response. On the back-end server 3, in a sixth step 600, an automatic determination of a troubleshooting operation M1-M6 based on the configuration specification A is performed; the software version associated with the error pattern EP2 corresponds to a specific troubleshooting operation M2, which provides for a software update of the software that operates the display unit; Accordingly, in a seventh step 700, a sending of the troubleshooting operation M2 to the means of transport 1b is performed), wherein the task information comprises information about an upgrade strategy associated with a software function status of the in-vehicle component (see e.g. [0039]- Accordingly, in a seventh step 700, a sending of the troubleshooting operation M2 to the means of transport 1b is performed. Here a software update is carried out on the means of transport 1b, which solves the error), information about the upgrade strategy indicates the in-vehicle component to be upgraded (See e.g. [0039]- a configuration request representing the union set of configuration requirements K1, K2, which states that a serial number of the display unit is needed and that a software version of the display unit is needed, is automatically generated and sent to the means of transport 1b. The means of transport 1b then generates a configuration specification A comprising a serial number of the display unit and a software version of the display unit. In response thereto, in a fifth step 500, the configuration specification A is sent to and received from the back-end server 3 as a response), and comprises a preset condition [used by the in-vehicle component to omit a pre-upgrade processing procedure or] is used by the in-vehicle component to directly enter an upgrade state (see e.g. [0022]- the troubleshooting operation may comprise automatically initiating a software update and [0039]- Accordingly, in a seventh step 700, a sending of the troubleshooting operation M2 to the means of transport 1b is performed. Here a software update is carried out on the means of transport 1b, which solves the error).
As to claim 15, the limitations of the claims are substantially similar to the limitations of claim 9, and therefore, it is rejected for the reasons stated above.
Claim Rejections - 35 USC § 103
7. 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.
8. Claims 4, 11-13, and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Knaut et al. (US Patent Application 2022/0083411 A1) in view of Takatsuna (US Patent Application 2021/0405994 A1).
As to claim 4, Knaut teaches the limitations of claim 1, but does not specifically teach sending a second instruction, wherein the second instruction indicates to check a speed and a gear state of a vehicle.
In an analogous art of updating vehicle components, however, Takatsuna teaches sending a second instruction, wherein the second instruction indicates to check a speed and a gear state of a vehicle (see e.g. [0036]- examples of the prerequisite conditions that vehicles are to satisfy at the time of execution of software updating processing will be described; The availability of functions of the electronic control unit that is the object of updating is a condition requesting that settings are made by the user to use the functions of the electronic control unit that is the object of updating. The shift range, vehicle speed, and GPS coordinates are conditions requesting that the vehicle is in a safe state at the time of execution of the software updating processing, and specifically, the shift range of P range, the vehicle speed of 0 km/h, and the current GPS coordinates in a coordinate range other than on a public road, such as in a parking lot or in a space where the vehicle can be stopped, or the like can be defined).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Knaut to incorporate/implement the limitations as taught by Takatsuna in order to provide a more efficient method of updating software of vehicle components as needed.
As to claim 11, the limitations of the claims are substantially similar to the limitations of claim 4, and therefore, it is rejected for the reasons stated above.
As to claim 12, Takatsuna further teaches wherein upgrading the in- vehicle component based on the information about the upgrade strategy comprises: receiving an upgrade package corresponding to the upgrade task (see e.g. [0043]- the communication unit 37 transmits a download request for a distribution package to the server 1, and receives the distribution package transmitted from the server 1), and upgrading the in-vehicle component based on the information about the upgrade strategy and the upgrade package (See e.g. [0072]- The electronic control units that are the objects of updating use the update data received from the software updating device 11 and install the update version of the software in a storage region).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Knaut to incorporate/implement the limitations as taught by Takatsuna in order to provide a more efficient method of updating software of vehicle components as needed.
As to claim 13, Takatsuna further teaches wherein upgrading the in-vehicle component based on the information about the upgrade strategy comprises upgrading the in-vehicle component based on the information about the upgrade strategy and a local upgrade package of the a vehicle corresponding to the in-vehicle component (See e.g. [0072]- The electronic control units that are the objects of updating use the update data received from the software updating device 11 and install the update version of the software in a storage region; The electronic control units that are the objects of updating switch the software to be executed to the update-version software, thereby enabling and starting the update-version software).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Knaut to incorporate/implement the limitations as taught by Takatsuna in order to provide a more efficient method of updating software of vehicle components as needed.
As to claim 17, the limitations of the claims are substantially similar to the limitations of claim 4, and therefore, it is rejected for the reasons stated above.
As to claim 18, the limitations of the claims are substantially similar to the limitations of claim 12, and therefore, it is rejected for the reasons stated above.
As to claim 19, the limitations of the claims are substantially similar to the limitations of claim 13, and therefore, it is rejected for the reasons stated above.
9. Claims 3 and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Knaut et al. (US Patent Application 2022/0083411 A1) in view of Ewert (US Patent Application 2019/0196806 A1).
As to claim 3, Knaut teaches obtaining task information of the upgrade task (see e.g. [0010] and [0039]), but does not specifically teach obtaining a first instruction when the software function of the in-vehicle component is faulty, wherein the first instruction is used to indicate the upgrade strategy of the in-vehicle component and obtaining the task information of the upgrade task in response to the first instruction.
In an analogous art of updating vehicle components, however, Ewert teaches obtaining a first instruction when a software function of the in-vehicle component is faulty wherein the first instruction is used to indicate the upgrade strategy of the in-vehicle component (see e.g. [0041]- Transmitting unit 9 of stationary server 8 may also be designed as a receiving unit, which makes it possible to receive data from motor vehicle communication systems 4,[0042]- This makes it possible to transmit data concerning sensors 6 from motor vehicle communication systems 4 to stationary server 8. This makes it possible for example to communicate to the manufacturer that an error occurred in sensor 6 and/or that sensor 6 is defective and/or that sensor 6 is operated with outdated software, [0043]- It is also possible to transmit the serial number of sensor 6 to the manufacturer/stationary server 8. This allows the manufacturer accurately to identify sensor 6 and errors possibly occurring on/in sensor 6 and to assign these to a sensor. In this manner, the manufacturer knows in particular precisely which motor vehicles 2, 14 are operated with a defective sensor 6. If it is a software error, it is subsequently possible in short order to install an updated software for the respective sensors 6 via the described connection 10, 12 precisely in these motor vehicles 2, 14) and obtaining the task information of the upgrade task in response to the first instruction [0044]-Motor vehicle servers 16 obtain the software updates for the sensors 6 installed in the respective motor vehicle via a car-to-car and/or a car-to-infrastructure communication interface, as was described previously, and distribute the software then via a local connection 5, e.g., LAN, LIN, CAN FlexRay, Ethernet, radio connection, etc., within the motor vehicle 2, 14 to the respective sensors 6 and/or their sensor control units).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Knaut to incorporate/implement the limitations as taught by Ewert in order to provide a more efficient method of updating software of vehicle components.
As to claim 6, Ewert further teaches wherein the first instruction is determined based on a user input (see e.g. [0027]-[0028]: the user/driver of the motor vehicle is informed about the software update; before a software update is performed on the sensor, a confirmation of the software update is requested from the driver via the HMI, for example a display or a smartphone. The update is performed only if the user/driver consents).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Knaut to incorporate/implement the limitations as taught by Ewert in order to provide a more efficient method of updating software of vehicle components.
10. Claims 5 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Knaut et al. (US Patent Application 2022/0083411 A1) in view of Matsumoto et al. (US Patent Application 2020/0233654 A1).
As to claim 5, Knaut does not specifically teach wherein before sending the task information of the upgrade task the method further comprises displaying risk warning information and obtaining a first operation of a user for the risk warning information, wherein the first operation indicates that the user allows a server to deliver the task information of the upgrade task.
In an analogous art of updating software, however, Matsumoto teaches wherein before sending task information of an the upgrade task the method further comprises displaying risk warning information and obtaining a first operation of a user for the risk warning information, wherein the first operation indicates that the user allows a server to deliver the task information of the upgrade task (See e.g. Figs.19 and 20 and associated text, e.g. [0139]- the software update control unit 410 displays information related to the update of the secure software based on the received information (6), together with complementary information such as precautions, restrictions and instructions in the update of the secure software, as a GUI on the display device 110 as shown in FIG. 20 (S1920). Here, because the server 30 cannot receive the update information of the secure software (secure software group to be updated and related information (software name and version, restrictions upon performing software update, message to user, etc.)) (information (5)) when the communication path is the communication terminal 20, the software update control unit 410 changes the communication path from the communication terminal 20 to the vehicle communication device 44 (S1922), Next, the software update control unit 410 acquires the communication path (communication path=vehicle communication device 44) that can be used for the software update (S1923), subsequently performs authentication with the server 30, and sends the configuration of the secure software, and the communication path information, to the server 30 via the vehicle communication device 44 (S1924)).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Knaut to incorporate/implement the limitations as taught by Matsumoto in order to provide a more efficient and cost-effective method of updating software used in vehicles.
As to claim 7, Matsumoto further teaches obtaining a third instruction, wherein the third instruction indicates that the user allows the server to deliver an upgrade package corresponding to the upgrade task (see e.g. [0139]- the software update control unit 410 displays information related to the update of the secure software based on the received information (6), together with complementary information such as precautions, restrictions and instructions in the update of the secure software, as a GUI on the display device 110 as shown in FIG. 20 (S1920) and sending the upgrade package to the a vehicle corresponding to the in-vehicle component (see e.g. [0140]- The software distribution control unit 610 of the server 30 confirms whether there is any update of the secure software based on the configuration information of the secure software (S1932), and, when there is a software update, subsequently generates the update information (information (5)) of the secure software based on the received information (S1934), and sends the generated information (5) to the in-vehicle terminal 10 via the vehicle communication device 44 (S1936)).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Knaut to incorporate/implement the limitations as taught by Matsumoto in order to provide a more efficient and cost-effective method of updating software used in vehicles.
11. Claims 8, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Knaut et al. (US Patent Application 2022/0083411 A1) in view of Yang et al. (US Patent Application Publication 2021/0051000 A1).
As to claim 8, Knaut teaches the task information of the upgrade task (see e.g. [0010] and [0039]), but does not specifically teach signing the task information of the upgrade task based on a first certificate of a vehicle corresponding to the in-vehicle component to obtain the signed task information, wherein the signed task information is used to verify security of the task information.
In an analogous art of updating software, however, Yang teaches signing task information of an upgrade task (e.g. in-vehicle upgrade package) based on a first certificate of a vehicle corresponding to an in-vehicle component to obtain the signed task information (see e.g. Figs.4 and 8 and associated text, e.g. [0121]- An upgrade server is configured to obtain, from a developer, an in-vehicle upgrade package encrypted by the developer, [0122]- A key server is configured to: when the in-vehicle upgrade package is encrypted by the developer, obtain a key from the developer through a secure channel, store the key, and finally provide the key to a vehicle-mounted control device, [0124]- the developer delivers the in-vehicle upgrade package to the upgrade server, where the delivered in-vehicle upgrade package needs to be signed through digital signature. Optionally, before being signed through digital signature, the in-vehicle upgrade package may be further encrypted), wherein the signed task information is used to verify security of the task information (see e.g. [0108]- a logical functional entity is newly added to the upgrade server, and the logical functional entity is configured to store a related key, to perform security enhancement on intra-vehicle storage or transmission of an upgrade file, thereby ensuring secure upgrade of the vehicle).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Knaut to incorporate/implement the limitations as taught by Yang in order to provide a more efficient and secure method of updating software/firmware of vehicle components to ensure safety of the vehicle and its users.
As to claim 14, Yang further teaches wherein, before the upgrading the in-vehicle component based on the information about the upgrade strategy, the method further comprises verifying a signature of the task information based on a first certificate of a vehicle corresponding to the in-vehicle component and determining that signature verification of the task information is successful (see e.g. [0014]- before the vehicle-mounted control device receives the first partial key sent by the communications device, the method further includes: the vehicle-mounted control device obtains an upgrade package. The upgrade package includes the first upgrade file. The vehicle-mounted control device performs secure verification on the upgrade package. When the verification succeeds, the vehicle-mounted control device requests the first partial key from the communications device. In this embodiment of the present disclosure, before obtaining partial key that is separately stored, the vehicle-mounted control device first needs to obtain the upgrade package including the upgrade file, and performs secure verification on the upgrade package. After the verification succeeds, the vehicle-mounted control device initiates a procedure of performing secure processing on the corresponding upgrade file and transmitting the upgrade file to the corresponding to-be-upgraded vehicle-mounted device. Only in this case, the vehicle-mounted control device requests, from the communications device, the partial key used to perform secure processing on the upgrade file and [0124]- the developer delivers the in-vehicle upgrade package to the upgrade server, where the delivered in-vehicle upgrade package needs to be signed through digital signature. Optionally, before being signed through digital signature, the in-vehicle upgrade package may be further encrypted).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Knaut to incorporate/implement the limitations as taught by Yang in order to provide a more efficient and secure method of updating software/firmware of vehicle components to ensure safety of the vehicle and its users.
As to claim 20, the limitations of the claims are substantially similar to the limitations of claim 14, and therefore, it is rejected for the reasons stated above.
Conclusion
12. Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHENECA SMITH whose telephone number is (571)270-1651. The examiner can normally be reached Mon-Fri 8:00AM-4:30PM 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, Hyung S Sough can be reached at 571-272-6799. 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.
/CHENECA SMITH/Examiner, Art Unit 2192
/S. Sough/SPE, Art Unit 2192
Prosecution Insights