Prosecution Insights
Last updated: April 19, 2026
Application No. 18/173,438

SCHEDULING VEHICLE SOFTWARE UPDATES

Final Rejection §103
Filed
Feb 23, 2023
Examiner
WU, DAXIN
Art Unit
2191
Tech Center
2100 — Computer Architecture & Software
Assignee
Volvo Truck Corporation
OA Round
4 (Final)
85%
Grant Probability
Favorable
5-6
OA Rounds
2y 6m
To Grant
99%
With Interview

Examiner Intelligence

Grants 85% — above average
85%
Career Allow Rate
529 granted / 620 resolved
+30.3% vs TC avg
Strong +19% interview lift
Without
With
+18.6%
Interview Lift
resolved cases with interview
Typical timeline
2y 6m
Avg Prosecution
26 currently pending
Career history
646
Total Applications
across all art units

Statute-Specific Performance

§101
14.8%
-25.2% vs TC avg
§103
55.4%
+15.4% vs TC avg
§102
4.9%
-35.1% vs TC avg
§112
13.2%
-26.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 620 resolved cases

Office Action

§103
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 . DETAILED ACTION This Office action is in response to the amendment filed on November 13, 2025. Claims 1-13 and 15-16 are pending. Claim 1 has been amended. Claim 14 was previously canceled. Response to Arguments Applicant's arguments have been considered but are moot in view of new ground(s) of rejection. In these arguments applicant relies on the amended claims and not the original ones. See below rejections under 35 USC § 103 for response to arguments. 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 of this title, 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-5, and 8-13 are rejected under 35 U.S.C. 103 as being unpatentable over US 9,086,941 (hereinafter "Siegal”), in view of US 2018/0107473 (hereinafter “Ahmed”), and further in view of CN 113227967 (hereinafter “Ma”) In the following claim analysis, Applicant’s claim language is in bold text and Examiner’s explanations are enclosed in square brackets. As to claim 1, Siegal discloses A computer-implemented method for scheduling a vehicle software update in a first vehicle (Siegal, Abstract, A system and method for providing predictive software upgrades … providing the one or more time periods determined, to the user for selection of one or more time period; receiving a selected one or more time period for upgrading of the software), the method comprising: associating a probability of the first vehicle having an updateable operational state with one or more time periods (Siegal, col. 2, lines 46-49, determining one or more time period when a device having software to be upgraded will be in an off state for long enough for updating of software to take place without the device changing state from off to on; col. 10, lines 32-41, historic data provided by the virtual vehicle may be used to provide an average stop duration and standard deviation of stopped time for a frequented location such as home or an office building. This same historic information provides information about typical timing of trips to this location, along with a confidence interval. When confidence is sufficiently high, the trip start and end times are presented to a selection algorithm, which determines whether the upgrade can successfully be completed in the allotted time required for the upgrade), wherein the probability of the first vehicle being updateable is determined based at least partly on data representing behavioral states of one or more other vehicles having a relation to the first vehicle in terms of vehicle usage characteristics (Siegal, col. 2, lines 60-67, querying a virtual vehicle [another vehicle] application that simulates a real vehicle to determine one or more time period when the vehicle will be in an off state for long enough for updating of software to take place without the vehicle operating status being changed; col. 10, lines 25-29, the identification of the vehicle, date and time when the vehicle is turned on, when the vehicle stops, and other vehicle use history are used by the service application 128 to calculate the list of possible times to upgrade the vehicle control module)); scheduling a pending software update until the next time period of the one or more time periods where the probability of the first vehicle having an updateable operational state meets a software update condition (Siegal, col. 10, lines 12-17, The service application 128 is capable of taking the time required for upgrading of the vehicle control module and searching for times when the vehicle will be off for a time period that is more than the required time for upgrading of the vehicle control module; Fig. 2, col. 12, lines 1-6, more than one time option may be selected. In such a situation, the first available time slot would be used, however, if the first selected time slot becomes invalid prior to starting the update process, then the next available selected timeslot will be used); and, enabling the software update (Siegal, col. 12, lines 38-43, if the user confirms the selected software upgrade time, at the selected upgrade time, the service application 128 instructs the vehicle control module update application 38 to upgrade the vehicle control module with the vehicle control software stored within the vehicle storage device 40); Siegal does not appear to explicitly disclose wherein the updateable operational state is a non-stationary behavior state of the first vehicle, wherein the non-stationary behaviour state of the first vehicle indicates that the first vehicle is in motion. However, in an analogous art to the claimed invention in the field of vehicle software update, Ahmed teaches wherein the updateable operational state is a non-stationary behavior state of the first vehicle (Ahmed, Fig. 3, ¶ 36, the method may begin while the vehicle is in the non-stationary state … a vehicle user may be driving the vehicle 24 and the gateway module 46 may receive a notification of a vehicle system or software update (step 305) via an over-the-air communication … the notification may be simply receiving the update), wherein the non-stationary behaviour state of the first vehicle indicates that the first vehicle is in motion (Ahmed, ¶ 22, The non-stationary state may include instances where the vehicle 24 is moving; ¶ 36, The method may begin while the vehicle is in the non-stationary state. For example, a vehicle user may be driving the vehicle 24). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Siegal’s system with the system taught by Ahmed including that the updateable operational state is a non-stationary behavior state of the vehicle. The modification would be obvious because one of ordinary skill in the art would be motivated to determine whether a vehicle is in the non-stationary state, which can allow the vehicle to receive a software update and allow a vehicle use continue to drive the vehicle (Ahmed, ¶ 36). Siegal as modified does not appear to explicitly disclose determining that the probability meets the software update condition; and performing the software update to the first vehicle while the probability of having the updateable operational state meets the software update condition. However, in an analogous art to the claimed invention in the field of vehicle software update, Ma teaches determining that the probability meets the software update condition (Ma, pg. 29, the send to the last paragraph, when the determined to-be-upgraded file for upgrading auxiliary function, control software the vehicle is in the motion state, the upgrading control device 110 can control the human-computer interface display prompt information D4, the prompt information D4 is used for prompting the user during the vehicle movement; Upgrading the auxiliary function may lead to risk. … the user can select to bear the risk, not actively parking, so that the vehicle upgrading the auxiliary function in the moving state); and performing the software update to the first vehicle while the probability of having the updateable operational state meets the software update condition (Ma, pg. 28, para. 3, the embodiment of the invention claims software upgrade method, not only can be applied to the vehicle in the parking state, in some cases also can be applied in the moving state of the vehicle; pg. 28, para. 4, in the moving state of the vehicle using the software upgrade of the invention claims the method for software upgrade the process; pg. 29, the send to the last paragraph; the embodiment of the invention claims software upgrade method, not only can be applied to the vehicle in the parking state, in some cases also can be applied in the moving state of the vehicle). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Siegal’s system as modified with the system taught by Dickerson including determining that the probability meets the software update condition. The modification would be obvious because one of ordinary skill in the art would be motivated to set two vehicle states during software upgrade, where the first function of the vehicle is disabled state, the second function is available state, so that the user can still use the second function during the vehicle software upgrade so as to improve the vehicle experience of the user (Ma, Abstract). As to claim 2, the rejection of claim 1 is incorporated. Siegal as modified further discloses The computer-implemented method of claim 1, wherein the vehicle operates in or along one or more of: a defined area or site (Siegal, col. 10, lines 18-24, vehicles are typically located at the same locations when they are parked for a significant time period. For instance, a vehicle is typically parked for an elongated period of time at the home of the user. For this reason, the service application 128 may use location data of the vehicle in determining the list of possible times to upgrade the vehicle control module); a confined or enclosed area or site (Siegal, col. 10, lines 18-24, vehicles are typically located at the same locations when they are parked for a significant time period. For instance, a vehicle is typically parked for an elongated period of time at the home of the user); and a defined trajectory (Siegal, col. 10, lines 31-37, historic data provided by the virtual vehicle may be used to provide an average stop duration and standard deviation of stopped time for a frequented location such as home or an office building. This same historic information provides information about typical timing of trips to this location, along with a confidence interval). As to claim 3, the rejection of claim 1 is incorporated. Siegal as modified further discloses The computer-implemented method of claim 1, wherein a vehicle which has a relation to the first vehicle in terms of one or more vehicle usage characteristics is one or more of: a same or similar type of vehicle (Siegal, col. 10, lines 32-41, historic data provided by the virtual vehicle may be used to provide an average stop duration and standard deviation of stopped time for a frequented location such as home or an office building. This same historic information provides information about typical timing of trips to this location, along with a confidence interval. When confidence is sufficiently high, the trip start and end times are presented to a selection algorithm, which determines whether the upgrade can successfully be completed in the allotted time required for the upgrade); a vehicle having a same or a similar role to the vehicle (Siegal, col. 10, lines 32-41); and a vehicle following a same or similar trajectory or route to the vehicle ((Siegal, col. 10, lines 32-41). As to claim 4, the rejection of claim 1 is incorporated. Siegal as modified further discloses The computer-implemented method of claim 1, wherein the probability of the vehicle having an updateable operational state is determined at least partly based on collected data indicative of vehicle use (Siegal, col. 10, lines 32-37, historic data provided by the virtual vehicle may be used to provide an average stop duration and standard deviation of stopped time for a frequented location such as home or an office building. This same historic information provides information about typical timing of trips to this location, along with a confidence interval) and wherein the method further comprises: processing the collected data to determine one or more usage characteristics of the vehicle (Siegal, col. 10, lines 30-41, historic data provided by the virtual vehicle may be used to provide an average stop duration and standard deviation of stopped time for a frequented location such as home or an office building. This same historic information provides information about typical timing of trips to this location, along with a confidence interval. When confidence is sufficiently high, the trip start and end times are presented to a selection algorithm, which determines whether the upgrade can successfully be completed in the allotted time required for the upgrade). As to claim 5, the rejection of claim 1 is incorporated. Siegal as modified further discloses The computer-implemented method of claim 1, wherein the probability of the vehicle having an updateable operational state is determined dynamically at least partly based on receiving a user input within one or more previous time-periods (Siegal, col. 12, lines 7-23, At a predefined time period prior to the user selected software upgrade time, the service application 128 transmits a request for confirmation to the portable interactive communication device 70 (block 212). The predefined time period may be any time that provides ample notice to the user of the vehicle, as well as being close enough to the selected software upgrade time, so as to ensure that the user can not only confirm agreement with the selected software upgrade time, but also will not forget about the approaching selected software upgrade time). Claims 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over US 9,086,941 (hereinafter "Siegal”), in view of US 2018/0107473 (hereinafter “Ahmed”), in view of CN 113227967 (hereinafter “Ma”), and further in view of US 9,715,378 (hereinafter “Dickerson”). As to claim 6, the rejection of claim 1 is incorporated and Siegal as modified does not appear to explicitly disclose The computer-implemented method of claim 1, wherein the method further comprises: determining the type of system subsystems and/or software components that the vehicle software update will use in the vehicle. However, in an analogous art to the claimed invention in the field of vehicle software update, Dickerson teaches The computer-implemented method of claim 1, wherein the method further comprises: determining the type of system subsystems and/or software components that the vehicle software update will use in the vehicle (Dickerson, , Fig. 4, col. 8, lines 47-56, In a first step 400, software updates needed for a vehicle or vehicles are identified … This can also be accomplished by instructions or other communications received by the software update manager from external sources such as from a user making a purchase of an additional software feature or a communication from an owner of the software management system providing notification of a safety recall software update; Fig. 6A, col. 12, lines 7-18, Record 600 includes a software update identifier 601, a software update type 602, a software update version 603, a software update granularity 604, and software update requirements 605. Software update identifier 601 provides an identification of the software update such as whether the software update is to a specific application. Software update type 602 is a descriptor of whether the software update is an improved version of existing software, a software upgrade, whether the software update is to a critical function or not, etc. Software update version 603 identifies the version of an update is a descriptor of whether the software update is an improved version of existing software, a software upgrade, whether the software update is to a critical function or not, etc. Software update version 603 identifies the version of an update); associating each type of system subsystem and/or software components with one or more different software component groups of the vehicle (Dickerson, Fig. 6A, col. 12, lines 7-18, Record 600 includes a software update identifier 601, a software update type 602, a software update version 603, a software update granularity 604, and software update requirements 605. Software update identifier 601 provides an identification of the software update such as whether the software update is to a specific application. Software update type 602 is a descriptor of whether the software update is an improved version of existing software, a software upgrade, whether the software update is to a critical function or not, etc. Software update version 603 identifies the version of an update is a descriptor of whether the software update is an improved version of existing software, a software upgrade, whether the software update is to a critical function or not, etc. Software update version 603 identifies the version of an update), wherein each software component group has an assigned set of conditions which need to be fulfilled in order to proceed with the software update (Dickerson, Fig. 4, col. 8, lines 56-65. a set of requirements for updating the software are determined. This can include the length of time for the update including diagnostics, bandwidth requirements, wireless security requirements, proximity to a dealership should a dispatch be required, whether there are any other timing requirements such as whether this is a safety update that needs immediate action; Fig. 6A, col. 12, lines 7-18); and associating the probability of the vehicle having an updateable operational state with one or more time periods based on when the time periods when the assigned set of conditions for each software component group used by the software update are fulfilled (Dickerson, Fig. 4, col. 8-9, lines 66-11, in a third step 410, the requirements are provided to the scheduling manager to identify time windows when the software update can be performed. his time window can be based on statistical analysis of vehicle usage such as when a vehicle is turned off and other requirements are met to determine a time window with a high probability of not being interrupted. The best time window meets all the requirements and has the highest probability of not being interrupted; Fig. 5, col.10, lines 43-55, In a third step 510, the requirements are provided to the scheduling manager to identify time windows when the software update can be performed. Then in step 515, the scheduling manager identifies and provides a best proposed time window to the software update manager including whether providing a notification there is no time window that meets the requirements. This time window can be based on statistical analysis of vehicle usage such as when a vehicle is turned off and other requirements are met to determine a time window with a high probability of not being interrupted. The best time window meets all the requirements and has the highest probability of not being interrupted). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Siegal’s system as modified with the system taught by Dickerson including determining the type of system subsystems and/or software components that the vehicle software update will use in the vehicle; associating each type of system subsystem and/or software components with one or more different software component groups of the vehicle, wherein each software component group has an assigned set of conditions which need to be fulfilled in order to proceed with the software update; and associating the probability of the vehicle having an updateable operational state with one or more time periods based on when the time periods when the assigned set of conditions for each software component group used by the software update are fulfilled. The modification would be obvious because one of ordinary skill in the art would be motivated to automate the process of scheduling a software update affecting vehicle functionality based on usage patterns including tracking usage patterns of a vehicle; automatically determining a time window for scheduling a software update that affects vehicle functionality to the vehicle based on the tracked usage patterns; and applying software updates to the vehicle during the scheduled time window without human manual work (Dickerson, Abstract). As to claim 7, the rejection of claim 1 is incorporated and Siegal as modified further discloses The computer-implemented method of claim 1, wherein the updateable operational state is associated with the software component group(s) used by the vehicle software update (Dickerson, Fig. 5, col. 11, lines 27-47, In step 555, the scheduled software update is performed during the scheduled time window if the software update is available and the vehicle is located in the desired location with the requirements met … then in step 570 it is determined whether the vehicle can function safely). The motivation to combine the references is the same as set forth in the rejection of claim 6. As to claim 8, the rejection of claim 1 is incorporated. Siegal as modified further discloses The computer implemented method as claimed in claim 1, wherein the selection condition for selecting a probability of the vehicle having an updateable operational states comprises a condition that the probability has a value exceeding a threshold probability value and/or a condition that value is associated with a confidence score above a threshold confidence score (Siegal, col. 10, lines 32-41, historic data provided by the virtual vehicle may be used to provide an average stop duration and standard deviation of stopped time for a frequented location such as home or an office building. This same historic information provides information about typical timing of trips to this location, along with a confidence interval. When confidence is sufficiently high, the trip start and end times are presented to a selection algorithm, which determines whether the upgrade can successfully be completed in the allotted time required for the upgrade). As to claim 9, Siegal as modified teaches Apparatus for scheduling vehicle software updates, the apparatus comprising: computer code; memory; and at least one processor; wherein the at least one processor is configured to execute the computer code when loaded from the memory to cause the vehicle control system to execute a method according to claim 1 (Siegal, claims 1-8 and the combination paragraphs from Siegal and Ahmed used in the rejection of claim 1). As to claim 10, the rejection of claim 9 is incorporated. Siegal as modified further discloses Apparatus according to claim 9, wherein the apparatus comprises a remote system from a site comprising one or more vehicles for which the remote system is configured to schedule vehicle software updates (Siegal, Fig. 1, col. 4, lines 5-39; col. 8, lines 51-63). As to claim 11, Siegal as modified teaches A system for scheduling vehicle software updates, the system comprising: an apparatus according to claim 9 (Siegal, claims 1-8 and the combination paragraphs from Siegal and Ahmed used in the rejection of claim 1); and one or more vehicles configured to provide behavioural state data to the apparatus, wherein the apparatus is configured to process the received behavioural state data when performing the method to schedule a vehicle software update for one or more of the vehicles (Siegal, Fig. 1, col. 4, lines 5-39; col. 8, lines 51-63). As to claim 12, the rejection of claim 11 is incorporated and the claim is corresponding to the method claim 3. Therefore, it is rejected under the same rational set forth in the rejection of the method claim. As to claim 13, the claim is a dependent claim of method claim 1 as a non-transitory computer-readable storage medium storing instructions which, when executed by at least one processor, cause the at least one processor to perform operations according to claim 1. Therefore, it is rejected under the same rational set forth in the rejection of claim 1. Claims 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Siegal in view of Ahmed, in view of Ma, and further in view of US 2022/0027143 (hereinafter “Fukuyo”). As to claim 15, Siegal as modified teaches vehicle is configured to provide behavioural state data to an apparatus according to claim 9 (Siegal, claims 1-8 and the combination paragraphs from Siegal and Ahmed used in the rejection of claim 1). Siegal as modified does not appear to explicitly disclose A heavy-duty vehicle comprising an automated-driving system. However, in an analogous art to the claimed invention in the field of vehicle software update, Fukuyo teaches A heavy-duty vehicle comprising an automated-driving system (Fukuyo, ¶ 35, the functions of the vehicle is the number of times or the like of user operations or the like enabling the functions making up advanced driver-assistance systems (ADAS), such as lane centering, cruise control, automated braking, proximity warning, and so forth). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Siegal’s system as modified with the system taught by Fukuyo including that the updateable operational state is a non-stationary behavior state of the vehicle. The modification would be obvious because one of ordinary skill in the art would be motivated to distributes update data for updating software for updating software of in-vehicle devices installed in vehicles is distributed to each of a plurality of vehicles including advanced driver-assistance systems (ADAS) (Fukuyo, ¶¶ 8 and 35). As to claim 16, the rejection of claim 15 is incorporated and Siegal as modified further teaches The heavy-duty vehicle of claim 15, wherein the heavy-duty vehicle is configured to perform a software update of one or more vehicle software components at a time scheduled by the apparatus (Siegal, col. 12, lines 38-43, if the user confirms the selected software upgrade time, at the selected upgrade time, the service application 128 instructs the vehicle control module update application 38 to upgrade the vehicle control module with the vehicle control software stored within the vehicle storage device 40). Conclusion Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 extension fee 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 date of this final action. Contact Information Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAXIN WU whose telephone number is (571) 270-7721. The examiner can normally be reached on M-F (7 am - 11:30 am; 1:30- 5 pm). If attempts to reach the examiner by telephone are unsuccessful, the examiner' s supervisor, Wei Mui can be reached at (571) 272-3708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form. Wu, Daxin Primary Examiner Art Unit 2191 /DAXIN WU/Primary Examiner, Art Unit 2191
Read full office action

Prosecution Timeline

Feb 23, 2023
Application Filed
Nov 12, 2024
Non-Final Rejection — §103
Feb 14, 2025
Response Filed
Mar 24, 2025
Final Rejection — §103
May 28, 2025
Request for Continued Examination
May 30, 2025
Response after Non-Final Action
Aug 11, 2025
Non-Final Rejection — §103
Nov 13, 2025
Response Filed
Dec 31, 2025
Final Rejection — §103
Mar 03, 2026
Interview Requested
Mar 10, 2026
Applicant Interview (Telephonic)
Mar 10, 2026
Examiner Interview Summary

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12585451
SOFTWARE UPDATES BASED ON TRANSPORT-RELATED ACTIONS
2y 5m to grant Granted Mar 24, 2026
Patent 12578949
DEVICE AND METHOD FOR EXCHANGING A PUBLIC KEY IN THE COURSE OF A FIRMWARE UPDATE FOR LEVEL SENSORS
2y 5m to grant Granted Mar 17, 2026
Patent 12555079
VERSION MAINTENANCE SERVICE FOR ANALYTICS COMPUTING
2y 5m to grant Granted Feb 17, 2026
Patent 12547391
Mobile Application Updates for Analyte Data Receiving Devices
2y 5m to grant Granted Feb 10, 2026
Patent 12547395
MOBILE TERMINAL AND SOFTWARE DISTRIBUTION SYSTEM
2y 5m to grant Granted Feb 10, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

5-6
Expected OA Rounds
85%
Grant Probability
99%
With Interview (+18.6%)
2y 6m
Median Time to Grant
High
PTA Risk
Based on 620 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month