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
Continued Examination Under 37 CFR 1.114
1. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 07/16/2026 has been entered.
Status of Claim
2. Applicant's amendment dated 07/16/2026 responding to the Office Action 06/01/2026 provided in the rejection of claims 1-8.
3. Claims 1, 6 and 8 have been amended.
4. Claims 1-8 are pending in the application, of which claims 1, 6 and 8 in independent form and which have been fully considered by the examiner.
Response to Amendments
5. (A) Regarding art rejection: Applicants' amendment necessitated new grounds of rejections presented in the following art rejection. Please see Yasunori (JP 2011053954 A).
Examiner Notes
6. Examiner cites particular columns and line numbers in the references as applied to the claims below for the 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 in 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.
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(s) 1, 3 and 5-8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Nagata et al. (US Pub. No. 2022/0413835 A1 – art of record – herein after Nagata) in view of Sangameswaran et al. (US Pub. No. 2019/0259223 A1 – art of record --herein after Sang) and in view of Yasunori (JP 2011053954 A – herein after Yasunori).
Regarding claim 1.
Nagata discloses
A software updating device comprising a central processing unit (CPU) (terminal device 200 comprising a processor 201 – See Fig. 2), the CPU being configured to execute:
downloading software update data for software for an information processing device (downloading the update data at the download start time and an instruction to start updating the program using the update data at the update start time – See paragraph [0072]);
obtaining schedule information (schedule information – See Fig. 4), the schedule information including information on a scheduled event that is scheduled for a user and information regarding a time slot of the scheduled event (is information indicating update of program of high importance included and specify distribution start date and time of update data – See Fig. 6, steps S001-S008 and Fig. 7, steps S009-S010);
[[predicting a blank period in the future in which the scheduled event will not occur and the schedule information indicates that the user is free, based on (i) the schedule information that is acquired and (ii) a location of the scheduled event]];
deciding a scheduled update date-and-time that is a date and time when an update of the software for the information processing device is to be performed with software update data, [[within the blank period]] (the operation plan includes a mobile body identification (ID) for identifying the mobile body 2. Further, in the data example of FIG. 4, the operation plan is created for each day and includes the date, month, and year. Further, in the data example of FIG. 4, the operation schedule, the maintenance schedule, and the like of the mobile body 2 for each time zone are specified in the operation plan – See paragraph [0055-0056]); and
performing the update of the software at the scheduled update date-and-time (update program using update data – See Fig. 8, step S 109; set download start time and update start time from central ECU (updating device) – See Fig. 8, steps S101-S106).
Nagata discloses the control center 4 updates the operation schedule in a timely manner, distributes the updated operation schedule to the mobile body 2, and manages the operation of the mobile body 2 – See paragraph [0036].
Nagata does not disclose
predicting a blank period in the future in which the scheduled event will not occur and the schedule information indicates that the user is free, based on (i) the schedule information that is acquired and (ii) a location of the scheduled event;
deciding a scheduled update date-and-time that is a date and time when an update of the software for the information processing device is to be performed with software update data, within the blank period.
Sang discloses
predicting a blank period in the future in which the scheduled event will not occur, [[and the schedule information indicates that the user is free]], based on (i) the schedule information that is acquired (a predicted duration required to transmit the update to the vehicle - See paragraph [0025]) and (ii) a location of the scheduled event (the vehicle location may be predicted, such as a predicted location at which the vehicle is likely to be parked or stopped for an extended period of time. The SOC threshold corresponding to the pending update may be modified based on the known or predicted location of the vehicle at the time the update is going to be performed. Key-on probability map 224 includes predictive information provided without use of location information (e.g., the data is location-less, as an overall average type of prediction). Also of note, the stop duration prediction may be performed by estimating the time until the next key-on is likely (e.g., until the accumulated probability exceeds a threshold value). For instance, in the example shown in FIG. 3, the best time to perform an update that could last between 2-3 hours is shown as being between 2 AM and 5 AM - See paragraphs [0032-0036]. One of the challenges of performing OTA updates is to predict a time to schedule the installation that minimizes inconvenience to the driver - See paragraph [0012]. An improved system for identifying a time for performing a software update may make use of historical vehicle usage information. The system may learn a usage pattern for the vehicle based upon time of day and day of week. Using this information, a probability of the customer using the vehicle at any given time may be determined. Additionally, an amount of time required to perform the OTA update may be identified from a manifest including information about the updates to be performed. This timing information gleaned from the manifest can be determined during vehicle development phases, such as by recording the amount of time required for updating the vehicle controller in a controlled environment. Based on vehicle usage pattern and the time to perform the update, the system may identify an optimum time to schedule vehicle downtime for performing the update. Moreover, driver preferences may be accounted for to allow the system to ask before performing each update or instead to perform silent updates - See paragraph [0013]. An example probability map 224. As shown, the probability map 224 indicates key-on probability for the vehicle 102 according to time and day of week. The example probability map 224 indicates values for each day of the week (Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, from top to bottom) and over different times of the day (24 hours, from left to right). Given the current day and time, the update scheduler application 222 may be configured to evaluate the likelihood of a key-on event by integrating the probability values up to a desired future time horizon to determine the estimated likelihood of a key-on event that may interrupt an OTA scheduled event. Furthermore, see figures 4-5 (and related text)) - See Fig. 3 and paragraph [0033]);
deciding a scheduled update date-and-time that is a date and time when an update of the software for the information processing device is to be performed with software update data, within the blank period (a probability map including information indicative of probabilities of a vehicle being used during each of a plurality of blocks of a time period and instructions to cause a processor to schedule a time to install a software update utilizing the probability map and an expected downtime required for installation, and install the software update at the scheduled time responsive to confirming the vehicle is not in use - See paragraph [0005]. In the example shown in FIG. 3, the best time to perform an update that could last between 2- 3 hours is shown as being between 2 AM and 5 AM - See paragraphs [0032-0036]. Schedule a time to install a software update utilizing the probability map and an expected downtime required for the installation - See Abstract. The update procedure is performed only to the day/time blocks that match the key-on event (i.e., the block included within the key-on period for the trip) - See paragraph [0048]).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Sang's teaching into Nagata's invention because incorporating Sang's teaching would enhance Nagata to enable to install the software update at the scheduled time responsive to confirming the vehicle is not in use as suggested by Sang (Abstract).
Nagata and Sang do not disclose
predicting a blank period in the future in which the schedule information indicates that the user is free,
Yasunorii discloses
predicting a blank period in the future in which the scheduled event will not occur (the schedule candidate determination unit 13 has a function of determining a reprogram schedule candidate based on the predicted free time – See page 2) and the schedule information indicates that the user is free (the schedule candidate determination unit 13 determines, for example, the free time when the vehicle 3 is not used by the user (user) based on the usage status of the vehicle 3, and secures the time more than the program update time in the free time – See page 2), based on (i) the schedule information that is acquired and (ii) a location of the scheduled event (the usage status detection unit 30 determines whether or not the vehicle 3 is present in the registered position information based on the position information of the stop location registered in advance, and if so, which of the registered locations is It has a function to detect whether it exists. As the registered stop location, for example, a home garage, a workplace parking lot, another parking lot, or the like is used. Usage status learning DB 10 stores a table that expresses the number of use and stop locations in a -format with zones as rows and days of the week as columns. Stop locations are divided into home garages, workplace parking lots, and other parking lots. The candidate determination unit 13 inputs the tables shown in FIGS. 5A and 5B with reference to the usage situation learning DB10. When the process of S10 ends, the process proceeds to an information input process (S12) – See page 3);
Yasunorii also discloses
deciding a scheduled update date-and-time that is a date and time when an update of the software for the information processing device is to be performed with software update data, within the blank period (selects a schedule candidate for updating the program of the vehicle 3 based on the usage status of the vehicle 3 and the update time of the program. It has a function to decide. The schedule candidate determination unit 13 determines, for example, the free time when the vehicle 3 is not used by the user (user) based on the usage status of the vehicle 3. It has a function of predicting the free time that can be used as the free time that can be updated. The schedule candidate determination unit 13 has a function of determining a reprogram schedule candidate based on the predicted free time. The schedule candidate determination unit 13 has a function of determining a reprogram schedule candidate based on the predicted free time. The schedule candidate determination unit 13 has a function of determining a plurality of reprogram schedule candidates or narrowing down to a predetermined number when there are a plurality of idle times that satisfy the conditions. Furthermore, the schedule candidate determination unit 13 has a function of outputting information on schedule candidates to the schedule candidate presentation unit 14 and the reprogram processing unit 15 – See page 2).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Yasunori’s teaching into Nagata’s and Sang’s invention because incorporating Yasunori’s teaching would enhance Nagata and Sang to enable to select a schedule candidate for updating the program of the vehicle based on the usage status of the vehicle and the update time of the program as suggested by Yasunori (paragraphs [0046-0050]).
Regarding claim 3, the software updating device according to claim 1,
Nagata discloses
wherein the CPU is configured to execute (a central processing unit (CPU). The processor 201 performs various processes by executing various programs – See paragraph [0049])
performing, when the scheduled update date-and-time is decided (set download start time and update start time – See Fig. 8, steps S101-S109), confirmation regarding whether the user consents to perform the update of the software at the scheduled update date-and-time (the UIF device 23 may accept input for confirmation by an operation of the user via the reprogramming HMI. That is, the central ECU 22 may request the user to confirm start updating the program with the UIF device 23, and may start updating the program after the confirmation is obtained. The UIF device 23 itself also acquires the update data from the central ECU 22 and updates the program of the UIF device 23 – See paragraph [0041]), and
performing the update of the software at the scheduled update date-and-time, on a condition that consent to performing the update of the software at the scheduled update date-and-time is obtained (the central ECU 22 may request the user to confirm start updating the program with the UIF device 23, and may start updating the program after the confirmation is obtained. The UIF device 23 itself also acquires the update data from the central ECU 22 and updates the program of the UIF device 23 – See paragraph [0041]).
Regarding claim 5, the software updating device according to claim 1, wherein:
Nagata discloses
the information processing device is installed in a vehicle; and
the CPU is configured to execute predicting a non-use period that is a period during which the user will not use the vehicle (the update of the program for the ECU mounted on the mobile body 2 is executed during a maintenance period when travel of the mobile body 2 is stopped (time during which the mobile body 2 is stopped) – See paragraph [0037]),
Nagata does not disclose
and predicting a period within the non-use period in which the scheduled event will not occur for the user, as the blank period.
Sang discloses
and predicting a period within the non-use period in which the scheduled event will not occur for the user, as the blank period (to schedule a time to install a software update utilizing the probability map and an expected downtime required for installation, and install the software update at the scheduled time responsive to confirming the vehicle is not in use – See paragraphs [0003-0005]).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Sang’s teaching into Nagata’s invention because incorporating Sang’s teaching would enhance Nagata to enable to to schedule a time to install a software update utilizing the probability map and an expected downtime required for installation, and install the software update at the scheduled time responsive to confirming the vehicle is not in use as suggested by Sang (paragraphs [0003-0005]).
Regarding claim 6.
A software updating method executed by an updating device, the software updating method comprising:
Regarding claim 6, recites the same limitations as rejected claim 1 above.
Regarding claim 7.
A non-transitory storage medium storing instructions that are executable by an updating device and that cause the updating device to execute the software updating method according to claim 6.
Regarding claim 7, recites the same limitations as rejected claim 1 and claim 6 above.
Regarding claim 8.
Nagata discloses
A software updating system (control center – See Fig. 4), comprising:
a computer (control center – See Fig. 4) that stores schedule information (The control center 4 creates, for example, an operation schedule such as an operation start time, an operation, an operation end time, and a maintenance time zone of the mobile body 2 that is regularly operated – See paragraph [0036]), the schedule information (Fig. 4 and Fig. 5) including information on a scheduled event that is scheduled for a user and information regarding a time slot of the scheduled event (is information indicating update of program of high importance included and specify distribution start date and time of update data – See Fig. 6, steps S001-S008 and Fig. 7, steps S009-S010); and
a processor (the central ECU 22 updates, for example, a program executed by the ECU mounted on each device in the mobile body 2 and manages the progress of the update of the program – See paragraphs [0027-0028]) that is configured to communicate with the computer (the central ECU 22 and the DCM 21 is an example of the computer (in-vehicle computer) mounted on the vehicle – See paragraph [0027]), and that is installed in a vehicle (a central electrical control unit (central ECU) 22 – See Fig. 1 and paragraphs [0025-0028]), and configured to execute:
downloading software update data for software for an information processing device (downloading the update data at the download start time and an instruction to start updating the program using the update data at the update start time – See paragraph [0072]);
acquiring the schedule information from the computer (acquires, from the storage device 202, the operation plan data of the mobile body 2 on a predetermined date after the distribution start date and time (for example, the distribution start date or the next day of the distribution start date) – See paragraphs [0062-0067]),
[[predicting a blank period in the future in which the scheduled event will not occur, and the schedule information indicates that the user is free, based on (i) the schedule information that is acquired and (ii) a location of the scheduled event, ]]
deciding a scheduled update date-and-time that is a date and time when an update of the software for the information processing device installed in the vehicle is to be performed with the software updated data [[within the blank period]] (the operation plan includes a mobile body identification (ID) for identifying the mobile body 2. Further, in the data example of FIG. 4, the operation plan is created for each day and includes the date, month, and year. Further, in the data example of FIG. 4, the operation schedule, the maintenance schedule, and the like of the mobile body 2 for each time zone are specified in the operation plan – See paragraph [0055-0056]),
transmitting information regarding the scheduled update date-and-time to the computer when the scheduled update date-and-time is decided (The vehicle center 3 notifies the control center 4 of the latest update contents and update schedule of the program for each ECU in the form of release note. When the control center 4 receives the release note, the control center 4 incorporates the update schedule of the program for each ECU into the operation schedule of each mobile body 2. The DCM 21 accesses the vehicle center 3 according to the received operation schedule, acquires update data for updating the program, and transfers the update data to the central ECU 22 – See paragraphs [0038-0040]), and
performing the update of the software at the scheduled update date-and-time (update program using update data – See Fig. 8, step S 109); set download start time and update start time from central ECU (updating device) – See Fig. 8, steps S101-S106), and
the computer is configured to execute (the control center manages and operation – See paragraph [0036])
acquiring timing information regarding the scheduled update date-and-time (the control center 4 creates, for example, an operation schedule such as an operation start time, an operation, an operation end time, and a maintenance time zone of the mobile body 2 that is regularly operated – See paragraph [0036]), and
updating the schedule information in accordance with information regarding the scheduled update date-and-time (the latest update contents and update schedule of the program for each ECU in the form of release note. When the control center 4 receives the release note, the control center 4 incorporates the update schedule of the program for each ECU into the operation schedule of each mobile body 2 – See paragraph [0038-0040] and Fig. 5, last update date. The control center 4 records the last update date and time and the system version of the entire updated program group in the state information – See paragraph [0061]).
Nagata discloses the control center 4 updates the operation schedule in a timely manner, distributes the updated operation schedule to the mobile body 2, and manages the operation of the mobile body 2 – See paragraph [0036].
Nagata does not disclose
predicting a blank period in the future in which the scheduled event will not occur, and the schedule information indicates that the user is free, based on (i) the schedule information that is acquired and (ii) a location of the scheduled event,
deciding a scheduled update date-and-time that is a date and time when an update of the software for the information processing device installed in the vehicle is to be performed with the software updated data within the blank period.
Sang discloses
predicting a blank period in the future in which the scheduled event will not occur, [[and the schedule information indicates that the user is free]], based on (i) the schedule information that is acquired (a predicted duration required to transmit the update to the vehicle - See paragraph [0025]) and (ii) a location of the scheduled event (the vehicle location may be predicted, such as a predicted location at which the vehicle is likely to be parked or stopped for an extended period of time. The SOC threshold corresponding to the pending update may be modified based on the known or predicted location of the vehicle at the time the update is going to be performed. Key-on probability map 224 includes predictive information provided without use of location information (e.g., the data is location-less, as an overall average type of prediction). Also of note, the stop duration prediction may be performed by estimating the time until the next key-on is likely (e.g., until the accumulated probability exceeds a threshold value). For instance, in the example shown in FIG. 3, the best time to perform an update that could last between 2-3 hours is shown as being between 2 AM and 5 AM - See paragraphs [0032-0036]. One of the challenges of performing OTA updates is to predict a time to schedule the installation that minimizes inconvenience to the driver - See paragraph [0012]. An improved system for identifying a time for performing a software update may make use of historical vehicle usage information. The system may learn a usage pattern for the vehicle based upon time of day and day of week. Using this information, a probability of the customer using the vehicle at any given time may be determined. Additionally, an amount of time required to perform the OTA update may be identified from a manifest including information about the updates to be performed. This timing information gleaned from the manifest can be determined during vehicle development phases, such as by recording the amount of time required for updating the vehicle controller in a controlled environment. Based on vehicle usage pattern and the time to perform the update, the system may identify an optimum time to schedule vehicle downtime for performing the update. Moreover, driver preferences may be accounted for to allow the system to ask before performing each update or instead to perform silent updates - See paragraph [0013]. An example probability map 224. As shown, the probability map 224 indicates key-on probability for the vehicle 102 according to time and day of week. The example probability map 224 indicates values for each day of the week (Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, from top to bottom) and over different times of the day (24 hours, from left to right). Given the current day and time, the update scheduler application 222 may be configured to evaluate the likelihood of a key-on event by integrating the probability values up to a desired future time horizon to determine the estimated likelihood of a key-on event that may interrupt an OTA scheduled event. Furthermore, see figures 4-5 (and related text)) - See Fig. 3 and paragraph [0033]);
deciding a scheduled update date-and-time that is a date and time when an update of the software for the information processing device is to be performed with software update data, within the blank period (a probability map including information indicative of probabilities of a vehicle being used during each of a plurality of blocks of a time period and instructions to cause a processor to schedule a time to install a software update utilizing the probability map and an expected downtime required for installation, and install the software update at the scheduled time responsive to confirming the vehicle is not in use - See paragraph [0005]. In the example shown in FIG. 3, the best time to perform an update that could last between 2- 3 hours is shown as being between 2 AM and 5 AM - See paragraphs [0032-0036]. Schedule a time to install a software update utilizing the probability map and an expected downtime required for the installation - See Abstract. The update procedure is performed only to the day/time blocks that match the key-on event (i.e., the block included within the key-on period for the trip) - See paragraph [0048]).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Sang's teaching into Nagata's invention because incorporating Sang's teaching would enhance Nagata to enable to install the software update at the scheduled time responsive to confirming the vehicle is not in use as suggested by Sang (Abstract).
Nagata and Sang do not disclose
predicting a blank period in the future in which the schedule information indicates that the user is free,
Yasunori discloses
predicting a blank period in the future in which the scheduled event will not occur (the schedule candidate determination unit 13 has a function of determining a reprogram schedule candidate based on the predicted free time – See page 2) and the schedule information indicates that the user is free (the schedule candidate determination unit 13 determines, for example, the free time when the vehicle 3 is not used by the user (user) based on the usage status of the vehicle 3, and secures the time more than the program update time in the free tim3 – See page 2), based on (i) the schedule information that is acquired and (ii) a location of the scheduled event (the usage status detection unit 30 determines whether or not the vehicle 3 is present in the registered position information based on the position information of the stop location registered in advance, and if so, which of the registered locations is It has a function to detect whether it exists. As the registered stop location, for example, a home garage, a workplace parking lot, another parking lot, or the like is used. Usage status learning DB 10 stores a table that expresses the number of use and stop locations in a -format with zones as rows and days of the week as columns. Stop locations are divided into home garages, workplace parking lots, and other parking lots. The candidate determination unit 13 inputs the tables shown in FIGS. 5A and 5B with reference to the usage situation learning DB10. When the process of S10 ends, the process proceeds to an information input process (S12) – See page 3);
Yasunori also discloses
deciding a scheduled update date-and-time that is a date and time when an update of the software for the information processing device is to be performed with software update data, within the blank period (selects a schedule candidate for updating the program of the vehicle 3 based on the usage status of the vehicle 3 and the update time of the program. It has a function to decide. The schedule candidate determination unit 13 determines, for example, the free time when the vehicle 3 is not used by the user (user) based on the usage status of the vehicle 3. It has a function of predicting the free time that can be used as the free time that can be updated. The schedule candidate determination unit 13 has a function of determining a reprogram schedule candidate based on the predicted free time. The schedule candidate determination unit 13 has a function of determining a reprogram schedule candidate based on the predicted free time. The schedule candidate determination unit 13 has a function of determining a plurality of reprogram schedule candidates or narrowing down to a predetermined number when there are a plurality of idle times that satisfy the conditions. Furthermore, the schedule candidate determination unit 13 has a function of outputting information on schedule candidates to the schedule candidate presentation unit 14 and the reprogram processing unit 15 – See page 2).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Yasunori’s teaching into Nagata’s invention because incorporating Yasunori’s teaching would enhance Nagata to enable to select a schedule candidate for updating the program of the vehicle based on the usage status of the vehicle and the update time of the program as suggested by Sakurai (paragraphs [0046-0050]).
8. Claim(s) 2 and 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Nagata and Sang and Yasunori as applied to claim 1 above, and further in view of Sakurai et al. (US Pub. No. 2022/0410754 A1 – art of record --herein after Sakurai).
Regarding claim 2, the software updating device according to claim 1,
Sakurai discloses
wherein the CPU is configured to execute external transmission of information regarding the scheduled update date-and-time when the scheduled update date-and-time is decided (the transmission of the update campaign information from the center device 2 to the vehicle corresponds to “notification that the data to be stored in the electronic control device should be updated”. The OTA control unit 6 compares the time or the time period when the battery 8 is charged according to the setting of the charge schedule with the update required time, and determines whether or not it is possible to update the program from now on. If update execution is possible, the possibility is notified to the user through the HMI device 5, and if the user acknowledges the update execution, the update is started – See paragraphs [0046-0050]).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Sakurai’s teaching into Nagata’s and Sang’s and Yasunori‘s inventions because incorporating Sakurai’s teaching would enhance Nagata and Sang and Yasunori to enable to transmission of the update information from the external device as suggested by Sakurai (paragraphs [0046-0050]).
Regarding claim 4, the software updating device according to claim 1,
Sakurai discloses
wherein the update of the software includes activating an updated version of the software (the OTA control unit 6 grasps the time (2) required for the update campaign execution included in the above information. The time (2) is the total time for downloading the update program, installing the update program in the ECU, and activating the installed update program to validate the program – See paragraph [0049]).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Sakurai’s teaching into Nagata’s and Sang’s Yasunori‘s inventions because incorporating Sakurai’s teaching would enhance Nagata and Sang and Yasunori to enable to activate the installed update program to validate the program as suggested by Sakurai (paragraphs [0046-0050]).
Conclusion
9. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ullman et al. (US Patent No. 11494173 B2) discloses performing software updates for vehicles. The vehicles may be scheduled for the software updates based on information related to the vehicles. Update systems may determine when the vehicles have entered service ranges of the update systems for the scheduled software updates and may initiate the software updates in response to determining that the vehicles have entered the service ranges. Progress of the software updates may be monitored and displayed on a dashboard system overseeing the software updates of the vehicles – See Abstract and specification for more details.
Machida (US Pub. No. 2013/0305083 A1) discloses specifies a computing resource or application service used by a user, from a resource usage profile of the user. Based on the reservation information, the recovery time predicting means 205 determines whether a computing resource used exclusively by a plurality of users is free. Based on the recovery schedule, the recovery time predicting means 205 stores reservation information, which includes a recovery time of the free computing resource as a reservation start time, in the resource reservation information storing unit 208. The recovery time predicting means 205 specifies the time at which the user can reserve a computing resource, from the recovery schedule and the reservation information – See paragraphs [0084-0085].
Braun et al. (US Pub. No. 2023/0273784 A1) discloses provide that the delivery of the updatable services is carried out as a function of a recorded service-usage behavior of the vehicle user, a prioritized delivery of the service being carried out if a frequency of usage of a service exceeds a predetermined threshold value. Vehicle users who regularly utilize a service are consequently prioritized in the course of delivery in comparison with vehicle users who utilize the service irregularly – See paragraphs [0031-0032].
Afrasyab Bashir (MSIS: Meta-scheduler Infornation Service for Resource Performance Predictors, 2007) discloses an established technique to predict the performance of resources over a future period of time, based on which efficient scheduling decisions can be taken All predictive algorithms, however, depend upon certain input information that gives them the ability to estimate the load on the concerned resources for a limited future – See page 1.
Kikuchi et al. (WO 2023007577 A1) discloses provided is a software updating device (10) that updates software of in-vehicle control devices (14A to 14C) mounted on a vehicle (1), the software updating device (10) including: an information acquisition unit (41) that acquires update processing information regarding update of the software of the in-vehicle control devices (14A to 14C); an output unit (43) that outputs acceptance request information of asking a user whether to accept the update of the software – See Abstract and specification for more details.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MONGBAO NGUYEN whose telephone number is (571)270-7180. The examiner can normally be reached Monday-Friday 8am-5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hyung S. Sough can be reached at 571-272-6799. 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.
/MONGBAO NGUYEN/ Examiner, Art Unit 2192
Prosecution Insights