Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
1. This Office Action is in response to the application filed on 12/12/2023. Claims 1-20 are pending in this application. Claims 1, 7, 8, 13 and 18-20 are independent claims.
Claim Rejections - 35 USC § 101
2. 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 therefor, subject to the conditions and requirements of this title.
3. Claims 8-12 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the center device of the system claim 8 is subject to software per se as the center device can be interpreted as software program that transmits update data by a streaming manner. Claims 9-12 are also rejected for incorporating the deficiency of their independent claim 8.
4. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The independent claims 1, 7, 8, 13 and 18-20 are corresponding to one of four statutory categories including method, system, and method respectively under step 1.
The claim 1 recites “an onboard communication system comprising: a center device that is configured to transmit update data as a distribution package by a streaming manner to an electronic control unit installed in a vehicle; a master device that is installed in the vehicle and is configured to receive the distribution package and transfer the update data to the electronic control unit; and the electronic control unit that is configured to write the update data transferred from the master device to a storage unit, wherein the center device also transmits a hash value calculated for the update data to the master device, the electronic control unit calculates a hash value for the update data and transmits the hash value to the master device, and the master device compares the hash value transmitted from the center device with the hash value transmitted from the electronic control unit to verify integrity of the update data”.
The claim 7 recites “an onboard communication system comprising: a center device that is configured to transmit update data as a distribution package by a streaming manner to an electronic control unit installed in a vehicle; a master device that is configured to receive the distribution package and transfer the update data to the electronic control unit; and the electronic control unit that is configured to write the update data transferred from the master device to a storage unit, wherein the center device also transmits a hash value calculated for the update data to the master device, and the master device calculates a hash value for each predetermined data size for the update data to obtain a hash value for a whole update data, and compares the hash value with the hash value transmitted from the center device to verify integrity of the update data”.
The claim 8 recites “a center device that transmits update data by a streaming manner as well as a hash value calculated for the update data to an electronic control unit installed in a vehicle”.
The claim 13 recites “a vehicle-side system comprising: a master device that is installed in a vehicle and is configured to receive a distribution package, which includes update data and is transmitted from a center device by a streaming manner; and an electronic control unit that is installed in the vehicle and is configured to write the update data transferred from the master device to a storage portion, wherein the master device receives a hash value calculated for the update data and transmitted by the center device, a hash value calculated for the update data by the center device the electronic control unit calculates a hash value for the update data and transmits the hash value to the master device, and the master device compares the hash value transmitted from the center device with the hash value transmitted from the electronic control unit to verify integrity of the update data”.
The claim 18 recites “a vehicle-side system comprising: a master device that is installed in a vehicle and is configured to receive update data transmitted by a streaming manner from a center device as a distribution package; and an electronic control unit that is installed in the vehicle and is configured to write the update data transferred from the master device to a storage portion, wherein the center device transmits a hash value calculated for the update data to the master device, and the master device receives a hash value calculated for the update data by the center device, the master device calculates a hash value for each predetermined data size for the update data to obtain a hash value for a whole update data, and compares the hash value with the hash value transmitted from the center device to verify integrity of the update data”.
The claim 19 recites “a method for verifying update data of onboard communication comprising: when a center device transmits update data by a streaming manner to an electronic control unit installed in a vehicle, transferring distribution package to the electronic control unit when a master device installed in the vehicle receives the update data as the distribution package; transmitting, by the center device, a hash value calculated for the update data to the master device, transmitting, by the electronic control unit, a hash value calculated for the update data to the master device, and verifying, by the master device, integrity of the update data by comparing the hash value transmitted from the center device with the hash value transmitted from the electronic control unit”.
The claim 20 recites “a method for verifying update data of onboard communication comprising, when a center device transmits update data by a streaming manner to an electronic control unit installed in a vehicle, transferring a distribution package to the electronic control unit when a master device installed in the vehicle receives the update data as the distribution package, transmitting, by the center device, a hash value calculated for the update data to the master device, receiving, by the master device, a hash value for the update data calculated by the center device, obtaining, by the master device, a hash value for a whole update data by calculating a hash value for each predetermined data size for the update data, and verifying, by the master device, integrity of the update data by comparing the hash value with the hash value transmitted from the center device”.
The limitation of the claims 1, 7, 8, 13 and 18-20 of “the electronic control unit calculates a hash value for the update data,”(claim 1), “the master device calculates a hash value for each predetermined data size for the update data to obtain a hash value for a whole update data” (claim 7), “a hash value calculated for the update data to an electronic control unit installed in a vehicle” (claim 8), “a hash value calculated for the update data by the center device, the electronic control unit calculates a hash value for the update data”(claim 13), “the master device calculates a hash value for each predetermined data size for the update data to obtain a hash value for a whole update data,” (claim 18), “a hash value calculated for the update data to the master device“(claim 19) and “a hash value for the update data calculated by the center device” and “obtaining, by the master device, a hash value for a whole update data by calculating a hash value for each predetermined data size for the update data” (claim 20) as drafted, is a mathematical operation that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “calculating” in the context of this claim encompasses the user may calculate a hash value for the update data with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mathematical Operations” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
The limitation of the claims 1, 7, 13 and 18-20 of “the master device compares the hash value transmitted from the center device with the hash value transmitted from the electronic control unit to verify integrity of the update data” (claim 1), “compares the hash value with the hash value transmitted from the center device to verify integrity of the update data” (claim 7), “the master device compares the hash value transmitted from the center device with the hash value transmitted from the electronic control unit to verify integrity of the update data” (claim 13), “compares the hash value with the hash value transmitted from the center device to verify integrity of the update data” (claim 18), “verifying, by the master device, integrity of the update data by comparing the hash value transmitted from the center device with the hash value transmitted from the electronic control unit” (claim 19), and ” verifying, by the master device, integrity of the update data by comparing the hash value with the hash value transmitted from the center device” (claim 20) as drafted, is a mental process that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “comparing” in the context of this claim encompasses the user may compare the hash value transmitted from the center device with the hash value transmitted from the electronic control unit to verify integrity of the update data with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
This judicial exception is not integrated into a practical application. In particular, the claims 1, 7, 8 19 and 20 recite additional elements such as “a center device that is configured to transmit update data as a distribution package by a streaming manner to an electronic control unit installed in a vehicle”. “a center device that is configured to transmit update data as a distribution package by a streaming manner to an electronic control unit installed in a vehicle”, “a center device that transmits update data by a streaming manner to an electronic control unit installed in a vehicle”, “when a center device transmits update data by a streaming manner to an electronic control unit installed in a vehicle,” and “when a center device transmits update data by a streaming manner to an electronic control unit installed in a vehicle,”
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to mere data gathering under MPEP § 2106.05(g): Insignificant Extra-Solution Activity, which does not impose any meaningful limits on practicing the mental process (insignificant additional element). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2A Prong 2 and Step 2B.
This judicial exception is not integrated into a practical application. In particular, the claims 1, 7, 13, 18, 19 and 20 recite additional elements such as “a master device that is installed in the vehicle and is configured to receive the distribution package and transfer the update data to the electronic control unit”, “a master device that is configured to receive the distribution package and transfer the update data to the electronic control unit”, “a master device that is installed in a vehicle and is configured to receive a distribution package, which includes update data and is transmitted from a center device by a streaming manner;”, “a master device that is installed in a vehicle and is configured to receive update data transmitted by a streaming manner from a center device as a distribution package;”, “transferring distribution package to the electronic control unit when a master device installed in the vehicle receives the update data as the distribution package” and “transferring a distribution package to the electronic control unit when a master device installed in the vehicle receives the update data as the distribution package”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to mere data gathering under MPEP § 2106.05(g): Insignificant Extra-Solution Activity, which does not impose any meaningful limits on practicing the mental process (insignificant additional element). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2A Prong 2 and Step 2B.
This judicial exception is not integrated into a practical application. In particular, the claims 1, 4, 7, 11 and 13 and 18 recite additional elements such as “the electronic control unit that is configured to write the update data transferred from the master device to a storage unit”, “the master device transfers the update data to an electronic control unit supporting the storage manner”, “the electronic control unit that is configured to write the update data transferred from the master device to a storage unit”, “when the update data is transmitted by a storage manner for a part of the plurality of electronic control units; the center device transmits the update data”, “an electronic control unit that is installed in the vehicle and is configured to write the update data transferred from the master device to a storage portion” and “an electronic control unit that is installed in the vehicle and is configured to write the update data transferred from the master device to a storage portion”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to mere data storing under MPEP § 2106.05(g): Insignificant Extra-Solution Activity, which does not impose any meaningful limits on practicing the mental process (insignificant additional element). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2A Prong 2 and Step 2B.
This judicial exception is not integrated into a practical application. In particular, the claims 1, 7, 8, 11, 13, 18, 19 and 20 recite additional elements such as “wherein the center device also transmits a hash value calculated for the update data to the master device”, “wherein the center device also transmits a hash value calculated for the update data to the master device”, “the center device transmits the hash value calculated for the update data”, “a center device that transmits a hash value calculated for the update data to an electronic control unit installed in a vehicle”, “wherein the master device receives a hash value calculated for the update data and transmitted by the center device”, “wherein the center device transmits a hash value calculated for the update data to the master device”, “transmitting, by the center device, a hash value calculated for the update data to the master device”, and “transmitting, by the center device, a hash value calculated for the update data to the master device”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to mere data gathering under MPEP § 2106.05(g): Insignificant Extra-Solution Activity, which does not impose any meaningful limits on practicing the mental process (insignificant additional element). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2A Prong 2 and Step 2B.
This judicial exception is not integrated into a practical application. In particular, the claims 1, 13, 18, 19 and 20 recite additional elements such as “the electronic control unit transmits the hash value to the master device”, “the electronic control unit transmits the hash value to the master device”, “the master device receives a hash value calculated for the update data by the center device”, “transmitting, by the electronic control unit, a hash value calculated for the update data to the master device” and “receiving, by the master device, a hash value for the update data calculated by the center device”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to mere data gathering under MPEP § 2106.05(g): Insignificant Extra-Solution Activity, which does not impose any meaningful limits on practicing the mental process (insignificant additional element). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2A Prong 2 and Step 2B.
This judicial exception is not integrated into a practical application. In particular, the claims 2, 4, 8, 14 and 16 recite additional elements such as “wherein the center device transmits a plurality of hash values calculated for each update data to the master device when a plurality of update data is respectively written to a plurality of electronic control units, the master device transfers each of the update data to each of the electronic control units”, “when update data is transmitted to a part of the plurality of electronic control units in a storage manner, the center device transmits the update data and the hash value calculated for the update data to the master device”, “wherein when transmitting the update data to each of a plurality of electronic control units, the center device also transmits a plurality of hash values calculated for each update data” and “wherein when the center device transmits a plurality of update data to a plurality of electronic control units, the master device also receives a plurality of hash values calculated and transmitted for each of the update data and transfers each update data to each electronic control unit,”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to mere data gathering under MPEP § 2106.05(g): Insignificant Extra-Solution Activity, which does not impose any meaningful limits on practicing the mental process (insignificant additional element). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2A Prong 2 and Step 2B.
The limitation of the claims 2, 4, 14 and 16 of “each of the electronic control units calculates a hash value for the update data and transmits the hash value to the master device” and “the master device calculates a hash value for the update data” as drafted, is a mathematical operation that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “calculating” in the context of this claim encompasses the user may calculate a hash value for the update data with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mathematical Operations” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
The limitation of the claims 2, 4, 14 and 16 of “the master device compares each of the hash values transmitted from the electronic control units with the corresponding hash value transmitted from the center device” and “the master device compares the calculated hash value with the corresponding hash value transmitted from the center device to verify integrity of the update data, and when the integrity of the update data is verified” as drafted, is a mental process that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “comparing” in the context of this claim encompasses the user may compare the hash value transmitted from the center device with the hash value transmitted from the electronic control unit to verify integrity of the update data with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
This judicial exception is not integrated into a practical application. In particular, the claims 3, 10,
and 15 recite additional elements such as “wherein a hash value calculated for the plurality of hash values is defined as a high-order hash value, the center device also transmits the high-order hash value to the master device, and the master device calculates a high-order hash value for the hash values received from the electronic control units, and compares the calculated high-order hash value with the high-order hash value transmitted from the center device”, “wherein the hash value calculated for the plurality of hash values is defined as a high-order hash value, and the high-order hash value is also transmitted” and “wherein the master device also receives a hash value that is calculated and transmitted by the center device for the hash values as a high-order hash value, and when the master device calculates a high-order hash value for the plurality of hash values received from the plurality of electronic control units, the master device compares the calculated high-order hash value with the high-order hash value transmitted from the center device”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to field of use under MPEP § 2106.05(h): Field of Use and Technological Environment, which does not impose any meaningful limits on practicing the mental process. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea under Step 2A Prong 2 and 2B.
This judicial exception is not integrated into a practical application. In particular, the claims 5 and 12 recite additional elements such as “wherein the center device adds the hash value to download metadata including at least an address of a data acquisition destination, a data name, a data size, an ID of an electronic control unit to which the update data is distributed, and information of a data transfer manner, and transmits to the master device”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to field of use under MPEP § 2106.05(h): Field of Use and Technological Environment, which does not impose any meaningful limits on practicing the mental process. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea under Step 2A Prong 2 and 2B.
This judicial exception is not integrated into a practical application. In particular, the claims 6 and 17 recite additional elements such as “a portable information terminal capable of receiving the update data from the center device, wherein the master device is able to receive the update data via the portable information terminal”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to mere data gathering under MPEP § 2106.05(g): Insignificant Extra-Solution Activity, which does not impose any meaningful limits on practicing the mental process (insignificant additional element). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2A Prong 2 and Step 2B.
Dependent claims 2-6, 9-12 and 14-17 are also similar rejected under same rationale as cited above wherein these claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. These claims are merely further elaborate the mental process itself or providing additional definition of process which does not impose any meaningful limits on practicing the abstract idea. Claims 2-6, 9-12 and 14-17 are also rejected for incorporating the deficiency of their independent claims 1, 8 and 13 respectively.
Claim Rejections - 35 USC § 102
5. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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.
6. Claim 8 is rejected under 35 U.S.C. 102(a)(1) as being anticipated by Kiyama (US PGPub 20190163466).
As per Claim 8, Kiyama teaches of a center device that transmits update data by a streaming manner as well as a hash value calculated for the update data to an electronic control unit installed in a vehicle. (Par 206, “Note that, in the in-vehicle software distribution system 1 according to this embodiment, the hash value comparison processing performed in step S623 of FIG. 14 may also be carried out by software update apparatus 210 installed in the vehicle 20 instead of by the campaign management unit 112 of the telematics center 10 [center device]. In the foregoing case, in the processing performed in step S515 of FIG. 13, in transmitting the update software to the vehicle 20, the telematics center 10 [center device] transmits the update software together with the verification hash value 1247 that was registered in the update software test campaign.” Par 209, “As explained hereinabove, in the in-vehicle software distribution system 1 according to this embodiment, the telematics center 10 which is the in-vehicle software distribution server manages updates to an identical function by means of a campaign (main campaign) and distributes software based on the campaign remotely in target vehicles of the campaign.”)
Claim Rejections - 35 USC § 103
7. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
8. 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.
9. Claims 1, 6, 13, 17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Ishikawa (US PGPub 20220276853), in view of Kiyama (US PGPub 20190163466), and further in view of Murakami (US PGPub 20180145977).
As per Claim 1, Ishikawa teaches of an onboard communication system comprising: a center device that is configured to transmit update data as a distribution package by a streaming manner to an electronic control unit installed in a vehicle; (Fig. 1 and Par 9, The OTA master [master device] includes a communication unit configured to receive, from a center [center device], a distribution package including update data for the electronic control unit on which a first-kind non-volatile memory having one storage area is mounted and update data for the electronic control unit on which a second-kind non-volatile memory having two storage areas is mounted. Par 14, A center according to a second aspect of the present disclosure is configured to communicate with an OTA master that controls software update for an electronic control unit mounted on a vehicle. Par 42-43, The center 10 can communicate with an OTA master 30 included in the in-vehicle network 20 via a network 70, and can manage software update for the ECUs 40a to 40d connected to the OTA master 30. The OTA master 30 will be described below. The center 10 functions as a so-called server.)
a master device that is installed in the vehicle and is configured to receive the distribution package and transfer the update data to the electronic control unit; and (Fig. 1 and par 17, A system according to a third aspect of the present disclosure includes an OTA master configured to control software update for an electronic control unit mounted on a vehicle and a center [center device] configured to communicate with the OTA master [master device]. The center [center device] includes a communication unit configured to transmit, to the OTA master [master device], a distribution package including update data for the electronic control unit [ECU].)
the electronic control unit that is configured to write the update data transferred from the master device to a storage unit, (Par 14, Fig. 1 and Par 9, The OTA master includes a communication unit configured to receive, from a center, a distribution package including update data for the electronic control unit on which a first-kind non-volatile memory having one storage area [storage unit] is mounted and update data for the electronic control unit on which a second-kind non-volatile memory having two storage areas is mounted.)
Ishikawa does not specifically teach, however Kiyama teaches of wherein the center device also transmits a hash value calculated for the update data [to the master device], (Fig.1 and Par 202, The campaign management unit 112 then compares the extracted verification hash value 1247 [from telemetry center [center device] in par 47] with the hash value received from the vehicle 20 [ECU] in step S622 (step S623). Further, the campaign management unit 112 sends the result of the hash value comparison in step S623 to the vehicle 20 (step S624). Par 47, As mentioned earlier, the test campaign DB 124 stores, prior to the distribution campaign, ‘test campaign information’ which is configured from information required for a ‘test campaign’ that is carried out for a specific vehicle 20 which is limited to a test application.)
the electronic control unit calculates a hash value for the update data and transmits the hash value [to the master device], and (Par 211, Moreover, in the in-vehicle software distribution system 1 according to this embodiment, the hash value acquired from the update target ECU after the software installation in the test campaign is compared with the hash value acquired from the update target ECU after the software installation in the distribution campaign (step S623 in FIG. 14), and by determining that the distribution campaign has succeeded (a normal update software installation) when the two hash values match, the safety and reliability of the function update via the campaign can be improved. Par 155, At this time, the ECU software update unit 214 receives a hash value which is created by regarding the storage apparatus area of the ECU as one binary data in addition to update outcome information from the update target ECU)
[the master device] compares the hash value transmitted from the center device with the hash value transmitted from the electronic control unit to verify integrity of the update data. (Par 202, The campaign management unit 112 then compares the extracted verification hash value 1247 [from the center device] with the hash value received from the vehicle 20 [from ECUs in the vehicles] in step S622 (step S623). Further, the campaign management unit 112 sends the result of the hash value comparison in step S623 to the vehicle 20 (step S624). Par 203, Par 203, Furthermore, in the vehicle 20 which has received the hash value comparison result from the telematics center 10 [center device], the campaign confirmation unit 212 implements control of the vehicle 20 according to the comparison result (step S610). To explain this in detail, when the two hash values are the same value, this means that the distribution campaign update software has been installed normally in the same way as at the time of test campaign verification, and hence special control of the vehicle 20 is not implemented. On the other hand, when the two hash values are not the same value, this means that the distribution campaign update software has not been installed normally, and hence predetermined control which is decided beforehand for when installation fails is performed on the vehicle 20.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add wherein the center device also transmits a hash value calculated for the update data [to the master device], the electronic control unit calculates a hash value for the update data and transmits the hash value [to the master device], and [the master device] compares the hash value transmitted from the center device with the hash value transmitted from the electronic control unit to verify integrity of the update data, as conceptually seen from the teaching of Kiyama, into that of Ishikawa because this modification can help ensure the software update integrity and security by verifying for each ECU in vehicle.
Neither Ishikawa nor Kiyama specifically teaches, however Murakami teaches that the master device compares the hash value … with the hash value … (Par 116, In this case, the master processing unit 12 can compare the hash value of the authentication response_master from the slave unit 20 with the hash value of data, which can be obtained by coding the random number data R1 using the coding pattern Ki, to obtain the authentication determination. This also applies to other authentication determination (including the authentication determination on the slave processing unit 22 side).)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the master device comparing the hash value … with the hash value …, as conceptually seen from the teaching of Murakami, into that of Ishikawa and Kiyama because this modification can help verify the software update for ECUs in vehicles by providing a centralized, secure and efficient way for managing software updates on ECUs via the master device.
As per Claim 6, Ishikawa further teaches of the onboard communication system according to claim 1, further comprising: a portable information terminal capable of receiving the update data from the center device, wherein the master device is able to receive the update data via the portable information terminal. (Fig. 1 and Par 48, For example, the OTA master 30 may be connected to a display device (an HMI) used for executing various displays, such as a display representing that there is update data at the time of executing the software update processing of the ECUs 40a to 40d, a display of an approval request screen for requesting approval for the software update from a user or a manager of the vehicle, and a display of a result of the software update. For example, the above-described display device may be connected to the OTA master 30 via a bus other than the buses 60a to 60c. Par 4, As a technology for updating software of an electronic control unit, an over-the-air (OTA) technology is well-known. In the OTA technology, a device that wirelessly connects an in-vehicle communication device connected to an in-vehicle network to a communication network, such as the Internet, and executes software update processing of the vehicle updates or adds the software of the electronic control unit by downloading software from a server via wireless communication and installing the downloaded software on the electronic control unit.)
As per Claim 13, Ishikawa teaches of a vehicle-side system comprising: a master device that is installed in a vehicle and is configured to receive a distribution package, which includes update data and is transmitted from a center device by a streaming manner; and (Fig. 1 and Par 9, The OTA master [master device] includes a communication unit configured to receive, from a center [center device], a distribution package including update data for the electronic control unit on which a first-kind non-volatile memory having one storage area is mounted and update data for the electronic control unit on which a second-kind non-volatile memory having two storage areas is mounted. Par 14, A center according to a second aspect of the present disclosure is configured to communicate with an OTA master that controls software update for an electronic control unit mounted on a vehicle. par 17, A system according to a third aspect of the present disclosure includes an OTA master configured to control software update for an electronic control unit mounted on a vehicle and a center [center device] configured to communicate with the OTA master [master device]. The center [center device] includes a communication unit configured to transmit, to the OTA master [master device], a distribution package including update data for the electronic control unit [ECU].)
an electronic control unit that is installed in the vehicle and is configured to write the update data transferred from the master device to a storage portion, (Par 14, Fig. 1 and Par 9, The OTA master includes a communication unit configured to receive, from a center, a distribution package including update data for the electronic control unit on which a first-kind non-volatile memory having one storage area [storage unit] is mounted and update data for the electronic control unit on which a second-kind non-volatile memory having two storage areas is mounted.)
Ishikawa does not specifically teach, however Kiyama teaches of wherein [the master device] receives a hash value calculated for the update data and transmitted by the center device, (Fig.1 and Par 202, The campaign management unit 112 then compares the extracted verification hash value 1247 [from telemetry center [center device] in par 47] with the hash value received from the vehicle 20 [ECU] in step S622 (step S623). Further, the campaign management unit 112 sends the result of the hash value comparison in step S623 to the vehicle 20 (step S624). Par 47, As mentioned earlier, the test campaign DB 124 stores, prior to the distribution campaign, ‘test campaign information’ which is configured from information required for a ‘test campaign’ that is carried out for a specific vehicle 20 which is limited to a test application.)
the electronic control unit calculates a hash value for the update data and transmits the hash value [to the master device], and (Par 211, Moreover, in the in-vehicle software distribution system 1 according to this embodiment, the hash value acquired from the update target ECU after the software installation in the test campaign is compared with the hash value acquired from the update target ECU after the software installation in the distribution campaign (step S623 in FIG. 14), and by determining that the distribution campaign has succeeded (a normal update software installation) when the two hash values match, the safety and reliability of the function update via the campaign can be improved. Par 155, At this time, the ECU software update unit 214 receives a hash value which is created by regarding the storage apparatus area of the ECU as one binary data in addition to update outcome information from the update target ECU)
[the master device] compares the hash value transmitted from the center device with the hash value transmitted from the electronic control unit to verify integrity of the update data. (Par 202, The campaign management unit 112 then compares the extracted verification hash value 1247 [from the center device] with the hash value received from the vehicle 20 [from ECUs in the vehicles] in step S622 (step S623). Further, the campaign management unit 112 sends the result of the hash value comparison in step S623 to the vehicle 20 (step S624). Par 203, Par 203, Furthermore, in the vehicle 20 which has received the hash value comparison result from the telematics center 10 [center device], the campaign confirmation unit 212 implements control of the vehicle 20 according to the comparison result (step S610). To explain this in detail, when the two hash values are the same value, this means that the distribution campaign update software has been installed normally in the same way as at the time of test campaign verification, and hence special control of the vehicle 20 is not implemented. On the other hand, when the two hash values are not the same value, this means that the distribution campaign update software has not been installed normally, and hence predetermined control which is decided beforehand for when installation fails is performed on the vehicle 20.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add wherein [the master device] receives a hash value calculated for the update data and transmitted by the center device, the electronic control unit calculates a hash value for the update data and transmits the hash value [to the master device], and [the master device] compares the hash value transmitted from the center device with the hash value transmitted from the electronic control unit to verify integrity of the update data, as conceptually seen from the teaching of Kiyama, into that of Ishikawa because this modification can help ensure the software update integrity and security by verifying for each ECU in vehicle.
Neither Ishikawa nor Kiyama specifically teaches, however Murakami teaches that the master device compares the hash value … with the hash value … (Par 116, In this case, the master processing unit 12 can compare the hash value of the authentication response_master from the slave unit 20 with the hash value of data, which can be obtained by coding the random number data R1 using the coding pattern Ki, to obtain the authentication determination. This also applies to other authentication determination (including the authentication determination on the slave processing unit 22 side).)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the master device comparing the hash value … with the hash value …, as conceptually seen from the teaching of Murakami, into that of Ishikawa and Kiyama because this modification can help verify the software update for ECUs in vehicles by providing a centralized, secure and efficient way for managing software updates on ECUs via the master device.
As per Claim 17, Ishikawa further teaches of the vehicle-side system according to claim 13, further comprising: a portable information terminal capable of receiving the distribution package from the center device, wherein the master device is able to receive the distribution package from the center device via the portable information terminal. (Fig. 1 and Par 48, For example, the OTA master 30 may be connected to a display device (an HMI) used for executing various displays, such as a display representing that there is update data at the time of executing the software update processing of the ECUs 40a to 40d, a display of an approval request screen for requesting approval for the software update from a user or a manager of the vehicle, and a display of a result of the software update. For example, the above-described display device may be connected to the OTA master 30 via a bus other than the buses 60a to 60c. Par 4, As a technology for updating software of an electronic control unit, an over-the-air (OTA) technology is well-known. In the OTA technology, a device that wirelessly connects an in-vehicle communication device connected to an in-vehicle network to a communication network, such as the Internet, and executes software update processing of the vehicle updates or adds the software of the electronic control unit by downloading software from a server via wireless communication and installing the downloaded software on the electronic control unit.)
As per Claim 19, Ishikawa teaches of a method for verifying update data of onboard communication comprising: when a center device transmits update data by a streaming manner to an electronic control unit installed in a vehicle, transferring distribution package to the electronic control unit (Fig. 1 and Par 9, The OTA master [master device] includes a communication unit configured to receive, from a center [center device], a distribution package including update data for the electronic control unit on which a first-kind non-volatile memory having one storage area is mounted and update data for the electronic control unit on which a second-kind non-volatile memory having two storage areas is mounted. Par 14, A center according to a second aspect of the present disclosure is configured to communicate with an OTA master that controls software update for an electronic control unit mounted on a vehicle.)
when a master device installed in the vehicle receives the update data as the distribution package; (Fig. 1 and par 17, A system according to a third aspect of the present disclosure includes an OTA master configured to control software update for an electronic control unit mounted on a vehicle and a center [center device] configured to communicate with the OTA master [master device]. The center [center device] includes a communication unit configured to transmit, to the OTA master [master device], a distribution package including update data for the electronic control unit [ECU].)
Ishikawa does not specifically teach, however Kiyama teaches of transmitting, by the center device, a hash value calculated for the update data to [the master device], (Fig.1 and Par 202, The campaign management unit 112 then compares the extracted verification hash value 1247 [from telemetry center [center device] in par 47] with the hash value received from the vehicle 20 [ECU] in step S622 (step S623). Further, the campaign management unit 112 sends the result of the hash value comparison in step S623 to the vehicle 20 (step S624). Par 47, As mentioned earlier, the test campaign DB 124 stores, prior to the distribution campaign, ‘test campaign information’ which is configured from information required for a ‘test campaign’ that is carried out for a specific vehicle 20 which is limited to a test application.)
transmitting, by the electronic control unit, a hash value calculated for the update data to [the master device], and (Par 211, Moreover, in the in-vehicle software distribution system 1 according to this embodiment, the hash value acquired from the update target ECU after the software installation in the test campaign is compared with the hash value acquired from the update target ECU after the software installation in the distribution campaign (step S623 in FIG. 14), and by determining that the distribution campaign has succeeded (a normal update software installation) when the two hash values match, the safety and reliability of the function update via the campaign can be improved. Par 155, At this time, the ECU software update unit 214 receives a hash value which is created by regarding the storage apparatus area of the ECU as one binary data in addition to update outcome information from the update target ECU)
verifying, [by the master device], integrity of the update data by comparing the hash value transmitted from the center device with the hash value transmitted from the electronic control unit. (Par 202, The campaign management unit 112 then compares the extracted verification hash value 1247 [from the center device] with the hash value received from the vehicle 20 [from ECUs in the vehicles] in step S622 (step S623). Further, the campaign management unit 112 sends the result of the hash value comparison in step S623 to the vehicle 20 (step S624). Par 203, Par 203, Furthermore, in the vehicle 20 which has received the hash value comparison result from the telematics center 10 [center device], the campaign confirmation unit 212 implements control of the vehicle 20 according to the comparison result (step S610). To explain this in detail, when the two hash values are the same value, this means that the distribution campaign update software has been installed normally in the same way as at the time of test campaign verification, and hence special control of the vehicle 20 is not implemented. On the other hand, when the two hash values are not the same value, this means that the distribution campaign update software has not been installed normally, and hence predetermined control which is decided beforehand for when installation fails is performed on the vehicle 20.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add transmitting, by the center device, a hash value calculated for the update data to [the master device], transmitting, by the electronic control unit, a hash value calculated for the update data to [the master device], and verifying, [by the master device], integrity of the update data by comparing the hash value transmitted from the center device with the hash value transmitted from the electronic control unit, as conceptually seen from the teaching of Kiyama, into that of Ishikawa because this modification can help ensure the software update integrity and security by verifying for each ECU in vehicle.
Neither Ishikawa nor Kiyama specifically teaches, however Murakami teaches that the master device verifies by comparing integrity of the update data the hash value … with the hash value … (Par 116, In this case, the master processing unit 12 can compare the hash value of the authentication response_master from the slave unit 20 with the hash value of data, which can be obtained by coding the random number data R1 using the coding pattern Ki, to obtain the authentication determination. This also applies to other authentication determination (including the authentication determination on the slave processing unit 22 side).)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the master device comparing the hash value … with the hash value …, as conceptually seen from the teaching of Murakami, into that of Ishikawa and Kiyama because this modification can help verify the software update for ECUs in vehicles by providing a centralized, secure and efficient way for managing software updates on ECUs via the master device.
10. Claims 2, 4, 14 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Ishikawa (US PGPub 20220276853), in view of Kiyama (US PGPub 20190163466), in view of Murakami (US PGPub 20180145977), and further in view of Takahashi (US PGPub 20200204395).
As per Claim 2, Ishikawa does not specifically teach, however Kiyama teaches of the onboard communication system according to claim 1, wherein the center device transmits a plurality of hash values calculated for each update data to the master device when a plurality of update data is respectively written to a plurality of electronic control units, the master device transfers each of the update data to each of the electronic control units, (Par 142, At D25, the master device 11 sends the vehicle generated hash value together with the VIN to the center apparatus 3 via the wireless communications. Par 143, In response to the master device 11 sending the vehicle generated hash value, the VIN etc. to the center apparatus 3 at D25, the processes performed by the center computer 310 shown in FIG. 22A is started. Par 100, The integrity verification data includes a hash value obtained by applying a hash function to data values. When the whole data of the new program is used as the update data in place of the difference data, the integrity verification data for the update data may be the same as that for the new program. Par 107-108, The hash value generated by the center apparatus 3 (specifically, by the center computer 310) and registered in the individual vehicle information DB 213 is also referred to as a verification hash value in the present disclosure. The verification hash value can be generated, for example, as follows. The center computer 310 applies the registered ECU SWIDs associated with a respective VIN in the individual vehicle information DB 213 to a hash function.)
and [the master device] compares each of the hash values transmitted from the electronic control units with the corresponding hash value transmitted from the center device. (par 202, The campaign management unit 112 then compares the extracted verification hash value 1247 with the hash value received from the vehicle 20 in step S622 (step S623). Further, the campaign management unit 112 sends the result of the hash value comparison in step S623 to the vehicle 20 (step S624))
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add wherein the center device transmits a plurality of hash values calculated for each update data to the master device when a plurality of update data is respectively written to a plurality of electronic control units, the master device transfers each of the update data to each of the electronic control units and [the master device] compares each of the hash values transmitted from the electronic control units with the corresponding hash value transmitted from the center device, as conceptually seen from the teaching of Kiyama, into that of Ishikawa because this modification can help ensure the software update integrity and security by verifying for each ECU in vehicle.
Neither Ishikawa nor Kiyama specifically teaches, however Murakami teaches that the master device compares the hash value … with the hash value … (Par 116, In this case, the master processing unit 12 can compare the hash value of the authentication response_master from the slave unit 20 with the hash value of data, which can be obtained by coding the random number data R1 using the coding pattern Ki, to obtain the authentication determination. This also applies to other authentication determination (including the authentication determination on the slave processing unit 22 side).)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the master device comparing the hash value … with the hash value …, as conceptually seen from the teaching of Murakami, into that of Ishikawa and Kiyama because this modification can help verify the software update for ECUs in vehicles by providing a centralized, secure and efficient way for managing software updates on ECUs via the master device.
None of Ishikawa, Kiyama and Murakami specifically teaches, however Takahashi teaches of each of the electronic control units calculates a hash value for the update data and transmits the hash value to the master device (Par 8-9, By comparing this hash value with a hash value of a message transmitted from each ECU, an unauthorized ECU transmitting an unauthorized message is identified, and blocked from the in-vehicle network.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add each of the electronic control units calculates a hash value for the update data and transmits the hash value to the master device, as conceptually seen from the teaching of Takahashi, into that of Ishikawa, Kiyama and Murakami because this modification can help verify individual software update for each ECU in vehicle by providing software update data integrity and security.
As per Claim 4, Ishikawa does not specifically teach, however Kiyama teaches of the onboard communication system according to claim 2, wherein when update data is transmitted to a part of the plurality of electronic control units in a storage manner, the center device transmits the update data and (Abstract, An in-vehicle software distribution system 1 is configured comprising an in-vehicle software distribution server (telematics center 10) which manages updates to an identical function by means of a campaign for an in-vehicle system (an engine ECU 241, for example) of a plurality of vehicles 20 and distributes software of the campaign remotely to target vehicles, a terminal 30, and a software update apparatus 210 which is mounted in each of the plurality of vehicles 20. Furthermore, in the telematics center 10, a campaign management unit 112 categorizes the campaign target vehicles into groups based on a predetermined criterion and creates a plurality of sub-campaigns which are subordinate to the campaign for each of the categorized groups, and a software distribution unit (an update software distribution unit 113) distributes software remotely to the target vehicles for each of the sub-campaigns.)
the hash value calculated for the update data to [the master device], [the master device] calculates a hash value for the update data and compares the calculated hash value with the corresponding hash value transmitted from the center device to verify integrity of the update data, and when the integrity of the update data is verified, [the master device] transfers the update data to an electronic control unit supporting the storage manner. (Par 202, The campaign management unit 112 then compares the extracted verification hash value 1247 with the hash value received from the vehicle 20 in step S622 (step S623). Further, the campaign management unit 112 sends the result of the hash value comparison in step S623 to the vehicle 20 (step S624). Par 100, The verification hash value 1247 is information indicating the hash value acquired for the whole area of the storage apparatus after the vehicle 20 designated in the test campaign of the appropriate record (that is, the test vehicle specified by the test vehicle VIN 1243) has undergone an update target ECU software update.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add when update data is transmitted to a part of the plurality of electronic control units in a storage manner, the center device transmits the update data and the hash value calculated for the update data to [the master device], [the master device] calculates a hash value for the update data and compares the calculated hash value with the corresponding hash value transmitted from the center device to verify integrity of the update data, and when the integrity of the update data is verified, [the master device] transfers the update data to an electronic control unit supporting the storage manner, as conceptually seen from the teaching of Kiyama, into that of Ishikawa because this modification can help ensure the software update integrity and security by verifying for each ECU in vehicle.
Neither Ishikawa nor Kiyama specifically teaches, however Murakami teaches that the master device compares the hash value … with the hash value … (Par 116, In this case, the master processing unit 12 can compare the hash value of the authentication response_master from the slave unit 20 with the hash value of data, which can be obtained by coding the random number data R1 using the coding pattern Ki, to obtain the authentication determination. This also applies to other authentication determination (including the authentication determination on the slave processing unit 22 side).)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the master device comparing the hash value … with the hash value …, as conceptually seen from the teaching of Murakami, into that of Ishikawa and Kiyama because this modification can help verify the software update for ECUs in vehicles by providing a centralized, secure and efficient way for managing software updates on ECUs via the master device.
As per Claim 14, Ishikawa does not specifically teach, however Kiyama teaches of the vehicle-side system according to claim 13, wherein when the center device transmits a plurality of update data to a plurality of electronic control units, the master device also receives a plurality of hash values calculated and transmitted for each of the update data and transfers each update data to each electronic control unit and (Par 142, At D25, the master device 11 sends the vehicle generated hash value together with the VIN to the center apparatus 3 via the wireless communications. Par 143, In response to the master device 11 sending the vehicle generated hash value, the VIN etc. to the center apparatus 3 at D25, the processes performed by the center computer 310 shown in FIG. 22A is started. Par 100, The integrity verification data includes a hash value obtained by applying a hash function to data values. When the whole data of the new program is used as the update data in place of the difference data, the integrity verification data for the update data may be the same as that for the new program. Par 107-108, The hash value generated by the center apparatus 3 (specifically, by the center computer 310) and registered in the individual vehicle information DB 213 is also referred to as a verification hash value in the present disclosure. The verification hash value can be generated, for example, as follows. The center computer 310 applies the registered ECU SWIDs associated with a respective VIN in the individual vehicle information DB 213 to a hash function.)
[the master device] compares the hash values transmitted from the plurality of electronic control units with the corresponding hash values transmitted from the center device. (par 202, The campaign management unit 112 then compares the extracted verification hash value 1247 with the hash value received from the vehicle 20 in step S622 (step S623). Further, the campaign management unit 112 sends the result of the hash value comparison in step S623 to the vehicle 20 (step S624))
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add when the center device transmits a plurality of update data to a plurality of electronic control units, the master device also receives a plurality of hash values calculated and transmitted for each of the update data and transfers each update data to each electronic control unit and transmits the hash value to the master device, and the master device] compares the hash values transmitted from the plurality of electronic control units with the corresponding hash values transmitted from the center device, as conceptually seen from the teaching of Kiyama, into that of Ishikawa because this modification can help ensure the software update integrity and security by verifying for each ECU in vehicle.
Neither Ishikawa nor Kiyama specifically teaches, however Murakami teaches that the master device compares the hash value … with the hash value … (Par 116, In this case, the master processing unit 12 can compare the hash value of the authentication response_master from the slave unit 20 with the hash value of data, which can be obtained by coding the random number data R1 using the coding pattern Ki, to obtain the authentication determination. This also applies to other authentication determination (including the authentication determination on the slave processing unit 22 side).)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the master device comparing the hash value … with the hash value …, as conceptually seen from the teaching of Murakami, into that of Ishikawa and Kiyama because this modification can help verify the software update for ECUs in vehicles by providing a centralized, secure and efficient way for managing software updates on ECUs via the master device.
None of Ishikawa, Kiyama and Murakami specifically teaches, however Takahashi teaches of each of the electronic control units calculates a hash value for the update data and transmits the hash value to [the master device] (Par 8-9, By comparing this hash value with a hash value of a message transmitted from each ECU, an unauthorized ECU transmitting an unauthorized message is identified, and blocked from the in-vehicle network.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add each of the electronic control units calculates a hash value for the update data and transmits the hash value to the master device, as conceptually seen from the teaching of Takahashi, into that of Ishikawa, Kiyama and Murakami because this modification can help verify individual software update for each ECU in vehicle by providing software update data integrity and security.
As per Claim 16, Ishikawa does not specifically teach, however Kiyama teaches of the vehicle-side system according to claim 14, wherein when the center device transmits a distribution package including the update data for a part of the plurality of electronic control units in a storage manner, (Abstract, An in-vehicle software distribution system 1 is configured comprising an in-vehicle software distribution server (telematics center 10) which manages updates to an identical function by means of a campaign for an in-vehicle system (an engine ECU 241, for example) of a plurality of vehicles 20 and distributes software of the campaign remotely to target vehicles, a terminal 30, and a software update apparatus 210 which is mounted in each of the plurality of vehicles 20. Furthermore, in the telematics center 10, a campaign management unit 112 categorizes the campaign target vehicles into groups based on a predetermined criterion and creates a plurality of sub-campaigns which are subordinate to the campaign for each of the categorized groups, and a software distribution unit (an update software distribution unit 113) distributes software remotely to the target vehicles for each of the sub-campaigns.)
[the master device] receives the update data and a hash value calculated for the update data, (Par 206, Note that, in the in-vehicle software distribution system 1 according to this embodiment, the hash value comparison processing performed in step S623 of FIG. 14 may also be carried out by software update apparatus 210 installed in the vehicle 20 instead of by the campaign management unit 112 of the telematics center 10 [center device]. In the foregoing case, in the processing performed in step S515 of FIG. 13, in transmitting the update software to the vehicle 20, the telematics center 10 [center device] transmits the update software together with the verification hash value 1247 that was registered in the update software test campaign.)
[the master device] calculates a hash value for the update data and compares the calculated hash value with the corresponding hash value transmitted from the center device to verify integrity of the update data, and when the integrity of the update data is verified, [the master device] transfers the update data to an electronic control unit supporting the storage manner. (Par 202, The campaign management unit 112 then compares the extracted verification hash value 1247 with the hash value received from the vehicle 20 in step S622 (step S623). Further, the campaign management unit 112 sends the result of the hash value comparison in step S623 to the vehicle 20 (step S624). Par 100, The verification hash value 1247 is information indicating the hash value acquired for the whole area of the storage apparatus after the vehicle 20 designated in the test campaign of the appropriate record (that is, the test vehicle specified by the test vehicle VIN 1243) has undergone an update target ECU software update.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add when the center device transmits a distribution package including the update data for a part of the plurality of electronic control units in a storage manner, [the master device] receives the update data and a hash value calculated for the update data, [the master device] calculates a hash value for the update data and compares the calculated hash value with the corresponding hash value transmitted from the center device to verify integrity of the update data, and when the integrity of the update data is verified, [the master device] transfers the update data to an electronic control unit supporting the storage manner, as conceptually seen from the teaching of Kiyama, into that of Ishikawa because this modification can help ensure the software update integrity and security by verifying for each ECU in vehicle.
None of Ishikawa, Kiyama and Takahashi specifically teaches, however Murakami teaches that the master device calculates and compares the hash value … with the hash value … (Par 116, In this case, the master processing unit 12 can compare the hash value of the authentication response_master from the slave unit 20 with the hash value of data, which can be obtained by coding the random number data R1 using the coding pattern Ki, to obtain the authentication determination. This also applies to other authentication determination (including the authentication determination on the slave processing unit 22 side).)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the master device comparing the hash value … with the hash value …, as conceptually seen from the teaching of Murakami, into that of Ishikawa, Kiyama and Takahashi because this modification can help verify the software update for ECUs in vehicles by providing a centralized, secure and efficient way for managing software updates on ECUs via the master device.
11. Claims 3 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Ishikawa (US PGPub 20220276853), in view of Kiyama (US PGPub 20190163466), in view of Murakami (US PGPub 20180145977), in view of Takahashi (US PGPub 20200204395), and further in view of Houdek (US Patent 4903194).
As per Claim 3, none of Ishikawa, Kiyama, Murakami and Takahashi specifically teaches, however Houdek teaches of the onboard communication system according to claim 2, wherein a hash value calculated for the plurality of hash values is defined as a high-order hash value, the center device also transmits the high-order hash value to the master device, and the master device calculates a high-order hash value for the hash values received from the electronic control units, and compares the calculated high-order hash value with the high-order hash value transmitted from the center device. (Col 6, lines 1-14, The I/O hash bits from the I/O generate logic 26 are compared with the high order hash bits in the address register 20 by compare logic 27 which for example can be logical and circuits. If the generated hash bits do not compare with the hash bits from the address register 20, an error condition exists and a signal noting that condition is sent to the I/O unit over line 28. This indicates to the IOP that the address sent for the data transfer was invalid. Consequently the data transfer operation is ended. Note that the hash bits by this arrangement not only are used for detecting a boundary crossing error, but enable detection of a WRITE to a READ only area in storage as a storage addressing error.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add wherein a hash value calculated for the plurality of hash values is defined as a high-order hash value, the center device also transmits the high-order hash value to the master device, and the master device calculates a high-order hash value for the hash values received from the electronic control units, and compares the calculated high-order hash value with the high-order hash value transmitted from the center device, as conceptually seen from the teaching of Houdek, into that of Ishikawa, Kiyama, Murakami and Takahashi because this modification can help provide superior security and data integrity by enabling faster verification and detection of unauthorized tampering.
As per Claim 15, none of Ishikawa, Kiyama, Murakami and Takahashi specifically teaches, however Houdek teaches of the vehicle-side system according to claim 14, wherein the master device also receives a hash value that is calculated and transmitted by the center device for the hash values as a high-order hash value, and when the master device calculates a high-order hash value for the plurality of hash values received from the plurality of electronic control units, the master device compares the calculated high-order hash value with the high-order hash value transmitted from the center device. (Col 6, lines 1-14, The I/O hash bits from the I/O generate logic 26 are compared with the high order hash bits in the address register 20 by compare logic 27 which for example can be logical and circuits. If the generated hash bits do not compare with the hash bits from the address register 20, an error condition exists and a signal noting that condition is sent to the I/O unit over line 28. This indicates to the IOP that the address sent for the data transfer was invalid. Consequently the data transfer operation is ended. Note that the hash bits by this arrangement not only are used for detecting a boundary crossing error, but enable detection of a WRITE to a READ only area in storage as a storage addressing error.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add wherein the master device also receives a hash value that is calculated and transmitted by the center device for the hash values as a high-order hash value, and when the master device calculates a high-order hash value for the plurality of hash values received from the plurality of electronic control units, the master device compares the calculated high-order hash value with the high-order hash value transmitted from the center device, as conceptually seen from the teaching of Takahashi, into that of Ishikawa, Kiyama and Murakami because this modification can help provide superior security and data integrity by enabling faster verification and detection of unauthorized tampering.
12. Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Ishikawa (US PGPub 20220276853), in view of Kiyama (US PGPub 20190163466), in view of Murakami (US PGPub 20180145977), and further in view of Rivas Silva (US PGPub 20180196660).
As per Claim 5, none of Ishikawa, Kiyama and Murakami specifically teaches, however Rivas Silva teaches of the onboard communication system according to claim 1, wherein the center device adds the hash value to download metadata including at least an address of a data acquisition destination, a data name, a data size, an ID of an electronic control unit to which the update data is distributed, and information of a data transfer manner, and transmits to the master device. (Par 44, in general, the system for the reprogramming of ECU devices (Electronic Control Units) in vehicles via digital radio, in accordance with the present invention, consists of: means for encrypting audio files with software files for updating or reprogramming ECUs of vehicles generating a first encrypted packet and means to encrypt in parallel files of data and vehicle information files by adding a header with the data referring to the vehicle model (data of the Original Equipment Manufacturer (OEM), model of the vehicle, vehicle year, vehicle platform [obviously including destination address], ECU identification data (ID), data packet size, software file key, end of file data) and the specific ECU that will be the final recipient of the information, generating a second encrypted packet; means for mixing said first encrypted packet and said second packet encrypted via digital radio technology to be transmitted simultaneously from a radio broadcasting station in digital format. Par 46 and 48, In the preferred embodiment of the invention, the data files with vehicle information files adding a header with data referring to the vehicle model and the specific ECU that will be the final recipient of the information, contain an identification key, data from the original equipment manufacturer (OEM), vehicle model, year of the vehicle, vehicle platform, ECU identification (ID) data, data packet size; key of the software file, end of file data, which make up data packets that are mixed with the audio files.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the center device adds the hash value to download metadata including at least an address of a data acquisition destination, a data name, a data size, an ID of an electronic control unit to which the update data is distributed, and information of a data transfer manner, and transmits to the master device, as conceptually seen from the teaching of Rivas Silva, into that of Ishikawa, Kiyama and Murakami because this modification can help verify the software update for the specific ECUs in vehicles by utilizing more specific metadata for the software update data and the target ECUs.
13. Claims 7, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ishikawa (US PGPub 20220276853), in view of Kiyama (US PGPub 20190163466), in view of Hong (US PGPub 20200183677), and further in view of Murakami (US PGPub 20180145977).
As per Claim 7, Ishikawa teaches of an onboard communication system comprising: a center device that is configured to transmit update data as a distribution package by a streaming manner to an electronic control unit installed in a vehicle; (Fig. 1 and Par 9, The OTA master [master device] includes a communication unit configured to receive, from a center [center device], a distribution package including update data for the electronic control unit on which a first-kind non-volatile memory having one storage area is mounted and update data for the electronic control unit on which a second-kind non-volatile memory having two storage areas is mounted. Par 14, A center according to a second aspect of the present disclosure is configured to communicate with an OTA master that controls software update for an electronic control unit mounted on a vehicle.)
a master device that is configured to receive the distribution package and transfer the update data to the electronic control unit; and (Fig. 1 and par 17, A system according to a third aspect of the present disclosure includes an OTA master configured to control software update for an electronic control unit mounted on a vehicle and a center [center device] configured to communicate with the OTA master [master device]. The center [center device] includes a communication unit configured to transmit, to the OTA master [master device], a distribution package including update data for the electronic control unit [ECU].)
the electronic control unit that is configured to write the update data transferred from the master device to a storage unit, (Par 14, Fig. 1 and Par 9, The OTA master includes a communication unit configured to receive, from a center, a distribution package including update data for the electronic control unit on which a first-kind non-volatile memory having one storage area [storage unit] is mounted and update data for the electronic control unit on which a second-kind non-volatile memory having two storage areas is mounted.)
Ishikawa does not specifically teach, however Kiyama teaches of wherein the center device also transmits a hash value calculated for the update data to [the master device], and (Fig.1 and Par 202, The campaign management unit 112 then compares the extracted verification hash value 1247 [from telemetry center [center device] in par 47] with the hash value received from the vehicle 20 [ECU] in step S622 (step S623). Further, the campaign management unit 112 sends the result of the hash value comparison in step S623 to the vehicle 20 (step S624). Par 47, As mentioned earlier, the test campaign DB 124 stores, prior to the distribution campaign, ‘test campaign information’ which is configured from information required for a ‘test campaign’ that is carried out for a specific vehicle 20 which is limited to a test application.)
compares the hash value with the hash value transmitted from the center device to verify integrity of the update data. (Par 202, The campaign management unit 112 then compares the extracted verification hash value 1247 [from the center device] with the hash value received from the vehicle 20 [from ECUs in the vehicles] in step S622 (step S623). Further, the campaign management unit 112 sends the result of the hash value comparison in step S623 to the vehicle 20 (step S624).)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add wherein the center device also transmits a hash value calculated for the update data to [the master device], and compares the hash value with the hash value transmitted from the center device to verify integrity of the update data, as conceptually seen from the teaching of Kiyama, into that of Ishikawa because this modification can help ensure the software update integrity and security by verifying for each ECU in vehicle.
Neither Ishikawa nor Kiyama specifically teaches, however Hong teaches [the master device] calculates a hash value for each predetermined data size for the update data to obtain a hash value for a whole update data, and (Par 143, Referring to FIGS. 7 and 13, a verification step (S40) may be performed using a hash function. The hash function may be of one of a variety of types, and the standard size of data calculated by a particular hash function may be determined. For example, if the standard size of data calculated by the particular hash function is 32 bytes, the predetermined hash function may calculate a hash value by dividing data into 32-byte segments. In embodiments herein, writing the boot code to the backup boot ROM area may be performed in units of segments such as the 32-byte segments. Writing the boot code to the backup boot ROM area in units of the segments may be performed fully or partly simultaneously with calculating the hash value of the boot code by dividing the boot code into the segments of the standard size of data calculated by the hash function. In other words, the writing and calculating may both be performed in a single process such as at S40, without other process functions described herein intervening.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add calculating a hash value for each predetermined data size for the update data to obtain a hash value for a whole update data, as conceptually seen from the teaching of Hong, into that of Ishikawa and Kiyama because this modification can help optimize the software update verification and integrity for ECUs in vehicles by enabling the detection of corruption in individual and smaller segments of the software update data.
None of Ishikawa, Kiyama and Hong specifically teaches, however Murakami teaches that the master device calculates and compares the hash value … with the hash value … (Par 116, In this case, the master processing unit 12 can compare the hash value of the authentication response_master from the slave unit 20 with the hash value of data, which can be obtained by coding the random number data R1 using the coding pattern Ki, to obtain the authentication determination. This also applies to other authentication determination (including the authentication determination on the slave processing unit 22 side).)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the master device comparing the hash value … with the hash value …, as conceptually seen from the teaching of Murakami, into that of Ishikawa, Kiyama and Hong because this modification can help verify the software update for ECUs in vehicles by providing a centralized, secure and efficient way for managing software updates on ECUs via the master device.
As per Claim 18, Ishikawa teaches of a vehicle-side system comprising: a master device that is installed in a vehicle and is configured to receive update data transmitted by a streaming manner from a center device as a distribution package; and (Fig. 1 and Par 9, The OTA master [master device] includes a communication unit configured to receive, from a center [center device], a distribution package including update data for the electronic control unit on which a first-kind non-volatile memory having one storage area is mounted and update data for the electronic control unit on which a second-kind non-volatile memory having two storage areas is mounted. Par 14, A center according to a second aspect of the present disclosure is configured to communicate with an OTA master that controls software update for an electronic control unit mounted on a vehicle. par 17, A system according to a third aspect of the present disclosure includes an OTA master configured to control software update for an electronic control unit mounted on a vehicle and a center [center device] configured to communicate with the OTA master [master device]. The center [center device] includes a communication unit configured to transmit, to the OTA master [master device], a distribution package including update data for the electronic control unit [ECU].)
an electronic control unit that is installed in the vehicle and is configured to write the update data transferred from the master device to a storage portion, (Par 14, Fig. 1 and Par 9, The OTA master includes a communication unit configured to receive, from a center, a distribution package including update data for the electronic control unit on which a first-kind non-volatile memory having one storage area [storage unit] is mounted and update data for the electronic control unit on which a second-kind non-volatile memory having two storage areas is mounted.)
Ishikawa does not specifically teach, however Kiyama teaches of wherein the center device transmits a hash value calculated for the update data to [the master device], and (Fig.1 and Par 202, The campaign management unit 112 then compares the extracted verification hash value 1247 [from telemetry center [center device] in par 47] with the hash value received from the vehicle 20 [ECU] in step S622 (step S623). Further, the campaign management unit 112 sends the result of the hash value comparison in step S623 to the vehicle 20 (step S624). Par 47, As mentioned earlier, the test campaign DB 124 stores, prior to the distribution campaign, ‘test campaign information’ which is configured from information required for a ‘test campaign’ that is carried out for a specific vehicle 20 which is limited to a test application.)
[the master device] receives a hash value calculated for the update data by the center device, (Par 211, Moreover, in the in-vehicle software distribution system 1 according to this embodiment, the hash value acquired from the update target ECU after the software installation in the test campaign is compared with the hash value acquired from the update target ECU after the software installation in the distribution campaign (step S623 in FIG. 14), and by determining that the distribution campaign has succeeded (a normal update software installation) when the two hash values match, the safety and reliability of the function update via the campaign can be improved. Par 155, At this time, the ECU software update unit 214 receives a hash value which is created by regarding the storage apparatus area of the ECU as one binary data in addition to update outcome information from the update target ECU)
compares the hash value with the hash value transmitted from the center device to verify integrity of the update data. (Par 202, The campaign management unit 112 then compares the extracted verification hash value 1247 [from the center device] with the hash value received from the vehicle 20 [from ECUs in the vehicles] in step S622 (step S623). Further, the campaign management unit 112 sends the result of the hash value comparison in step S623 to the vehicle 20 (step S624). Par 203, Par 203, Furthermore, in the vehicle 20 which has received the hash value comparison result from the telematics center 10 [center device], the campaign confirmation unit 212 implements control of the vehicle 20 according to the comparison result (step S610). To explain this in detail, when the two hash values are the same value, this means that the distribution campaign update software has been installed normally in the same way as at the time of test campaign verification, and hence special control of the vehicle 20 is not implemented. On the other hand, when the two hash values are not the same value, this means that the distribution campaign update software has not been installed normally, and hence predetermined control which is decided beforehand for when installation fails is performed on the vehicle 20.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add wherein the center device transmits a hash value calculated for the update data to [the master device], and [the master device] receives a hash value calculated for the update data by the center device, compares the hash value with the hash value transmitted from the center device to verify integrity of the update data, as conceptually seen from the teaching of Kiyama, into that of Ishikawa because this modification can help ensure the software update integrity and security by verifying for each ECU in vehicle.
Neither Kiyama nor Ishikawa specifically teaches, however Hong teaches calculates a hash value for each predetermined data size for the update data to obtain a hash value for a whole update data, and (Par 143, Referring to FIGS. 7 and 13, a verification step (S40) may be performed using a hash function. The hash function may be of one of a variety of types, and the standard size of data calculated by a particular hash function may be determined. For example, if the standard size of data calculated by the particular hash function is 32 bytes, the predetermined hash function may calculate a hash value by dividing data into 32-byte segments. In embodiments herein, writing the boot code to the backup boot ROM area may be performed in units of segments such as the 32-byte segments. Writing the boot code to the backup boot ROM area in units of the segments may be performed fully or partly simultaneously with calculating the hash value of the boot code by dividing the boot code into the segments of the standard size of data calculated by the hash function. In other words, the writing and calculating may both be performed in a single process such as at S40, without other process functions described herein intervening.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add calculating a hash value for each predetermined data size for the update data to obtain a hash value for a whole update data, as conceptually seen from the teaching of Hong, into that of Ishikawa and Kiyama because this modification can help optimize the software update verification and integrity for ECUs in vehicles by enabling the detection of corruption in individual and smaller segments of the software update data.
None of Ishikawa, Kiyama and Hong specifically teaches, however Murakami teaches that the master device calculates and compares the hash value … with the hash value … (Par 116, In this case, the master processing unit 12 can compare the hash value of the authentication response_master from the slave unit 20 with the hash value of data, which can be obtained by coding the random number data R1 using the coding pattern Ki, to obtain the authentication determination. This also applies to other authentication determination (including the authentication determination on the slave processing unit 22 side).)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the master device comparing the hash value … with the hash value …, as conceptually seen from the teaching of Murakami, into that of Ishikawa, Kiyama and Hong because this modification can help verify the software update for ECUs in vehicles by providing a centralized, secure and efficient way for managing software updates on ECUs via the master device.
As per Claim 20, Ishikawa teaches of a method for verifying update data of onboard communication comprising, when a center device transmits update data by a streaming manner to an electronic control unit installed in a vehicle, transferring a distribution package to the electronic control unit (Fig. 1 and Par 9, The OTA master [master device] includes a communication unit configured to receive, from a center [center device], a distribution package including update data for the electronic control unit on which a first-kind non-volatile memory having one storage area is mounted and update data for the electronic control unit on which a second-kind non-volatile memory having two storage areas is mounted. Par 14, A center according to a second aspect of the present disclosure is configured to communicate with an OTA master that controls software update for an electronic control unit mounted on a vehicle.)
when a master device installed in the vehicle receives the update data as the distribution package, (Fig. 1 and par 17, A system according to a third aspect of the present disclosure includes an OTA master configured to control software update for an electronic control unit mounted on a vehicle and a center [center device] configured to communicate with the OTA master [master device]. The center [center device] includes a communication unit configured to transmit, to the OTA master [master device], a distribution package including update data for the electronic control unit [ECU].)
Ishikawa does not specifically teach, however Kiyama teaches of transmitting, by the center device, a hash value calculated for the update data to [the master device], (Fig.1 and Par 202, The campaign management unit 112 then compares the extracted verification hash value 1247 [from telemetry center [center device] in par 47] with the hash value received from the vehicle 20 [ECU] in step S622 (step S623). Further, the campaign management unit 112 sends the result of the hash value comparison in step S623 to the vehicle 20 (step S624). Par 47, As mentioned earlier, the test campaign DB 124 stores, prior to the distribution campaign, ‘test campaign information’ which is configured from information required for a ‘test campaign’ that is carried out for a specific vehicle 20 which is limited to a test application.)
receiving, [by the master device], a hash value for the update data calculated by the center device, (Par 211, Moreover, in the in-vehicle software distribution system 1 according to this embodiment, the hash value acquired from the update target ECU after the software installation in the test campaign is compared with the hash value acquired from the update target ECU after the software installation in the distribution campaign (step S623 in FIG. 14), and by determining that the distribution campaign has succeeded (a normal update software installation) when the two hash values match, the safety and reliability of the function update via the campaign can be improved. Par 155, At this time, the ECU software update unit 214 receives a hash value which is created by regarding the storage apparatus area of the ECU as one binary data in addition to update outcome information from the update target ECU)
verifying, [by the master device], integrity of the update data by comparing the hash value with the hash value transmitted from the center device. (Par 202, The campaign management unit 112 then compares the extracted verification hash value 1247 [from the center device] with the hash value received from the vehicle 20 [from ECUs in the vehicles] in step S622 (step S623). Further, the campaign management unit 112 sends the result of the hash value comparison in step S623 to the vehicle 20 (step S624). Par 203, Par 203, Furthermore, in the vehicle 20 which has received the hash value comparison result from the telematics center 10 [center device], the campaign confirmation unit 212 implements control of the vehicle 20 according to the comparison result (step S610). To explain this in detail, when the two hash values are the same value, this means that the distribution campaign update software has been installed normally in the same way as at the time of test campaign verification, and hence special control of the vehicle 20 is not implemented. On the other hand, when the two hash values are not the same value, this means that the distribution campaign update software has not been installed normally, and hence predetermined control which is decided beforehand for when installation fails is performed on the vehicle 20.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add transmitting, by the center device, a hash value calculated for the update data to [the master device],receiving, [by the master device], a hash value for the update data calculated by the center device, verifying, [by the master device], integrity of the update data by comparing the hash value with the hash value transmitted from the center device, as conceptually seen from the teaching of Kiyama, into that of Ishikawa because this modification can help ensure the software update integrity and security by verifying for each ECU in vehicle.
Neither Ishikawa nor Kiyama specifically teaches, however Hong teaches of obtaining, [by the master device], a hash value for a whole update data by calculating a hash value for each predetermined data size for the update data, and (Par 143, Referring to FIGS. 7 and 13, a verification step (S40) may be performed using a hash function. The hash function may be of one of a variety of types, and the standard size of data calculated by a particular hash function may be determined. For example, if the standard size of data calculated by the particular hash function is 32 bytes, the predetermined hash function may calculate a hash value by dividing data into 32-byte segments. In embodiments herein, writing the boot code to the backup boot ROM area may be performed in units of segments such as the 32-byte segments. Writing the boot code to the backup boot ROM area in units of the segments may be performed fully or partly simultaneously with calculating the hash value of the boot code by dividing the boot code into the segments of the standard size of data calculated by the hash function. In other words, the writing and calculating may both be performed in a single process such as at S40, without other process functions described herein intervening.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add calculating a hash value for each predetermined data size for the update data to obtain a hash value for a whole update data, as conceptually seen from the teaching of Hong, into that of Ishikawa and Kiyama because this modification can help optimize the software update verification and integrity for ECUs in vehicles by enabling the detection of corruption in individual and smaller segments of the software update data.
None of Ishikawa, Kiyama and Hong specifically teaches, however Murakami teaches that the master device calculates and compares the hash value … with the hash value … (Par 116, In this case, the master processing unit 12 can compare the hash value of the authentication response_master from the slave unit 20 with the hash value of data, which can be obtained by coding the random number data R1 using the coding pattern Ki, to obtain the authentication determination. This also applies to other authentication determination (including the authentication determination on the slave processing unit 22 side).)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the master device comparing the hash value … with the hash value …, as conceptually seen from the teaching of Murakami, into that of Ishikawa, Kiyama and Hong because this modification can help verify the software update for ECUs in vehicles by providing a centralized, secure and efficient way for managing software updates on ECUs via the master device.
14. Claims 9 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Kiyama (US PGPub 20190163466), in view of Ishikawa (US PGPub 20220276853), in view of and further in view of Takahashi (US PGPub 20200204395).
As per Claim 9, Kiyama does not specifically teaches, however Ishikawa teaches of the center device according to claim 8, wherein when transmitting the update data to each of a plurality of electronic control units, (Par 41-43, FIG. 1 is a block diagram illustrating an overall configuration of a network system according to an embodiment of the present disclosure. The network system illustrated in FIG. 1 is used for updating software of a plurality of ECUs 40a to 40d mounted on a vehicle, and includes a center 10 outside the vehicle and an in-vehicle network 20 constructed inside the vehicle.)
Neither Kiyama nor Ishikawa specifically teaches, however Takahashi teaches the center device also transmits a plurality of hash values calculated for each update data. (Par 8-9, By comparing this hash value with a hash value of a message transmitted from each ECU, an unauthorized ECU transmitting an unauthorized message is identified, and blocked from the in-vehicle network.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the center device also transmits a plurality of hash values calculated for each update data, as conceptually seen from the teaching of Takahashi, into that of Kiyama and Ishikawa because this modification can help verify individual software update for each ECU in vehicle by providing software update data integrity and security.
As per Claim 11, Kiyama further teaches of the center device according to claim 9, wherein when the update data is transmitted by a storage manner for a part of the plurality of electronic control units, the center device transmits the update data and the hash value calculated for the update data. (Abstract, An in-vehicle software distribution system 1 is configured comprising an in-vehicle software distribution server (telematics center 10) which manages updates to an identical function by means of a campaign for an in-vehicle system (an engine ECU 241, for example) of a plurality of vehicles 20 and distributes software of the campaign remotely to target vehicles, a terminal 30, and a software update apparatus 210 which is mounted in each of the plurality of vehicles 20. Furthermore, in the telematics center 10, a campaign management unit 112 categorizes the campaign target vehicles into groups based on a predetermined criterion and creates a plurality of sub-campaigns which are subordinate to the campaign for each of the categorized groups, and a software distribution unit (an update software distribution unit 113) distributes software remotely to the target vehicles for each of the sub-campaigns. Par 206, Note that, in the in-vehicle software distribution system 1 according to this embodiment, the hash value comparison processing performed in step S623 of FIG. 14 may also be carried out by software update apparatus 210 installed in the vehicle 20 instead of by the campaign management unit 112 of the telematics center 10 [center device]. In the foregoing case, in the processing performed in step S515 of FIG. 13, in transmitting the update software to the vehicle 20, the telematics center 10 [center device] transmits the update software together with the verification hash value 1247 that was registered in the update software test campaign.)
15. Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Kiyama (US PGPub 20190163466), in view of Ishikawa (US PGPub 20220276853), in view of Takahashi (US PGPub 20200204395), and further in view of Houdek (US Patent 4903194).
As per Claim 10, none of Kiyama, Ishikawa and Takahashi specifically teaches, however Houdek teaches of the center device according to claim 9, wherein the hash value calculated for the plurality of hash values is defined as a high-order hash value, and the high-order hash value is also transmitted. (Col 6, lines 1-14, The I/O hash bits from the I/O generate logic 26 are compared with the high order hash bits in the address register 20 by compare logic 27 which for example can be logical and circuits. If the generated hash bits do not compare with the hash bits from the address register 20, an error condition exists and a signal noting that condition is sent to the I/O unit over line 28. This indicates to the IOP that the address sent for the data transfer was invalid. Consequently the data transfer operation is ended. Note that the hash bits by this arrangement not only are used for detecting a boundary crossing error, but enable detection of a WRITE to a READ only area in storage as a storage addressing error.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the hash value calculated for the plurality of hash values is defined as a high-order hash value, and the high-order hash value is also transmitted, as conceptually seen from the teaching of Houdek, into that of Kiyama, Ishikawa and Takahashi because this modification can help provide superior security and data integrity by enabling faster verification and detection of unauthorized tampering.
16. Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Kiyama (US PGPub 20190163466), in view of Rivas Silva (US PGPub 20180196660).
As per Claim 12, Kiyama does not specifically teach, however Rivas Silva teaches of the center device according to claim 8, wherein the center device adds a hash value to at least an address of a data acquisition destination, a data name, a data size, an ID of an electronic control unit to which the update data is distributed, and information of a data transfer manner and transmit them. (Par 44, in general, the system for the reprogramming of ECU devices (Electronic Control Units) in vehicles via digital radio, in accordance with the present invention, consists of: means for encrypting audio files with software files for updating or reprogramming ECUs of vehicles generating a first encrypted packet and means to encrypt in parallel files of data and vehicle information files by adding a header with the data referring to the vehicle model (data of the Original Equipment Manufacturer (OEM), model of the vehicle, vehicle year, vehicle platform [obviously including destination address], ECU identification data (ID), data packet size, software file key, end of file data) and the specific ECU that will be the final recipient of the information, generating a second encrypted packet; means for mixing said first encrypted packet and said second packet encrypted via digital radio technology to be transmitted simultaneously from a radio broadcasting station in digital format. Par 46 and 48, In the preferred embodiment of the invention, the data files with vehicle information files adding a header with data referring to the vehicle model and the specific ECU that will be the final recipient of the information, contain an identification key, data from the original equipment manufacturer (OEM), vehicle model, year of the vehicle, vehicle platform, ECU identification (ID) data, data packet size; key of the software file, end of file data, which make up data packets that are mixed with the audio files.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the center device adds the hash value to download metadata including at least an address of a data acquisition destination, a data name, a data size, an ID of an electronic control unit to which the update data is distributed, and information of a data transfer manner, and transmits to the master device, as conceptually seen from the teaching of Rivas Silva, into that of Kiyama because this modification can help verify the software update for the specific ECUs in vehicles by utilizing more specific metadata for the software update data and the target ECUs.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAE UK JEON whose telephone number is (571)270-3649. The examiner can normally be reached 9am-6pm. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chat Do can be reached on 571-272-3721. 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.
/JAE U JEON/Primary Examiner, Art Unit 2193