Prosecution Insights
Last updated: April 19, 2026
Application No. 18/407,262

SYSTEMS AND METHODS FOR INCENTIVIZED BEHAVIOR OF AUTONOMOUS VEHICLES

Final Rejection §103
Filed
Jan 08, 2024
Examiner
SIENKO, TANYA CHRISTINE
Art Unit
3664
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Torc Robotics, Inc.
OA Round
2 (Final)
86%
Grant Probability
Favorable
3-4
OA Rounds
2y 7m
To Grant
99%
With Interview

Examiner Intelligence

Grants 86% — above average
86%
Career Allow Rate
167 granted / 195 resolved
+33.6% vs TC avg
Strong +16% interview lift
Without
With
+15.7%
Interview Lift
resolved cases with interview
Typical timeline
2y 7m
Avg Prosecution
14 currently pending
Career history
209
Total Applications
across all art units

Statute-Specific Performance

§101
10.7%
-29.3% vs TC avg
§103
46.1%
+6.1% vs TC avg
§102
15.2%
-24.8% vs TC avg
§112
26.5%
-13.5% vs TC avg
Black line = Tech Center average estimate • Based on career data from 195 resolved cases

Office Action

§103
DETAILED ACTION 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 . Claims Claims 1-20 are pending in the application. Drawings The objection to Fig. 7 has been addressed and is removed. Specification The objection to the specification in paragraph [0054] has been addressed and is removed. Response to Arguments Applicant’s arguments, see pg. 9-10 of Remarks, filed 9/18/2025, with respect to the rejection(s) of claim(s) 1, 8, and 15 under §103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of US Pat. 9,832,241 (Hayward). 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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claims 1-3, 6-10, 13-17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0187691 Al (Magzimof et al., hence Magzimof) in light of US 9,832241 (Hayward) and in light of US 2019/0339699 (Iagnemma et al., Iagnemma) . As for claim 1, Magzimof teaches an autonomous vehicle, the autonomous vehicle comprising: (Magzimof: "Embodiments of the present disclosure provide methods for support of vehicles, and other systems, which may typically be autonomous in operation, but which on occasions require some form of assistance from an external resource." [0027]) an exterior surface displaying an indicium (Magzimof: "FIG. 4C shows an embodiment in which a QR code unit 422 is displayed to parties external to the vehicle 420 on a window, providing identifying information for the vehicle 120. The requesting party may then make a request to the remote support system 102 for remote support for the vehicle 120." [0070]); receive at least one request from the client device, the at least one request including a desired action of the autonomous vehicle (Magzimof: The request from the client is that support be provided to the autonomous vehicle from the remote support system. A "desired action" is whatever the remote support system decides to send to the autonomous vehicle to carry out, based on the vehicle circumstances ([0005], [0009])); initiate execution of the desired action. (Magzimof: "Furthermore, the remote support system may analyze the state of the vehicle to determine whether to activate an emergency stop system of the vehicle. Responsive to determining to activate the emergency stop, the remote support system may send an emergency stop signal to the vehicle." [0009]) Magzimof does not specifically teach an autonomy computing system included within the autonomous vehicle, the autonomy computing system comprising at least one processor and at least one memory storing computer executable [instructions], the computer executable instructions, upon execution by the processor, configuring the processor to: establish direct communication between a client device of a user and the autonomous vehicle. However, Hayward teaches an autonomy computing system included within the autonomous vehicle, (Hayward: under BRI the autonomy computing system can be computing device 300 containing communication unit 330. "In another aspect, computing device 300 may be implemented as an on-board vehicle computer (e.g., onboard vehicle computer 114, as shown in FIG. 1)." Col. 18, lines 48-50.) the autonomy computing system comprising at least one processor and at least one memory storing computer executable [instructions], (Hayward: mention of an on-board computer, where “computer” inherently contains processors, memory, and instructions in the form of software) the computer executable instructions, upon execution by the processor, configuring the processor to: establish direct communication between a client device of a user and the autonomous vehicle (Hayward: "To provide still another example, aspects include communication unit 330 being additionally or alternatively 10 configured to only broadcast telematics data when communication unit 330 is connected to and/or communicating with a device identified as a vehicle." Col.21 lines 9-13. Also note the direct communication paths as shown in Fig. 2.) Hayward does not specifically mention the use of an indicium to link to the communications channel, but this problem has been solved in Magzimof. Magzimof does not specifically teach at least one memory storing computer executable instructions defining an incentivized behavior module. However, a incentivized behavior module is taught by Hayward (Hayward: Col. 60 lines 39-55 discusses how the use of telematics data of the vehicle can be used to provide insurance discounts or rewards to a user.) It would have been obvious to one of ordinary skill in the art at the time of the application to add the system of intervehicle communication, as well as the incentivized behavior module, as described by Hayward, in the system of Magzimof. The motivation would be to include direct request channels from other vehicles and to incent the driver/driver module to carry out particular actions. Magzimof, as modified by Hayward, does not specifically teach communicat[ing] to the client device the autonomous vehicle will complete the desired action. However, such feedback is known in the art (see Fig. 9 of Iagnemma) and would be obvious to one of ordinary skill in the art. The motivation would be to provide a feedback signal to the client that a particular action request has been processed and will be acted upon. As for claim 2, Magzimof, as modified by Hayward and by Iagnemma, teaches wherein the user scans, with the client device, the indicium visible on the autonomous vehicle in order to establish communication. (Magzimof: "FIG. 4C shows an embodiment in which a QR code unit 422 is displayed to parties external to the vehicle 420 on a window, providing identifying information for the vehicle 120. The requesting party may then make a request to the remote support system 102 for remote support for the vehicle 120." [0070]) As for claim 3, Magzimof, as modified by Hayward and by Iagnemma, teaches wherein the vehicle broadcasts a network identifier of a wireless communication equipment installed on the autonomous vehicle in order to establish communication. (Magzimof: "In a zone where, for example an accident has occurred, autonomous vehicles may be required to revert to a remote support mode, or a partially assisted mode. Such a request may be transmitted to the vehicle wirelessly, by a suitable technology such as WiFi or Bluetooth."[0040]. Note: if the communication is using WiFi, then a Service Set Identifier is automatically included.) As for claim 6, Magzimof, as modified by Hayward and by Iagnemma, teaches wherein upon receiving the request from the client device, the processor determines if the request is permitted. (Magzimof: "In another embodiment, there may be certain types of restricted requests that may only be made by an authorized passenger. In such a situation, a process to authorize the requesting user may be made, for example, by use of biometric information. Some examples are by finger print, iris recognition, face recognition, voice recognition, or other types of sensors." [0037]) As for claim 7, Magzimof, as modified by Hayward and by Iagnemma, teaches wherein upon determining the request is permitted, initiating execution of the desired action. (Magzimof in [0037] and [0038] gives examples of actions which are carried out after the authorization of the individual to make such a request is confirmed. In [0037], an otherwise unscheduled stop of the vehicle is mentioned. In [0038]: “A type of request that may occur is by a police official who can direct the vehicle to move to a certain location not related to the vehicle destination. Another such type of request is by an official who may initiate a request for linkage of the vehicle into a convoy.") As for claim 8, Magzimof teaches a method of requesting an action of an autonomous vehicle, (Magzimof: "Embodiments of the present disclosure provide methods for support of vehicles, and other systems, which may typically be autonomous in operation, but which on occasions require some form of assistance from an external resource." [0027]) the method comprising: establishing [communication] between a client device of a user and the autonomous establishing communication between the client device and an autonomy computing [system]: (Magzimof: "FIG. 4C shows an embodiment in which a QR code unit 422 is displayed to parties external to the vehicle 420 on a window, providing identifying information for the vehicle 120. The requesting party may then make a request to the remote support system 102 for remote support for the vehicle 120." [0070]); implied by the existence of communication between the external party and remote support system [0030] using a QR code); receive at least one request from the client device, the at least one request including a desired action of the autonomous vehicle (Magzimof: The request from the client is that support be provided to the autonomous vehicle from the remote support system. A "desired action" is whatever the remote support system decides to send to the autonomous vehicle to carry out, based on the vehicle circumstances ([0005], [0009])); initiate execution of the desired action. (Magzimof: "Furthermore, the remote support system may analyze the state of the vehicle to determine whether to activate an emergency stop system of the vehicle. Responsive to determining to activate the emergency stop, the remote support system may send an emergency stop signal to the vehicle." [0009]) Magzimof does not specifically teach the method comprising: establishing direct communication between a client device of a user and an autonomy computing system included within the autonomous vehicle. However, Hayward teaches establishing direct communication between a client device of a user and an autonomy computing system included within the autonomous vehicle. (Under BRI the autonomy computing system can be computing device 300 containing communication unit 330. "In another aspect, computing device 300 may be implemented as an on-board computer (e.g., onboard vehicle computer 114, as shown in FIG. 1)." Col. 18, lines 48-50.). Also: ("To provide still another example, aspects include communication unit 330 being additionally or alternatively 10 configured to only broadcast telematics data when communication unit 330 is connected to and/or communicating with a device identified as a vehicle." Col.21 lines 9-13. Also note the direct communication paths as shown in Fig. 2.)) It would have been obvious to one of ordinary skill in the art at the time of the application to add the system of intervehicle communication of Hayward, in the system of Magzimof. The motivation would be to include direct request channels from other vehicles. Magzimof, does not specifically teach communicat[ing] to the client device the autonomous vehicle will complete the desired action. However, such feedback is known in the art (see Fig. 9 of Iagnemma) and would be obvious to one of ordinary skill in the art. The motivation would be to provide a feedback signal to the client that a particular action request has been processed and will be acted upon. As for claim 9, Magzimof, as modified by Hayward and by Iagnemma, teaches wherein the user scans, with the client device, an indicium visible on the autonomous vehicle. (Magzimof: "FIG. 4C shows an embodiment in which a QR code unit 422 is displayed to parties external to the vehicle 420 on a window, providing identifying information for the vehicle 120. The requesting party may then make a request to the remote support system 102 for remote support for the vehicle 120." [0070]) As for claim 10, Magzimof, as modified by Hayward and by Iagnemma, teaches wherein establishing communication includes broadcasting a network identifier of a wireless communication equipment installed on the autonomous vehicle. (Magzimof: "In a zone where, for example an accident has occurred, autonomous vehicles may be required to revert to a remote support mode, or a partially assisted mode. Such a request may be transmitted to the vehicle wirelessly, by a suitable technology such as WiFi or Bluetooth."[0040]. Note: if the communication is using WiFi, then a Service Set Identifier is automatically included.) As for claim 13, Magzimof, as modified by Hayward and by Iagnemma, teaches upon receiving the request from the client device, determining if the request is permitted. (Magzimof: "In another embodiment, there may be certain types of restricted requests that may only be made by an authorized passenger. In such a situation, a process to authorize the requesting user may be made, for example, by use of biometric information. Some examples are by finger print, iris recognition, face recognition, voice recognition, or other types of sensors." [0037]) As for claim 14, Magzimof, as modified by Hayward and by Iagnemma, teaches wherein upon determining the request is permitted, execution of the desired action is initiated. (Magzimof in [0037] and [0038] gives examples of actions which are carried out after the authorization of the individual to make such a request is confirmed. In [0037], an otherwise unscheduled stop of the vehicle is mentioned. In [0038]: “A type of request that may occur is by a police official who can direct the vehicle to move to a certain location not related to the vehicle destination. Another such type of request is by an official who may initiate a request for linkage of the vehicle into a convoy.") As for claim 15, Magzimof teaches an autonomy computing system comprising at least one processor and at least one memory storing computer executable [instructions] (Magzimof: memory and processor mentioned in [0084]; algorithms mentioned in [0081]; establishing communication between the client device (see comments) and "the autonomous vehicle" (under BRI "the autonomous vehicle" can include the remote support system (see Fig. 1)), the computer executable instructions, upon execution by the processor, configuring the processor to: establish [communication], between a client device of a user and the autonomy computing [system] (Magzimof: establishing communication between the client device and "the autonomous vehicle" (under BRI "the autonomous vehicle" can include the remote support system (see Fig. 1); implied by the existence of communication between the external party and remote support system [0030]); receive, at least one request from the client device, the at least one request including a desired action of the autonomy computing system; (Magzimof: The request from the client is that support be provided to the autonomous vehicle from the remote support system. A "desired action" is whatever the remote support system decides to send to the autonomous vehicle to carry out, based on the vehicle circumstances ([0005], [0009])); initiate execution of the desired action. (Magzimof: "Furthermore, the remote support system may analyze the state of the vehicle to determine whether to activate an emergency stop system of the vehicle. Responsive to determining to activate the emergency stop, the remote support system may send an emergency stop signal to the vehicle." [0009]) Magzimof does not specifically teach establish direct communication between a client device of a user and the autonomy computing system included within an autonomous vehicle. However, Hayward teaches establish direct communication between a client device of a user and the autonomy computing system included within an autonomous vehicle. (Hayward: Under BRI the autonomy computing system can be computing device 300 containing communication unit 330. "In another aspect, computing device 300 may be implemented as an on-board computer (e.g., onboard vehicle computer 114, as shown in FIG. 1)." Col. 18, lines 48-50.). Also: ("To provide still another example, aspects include communication unit 330 being additionally or alternatively 10 configured to only broadcast telematics data when communication unit 330 is connected to and/or communicating with a device identified as a vehicle." Col.21 lines 9-13. Also note the direct communication paths as shown in Fig. 2.)) Magzimof does not specifically teach at least one memory storing computer executable instructions defining an incentivized behavior module. However, a incentivized behavior module is taught by Hayward (Hayward: Col. 60 lines 39-55 discusses how the use of telematics data of the vehicle can be used to provide insurance discounts or rewards to a user.) It would have been obvious to one of ordinary skill in the art at the time of the application to include an incentivized behavior module, as described in Hayward, in the system of Magzimof. The motivation would be to incent the driver (or driver module) to carry out particular actions. Magzimof, as modified by Hayward, does not specifically teach communicat[ing] to the client device whether the autonomous vehicle will complete the desired action. However, such feedback is known in the art (see Fig. 9 of Iagnemma) and would be obvious to one of ordinary skill in the art. The motivation would be to provide a feedback signal to the client that a particular action request has been processed and will be acted upon. As for claim 16, Magzimof, as modified by Hayward and by Iagnemma, teaches wherein the user scans, with the client device, the indicium visible on the autonomous vehicle in order to establish communication. (Magzimof: "FIG. 4C shows an embodiment in which a QR code unit 422 is displayed to parties external to the vehicle 420 on a window, providing identifying information for the vehicle 120. The requesting party may then make a request to the remote support system 102 for remote support for the vehicle 120." [0070]) As for claim 17, Magzimof, as modified by Hayward and by Iagnemma, teaches wherein the vehicle broadcasts a network identifier of a wireless communication equipment installed on the autonomous vehicle in order to establish communication. (Magzimof: "In a zone where, for example an accident has occurred, autonomous vehicles may be required to revert to a remote support mode, or a partially assisted mode. Such a request may be transmitted to the vehicle wirelessly, by a suitable technology such as WiFi or Bluetooth."[0040]. Note: if the communication is using WiFi, then a Service Set Identifier is automatically included.) As for claim 20, Magzimof, as modified by Hayward and by Iagnemma, teaches upon receiving the request from the client device, the processor determines if the request is permitted (Magzimof: "In another embodiment, there may be certain types of restricted requests that may only be made by an authorized passenger. In such a situation, a process to authorize the requesting user may be made, for example, by use of biometric information. Some examples are by finger print, iris recognition, face recognition, voice recognition, or other types of sensors." [0037]) and, upon determining the request is permitted, initiating execution of the desired action. (Magzimof in [0037] and [0038] gives examples of actions which are carried out after the authorization of the individual to make such a request is confirmed. In [0037], an otherwise unscheduled stop of the vehicle is mentioned. In [0038]: “A type of request that may occur is by a police official who can direct the vehicle to move to a certain location not related to the vehicle destination. Another such type of request is by an official who may initiate a request for linkage of the vehicle into a convoy.") Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Magzimof, in light of Hayward and in light of Iagnemma as applied to claim 1 above, and further in view of “Wikipedia: General Data Protection Regulation” (attached as NPL-GDPR.pdf, hence “Wikipedia”. As for claim 4, Magzimof, as modified by Hayward and by Iagnemma, teaches wherein the processor presents a list of options to present on the client device, the list including available options from which the user may request. (Magzimof: "In another embodiment, there may be certain types of restricted requests that may only be made by an authorized passenger. In such a situation, a process to authorize the requesting user may be made, for example, by use of biometric information. Some examples are by finger print, iris recognition, face recognition, voice recognition, or other types of sensors." [0037]) Magzimof does not specifically teach that these are options that are chosen among, but in countries such as the EU, the implementation of a vehicle being able to use one or more from the list above as biometric data requires, under the General Data Protection Regulation, explicit consent from individuals (See the explanation of Section 6 in Wikipedia), thus satisfying the elements of the claim. It would have been obvious to one of ordinary skill in the art at the time of the application to implement a choice of biometric information under the requirements of GDPR when authorizing the ability to make a request in the system of Magzimof. The motivation would be to provide a reasonable balance between demand for information and privacy. Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Magzimof, in light of Hayward and in light of Iagnemma as applied to claim 1 above, and further in view of “Micropayments for Trusted Vehicular Services using MOTIVE”, attached as NPL-Ramachandran.pdf, henceforth “Ramachandran”. As for claim 5, Magzimof, as modified by Hayward and by Iagnemma, does not specifically teach wherein, in response to receiving the request from the client device, the processor requests payment credentials from the user. However, requesting and receiving payment credentials from a user of a vehicle is known in the art (see in Ramachandran Section 2 “Motive Architecture”, where the attaching of a digital wallet is mentioned to handle payments for services provided or consumed) and would be obvious to one of ordinary skill in the art. The motive for such, as Ramachandran points out in section 1, is to create a trust mechanism for users/providers of a service. Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Magzimof, in light of Hayward and in light of Iagnemma as applied to claim 8 above, and further in view of Wikipedia. As for claim 11, Magzimof, as modified by Hayward and by Iagnemma, teaches presenting a list of options on a user interface on the client device, the list including available options from which the user may request. (Magzimof: "In another embodiment, there may be certain types of restricted requests that may only be made by an authorized passenger. In such a situation, a process to authorize the requesting user may be made, for example, by use of biometric information. Some examples are by finger print, iris recognition, face recognition, voice recognition, or other types of sensors." [0037]) Magzimof does not specifically teach that these are options that are chosen among, but in countries such as the EU, the implementation of a vehicle being able to use one or more from the list above as biometric data requires, under the General Data Protection Regulation, explicit consent from individuals (See the explanation of Section 6 in Wikipedia), thus satisfying the elements of the claim. It would have been obvious to one of ordinary skill in the art at the time of the application to implement a choice of biometric information under the requirements of GDPR when authorizing the ability to make a request in the system of Magzimof. The motivation would be to provide a reasonable balance between demand for information and privacy. Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Magzimof, in light of Hayward, in light of Iagnemma as applied to claim 8 above, and further in view of Ramachandran. As for claim 12, Magzimof, as modified by Hayward and by Iagnemma, does not specifically teach wherein, in response to receiving the request from the client device, requesting payment credentials from the user. However, requesting and receiving payment credentials from a user of a vehicle is known in the art (see in Ramachandran Section 2 “Motive Architecture”, where the attaching of a digital wallet is mentioned to handle payments for services provided or consumed) and would be obvious to one of ordinary skill in the art. The motive for such, as Ramachandran points out in section 1, is to create a trust mechanism for users/providers of a service. Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Magzimof, in light of Hayward and in light of Iagnemma as applied to claim 15 above, and further in view of Wikipedia. As for claim 18, Magzimof, as modified by Hayward and by Iagnemma, teaches wherein the processor presents a list of options to present on the client device, the list including available options from which the user may request. (Magzimof: "In another embodiment, there may be certain types of restricted requests that may only be made by an authorized passenger. In such a situation, a process to authorize the requesting user may be made, for example, by use of biometric information. Some examples are by finger print, iris recognition, face recognition, voice recognition, or other types of sensors." [0037]) Magzimof does not specifically teach that these are options that are chosen among, but in countries such as the EU, the implementation of a vehicle being able to use one or more from the list above as biometric data requires, under the General Data Protection Regulation, explicit consent from individuals (See the explanation of Section 6 in Wikipedia), thus satisfying the elements of the claim. It would have been obvious to one of ordinary skill in the art at the time of the application to implement a choice of biometric information under the requirements of GDPR when authorizing the ability to make a request in the system of Magzimof. The motivation would be to provide a reasonable balance between demand for information and privacy. Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Magzimof, in light of Hayward and in light of Iagnemma as applied to claim 15 above, and further in view of Ramachandran. As for claim 19, Magzimof, as modified by Hayward and by Iagnemma, does not specifically teach wherein, in response to receiving the request from the client device, the processor requests payment credentials from the user. However, requesting and receiving payment credentials from a user of a vehicle is known in the art (see in Ramachandran Section 2 “Motive Architecture”, where the attaching of a digital wallet is mentioned to handle payments for services provided or consumed) and would be obvious to one of ordinary skill in the art. The motive for such, as Ramachandran points out in section 1, is to create a trust mechanism for users/providers of a service. Conclusion Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to TANYA CHRISTINE SIENKO whose telephone number is (571)272-5816. The examiner can normally be reached Mon - Fri 8:00-5:00. 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, Kito Robinson can be reached at 571-270-3912. 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. /TANYA C SIENKO/Examiner, Art Unit 3664 /KITO R ROBINSON/Supervisory Patent Examiner, Art Unit 3664
Read full office action

Prosecution Timeline

Jan 08, 2024
Application Filed
Jul 02, 2025
Non-Final Rejection — §103
Aug 29, 2025
Interview Requested
Sep 04, 2025
Applicant Interview (Telephonic)
Sep 04, 2025
Examiner Interview Summary
Sep 18, 2025
Response Filed
Oct 14, 2025
Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12594946
DRIVER ASSISTANCE APPARATUS AND DRIVER ASSISTANCE METHOD
2y 5m to grant Granted Apr 07, 2026
Patent 12576820
VEHICLE
2y 5m to grant Granted Mar 17, 2026
Patent 12552289
SYSTEMS AND METHODS FOR PRE-CONDITIONING A VEHICLE
2y 5m to grant Granted Feb 17, 2026
Patent 12539853
VEHICLE CONTROL DEVICE, VEHICLE CONTROL METHOD, AND STORAGE MEDIUM
2y 5m to grant Granted Feb 03, 2026
Patent 12528506
TELEOPERATION OF A VEHICLE
2y 5m to grant Granted Jan 20, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
86%
Grant Probability
99%
With Interview (+15.7%)
2y 7m
Median Time to Grant
Moderate
PTA Risk
Based on 195 resolved cases by this examiner. Grant probability derived from career allow 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