DETAILED ACTION
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 8/5/2026 has been entered.
Claims 1, 3, 6, 10-11, 14, 16, and 19 are amended. Claims 4, 8-9, 12, 15, 18, and 20 were previously canceled. Thus, claims 1-3, 5-7, 10-11, 13-14, 16-17, and 19 are currently pending.
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.
Claims 1-3, 5-6, 10-11, 13-14, 16-17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Cho (USPN: 2016/0334239) in view of Bryan et al. (Internet Engineering Task Force (IETF), Request for Comments: 6902, JavaScript Object Notation (JSON) Patch, April 2013), hereinafter, “RFC 6902”, further in view of Gounares et al. (USPN: 2013/0074092) hereinafter, “Gounares”.
As per claim 1, Cho teaches a method comprising:
reading, in a vehicle, a first configuration file comprising a first configuration parameter that affects an execution of a process in the vehicle into a memory as a set of in-memory configuration parameters (i.e. reading the user authentication information and the current map version information);
determining, by the vehicle, whether any update configuration file is present by checking for a storage location having an identifier based on a name of the first configuration file, the update configuration file comprising an entry specifying a change for the first configuration file (i.e. by checking and comparing current map version at the automatic navigation system update device with the latest map version at the update server. Note: the version numbers are considered as the claimed configuration file names); and
based on determining that the update configuration file is present in the storage location (i.e. the change is valid), determining, by applying the update configuration file to the set of in-memory configuration parameters in the memory, final configuration parameters to be applied for the process when executed in the vehicle, the final configuration parameters being produced without changing the first configuration file (i.e. once it is determined that the map version newer than the current one (e.g. newer than V3), the differential data lists are generated without changing the current/V3 map version; see [0032]-[0034] and [0051]), and
wherein checking for the storage location comprises checking for a directory having a name based on the name of the first configuration file, and wherein the update configuration file if present is in the directory (i.e. based on the current version of the map data; see [0059]).
However, Cho does not specifically disclose deriving, by the vehicle, the name of the directory by replacing a suffix in the name of the first configuration file with a different suffix. Although Cho does not explicitly recite the claimed step of deriving, the suffix replacement to derive related directory names is a straightforward string manipulation routine in file systems and config tools. Many configuration management systems derive file locations by stripping/trimming suffixes of the file names (see at least section 4.3 of RFC 6902). Therefore, in view of this conventional file lookup logic taught by RFC 6902, it would have been obvious to one of ordinary skills in the art to implement this deriving step in the method taught by Cho.
To the extent it is considered that Cho does not teach checking for the storage location comprises checking for a directory having a name based on the name of the first configuration file, and wherein the update configuration file if present is in the directory, RFC 6902 which is well known in the art teaches storing and applying update configuration files as patch files (see at least section 1 and Abstract), which implies they must be located and retrieved from a storage location before application. It is also well known and common that many file lookup strategies use derived directory names based on configuration file names; i.e. looking for a directory named from configuration file base name plus a suffix. Therefore, it would have been obvious to one of ordinary skills in the art to modify the method taught by Cho in view of RFC 6902 by checking for a directory based on the name of a configuration file (e.g. strip suffix and derive directory for updates), because file lookup frameworks already taught deriving storage locations from file names and extensions. That way a structure, where update files are stored and checked in a directory named based on the initial config file name, would be arrived.
Both Cho and RFC 6902 failed to teach the claimed limitations of the first configuration parameter specifies a size of private memory assigned to the process, the update configuration file specifies a change to the size, and the process executes using the changed size of private memory specified by the final configuration parameters. Gounares however teaches about dynamically allocating memory (changing the size of previously allocated memory) by changing the memory settings in the configuration file (see at least [0004]). Accordingly, it would have been obvious to one of ordinary skills in the art to modify the method taught by Cho in view of RFC 6902 to get the size of originally assigned private memory to a process, determine the required change in the size of the private memory assignment and then executing the process using that changed size of private memory allocated in order to achieve the expected result of changing the process’s available memory allocation as needed base instead of single memory allocation scheme that applied to all executable code (see [0001]-[0003]).
As per claim 2, Cho further teaches the storage location is in a memory and the storage location comprises the first configuration file and the update configuration file (i.e. the memory is inherently present on the update server; see [0033]).
As per claim 3, Cho further teaches the update configuration file further comprises another entry specifying an insertion of a second configuration parameter into the set of in-memory configuration parameters, the second configuration parameter not being present in the first configuration file (i.e. the differential data in differential data lists are not present in the current (V3) map version information; see [0033]-[0034]).
As per claim 5, Cho further teaches the insertion of the second configuration parameter comprises: appending the second configuration parameter after an entry in the set of in-memory configuration parameters based on the first configuration file; or prepending the second configuration parameter before an entry in the set of in-memory configuration parameters based on the first configuration file; or inserting the second configuration parameter between entries in the set of in-memory configuration parameters based on the first configuration file (i.e. updating the current version of map data using the differential data inherently includes appending and/or prepending and/or deleting appending/prepending/inserting new parameter(s) after/before/between the entry of the first configuration file; see [0028]-[0029] and [0037]).
As per claim 6, Gounares further teaches the change from the size to the changed size comprises replacing a first value of the first configuration parameter in the set of in-memory configuration parameters with a second value different from the first value (i.e. changing the memory allocation size from default settings to new optimized size after performing lookup and calculation (see abstract, [0004], [0083]-[0085]. [0109]-[0112] and Figs. 4 and 7). It would have been obvious to one of ordinary skills in the art to implement the teaching of Gounares in the method taught by Cho in view of RFC 6902 to dynamically allocate the process’s available memory as needed base instead of single memory allocation scheme that applied to all executable code (see [0001]-[0003]).
As per claim 10, Gounares further teaches the first configuration parameter is represented in the first configuration file by a key-value pair comprising a size key and a first value assigned to the size key, and the change from the size to the changed size comprises replacing the first value with a second value assigned to the size key (i.e. changing the memory allocation size from default settings to new optimized size after performing lookup and calculation (see abstract, [0004], [0083]-[0085]. [0109]-[0112] and Figs. 4 and 7). It would have been obvious to one of ordinary skills in the art to implement the teaching of Gounares in the method taught by Cho in view of RFC 6902 to dynamically allocate the process’s available memory as needed base instead of single memory allocation scheme that applied to all executable code (see [0001]-[0003]).
As per claim 11, Cho teaches the storage location comprises a plurality of update configuration files including the update configuration file and furthermore about applying, to the set of in-memory configuration parameters in the memory, the plurality of update configuration files in a specified order according to characteristics of the plurality of update configuration files, wherein the characteristics comprise names of the plurality of update configuration files, to the set of in-memory configuration parameters in the memory to determine the final configuration parameters to be applied for the process when executed in the vehicle (see [0033]-[0034]).
For the sake of argument, if it is considered that Cho does not teach the ‘applying’ limitation of this claim, ordered application of patches is widely known in the art. RFC 6902 which is well known in the art defines an ordered list of operations and teaches about allowing sequences of patch operations. Therefore, a person of ordinary skill in the art would find it obvious to apply multiple update patches in a specified order in the method taught by Cho because patch frameworks inherently work by processing an ordered list of operations. Likewise, config frameworks load multiple files in a determined order.
As per claim 13, Cho teaches the claimed invention as described above and furthermore, Cho teaches the specified order is an alphabetical order according to the names of the plurality of update configuration files (i.e. differential data is generated and applied version-by-version (e.g. V3, V4, V5, V6…), which is also in alphabetical order as claimed; see [0033]-[0034]).
As per claim 14, although neither of Cho, RFC 6902 and Gounares explicitly recite the further limitation of claim 14, it is well-known practice in configuration management systems and in RFC 6902 to validate a configuration update file against schema information prior to applying the update configuration file in order to prevent malformed or incompatible updates.
As per claim 16, Cho teaches a vehicle system (as shown in Fig. 1) comprising: one or more processors (inherently present in the update server 200 as well as in the navigation system update device 100); and a non-transitory storage medium storing instructions executable by the one or more processors (inherent). For the rest of the claim limitations, see the rejection of claim 1 above.
As per claim 17, although neither of Cho, RFC 6902 and Gounares specifically disclose the further limitation of claim 17, it is common and would have been obvious to prevent application of an update configuration file upon detecting an invalid change, as this fundamental error handling practice in software systems to ensure system stability.
As per claim 19, Cho teaches a non-transitory machine-readable storage medium comprising instructions (inherently present in the update server 200 as well as in the navigation system update device 100) that upon execution cause a vehicle system (shown in Fig. 1). For the rest of the claim limitations, see the rejection of claim 1 above.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Cho in view of RFC 6902, further in view Gounares and Debickes et al. (USPN: 2018/0167380), hereinafter, Debickes.
As per claim 7, although neither of Cho, RFC 6902 and Gounares specifically disclose, Debickes teaches the first configuration file and the update configuration file are received at the vehicle in a package (see [0002]).
It would have been obvious to one of ordinary skills in the art to implement the teachings of Debickes in the method taught by the combination of Cho, RFC 6902 and Gounares to receive both an initial configuration file and an update configuration file at the vehicle in a package, as claimed, in order to ensure version consistency between configuration data and updates; simplify deployment and installation procedures; reduce the risk of incompatible or missing configuration artifacts; and improve reliability of vehicle software updates, which is a known concern in automotive system.
Remarks
Applicant’s arguments with respect to claim(s) 102 and 103 rejections have been considered but are moot in view of the new ground of rejection made in this Office action.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Hetul Patel whose telephone number is (571)272-4184. The examiner can normally be reached M-F 9am-5pm.
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.
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.
/Hetul Patel/
Supervisory Patent Examiner
Art Unit 3992
