DETAILED ACTION
This office action is in response to the amendment filed June 30, 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 June 30, 2026 have been fully considered and are persuasive, but moot in view of the new grounds of rejection applied herein.
Double Patenting
The non-statutory 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 non-statutory 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 non-statutory 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 non-statutory 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 “Choi” (US PG Pub 2016/0147525) in view of “Song” (US PG Pub 2016/0246297) and “Smereka” (US PG Pub 2016/0013934)
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 “Choi” (US PG Pub 2016/0147525) in view of “Song” (US PG Pub 2016/0246297) and “Smereka” (US PG Pub 2016/0013934) 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 Choi teaches:
1. (currently amended) A method comprising: receiving, by a first device, a software update download for updating software of the first device; (Choi s190, fig. 3, ¶51 describes downloading an update from server 300 to vehicle telematic terminal 200)
and in response to the command, initiating, by the first device, an installation process to install the software update download. (choi s360, ¶¶55-56 teaches updating at vehicle in response to the command including installation of previously downloaded update) 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 Choi as each is directed to vehicle software update processes and Choi recognized the need for networked updates The patented claims further does not teach, Choi recognized the utility of (e.g. ¶6) and updating using remote update techniques.
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; (smerkea ¶49 see also fig. 3 teaches a method where vehicle sends a message, including device information, to update server 210 to associate the vehicle with the nomadic device, e.g. via association of VINS and mobile device numbers)
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 Choi and Smerkea as each is directed to vehicle software update processes and Smerkea’s system improves update security in that “vehicle may receive the encrypted update, and decrypt the update according to the first factor known to the vehicle. Then, to complete the decryption of the update file, the vehicle may request the second factor from the update server.” (¶20)
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)
sending, by the first device to the second device via the intermediary component, an informing message…
(Choi e.g. ¶49 describes the vehicle sending a message s130 indication that the condition of remote service execution state of the vehicle is met, including e.g. ignition off/stand by state as in ¶22)the informing message enabling a user interface at the second device for allowing the software update; (choi ¶¶52-54 teaches relaying a download complete message, after a previous infoming message of s130 described in ¶49 from vehicle to server. The server in turn causes a message to the mobile terminal, the mobile terminal to check if update should procede with user. ) [here, checking update progress with user inherently enables a user interface to communicate and receive some user input at the mobile terminal in Choi. Further both the state message and the download complete message are prerequisite to checking whether to proceed message to the mobile terminal]
when user input is applied to the user interface, receiving, by the first device from the second device via the intermediary component, a command to install the software update download; ((choi ¶¶53-54 the mobile terminal to check if update should proceed with user and receiving indication to proceed from user, which kicks of message to update S330 from mobile to server, and subsequent message s340 from server to vehicle. ) [here, checking update progress with user inherently enables a user interface to communicate and receive some user input at the mobile terminal in Choi]
Choi does not teach, but Song teaches:
the first device being affixed to or part of an unmanned vehicle; ( Song See Mobile 14, Control System 10, and UAV 16 in FIG. 1; See further 10, fig. 2 including app store 38, ¶¶6-8 describe a system for downloading specific applications from cloud control system 10 to UAV 16 based on direction from associated device 14, see further process of Fig. 4)
the intermediary component and the second device being not affixed to or part of the unmanned vehicle; ( Song See Mobile 14, Control System 10, and UAV 16 in FIG. 1, connected only by wireless network 12 )
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 Choi and Song as each is directed to vehicle software update processes and Song’s system “supporting a number of applications that may be downloaded to a UAV on an as-needed basis, thus creating an intelligent UAV.” (¶6).
Choi does not teach, but Smerkea 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; (smerkea ¶49 see also fig. 3 teaches a method where vehicle sends a message, including device information, to update server 210 to associate the vehicle with the nomadic device, e.g. via association of VINS and mobile device numbers)
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 Choi and Smerkea as each is directed to vehicle software update processes and Smerkea’s system improves update security in that “vehicle may receive the encrypted update, and decrypt the update according to the first factor known to the vehicle. Then, to complete the decryption of the update file, the vehicle may request the second factor from the update server.” (¶20)
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, 7, 9,11, 12, 15, 17, 18, 19, 21 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over “Choi” (US PG Pub 2016/0147525) in view of “Song” (US PG Pub 2016/0246297) and “Smereka” (US PG Pub 2016/0013934)
Regarding Claim 1, Choi teaches:
1. (Currently Amended) A method comprising: receiving, by a first device, a software update download for updating software of the first device, (Choi s190, fig. 3, ¶51 describes downloading an update from server 300 to vehicle telematic terminal 200)
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 of the vehicle sending a download complete message to the server 300, which relays the download completion information to the mobile device in ¶52)
sending, by the first device to the second device via the intermediary component, an informing message including information indicating that conditions for installing the software update download have been met, (Choi e.g. ¶49 describes the vehicle sending a message s130 indication that the condition of remote service execution state of the vehicle is met, including e.g. ignition off/stand by state as in ¶22)
the informing message enabling a user interface at the second device for allowing the software update; (choi ¶¶52-54 teaches relaying a download complete message, after a previous infoming message of s130 described in ¶49 from vehicle to server. The server in turn causes a message to the mobile terminal, the mobile terminal to check if update should procede with user. ) [here, checking update progress with user inherently enables a user interface to communicate and receive some user input at the mobile terminal in Choi. Further both the state message and the download complete message are prerequisite to checking whether to proceed message to the mobile terminal]
when user input is applied to the user interface, receiving, by the first device from the second device via the intermediary component, a command to install the software update download; ((choi ¶¶53-54 the mobile terminal to check if update should proceed with user and receiving indication to proceed from user, which kicks of message to update S330 from mobile to server, and subsequent message s340 from server to vehicle. ) [here, checking update progress with user inherently enables a user interface to communicate and receive some user input at the mobile terminal in Choi]
and in response to the command, initiating, by the first device, an installation process to install the software update download. (choi s360, ¶¶55-56 teaches updating at vehicle in response to the command including installation of previously downloaded update)
Choi does not teach, but Song teaches:
the first device being affixed to or part of an unmanned vehicle; ( Song See Mobile 14, Control System 10, and UAV 16 in FIG. 1; See further 10, fig. 2 including app store 38, ¶¶6-8 describe a system for downloading specific applications from cloud control system 10 to UAV 16 based on direction from associated device 14, see further process of Fig. 4)
the intermediary component and the second device being not affixed to or part of the unmanned vehicle; ( Song See Mobile 14, Control System 10, and UAV 16 in FIG. 1, connected only by wireless network 12 )
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 Choi and Song as each is directed to vehicle software update processes and Song’s system “supporting a number of applications that may be downloaded to a UAV on an as-needed basis, thus creating an intelligent UAV.” (¶6).
Choi does not teach, but Smerkea 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; (smerkea ¶49 see also fig. 3 teaches a method where vehicle sends a message, including device information, to update server 210 to associate the vehicle with the nomadic device, e.g. via association of VINS and mobile device numbers)
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 Choi and Smerkea as each is directed to vehicle software update processes and Smerkea’s system improves update security in that “vehicle may receive the encrypted update, and decrypt the update according to the first factor known to the vehicle. Then, to complete the decryption of the update file, the vehicle may request the second factor from the update server.” (¶20)
Regarding Claim 3, Choi does not teach, but Smereka 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. (Smereka ¶40 describes associating the VIN with a current release version of the software/hardward components)
Regarding Claim 4, Choi teaches:
4. (Previously presented) 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)
Regarding Claim 7, Choi teaches:
7. (Previously presented) 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)
Regarding Claim 9, Choi teaches:
9. (Currently Amended) A…the computing device comprising:
a processor; (Choi 200, Fig. 2, ¶20, ¶58, teaches a telematics terminal of a vehicle device, implemented including a processor)
and a communications subsystem, ((Choi 200, Fig. 2, ¶20, telematics terminal for communication e.g. with telematics server )
receive a software update download for updating software of the computing device; (Choi s190, fig. 3, ¶51 describes downloading an update from server 300 to vehicle telematic terminal 200)
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 of the vehicle sending a download complete message to the server 300, which relays the download completion information to the mobile device in ¶52)
send, to the second device via the intermediary component, an informing message including information indicating that conditions for installing the software update download have been met, (Choi e.g. ¶49 describes the vehicle sending a message s130 indication that the condition of remote service execution state of the vehicle is met, including e.g. ignition off/stand by state as in ¶22, in addition to the download complete message of ¶52 described above)
the informing message enabling a user interface at the second device for allowing the software update; (Choi ¶¶52-54 teaches relaying a download complete message, after a previous infoming message of s130 described in ¶49 from vehicle to server. The server in turn causes a message to the mobile terminal, the mobile terminal to check if update should procede with user. ) [here, checking update progress with user inherently enables a user interface to communicate and receive some user input at the mobile terminal in Choi. Further both the state message and the download complete message are prerequisite to checking whether to proceed message to the mobile terminal]
when user input is applied to the user interface, receive, from the second device via the intermediary component, a command to install the software update download; (choi ¶¶53-54 the mobile terminal to check if update should proceed with user and receiving indication to proceed from user, which kicks of message to update S330 from mobile to server, and subsequent message s340 from server to vehicle. ) [here, checking update progress with user inherently enables a user interface to communicate and receive some user input at the mobile terminal in Choi]
and in response to the command, initiate an installation process to install the software update download. (choi s360, ¶¶55-56 teaches updating at vehicle in response to the command including installation of previously downloaded update)
Choi does not teach, but Song teaches:
computing device of an unmanned vehicle… wherein the computing device of the unmanned vehicle is configured to: ( Song See Mobile 14, Control System 10, and UAV 16 in FIG. 1; See further 10, fig. 2 including app store 38, ¶¶6-8 describe a system for downloading specific applications from cloud control system 10 to UAV 16 based on direction from associated device 14, see further process of Fig. 4)
the intermediary component and the second device being not affixed to or part of the unmanned vehicle; ( ) ( Song See Mobile 14, Control System 10, and UAV 16 in FIG. 1, connected only by wireless network 12 ),
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 Choi and Song as each is directed to vehicle software update processes and Song’s system “supporting a number of applications that may be downloaded to a UAV on an as-needed basis, thus creating an intelligent UAV.” (¶6).
Choi does not teach, but Smerkea teaches:
send, to the intermediary component, a connect message including an identifier to establish a second communication between the computing device and the intermediary component; (smerkea ¶49 see also fig. 3 teaches a method where vehicle sends a message, including device information, to update server 210 to associate the vehicle with the nomadic device, e.g. via association of VINS and mobile device numbers)
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 Choi and Smerkea as each is directed to vehicle software update processes and Smerkea’s system improves update security in that “vehicle may receive the encrypted update, and decrypt the update according to the first factor known to the vehicle. Then, to complete the decryption of the update file, the vehicle may request the second factor from the update server.” (¶20)
Regarding Claim 25, Choi does not teach, but Song teaches:
25. (Previously presented) 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. ( Song See Mobile 14, Control System 10, and UAV 16 in FIG. 1; See further 10, fig. 2 including app store 38, ¶¶6-8 describe a system for downloading specific applications from cloud control system 10 to UAV 16 based on direction from associated device 14, see further process of Fig. 4)
Claims 11,12 and 15 are rejected on the same basis as claims 3,4 and 7 respectively above.
Claims 18, 19 and 21 are rejected on the same basis as claims 3, 7 and 4 respectively above.
Claim(s) 5, 13 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over “Choi” (US PG Pub 2016/0147525) in view of “Song” (US PG Pub 2016/0246297) and “Smereka” (US PG Pub 2016/0013934) as applied above, and further in view of “Searle” (us PG Pub 2018/0052681).
Regarding Claim 5, Choi does not teach but Searle teaches:
5. (Previously presented) 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 Choi et al with those of Searle as each is directed to update management systems and Searle 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).
Claims 13 and 22 are rejected on the basis of claim 5 above.
Claim(s) 6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over “Choi” (US PG Pub 2016/0147525) in view of “Song” (US PG Pub 2016/0246297) and “Smereka” (US PG Pub 2016/0013934) as applied above, and further in view of ‘Rockwell” (US PG Pub 2015/0339114)
Regarding Claim 6, Choi does not teach, but Rockwell teaches:
6. (Previously presented) 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)
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 Choi and Song as each is directed to vehicle software update processes and Rockwell teaches a “vehicle may be further configured to provide a vehicle human-machine interface (HMI) through which a user may select software update to be applied to the vehicle modules using the software update management module. In addition to software updates designed to provide for quality improvement, the software update management module may be further utilized to offer optional applications for download.” (¶160.
Claim 14 is rejected on the same basis as claim 6 above.
Claim(s) 23 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over “Choi” (US PG Pub 2016/0147525) in view of “Song” (US PG Pub 2016/0246297) and “Smereka” (US PG Pub 2016/0013934) as applied above, and further in view of ‘Pereira Cabral” (US PG Pub 2018/0052681)
Regarding Claims 23, Choi does not teach, but Pereira Cabral teaches:
23. (Previously presented) 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. Pereira Cabral 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 Choi 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 Claims 23, Choi does not teach, but Pereira Cabral teaches:
24. (Previously presented) 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. Pereira Cabral 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.
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.
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 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
9/24/2026
/MATTHEW J BROPHY/Primary Examiner, Art Unit 2191
