DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-8, 10-17 and 19 are pending in this application.
Claims 1 and 11 are currently amended.
Claims 9 and 18 are cancelled.
No new IDS was filed.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/02/2026 has been entered.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-8 and 10 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1-8 and 10 are drafted in means plus function naming elements such as “a communication device configured to...” in line 3 of claim 1 which was not properly described in the specification. See the 11(b) rejection below for details.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-8, 10-17 and 19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 1 and 11, recites “wherein the verification data corresponds to integrity information of the software loaded in the vehicle controller”. It is unclear whether “the verification data” refers to the “first verification data” or “second verification data”; Correction of the antecedent basis and/or clarification is required.
Claims 2-8, 10, 12-17 and 19 inherit the indefiniteness since these claims are dependent from claims 1 and 11.
Regarding claims 1, it is noted that the claim elements “a communication device configured to ...” in line 3 is a limitation that invoke 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for the claimed function. Specifically, each limitation that invokes 35 U.S.C. 112, sixth paragraph must be clearly described in terms of specific hardware structures and computer algorithms, however, applicant's specification only discloses such features in a general form of black boxes (e.g., Fig. 6, [0066], [0069]; the description does not offer enough details but merely repeat in similar words of the claim language).
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112, sixth paragraph; or
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the claimed function without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01 (o) and 2181.
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 dependent claims 2-9 included in the statement of rejection but not specifically addressed in the body of the rejection have inherited the deficiencies of their parent claim and have not resolved the deficiencies. Therefore, they are rejected based on the same rationale as applied to their parent claims above.
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.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 10-13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kanno et al. (US 2014/0074316 A1) (hereinafter, “Kanno”) in view of Mondello et al. (US 2020/0314096 A1) (hereinafter, “Mondello”).
As to claim 1, Kanno discloses an apparatus of verifying a software integrity of a vehicle controller, the apparatus comprising: a communication device configured to perform receive first verification data by performing communication with a software management system (“… a data update system 1 includes a data processing device 2 to be used by a manufacturer of a vehicle, and an electronic control unit 3 mounted on the vehicle. The data processing device 2 can be provided at a car dealer or the like.” -e.g., see, [0017]; see also: “First, the data processing device 2 in the manufacturer and the electronic control unit 3 are connected so that data communication becomes possible.” -e.g., see, [0022], and Fig. 1, numerical 3; herein, dealer/manufacturer data processing device 2 is the claimed apparatus. Its connection to the manufacturer side hash store and to ECU 3 is the communication device receiving first verification data from the management side source and communicating with the vehicle controller); and
a controller configured to obtain the first verification data of the vehicle controller from the software management system, to obtain second verification data from the vehicle controller, and to verify an integrity of software loaded in the vehicle controller based on the obtained first verification data and the obtained second verification data (“The data processing device 2 can be functionally divided into a control-data storage unit 11 that records control data including a control program and a control value, a hash-code output unit 12 that generates a hash code including unique data defining the control data, a hash-code storage unit 13 that stores therein the hash code, and a hash-code comparison unit 14 that compares a plurality of hash codes.” -e.g., see, [0018]; see also: “The hash-code output unit 12 uses a so-called "hash algorithm", for example, such a hash algorithm that creates a hash code including integer values and alphabets from a binary code, and the hash code is a unique code that is in one-to-one correspondence to the corresponding control data. The hash-code comparison unit 14 compares first storage data 41 including a hash code stored at the manufacturer side with data of a hash code stored in the onboard electronic control unit of the vehicle, to judge whether the both hash codes match each other.” -e.g., see, [0019]; herein, comparison unit 14 and the processor of device 2 are the claimed controller. First storage data 41 is first verification data obtained from the manufacturer side management store. The ECU side hash is second verification data obtained from the vehicle controller. The match judgement is verification of integrity of the loaded software),
wherein, the first verification data is generated based on firmware of program forming the software loaded in the vehicle controller as verification target data (“The hash-code output unit 12 generates a hash code from the binary code of the control program by using the hash algorithm prepared beforehand. A data amount of the hash code is much smaller than that of the control program itself, and the hash code is uniquely generated with respect to each control program. The hash code generated in this manner is stored in the hash-code storage unit 13 as the first storage data 41. When there is a hash code already stored therein, the hash-code storage unit 13 adds the new hash code after the existing hash code without replacing the existing hash code by the new hash code, to create and store the first storage data 41.” -e.g., see, [0023]; herein, the binary control program written into the ECU is the firmware of the program forming the loaded software (i.e. verification target). The manufacturer side hash generated from the binary is first verification data generated based on the firmware), and
wherein the verification data corresponds to integrity information of the software loaded in the vehicle controller (“… the hash code is a unique code that is in one-to-one correspondence to the corresponding control data. The hash-code comparison unit 14 compares first storage data 41 including a hash code stored at the manufacturer side with data of a hash code stored in the onboard electronic control unit of the vehicle, to judge whether the both hash codes match each other.” -e.g., see, [0019]; see also: “The hash-code output unit 12 in the manufacturer and the hash-code generation unit 31 on a vehicle use the same hash algorithm as described above. Accordingly, the first storage data 41 stored in the hash-code storage unit 13 in the manufacturer and the second storage data 42 stored in the hash-code recording unit 32 on a vehicle have the same contents if there is no falsification or the like. Because newer hash codes are sequentially added and stored, the number of hash codes to be stored and an arrangement order are the same between the first storage data 41 and the second storage data 42.” -e.g., see, [0031]; herein, The hashes are integrity information of the loaded control program/software; identity means no falsification),
wherein, the second verification data is determined by the vehicle controller …. when verifying the integrity of the software loaded in the vehicle controller (“The storage unit 21 transmits a binary code of the new control program to the hash-code generation unit 31 of the CPU 22. The hash-code generation unit 31 generates a hash code from the binary code of the new control program by using the hash algorithm same as the hash algorithm used by the hash-code output unit 12 of the data processing device 2. The generated hash code is stored in the hash-code recording unit 32 as the second storage data 42.” -e.g., see, [0030]; see also: “… if the electronic control unit 3 is appropriately used, the first storage data 41 and the second storage data 42 are the same. That is, when the hash-code comparison unit 14 compares the two pieces of storage data 41 and 42 with each other, the both pieces of data match each other.” -e.g., see, [0031]; herein, the vehicle controller (ECU CPU/hash-code generation unit 31) determines the second hash from the loaded program; device 2 uses that second hash to verify integrity information of the loaded software), and
wherein the second verification data is used to verify the integrity information corresponding to the software loaded in the vehicle controller (: “… if the electronic control unit 3 is appropriately used, the first storage data 41 and the second storage data 42 are the same. That is, when the hash-code comparison unit 14 compares the two pieces of storage data 41 and 42 with each other, the both pieces of data match each other.” -e.g., see, [0031]; herein, the vehicle controller (ECU CPU/hash-code generation unit 31) determines the second hash from the loaded program; device 2 uses that second hash to verify integrity information of the loaded software).
Kanno does not explicitly disclose that the second verification data is determined by the vehicle controller based on a secure flash library or a crypto library by the vehicle controller.
However, in an analogous art, Mondello discloses the second verification data is determined by the vehicle controller based on a secure flash library or a crypto library by the vehicle controller (“Circuitry 210 can generate a run-time cryptographic hash 241 for validating (e.g., authenticating and/or attesting) an electronic control unit (e.g., electronic control unit 347 in FIG. 3) of a vehicle (e.g., vehicle 351 in FIG. 3).” -e.g., see, [0043]; see also: “The run-time cryptographic hash 241 of the data stored in memory array 201 can be generated (e.g., calculated), for example, by circuitry 210. In such an example, the run-time cryptographic hash 241 of the data stored can be internally generated by memory device 206 without having external data moving on interface 204. As an additional example, the run-time cryptographic hash 241 of the data can be communicated from an external entity. For instance, host 202 can generate the run-time cryptographic hash 241 of the data stored in memory array 201 and send the generated run-time cryptographic hash 241 to memory device 206 (e.g., circuitry 210 can receive the run-time cryptographic hash 241 of the data stored in memory array 201 from host 202)” -e.g., see, [0045]; see also: “The run-time cryptographic hash 241 of the data, including the ID number 245, stored in memory array 201 can comprise, for instance, a SHA-256 cryptographic hash. Further, the run-time cryptographic hash 241 of the data stored in memory array 201 can comprise 256 bytes of data.” -e.g., see, [0044]; herein, On ECU memory circuitry that internally computes a SHA-265 cryptographic hash over data stored in the memory array is a crypto library/secure flash implementation. Using that mechanism as Kanno’s ECU side hash-code generation unit 31 is determination of the second verification data based on a secure flash library or a crypto library).
Mondello further teaches using that runtime hash as integrity information compared to a stored reference (“a run-time cryptographic hash 241 can be generated (e.g., calculated) and compared with the golden hash 243. If the comparison indicates the run-time cryptographic hash 241 and golden hash 243 match (e.g., equal), it can be determined that the ID number 245 is valid (e.g., valid 369 in FIG. 3), and therefore the electronic control unit (e.g., electronic control unit 347 in FIG. 3) is authentic.” -e.g., see, [0052]; herein, confirms the second (runtime) cryptographic value is used to verify integrity information corresponding to the vehicle controller’s stored data/software);
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of invention to modify the teaching of Kanno with Mondello in order to harden the second verification data against aftermarket rewrite; Thus, providing adequate data security of the verification data which can’t be altered easily.
As to claim 11, it is rejected using the similar rationale as for the rejection of claim 1.
As to claim 2, Kanno in view of Mondello discloses the apparatus of claim 1, Kanno further discloses wherein the controller is configured to determine that the software loaded in the vehicle controller has the integrity, when the controller concludes that the obtained first verification data and the obtained second verification data are identical to each other (“if the electronic control unit 3 is appropriately used, the first storage data 41 and the second storage data 42 are the same. That is, when the hash-code comparison unit 14 compares the two pieces of storage data 41 and 42 with each other, the both pieces of data match each other.” -e.g., see, [0031]).
As to claim 12, it is rejected using the similar rationale as for the rejection of claim 2.
As to claim 3, Kanno in view of Mondello discloses the apparatus of claim 1, Kanno further discloses wherein the controller is configured to obtain a plurality of verification data corresponding to the vehicle controller from the software management system, to compare whether the plurality of verification data obtained from the software management system and a plurality of verification data obtained from the vehicle controller are identical to each other when the plurality of verification data is obtained from the vehicle controller, and to determine that the software loaded in the vehicle controller has the integrity when the controller concludes that the verification data are identical to each other (“A data amount of the hash code is much smaller than that of the control program itself, and the hash code is uniquely generated with respect to each control program. The hash code generated in this manner is stored in the hash-code storage unit 13 as the first storage data 41. When there is a hash code already stored therein, the hash-code storage unit 13 adds the new hash code after the existing hash code without replacing the existing hash code by the new hash code, to create and store the first storage data 41.” -e.g., see, [0023]; see also: “For example, when data writing has been performed twice with respect to the electronic control unit 3 before the current data update, the hash-code storage unit 13 has already stored and includes two hash codes in the first storage data 41 before the current update in order of write. The two existing hash codes are assumed here as "5ec8eee62e66457b" and "41f2d2da5d83ecf6", for example. When the hash-code output unit 12 generates a new hash code "7aa0371ff93d0144" in association with data update this time, this new hash code is added after the two existing hash codes, and these three hash codes are stored as the first storage data 41.” -e.g., se, [0024]; see also: “Because newer hash codes are sequentially added and stored, the number of hash codes to be stored and an arrangement order are the same between the first storage data 41 and the second storage data 42. Accordingly, if the electronic control unit 3 is appropriately used, the first storage data 41 and the second storage data 42 are the same. That is, when the hash-code comparison unit 14 compares the two pieces of storage data 41 and 42 with each other, the both pieces of data match each other.” -e.g., see, [0031]).
As to claim 13, it is rejected using the similar rationale as for the rejection of claim 3.
As to claim 10, Kanno in view of Mondello discloses the apparatus of claim 1, Kanno further discloses wherein the second verification data is one of a Secure Hash Algorithm (SHA)-1 value, a SHA-2 value, a Cyclic Redundancy Check (CRC) 16 value, or a CRC 32 value (“A writable/readable memory is used for the control-data storage unit 11 and the hash-code storage unit 13. The hash-code output unit 12 uses a so-called "hash algorithm", for example, such a hash algorithm that creates a hash code including integer values and alphabets from a binary code, and the hash code is a unique code that is in one-to-one correspondence to the corresponding control data.” -e.g., see, [0019]; see also: “The hash-code generation unit 31 generates a hash code from the binary code of the new control program by using the hash algorithm same as the hash algorithm used by the hash-code output unit 12 of the data processing device 2. The generated hash code is stored in the hash-code recording unit 32 as the second storage data 42. When there is a hash code already stored, the hash-code recording unit 32 adds the new hash code after the existing hash code without replacing the existing hash code by the new hash code, to create and store the second storage data 42.” -e.g., see, [0030]).
As to claim 19, it is rejected using the similar rationale as for the rejection of claim 10.
Claims 4-8 and 14-17 are rejected under 35 U.S.C. 103 as being unpatentable over Kanno in view of Mondell as applied to claims 1 and 11 above, and further in view of Cho et al. (US 2020/0057630 A1) (hereinafter, “Cho”).
As to claim 4, Kanno in view of Mondello discloses the apparatus of claim 1, Kanno further discloses wherein the software management system is configured to … forming the software loaded in the vehicle controller (“The data processing device 2 can be functionally divided into a control-data storage unit 11 that records control data including a control program and a control value, a hash-code output unit 12 that generates a hash code including unique data defining the control data, a hash-code storage unit 13 that stores therein the hash code,… “ -e.g., see, [0018]; see also: “The hash-code output unit 12 generates a hash code from the binary code of the control program by using the hash algorithm prepared beforehand. A data amount of the hash code is much smaller than that of the control program itself, and the hash code is uniquely generated with respect to each control program. The hash code generated in this manner is stored in the hash-code storage unit 13 as the first storage data 41. When there is a hash code already stored therein, the hash-code storage unit 13 adds the new hash code after the existing hash code without replacing the existing hash code by the new hash code, to create and store the first storage data 41.” -e.g., see, [0023]).
Kanno in view of Mondello doesn’t explicitly disclose manage a software package and version information and verification data of the software package for respective program.
However, in an analogous art, Cho discloses the software management system is configured to manage a software package and version information and verification data of the software package for respective program forming the software loaded in the vehicle controller (“The update server 10 collects state information of the software module from the vehicles and distributes the software update module to the vehicles. The update server 10 may operate in conjunction with a log database that stores software state information of each vehicle to manage the software state of the vehicle. “ -e.g., see, [0033]; see also: “… deviceid Device ID defined by a car maufacturer/supplier. hwversion Version of this hardware module. Module — Container of module information, which contains a hash element. moduleid Module ID is a unique ID provided by a car manufacturer/ supplier. version Version of this software module. nextversion The version of the module update in progress, which is mainly used for sending a response message during an update. Hash — Hash is a container of a hash value and information of its hash algorithm. algorithm Algorithm of the hash function (e.g., SHA-3, SHA-256, etc.).” -e.g., see, [0068]; herein, update server 10 is the software management system which manages for respective programs forming ECU software, the update package, version/nexversion and hash verification data of the package).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of invention to modify the teaching of Kanno and Mondell with the additional teaching of Cho in order to provide enable the secure and cost-effective deployment of emergency security patches, bug fixes, and feature updates over the lifespan of the vehicle while maintain the integrity of the provided software.
As to claim 5, Kanno in view of Mondello and Cho discloses the apparatus of claim 4, Cho further discloses wherein the vehicle controller is configured to perform a firmware update based on the software package received from the software management system (“… the update server sends the VMG an update_check response message that includes data, e.g., URLs from which the update module can be downloaded (STEP 8).” -e.g., see, [0048]; see also: “… the VMG may access the relevant URL to download the update module (STEP 9).” -e.g., see, [0049]; see also: “… he VMG may send the update files to the corresponding ECUs and request to apply the update (STEP 12).” -e.g., see, [0052]; see also: “… each ECU in receipt of the update module file applies the update and sends the application result to the VMG (STEP 13).” -e.g., see, [0053]; see also: “… the processor 1610 may obtain information regarding an update type (e.g., full update, partial update, delta update, etc.) of the update package from the update_check response message received from the update server, and it may provide the target ECU with an indicator indicating the update type together with the downloaded update package, so that the target ECU is able to perform updates in a corresponding manner to the update type.” -e.g., see, [0125]; herein, Vehicle controller applies the update package downloaded from the update server (software management system). That is a firmware update based on the software package received from the software management system).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of invention to modify the teaching of Kanno and Mondell with the additional teaching of Cho in order to provide enable the secure and cost-effective deployment of emergency security patches, bug fixes, and feature updates over the lifespan of the vehicle while maintain the integrity of the provided software.
As to claim 14, it is rejected using the similar rationale as for the rejection of claims 4 and 5.
As to claim 6, Kanno in view of Mondello and Cho discloses the apparatus of claim 5, Mondello further discloses wherein the vehicle controller is configured to determine verification data based on the software package when a vehicle is started on (IGN ON) (“The process 361 of validating the electronic control unit 347 can begin in response to a powering (e.g., a powering on and/or powering up) of memory device (e.g., memory device 206 in FIG. 2), the electronic control unit 347, and/or the vehicle 351. As such, a validation of the electronic control unit 347 can be initiated (e.g., automatically) upon the powering of the memory device, the electronic control unit 347, and/or the vehicle 351.” -e.g., see, [0062]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of invention to modify the teaching of Kanno with Mondello in order to harden the second verification data against aftermarket rewrite; Thus, providing adequate data security of the verification data which can’t be altered easily.
Kanno in view of Mondello doesn’t explicitly disclose transmission of the verification data upon request from the controller.
Cho further discloses transmission of the verification data upon request from the controller (“The VMG sends a diagnostic request message to each of the electronic control units (ECUs) connected to it to submit a software list (STEP 2).” -e.g., see, [0042]; see also: “In response to the diagnostic request message, each ECU checks the software status, generates a software module list and sends it to the VMG via a diagnostic report message (STEP 3).” -e.g., see, [0043]; herein, Cho teaches software state/verification data upon request from the higher level controller).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of invention to modify the teaching of Kanno and Mondell with the additional teaching of Cho in order to provide enable the secure and cost-effective deployment of emergency security patches, bug fixes, and feature updates over the lifespan of the vehicle while maintain the integrity of the provided software.
As to claim 15, it is rejected using the similar rationale as for the rejection of claim 6.
As to claim 7, Kanno in view of Mondello and Cho discloses the apparatus of claim 5, Cho further discloses wherein the vehicle controller is configured to determine verification data based on the software package upon request from the controller, and to transmit the determined verification data to the controller (“The VMG sends a diagnostic request message to each of the electronic control units (ECUs) connected to it to submit a software list (STEP 2).” -e.g., see, [0042]; see also: “In response to the diagnostic request message, each ECU checks the software status, generates a software module list and sends it to the VMG via a diagnostic report message (STEP 3).” -e.g., see, [0043]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of invention to modify the teaching of Kanno and Mondell with the additional teaching of Cho in order to provide enable the secure and cost-effective deployment of emergency security patches, bug fixes, and feature updates over the lifespan of the vehicle while maintain the integrity of the provided software.
As to claim 16, it is rejected using the similar rationale as for the rejection of claim 7.
As to claim 8, Kanno in view of Mondello and Cho discloses the apparatus of claim 7, Chao further discloses wherein the vehicle controller is configured to transmit the determined verification data to the controller when an additional request is received from the controller, without determining additionally the verification data when a vehicle is started on (IGN ON) (“… when the update of the software module is successfully performed, the VMG may store the RXSWIN obtained from the update_check response message in the VMG itself or in another electronic control system (e.g., an electronic control system to which the corresponding software module is applied), so that the RXSWIN can be read from outside the vehicle later through an OBD port, or the like, and that it can be protected from unauthorized modifications.” -e.g., see, Chao: [0103]; herein, stored verification/identification data is transmitted later upon an additional external/diagnostic request without recomputing it; Mondello discloses transmitting verification data when a vehicle is stared on (IGN ON); e.g., see, claim 6 above for further explanation).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of invention to modify the teaching of Kanno and Mondell with the additional teaching of Cho in order to provide enable the secure and cost-effective deployment of emergency security patches, bug fixes, and feature updates over the lifespan of the vehicle while maintain the integrity of the provided software.
As to claim 17, it is rejected using the similar rationale as for the rejection of claim 8.
Response to Arguments/Amendments
Applicant’s arguments with respect to claims 1 and 11 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Examiner would like to point out that no explanation was provided for 35 USC 112 second rejection. Applicant needed to provide an adequate explanation on what structure of “a communication device …” would perform “receive first verification data by performing communication with a software management system”; merely amending with “performing communication” doesn’t provide structure of “a communication device configured to …”. Examiner concluded that the previous 112(a) and 112(b) rejections to claims 1-8 and 10 are maintained.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SUMAN DEBNATH whose telephone number is (571)270-1256. The examiner can normally be reached Mon-Fri; 9:00am-5:00pm.
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, Farid Homayounmehr can be reached at 571-272-3739. 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.
SUMAN DEBNATH
Patent Examiner
Art Unit 2495
/S.D/ Examiner, Art Unit 2495
/FARID HOMAYOUNMEHR/ Supervisory Patent Examiner, Art Unit 2495
Prosecution Insights