Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
2. This office action has been issued in response to amendment filed on 12/17/2025. Claims 1-3 have been amended. Claims 1-3 are pending in this Office Action. Accordingly, this action has been made FINAL.
Response to Argument
3. Claims 1-3 have been amended to overcome claim objections. Therefore, claims objections for claims 1-3 have been withdrawn.
Claims 1-3 have been amended to overcome 112(b) rejection. Therefore, the 112(b) rejection for claims 1-3 has been withdrawn.
Applicant's arguments with respect to claims 1-3 have been considered but are moot in view of the new ground(s) of rejection.
Status of Claims
4. Claims 1-3 are pending, of which claims, of which claim 1, 2 and 3 are in independent form.
The Office's Note:
5. The Office has cited particular paragraphs / columns and line numbers in the reference(s) applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim(s), other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the cited passages as taught by the prior art or relied upon by the Examiner.
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.
6. Claims 1-3 are rejected under 35 U.S.C. 103 as being unpatentable over Cardillo (US 20240053974– hereinafter Cardillo), in view of Aleksandrov(US 20160266885– hereinafter Aleksandrov), Imadali (US 20150215274 – hereinafter Imadali) and further in view of Ingraham (US 20200057872 – hereinafter Ingraham).
Claim 1 is rejected, Cardillo teaches a computer-implemented method in an automotive server for securely updating computer configuration files of a specific automobile type and a specific automobile, the method comprising (Cardillo, abstract and summary):
storing configuration files and updates to configuration files from automobile manufacturer (Cardillo, US 20240053974, fig. 1, Update Server – component 121, packages – component 127. Para [0020-0021], FIG. 1 shows an illustrative example of an ECU update and audit system. In this example, an update server 121 residing remotely from the vehicle 100 (e.g., in the cloud 120), receives various vehicle updates to be delivered for certain ECUs on certain vehicles. As an update is to be distributed, the server selects a vehicle for receipt of the update based on either a request from the vehicle or a correlation of the vehicle (e.g., make, model, etc.) to parameters specified in association with the update. Para [0021], a configurator process 123 accesses a list of VINs 129 associated with vehicles, including target vehicle 100. This data may include, for example, ESNs of all ECUs installed on the given vehicle 100, as well as currently installed software/firmware versions, etc. The configurator can calculate a hash using a hashing function known to the server 121 and vehicle 100. The hash 125 may use the VIN or other unique vehicle identifier, so that when the vehicle 100 receives the package, it can calculate a hash using the same function and its own VIN, to ensure the package was intended for that vehicle by comparison of the received hashed value with the onboard calculated value. The hash may also include secure configuration data, which can be retrieved from the package and used in the onboard hash for comparison purposes. That way, if the secure configuration data was altered in transit, the hash will not match. Para [0025-0026].);
storing certificates for each individual automobile generated from a unique vehicle identification number (VIN) number portion of a specific automobile along with an Internet Protocol associated with the specific automobile (Cardillo, para [0021], a configurator process 123 accesses a list of VINs 129 associated with vehicles, including target vehicle 100. This data may include, for example, ESNs of all ECUs installed on the given vehicle 100, as well as currently installed software/firmware versions, etc. The configurator can calculate a hash using a hashing function known to the server 121 and vehicle 100. The hash 125 may use the VIN or other unique vehicle identifier, so that when the vehicle 100 receives the package, it can calculate a hash using the same function and its own VIN, to ensure the package was intended for that vehicle by comparison of the received hashed value with the onboard calculated value. The hash may also include secure configuration data, which can be retrieved from the package and used in the onboard hash for comparison purposes. That way, if the secure configuration data was altered in transit, the hash will not match. Para [0025-0026].);
receiving, in real-time over the data communication network, a request to check for updated configuration files for a specific automobile and a specific automobile type(Cardillo, para [0020-0021], FIG. 1 shows an illustrative example of an ECU update and audit system. In this example, an update server 121 residing remotely from the vehicle 100 (e.g., in the cloud 120), receives various vehicle updates to be delivered for certain ECUs on certain vehicles. As an update is to be distributed, the server selects a vehicle for receipt of the update based on either a request from the vehicle or a correlation of the vehicle (e.g., make, model, etc.) to parameters specified in association with the update. Para [0025-0026], FIG. 2a shows an illustrative process for update packaging. In this example, Even if the VIN and ECU are included in the request, the server may use any local data to validate that the ECU ESN included in a request corresponds to the VIN included in a request to prevent creating a package for an ECU that has been improperly moved to a new vehicle and simply relying on the combination of VIN and ESN identified in a request from that vehicle to build the security check.);
if update, generating a signature using the certificate from the unique VIN number portion and the stored configuration file for encrypting the stored configuration file (Cardillo, fig. 2A and para [0025-0026], The server 121 then configures the update package at 207, which can include a payload, signature, header file, ECU ESN, hash of the VIN and secure configuration data determined at 209, timestamp, etc. The server 121 can then transmit the data at 211. Para [0027], FIG. 2b shows an illustrative update server. This server has access to, for example, VIN data or other unique vehicle identifiers 221 and the secure configuration data 223 associated with a given deliverable. Those two values can be used in the hash 225, which creates a value usable for immediate and future (via audit) verification. A timestamp 227 can be appended which creates assurances that an older update (replayed or late-delivered) will not be used to replace a newer-installed update. This information can then be combined into the package, which may include the actual secure configuration value and a secure signature 231.); and
transmitting signature and stored configuration file to the specific automobile for local configuration update(Cardillo, fig. 2A and para [0025-0026], The server 121 then configures the update package at 207, which can include a payload, signature, header file, ECU ESN, hash of the VIN and secure configuration data determined at 209, timestamp, etc. The server 121 can then transmit the data at 211.).
Cardillo does not explicitly teach
comparing a hash value of received request against a hash value such of the stored configuration file to check for an update;
However, Aleksandrov teaches
comparing a hash value of received request against a hash value such of the stored configuration file to check for an update (Aleksandrov, US 20160266885, para [0023], Intelligent mobile application update program 200 receives a checksum associated with mobile application 112. A checksum is the outcome of running an algorithm, referred to as a cryptographic hash function, on a piece of data, usually a single file, such as mobile application 112. The resulting checksum is a small sized datum generated for the purpose of error checking (i.e., comparison of the checksum for two files verifies whether the two files are the same). Intelligent mobile application update program 200 receives the network type associated with network 130 that mobile computing device 110 connects to (e.g., WPAN, 3G, 4G, etc.). Additionally, intelligent mobile application update program 200 receives information pertaining to the security features set on mobile computing device 110 (e.g., security bit set to true or false). Para [0024-0025], In decision 204, intelligent mobile application update program 200 determines whether the checksum associated with mobile application 112 is the same as the checksum associated with server version update application 122. Intelligent mobile application update program 200 compares the received checksum associated with mobile application 112 with the stored checksum associated with server version update application 122. If intelligent mobile application update program 200 determines the checksums are the same (decision 204, yes branch), then intelligent mobile application update program 200 completes. If intelligent mobile application update program 200 determines the checksums are different (decision 204, no branch), then intelligent mobile application update program 200 determines an update package for update policy 124 (step 206) and initiates creation of update policy 124. For example, mobile application 112 is the factory installed application software, and server version update application 122 is a new version that includes updates and a critical fix. The checksum for mobile application 112 is not the same as the checksum for server version update application 122, indicating mobile application 112 is not the latest version of the application software. In another embodiment, intelligent mobile application update program 200 may determine whether mobile application 112 is the same as server version update application 122 by comparing the version numbers associated with both software applications. In some other embodiment, intelligent mobile application update program 200 may determine whether mobile application 112 is the same as server version update application 122 by comparing release dates.);
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Aleksandrov into Cardillo 's invention to determine whether the received mobile software application matches with a stored mobile software application in the data processing unit. An update policy is determined for scheduling an update of the mobile software application in the mobile data processing unit when the received mobile software application does not match the stored application as suggested by Aleksandrov (See abstract and summary).
The Office would like to use prior art Imadali to back up Cardillo and Aleksandrov to further teach limitation
Internet Protocol associated with the specific automobile (Imadali, US 20150215274, para [0015], solutions exist for using the vehicle identification number (VIN), which is a unique identifying number of a vehicle, for the generation of one or more IP addresses inside a vehicle. Para [0037], In order to obtain the desired results, a method is proposed for generating Internet Protocol (IP) addresses for entities connected to a communication controller via a network within a vehicle, the vehicle being associated with a vehicle identification number (VIN). The method includes the steps of: [0038] encoding the content of one or more fields of the VIN in the decimal base and the content of one or more other fields of the VIN according to a non-random algorithm; [0039] converting the result of the encoding into binary; [0040] ordering the bits obtained according to a predefined sequence; [0041] generating an interface identifier (IID) and an IP address prefix from the ordered sequence; and [0042] constructing an IP address for each entity, each IP address including at least said generated prefix.).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Imadali into Cardillo and Aleksandrov 's invention to encode contents of fields of a vehicle identification number (VIN) in decimal base according to a non-random algorithm. The result of the encoding contents is converted into a binary form. The bits obtained in a predefined sequence are arranged. An ordered sequence of an interface identifier (IID) and an IP address prefix is generated. The IP address for each entity is generated, where each IP address includes a generated prefix. A message is sent to a unit of a vehicle to announce the prefix.as suggested by Imadali (See abstract and summary).
The Office would like to use prior art Ingraham to back up Cardillo, Aleksandrov and Imadali to further teach limitation
if update, generating a signature using the certificate from the unique VIN number portion and the stored configuration file for encrypting the stored configuration file(Ingraham, US 20200057872, para [0010-0012], certificate and encrypt. Fig. 8 and para [0041], FIG. 8 is a detail sub-figure flowchart 800 of step 420 in FIG. 4. Details for the step of validating the authenticity of input and the entity/vehicle comprise receiving input for programming update for entity/vehicle 805; providing programming to security module 810; is programming authenticated? 815; if no, terminate programming update 820; if yes, direct input 825 to either decrypt via security module & provide decrypted update to module for programming 830 or provide encrypted update to module for programming 835. Then, if programming authenticated? 840 is no, terminate programming 820, if programming authenticated? 840 is yes, log activities 845 and exit. Validation is by the security module and, if possible, also the end use location. For embodiments, the decrypted input is not provided to the module for programming as this provides an attack surface to intercept the update in transit. The end use module should (in the best case scenario) do the authentication and decryption internally such that the update is always encrypted in transmit. The security module can authenticate and decrypt a first layer of encryption, the most robust implementation is for final authentication and decryption to occur at point of use in cases where there are multiple layers of encryption.).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Ingraham into Cardillo, Aleksandrov and Imadali 's invention to encrypt and decrypt a file using a certificate. The authenticity of the vehicle is immutable and cryptographically verified. The system ensures that over the air (OTA) or local code updates are authentic and not malicious, and prevents reverse compiling of encrypted code as suggested by Ingraham (See abstract and summary).
As per claim 2, this is the medium claim to method claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 3, this is the system claim to method claim 1. Therefore, it is rejected for the same reasons as above.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUY KHUONG THANH NGUYEN whose telephone number is (571)270-7139. The examiner can normally be reached Monday - Friday 0800-1630.
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, Lewis Bullock can be reached on 5712723759. 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.
/DUY KHUONG T NGUYEN/ Primary Examiner, Art Unit 2199