DETAILED ACTION
This office action is in response to the amendment filed March 2, 2026.
Claims 1, 3-7, 9, 11-15, 17-19, and 21-25 are pending.
This application is a continuation of application 15/869,868, now US Patent 10,776,096, and application 16/991,369, now US Patent 11,556,328, and the claims herein are examined as entitled to the earlier filing date of January 12, 2018.
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 .
Response to Arguments
Applicant's arguments filed March 2, 2026 have been fully considered but they are not persuasive. Applicant’s arguments with respect to claim(s) 1, 3-7, 9, 11-15, 17-19, and 21-25 have been considered but are not persuasive. Specifically, Applicant’s amendment necessitated a new ground of rejection including the teachings of as applied herein. As such these arguments are not persuasive in relation to the necessitated updated grounds of rejection herein.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1,4,9,12,17, 21 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1,1,7,7, and 13, 13 respectively of U.S. Patent No. 11,556,328 and further in view of “Jang” (US PG Pub 2014/0325500) and further in view of “Pereira Cabral” (US PG Pub 2018/0052681)
Although the claims at issue are not identical, they are not patentably distinct from each other because the pending claims are obvious in view of the patented claims as aligned herein below.
Claims 1,4,9,12,17, 21 are further ejected on the ground of nonstatutory double patenting as being unpatentable over claim 1,1,8,8, and 15, 15 respectively of U.S. Patent No. 10,776,096 both in view of “Rockwell” (US PG Pub 2015/0339114) in view of “Searle” (US PG Pub 2016/0117162) and further in view of “Choi” (US PG Pub 2016/0147525). and further in view of “Jang” (US PG Pub 2014/0325500) and further in view of “Pereira Cabral” (US PG Pub 2018/0052681) Although the claims at issue are not identical, they are not patentably distinct from each other because the pending claims are obvious in view of the patented claims as aligned herein below. Specifically, the bolded portions in the table below are taught or suggested by the aligned bolded patent claim limitations, wheras the other elements are taught or suggested by the prior art as set forth below the table. The Dependent claims 4,12, and 21 are rejected based on the final bolded portion of each respective patented independent claim as cited in the table below.
This Application
Patent 10,776,096
Patent 11,556,328
1. (currently amended) A method comprising:
receiving, by a first device, a software update download for updating software of the first device; the first device being affixed to or part of an unmanned vehicle;
in response to receiving the software update download, sending, by the first device, a first download complete message to an intermediary component that allows a first communication between the first device and a second device to be established; second device being not affixed to or part of the unmanned vehicle;
sending, by the first device to the intermediary component, a connect message including an identifier to establish a second communication between the first device and the intermediary component;
sending, by the first device to the intermediary component, an informing message including information indicating that conditions for installing the software update download have been met;
receiving, by the first device from the intermediary component, a command to install the software update download; and in response to the command, initiating, by the first device, an installation process to install the software update download.
sending, by the first device to the second device via the intermediary component, an informing message…
the informing message enabling a user interface at the second device for allowing the software update;
when user input is applied to the user interface…from the second device via the intermediary component
4. (currently amended) The method of claim 1, further comprising: sending, to the intermediary component, status messages concerning the installation of the software update download.
9. (currently amended) A computing device of an unmanned vehicle, the computing device comprising: a processor; and a communications subsystem, wherein the computing device of the unmanned vehicle is configured to:receive a software update download for updating software of the computing device;in response to receiving the software update download, send a first download complete message to an intermediary component that allows a first communication between the computing device and a second device to be established;send, to the intermediary component,Va connect message including an identifier to establish a second communication between the computing device and the intermediary component; send, to the intermediary component,an informing message including information indicating that conditions for installing the software update download have been met;
receive, from the intermediary component, a command to install the software update download;
and in response to the command, initiate an installation process to install the software update download.
sending, by the first device to the second device via the intermediary component, an informing message…
the informing message enabling a user interface at the second device for allowing the software update;
when user input is applied to the user interface…from the second device via the intermediary component
12. (currently amended) The computing device of claim 9, wherein the computing device is further configured to: send, to the intermediary component, status messages concerning the installation of the software update download.
17. (currently amended) A non-transitory computer readable medium for storing instruction code, which when executed by a processor of a computing device of an unmanned vehicle, causes the computing device to: receive a software update download for updating software of the computing device of an unmanned vehicle,; in response to receiving the software update download, send a first download complete message to an intermediary component #that allows a first communication between the computing device and a second device to be established;send, to the intermediary component,la connect message including an identifier to establish a second communication between the computing device and the intermediary component;send, to the intermediary component, an informing message including information indicating that conditions for installing the software update download have been met;
sending, by the first device to the second device via the intermediary component, an informing message…
the informing message enabling a user interface at the second device for allowing the software update;
when user input is applied to the user interface…from the second device via the intermediary component
receive, from the intermediary component, a command to install the software update download; and in response to the command, initiate an installation process to install the software update download.
21. (currently amended) The non-transitory computer readable medium of claim 17, wherein the instruction code further causes the computing device to send, to the intermediary component, status messages concerning the installation of the software update download.
1. A method at an Electronic Control Unit (ECU) of a vehicle acting as a switchboard between a wireless communications device, and a device to be updated, the method comprising:
receiving, at the ECU, a connection request from the wireless communications device, the connection request including a unique identifier;
receiving, at the ECU, a connection request from the device to be updated; associating, at the ECU, the connection request from the wireless communications device and the connection request from the device to be updated, when the unique identifier matches an identifier for the device to be updated;
receiving, at the ECU, a first message from the device to be updated indicating that update conditions have been met;
transmitting, from the ECU, the first message to the wireless communication device; forwarding, at the ECU, a second message from the wireless communications device to the device to be updated to start an update process;
and forwarding, at the ECU, update status information from the device to be updated to the wireless communications device.
[see claim 1 above]
8. An Electronic Control Unit (ECU) of a vehicle configured to act as a switchboard between a wireless communications device and a device to be updated, the ECU comprising: a processor; and a communications subsystem, wherein the ECU is configured to: receive a connection request from the wireless communications device, the connection request including a unique identifier; receive a connection request from the device to be updated; associate the connection request from the wireless communications device and the connection request from the device to be updated, when the unique identifier matches an identifier for the device to be updated; receive, at the ECU, a first message from the device to be undated indicating that update conditions have been met; transmit, from the ECU, the first message to the wireless communications device; forward a second message from the wireless communications device to the device to be updated to start an update process;
and forward update status information from the device to be updated to the wireless communications device.
[see claim 8 above]
15. A non-transitory computer readable medium for storing instruction code, which when executed by a processor an Electronic Control Unit (ECU) of a vehicle configured to act as a switchboard between a wireless communications device and a device to be updated, cause the ECU to: receive a connection request from the wireless communications device, the connection request including a unique identifier; receive a connection request from the device to be updated; associate the connection request from the wireless communications device and the connection request from the device to be updated, when the unique identifier matches an identifier for the device to be updated; receive, at the ECU, a first message from the device to be updated indicating that update conditions have been met; transmit, from the ECU the first message to the wireless communications device; forward a second message from the wireless communications device to the device to be updated to start an update process;
and forward update status information from the device to be updated to the wireless communications device.
[See claim 15 above]
1. A method at a network server acting as a switchboard between a wireless communications device, and a device to be updated, the method comprising:
receiving, at the network server, a connection request from the wireless communications device, the connection request from the wireless communications device including a unique identifier; receiving, subsequent to the connection request from the wireless communications device, at the network server, a connection request from the device to be updated, the connection request from the device to be updated being based on the device to be updated being put into an update state, the connection request from the device to be updated further including the unique identifier; associating, at the network server, the connection request from the wireless communications device and the connection request from the device to be updated based on the unique identifier; receiving, at the network server, a first message from the device to be updated indicating that update conditions have been met, the update conditions comprising a physical authenticating interaction at the device to be updated while in the update state; transmitting, from the network server, the first message to the wireless communications device; forwarding, at the network server, a second message from the wireless communications device to the device to be updated to start an update process;
and forwarding, at the network server, update status information from the device to be updated to the wireless communications device.
[see claim 1 above]
7. A network server configured to act as a switchboard between a wireless communications device and a device to be updated, the network server comprising: a processor; and a communications subsystem, wherein the network server is configured to: receive a connection request from the wireless communications device, the connection request from the wireless communications device including a unique identifier; receive, subsequent to the connection request from the wireless communications device, a connection request from the device to be updated, the connection request from the device to be updated being based on the device to be updated being put into an update state, the connection request from the device to be updated further including the unique identifier; associate the connection request from the wireless communications device and the connection request from the device to be updated based on the unique identifier; receive, at the network server, a first message from the device to be updated indicating that update conditions have been met, the update conditions comprising a physical authenticating interaction at the device to be updated while in the update state;
transmit, from the network server, the first message to the wireless communications device; forward a second message from the wireless communications device to the device to be updated to start an update process;
and forward update status information from the device to be updated to the wireless communications device.
[see claim 7 above]
13. A non-transitory computer readable medium for storing instruction code, which when executed by a processor of a network server configured to act as a switchboard between a wireless communications device and a device to be updated, cause the network server to: receive a connection request from the wireless communications device, the connection request from the wireless communications device including a unique identifier; receive, subsequent to the connection request from the wireless communications device, a connection request from the device to be updated, the connection request from the device to be updated being based on the device to be updated being put into an update state, the connection request from the device to be updated further including the unique identifier; associate the connection request from the wireless communications device and the connection request from the device to be updated based on the unique identifier; receive, at the network server, a first message from the device to be updated indicating that update conditions have been met, the update conditions comprising a physical authenticating interaction at the device to be updated while in the update state; transmit, from the network server, the first message to the wireless communications device; forward a second message from the wireless communications device to the device to be updated to start an update process;
and forward update status information from the device to be updated to the wireless communications device.
[See claim 13 above]
The patented claims do not explicitly teach, for example with respect to claim 1, but Rockwell teaches:
1. (currently amended) A method comprising: receiving, by a first device, a software update download for updating software of the first device; (Rockwell see download of claim 3, ¶33, Fig. 2, 800, 802 Fig. 8, ¶¶49-50 describes recognizing the start of an update state)
and in response to the command, initiating, by the first device, an installation process to install the software update download. (Rockwell updating in ¶¶56-59, 814-820 Fig. 8) In addition it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of the patented claims and Rockwell as each is directed to vehicle software update processes and Rockwell recognized the need for networked updates The patented claims further does not teach, Rockwell recognized the utility of avoiding manual dealership updates (e.g. ¶4) and updating using “any other device having wireless remote network connectivity.” (¶21).
sending, by the first device to the intermediary component, a connect message including an identifier to establish a second communication between the first device and the intermediary component; (See Searle 321 Fig. 52 fig. 3 610, 6134 Fig. 6 sending a connection notification to the update server, including a identifier as in ¶61, to indicate beginning of the update process for that device and that the device is in a connected state) In addition it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of the patented claims and Searle as each is directed to vehicle software update processes and Searle’s system “helps manage and update embedded devices that traditionally have been inaccessible and impracticable to update.” (¶46).
The Patented claims does not teach, but Choi teaches: in response to receiving the software update download, sending, by the first device, a first download complete message to an intermediary component that allows a first communication between the first device and a second device to be established; (Choi ¶52, S200, Fig 3 teaches the telematics terminal sending a download complete message to the server 300, which relays the download completion information to the terminal in ¶52)
In addition it would have been obvious to one of ordinary prior to the effective filing date of the application to combine the teachings of the patented claims et al with those of Choi as each is directed to software update systems and Choi recognized the utility of “t he mobile terminal 100 is a terminal that user holds, and any device, which can perform wireless communication and install application for vehicle control, may correspond to it..” (¶19)
The patented claims et al do not teach but Jang teaches:
sending, by the first device to the second device via the intermediary component, an informing message…
(JANG ¶¶46, 52-53, 60-64, 45-47, CLAIM 19, FIG. 4 teaches a system which, in some embodiments may have a user terminal indirectly connected to an update device of a vehicles w/ ECUs to update which receives information on updates stored at the update device by comparison to version applied to the ECU and the user may send a message indirectly to the update device via the update service to update the ECU)
the informing message enabling a user interface at the second device for allowing the software update; (JANG ¶¶46, 52-53, 60-64, 45-47, CLAIM 19, FIG. 4 teaches a system which, in some embodiments may have a user terminal indirectly connected to an update device of a vehicles w/ ECUs to update which receives information on updates stored at the update device by comparison to version applied to the ECU and the user may send a message indirectly to the update device via the update service to update the ECU)
when user input is applied to the user interface…from the second device via the intermediary component (JANG ¶¶46, 52-53, 60-64, 45-47, CLAIM 19, FIG. 4 teaches a system which, in some embodiments may have a user terminal indirectly connected to an update device of a vehicles w/ ECUs to update which receives information on updates stored at the update device by comparison to version applied to the ECU and the user may send a message indirectly to the update device via the update service to update the ECU)
In addition it would have been obvious to one of ordinary prior to the effective filing date of the application to combine the teachings of The patented claims et al with those of Jang as each is directed to update systems and Jang recognized “ it is difficult for consumers to update the electronic control units of the cars, which have problems, easily and conveniently…” (¶4).
The Patent Claims do not teach, but Pereira Cabral teaches:
the first device being affixed to or part of an unmanned vehicle; (See e.g. Drones in Fig. 3, ¶63 describes drones as devices in a network connected via access points over the local network and then to internet as in Fig. 1 to cloud services, e.g. for software updates as in ¶¶50, Figs. 9, 10A-C)
device being not affixed to or part of the unmanned vehicle; (See e.g. Drones in Fig. 3, ¶63 describes drones as devices in a network connected via access points over the local network and then to internet as in Fig. 1 to cloud services, e.g. for software updates as in ¶¶50, Figs. 9, 10A-C)
In addition it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the patented claims and Pereira Cabral as each is directed to software update processes and Pereira Cabral recognized “Current communication networks are unable to adequately support communication environments involving mobile and static nodes” (¶2 )and provides systems for improving network support for drone updates and other purposes.
Claims 9 and 17 are rejected on the same basis.
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(s) 1,3,4,6,7,9,11,12 14,15,17,18,19, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over “Rockwell” (US PG Pub 2015/0339114) in view of “Searle” (US PG Pub 2016/0117162), “Choi” (US PG Pub 2016/0147525) and “Madrid” (US US PG Pub 2018/0189049), “Jang” (US PG Pub 2014/0325500) and “Pereira Cabral” (US PG Pub 2018/0052681).
Regarding Claim 1, Rockwell teaches:
1. (currently amended) A method comprising: receiving, by a first device, a software update download for updating software of the first device; (Rockwell see download of claim 3, ¶33, Fig. 2, 800, 802 Fig. 8, ¶¶49-50 describes recognizing the start of an update state)
and in response to the command, initiating, by the first device, an installation process to install the software update download. (Rockwell updating in ¶¶56-59, 814-820 Fig. 8)
Rockwell does not teach, but Searle teaches:
sending, by the first device to the intermediary component, a connect message including an identifier to establish a second communication between the first device and the intermediary component; (See Searle 321 Fig. 52 fig. 3 610, 6134 Fig. 6 sending a connection notification to the update server, including a identifier as in ¶61, to indicate beginning of the update process for that device and that the device is in a connected state)
receiving, by the first device from the intermediary component, a command to install the software update download; (See Searle ¶¶74-76, Fig 6-7 teaches the server sending the update to the vehicle to commence the update process).
In addition it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Rockwell and Searle as each is directed to vehicle software update processes and Searle’s system “helps manage and update embedded devices that traditionally have been inaccessible and impracticable to update.” (¶46).
Rockwell does not teach, but Choi teaches: in response to receiving the software update download, sending, by the first device, a first download complete message to an intermediary component that allows a first communication between the first device and a second device to be established; (Choi ¶52, S200, Fig 3 teaches the telematics terminal sending a download complete message to the server 300, which relays the download completion information to the terminal in ¶52)
In addition it would have been obvious to one of ordinary prior to the effective filing date of the application to combine the teachings of Rockwell et al with those of Choi as each is directed to software update systems and Choi recognized the utility of “t he mobile terminal 100 is a terminal that user holds, and any device, which can perform wireless communication and install application for vehicle control, may correspond to it..” (¶19)
Rockwell does not teach, but Madrid teaches:sending, by the first device to the intermediary component, an informing message including information indicating that conditions for installing the software update download have been met; (Madrid, e.g. ¶43 describes a device to be updated receiving a signal e.g. from another component over a bus, a signal that the conditions for updating have been met, in response to the condition being met, Madrid initiates update processing in e.g. 404, Fig. 4)
In addition it would have been obvious to one of ordinary prior to the effective filing date of the application to combine the teachings of Rockwell et al with those of Madrid as each is directed to software update systems and Madrid recognized the need for “a method for over-the-air software updates includes confirming, by a vehicle ECU at keyoff before vehicle shutdown…” (¶5).
Rockwell et al do not teach but Jang teaches:
sending, by the first device to the second device via the intermediary component, an informing message…
(JANG ¶¶46, 52-53, 60-64, 45-47, CLAIM 19, FIG. 4 teaches a system which, in some embodiments may have a user terminal indirectly connected to an update device of a vehicles w/ ECUs to update which receives information on updates stored at the update device by comparison to version applied to the ECU and the user may send a message indirectly to the update device via the update service to update the ECU)
the informing message enabling a user interface at the second device for allowing the software update; (JANG ¶¶46, 52-53, 60-64, 45-47, CLAIM 19, FIG. 4 teaches a system which, in some embodiments may have a user terminal indirectly connected to an update device of a vehicles w/ ECUs to update which receives information on updates stored at the update device by comparison to version applied to the ECU and the user may send a message indirectly to the update device via the update service to update the ECU)
when user input is applied to the user interface…from the second device via the intermediary component (JANG ¶¶46, 52-53, 60-64, 45-47, CLAIM 19, FIG. 4 teaches a system which, in some embodiments may have a user terminal indirectly connected to an update device of a vehicles w/ ECUs to update which receives information on updates stored at the update device by comparison to version applied to the ECU and the user may send a message indirectly to the update device via the update service to update the ECU)
In addition it would have been obvious to one of ordinary prior to the effective filing date of the application to combine the teachings of Rockwell et al with those of Jang as each is directed to update systems and Jang recognized “ it is difficult for consumers to update the electronic control units of the cars, which have problems, easily and conveniently…” (¶4).
Rockwell does not teach, but Pereira Cabral teaches:
the first device being affixed to or part of an unmanned vehicle; (See e.g. Drones in Fig. 3, ¶63 describes drones as devices in a network connected via access points over the local network and then to internet as in Fig. 1 to cloud services, e.g. for software updates as in ¶¶50, Figs. 9, 10A-C)
device being not affixed to or part of the unmanned vehicle; (See e.g. Drones in Fig. 3, ¶63 describes drones as devices in a network connected via access points over the local network and then to internet as in Fig. 1 to cloud services, e.g. for software updates as in ¶¶50, Figs. 9, 10A-C)
In addition it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Rockwell and Pereira Cabral as each is directed to vehicle software update processes and Pereira Cabral recognized “Current communication networks are unable to adequately support communication environments involving mobile and static nodes” (¶2 )and provides systems for improving network support for drone updates and other purposes.
Claims 17 is rejected on the same basis as claim 1 above.
Regarding Claim 9, Rockwell teaches:
9. (currently amended) A computing device comprising:
a processor; (processor and update system e.g. ¶3) and a communications subsystem, (processor and update system e.g. ¶3)
wherein the computing device is configured to:receive a software update download for updating software of the computing device; (Rockwell see download of claim 3, ¶33, Fig. 2, 800, 802 Fig. 8, ¶¶49-50 describes recognizing the start of an update state)
and in response to the command, initiate an installation process to install the software update download. (Rockwell updating in ¶¶56-59, 814-820 Fig. 8)
Rockwell does not teach, but Searle teaches:
send, to the intermediary component,Va connect message including an identifier to establish a second communication between the computing device and the intermediary component; (See Searle 321 fig. 3 610, 613-4 Fig. 6 sending a connection notification to the update server, including a identifier as in ¶61, to indicate beginning of the update process for that device and that the device is in a connected state)
receive, from the intermediary component, a command to install the software update download; (See Searle ¶¶74-76, Fig 6-7 teaches the server sending the update to the vehicle to commence the update process).
In addition it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Rockwell and Searle as each is directed to vehicle software update processes and Searle’s system “helps manage and update embedded devices that traditionally have been inaccessible and impracticable to update.” (¶46).
Rockwell does not teach, but Choi teaches:
in response to receiving the software update download, send a first download complete message to an intermediary component that allows a first communication between the computing device and a second device to be established; (Choi ¶52, S200, Fig 3 teaches the telematics terminal sending a download complete message to the server 300, which relays the download completion information to the terminal in ¶52)
In addition it would have been obvious to one of ordinary prior to the effective filing date of the application to combine the teachings of Rockwell et al with those of Choi as each is directed to software update systems and Choi recognized the utility of “t he mobile terminal 100 is a terminal that user holds, and any device, which can perform wireless communication and install application for vehicle control, may correspond to it..” (¶19)
Rockwell does not teach, but Madrid teaches:
send, to the intermediary component,Van informing message including information indicating that conditions for installing the software update download have been met;; (Madrid, e.g. ¶43 describes a device to be updated receiving a signal e.g. from another component over a bus, a signal that the conditions for updating have been met, in response to the condition being met, Madrid initiates update processing in e.g. 404, Fig. 4)
In addition it would have been obvious to one of ordinary prior to the effective filing date of the application to combine the teachings of Rockwell et al with those of Madrid as each is directed to software update systems and Madrid recognized the need for “a method for over-the-air software updates includes confirming, by a vehicle ECU at keyoff before vehicle shutdown…” (¶5).
Rockwell et al do not teach but Jang teaches:
sending, by the first device to the second device via the intermediary component, an informing message…
(JANG ¶¶46, 52-53, 60-64, 45-47, CLAIM 19, FIG. 4 teaches a system which, in some embodiments may have a user terminal indirectly connected to an update device of a vehicles w/ ECUs to update which receives information on updates stored at the update device by comparison to version applied to the ECU and the user may send a message indirectly to the update device via the update service to update the ECU)
the informing message enabling a user interface at the second device for allowing the software update; (JANG ¶¶46, 52-53, 60-64, 45-47, CLAIM 19, FIG. 4 teaches a system which, in some embodiments may have a user terminal indirectly connected to an update device of a vehicles w/ ECUs to update which receives information on updates stored at the update device by comparison to version applied to the ECU and the user may send a message indirectly to the update device via the update service to update the ECU)
when user input is applied to the user interface…from the second device via the intermediary component (JANG ¶¶46, 52-53, 60-64, 45-47, CLAIM 19, FIG. 4 teaches a system which, in some embodiments may have a user terminal indirectly connected to an update device of a vehicles w/ ECUs to update which receives information on updates stored at the update device by comparison to version applied to the ECU and the user may send a message indirectly to the update device via the update service to update the ECU)
In addition it would have been obvious to one of ordinary prior to the effective filing date of the application to combine the teachings of Rockwell et al with those of Jang as each is directed to update systems and Jang recognized “ it is difficult for consumers to update the electronic control units of the cars, which have problems, easily and conveniently…” (¶4).
Rockwell does not teach, but Pereira Cabral teaches:
9. of an unmanned vehicle, the computing device
(See e.g. Drones in Fig. 3, ¶63 describes drones as devices in a network connected via access points over the local network and then to internet as in Fig. 1 to cloud services, e.g. for software updates as in ¶¶50, Figs. 9, 10A-C)
of the unmanned vehicle (See e.g. Drones in Fig. 3, ¶63 describes drones as devices in a network connected via access points over the local network and then to internet as in Fig. 1 to cloud services, e.g. for software updates as in ¶¶50, Figs. 9, 10A-C)
In addition it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Rockwell and Pereira Cabral as each is directed to vehicle software update processes and Pereira Cabral recognized “Current communication networks are unable to adequately support communication environments involving mobile and static nodes” (¶2 )and provides systems for improving network support for drone updates and other purposes.
Regarding Claim 3, Searle teaches:
3. (previously presented) The method of claim 1, wherein the identifier includes vehicle identification number data associated with one or more of a vehicle operational state, update progress, a current release version, and a current release install timestamp. See Searle ¶¶61-62 VINs used in ¶62 to carry out this targeted deployment of the update to the vehicles, including a specified version) In addition it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Rockwell and Searle as each is directed to vehicle software update processes and Searle’s system “helps manage and update embedded devices that traditionally have been inaccessible and impracticable to update.”
Regarding Claim 4, Choi further teaches:
4. (currently amended) The method of claim 1, further comprising: sending, to the intermediary component, status messages concerning the installation of the software update download. (Choi ¶52, S200, Fig 3 teaches the telematics terminal sending a download complete message to the server 300, which relays the download completion information to the terminal in ¶52)
In addition it would have been obvious to one of ordinary prior to the effective filing date of the application to combine the teachings of Rockwell et al with those of Choi as each is directed to software update systems and Choi recognized the utility of “t he mobile terminal 100 is a terminal that user holds, and any device, which can perform wireless communication and install application for vehicle control, may correspond to it..” (¶19)
Claim 21 is rejected on the same basis as clam 4 above.
Regarding Claim 6, Rockwell further teaches:
6. (currently amended) The method of claim 1, further comprising: receiving, using a user interface at the first device, a physical authentication interaction so that the first device enters an update state, wherein the physical authentication interaction provides verification to the intermediary component that a user is present at the first device. (Rockwell 800, 802 Fig. 8, ¶¶49-50 describes recognizing the start of an update state and further 810, fig. 10, ¶54 and Figs. 4-6 describe a physical authentication of the update by selecting an option in the UI and See Rockwell UI requiring physical interaction and presence in Figs. 4-6)
Regarding Claim 7, Choi teaches:
7. (currently amended) The method of claim 1, wherein the second device is configured to receive a second download complete message from the intermediary component. (Choi ¶52, S200, Fig 3 teaches the telematics terminal sending a download complete message to the server 300, which relays the download completion information to the terminal in ¶52)
In addition it would have been obvious to one of ordinary prior to the effective filing date of the application to combine the teachings of Rockwell et al with those of Choi as each is directed to software update systems and Choi recognized the utility of “t he mobile terminal 100 is a terminal that user holds, and any device, which can perform wireless communication and install application for vehicle control, may correspond to it..” (¶19)
Regarding new Claims 23-25, Rockwell does not teach, but Pereira Cabral teaches:
23. (New) The method of claim 1, wherein the unmanned vehicle is connected to a first network and at least one of the intermediate device and the second device is connected to a second network that is different than the first network. (See e.g. Drones in Fig. 3, ¶63 describes drones as devices in a network connected via access points over the local network and then to internet as in Fig. 1 to cloud services, e.g. for software updates as in ¶¶50, Figs. 9, 10A-C; See further e.g. ¶152 describing the networks in the reference as comprising different networks such as e.g. the internet and the local mobile access network) In addition it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Rockwell and Pereira Cabral as each is directed to vehicle software update processes and Pereira Cabral recognized “Current communication networks are unable to adequately support communication environments involving mobile and static nodes” (¶2 )and provides systems for improving network support for drone updates and other purposes.
24. (New) The method of claim 23, wherein the unmanned vehicle is connected to the Internet via a first base station or a first access point on the first network, wherein the intermediate device is accessible via the Internet. (See e.g. Drones in Fig. 3, ¶63 describes drones as devices in a network connected via access points over the local network and then to internet as in Fig. 1 to cloud services, e.g. for software updates as in ¶¶50, Figs. 9, 10A-C) In addition it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Rockwell and Pereira Cabral as each is directed to vehicle software update processes and Pereira Cabral recognized “Current communication networks are unable to adequately support communication environments involving mobile and static nodes” (¶2 )and provides systems for improving network support for drone updates and other purposes.
25. (New) The method of claim 1, wherein the unmanned vehicle is selected from the group consisting of an unmanned aerial vehicle, an unmanned aircraft system, and a drone. (See e.g. Drones in Fig. 3, ¶63 describes drones as devices in a network connected via access points over the local network and then to internet as in Fig. 1 to cloud services, e.g. for software updates as in ¶¶50, Figs. 9, 10A-C) In addition it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of Rockwell and Pereira Cabral as each is directed to vehicle software update processes and Pereira Cabral recognized “Current communication networks are unable to adequately support communication environments involving mobile and static nodes” (¶2 )and provides systems for improving network support for drone updates and other purposes.
Claims 11,12, 14 and 15 are rejected on the same basis as claims 3,4, 6 and 7 respectively above.
Claims 18 and 19 are rejected on the same basis as claims 3 and 7 respectively above.
Claim(s) 5, 13 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over “Rockwell” (US PG Pub 2015/0339114) in view of “Searle” (US PG Pub 2016/0117162) and further in view of “Choi” (US PG Pub 2016/0147525) and “Madrid” (US US PG Pub 2018/0189049) and “Pereira Cabral” (US PG Pub 2018/0052681) as applied above and further in view of “Searle ‘605” (US PG Pub 2016/0294605).
Regarding Claim 5, Rockwell et al teach the limitations of Claim 4 as described above, but do not further teach, while Searle ‘605 teaches:
5. (currently amended) The method of claim 4 wherein the status messages indicate a percentage of completion of the installation. (See e.g. ¶113 teaches sending event messages to the server to notify of events within the system and further see e.g. ¶¶986-987 describes one of the event types as a download progress event specifying a percentage of download completion).
In addition it would have been obvious to one of ordinary prior to the effective filing date of the application to combine the teachings of Rockwell et al with those of Searle ‘605 as each is directed tu update management systems and Searle ‘605 recognized “the need for communicating event data including download progress as “Logged events data may be utilized in a variety of analytics applications including fault analysis, predictive analytics, service (e.g., warranty repair predictions), surveillance, planning (e.g., future products), inference-based analytics, and/or the like.” (¶113).
Claim 13 is rejected on the same basis as clam 5 above.
New Claim 22 is rejected on the same basis as claim 5 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The prior art cited in the attached PTO-892 form includes additional prior art relevant to applicant’s disclosure of various software updating systems and methods.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW J BROPHY whose telephone number is (571)270-1642. The examiner can normally be reached Monday-Friday, 9am-4: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, Wei Zhen can be reached on 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 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.
MJB
3/31/2026
/MATTHEW J BROPHY/Primary Examiner, Art Unit 2191
Prosecution Insights