DETAILED ACTION
Remarks
Applicant presents a communication dated 28 July 2025 responsive to the 30 May 2025 non-final Office action (the “Previous Action”).
With the communication:
Claims 1, 5, 7-8, 12-15 and 19-20 are amended;
Claims 4, 11 and 18 are cancelled;
Claims 21 and 22 are added.
Claims 1-3, 5-10, 12-17 and 19-22 remain pending in this application. Claims 1, 8 and 15 are the independent claims.
Any unpersuasive arguments are addressed in the “Response to Arguments” section below.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Examiner Notes
Examiner cites particular columns, paragraphs, figures 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 their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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 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.
Response to Arguments
Applicant presents no arguments and only amends the claims.
Claim Rejections - 35 USC § 112
The Previous Action’s § 112(a) rejections are withdrawn in view of Applicant’s claim amendments.
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.
Claim 1, 5, 7-8, 12, 14-15, 19 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Bauchot et al. (US 2006/0294514) (art of record – hereinafter Bauchot) in view of Nemawarkar et al. (US 2005/0034049) (art made of record – hereinafter Nemarwarkar), and Ang et al. (US 2017/0249137) (art made of record – hereinafter Ang).
As to claim 1, Bauchot discloses a method, comprising:
receiving, by a vehicle, an initial portion of a software update from a first node; (e.g., Bauchot, par. [0043]: each vehicle is able to determine whether or not the other vehicle [first node] is carrying a more recent version of the codes it is carrying and which segment(s) of code it can obtain from the other vehicle. When a vehicle determines that it can obtain one or more code segments from another vehicle, it starts a code transfer session for the selected segments to be obtained. Each vehicle can act as both a server and a client for the other vehicle)
detecting, by the vehicle, an issue with a last sub-portion of the software update (e.g., Bauchot, par, [0045]: code segments can be downloaded in any order. The download of a given code can be interrupted at any segment [this segment at which the download is interrupted is the last sub-portion]; par. [0076]: the last event handled is “Partner lost” 440 generated by the physical connection manager when the physical connection has been dropped;)
responsive to detecting the issue, stopping, by the vehicle, the software update (e.g., Bauchot, par. [0076]: the last event handled is “Partner lost” 440 generated by the physical connection manager when the physical connection has been dropped. On receipt of this event, the session manager verifies if a Client session exists 450. If it is the case, then a “Close Session” 455 is sent to the client process in order to stop it)
a point in the software update where the issue was encountered (e.g., Bauchot, par, [0045]: the download of a given code can be interrupted at any segment) and the second node (see immediately below)
receiving, by the vehicle, a remaining portion of the software update from the second node (e.g., Bauchot, par. [0045]: the download of a given code can be interrupted at any segment, and restarted either with the same vehicle or with another vehicle [second node]; par. [0054]: bit set to 1 indicates that the chunk has been received; par. [0056]: the “Status” field 207 may take 3 different values which are “Installed”, “Installable” when the code has been entirely received).
Bauchot does not explicitly disclose detecting an issue with a last sub-portion of the software update based on a cyclic redundancy check (CRC); determining a second node that includes the software update based on manufacturer data stored within a memory of the vehicle; and transmitting an identifier of a point in the software update where the issue was encountered to the second node.
However, in an analogous art, Nemawarkar discloses:
detecting an issue with a last sub-portion based on a cyclic redundancy check (CRC); (e.g., Nemarwarkar, par. [0082]: individual transactions may be segmented in non-consecutive packets; par. [0192]: the CRC check is compared with CRC check information encoded in the packet to check the packet for errors; par. [0197]: a packet may be considered error-free if the encoded CRC value is compared with a re-computed value. Once a packet is received without errors, its sequence identifier is noted as the last good sequence identifier to be sent in the next ACK packet; par. [0198]: even during normal flow of packets, errors can occur. For example, if an acknowledgement packet is not received, then ACK timeout error can occur. Alternatively, the encoded CRC value may not match a re-computed CRC value. According to embodiments, any such error forces the link on which the packet was sent to be shut down).
transmitting, an identifier of a point where the issue was encountered to the node; (e.g., Nemarwarkar, par. [0199]: once the link is down due to error, the PHY layers re-connect. Once this PHY link is up, the last good reception of packets at each interconnection controller is conveyed to the other interconnection controller using ACK packets; par. [0192]: the ACK packet indicating the sequence identifier of the last error-free packet received)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the vehicle detecting of issues with a last sub-portion of a software update taught by Bauchot, such that an issue with the last portion is detected based on a cyclic redundancy check (CRC), as taught by Nemawarkar, as Nemawarkar would provide the advantage of a means of checking each portion for errors. (See Nemawarkar, par. [0192]). It also would have been obvious to substitute the checking of each portion by means of the hashes taught by Bauchot with checking by means of a CRC, as taught by Nemawarkar, as both are means of checking data and Nemawarkar shows that data can be checked using a CRC instead of the hashes disclosed by Bauchot and achieve the same result. (See M.P.E.P. § 2143(I)(B)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the point in which an issue was encountered during download of a software update and resumption of the update download from a second node taught by Bauchot, such that an identifier of the point where the issue was encountered is transmitted to the node from where the download is resumed, as taught by Nemawarkar, as Nemawarkar would provide the advantage of a means of resuming the download from the point in which the issue was encountered. (See Nemarwarkar, par. [0200]).
Further, in an analogous art, Ang discloses:
determining a second node that includes the software update based on manufacturer data stored within a memory of the device; (e.g., Ang, Fig. 1 and associated text, par. [0063]: the first terminal [device] may preset, in the first terminal [i.e., in its memory], a list of device models compatible with the device model of the first terminal, as shown in Table 1 [see table it indicates that certain phones of the brand “Huawei” (manufacturer) are compatible with the first terminal]. If the device model of the second terminal [second node] is in the preset list of device models, the first terminal determines that the device model of the second terminal conforms to the device model of the first terminal; par [0065]: if the second terminal is compatible, it indicates the software used by the second terminal is also applicable to the first terminal; par. [0069]: in step S103, the first terminal obtains, from the second terminal, the software data so that the first terminal completes system upgrade according to the system software data; par. [0104]: if the connection is interrupted, the first terminal may determine whether the device model of the third terminal [also second node] is compatible)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the vehicle (i.e., a device) downloading a software update taught by Bauchot, such that the device determines a second node that includes the software update based on manufacturer data stored within a memory of the device, as taught by Ang, as Ang would provide the advantage of a means of identifying which brands have software compatible with the downloading device. (See Ang, pars. [0061-0062]).
As to claim 5, Bauchot/Nemawarkar/Ang discloses the method of claim 1 (see rejection of claim 1 above), Bauchot further discloses:
wherein receiving the remaining portion comprises:
identifying a signature in the remaining portion of the software update; (e.g., Bacuhot, par. [0107]: one way hashing is compared at step 665 to the hashing extracted from the signature (Csig) [signature] sent by the partner server. Signature (Csig) is decrypted using “Public key” 222 [the chunk(s) and signature(s) from the “another vehicle” cited with respect to claim 1 being the remaining portion])
generating a calculated signature based on the remaining portion; (e.g., par. [0104]: a one way hashing [calculated signature] is calculated at step 660 on chunk data (Cdata)) and
determining the calculated signature matches the signature in the remaining portion (e.g., Bauchot, par. [0109]: if both hashings match, the chunk is valid).
As to claim 7, Bauchot/Nemawarkar/Ang discloses the method of claim 1 (see rejection of claim 1 above), Bauchot further discloses wherein the determining comprises: identifying a compatible vehicle within a range of the vehicle; (e.g., Bauchot, par. [0066]: each vehicle has wireless short range means to communicate with other neighbor vehicles; par. [0071]: a new partner has been detected [if the vehicles are able to connect, communicate and use each other’s software with each other, they are compatible]) and the receiving comprises receiving the remaining portion from the compatible vehicle (e.g., Bauchot, par. [0045]: the download of a given code can be interrupted at any segment, and restarted with the same vehicle or with another vehicle).
As to claim 8, it is a system claim whose limitations are substantially the same as those of claim 1. Accordingly, it is rejected for substantially the same reasons. Further limitations, disclosed by Bauchot, include:
a processor; (e.g., Bauchot, par. [0021]: a computer program executed on a computer system [processor, or comprising one] for updating embedded computer programs) and
a memory, coupled to the processor, comprising instructions that when executed by the processor are configured (see immediately above, the program [instructions] must be stored in memory coupled to the processor if they are executed) to: (see rejection of claim 1 above).
As to claim 12, it is a system claim whose limitations are substantially the same as those of claim 5. Accordingly, it is rejected for substantially the same reasons.
As to claim 14, it is a system claim whose limitations are substantially the same as those of claim 7. Accordingly, it is rejected for substantially the same reasons.
As to claim 15, it is a medium claim whose limitations are substantially the same as those of claim 1. Accordingly, it is rejected for substantially the same reasons. Further limitations, disclosed by Bauchot, include:
a non-transitory computer readable storage medium comprising instructions, that when read by a processor, cause a processor (e.g., Bauchot, par. [0021]: a computer program [necessarily stored in a non-transitory medium] executed [read] on a computer system [processor, or comprising one] for updating embedded computer programs) to perform (see rejection of claim 1 above).
As to claim 19, it is a medium claim whose limitations are substantially the same as those of claim 5. Accordingly, it is rejected for substantially the same reasons.
As to claim 22, Bauchot/Nemawarkar/Ang discloses the method of claim 1 (see rejection of claim 1 above) Bauchot further discloses:
further comprising combining the initial portion of the software update from the first node and the remaining portion of the software update form the second node, and installing the combined portions of the software update in the vehicle (e.g., Bauchot, par. [0046]: segments of code are kept in memory (buffered) until the entire code is constituted. When the code is entirely constituted, it can actually be installed on the Electronic Control Unit requiring it).
Claims 2, 9 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Bauchot (US 2006/0294514) in view of Nemawarkar (US 2005/0034049) in view of Ang (US 2017/0249137) in further view of Muttik (US 2015/0257026) (art of record – hereinafter Muttik).
As to claim 2, Bauchot/Nemawarkar/Ang discloses the method of claim 1 (see rejection of claim 1) Bauchot further discloses the software update and the vehicle (see rejection of claim 1 above), but Bauchot/Nemawarkar/Ang does not explicitly disclose wherein the method further comprises: determining the signal strength between the vehicle and the first node; adjusting a download time of the software update from the first node, based on the signal strength.
However, in an analogous art, Muttik discloses:
wherein the method further comprises:
determining a signal strength between the device and the first node; (e.g., Muttik, par. [0039]: the scheme needs to pay attention to the diminishing signal strength as it indicates the connection may soon be interrupted if the device continues to move at its current pace)
adjusting a download time of the data from the first node, based on the signal strength; (e.g., Muttik, par. [0010]: transmission “(both downloads and uploads)”; Fig. 4 and associated text par. [0039]: the scheme needs to pay attention to the diminishing signal strength as it indicates the connection may soon be interrupted if the device continues to move at its current pace. In such instances this can trigger the scheme to estimate a remaining window to complete the transmission. The scheme may apply Equations 1 and 2 to determine an expected remaining time window for transmission [adjusting a download time, note too in the figure that it is calculated repetitively at step 435]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the downloading of software update data to a vehicle of Bauchot by determining a received signal strength of the downloading device, adjusting a download time based on the signal strength and receiving the downloaded data within the download time, as taught by Muttik, as Muttik would provide the advantage of a means of decreasing the number of failed transmissions. (See Muttik, par. [0017]).
As to claim 9, it is a system claim whose limitations are substantially the same as those of claim 2. Accordingly, it is rejected for substantially the same reasons.
As to claim 16, it is a medium claim whose limitations are substantially the same as those of claim 2. Accordingly, it is rejected for substantially the same reasons.
Claim 3, 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Bauchot (US 2006/0294514) in view of Nemawarkar (US 2005/0034049) in view of Ang (US 2017/0249137) in further view of Choi (US 2017/0123782) (art of record – hereinafter Choi).
As to claim 3, Bauchot/Nemawarkar/Ang discloses the method of claim 1 (see rejection of claim 1 above), Bauchot further discloses the software update (see rejection of claim 1 above) and validating an amount of the initial portion received (e.g., Bauchot, par. [0109]: if both hashings match, the chunk [initial portion, see rejection of claim 1 above] is valid) but Bauchot/Nemawarkar/Ang does not explicitly disclose wherein the stopping the software update comprises: determining the signal strength has fallen below a threshold while receiving the software update; and validating an amount of the initial portion received while the signal strength is above the threshold.
However, in an analogous art, Choi discloses wherein the stopping the software update comprises:
determining, a signal strength has fallen below the threshold while receiving the software update; (e.g., Choi, par. [0181]: the vehicle starts driving [moving] during the standby mode and thus switches to normal mode; par. [0182]: if normal mode is performed, the vehicle may determine the presences of the stored update notification message. If the message is present, the vehicle may download the update file; par. [0233]: the controller 133 may confirm the signal strength when downloading the update file. If the confirmed signal strength is less than reference signal strength [a threshold], the controller 133 may stop downloading) and
the initial portion received while the signal strength is above the threshold (e.g., Choi, Fig. 3 and associated text, the vehicle may re-download the update file from the server in operation 308; par. [0168]: the operation for re-downloading the interrupted update file may include downloading the update file starting from the download-interrupted data from among the update file [the data before that starting point being the initial portion received while the signal strength is above the threshold]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the update downloading and validation of a portion of the update received before the downloading is stopped taught by Bauchot such that the download is received while the signal strength is above a threshold and stopped if the signal strength falls below the threshold, as taught by Choi, as Choi would provide the advantage of a means of ensuring the download only takes place with a sufficiently strong signal. (See Choi, pars. [0233-0234]).
As to claim 10, it is a system claim whose limitations are substantially the same as those of claim 3. Accordingly, it is rejected for substantially the same reasons.
As to claim 17, it is a medium claim whose limitations are substantially the same as those of claim 3. Accordingly, it is rejected for substantially the same reasons.
Claims 6, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Bauchot (US 2006/0294514) in view of Nemawarkar (US 2005/0034049) in view of Ang (US 2017/0249137) in further view of Imoto et al. (US 2017/0070755) (art of record – hereinafter Imoto).
As to claim 6, Bauchot/Nemawarkar/Ang discloses the method of claim 1 (see rejection of claim 1 above), Bauchot further discloses the software update (see rejection of claim 1 above) but does not explicitly disclose comprising: identifying a location in the initial portion of the software update that corresponds to the issue; determining an endpoint of the initial portion preceding the location; and designating a difference between the endpoint and an end of the software update as the remaining portion.
However, in an analogous art, Imoto discloses comprising:
identifying a location in the initial portion of the data that corresponds to the issue; (e.g., Imoto, par. [0170]: for example, when the video has been downloaded up to 120 MB from the beginning of the video data before the cutoff of wireless communication [i.e., 120MB is the location that corresponds to the issue], the OS 335 sends a request for a byte range of the data from 119MB to the end. In this example, the origin (119MB) of the byte range that is requested is set to 1MB before the end (120 MB) of the video data that has been downloaded by the time the download is interrupted)
determining an endpoint of the initial portion preceding the location; (e.g., Imoto, par. [0163]: the OS 335 is configured to send the download request for the video data of a byte range from a location before the download interruption [endpoint of the initial portion preceding the location] to the end of the video data par. [0170]: the OS 3356 sends a download request for the resume video data by designating the byte range of the video data before the download interruption to the end of the video data;) and
designating a difference between the endpoint and an end of the data as the remaining portion (see immediately above).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the downloading and resumed downloading of software update data of Bauchot such that a location in the initial portion of the downloaded data corresponding to the issue is identified, an endpoint of the initial portion preceding the location is determined and a difference between the endpoint and an end of the data is designated as the remaining portion, as taught by Imoto, as Imoto would provide the advantage of a means of preventing malfunction due to use of the data between the endpoint and the location of the issue. (See Imoto, par. [0178]).
As to claim 13, it is a system claim whose limitations are substantially the same as those of claim 6. Accordingly, it is rejected for substantially the same reasons.
As to claim 20, it is a medium claim whose limitations are substantially the same as those of claim 6. Accordingly, it is rejected for substantially the same reasons.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Bauchot (US 2006/0294514) in view of Nemawarkar (US 2005/0034049) in view of Ang (US 2017/0249137) in further view of Fry (US 2004/0117459) (art of record – hereinafter Fry).
As to claim 21, Bauchot/Nemawarkar/Ang discloses the method of claim 1 (see rejection of claim 1 above), Bauchot further discloses:
where the transmitting an identifier comprises transmitting an identifier of the software update to the second node (e.g., Bauchot, par. [0079]: a “GetUpdate” is received as having the parameters: [0080] the code identification).
Bauchot/Nemawarkar/Ang does not explicitly disclose the transmitting an identifier comprises transmitting an identifier and a number of bytes that have been successfully received so far to the second node.
However, in an analogous art, Fry discloses:
the transmitting an identifier comprises transmitting an identifier and a number of bytes that have been successfully received so far to the node (e.g., Fry, par. [0043]: one method to establish the marker is to store the number of bytes that the client has successfully received. The marker in this case is represented by the number of bytes; Fig. 2 and asscoaited text, par. [0054]: whenb the client is ready to resume MM delivery, he presses Resume. This causes the MM client 1 to use a resume command, i.e., “RESUME MM DOWNLOAD” or “MM_RESUME_REQUEST”. This message preferable includes the marker [and see figure, it also includes the “MM identifier”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the resuming download of a software update having an identifier from a second node taught by Bauchot/Nemawarkar/Ang by incorporating transmitting the identifiers and a number of bytes that have been received so far to the node, as taught by Fry, as Fry would provide the advantage of a means of resuming transmission from the point at which it was suspended. (See Fry, par. [0055]). Bauchot/Nemawarkar also suggests the combination because Bauchot/Nemawarkar discloses transmitting an identifier of the last good portion received and Fry discloses that a number of bytes is such an identifier.
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 nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TODD AGUILERA whose telephone number is (571)270-5186. The examiner can normally be reached M-F 11AM - 7:30PM EST.
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, April Blair can be reached at (571)270-1014. 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.
/TODD AGUILERA/Primary Examiner, Art Unit 2196