5Notice 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 .
Response to Arguments
Drawings
"FIGURE 5 is a block diagram that illustrates aspects of an exemplary computing device 500 appropriate for use with embodiments of the present disclosure. In other words, the computing device 500 is an example system that is used to implement the embodiments of the novel invention" (emphasis added.)
The what is shown in fig. 5 is disclosed as usable “with” the present invention. The use of the word “with” here indicates that what is shown in fig. 5 is different from the invention. Fig. 5 does not show the exemplary device “used to” (e.g. configured to) implement the invention. Accordingly, all that is actually shown in fig. 5 is a generic prior art computing device and the objection is maintained.
If the applicant wants to avoid the prior art label, examiner suggests amending the figure to, e.g., include an indication of software for performing the invention (e.g. Update Management Module 209) stored on the storage medium 508.
Rejections under 35 U.S.C. §103
Applicant’s arguments have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
More specifically, Sangameswaran discloses monitoring a state of the vehicle to ensure proper installation/update (par. [0004] “detect a key-off”). Zymeri teaches pausing an update when an improper state is detected (par. [0083] “that update installation is for example paused”). Moeller, Davidson and Choi teach monitoring the recited states (as indicated below). It would have been obvious to monitor these states to ensure proper installation/update (thus increasing the “robustness” of the system).
Drawings
Figure 5 should be designated by a legend such as --Prior Art-- because only that which is old is illustrated. See MPEP § 608.02(g). Corrected drawings in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. The replacement sheet(s) should be labeled “Replacement Sheet” in the page header (as per 37 CFR 1.84(c)) so as not to obstruct any portion of the drawing figures. If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 24-38 and 40-43 are rejected under 35 U.S.C. 103 as being unpatentable over US 2017/0242678 to Sangameswaran et al. (Sangameswaran) in view of US 2017/0123784 to Zymeri et al. (Zymeri) in view of US 2010/0325167 to Landry (Landry) in view of US 2019/0068393 to Lee et al. (Lee).
Claims 24 and 31: Sangameswaran discloses a non-transitory computer-readable medium having computer-executable instructions stored thereon that, in response to execution by one or more processors of a vehicle computer system of a vehicle, cause the vehicle computer system to perform actions comprising:
receiving a software update package, wherein the software update package comprises a first software update for a first updatable electronic component of the vehicle (par. [0045] “download the appropriate updates”);
after receiving the software update package and prior to installing the first software update (par. [0070] “flashing/loading the current build/version to a first software location before processing the update from a new software location”):
checking a storage device of the vehicle for a previously stored backup software version for the first updatable electronic component that is available (par. [0070] “copying it, if a copy does not already exist”);
in response to determining, at the vehicle onto which the software update package is to be installed, that the previously stored backup software version is not available (par. [0070] “before processing the update … if it does not already exist”, par. [0058] “an ECU containing the typical internal memory and a second, external memory”):
updating the stored backup software version with an available backup software version in the non-transitory computer-readable media at the vehicle (par. [0070] “flashing/loading the current build/version to a first software location … ensures that a backup currently exists in one additional location … copying it, if a copy does not already exist”);
installing, only after updating to the available backup software version and the first software update in the first updatable electronic component at the vehicle (par. [0045] “the updates will also be installed 233”), and
monitoring a state of the vehicle (par. [0004] “detect a key-off”).
Sangameswaran does not explicitly disclose:
monitoring vehicle state conditions during installation of the first software update, including monitoring whether the ignition key is in an “on” position, an engine of the vehicle is turned off, a parking brake of the vehicle is set, and wireless signal strength state meets a threshold level; and
in response to one or more of the ignition key being turned to an “off” position, the engine of the vehicle being turned on, the parking brake being released, or the wireless signal strength state falling below the threshold level, pausing installation of the first software update.
Zymeri teaches:
monitoring one or more vehicle state conditions during installation of the first software update (par. [0083] “the battery state has been fallen below … the defined target value”); and
in response to a change in a the vehicle state conditions, pausing installation of the first software update (par. [0083] “that update installation is for example paused”).
Moeller teaches:
monitoring an ignition key position, or an engine of the vehicle being turned on/off (par. [0010] "validating the updated rule set", par. [0146] “the rules may include … ignition on, ignition in accessory position, …) engine status (on, off)”).
Davidson teaches:
monitoring whether a parking break is set (col. 15, lines 7-19 “a vehicle’s parking break being engaged”).
Choi teaches:
monitoring a signal strength state relative to a threshold (par. [0175] “recognize the strength of the signal … whether the recognized signal strength is less than reference signal strength”).
It would have been obvious prior to the effective filing date of the claimed invention to monitor and the vehicle for a desirable state and pause the installation in response to a change in monitored state conditions to an undesirable state. Those of ordinary skill in the art would have been motivated to do so to “increase[e] the robustness” of the installation process (see e.g. Zymeri par. [0007]) and ensure that the owner isn’t using the vehicle during the update (Sangameswaran par. [0064]).
Sangameswaran, Zymeri , Moeller, Davidson, and Choi do not explicitly teach:
checking a storage device of the vehicle for a previously stored backup software version for the first updatable electronic component that is compatible with a current configuration of the vehicle.
Landry teaches:
checking a storage device for a previously stored backup that is compatible (par. [0050] “metadata 15 is used to check the compatibility of each of the backed-up application modules”).
It would have been obvious prior to the effective filing date of the claimed invention to check the storage device of the vehicle for a backup software version that is compatible (Sangameswaran par. [0070] “flashing/loading the current build/version … if a copy does not already exist”, Landry par. [0050] “check the compatibility of each of the backed-up application modules”). Those of ordinary skill in the art would have been motivated to do so ensure the backup will be available and functional for use (Sangameswaran par. [0070] “ensures a backup … exists”).
Sangameswaran, Zymeri , Moeller, Davidson, Choi and Landry do not explicitly teach:
determining whether a human-machine interface (HMI) device within the vehicle has been actuated for a threshold amount of time.
Lee teaches:
determining whether a human-machine interface (HMI) device has been actuated for a threshold amount of time (par. [0044] “a long press gesture … of a user touching the screen with a single finger for a long period of time (e.g., longer than a threshold time duration)”).
It would have been obvious prior to the effective filing date of the claimed invention to determine an HMI device has been actuated for a threshold amount of time prior to performing the installation. Those of ordinary skill in the art would have been motivated to do so as a known alternative means of receiving input from a user which would have produced only the expected results (see e.g. Sangameswaran par. [0017] “the interaction occurs through, button presses”).
Claim 25: Sangameswaran, Zymeri , Moeller, Davidson, Choi, Landry and Lee teach the non-transitory computer-readable medium of claim 24, wherein the actions further comprise:
in response to determining that the installation of the first software update is successful, storing the first software update in a storage medium in the vehicle computer system as a current backup software version for the first updatable electronic component (Sangameswaran par. [0057] “A resilient backup version of a currently installed software version also exists, in case the update fails”, par. [0060] “memory locations A and B … for holding the update and a backup version”).
Claim 26: Sangameswaran, Zymeri , Moeller, Davidson, Choi, Landry and Lee teach the non-transitory computer-readable medium of claim 25, wherein storing the first software update as a current backup software version comprises overwriting the compatible backup software version for the first updatable electronic component (Sangameswaran par. [0070] “flashing/loading the current build/version to a first software location).
Claim 27: Sangameswaran, Zymeri , Moeller, Davidson, Choi, Landry and Lee teach the non-transitory computer-readable medium of claim 25, wherein the vehicle computer system comprises a computing device including a wireless modem (par. [0030] “wireless router 73”), a processor (par. [0030] “CPU”), and the storage medium (par. [0018] “random access memory (RAM)”).
Claims 28 and 36: Sangameswaran, Zymeri , Moeller, Davidson, Choi, Landry and Lee teach claim 24 and 31, wherein the first updatable electronic component comprises an electronic control unit (ECU) (Sangameswaran par. [0057] “electronic control unit (ECU)”).
Claim 29: Sangameswaran, Zymeri , Moeller, Davidson, Choi, Landry and Lee teach the non-transitory computer-readable medium of claim 24, wherein the actions further comprise:
based on receiving an indication that the first updatable electronic component is functioning correctly, determining that the installation of the first software update is successful (Sangameswaran par. [0067] “The newly installed version can be tested for errors and functionality 815”, par. [0040] “receive a state log identifying the success or failure of various update installations 215”).
Claims 30, 37 and 43: Sangameswaran, Zymeri , Moeller, Davidson, Choi, Landry and Lee teach claims 24, 31 and 41, wherein the software update package comprises a second software update for a second updatable electronic component of the vehicle (par. [0044] “an update manifest containing a list of the updateable software modules available for download 229”), the actions further comprising:
installing the second software update in the second updatable electronic component (Sangameswaran par. [0045] “the updates will also be installed 233”);
determining that the installation of the second software update is successful (Sangameswaran par. [0040] “receive a state log identifying the success or failure of various update installations 215”); and
in response to determining that the installation of the second software update is successful, storing the second software update as a backup software version for the second updatable electronic component (Sangameswaran par. [0070] “flashing/loading the current build/version”).
Claim 32: Sangameswaran, Zymeri , Moeller, Davidson, Choi, Landry and Lee teach the method of claim 31, further comprising:
detecting an error or interruption in the installation of the first software update (Sangameswaran par. [0067] “If an error is detected”);
canceling the installation of the first software update (Sangameswaran par. [0067] “wipe the newly installed version”);
retrieving the compatible backup software version from the storage medium (Sangameswaran par. [0067] “The previously installed version can then be reloaded from another external memory space 821”); and
installing the compatible backup software version on the first updatable electronic component (Sangameswaran par. [0067] “The previously installed version can then be reloaded from another external memory space 821”).
Claim 33: Sangameswaran, Zymeri , Moeller, Davidson, Choi, Landry and Lee teach the method of claim 32, wherein the on-board computer system performs at least the steps of detecting the error or interruption, suspending the installation of the first software update, retrieving the compatible backup software version, and installing the compatible backup software version automatically without requiring user input (Sangameswaran par. [0030] “CPU … connected to a vehicle based wireless router 73”).
Claim 34: Sangameswaran, Zymeri , Moeller, Davidson, Choi, Landry and Lee teach the method of claim 31, wherein requesting and receiving the compatible backup software version comprises requesting and receiving the compatible backup software version from a remote server (par. [0045] “download the appropriate updates”).
Claim 35: Sangameswaran, Zymeri , Moeller, Davidson, Choi, Landry and Lee teach the method of claim 31, wherein the on-board computer system comprises a computing device including a wireless modem, a processor, and the storage medium, and wherein the computing device performs at least the steps of receiving the software update and retrieving the compatible backup software version from the storage medium (Sangameswaran par. [0030] “CPU … connected to a vehicle based wireless router 73”, par. [0018] “random access memory (RAM)”).
Claim 38: Sangameswaran, Zymeri , Moeller, Davidson, Choi, Landry and Lee teach the method of claim 31, wherein the software update package is received from a remote computer system via a wireless communication network (par. [0045] “download the appropriate updates”, par. [0030] “wireless router 73 … connect to remote networks”).
Claim 40: Sangameswaran discloses a vehicle comprising:
a first electronic control unit (ECU) (par. [0057] “electronic control unit (ECU)”); and
a computing device comprising a wireless modem, a processor, and non-transitory computer-readable storage media (par. [0030] “CPU … connected to a vehicle based wireless router 73”, par. [0018] “random access memory (RAM)”), the computing device being programmed to perform actions comprising:
receiving a first software update package, wherein the first software update package comprises a first software update for the first ECU (par. [0045] “download the appropriate updates”);
after receiving the first software update package and prior to installing the first software update (par. [0070] “flashing/loading the current build/version to a first software location before processing the update from a new software location”):
checking the non-transitory computer-readable media for a previously stored backup software version for the first ECU that is available (par. [0070] “copying it, if a copy does not already exist”);
in response to determining that the previously stored backup software version is not available with the current configuration of the vehicle, and prior to determining that the previously stored backup software version is to be re-installed (par. [0070] “before processing the update … if it does not already exist”):
updating the stored backup software version with an available backup software version in the non-transitory computer-readable media (par. [0070] “flashing/loading the current build/version to a first software location … ensures that a backup currently exists in one additional location … copying it, if a copy does not already exist”); and
installing, only after updating to the compatible backup software version, the first software update in the first ECU (par. [0045] “the updates will also be installed 233”), and
monitoring ignition key position (par. [0004] “detect a key-off”).
Sangameswaran does not explicitly disclose:
monitoring vehicle state conditions during installation of the first software update, including monitoring whether the ignition key is in an “on” position, an engine of the vehicle is turned off, a parking brake of the vehicle is set, and wireless signal strength state, meets a threshold level; and
in response to one or more of: the ignition key being turned to an “off” position, the engine of the vehicle being turned on, the parking brake being released, or the wireless signal strength state falling below the threshold level, pausing installation of the first software update.
Zymeri teaches:
monitoring vehicle state conditions during installation of the first software update (par. [0083] “the battery state has been fallen below … the defined target value”); and
in response to a change in a the vehicle state conditions, pausing installation of the first software update (par. [0083] “that update installation is for example paused”).
Moeller teaches:
monitoring an ignition key position, or an engine of the vehicle being turned on/off (par. [0010] "validating the updated rule set", par. [0146] “the rules may include … ignition on, ignition in accessory position, …) engine status (on, off)”).
Davidson teaches:
monitoring whether a parking break is set (col. 15, lines 7-19 “a vehicle’s parking break being engaged”).
Choi teaches:
monitoring a signal strength state relative to a threshold (par. [0175] “recognize the strength of the signal … whether the recognized signal strength is less than reference signal strength”).
It would have been obvious prior to the effective filing date of the claimed invention to monitor and the vehicle for a desirable state and pause the installation in response to a change in monitored state conditions to an undesirable state. Those of ordinary skill in the art would have been motivated to do so to “increase[e] the robustness” of the installation process (see e.g. Zymeri par. [0007]) and ensure that the owner isn’t using the vehicle during the update (Sangameswaran par. [0064]).
Claim 41: Sangameswaran, Zymeri , Moeller, Davidson, Choi, Landry and Lee teach the vehicle of Claim 40, wherein the computing device is further programmed to perform actions comprising:
storing the first software update in the storage media as a current backup software version for the first ECU (Sangameswaran par. [0057] “A resilient backup version of a currently installed software version also exists, in case the update fails”, par. [0060] “memory locations A and B … for holding the update and a backup version”);
Claim 42: Sangameswaran, Zymeri , Moeller, Davidson, Choi, Landry and Lee teach the vehicle of Claim 41, wherein storing the first software update in the storage media as the current backup software version for the first ECU comprises overwriting the compatible backup software version for the first ECU (Sangameswaran par. [0070] “flashing/loading the current build/version … if a copy does not already exist”).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASON D MITCHELL whose telephone number is (571)272-3728. The examiner can normally be reached Monday through Thursday 7:00am - 4:30pm and alternate Fridays 7:00am 3:30pm.
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 (571)272-3759. 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.
/JASON D MITCHELL/Primary Examiner, Art Unit 2199