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 .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references cited in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Response to Amendment
The preliminary amendment to the Claims and Specification filed 8/26/2025 has been entered.
Claim Objections
Claims 1, 10, and 19 are objected to because of the following informalities:
In claim 1, line 9, “a signal catalog” should include a modifier to clarify it is different from the previously recited “reference signal catalog”. Examiner recommends amending claim 1, line 9, to recite “a second signal catalog”.
In claim 10, line 11, “a signal catalog” should include a modifier to clarify it is different from the previously recited “reference signal catalog”. Examiner recommends amending claim 10, line 11, to recite “a second signal catalog”.
In claim 19, line 10, “a signal catalog” should include a modifier to clarify it is different from the previously recited “reference signal catalog”. Examiner recommends amending claim 19, line 10, to recite “a second signal catalog”.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
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-20 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.
Claim 1 recites the limitation "the node path names" in line 8. There is insufficient antecedent basis for this limitation in the claim. For clarity of the record, the Examiner has interpreted this limitation to be referring to the singular, previously recited “node path name” in line 4.
Claim 1 recites the limitation "the second signal catalog" in line 11. There is insufficient antecedent basis for this limitation in the claim. For clarity of the record, the Examiner has interpreted this limitation to be referring to the previously recited “signal catalog” in line 9.
Claims 2-9 depend from claim 1 and therefore inherit the deficiencies of claim 1.
Claim 2 recites the limitation "the synthetic sensor" in line 2. There is insufficient antecedent basis for this limitation in the claim.
Claim 3 depends from claim 2 and therefore inherits the deficiencies of claim 2.
Claim 10 recites the limitation "the node path names" in line 10. There is insufficient antecedent basis for this limitation in the claim. For clarity of the record, the Examiner has interpreted this limitation to be referring to the singular, previously recited “node path name” in lines 5-6.
Claim 10 recites the limitation "the second signal catalog" in line 12. There is insufficient antecedent basis for this limitation in the claim. For clarity of the record, the Examiner has interpreted this limitation to be referring to the previously recited “signal catalog” in line 11.
Claims 11-18 depend from claim 10 and therefore inherit the deficiencies of claim 10.
Claim 11 recites the limitation "the synthetic sensor" in line 3. There is insufficient antecedent basis for this limitation in the claim.
Claim 12 depends from claim 11 and therefore inherits the deficiencies of claim 11.
Claim 19 recites the limitation "the node path names" in line 9. There is insufficient antecedent basis for this limitation in the claim. For clarity of the record, the Examiner has interpreted this limitation to be referring to the singular, previously recited “node path name” in line 5.
Claim 19 recites the limitation "the second signal catalog" in line 12. There is insufficient antecedent basis for this limitation in the claim. For clarity of the record, the Examiner has interpreted this limitation to be referring to the previously recited “signal catalog” in line 10.
Claim 20 depends from claim 19 and therefore inherit the deficiencies of claim 19.
Claim 20 recites the limitation "the synthetic sensor" in line 3. There is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-18 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1:
Claim 1 is directed to A method at a computing device for validating an application, comprising: a series of steps, and is therefore directed to a process, which is one of the four statutory categories.
Step 2A, Prong One:
Claim 1 recites the limitations:
enhancing a manifest of the application, the manifest of the application comprising a node path name corresponding to a required signal by the application, wherein enhancing the manifest comprises:
searching, in a reference signal catalog for a unique identifier corresponding to the node path name; and
adding, into an enhanced manifest, the node path names and the unique identifier; validating the enhanced manifest against a signal catalog, wherein the validating comprises:
searching, in the second signal catalog, for a second unique identifier corresponding to the node path name; and
reporting whether the second unique identifier is the same as the unique identifier, different from the unique identifier, or missing from the second signal catalog
all of which can be performed in the human mind through observation, evaluation, judgment and opinion, with the aid of pen and paper, and are therefore reciting a mental process.
Accordingly, claim 1 recites a judicial exception (i.e., an abstract idea).
Step 2A, Prong Two:
Claim 1 does not recite any additional elements beyond the recited judicial exception. “Because a judicial exception alone is not eligible subject matter, if there are no additional claim elements besides the judicial exception, or if the additional claim elements merely recite another judicial exception, that is insufficient to integrate the judicial exception into a practical application.” See MPEP 2106.04(d).
Thus, when considering claim 1 as a whole, the judicial exception is not integrated into a practical application.
Step 2B:
Claim 1 does not claim any additional elements beyond the recited judicial exception. Thus, the claim as a whole cannot amount to significantly more than the recited judicial exception. See MPEP 2106.05.
Consequently claim 1 is not eligible.
Claim 2 is dependent on claim 1, and therefore inherits the same judicial exception recited in claim 1. Claim 1 failed to recite any additional elements beyond the judicial exception.
Claim 2 recites the additional element “upon determining that the second unique identifier is the same as the unique identifier, installing the synthetic sensor on a vehicle” which amounts to generally linking the use of the exception to a particular technological environment and does not meaningfully limit the recited judicial exception. Specifically, this additional element is merely stating that a synthetic sensor may be installed in a vehicle after reporting that a second unique identifier from an arbitrary second signal catalog is the same as a unique identifier corresponding to a signal required by an application. Generally linking the use of a judicial exception to particular technological environment is not indicative of integration into a practical application. See MPEP 2106.04(d). Further, additional elements which generally link the use of an exception to a particular technological environment do not amount to significantly more than the recited judicial exception. Thus, claim 2 is not eligible.
Claim 3 is dependent on claim 2, and therefore inherits the same judicial exception recited in claim 1.
Claim 3 recites the additional element “the vehicle has the second signal catalog installed thereon”, which amounts to generally linking the use of the exception to a particular technological environment and does not meaningfully limit the recited judicial exception. Specifically, this additional element is merely stating that the second signal catalog which is used to validate the enhanced manifest is installed on a vehicle on which a synthetic sensor is installed, but does not limit how the enhanced manifest is validated. Generally linking the use of a judicial exception to particular technological environment is not indicative of integration into a practical application. See MPEP 2106.04(d). Further, additional elements which generally link the use of an exception to a particular technological environment do not amount to significantly more than the recited judicial exception. Even when considered in combination with the additional element of claim 2, these additional elements are not indicative of integration into a practical application, nor do they amount to significantly more than the recited judicial exception. Thus, claim 3 is not eligible.
Claim 4 is dependent on claim 1, and therefore inherits the same judicial exception recited in claim 1, including the step “searching, in a reference signal catalog for a unique identifier corresponding to
the node path name” which can be performed in the human mind through observation, evaluation, judgment and opinion, with the aid of pen and paper, and is therefore reciting a mental process. Claim 4 further recites “wherein the unique identifier is unique for a combination of node path name and semantic information”. Since a person would still be able to search for the unique identifier specified in the limitation recited by claim 4 through observation, evaluation, judgment and opinion, with the aid of pen and paper, the limitation of claim 4 is still reciting a mental process.
Claim 4 does not recite any additional elements beyond the recited judicial exception. Accordingly, for the same reasons presented with respect to claim 1, since there are no additional elements recited by the claims, the judicial exception is not integrated into a practical application nor do the claims amount to significantly more than the recited judicial exception. Thus, claim 4 is not eligible.
Claim 5 is dependent on claim 1, and therefore inherits the same judicial exception recited in claim 1. Claim 5 further recites “prior to the enhancing, computing a respective unique identifier for each respective node path name in the reference signal catalog and the second signal catalog”, which can be performed in the human mind through observation, evaluation, judgment and opinion, with the aid of pen and paper, and is therefore reciting a mental process.
Claim 5 does not recite any additional elements beyond the recited judicial exception. Accordingly, for the same reasons presented with respect to claim 1, since there are no additional elements recited by the claims, the judicial exception is not integrated into a practical application nor do the claims amount to significantly more than the recited judicial exception. Thus, claim 5 is not eligible.
Claim 6 is dependent on claim 5, and therefore inherits the same judicial exception recited in claims 1 and 5. Claim 6 further recites “wherein the respective unique identifier is computed as a hash of the respective node path name and semantic information of the respective node path name”, which can be performed in the human mind through observation, evaluation, judgment and opinion, with the aid of pen and paper, and is therefore reciting a mental process. Additionally, this limitation comprises mathematical calculations, which are also an abstract idea, and is therefore reciting a judicial exception.
Claim 6 does not recite any additional elements beyond the recited judicial exception(s). Accordingly, for the same reasons presented with respect to claims 1 and 5, since there are no additional elements recited by the claims, the judicial exception(s) are not integrated into a practical application nor do the claims amount to significantly more than the recited judicial exception. Thus, claim 6 is not eligible.
Claim 7 is dependent on claim 6, and therefore inherits the same judicial exception recited in claims 1 and 5-6, including “computing a respective unique identifier” and “wherein the respective unique identifier is computed as a hash. Claim 7 further recites “where in the hash is a 64-bit hash”. Computing a 64-bit hash comprises mathematical calculations, and therefore the claims (i.e., claims 5-7) are reciting a judicial exception of an abstract idea.
Claim 7 does not recite any additional elements beyond the recited judicial exceptions. Accordingly, for the same reasons presented with respect to claims 1 and 5-6, since there are no additional elements recited by the claims, the judicial exceptions are not integrated into a practical application nor do the claims amount to significantly more than the recited judicial exception. Thus, claim 7 is not eligible.
Claim 8 is dependent on claim 1, and therefore inherits the same judicial exception recited in claim 1. Claim 8 further recites “wherein the application is developed based on the reference signal catalog”, which can be performed in the human mind through observation, evaluation, judgment and opinion, with the aid of pen and paper, and is therefore reciting a mental process.
Claim 8 does not recite any additional elements beyond the recited judicial exception. Accordingly, for the same reasons presented with respect to claim 1, since there are no additional elements recited by the claims, the judicial exception is not integrated into a practical application nor do the claims amount to significantly more than the recited judicial exception. Thus, claim 8 is not eligible.
Claim 9 is dependent on claim 1, and therefore inherits the same judicial exception recited in claim 1, including the step “enhancing a manifest of the application” which can be performed in the human mind through observation, evaluation, judgment and opinion, with the aid of pen and paper, and is therefore reciting a mental process. Claim 9 further recites “wherein the manifest further comprises a second node path name corresponding to an optional signal for the application”. Since a person would still be able to enhance the manifest specified in the limitation recited by claim 9 through observation, evaluation, judgment and opinion, with the aid of pen and paper, the limitation of claim 9 is still reciting a mental process.
Claim 9 does not recite any additional elements beyond the recited judicial exception. Accordingly, for the same reasons presented with respect to claim 1, since there are no additional elements recited by the claims, the judicial exception is not integrated into a practical application nor do the claims amount to significantly more than the recited judicial exception. Thus, claim 9 is not eligible.
Claim 10 recites A computing device for validating an application, comprising: a communication subsystem; a processor; wherein the communication subsystem and the processor cooperate to: perform the steps of the method of claim 1. Thus, for similar reasons presented with respect to claim 1, claim 10 is rejected because the claimed invention is directed to an abstract idea without significantly more.
For clarity of the record, the additional element recited above amounts to mere instructions to apply the exception on a generic computer, which is neither indicative of integration into a practical application nor amounts to significantly more than the recited judicial exception. See MPEP 2106.04(d) and MPEP 2106.05(f).
Claims 11-18 recite substantially the same limitations as those recited in claims 2-9, respectively, applied to the apparatus of claim 10. Thus, for the same reasons presented with respect to claims 2-9, claims 11-18 are directed to an abstract idea without significantly more and are not eligible.
Claims 19-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the claimed “computer readable medium” encompasses transitory signals (“signals per se”) which is not one of the four statutory categories.
The Examiner recommends amending the claims to recite a “non-transitory computer readable medium” to overcome the rejection.
For clarity of the record, if claims 19-20 are amended to recite a “non-transitory computer readable medium” such that the claims fall within one of the four statutory categories, the claims would be rejected under 35 U.S.C. 101 for being directed to an abstract idea without significantly more for similar reasons presented with respect to claims 1-2 and 10-11 presented above.
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-4, 8-13, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Mendez Rodriguez et al. (U.S. Pub. No. 2022/0321655), hereinafter Mendez Rodriguez, in view of Ramnani et al. (U.S. Pub. No. 2023/0169805), hereinafter Ramnani.
Regarding claim 1, Mendez Rodriguez teaches A method at a computing device ([0149] – “FIG. 15 is a block diagram illustrating an example computer system that implements some or all of the techniques described herein”) for validating an application, comprising:
enhancing a manifest of the application, the manifest of the application comprising […] a required signal by the application (FIG. 2; [0040] – including annotations as metadata in a synthetic sensor package allows an orchestration component to determine a placement location of the synthetic sensor without having to parse the code; [0043] – “sensor data to use as inputs for the synthetic sensor from a list of sensor data types […] The developer may further determine mappings between the inputs, the logic elements (e.g. the rules and/or the models), to an output of the new synthetic sensor. In some embodiments, the mappings may be represented as JSON objects or XML code, wherein a synthetic sensor orchestration environment in a vehicle to which a package for the new synthetic sensor is deployed parses the JSON objects or XML code to determine relationships between inputs, logic elements (e.g. rules and/or models), and outputs. […] one or more annotations stored as metadata of the synthetic sensor package (outside of the envelope) may indicate characteristics of the synthetic sensor such as required inputs, optional inputs, outputs, certification levels, synthetic sensor dependencies, failure modes, etc.”; [0055]-[0056] – “service interface 108 may provide a "drag and drop" graphical user interface (GUI), wherein a client drags and drops logic elements, such as rules models, etc. to be used in a new synthetic sensor and further defines a data flow through the new synthetic sensor by drawing lines connecting inputs to the logic elements and further connecting the logic elements to one or more outputs of the synthetic sensor. […] mapping and annotation generator 110 may then generate a synthetic sensor package as defined by the client via service interface 108. In some embodiments, the client may specify annotations to be included with the synthetic sensor package, or mapping and annotation generator 110 may automatically determine annotations based on the synthetic sensor definition received via service interface 108.”
For clarity of the record, the Examiner would like to point to paragraph [00116] of the Specification of the instant application, which recites “the application manifest may be replaced by a list of signals of interest for the application.” Thus, since the synthetic sensor package for the synthetic sensor (an “application”) comprises a list of signals of interest (e.g., sensor data inputs and outputs) for the synthetic sensor, the listed signals of the synthetic sensor package is analogous to the recited “application manifest”. Specifically, sensor data inputs and outputs are included in the mappings defining the synthetic sensor, and metadata annotations indicating the input signals are generated, based on the mappings defining the synthetic sensor, and added to the package, where the annotations “enhance” the package, as described in [0040] of Mendez Rodriguez.), wherein enhancing the manifest comprises:
searching, in a reference signal catalog for [the required signal] ([0043] – “The developer of the synthetic sensor (e.g. OEM manufacturer, OEM parts manufacturer, or third-party) may select sensor data to use as inputs for the synthetic sensor from a list of sensor data types”; [0055] – “a console implemented by service interface 108 may provide clients 120 with available sensors included in a vehicle that may be used to design a new synthetic sensor. For example, physical sensor list 106 may store updated lists of available sensors that are included in various types of vehicles that subscribe to the synthetic sensor service 102.”) […]; and
adding, into an enhanced manifest, the [required signal] ([0056] – “mapping and annotation generator 110 may then generate a synthetic sensor package as defined by the client via service interface 108. In some embodiments, the client may specify annotations to be included with the synthetic sensor package, or mapping and annotation generator 110 may automatically determine annotations based on the synthetic sensor definition received via service interface 108.”; [0043] – “one or more annotations stored as metadata of the synthetic sensor package (outside of the envelope) may indicate characteristics of the synthetic sensor such as required inputs”);
validating the enhanced manifest against a signal catalog ([0083] – “orchestration component 524 determines placement based on annotations associated with the synthetic sensor packages 146A and/or 146B, input availabilities at the respective placement locations (e.g. ECUs 502,504, 508, etc.)”; [0131] – “respective availabilities of data inputs at different placement locations”; Claim 1 – “determine a placement location for the synthetic sensor, based on: respective availabilities of data inputs for the mappings of the synthetic sensor package at respective ones of the ECUs”.
For clarity of the record, the Examiner would like to point to paragraph [0020] of the Specification of the instant application, which recites “"Signal Catalog": The set of signals used in a vehicle. Thus, the respective input availabilities of sensor data inputs at a particular placement locations, e.g., at a particular ECU, is analogous to a signal catalog, as it corresponds to the set of signals used at that placement location in the vehicle.), wherein the validating comprises:
searching, in the second signal catalog, for a second [signal] corresponding to the [required signal] ([0030] – “capability limits of ECU includes input limitations regarding which types of inputs the ECU has access to”; [0069] – “monitoring component 306 is responsible for reporting ECU capacities, capabilities, priorities, etc. to orchestration component 302.”; [0071] – “the orchestration component, may place the synthetic sensor based on annotations indicated for the synthetic sensor package and based on status information provided by monitoring component 306. The orchestration component 302 may keep a global view of the state of the ECUs of the in-vehicle distributed computing environment 140 and may assign work to respective ECUs based on this global view and the respective requirements of the work.”; [0083] – “orchestration component 524 determines placement based on annotations associated with the synthetic sensor packages 146A and/or 146B, input availabilities at the respective placement locations (e.g. ECUs 502, 504, 508, etc.)”; [0131]-[0132] – “At 1208/1210, the in-vehicle distributed computing environment determines whether the given synthetic sensor is to be placed in the in-vehicle distributed computing environment as a single synthetic sensor or is to be placed in the in-vehicle distributed computing environment as two or more modular components, based on the one or more annotations of the synthetic senor package, respective availabilities of data inputs at different placement locations, an respective processor capacities and/or capabilities at the different placement locations. At 1212, if a monolith placement is determined, the in-vehicle distributed computing environment places the synthetic sensor in single placement location having required data inputs and processor capabilities, capacities, priorities, etc.” To determine the placement location, e.g., an ECU having the required data inputs available, the orchestration component must determine the required inputs are included within the respective availabilities of one of the ECUs, i.e., search the respective availabilities (the “second signal catalog”) reported by the monitoring component for available inputs corresponding to the required inputs.) […]; and
reporting whether the second [signal] is the same as the [required signal], different from the second unique identifier, or missing from the second signal catalog ([0070]-[0071] – the orchestration component 302 places the synthetic sensor at a particular ECU by communicating work (e.g., the synthetic sensor) to the ECU via communication layer 308; [0131]-[0132] – “At 1208/1210, the in-vehicle distributed computing environment determines whether the given synthetic sensor is to be placed in the in-vehicle distributed computing environment as a single synthetic sensor […] based on the one or more annotations of the synthetic senor package, respective availabilities of data inputs at different placement locations, and respective processor capacities and/or capabilities at the different placement locations. At 1212, if a monolith placement is determined, the in-vehicle distributed computing environment places the synthetic sensor in single placement location having required data inputs, and processor capabilities, capacities, priorities, etc.” When a monolith placement at a particular ECU is determined, the input availabilities (“second signal catalog”) at the particular ECU were determined to include all the required inputs that were obtained from the “reference signal catalog” and added into the synthetic sensor package, i.e., the available “second” signal at the particular ECU is determined to be “the same as” the required signal. The orchestration component placing/communicating the synthetic sensor to the particular ECU implicitly is “reporting” to the particular ECU this determination that the available signal is the same as the required signal.
For clarity of the record, the claim recites a list of limitations in the alternative “the second unique identifier is the same as the unique identifier, different from the second unique identifier, or missing from the second signal catalog”. Accordingly, only one of the alternatives is required by the claims. The Examiner has relied upon Mendez Rodriguez, as modified in view of Ramnani presented below, to teach the alternative “the second unique identifier is the same as the unique identifier”).
Mendez Rodriguez fails to expressly teach a node path name corresponding to the required signal; a reference signal catalog containing a unique identifier corresponding to the node path name; adding the node path names and the unique identifier to an application manifest; and validating the manifest against a second signal catalog of signals available in a vehicle, wherein the second signal catalog includes a second unique identifier corresponding to the node path name.
However, Ramnani teaches a node path name corresponding to a vehicle signal ([0036]- “signal catalog may follow a Vehicle Signal Specification (VSS) naming guide and may be accessible using qualified names (e.g., Vehicle.Powertrain.CombustionEngine.FuelType).There may be one unique path per signal”); a reference signal catalog containing a unique identifier corresponding to the node path name ([0047] – “the signal catalog may follow a Vehicle Signal Specification (VSS) naming guide and may be accessible only using its qualified name. In some embodiments, there may be only one unique path per signal of the signal catalog wherein in some embodiments the data collection scheme controller 108 may assign the signal a unique signal id. The data collection scheme controller 108 of the data plane 104 may guarantee that the signal id be unique across the signal catalog.”); adding the node path names and the unique identifier to an application manifest ([0053] – “The data collection scheme controller 108 may receive from the customer various data collection schemes or configurations that instruct vehicles what data to collect from the vehicle […] When creating the data collection scheme, the OEMs or the customer 122 can specify a subset of the signals from the signal catalog that they wish to collect”; [0047] – signals are identified within the signal catalog using the unique node path name and corresponding unique id); and validating the manifest against a second signal catalog of signals available in a vehicle, wherein the second signal catalog includes a second unique identifier corresponding to the node path name ([0033] – “The data collection scheme controller 108 then validates the scheme against the model configuration of the vehicle […] If the vehicle scheme is determined to be applied to a fleet, the data collection scheme controller 108 may work with the vehicle communication interface 180 to apply the scheme to designated vehicles of the fleet”; [0036] and [0047] – a signal is identified in the signal catalog following a VSS naming guide including a unique node path name and unique id for the signal, where the catalog is only accessible using only the qualified node path name of the signal; [0048] – “The model configuration may be a collection of signals chosen from the signal catalog that are applicable to that specific vehicle model”; [0049] – “in-vehicle signal formats (e.g., a channel Id for signals providing the CAN DBC), and a mapping file that maps signal names given in the CAN DBCs to the signal name given in the model configuration”; [0056]-[0057] – “the model configuration 300 contains all or a subset of signal types in a signal catalog. The signals provided by the signal catalog may be arranged in a hierarchical structure as depicted in the model configuration 300 […] may utilize a VSS format […] a query 352 of vehicle model configuration 300 for "Drivetrain. Transmission. Speed" returns the relevant type of "sensor" for the signal "speed" 336 that is under "drivetrain" 332 and "transmission" 334” The model configuration (a “second signal catalog”) includes the subset of signals from a reference signal catalog that are applicable for a particular vehicle. It also has a VSS format, which, as described in [0047], includes a unique node path name and unique id for each signal. Thus, a signal contained in a model configuration has a “second unique identifier” corresponding to the node path name of the signal (the same unique id from the reference signal catalog, but located in the model configuration).).
Mendez Rodriguez and Ramnani are considered to be analogous art to the claimed invention because they are in the same field of operating applications on a vehicle. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the required signal taught by Mendez Rodriguez to be identified by a corresponding node path name and a unique id corresponding to the node path name as taught by Ramnani, such that enhancing the application manifest (i.e., searching a reference signal catalog for the required signal and adding the annotations identifying the required signal to the synthetic sensor package) as taught by Mendez Rodriguez comprises searching the reference signal catalog for the unique id corresponding to the node path name and adding the node path name and unique id for the required signal in the annotations of the synthetic sensor package, and such that validating the enhanced manifest against the second signal catalog (i.e., searching for an available signal of the set of available signals in a vehicle corresponding to the required signal and reporting if the available signal is the same as the required signal) as taught by Mendez Rodriguez comprises searching for a unique id corresponding to the node path name of the required signal in the second signal catalog (i.e., the set of available signals at a placement location) and reporting the unique id representing the available signal is the same as the unique id representing the required signal. Using node path names and corresponding unique identifiers to identify and search for vehicle signals in the signal catalogs provides the benefit of guaranteeing unique identification of a vehicle signal and reflects the hierarchical relationships of ECUs and sensors in a vehicle (Ramnani: [0036],[0047], and [0055]-[0057]).
Regarding claim 2, the combination of Mendez Rodriguez in view of Ramnani teaches The method of claim 1. Mendez Rodriguez, as modified by Ramnani with respect to claim 1, teaches the method further comprising, upon determining that the second unique identifier is the same as the unique identifier, installing the synthetic sensor on a vehicle ([0026] – “The synthetic sensor may be placed in the in-vehicle distributed computing environment as a monolithic synthetic sensor placed in a single synthetic sensor orchestration environment of a given ECU of the vehicle” [0028] – “cause a processor of at least one of the ECUs to receive a synthetic sensor package for deployment in the vehicle”; [0057] – “an application may request a synthetic sensor be deployed in order to enable the application to be implemented in a vehicle”; [0060] – “a synthetic sensor package that may be deployed from a synthetic sensor service to an in-vehicle distributed computing environment”; [0131]-[0132] – “At 1208/1210, the in-vehicle distributed computing environment determines whether the given synthetic sensor is to be placed in the in-vehicle distributed computing environment as a single synthetic sensor or is to be placed in the in-vehicle distributed computing environment as two or more modular components, based on the one or more annotations of the synthetic senor package, respective availabilities of data inputs at different placement locations, an respective processor capacities and/or capabilities at the different placement locations. At 1212, if a monolith placement is determined, the in-vehicle distributed computing environment places the synthetic sensor in single placement location having required data inputs and processor capabilities, capacities, priorities, etc.” Upon determining a particular ECU’s input availabilities include the required signal (“the second unique identifier is the same as the unique identifier”), the synthetic sensor is placed/deployed (“installed”) at the particular ECU on the vehicle.).
Regarding claim 3, the combination of Mendez Rodriguez in view of Ramnani teaches The method of claim 2. Mendez Rodriguez further teaches wherein the vehicle has the second signal catalog installed thereon ([0028] – “a plurality of electronic control units (ECUs) installed, or configured to be installed, in a vehicle. […] determine a placement location for the synthetic sensor based on respective availabilities of data inputs for the mappings of the synthetic sensor package at respective ones of the ECUs”; [0083] – “orchestration component 524 determines placement based on annotations associated with the synthetic sensor packages 146A and/or 146B, input availabilities at the respective placement locations (e.g. ECUs 502, 504, 508, etc.)”; ECUs 502, 504, 508 are part of in-vehicle distributed computing environment 512, see FIG. 5A; [0129] – “existing physical sensors and/or ECUs of the vehicle”; Claim 11 – “the different respective ECUs have different respective availabilities of data inputs, based at least in part on: […] sensor data provided to the respective ECU from sensors connected to the ECU.”).
Regarding claim 4, the combination of Mendez Rodriguez in view of Ramnani teaches The method of claim 1. Ramnani further teaches wherein the unique identifier is unique for a combination of node path name and semantic information ([0036] – “There may be one unique path per signal of the signal catalog wherein in some embodiments the data collection scheme controller 108 may assign the signal a unique signal id. The data collection scheme controller 108 of the data plane 104 may guarantee that the signal id be unique across the signal catalog.”; FIG. 3, see box labeled 352 – the signal represented by Drivetrain.Transmission.Speed in the hierarchical structure of a signal catalog includes “semantic information” including type “sensor” and unit “kn/h”; [0055] – “FIG. 3 illustrates a graphical view of an example vehicle model configuration having a hierarchical tree structure that uses a vehicle signal catalog”; [0056] – “the model configuration 300 contains all or a subset of signal types in a signal catalog. The signals provided by the signal catalog may be arranged in a hierarchical structure as depicted in the model configuration 300 and may include various signal types such as attribute, branch, sensor, and actuator.” There is one unique path (“node path name”) per signal, where the signals include semantic information as shown in FIG. 3, and each signal is assigned a unique signal id; thus, the unique signal id is unique for the path of the signal and semantic information of the signal included in the catalog.).
It would have been obvious to one of ordinary skill in the art to have modified the teachings of Mendez Rodriguez such that each required vehicle signal of the application is identified with a corresponding node path name and unique identifier as taught by Ramnani. Using node path names and corresponding unique identifiers to identify vehicle signals and their semantic information contained in the signal catalogs provides the benefit of guaranteeing unique identification of a vehicle signal, reflects the hierarchical relationships of ECUs and sensors in a vehicle, and incorporates information needed for human-readable data exchange, such as data types of the sensor (Ramnani: [0036],[0047], and [0055]-[0057]).
Regarding claim 8, the combination of Mendez Rodriguez in view of Ramnani teaches The method of claim 1. Mendez Rodriguez further teaches wherein the application is developed based on the reference signal catalog ([0055] – “a console implemented by service interface 108 may provide clients 120 with available sensors included in a vehicle that may be used to design a new synthetic sensor. For example, physical sensor list 106 may store updated lists of available sensors that are included in various types of vehicles that subscribe to the synthetic sensor service 102.”).
Regarding claim 9, the combination of Mendez Rodriguez teaches The method of claim 1. Mendez Rodriguez further teaches wherein the manifest further comprises a second [signal] corresponding to an optional signal for the application ([0062] – “synthetic sensor package 202 includes annotations 208. In some embodiments, annotations may include required inputs for a synthetic sensor, optional inputs for the synthetic sensor”; [0063] – “Mappings 204 may define data flow between the required and optional inputs”).
Mendez Rodriguez does not, however Ramnani teaches a second node path name corresponding to a second signal ([0036] – “The signal catalog may follow a Vehicle Signal Specification (VSS) naming guide and may be accessible using qualified names (e.g., Vehicle.Powertrain.CombustionEngine.FuelType). There may be one unique path per signal of the signal catalog”; [0053] – “When creating the data collection scheme, the OEMs or the customer 122 can specify a subset of the signals from the signal catalog that they wish to collect”).
It would have been obvious to one of ordinary skill in the art to have modified the teachings of Mendez Rodriguez such that each vehicle signal of the application is identified with a corresponding node path name as taught by Ramnani. Using node path names and corresponding unique identifiers to identify vehicle signals provides the benefit of guaranteeing unique identification of a vehicle signal and reflects the hierarchical relationships of ECUs and sensors in a vehicle (Ramnani: [0036],[0047], and [0055]-[0057]).
Regarding claim 10, Mendez Rodriguez teaches A computing device ([0149] – “FIG. 15 is a block diagram illustrating an example computer system that implements some or all of the techniques described herein”) for validating an application, comprising: a communication subsystem; a processor; wherein the communication subsystem and the processor cooperate ([0150] – “computer system 15 00 includes one or more processors 1510 coupled to a system memory 1520 via an input/output (I/O) interface 1530. Computer system 1500 further includes a network interface 1540 coupled to I/O interface 1530.”; [0152] – “System memory 1520 may be configured to store program instructions and data accessible by processor(s) 1510A-1510N […] program instructions and data implementing one or more desired functions, such as those methods, techniques, and data described above, are shown stored within system memory 1520 as code”; [0153] – “I/O interface 1530 may be configured to coordinate I/O traffic between processors 1510A-1510N, system memory 1520, and any peripheral devices in the device, including network interface 1540”) to: perform the method of claim 1. Accordingly, claim 10 is rejected as being unpatentable over Mendez Rodriguez in view of Ramnani for the same reasons presented with respect to claim 1.
Claims 11-13 and 17-18 recite substantially the same additional limitations as claims 2-4 and 8-9, respectively. Accordingly, claims 11-13 and 17-18 are rejected as being unpatentable over Mendez Rodriguez in view of Ramnani for the same reasons presented with respect to claims 2-4 and 8-9 above.
Regarding claim 19, Mendez Rodriguez teaches A computer readable medium having stored thereon executable code for execution by a processor of a computing device, the executable code comprising instructions ([0155] – “system memory 1520 may be one embodiment of a computer-readable (i.e., computer-accessible) medium configured to store program instructions and data as described above for implementing embodiments of the corresponding methods, systems, and apparatus”) for: performing the method of claim 1. Accordingly, claim 19 is rejected as being unpatentable over Mendez Rodriguez in view of Ramnani for the same reasons presented with respect to claim 1.
Claim 20 recites substantially the same additional limitations as claim 2. Accordingly, Claim 20 is rejected as being unpatentable over Mendez Rodriguez in view of Ramnani for the same reasons presented with respect to claim 2 above.
Claims 5-7 and 14-16 are rejected under 35 U.S.C. 103 as being unpatentable over Mendez Rodriguez in view of Ramnani as applied to claims 1 and 10 above, and further in view of Singh et al. (U.S. Pub. No. 2016/0359628), hereinafter Singh.
Regarding claim 5, the combination of Mendez Rodriguez in view of Ramnani teaches The method of claim 1. Ramnani further teaches further comprising, prior to the enhancing, [assigning] a respective unique identifier for each respective node path name in the reference signal catalog and the second signal catalog ([0036] – “There may be one unique path per signal of the signal catalog wherein in some embodiments the data collection scheme controller 108 may assign the signal a unique signal id. The data collection scheme controller 108 of the data plane 104 may guarantee that the signal id be unique across the signal catalog. In some embodiments, customers 122a, 122n may create multiple signal catalogs. The multiple signal catalogs may encompass signal attributes that may be used to model different types of vehicles. […] multiple signal catalogs may be used to represent different subsets of signals for a same vehicle type.”); [0048] – “The model configuration may be a collection of signals chosen from the signal catalog that are applicable to that specific vehicle model.”; [0053] – “The data collection scheme controller 108 may receive from the customer various data collection schemes or configurations that instruct vehicles what data to collect from the vehicle […] When creating the data collection scheme, the OEMs or the customer 122 can specify a subset of the signals from the signal catalog that they wish to collect”. The signal catalog is already created/being managed by the data scheme controller 108 when the data collection scheme (“application”) is being created, i.e., before enhancing the application manifest.).
It would have been obvious to one of ordinary skill in the art to have modified the teachings of Mendez Rodriguez such that each vehicle signal in the signal catalogs is identified with a corresponding node path name and unique identifier in the signal catalogs as taught by Ramnani. Using node path names and corresponding unique identifiers to identify vehicle signals contained in the signal catalogs provides the benefit of guaranteeing unique identification of a vehicle signal and reflects the hierarchical relationships of ECUs and sensors in a vehicle (Ramnani: [0036],[0047], and [0055]-[0057]).
The combination of Mendez Rodriguez in view of Ramnani fails to expressly teach computing the respective unique identifier for each node path name corresponding to each signal.
However, Singh teaches computing a respective unique identifier based on attributes of each sensor signal, where the attributes include at least a unique identifier of the sensor signal ([0072] – “Each of the sensors 204.sub.A, 210, 226 can include a respective unique sensor identifier on each of reports 244 it sends to collector 118, to allow collector 118 to determine which sensor sent the report”; [0073]-[0075] – “The message 1 (306) includes at least one unique identifier of the sensor 302 or the host component of the sensor 302. In response to receiving the attributes of the sensor 302, the control server 304 can determine a hash value, using a one-way hash function and a secret key, based upon the attributes of the sensor 302. In some examples, the hash value is a fixed length hash value that is independent from the length of an input string to generate the hash value. The one-way hash function includes, HMAC, MD2, MD4, MD5, SHA-1, SHA-2, and SHA-3.The control server 304 can then send the hash value to the sensor 302 and designate the hash value as a sensor ID of the sensor. In response to receiving the sensor ID, the sensor 302 incorporates the sensor ID in all subsequent communication messages. Other components, nodes or sensors of the network can receive communication message(s) from the sensor 302, and further verify the validity of the sensor 302.”; [0083] – “determine a sensor ID for the sensor. The sensor ID can be used to uniquely identify the sensor in the network. The sensor ID is a hash value determined using a one-way hash function, a secret key, and the at least one unique identifier of the sensor”; [0017] – “assign unique identifications (IDs) for the sensors, and analyze data collected from the sensors to monitor and troubleshoot […] The attributes of the sensor can include at least one unique identifier of the sensor”).
Singh is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of uniquely identifying signals of sensor data. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the assignment of a unique identifier to each signal, e.g., a sensor, in the signal catalogs as taught by Ramnani, such that each unique identifier is computed, e.g., using a hash function, based on attributes including a unique identifier of the sensor as taught by Singh, where the attributes of each signal include a unique node path name identifying the signal as taught by Ramnani. Computing a hash as an identifier for a sensor based on attributes of the sensor enables unique identification of the sensor and enables verification of the validity of the sensor using the hash (Singh: [0075] and [0083]).
Regarding claim 6, the combination of Mendez Rodriguez in view of Ramnani and Singh teaches The method of claim 5. Ramnani further teaches wherein the respective unique identifier [corresponds to] the respective node path name and semantic information of the respective node path name ([0036] – “There may be one unique path per signal of the signal catalog wherein in some embodiments the data collection scheme controller 108 may assign the signal a unique signal id. The data collection scheme controller 108 of the data plane 104 may guarantee that the signal id be unique across the signal catalog.”; FIG. 3, see box labeled 352 – the signal represented by Drivetrain.Transmission.Speed in the hierarchical structure of a signal catalog includes “semantic information” including type “sensor” and unit “kn/h”; [0055] – “FIG. 3 illustrates a graphical view of an example vehicle model configuration having a hierarchical tree structure that uses a vehicle signal catalog”; [0056] – “the model configuration 300 contains all or a subset of signal types in a signal catalog. The signals provided by the signal catalog may be arranged in a hierarchical structure as depicted in the model configuration 300 and may include various signal types such as attribute, branch, sensor, and actuator.” There is one unique path (“node path name”) per signal, where the node path names corresponding to the signals include semantic information, and each signal is assigned a unique signal id; thus, the unique signal id is unique for and corresponds to the path of the signal and semantic information of the signal included in the catalog.).
It would have been obvious to one of ordinary skill in the art to have modified the teachings of Mendez Rodriguez such that each vehicle signal of the signal catalogs is identified with a corresponding node path name and unique identifier as taught by Ramnani. Using node path names and corresponding unique identifiers to identify vehicle signals and their semantic information contained in the signal catalogs provides the benefit of guaranteeing unique identification of a vehicle signal, reflects the hierarchical relationships of ECUs and sensors in a vehicle, and incorporates information needed for human-readable data exchange, such as data types of the sensor (Ramnani: [0036],[0047], and [0055]-[0057]).
Ramnani does not, however, Singh teaches the respective unique identifier is computed as a hash of attributes of the signal including at least a unique identifier of the sensor (([0072] – “Each of the sensors 204.sub.A, 210, 226 can include a respective unique sensor identifier on each of reports 244 it sends to collector 118, to allow collector 118 to determine which sensor sent the report”; [0073]-[0075] – “The message 1 (306) includes at least one unique identifier of the sensor 302 or the host component of the sensor 302. In response to receiving the attributes of the sensor 302, the control server 304 can determine a hash value, using a one-way hash function and a secret key, based upon the attributes of the sensor 302. In some examples, the hash value is a fixed length hash value that is independent from the length of an input string to generate the hash value. The one-way hash function includes, HMAC, MD2, MD4, MD5, SHA-1, SHA-2, and SHA-3.The control server 304 can then send the hash value to the sensor 302 and designate the hash value as a sensor ID of the sensor. In response to receiving the sensor ID, the sensor 302 incorporates the sensor ID in all subsequent communication messages. Other components, nodes or sensors of the network can receive communication message(s) from the sensor 302, and further verify the validity of the sensor 302.”; [0083] – “determine a sensor ID for the sensor. The sensor ID can be used to uniquely identify the sensor in the network. The sensor ID is a hash value determined using a one-way hash function, a secret key, and the at least one unique identifier of the sensor”; [0017] – “assign unique identifications (IDs) for the sensors, and analyze data collected from the sensors to monitor and troubleshoot […] The attributes of the sensor can include at least one unique identifier of the sensor”).
It would have been obvious to one of ordinary skill in the art to have modified the assignment of a unique identifier to each signal, e.g., a sensor, in the signal catalogs with a corresponding node path name and semantic information of the node path name as taught by Ramnani, such that each unique identifier is computed using a hash function based on attributes including at least a unique identifier of the sensor as taught by Singh, where the attributes of each signal used for hashing would include the unique node path name identifying the signal and semantic information of the node path name as taught by Ramnani. Computing a hash as an identifier for a sensor based on attributes of the sensor (e.g., the node path name and semantic information taught by Ramnani) enables unique identification of the sensor and enables verification of the validity of the sensor using the hash (Singh: [0075] and [0083]).
Regarding claim 7, the combination of Mendez Rodriguez in view of Ramnani and Singh teaches The method of claim 6. Singh further teaches wherein the hash is a 64-bit hash ([0024] – “A length of the fixed-length hash value can be at least 64-bit.”).
It would have been obvious to one of ordinary skill in the art to have modified the assignment of a unique identifier to each signal, e.g., a sensor, in the signal catalogs with a corresponding node path name and semantic information of the node path name as taught by Ramnani, such that each unique identifier is computed using a hash function as a 64-bit hash based on attributes including at least a unique identifier of the sensor as taught by Singh, where the attributes of each signal used for hashing would include the unique node path name identifying the signal and semantic information of the node path name as taught by Ramnani. Computing a hash as an identifier for a sensor based on attributes of the sensor (e.g., the node path name and semantic information taught by Ramnani) enables unique identification of the sensor and enables verification of the validity of the sensor using the hash (Singh: [0075] and [0083]).
Claims 14-16 recite substantially the same additional limitations as claims 5-7, respectively. Accordingly, claims 14-16 are rejected as being unpatentable over Mendez Rodriguez in view of Ramnani and further in view of Singh for the same reasons presented with respect to claims 5-7 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Elsbaugh et al. (U.S. Pub. No. 2025/0060972) teaches a method for evaluating application metadata (such as manifest files), where a manifest file may include a list of required elements and a list of optional elements and specifies components of a computer device the application requires access to when installed (see Abstract, [0002], [0024]-[0025], and [0045]-[0046]).
Slik et al. (U.S. Pub. No. 2020/0145509) teaches generating a handle to identify sensor data, where the handle is encoded using a hash based on various information of the sensor data, such as identification information of the sensor and a data type of the information comprised within the sensor data, where the handle is used to verify the integrity of the sensor data (see [0051], [0062]).
Mowatt et al. (U.S. Pub. No. 2019/0384749) teaches a method for deploying an application in which, the application is validated using a validation manifest to ensure the platform’s capabilities, e.g., inputs and outputs, conform to an expected scheme, and once verified, the application is made available for installation (see [0019]-[0020]).
ABADIE et al. (U.S. Pub. No. 2022/0303139) teaches a method for installing a computing component in an electronic device in a vehicle, comprising received a manifest including a hash value of the computing component and installing the computing component only in the case of a positive check of the hash value (see Abstract).
WINZELL (U.S. Pub. No. 2023/0367778) teaches a method for vehicle unique signal to vehicle general signal matching, such that proprietary vehicle signals can be mapped and translated to corresponding Vehicle Signal Specification (VSS) signals (see Abstract).
NPL Document titled “Doing a hash by hand/mathematically” teaches simple hashes are able to be computed by a person (see response from Jerry Coffin on Page 1).
Aust (NPL Document titled “Vehicle API and Service Catalog for Next Generation Mobility”) teaches the Vehicle Signal Specification (VSS) was developed as a standard within the automotive industry that specifies a signal set that can be used among OEMs, where the VSS is a hierarchical data model organized as a tree including vehicle signals (see Section III, IV, and V).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JENNIFER MARIE GUTMAN whose telephone number is (703)756-1572. The examiner can normally be reached M-F: 8:00 am - 4:00 pm.
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, Kevin Young can be reached at 571-270-3180. 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.
/JENNIFER MARIE GUTMAN/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights