DETAILED ACTION
Claims 1-20 are presented for examination.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 10/7/2024 and 4/30/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, these information disclosure statements are considered by the examiner.
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.
Claims 16 and 19 are rejected under 35 U.S.C. 112(a) 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 at the time the application was filed, had possession of the claimed invention.
The claims 16 and 19 (and specification in [0046]-[0051]) broadly cover systems not in vehicles, but:
The invention is framed as vehicle-centric throughout.
Only brief, conclusory mention of non-vehicle systems is provided.
Therefore, there is insufficient written description support for non-vehicle embodiments. A single paragraph saying “may be separate from any vehicle” is not enough to support full claim breadth.
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.
Claims 1-20 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, regards as the invention.
The term “property of the first configuration file” is extremely broad and undefined. The specification in [0023], [0037] and [0050] lists examples of it as name, identifier, memory address, “or any other property”. ‘Any other property’ renders the scope indeterminate. A person of ordinary skill in the art cannot determine the boundaries of what qualifies. Therefore, the term “property” lacks antecedent clarity and objective boundaries, rendering the claim scope of claims 1-20 uncertain.
Furthermore, claims 11-13 (and specification in [0026]-[0028]) recite applying update configuration files “in a specified order”, but
the independent claim 11 does not specify how the order is determined.
Dependent claim 12 mentions names or alphabetical order, but the base claim covers unspecified mechanism.
It is indefinite because the “specified order” lacks objective criteria in the independent claim.
Claim Rejections - 35 USC § 102
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-6, 15-16 and 19 are rejected under 35 U.S.C. 102(a)(1) and 35 U.S.C. 102(a)(2) as being anticipated by Rork et al. (USPN: 9,323,546) hereinafter, Rork.
As per claim 1, Rork teaches a method (i.e. an exemplary process 600 for targeted updating of vehicle feature configurations; see Col. 21, lines 9-10) comprising:
reading, in a vehicle, a first configuration file comprising a first configuration parameter that affects an execution of a process in the vehicle (i.e. implicit feature in view of the current hardware and feature grouping of the vehicle see Col. 21, lines 10-16);
determining, by the vehicle, whether any update configuration file is present by checking for a storage location having an identifier based on a property of the first configuration file (i.e. the vehicle 31 retrieves the published update. For example, if a vehicle-specific update has been published to the topic tree 208, the vehicle 31 may retrieve the updated configuration file 212; see Col. 22, lines 20-25),
the update configuration file comprising an entry specifying a change for the first configuration file (i.e. a configuration file 212 may include information to configure multiple portions of functionality of the configurable module 210. In some cases, a configuration file 212 may include information useful to allow the configurable module 210 to enable, disable, or configure all or substantially all of the functionality of the configurable module 210; see Col. 8, lines 62-67); and
based on determining that the update configuration file is present in the storage location, applying, by the vehicle, the update configuration file to the first configuration file to determine configuration parameters to apply for the process when executed in the vehicle (i.e. the vehicle 31 updates its configuration file 212 to use the retrieved configuration file 212. For example, the vehicle 31 may overwrite or otherwise replace the current configuration file 212 in use by the vehicle with the retrieved configuration file 212. Accordingly, the new configuration features and parameters from the configuration file 212 may be applied to the vehicle 31; see Col. 22, line 64 – Col. 23, line 3).
As per claim 2, although Rork does not explicitly recite that the storage location is in a memory and the storage location comprises the first configuration file and the update configuration file, it is inherent in Rork to have some sort of memory/storage device to save the first and updated configuration files.
As per claim 3, Rork further teaches that the change specified by the update configuration file comprises an insertion of a second configuration parameter with respect to the first configuration file (i.e. updating the first configuration file by overwriting or replacing it with the updated configuration file; see Col. 22, lines 64-67. Overwriting/replacing configuration file inherently includes deleting one/more existing parameter(s) OR appending/prepending/inserting new parameter(s) after/before/between the entry of the first configuration file).
As per claim 4, Rork further teaches that the second configuration parameter is not present in the first configuration file (i.e. updating the first configuration file by overwriting or replacing it with the updated configuration file; see Col. 22, lines 64-67. Overwriting/replacing configuration file inherently includes deleting one/more existing parameter(s) OR appending/prepending/inserting new parameter(s) after/before/between the entry of the first configuration file).
As per claim 5, Rork further teaches that the insertion of the second configuration parameter comprises: appending the second configuration parameter after an entry in the first configuration file; or prepending the second configuration parameter before an entry of the first configuration file; or inserting the second configuration parameter between entries of the first configuration file (i.e. updating the first configuration file by overwriting or replacing it with the updated configuration file; see Col. 22, lines 64-67. Overwriting/replacing configuration file inherently includes deleting one/more existing parameter(s) OR appending/prepending/inserting new parameter(s) after/before/between the entry of the first configuration file).
As per claim 6, Rork further teaches that the change specified by the update configuration file comprises a modification of a value of the first configuration parameter in the first configuration file (i.e. updating the first configuration file by overwriting or replacing it with the updated configuration file; see Col. 22, lines 64-67. Overwriting/replacing configuration file inherently includes modifying one or more value(s) of the first configuration parameter in the first configuration file).
As per claim 15, Rork further teaches that the first configuration file is read into a memory as a set of in-memory configuration parameters (i.e. implicit feature in view of the current hardware and feature grouping of the vehicle see Col. 21, lines 10-16), and wherein the applying of the update configuration file comprises changing the set of in-memory configuration parameters in the memory (i.e. the vehicle 31 updates its configuration file 212 to use the retrieved configuration file 212. For example, the vehicle 31 may overwrite or otherwise replace the current configuration file 212 in use by the vehicle with the retrieved configuration file 212. Accordingly, the new configuration features and parameters from the configuration file 212 may be applied to the vehicle 31; see Col. 22, line 64 – Col. 23, line 3).
As per claim 16, Rork teaches a system (i.e. a vehicle-based computing system 1 (VCS) for a vehicle 31; see Col. 3, lines 59-60) comprising:
one or more processors (i.e. a processor 3 or central processing unit 3; see Col. 4, lines 3-6); and
a non transitory storage medium storing instructions executable by the one or more processors to (i.e. persistent storage 7; see Col. 4, lines 7-18):
read a first configuration file comprising a first configuration parameter that affects an execution of a process in a vehicle (i.e. implicit feature in view of the current hardware and feature grouping of the vehicle see Col. 21, lines 10-16);
determine whether any update configuration file is present by checking for a storage location having an identifier based on a property of the first configuration file (i.e. the vehicle 31 retrieves the published update. For example, if a vehicle-specific update has been published to the topic tree 208, the vehicle 31 may retrieve the updated configuration file 212; see Col. 22, lines 20-25), the update configuration file comprising an entry specifying a change for the first configuration file (i.e. a configuration file 212 may include information to configure multiple portions of functionality of the configurable module 210. In some cases, a configuration file 212 may include information useful to allow the configurable module 210 to enable, disable, or configure all or substantially all of the functionality of the configurable module 210; see Col. 8, lines 62-67);
determine whether the change is valid (i.e. determines whether the current configuration fil 212 version matches the desired configuration file 212 version of the retrieved updated configuration file 212; see Col. 22, lines 56-59); and
based on determining that the change is valid, apply the update configuration file to the first configuration file (i.e. if the desired configuration file 212 version differs from that of the current configuration file 212 version, control passes to block 614; see Col. 22, line 61 – Col. 23, line 3)
to determine configuration parameters to apply for the process when executed in the vehicle (i.e. the new configuration features and parameters from the configuration file 212 may be applied to the vehicle 31; see Col. 22, line 64 – Col. 23, line 3).
As per claim 19, Rork teaches a non-transitory machine-readable storage medium comprising instructions that upon execution cause a system to: read a first configuration file comprising a first configuration parameter that affects an execution of a process in a vehicle (i.e. implicit feature in view of the current hardware and feature grouping of the vehicle; see Col. 21, lines 10-16);
determine whether any update configuration file is present by checking for a storage location having an identifier based on a property of the first configuration file (i.e. the vehicle 31 retrieves the published update. For example, if a vehicle-specific update has been published to the topic tree 208, the vehicle 31 may retrieve the updated configuration file 212; see Col. 22, lines 20-25),
the update configuration file comprising an entry specifying a change for the first configuration file (i.e. a configuration file 212 may include information to configure multiple portions of functionality of the configurable module 210. In some cases, a configuration file 212 may include information useful to allow the configurable module 210 to enable, disable, or configure all or substantially all of the functionality of the configurable module 210; see Col. 8, lines 62-67); and
apply the update configuration file to the first configuration file to determine configuration parameters to apply for the process when executed in the vehicle (i.e. the vehicle 31 updates its configuration file 212 to use the retrieved configuration file 212. For example, the vehicle 31 may overwrite or otherwise replace the current configuration file 212 in use by the vehicle with the retrieved configuration file 212. Accordingly, the new configuration features and parameters from the configuration file 212 may be applied to the vehicle 31; see Col. 22, line 64 – Col. 23, line 3).
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.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Rork.
As per claim 9, Rork teaches the claimed invention as described above but does not specifically disclose about 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 Rork 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). Therefore, in view of this conventional file lookup logic, it would have been obvious to one of ordinary skills in the art to implement this deriving step in the method taught by Rork.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Rork in view Debickes et al. (USPN: 2018/0167380), hereinafter, Debickes.
As per claim 7, although Rork does not 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 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.
Claims 8, 10-14, 17-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Rork in view of JSON Patch (RFC 6902) standard, hereinafter, RFC 6902.
As per claim 8, Rork teaches the claimed invention as described above but does not specifically disclose about checking for the storage location comprises checking for a directory having a name based on a name of the first configuration file, and wherein the update configuration file if present is in the directory.
However, 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 Rork 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.
As per claim 10, Rork teaches the claimed invention as described above but does not specifically disclose about the first configuration parameter in the first configuration file comprises a key-value pair comprising a key representing the first configuration parameter and a first value assigned to the key, and the change for the first configuration file comprises a modification of a value assigned to key.
However, RFC 6902 which is well known in the art teaches key-value parameters and modifying values in an existing configuration file (see at least various examples given in Appendix). The ‘replace value’, which is a basic config file edit operation, in JSON patch corresponds directly to this limitation (see at least section 4.3).
Therefore, it would have been obvious to one of ordinary skills in the art to implement the teachings of RFC 6902 in the method taught by Rork to modify/change/replace the key value so config parameter can be changed easily by simply changing the key value and changes can be easily tracked.
As per claim 11, Rork inherently teaches the storage location comprises a plurality of update configuration files. Rork does not specifically disclose about applying the plurality of update configuration files in a specified order according to characteristics of the plurality of update configuration files to the first configuration file to determine configuration parameters to apply for the process when executed in the vehicle.
However, 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 Rork 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 12, although Rork and RFC 6902 do not explicitly recite about the characteristics comprise names of the plurality of update configuration files, determining order of multiple patches based on file names is a routine convention in software. It is well-known and common practice to patch utilities and config loaders often sort files alphabetically or by timestamp. Therefore, a person of ordinary skill in the art would find it obvious to implement this teaching in the method of Rork and RFC 6902. Sorting and processing the configuration files in alphabetical order as a criterion is even more generic. Therefore, selecting alphabetical order to define a sequence of update configuration files, as in claim 13, would be obvious design choice for anyone managing multiple ordered update configuration files.
As per claim 14, although Rork does not explicitly recite the further limitation of claim 14, however, 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 17, although Rork and RFC 6902 do not explicitly recite the further limitation of claim 17, however, 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 20, Rork further teaches that the storage location comprises a directory (i.e. the desired feature node 404-C of the topic tree 208 subscribed to by the vehicle 31; see Col. 22, lines 24-25), and
the instructions upon execution cause the system to: determine whether any update configuration file is present by checking for the directory having the directory name (it is clear that the vehicle is subscribed to a node bearing a unique directory name; see Col. 21; lines 26-34).
Although Rork and RFC 6902 do 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. Therefore, in view of this conventional file lookup logic, it would have been obvious to one of ordinary skills in the art to implement this deriving step in the method taught by Rork and RFC 6902.
With respect to claim 18, see the rejection of claims 9 and 20.
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.
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.
/Hetul Patel/
Supervisory Patent Examiner
Art Unit 3992