Prosecution Insights
Last updated: August 16, 2026
Application No. 18/744,557

UPGRADE METHOD BASED ON OVER-THE-AIR OTA TECHNOLOGY AND COMMUNICATION APPARATUS

Non-Final OA §101§102§103
Filed
Jun 14, 2024
Priority
Dec 17, 2021 — continuation of PCTCN2021139204
Examiner
SLACHTA, DOUGLAS M
Art Unit
2193
Tech Center
2100 — Computer Architecture & Software
Assignee
Shenzhen Yinwang Intelligent Technology Co., Ltd.
OA Round
1 (Non-Final)
83%
Grant Probability
Favorable
1-2
OA Rounds
1m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 83% — above average
83%
Career Allowance Rate
290 granted / 351 resolved
+27.6% vs TC avg
Strong +18% interview lift
Without
With
+18.1%
Interview Lift
resolved cases with interview
Typical timeline
2y 3m
Avg Prosecution
14 currently pending
Career history
370
Total Applications
across all art units

Statute-Specific Performance

§101
20.8%
-19.2% vs TC avg
§103
48.5%
+8.5% vs TC avg
§102
8.1%
-31.9% vs TC avg
§112
16.0%
-24.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 351 resolved cases

Office Action

§101 §102 §103
Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . DETAILED ACTION This office action is in response to communication filed 8/21/2024. Claims 1-4, 8-12, 14-17, 21-25 and claims 5-7, 13, 18-20, and 26 are cancelled. Claims 1, 10, 14, 23 are the independent claims. Claim Objections Claims 1, 14 are objected to because of the following informalities: As per claims 1 and 14 they recite “…wherein the first upgrade task information comprises an upgrade package,.” and as such ends with a comma followed by a period (“,.”) when, for grammar it should recite “…upgrade package.” so that it just ends with a period (“.”) Appropriate correction is required. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. As per independent claim 10, it recites “An upgrade method based on an over-the-air OTA technology, comprising: sending, by a first device, vehicle identifiers of at least two vehicles to an OTA cloud, wherein the first device is configured to manage the at least two vehicles; receiving, by the first device, a first request message from the OTA cloud, wherein the first request message comprises a vehicle identifier of a target vehicle of the at least two vehicles; determining, by the first device, whether to upgrade the target vehicle; and sending, by the first device, a first request message indicating to upgrade the target vehicle.” The imitation “determining, by the first device, whether to upgrade the target vehicle”, as drafted, recites a function that, under its broadest reasonable interpretation, covers a function that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components. That is, the limitation “determining, by the first device, whether to upgrade the target vehicle” as drafted, is a function that, under its broadest reasonable interpretation, recite the abstract idea of a mental process. The limitation encompasses a human mind carrying out the function through observation, evaluation judgment and /or opinion, or even with the aid of pen and paper. For example, a human may mentally/with pen and paper/etc. determine/judge/decide/etc. whether to upgrade the target vehicle/whether to perform an upgrade/etc.. Thus, this limitation recites and falls within the “Mental Processes” grouping of abstract ideas This judicial exception is not integrated into a practical application. The claim recites the following additional elements “An upgrade method based on an over-the-air OTA technology, comprising”, “by a first device”, “sending, by a first device, vehicle identifiers of at least two vehicles to an OTA cloud, wherein the first device is configured to manage the at least two vehicles”, “receiving, by the first device, a first request message from the OTA cloud, wherein the first request message comprises a vehicle identifier of a target vehicle of the at least two vehicles”, and “sending, by the first device, a first request message indicating to upgrade the target vehicle.” The additional elements “An upgrade method based on an over-the-air OTA technology, comprising” and “by a/the first device” are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer and/or mere computer components/OTA technology/first device/etc. which does not integrate the abstract idea/mental process into a practical application. The additional elements “sending, by a first device, vehicle identifiers of at least two vehicles to an OTA cloud, wherein the first device is configured to manage the at least two vehicles”, “receiving, by the first device, a first request message from the OTA cloud, wherein the first request message comprises a vehicle identifier of a target vehicle of the at least two vehicles”, and “sending, by the first device, a first request message indicating to upgrade the target vehicle” do nothing more than add insignificant extra solution activities to the judicial exception of merely transmitting/sending/etc. data/information and gathering/receiving/etc. data/information, and the courts have identified functions such as gathering, displaying, updating, transmitting, and storing data as well-understood, routine, conventional activity (see MPEP 2106.05(d)). Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception. See MPEP 2106.05(f), 2106.05(g), etc.. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than mere instructions to apply the exception using generic computer and/or mere computer components, which does not amount to significantly more than the abstract idea/mental process/judicial exception, and insignificant extra solution activities to the judicial exception of merely transmitting data and gathering data, and the courts have identified functions such as gathering, displaying, updating, transmitting, and storing data as well-understood, routine, conventional activity, thus do not amount to significantly more than the judicial exception (see MPEP 2106.05(d)). Accordingly, the claims are not patent eligible under 35 USC 101. As per claim 11, it incorporates the deficiencies of claim 10, upon which it depends, and further recites “…wherein the first request message further comprises association information of an upgrade task, and the association information of the upgrade task comprises at least one of duration required for upgrade, an upgrade purpose, or a change brought by upgrade” which, conceptually, with broadest reasonable interpretation, recites further clarification as to the data/information being gathered/received in the insignificant extra solution activities, which does not integrate the abstract idea into a practical application and is not significantly more than the abstract idea/mental process, and the courts have identified functions such as gathering, displaying, updating, transmitting, and storing data as well-understood, routine, conventional activity, thus do not amount to significantly more than the judicial exception (see MPEP 2106.05(d)). As such, claim 11 fails to correct the deficiencies of claim 10 and therefore rejected for similar reasoning as claim 10, above. As per claim 12, it incorporates the deficiencies of claim 10, upon which it depends, and further recites “…receiving, by the first device, an upgrade result from the OTA cloud, wherein the upgrade result comprises an upgrade success, an upgrade failure, a rollback success, or a rollback failure” which, conceptually, with broadest reasonable interpretation, recites a further insignificant extra solution activity of gathering/receiving data/information/upgrade result/etc., which does not integrate the abstract idea into a practical application and the courts have identified functions such as gathering, displaying, updating, transmitting, and storing data as well-understood, routine, conventional activity, thus do not amount to significantly more than the judicial exception (see MPEP 2106.05(d)). As such, claim 12 fails to correct the deficiencies of claim 10 and therefore rejected for similar reasoning as claim 10, above. As per claim 23, it recites an upgrade apparatus having similar limitations as the upgrade method of claim 10, and as such recites similar abstract idea and has similar deficiencies as claim 10, above. Claim 23 recites the further additional elements “An upgrade apparatus, comprising: at least one processor; and one or more memories coupled to the at least one processor and storing programming instructions for execution by the at least one processor to cause the apparatus to”, which, with broadest reasonable interpretation, recites that high level/generic computer/computer components/at least one processor and one or more memories/etc. are used to implement/perform the abstract idea/mental process, and as such amounts to no more than mere instructions to apply the exception using generic computer and/or mere computer components, which does not integrate the abstract idea/mental process into a practical application and is not significantly more than the abstract idea/mental process. As such, the additional elements/limitations of claim 23 fail to correct the deficiencies of claim 10, and therefore claim 23 is rejected for similar reasoning as claim 10, above. As per claims 24 and 25, they recite apparatus’ having similar limitations as the methods of claims 11 and 12, respectively, and are therefore rejected for similar reasoning as claims 11 and 12, respectively, above. Claim Rejections - 35 USC § 102 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. Claims 1-4, 8-9, 14-17 and 21-22 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by David et al. (herein called David) (US PG Pub. 2020/0174778 A1) and As per claim 1, David anticipates: An upgrade method, comprising: receiving, by an over-the-air (OTA) cloud, vehicle identifiers of at least two vehicles from a first device, wherein the first device is configured to manage the at least two vehicles (fig. 4A items 402-406, pars. [0043]-[0044], [0065]-[0068], user selects particular vehicle from list of registered vehicles presented on mobile computing device for software update (first device/mobile device configured to manage/update/etc. the vehicles) and identifier of selected vehicle is transmitted to server computing system/OTA server (OTA cloud), vehicles are registered to user/mobile computing device/etc. by mobile device/first device providing vehicle identifier/VIN/etc. to server/OTA server/OTA cloud, etc. (OTA cloud/server/etc. receives vehicle identifiers from first device/mobile device that is configured to manage the vehicles), and as seen in fig. 4A multiple/three/at least two vehicles may be registered and considered for selection to be updated/managed/etc. and as such multiple/three/at least two vehicle identifiers have been received from the mobile device/first device to register the multiple/at least two vehicles and the mobile device/first devices manages the multiple/at least two vehicles (receiving vehicle identifiers of at least two vehicles from first device, wherein the first device is configured to manage the at least two vehicles).); receiving information from the first device, wherein the information indicates to send first upgrade task information to at least a target vehicle of the at least two vehicles (fig. 4A items 402-406, pars. [0038], [0040], [0043]-[0044], [0058]-[0059], vehicle identifier of vehicle selected for software upgrade (target vehicle) from vehicle list displayed on mobile computing device/first device is transmitted to server computing system/OTA server/interface element of mobile/firs device initiating software update of vehicle is selected and command is transmitted to server computing system/OTA server/etc. (receiving information from first device), as seen in fig. 4A there are multiple/at least two/etc. vehicles and the selected/target vehicle is of the multiple/at least two vehicles, and server computing system/OTA server/etc. transmits command/software update/etc. to vehicle/OTA updater device of vehicle/etc. to conduct software update process on vehicle/install software update/etc. (information indicates to send first upgrade task information to target vehicle of the at least two vehicles).); and sending the first upgrade task information to the target vehicle, wherein the first upgrade task information comprises an upgrade package, (pars. [0038], [0059], server computing system/OTA server/etc. provides software update (upgrade package) to OTA updater device of vehicle/etc./server sends command initiating software update (upgrade package) process to vehicle/etc., and software update/upgrade package is installed/upgrade is conducted/etc. at vehicle (send first upgrade task information comprising upgrade package to target vehicle/vehicle being updated/etc.).). As per claim 2, David further anticipates: sending a first request message to the first device, wherein the first request message comprises a vehicle identifier of the first target vehicle (pars. [0042]-[0043], list of registered vehicles includes vehicles identifiers/VIN numbers/etc. and status information of vehicles such as software updates available for each vehicle and is transmitted to mobile computing device for display and user selection of vehicle to perform software update (send first request message/list of vehicles and software update status of vehicles/etc. to first device/mobile device, first request message comprises vehicle identifier/VIN number/etc. of the first target vehicle/vehicle selected).); and wherein the information is comprised in a first response message from the first device (fig. 4A items 402-406, pars. [0038], [0040], [0043]-[0044], [0058]-[0059], vehicle identifier of vehicle selected for software upgrade from vehicle list displayed on mobile computing device/first device is transmitted to server computing system/OTA server/interface element of mobile/first device initiating software update of vehicle is selected and command is transmitted to server computing system/OTA server/etc. As the vehicle identifier of vehicle selected for upgrade/initiating software update of vehicle/etc. (information) is transmitted in response to the list of vehicles being displayed on mobile device for selection of vehicle to update/initiate software update/etc., the information is in a first response message from the first/mobile device.). As per claim 3, David further anticipates: wherein the first request message further comprises association information of an upgrade task, and the association information of the upgrade task comprises at least one of duration required for upgrade, an upgrade purpose, or a change brought by upgrade (pars. [0042], [0044], [0068], list of registered vehicles transmitted to mobile/first device for selection of vehicle to upgrade (first request message) includes status information of each vehicle that includes whether each vehicle has software update available/awaiting installation/etc. (includes information of upgrade task comprising change brought by an upgrade/information of software update to be installed/etc.).). As per claim 4, David further anticipates: wherein the first upgrade task information further comprises an upgrade type, and the upgrade type is confirmed upgrade (fig. 4A items 402-406, pars. [0038], [0040], [0043]-[0044], [0058]-[0059], user selects vehicle/target vehicle for software upgrade (user confirmed upgrade), vehicle identifier of vehicle selected for software upgrade from vehicle list displayed on mobile computing device/first device is transmitted to server computing system/OTA server/interface element of mobile/firs device initiating software update of vehicle is selected and command is transmitted to server computing system/OTA server/etc., and server computing system/OTA server/etc. transmits command/software update/etc. to vehicle/OTA updater device of vehicle/etc. to conduct software update process on vehicle/install software update/etc. (send first upgrade task information to target vehicle of the at least two vehicles), as a user confirms/selects the vehicle for the software update the first upgrade task information/software update/command to conduct update process/etc. sent to the vehicle is/comprises/etc. an upgrade type of confirmed/user selected/etc. upgrade.). As per claim 8, David further anticipates: receiving an upgrade result from the target vehicle, wherein the upgrade result comprises an upgrade success, an upgrade failure, a rollback success, or a rollback failure (pars. [0060]-[0062], result of software update is received from vehicle and determination is made as to whether software update was successful, and result of software update including success of the software update or failure of the software update is transmitted to mobile/first device (receive upgrade result comprising upgrade success or update failure from target vehicle).). As per claim 9, David further anticipates: wherein the method comprises: sending the upgrade result to the first device (pars. [0060], software update result/upgrade result is transmitted/sent to mobile computing device/first device.). As per claims 14-17 and 21-22, they recite apparatus’ having similar limitations as the methods of claims 1-4 and 8-9, respectively, and are therefore rejected for similar reasoning as claims 1-4 and 8-9, respectively, above. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 10-12 and 23-25 are rejected under 35 U.S.C. 103 as being unpatentable over David et al. (herein called David) (US PG Pub. 2020/0174778 A1) in further view of Schwarz et al. (herein called Schwarz) (US PG Pub. 2016/0373913 A1). As per claim 10, David teaches: sending, by a first device, vehicle identifiers of at least two vehicles to an OTA cloud, wherein the first device is configured to manage the at least two vehicles (fig. 4A items 402-406, pars. [0043]-[0044], [0065]-[0068], user selects particular vehicle from list of registered vehicles presented on mobile computing device for software update (first device/mobile device configured to manage/update/etc. the vehicles) and identifier of selected vehicle is transmitted to server computing system/OTA server (OTA cloud), vehicles are registered to user/mobile computing device/etc. by mobile device/first device providing vehicle identifier/VIN/etc. to server/OTA server/OTA cloud, etc. (first device/mobile device managing vehicles sends/provides vehicle identifiers to OTA cloud/server/etc.), and as seen in fig. 4A multiple/three/at least two vehicles may be registered and considered for selection to be updated/managed/etc. and as such multiple/three/at least two vehicle identifiers have been sent by the mobile device/first device to register the multiple/at least two vehicles and the mobile device/first devices manages the multiple/at least two vehicles (first/mobile device sends vehicle identifiers of at least two vehicles, wherein the first device is configured to manage the at least two vehicles).); receiving, by the first device, a first request message from the OTA cloud, wherein the first request message comprises a vehicle identifier of a target vehicle of the at least two vehicles (fig. 4A and pars. [0042]-[0043], list of registered vehicles includes vehicles identifiers/VIN numbers/etc. and status information of vehicles such as software updates available for each vehicle, and list is transmitted to mobile computing device for display and user selection of vehicle to perform software update (first request message/list of vehicles and software update status of vehicles for selection/etc. is received by first device/mobile device, and first request message comprises vehicle identifier/VIN number/etc. of the first target vehicle/vehicle selected).); determining whether to upgrade the target vehicle (pars. [0043]-[0044], [0047], [0058]-[0059], user selects vehicle from list of vehicles displayed on mobile/first device to perform software upgrade/actuates interface element on mobile device to initiate software update on vehicle/etc. (user determines/selects/etc. to upgrade the target vehicle/software on target vehicle/etc.).); and sending, by the first device, a first request message indicating to upgrade the target vehicle (pars. [0043]-[0044], [0058]-[0059], vehicle identifier of vehicle selected/target vehicle for software upgrade from vehicle list displayed on mobile computing device/first device is transmitted to server computing system/OTA server from mobile device to begin software upgrade on selected/target vehicle/interface element of mobile/first device initiating software update of vehicle is actuated and command is transmitted to server computing system/OTA server/etc. to initiate software upgrade on selected/target vehicle (mobile device/first device sends/transmits first request message indicating to upgrade the target vehicle).). While David teaches determining to whether to upgrade the target vehicle, it does not explicitly disclose that the first/mobile device may do the determining, and as such does not explicitly state, however Schwarz teaches: determining, by the first device, whether to upgrade the target vehicle (pars. [0051], device (first device) selects (determines) appropriate updates needed by the different vehicles (determines whether to upgrade/appropriate updates needed by/etc. the vehicles/target vehicles/vehicles to update/vehicle selected for software update from David/etc.).). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add determining, by the first device, whether to upgrade the target vehicle, as conceptually taught by Schwarz, into that of David because these modifications allow for the device/first device/etc. to determine updates to be performed for the vehicle, which is desirable as it allows for updates to be performed without requiring a user to make the determination which saves time a user would spend having to manually make the determination/select updates/etc. and helps keep the vehicles up to date by allowing for them to be updated automatically/without user input thereby avoiding delays in updating the vehicles caused by a user delaying a selection/determination of updates to be performed, thereby helping to ensure that the vehicle is up to date and operates correctly. As per claim 11, it recites an apparatus’ having similar limitations as the method of claim 3, and is therefore rejected for similar reasoning as claim 3, above. As per claim 12, David further teaches: receiving, by the first device, an upgrade result from the OTA cloud, wherein the upgrade result comprises an upgrade success, an upgrade failure, a rollback success, or a rollback failure (fig. 2A items 102, 104, 210, pars. [0060], communication relay module 210 of server computing system 104/OTA server (OTA cloud) transmits the result of the software update/upgrade result indicating success or failure of software update (upgrade result comprising upgrade success or upgrade failure) to mobile computing device 102/first device (first device receives upgrade result comprising upgrade success or upgrade failure from OTA cloud). ). As per claims 23-25, they recite apparatus’ having similar limitations as the methods of claims 10-12, respectively, and are therefore rejected for similar reasoning as claims 10-12, respectively, above. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Vangelov et al. US PG Pub. 2016/0210131 A1 teaches that a mobile device may used to control/manage/etc. wireless/over the air/network/etc. updates of vehicles and that the updates may be downloaded from a server over the wireless network. Smereka et al. US PG Pub. 2016/0013934 A1 teaches that a nomadic/mobile device associated with vehicle may be used to communicate with an update server storing software updates and a vehicle management application on a vehicle via a wireless network, and may be used to facilitate/confirm/manage/etc. software updates of the vehicle. Any inquiry concerning this communication or earlier communications from the examiner should be directed to DOUGLAS M SLACHTA whose telephone number is (571)270-0653. The examiner can normally be reached Monday-Friday 6:30am-4pm. 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, Chat Do can be reached at 571-272-3721. 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. /DOUGLAS M SLACHTA/Examiner, Art Unit 2193
Read full office action

Prosecution Timeline

Jun 14, 2024
Application Filed
Aug 21, 2024
Response after Non-Final Action
Jul 15, 2026
Non-Final Rejection mailed — §101, §102, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12693853
METHOD, ELECTRONIC DEVICE, AND COMPUTER PROGRAM PRODUCT FOR SETTING FEATURE FLAGS
2y 9m to grant Granted Jul 28, 2026
Patent 12681844
SECURE AND SEAMLESS INJECTION OF SECRETS BASED ON EXECUTION DEBUGGING
2y 11m to grant Granted Jul 14, 2026
Patent 12681721
METHOD AND APPARATUS TO EXTEND IMMUTABLE DATA
2y 8m to grant Granted Jul 14, 2026
Patent 12681850
TRANSFORMING LEGACY UEFI FIRMWARE TO UNIVERSAL SCALABLE FIRMWARE
2y 3m to grant Granted Jul 14, 2026
Patent 12681712
Creation of a performance-optimized image of a server
1y 11m to grant Granted Jul 14, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
83%
Grant Probability
99%
With Interview (+18.1%)
2y 3m (~1m remaining)
Median Time to Grant
Low
PTA Risk
Based on 351 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month