Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
2. This office action has been issued in response to amendment filed on 11/10/2025. Claims 15, 17, 25 and claim 27 have been amended. Claims13-32 are pending, of which claims, of which claim 13, 23 and 32 are in independent form.
3. Accordingly, this action has been made FINAL Amended claim 15, 17, 25 and 27 have been rejected with new reference.
Status of Claims
4. Claims 13-32 are pending, of which claims, of which claim 13, 23 and 32 are in independent form.
The Office's Note:
5. The Office has cited particular paragraphs / columns and line numbers in the reference(s) applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim(s), other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the cited passages as taught by the prior art or relied upon by the Examiner.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
6. The claim 20 in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
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.
7. Claim 13-14, 16, 18-24, 26, and 28-32 are rejected under 35 U.S.C. 103 as being unpatentable over Ohmert (US 20180137033– hereinafter Ohmert) and further in view of Amirpour (US 20130226394 – hereinafter Amirpour).
Claim 13 is rejected, Ohmert teaches a method for testing a software application and data related to the software application of a vehicle, the method comprising (Ohmert, abstract and summary):
receiving a first vehicle configuration (Ohmert, US 20180137033, para [0018] see vehicle profile. Para [0023], the vehicle profile may be used to determine whether the application code has access to certain types of vehicle parameters.) ;
receiving a test parameter, the test parameter comprising a technical property of the first vehicle configuration(Ohmert, para [0005], see vehicle parameter. Para [0023], the vehicle profile may be used to determine whether the application code has access to certain types of vehicle parameters.);
specifying a setpoint value for the received test parameter (Ohmert, para [0021-0023], see threshold.);
determining a first software identifier as a function of the first vehicle configuration(Ohmert, para [0021-0022], see vehicle operation, interior light on/off, engine temperature) ;
specifying the software application and the data related to the software application by means of the first software identifier (Ohmert, para [0021-0022] The series of vehicle parameter values may be provided to the application code or may be converted into a vehicle operation conception that can be understood by the application code can understand (e.g., the application code may understand “on” for an interior light as opposed to a binary “1” used by a vehicle computing device to represent “on”). In an example, the vehicle parameter signal may be a series of values, such as engine temperature values over time. In an example, the vehicle parameter signal may be filtered based upon a set of thresholds (e.g., the application code may merely request engine temperature values over a certain threshold indicative of an undesirable engine temperature increase).);
determining an actual value for the received test parameter using the specified software application or the specified data related to the software application(Ohmert, para [0021-0023], see fuel consumption values of the vehicle, light status information);
testing whether the determined actual value of the received test parameter and the determined setpoint value of the received test parameter match (Ohmert, para [0021-0022 and 0035], see filter and threshold); and
providing a test result of the received test parameter for the software application and the data related to the software application of the vehicle as a function of the test of whether the determined actual value of the received test parameter and the determined setpoint value of the received test parameter match(Ohmert, para [0024-0025], see result. Para [0005, 0022-0023], see alert, parameter signal and application code).
The Office would like to use prior art Amirpour to back up Ohmert to further teach limitation
determining an actual value for the received test parameter using the specified software application or the specified data related to the software application(Amirpour, US 20130226394, para [0018], see vehicle test device for measuring at least one vehicle parameter. Para [0032-0033], see value and calibration)
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Amirpour into Ohmert to measure t least one vehicle parameter. The functions such as diagnostic functions, calibration functions, etc., of the control device are integrated in the test unit. Hence an integrated inspection flow is realized. The software for control device communication is remotely controlled by the test device software in efficient manner. The entire test process can be carried out automatically, and faulty operations can be avoided, while avoiding incorrect adjusting of vehicle sensors. The work quality and efficiency of the test unit can be increased as suggested by Amirpour (See abstract and summary).
Claim 14 is rejected for the reasons set forth hereinabove for claim 13, Ohmert and Amirpour teach the method as claimed in claim 13, wherein the data related to the software application comprises calibration data or coding data of the software application(Ohmert, para [0021-0022], see vehicle operation, interior light on/off, engine temperature. Amirpour, para [0032-0033], see value and calibration).
Claim 16 is rejected for the reasons set forth hereinabove for claim 13, Ohmert and Amirpour teach the method as claimed in claim 13, wherein the setpoint value for the received test parameter is determined in a rule-based manner by means of predefined rules for the received test parameter (Ohmert, para [0021-0023], see threshold.).
Claim 18 is rejected for the reasons set forth hereinabove for claim 13, Ohmert and Amirpour teach the method as claimed in claim 13, wherein determining the first software identifier as a function of the first vehicle configuration comprises(Ohmert, para [0021-0022], see vehicle operation, interior light on/off, engine temperature):
if no first software identifier is determined or multiple first software identifiers are determined :terminating the testing of the software application and the data related to the software application of the vehicle; and providing a test result, wherein the test result indicates an error in determining the first software identifier (Ohmert, para [0023], the vehicle profile may be used to determine whether the application code has access to certain types of vehicle parameters. For example, if the vehicle profile indicates that the vehicle parameter is allowed to be accessed by the application, then the vehicle parameter may be simulated. Otherwise, if the vehicle profile indicates that the vehicle parameter is not allowed to be accessed by the application, then the vehicle parameter may not be simulated and an alert or error may be provided to the application code and/or the application developer.).
Claim 19 is rejected for the reasons set forth hereinabove for claim 13, Ohmert and Amirpour teach the method as claimed in claim 13, wherein determining the first software identifier as a function of the first vehicle configuration comprises(Ohmert, para [0021-0022], see vehicle operation, interior light on/off, engine temperature):
if exactly one first software identifier is determined: (Ohmert, para [0021-0022], see vehicle operation, interior light on/off, engine temperature.)
specifying the software application and the data related to the software application by means of the first software identifier(Ohmert, para [0021-0022] The series of vehicle parameter values may be provided to the application code or may be converted into a vehicle operation conception that can be understood by the application code can understand (e.g., the application code may understand “on” for an interior light as opposed to a binary “1” used by a vehicle computing device to represent “on”). In an example, the vehicle parameter signal may be a series of values, such as engine temperature values over time. In an example, the vehicle parameter signal may be filtered based upon a set of thresholds (e.g., the application code may merely request engine temperature values over a certain threshold indicative of an undesirable engine temperature increase);
determining an actual value for the received test parameter using the specified software application and the specified data related to the software application(Ohmert, para [0021-0023], see fuel consumption values of the vehicle, light status information);
testing whether the determined actual value of the received test parameter and the determined setpoint value of the received test parameter match(Ohmert, para [0021-0022 and 0035], see filter and threshold); and
providing the test result of the received test parameter for the software application and the data related to the software application of the vehicle as a function of the test of whether the determined actual value of the received test parameter and the determined setpoint value of the received test parameter match(Ohmert, para [0024-0025], see result. Para [0005, 0022-0023], see alert, parameter signal and application code).
Claim 20 is rejected for the reasons set forth hereinabove for claim 13, Ohmert and Amirpour teach the method as claimed in claim 13, wherein specifying the software application and the data related to the software application by means of the first software identifier comprises(Ohmert, para [0021-0022]):
virtually deploying the software application and the data related to the software application as a function of the first vehicle configuration(Ohmert, para [0026], see a simulation environment.).
Claim 21 is rejected for the reasons set forth hereinabove for claim 20, Ohmert and Amirpour teach the method as claimed in claim 20, wherein virtually deploying the software application and the data related to the software application as a function of the first vehicle configuration comprises(Ohmert, para [0026], see a simulation environment.):
evaluating a Boolean logic associated with the software application or the data related to the software application to specify the software application or the data related to the software application(Ohmert, para [0028], see a simulation result user interface.).
Claim 22 is rejected for the reasons set forth hereinabove for claim 13, Ohmert and Amirpour teach the method as claimed in claim 13, wherein determining the actual value for the received test parameter using the specified software application or the specified data related to the software application comprises(Amirpour, para [0018], see vehicle test device for measuring at least one vehicle parameter. Para [0032-0033], see value and calibration):
executing at least one function of the specified software application to calculate the actual value for the received test parameter(Ohmert, para [0033], see speed data).
As per claim 23, this is the medium claim to method claim 13. Therefore, it is rejected for the same reasons as above.
As per claim 24, this is the medium claim to method claim 14. Therefore, it is rejected for the same reasons as above.
As per claim 26, this is the medium claim to method claim 16. Therefore, it is rejected for the same reasons as above.
As per claim 28, this is the medium claim to method claim 18. Therefore, it is rejected for the same reasons as above.
As per claim 29, this is the medium claim to method claim 19. Therefore, it is rejected for the same reasons as above.
As per claim 30, this is the medium claim to method claim 20 and claim 21. Therefore, it is rejected for the same reasons as above.
As per claim 31, this is the medium claim to method claim 22. Therefore, it is rejected for the same reasons as above.
As per claim 32, this is the system claim to method claim 13. Therefore, it is rejected for the same reasons as above.
8. Claim 15, 17, 25 and 27 are rejected under 35 U.S.C. 103 as being unpatentable over Ohmert (US 20180137033– hereinafter Ohmert), in view of Amirpour (US 20130226394 – hereinafter Amirpour) and further in view of Rork (US 20150193220 – hereinafter Rork).
With respect to claim 15, Ohmert and Amirpour do not teach all limitations of claim 13.
However, Rork teaches these limitations.
Claim 15 is rejected for the reasons set forth hereinabove for claim 13, Ohmert and Amirpour teach the method as claimed in claim 13, wherein the first vehicle configuration comprises a unique identifier of a vehicle type and technical properties of the vehicle; wherein the unique identifier of the vehicle type and the technical properties of the vehicle uniquely specify a first variant of the vehicle associated with a first geographic region(Rork, US 20150193220, fig. 3 and para [0035], FIG. 3 illustrates an exemplary topic tree 206 for use in updating software versions of a VCS 1. The topic tree 206 may be used, for example, to allow the service delivery network 200 to define a topic 202 structure for performing vehicle 31 software updates. A VCS 1, such as a telematics unit of a vehicle 31, may subscribe to nodes of the topic tree 206 that correspond to the installed region, software/firmware version, features, configuration file version of the vehicle 31, etc. It should be noted that the particular layout of the exemplary topic tree 206 is for purpose of illustration only, and other layouts of topic tree 206 may be used. For example, other topic trees 206 may be used by the service delivery network 200 that have more, fewer or different levels of categorization. Para [0036], Referring to the topic tree 206 of FIG. 3, a region node 300 of the topic tree 206 may indicate a region for which the sub-topic 202 nodes under the region node 300 may relate. In some cases, the region nodes 300 may represent different regional market areas in which vehicles 31 may be sold, such as North America, Europe, and Asia Pacific. In other examples the region nodes 300 may relate to other geographical areas, such as countries, states, postal codes, and telephone area codes, as some other examples. By segmenting the topic tree 206 by region, the service delivery network 200 may accordingly publish different information for vehicles 31 associated with different regions. Para [0037], Under each region node 300, the topic tree 206 may include one or more vehicle-specific nodes 302, where each vehicle-specific node 302 relates to a vehicle 31 associated with the parent regional node 300. As one possibility, the service delivery network 200 may create vehicle-specific nodes 302 for vehicles 31 according to VIN or other unique identifier of vehicles 31 that register with the service delivery network 200 as belonging to the particular region. Sub-nodes to the vehicle-specific nodes 302 may be used to further organize topics 202 configured for communication to and from the individual vehicles 31. Para [0038-0039], For instance, under the vehicle-specific nodes 302, the topic tree 206 may further include one or more vehicle topic nodes 304 for communication to the specific vehicles 31. A vehicle 31 may subscribe to the vehicle topic node 304 that correspond to the VIN or other unique identifier of the vehicle 31, so that the vehicle 31 may be able to receive messages 204 in topics 202 that specifically relate to the vehicle 31 itself. Paragraph [0040-0041], a feature may refer to a grouping of configuration parameters applicable to the specified vehicle 31 included in the topic tree 206. A feature may, for example, represent settings to implement an available connected service (e.g., MY FORD MOBILE) or a customer-specific collection of settings (e.g., a suite of features requested to be enabled and/or disabled for use by a particular fleet purchaser). As yet a further example, a vehicle 31 may subscribe to a firmware update vehicle topic node 304-D for receiving messages 204 in a topic 202 directed to particular vehicles 31 and relating to updates to the firmware of the vehicle 31. Para [0042-0046], Moreover, under each region node 300 the topic tree 206 may include one or more hardware version topic nodes 308, where each hardware version topic node 308 relates to a installed vehicle 31 hardware version that may be shared by multiple vehicles 31 (e.g., a version of the VCS 1 hardware). Para [0047-0050].).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Rork into Ohmert and Amirpour to subscribe a first subject tree theme, which is associated with an installed vehicle-software component version and identifying a desired software component version based on a published notice that is accessed from the first theme. A software component is updated using a software update that is retrieved from a second subject tree theme that is associated with software updates for the installed version, if the version and the installed version differ.as suggested by Rok (See abstract and summary).
Claim 17 is rejected for the reasons set forth hereinabove for claim 15, Ohmert and Amirpour teach the method as claimed in claim 15, wherein the first software identifier uniquely identifies the software application and the data related to the software application of one or more components of the first vehicle configuration(Ohmert, para [0021-0022], see vehicle operation, interior light on/off, engine temperature. Para [0026], vehicle speed of 50 mph, a radio status of “on”, a parking brake status of “off”, a left turn signal status of “off”, a right turn signal status of “off”, a climate control temperature of 75 degrees, a fan speed of 2, etc. Rork, fig. 3 and para [0035-0050].).
As per claim 25, this is the medium claim to method claim 15. Therefore, it is rejected for the same reasons as above.
As per claim 27, this is the medium claim to method claim 17. Therefore, it is rejected for the same reasons as above.
Response to Argument
9. The Office will maintain that claim 20 invokes 112(f).
10. With respect to claims 13, 23 and 32, On pages 11-14, applicant argued that Ohmert does not disclose “determining a first software identifier as a function of the first vehicle configuration; specifying the software application and the data related to the software application by means of the first software identifier; determining an actual value for the received test parameter using the specified software application or the specified data related to the software application”.
The Office respectfully disagreed. On paragraph [0021-0022], Ohmert teaches parameter signals such as ‘interior light’, ‘engine temperature’. Furthermore, on para [0026], Ohmert teaches parameter signals such as ‘vehicle speed’, ‘parking brake’, ‘windshield status’, ‘left turn signal status’. These parameter signal ‘interior light’, ‘engine temperature’, vehicle speed’, ‘parking brake’, ‘windshield status’, ‘left turn signal status’, etc. which is “software identifier as a function of the first vehicle configuration” which means “determining a first software identifier as a function of the first vehicle configuration”. Furthermore, in para [0029-0031] and fig. 3, Ohmert teaches “the user may use vehicle input component user interfaces to specify various vehicle input parameter signals. For example, the user may specify an air temperature through an air temperature user interface 306, a parking brake status through a parking brake status user interface 308, a vehicle speed through a vehicle speed user interface 310, a cruise control setting through a cruise control user interface 312, an emergency lights status through an emergency lights status user interface 314, etc. “ which means “determining a first software identifier as a function of the first vehicle configuration”.
On paragraph [0021-0022], Ohmert teaches “The series of vehicle parameter values may be provided to the application code or may be converted into a vehicle operation conception that can be understood by the application code can understand (e.g., the application code may understand “on” for an interior light as opposed to a binary “1” used by a vehicle computing device to represent “on”).” which means the application code of interior light will be set which means “specifying the software application and the data related to the software application by means of the first software identifier”. In addition, in para [0029-0031] and fig. 3, Ohmert teaches “the user may use vehicle input component user interfaces to specify various vehicle input parameter signals. For example, the user may specify an air temperature through an air temperature user interface 306, a parking brake status through a parking brake status user interface 308, a vehicle speed through a vehicle speed user interface 310, a cruise control setting through a cruise control user interface 312, an emergency lights status through an emergency lights status user interface 314, etc. “ which means “specifying the software application and the data related to the software application by means of the first software identifier”
On paragraph [0021-0022], Ohmert teaches “At 108, the vehicle parameter signal may be provided as input to the application code to create a simulation result (e.g., the application code may perform some function based upon a determination that the fuel consumption is above a threshold, such as by providing an alert to a user or sending the alert to a remote server for further data collection and processing). In an example, the vehicle parameter signal may be formatted into a vehicle operation concept. For example, the vehicle parameter signal may comprise light status information, such as a binary “1” or “0” for “on” and for “off”, that the application code does not understand, and thus the binary information may be translated into “on” or “off”, which the application code can understand.” which mean application code was tested and produced a result which means ‘determining an actual value for the received test parameter using the specified software application or the specified data related to the software application’. Moreover, Ohmert teaches in para [0032] and fig. 3, “Simulating and providing the vehicle parameters to the application may result in a simulation result that is provided to the application developer through a simulation result user interface 316. For example, the application may request that the vehicle profile display an internet radio user interface through the vehicle display. The vehicle profile may format the internet radio user interface based upon a display property that enforces a black and white color scheme, binds the user interface to a top half of the vehicle display, etc.). The internet radio user interface may be displayed through a display of application user interface 318 so that the application developer can visualize how the internet radio user interface of the application will appear to a driver through the vehicle display. Because the application may modify various vehicle features, such as a speaker volume, vehicle feature data may be provided through a display of vehicle feature data user interface 320 so that the application developer can test whether the application is correctly modifying vehicle features (e.g., a speaker volume value may be provided through the display of vehicle feature data user interface 320).” which means ‘determining an actual value for the received test parameter using the specified software application or the specified data related to the software application’.
In conclusion, Ohmert teaches “determining a first software identifier as a function of the first vehicle configuration; specifying the software application and the data related to the software application by means of the first software identifier; determining an actual value for the received test parameter using the specified software application or the specified data related to the software application”.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUY KHUONG THANH NGUYEN whose telephone number is (571)270-7139. The examiner can normally be reached Monday - Friday 0800-1630.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lewis Bullock can be reached at 5712723759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DUY KHUONG T NGUYEN/ Primary Examiner, Art Unit 2199
Prosecution Insights