Prosecution Insights
Last updated: April 19, 2026
Application No. 19/225,892

SYSTEMS AND METHODS FOR PROCESSING DATA MESSAGES FROM A USER VEHICLE

Non-Final OA §102§103§DP
Filed
Jun 02, 2025
Examiner
ALI, JAHED
Art Unit
3699
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Mastercard International Incorporated
OA Round
1 (Non-Final)
60%
Grant Probability
Moderate
1-2
OA Rounds
3y 6m
To Grant
99%
With Interview

Examiner Intelligence

Grants 60% of resolved cases
60%
Career Allow Rate
85 granted / 141 resolved
+8.3% vs TC avg
Strong +60% interview lift
Without
With
+59.6%
Interview Lift
resolved cases with interview
Typical timeline
3y 6m
Avg Prosecution
29 currently pending
Career history
170
Total Applications
across all art units

Statute-Specific Performance

§101
30.2%
-9.8% vs TC avg
§103
37.1%
-2.9% vs TC avg
§102
5.0%
-35.0% vs TC avg
§112
20.1%
-19.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 141 resolved cases

Office Action

§102 §103 §DP
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 . Status of Claims This is a first office action on the merits, in response to the claims filed on September 25, 2025. Claims 1-20 have been canceled. Claims 21-40 have been examined. Information Disclosure Statement The information disclosure statement (IDS), submitted on 06/04/2025, is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Claim Objections Claims 21, 29 and 37 are objected to because of the following informalities. Claim 21 recites “receive an input biometric ID from a candidate user”; the claim further recites, “compare the encrypted biometric ID of the candidate user…” and “if the encrypted biometric ID of the candidate user matches”. The “input biometric ID” is not consistent throughout the claim language. Appropriate correction is required. Claim 26 objected to because the acronym GPS has not been defined. GPS must be defined as Global Positioning System (GPS), at least and initially, in Claim 26. Appropriate correction is required. Double Patenting The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969). A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13. The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer. Claims 21, 23, 27-29, 31, 35-38 and 40 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 5, 7, 9, 13, 15, 17 of Woods et al. (US 12321929 B2, hereinafter, “Patent Document”) in view of Ricci (US 20180013211 A1, “Ricci”). Regarding claims 21, 29 and 37: Although claims 21, 29 and 37 of this application and claim 1 of the Patent Document are not identical, the claimed subject matter of this application is not patently distinct from the Patent Document in view of Ricci. This Application Patent Document Claim 21, 29, and 37: A vehicle comprising a vehicle computing device and a vehicle memory, the vehicle computing device configured to: store, in the vehicle memory, a registration secure token including an account ID of a registered user, a vehicle ID unique to the vehicle, and an encrypted biometric ID of the registered user; transmit the registration secure token to a payment processor for processing payment transactions; establish a wireless communication link with a POS device of a merchant […]; receive an input biometric ID from a candidate user (e.g., second biometric input); compare the […] biometric ID of the candidate user to the stored […] biometric ID of the registered user; and if the […] biometric ID of the candidate user matches the stored […] biometric ID of the registered user, […]. Claims 1, 9 and 17: A computing system comprising: a vehicle computing device on-board a vehicle, the vehicle computing device comprising a vehicle computing memory and at least one vehicle computing processor communicatively coupled to the vehicle computing device; and generate a registration secure token by encrypting the vehicle identifier, an account identifier corresponding to the account, and a biometric identifier corresponding to the first biometric input, thereby improving security of sensitive data by masking the sensitive data; store the registration secure token in the vehicle computing memory; including transmitting the registration secure token to the payment processing computing system, wherein the payment processing computing system is configured to store the registration secure token to compare the stored registration secure token to one or more transaction secure tokens to process the electronic transactions; establish communication with at least one point-of-sale (POS) device using a wireless communication link; compare a second biometric input received via the biometric input device to the biometric identifier stored in the vehicle computing memory; compare a second biometric input received via the biometric input device to the biometric identifier stored in the vehicle computing memory; in response to matching the second biometric input to the biometric identifier, The Patent Document does not explicitly disclose, positioning the vehicle proximate to the POS device. However, Ricci, an analogous art of performing transaction using a vehicle computing device, discloses, establish a wireless communication link with a POS device of a merchant by positioning the vehicle proximate to the POS device (Ricci [0254]: A vehicle 100 may enter a location, in step 4608. For example, the vehicle 100 can enter a drive-through…The CPU 5608 may be provided signals from the RF devices 2004 to determine if an RF field is detected. In step 4616, the CPU 5608 can determine which of the RF devices 2004 has the best connection or the highest field strength. For example, if the user is at a gas station and device 2004b is nearest, to a gas pump with an RF transceiver, device 2004b may have the best connection, as the field strength there may be higher than at device 2004c or 2004a. If device 2004b has the best connection, then that device 2004b may couple with the RF transceiver at the third party; [0199]: the vehicle 100 and the second party 2804 can establish some communication connection through signal(s) 2808). The Patent Document does not explicitly disclose, encrypt the input biometric ID. However, Ricci discloses, encrypt the input biometric ID (Ricci [0239]: In steps 4408, 4424, the vehicle 100 can sense the presence of a driver or passenger, respectively. The internal sensors 5437 may sense the presence of a person within the vehicle 100. This person may be a driver or a passenger. The information gleaned from the sensors within the vehicle 100 may then be provided to the CPU 5608. In steps 4412, 4428, the CPU 5608 can receive the biometric information associated with the driver/passenger. This information may then be used to determine whether or not the passenger or driver is previously associated with the vehicle 100. The biometric information may be as stored in data structure 2404 in field 2408; [0181]: This encryption key 2428 can include some type of pretty good privacy (PGP) key or other types of encryption information used to encrypt the information in the data structure 2404 or other information described herein). The Patent Document does not explicitly disclose, compare the encrypted biometric ID, transmit the registration secure token to the POS device and the payment transaction is processed without the registered user directly interacting with the POS device. However, Ricci discloses: compare the encrypted biometric ID of the candidate user to the stored encrypted biometric ID of the registered user (Ricci [0240]: With the biometric information, the CPU 5608 can compare the received information with the information in field 2408 to determine if the driver or passenger is authenticated, in steps 4416, 4432; [0181]: This encryption key 2428 can include some type of pretty good privacy (PGP) key or other types of encryption information used to encrypt the information in the data structure 2404 or other information described herein); if the encrypted biometric ID of the candidate user matches the stored encrypted biometric ID of the registered user, transmit the registration secure token to the POS device using the wireless communication link to initiate payment transaction processing between the payment processor and the POS device (Ricci [0240]: If the received biometric information from internal sensors 5437 is the same or similar to stored biometric information 2408, the driver/passenger is authenticated…If the information does compare, then the driver/passenger is authenticated and the method 4400 proceeds “YES” to step 4448; [0241]: If the user finally is authenticated, then in step 4448, the vehicle processor 5608 can allow secure interactions between the vehicle 100 and third parties; [0200]: The vehicle 100 may then send a half-token or preauthorization for some type of good or service or other type of secure communication to the second party, in signal 2812; [0242]: Based on a driver's preferences (e.g., user goes to Starbucks every morning, etc.), the onboard computer automatically pre-authorizes a transaction at a particular time and/or in response to a particular detected location of the vehicle 100. This pre-authorization can be done by observation and based on historic user behavior or spatial proximity of the vehicle 100 to the vendor (e.g., range of a transceiver on the vehicle 100 to a transceiver at the vendor or GPS-based locations of the vehicle 100 and vendor), wherein the payment transaction is processed without the registered user directly interacting with the POS device (Ricci [0171]: The contactless payment application 2308 can conducts financial transactions using the vehicle. Contactless payment application 2308 may conduct the financial transactions with or without user input with third parties; [0191]: An embodiment of one or more routes taken by the user may be stored in route field 2612. These routes 2612 may be the consistent or common routes taken by the user and may also include information about what types of products or services may be offered along those routes. This information 2612 can allow the vehicle 100 to present options to the user or conduct automatic communications or transactions along such routes 2612; [0197]: In some configurations, the vehicle 100 may ask for a preauthorization or a half-token provided by the user, in signal 2732. Here, the vehicle 100 may present a user interface or an audio request to the user 220 requesting whether the user wishes to authorize certain automatic communications or automatic transactions before the drive begins. If the user does desire such type of automation, the user 220 may send an ack or acknowledge signal 2736 back to the vehicle 100). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Ricci in the Patent Document system. Moreover, in order to improve the payment transaction security and user experience of the Patent Document system, one of ordinary skill in the art would have been motivated to include encrypting additional data fields, such as encrypting input biometric ID, positioning the vehicle proximate to the POS device and payment transaction is processed without the registered user directly interacting with the POS device. Regarding dependent claims: Regarding claim 23: The Patent Document does not explicitly disclose, the biometric input device is associated with a user computer device wirelessly communicatively coupled to the vehicle computing device. However, Ricci, an analogous art of performing transaction using a vehicle computing device, discloses: The vehicle of Claim 22, wherein the biometric input device is associated with a user computer device wirelessly communicatively coupled to the vehicle computing device (Ricci [0180]: The mobile device information 2420 can include any information about one or more mobile devices or other types of devices that may be associated with the user and linked with the vehicle 100; [0326]: The associated device sensors 5423 can include any sensors that are associated with a device in the vehicle 100. As previously stated, typical devices may include smart phones, tablets, laptops, mobile computers, and the like. It is anticipated that the various sensors associated with these devices can be employed by the vehicle control system 5448. For example, a typical smart phone can include, an image sensor, an IR sensor, audio sensor, gyroscope, accelerometer, wireless network sensor, fingerprint reader, and more. It is an aspect of the present disclosure that one or more of these associated device sensors 5423 may be used by one or more subsystems of the vehicle 100). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Ricci in the Patent Document system. Moreover, in order to improve the transaction security of the Patent Document system, one of ordinary skill in the art would have been motivated to include additional input devices, such as biometric input device associated with a user computer device. Regarding claims 27 and 35: The Patent Document does not explicitly disclose, utilizing mileage reading from an odometer of the vehicle to perform a transaction. However, Ricci, an analogous art of performing transaction using a vehicle computing device, discloses: The vehicle of Claim 21, wherein the vehicle computing device is further configured to: capture a mileage reading from an odometer of the vehicle (Ricci [0299]: The odometry sensor and/or system 5416 may include one or more components that is configured to determine a change in position of the vehicle 100 over time; [0288]: a first event may be received, in step 5308. This event may be the user driving to a certain location, taking a route, or some other type of event that occurs that causes the vehicle 100 to decide to send a first portion of a secure communication to a third party, in step 5312. For example, the processor 5608 may provide a pre-order for some good or service typically purchased by the user at that time of day at that route); and Examiner’s Note: The Examiner considers, odometry sensor and/or system 5416 may include one or more components that is configured to determine a change in position of the vehicle 100 over time of Ricci to be the capture a mileage reading from an odometer of the claimed language. transmit the mileage reading to at least one of the payment processor and the POS device for comparison to a previous mileage reading (Ricci [0299]: In some embodiments, the odometry system 5416 may utilize data from one or more other sensors and/or systems 5404 in determining a position (e.g., distance, location, etc.) of the vehicle 100 relative to a previously measured position for the vehicle 100), wherein the payment transaction processing between the payment processor and the POS device is initiated when the mileage reading is greater than the previous mileage reading (Ricci [0288]: The second event may be the vehicle 100 driving to the physical location of the third party. As such, the second event may be the navigation system 302 identifying that the vehicle 100 is at the third party's location; [0289]: In step 5320, the processor 5608 can determine whether the user then authorizes the complete communication/transaction; [claim 25]: wherein the sensitive information comprises financial information of the user, wherein the common signal source is associated with a vendor, wherein the vendor is a drive through restaurant, wherein the first RF antenna communicates with a second RF antenna in physical proximity of a drive through window of the drive through restaurant, and wherein the processor authorizes the financial transaction in response to a plurality of a vehicle location, speed, proximity to a location, preference data and historical information associated with the user). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Ricci in the Patent Document system. Moreover, in order to improve the transaction security of the Patent Document system, one of ordinary skill in the art would have been motivated to include additional data attributes, such as mileage reading from an odometer of the vehicle to perform a transaction. Regarding claims 28, 36 and 40: Although claims 28, 36 and 40 of this application and claim 7 of the Patent Document is not identical, the claimed subject matter of this application is not patently distinct from the Patent Document in view of Ricci. Claim 28, 36 and 40: […] wherein the vehicle computing device is further configured to: retrieve, from a candidate user computer device wirelessly communicatively coupled to the vehicle computing device, a candidate device ID; compare (e.g., verify) the candidate device ID to the registered device ID; and when the candidate device ID matches the registered device ID, […]. Claims 7 and 15: The vehicle computing device according to claim 1, wherein the at least one vehicle computing processor is further programmed to: retrieve a device identifier of a user computing device connected to a wireless network of the vehicle; wherein the payment processing computing system is configured to verify the device identifier received from the at least one POS device against a stored device identifier registered by the user with the payment processing computing system. The Patent Document does not explicitly disclose, the registration secure token further includes a registered device ID of a user computer device of the registered user. However, Ricci, an analogous art of performing transaction using a vehicle computing device, discloses, the registration secure token further includes a registered device ID of a user computer device of the registered user (Ricci [0273]: the CPU may extract or create a half-token 2312 or information shown in data structure 2404; [0177]: The data structure 2404 can represent secure information associated with a user and/or the vehicle 100. This information data structure 2404 can have one or more data fields including, but not limited to: biometrics 2408, username 2412, password 2416, mobile device information 2420, dongle code 2424, encryption key 2428, credentials 2432, vehicle identification number (VIN) 2436, and electronic serial number (ESN) 2440, and/or an engine code 2444; [0180]: The mobile device information 2420 can include any information about one or more mobile devices or other types of devices that may be associated with the user and linked with the vehicle 100); (see paragraphs [0273], [0177] and [0219]). The Patent Document does not explicitly disclose, transmit the registration secure token to the POS device. However, Ricci, discloses, when the candidate device ID matches the registered device ID, transmit the registration secure token to the POS device (Ricci [0240]: As such, the CPU 5608 can determine if the driver/passenger is authenticated in steps 4420 or 4436. If the information does compare, then the driver/passenger is authenticated and the method 4400 proceeds “YES” to step 4448; [0241]: If the other information is valid and compares to the information stored in data structure 2404, the user may be authenticated again; [0219]: Also, having the mobile device information 3972, 3976 allows the vehicle 100 to conduct transactions through the mobile device rather than through the vehicle 100, if desired; [0200]: The vehicle 100 may then send a half-token or preauthorization for some type of good or service or other type of secure communication to the second party, in signal 2812). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Ricci in the Patent Document system. Moreover, in order to improve the transaction security of the Patent Document system, one of ordinary skill in the art would have been motivated to include additional data attributes, such as registered device ID of a user computer device and transmit the registration secure token to the POS device to perform a transaction. Regarding claim 31: The Patent Document does not explicitly disclose, the biometric input device is associated with a user computer device wirelessly communicatively coupled to the vehicle computing device. However, Ricci, an analogous art of performing transaction using a vehicle computing device, discloses: The method of Claim 30, wherein the receiving the input biometric ID from the candidate user from a biometric input device comprises receiving the input biometric ID from a biometric input device associated with a user computer device wirelessly communicatively coupled to the vehicle computing device (Ricci [0180]: The mobile device information 2420 can include any information about one or more mobile devices or other types of devices that may be associated with the user and linked with the vehicle 100; [0326]: The associated device sensors 5423 can include any sensors that are associated with a device in the vehicle 100. As previously stated, typical devices may include smart phones, tablets, laptops, mobile computers, and the like. It is anticipated that the various sensors associated with these devices can be employed by the vehicle control system 5448. For example, a typical smart phone can include, an image sensor, an IR sensor, audio sensor, gyroscope, accelerometer, wireless network sensor, fingerprint reader, and more. It is an aspect of the present disclosure that one or more of these associated device sensors 5423 may be used by one or more subsystems of the vehicle 100), (see paragraphs [0239] and [0314]). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Ricci in the Patent Document system. Moreover, in order to improve the transaction security of the Patent Document system, one of ordinary skill in the art would have been motivated to include additional input devices, such as biometric input device associated with a user computer device. Regarding claim 38: Although claim 38 of this application and claim 5 of the Patent Document is not identical, the claimed subject matter of this application is not patently distinct from the Patent Document in view of Ricci. This Application Patent Document Claim 38: The at least one non-transitory computer-readable storage medium of Claim 37, wherein the instructions are further executable to cause the at least one processor to receive the input biometric ID from the candidate user from a biometric input device […] Claims 5 and 13: The vehicle computing device according to claim 1, wherein the at least one vehicle computing processor is further programmed to: receive, via the biometric input device, the second biometric input; The Patent Document does not explicitly disclose, a biometric input device associated with a user computer device wirelessly communicatively coupled to the vehicle computing device. However, Ricci, an analogous art of performing transaction using a vehicle computing device, discloses: a biometric input device associated with a user computer device wirelessly communicatively coupled to the vehicle computing device (Ricci [0180]: The mobile device information 2420 can include any information about one or more mobile devices or other types of devices that may be associated with the user and linked with the vehicle 100; [0326]: The associated device sensors 5423 can include any sensors that are associated with a device in the vehicle 100. As previously stated, typical devices may include smart phones, tablets, laptops, mobile computers, and the like. It is anticipated that the various sensors associated with these devices can be employed by the vehicle control system 5448. For example, a typical smart phone can include, an image sensor, an IR sensor, audio sensor, gyroscope, accelerometer, wireless network sensor, fingerprint reader, and more. It is an aspect of the present disclosure that one or more of these associated device sensors 5423 may be used by one or more subsystems of the vehicle 100). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Ricci in the Patent Document system. Moreover, in order to improve the transaction security of the Patent Document system, one of ordinary skill in the art would have been motivated to include additional input devices, such as biometric input device associated with a user computer device. Claims 22, 24, 25, 30, 32 and 33 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 3, 5, 6, 11, 13, 14, 19 of the Patent Document. Although the claims at issue are not identical, they are not patentably distinct from each other because of the following reasons: This Application Patent Document Claim 22: The vehicle of Claim 21, wherein the vehicle computing device is further configured to receive the input biometric ID from the candidate user (e.g., second biometric input) from a biometric input device. Claims 5 and 13: The vehicle computing device according to claim 1, wherein the at least one vehicle computing processor is further programmed to: receive, via the biometric input device, the second biometric input; Claim 24: The vehicle of Claim 22, wherein the biometric input device is integral to the vehicle. Claims 3, 11 and 19: the biometric input device integral to at least one of a steering wheel, a dashboard, a mirror, or an audio system of the vehicle. Claims 25 and 33: The vehicle of Claim 21, wherein the vehicle computing device is further configured to: capture (e.g., retrieve) a current location of the vehicle from a vehicle GPS device; and transmit the current location of the vehicle to the payment processor (e.g., via at least one POS device) for comparison (e.g., verify) of the current location of the vehicle to a location of the merchant. Claims 6 and 14: The vehicle computing device according to claim 1, wherein the at least one vehicle computing processor is further programmed to: subsequent to establishing communication with the at least one POS device, retrieve a current location of the vehicle from a vehicle GPS device; and transmit the current location to the at least one POS device, wherein the payment processing computing system is configured to verify the current location received from the at least one POS device against a stored location associated with the at least one POS device. Claim 30: The method of Claim 29, wherein the receiving the input biometric ID comprises receiving the input biometric ID from the candidate user (e.g., second biometric input) from a biometric input device Claims 5 and 13: The vehicle computing device according to claim 1, wherein the at least one vehicle computing processor is further programmed to: receive, via the biometric input device, the second biometric input; Claim 32: wherein the receiving the input biometric ID from the candidate user from a biometric input device comprises receiving the input biometric ID from a biometric input device integral to the vehicle. Claims 5 and 13: receive, via the biometric input device, the second biometric input; Claims 3, 11 and 19: the biometric input device integral to at least one of a steering wheel, a dashboard, a mirror, or an audio system of the vehicle. Claims 26, 34 and 39 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of the Patent Document in view of Todasco (US 20180099630 A1, “Todasco”). Regarding claims 26, 34 and 39: The Patent Document does not explicitly disclose, utilizing location of the user computer device to process a transaction. However, Todasco, discloses: retrieve, from a GPS device of a user computer device wirelessly communicatively coupled to the vehicle computing device, a current location of the user computer device (Todasco [0058]: In some embodiments, the system 300 may determine a location 310 of the mobile device 304 that created the vehicle request. The location 310 of the mobile device 304 may correspond to a location 312 of the driver's device 306 associated with the request for the vehicle 308. For example, the location 310 may be proximate to and/or in range with the location 312 to receive wireless signals 318 from the vehicle 308 and/or the mobile device 306 as described further herein. The system 300 may retrieve data 322 from the mobile device 304 based on the location 310 of the mobile device 304); and transmit the current location of the user computer device as a current location of the vehicle to the payment processor for comparison of the current location of the vehicle to a location of the merchant (Todasco [0058]: The location 310 of the mobile device 304 may correspond to a location 312 of the driver's device 306 associated with the request for the vehicle 308. For example, the location 310 may be proximate to and/or in range with the location 312 to receive wireless signals 318 from the vehicle 308 and/or the mobile device 306 as described further herein. The system 300 may retrieve data 322 from the mobile device 304 based on the location 310 of the mobile device 304; [claim 1]: determining a location of the mobile device from the data retrieved from the operating system, wherein the location of the mobile device corresponds to a location of a merchant device). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Todasco in the Patent Document system. Moreover, in order to improve the payment transaction security of the Patent Document system, one of ordinary skill in the art would have been motivated to include utilizing location of the user computer device to process a transaction. Claim Rejections - 35 USC § 102 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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention. Claims 21-25, 27-33, 35-38 and 40 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Christopher P. Ricci (US 20180013211 A1, “Ricci”). Regarding claims 21, 29, and 37: Ricci discloses: A vehicle comprising a vehicle computing device and a vehicle memory, the vehicle computing device configured to: store, in the vehicle memory, a registration secure token (e.g., half tokens or pre-authorizations) including an account ID of a registered user, a vehicle ID unique to the vehicle, and an encrypted biometric ID of the registered user (Ricci [0170]: An embodiment of software 2300 that may be stored within the memory 1916 may be as shown in FIG. 23. Software 2300 can include one or more of an interaction application 2304…The interaction application 2304 can include a contactless payment component 2308 and/or half token application 2312; [0273]: the CPU may extract or create a half-token 2312 or information shown in data structure 2404; [0181]: This encryption key 2428 can include some type of pretty good privacy (PGP) key or other types of encryption information used to encrypt the information in the data structure 2404 or other information described herein; [0177]: The data structure 2404 can represent secure information associated with a user and/or the vehicle 100. This information data structure 2404 can have one or more data fields including, but not limited to: biometrics 2408, username 2412, password 2416, mobile device information 2420, dongle code 2424, encryption key 2428, credentials 2432, vehicle identification number (VIN) 2436, and electronic serial number (ESN) 2440, and/or an engine code 2444. There may be more or fewer fields than those shown in data structure 2404, as represented by ellipses 2452. Further, each user of the vehicle 100 may have their own data structure, as represented by ellipses 2448); Examiner’s Note: The Examiner considers, create a half-token 2312 or information shown in data structure 2404 of Ricci to be the registration secure token including an account ID of a registered user, a vehicle ID unique to the vehicle, and an encrypted biometric ID of the registered user of the claimed language. Additionally, The Examiner considers, encryption information used to encrypt the information in the data structure 2404 or other information of Ricci to be the encrypted biometric ID of the registered user of the claimed language. transmit the registration secure token to a payment processor (e.g., third party) for processing payment transactions (Ricci [0171]: The half token application 2312 can provide half tokens or pre-authorizations to third parties when interacting with those third parties. As such, the half token application 2312 is capable of authenticating or verifying the identity and veracity of the third party or providing that information for the user to the third party; [0281]: For example, if the third party is a bank, the bank may limit the amount of a transaction or a communication based on limits set by the bank for the vehicle 100); establish a wireless communication link with a POS device of a merchant by positioning the vehicle proximate to the POS device (Ricci [0254]: A vehicle 100 may enter a location, in step 4608. For example, the vehicle 100 can enter a drive-through…The CPU 5608 may be provided signals from the RF devices 2004 to determine if an RF field is detected. In step 4616, the CPU 5608 can determine which of the RF devices 2004 has the best connection or the highest field strength. For example, if the user is at a gas station and device 2004b is nearest, to a gas pump with an RF transceiver, device 2004b may have the best connection, as the field strength there may be higher than at device 2004c or 2004a. If device 2004b has the best connection, then that device 2004b may couple with the RF transceiver at the third party; [0199]: the vehicle 100 and the second party 2804 can establish some communication connection through signal(s) 2808), (see also paragraphs [0201] and [0273] and Figs. 28 and 46); receive an input biometric ID from a candidate user (Ricci [0239]: In steps 4408, 4424, the vehicle 100 can sense the presence of a driver or passenger, respectively. The internal sensors 5437 may sense the presence of a person within the vehicle 100. This person may be a driver or a passenger. The information gleaned from the sensors within the vehicle 100 may then be provided to the CPU 5608. In steps 4412, 4428, the CPU 5608 can receive the biometric information associated with the driver/passenger. This information may then be used to determine whether or not the passenger or driver is previously associated with the vehicle 100. The biometric information may be as stored in data structure 2404 in field 2408), (see Fig. 44); encrypt the input biometric ID (Ricci [0239]: In steps 4408, 4424, the vehicle 100 can sense the presence of a driver or passenger, respectively. The internal sensors 5437 may sense the presence of a person within the vehicle 100. This person may be a driver or a passenger. The information gleaned from the sensors within the vehicle 100 may then be provided to the CPU 5608. In steps 4412, 4428, the CPU 5608 can receive the biometric information associated with the driver/passenger. This information may then be used to determine whether or not the passenger or driver is previously associated with the vehicle 100. The biometric information may be as stored in data structure 2404 in field 2408; [0181]: This encryption key 2428 can include some type of pretty good privacy (PGP) key or other types of encryption information used to encrypt the information in the data structure 2404 or other information described herein); Examiner’s Note: The Examiner considers, encryption information used to encrypt the information in the data structure 2404 or other information of Ricci to be encrypt the input biometric ID of the claimed language. compare the encrypted biometric ID of the candidate user to the stored encrypted biometric ID of the registered user (Ricci [0240]: With the biometric information, the CPU 5608 can compare the received information with the information in field 2408 to determine if the driver or passenger is authenticated, in steps 4416, 4432), (see also paragraphs [0242], [0239] and [0212]); and if the encrypted biometric ID of the candidate user matches the stored encrypted biometric ID of the registered user, transmit the registration secure token to the POS device using the wireless communication link to initiate payment transaction processing between the payment processor and the POS device (Ricci [0240]: If the received biometric information from internal sensors 5437 is the same or similar to stored biometric information 2408, the driver/passenger is authenticated…If the information does compare, then the driver/passenger is authenticated and the method 4400 proceeds “YES” to step 4448; [0241]: If the user finally is authenticated, then in step 4448, the vehicle processor 5608 can allow secure interactions between the vehicle 100 and third parties; [0200]: The vehicle 100 may then send a half-token or preauthorization for some type of good or service or other type of secure communication to the second party, in signal 2812; [0242]: Based on a driver's preferences (e.g., user goes to Starbucks every morning, etc.), the onboard computer automatically pre-authorizes a transaction at a particular time and/or in response to a particular detected location of the vehicle 100. This pre-authorization can be done by observation and based on historic user behavior or spatial proximity of the vehicle 100 to the vendor (e.g., range of a transceiver on the vehicle 100 to a transceiver at the vendor or GPS-based locations of the vehicle 100 and vendor)), wherein the payment transaction is processed without the registered user directly interacting with the POS device (Ricci [0171]: The contactless payment application 2308 can conducts financial transactions using the vehicle. Contactless payment application 2308 may conduct the financial transactions with or without user input with third parties; [0191]: An embodiment of one or more routes taken by the user may be stored in route field 2612. These routes 2612 may be the consistent or common routes taken by the user and may also include information about what types of products or services may be offered along those routes. This information 2612 can allow the vehicle 100 to present options to the user or conduct automatic communications or transactions along such routes 2612; [0197]: In some configurations, the vehicle 100 may ask for a preauthorization or a half-token provided by the user, in signal 2732. Here, the vehicle 100 may present a user interface or an audio request to the user 220 requesting whether the user wishes to authorize certain automatic communications or automatic transactions before the drive begins. If the user does desire such type of automation, the user 220 may send an ack or acknowledge signal 2736 back to the vehicle 100), (see also paragraphs [0243]-[0245], [0250]-[0252] and [0264] and Fig. 45). Regarding claim 22: Ricci discloses the limitations of claim 21 above. Ricci further discloses: The vehicle of Claim 21, wherein the vehicle computing device is further configured to receive the input biometric ID from the candidate user from a biometric input device (Ricci [0239]: The internal sensors 5437 may sense the presence of a person within the vehicle 100. This person may be a driver or a passenger. The information gleaned from the sensors within the vehicle 100 may then be provided to the CPU 5608. In steps 4412, 4428, the CPU 5608 can receive the biometric information associated with the driver/passenger; [0178]: The biometrics field 2408 can include biometric information for the user. This information 2408 can include one of more of, but is not limited to: facial structure, facial recognition information, voiceprint, voice recognition information, eye color, DNA information, fingerprint information, or other types of biometric information that could be used to identify the user. This information 2408 may be gathered by sensors and stored in data structure 2408.), (see paragraph [0314] and Fig. 44). Regarding claim 23: Ricci discloses the limitations of claim 21 above. Ricci further discloses: The vehicle of Claim 22, wherein the biometric input device is associated with a user computer device wirelessly communicatively coupled to the vehicle computing device (Ricci [0180]: The mobile device information 2420 can include any information about one or more mobile devices or other types of devices that may be associated with the user and linked with the vehicle 100; [0326]: The associated device sensors 5423 can include any sensors that are associated with a device in the vehicle 100. As previously stated, typical devices may include smart phones, tablets, laptops, mobile computers, and the like. It is anticipated that the various sensors associated with these devices can be employed by the vehicle control system 5448. For example, a typical smart phone can include, an image sensor, an IR sensor, audio sensor, gyroscope, accelerometer, wireless network sensor, fingerprint reader, and more. It is an aspect of the present disclosure that one or more of these associated device sensors 5423 may be used by one or more subsystems of the vehicle 100). Regarding claim 24: Ricci discloses the limitations of claim 21 above. Ricci further discloses: The vehicle of Claim 22, wherein the biometric input device is integral to the vehicle (Ricci [0239]: In steps 4408, 4424, the vehicle 100 can sense the presence of a driver or passenger, respectively. The internal sensors 5437 may sense the presence of a person within the vehicle 100. This person may be a driver or a passenger. The information gleaned from the sensors within the vehicle 100 may then be provided to the CPU 5608. In steps 4412, 4428, the CPU 5608 can receive the biometric information associated with the driver/passenger; [0250]: The CPU 5608 can receive information from internal sensors 5437 that indicate the presence of a user within the vehicle, in step 4508. As described in conjunction with FIG. 44, the internal sensors 5437 can send information to the CPU 5608 indicating that a person is within the vehicle 100. In step 4512, the CPU 5608 can identify the person by comparing the biometric information received from the internal sensors 5437 with biometric information 2408 in data structure 2404), (see paragraph [0326]). Regarding claims 25 and 33: Ricci discloses the limitations of claim 21 above. Ricci further discloses: The vehicle of Claim 21, wherein the vehicle computing device is further configured to: capture a current location of the vehicle from a vehicle GPS device (Ricci [0173]: Geolocation application 2324 can provide location information to the vehicle 100. The geolocation information may be provided from a GPS antenna, through triangulation of cellular towers or other known landmarks, or by some other type of location information. Geolocation information may be provided to the mapping application 2228); and transmit the current location of the vehicle to the payment processor for comparison of the current location of the vehicle to a location of the merchant (Ricci [0242]: Based on a driver's preferences (e.g., user goes to Starbucks every morning, etc.), the onboard computer automatically pre-authorizes a transaction at a particular time and/or in response to a particular detected location of the vehicle 100. This pre-authorization can be done by observation and based on historic user behavior or spatial proximity of the vehicle 100 to the vendor (e.g., range of a transceiver on the vehicle 100 to a transceiver at the vendor or GPS-based locations of the vehicle 100 and vendor); [0264]: Payment may be later authorized based on vehicle identification and later acceptance. When a vehicle 100 conducts a payment transaction, the transaction may be authorized based on a unique identifier associated with the vehicle 100 and/or geolocation information associated with the vehicle 100 and/or the driver. During the initial part of the transaction, the vehicle's contactless payment system may deliver the payment information and information regarding the vehicle 100 and/or driver of the vehicle 100 (e.g., a half token). This information may be collected in other ways by the external payment device to support the authorization). Regarding claims 27 and 35: Ricci discloses the limitations of claim 21 above. Ricci further discloses: The vehicle of Claim 21, wherein the vehicle computing device is further configured to: capture a mileage reading from an odometer of the vehicle (Ricci [0299]: The odometry sensor and/or system 5416 may include one or more components that is configured to determine a change in position of the vehicle 100 over time; [0288]: a first event may be received, in step 5308. This event may be the user driving to a certain location, taking a route, or some other type of event that occurs that causes the vehicle 100 to decide to send a first portion of a secure communication to a third party, in step 5312. For example, the processor 5608 may provide a pre-order for some good or service typically purchased by the user at that time of day at that route); and Examiner’s Note: The Examiner considers, odometry sensor and/or system 5416 may include one or more components that is configured to determine a change in position of the vehicle 100 over time of Ricci to be the capture a mileage reading from an odometer of the claimed language. transmit the mileage reading to at least one of the payment processor and the POS device for comparison to a previous mileage reading (Ricci [0299]: In some embodiments, the odometry system 5416 may utilize data from one or more other sensors and/or systems 5404 in determining a position (e.g., distance, location, etc.) of the vehicle 100 relative to a previously measured position for the vehicle 100), wherein the payment transaction processing between the payment processor and the POS device is initiated when the mileage reading is greater than the previous mileage reading ([0288]: The second event may be the vehicle 100 driving to the physical location of the third party. As such, the second event may be the navigation system 302 identifying that the vehicle 100 is at the third party's location; [0289]: In step 5320, the processor 5608 can determine whether the user then authorizes the complete communication/transaction; [claim 25]: wherein the sensitive information comprises financial information of the user, wherein the common signal source is associated with a vendor, wherein the vendor is a drive through restaurant, wherein the first RF antenna communicates with a second RF antenna in physical proximity of a drive through window of the drive through restaurant, and wherein the processor authorizes the financial transaction in response to a plurality of a vehicle location, speed, proximity to a location, preference data and historical information associated with the user). Regarding claims 28, 36 and 40: Ricci discloses the limitations of claim 21 above. Ricci further discloses: The vehicle of Claim 21, wherein the registration secure token further includes a registered device ID of a user computer device of the registered user, and wherein the vehicle computing device is further configured to (see paragraphs [0273], [0177] and [0219]): retrieve, from a candidate user computer device wirelessly communicatively coupled to the vehicle computing device, a candidate device ID (Ricci [0230]: In step 4308, the CPU 5608 can receive sensitive information, as described in conjunction with FIG. 42. In step 4312, the CPU 5608 can determine an encryption key based on the user and/or vehicle information. As such, the CPU 5608 can associate the VIN 2436, the ESN 2440, the engine code 2444, or other information associated with the vehicle 100 with the user and the user information, for example, biometrics 2408, username 2412, password 2416, mobile device information 2420, dongle code 2424, etc.; [0177]: The data structure 2404 can represent secure information associated with a user and/or the vehicle 100. This information data structure 2404 can have one or more data fields including, but not limited to: biometrics 2408, username 2412, password 2416, mobile device information 2420, dongle code 2424, encryption key 2428, credentials 2432, vehicle identification number (VIN) 2436, and electronic serial number (ESN) 2440, and/or an engine code 2444; [0180]: The mobile device information 2420 can include any information about one or more mobile devices or other types of devices that may be associated with the user and linked with the vehicle 100); compare the candidate device ID to the registered device ID (Ricci [0240]: With the biometric information, the CPU 5608 can compare the received information with the information in field 2408 to determine if the driver or passenger is authenticated; [0241]: Other information may include a username 2412, a password 2416, mobile device information 2420, etc. that may be used to authenticate the user); and when the candidate device ID matches the registered device ID, transmit the registration secure token to the POS device (Ricci [0240]: As such, the CPU 5608 can determine if the driver/passenger is authenticated in steps 4420 or 4436. If the information does compare, then the driver/passenger is authenticated and the method 4400 proceeds “YES” to step 4448; [0241]: If the other information is valid and compares to the information stored in data structure 2404, the user may be authenticated again; [0219]: Also, having the mobile device information 3972, 3976 allows the vehicle 100 to conduct transactions through the mobile device rather than through the vehicle 100, if desired; [0200]: The vehicle 100 may then send a half-token or preauthorization for some type of good or service or other type of secure communication to the second party, in signal 2812). Regarding claim 30: Ricci discloses the limitations of claim 21 above. Ricci further discloses: The method of Claim 29, wherein the receiving the input biometric ID comprises receiving the input biometric ID from the candidate user from a biometric input device (Ricci [0239]: The internal sensors 5437 may sense the presence of a person within the vehicle 100. This person may be a driver or a passenger. The information gleaned from the sensors within the vehicle 100 may then be provided to the CPU 5608. In steps 4412, 4428, the CPU 5608 can receive the biometric information associated with the driver/passenger; [0178]: The biometrics field 2408 can include biometric information for the user. This information 2408 can include one of more of, but is not limited to: facial structure, facial recognition information, voiceprint, voice recognition information, eye color, DNA information, fingerprint information, or other types of biometric information that could be used to identify the user. This information 2408 may be gathered by sensors and stored in data structure 2408), (see paragraph [0314] and Fig. 44). Regarding claim 31: Ricci discloses the limitations of claim 21 above. Ricci further discloses: The method of Claim 30, wherein the receiving the input biometric ID from the candidate user from a biometric input device comprises receiving the input biometric ID from a biometric input device associated with a user computer device wirelessly communicatively coupled to the vehicle computing device (Ricci [0180]: The mobile device information 2420 can include any information about one or more mobile devices or other types of devices that may be associated with the user and linked with the vehicle 100; [0326]: The associated device sensors 5423 can include any sensors that are associated with a device in the vehicle 100. As previously stated, typical devices may include smart phones, tablets, laptops, mobile computers, and the like. It is anticipated that the various sensors associated with these devices can be employed by the vehicle control system 5448. For example, a typical smart phone can include, an image sensor, an IR sensor, audio sensor, gyroscope, accelerometer, wireless network sensor, fingerprint reader, and more. It is an aspect of the present disclosure that one or more of these associated device sensors 5423 may be used by one or more subsystems of the vehicle 100), (see paragraphs [0239] and [0314]). Regarding claim 32: Ricci discloses the limitations of claim 21 above. Ricci further discloses: The method of Claim 30, wherein the receiving the input biometric ID from the candidate user from a biometric input device comprises receiving the input biometric ID from a biometric input device integral to the vehicle (Ricci [0239]: In steps 4408, 4424, the vehicle 100 can sense the presence of a driver or passenger, respectively. The internal sensors 5437 may sense the presence of a person within the vehicle 100. This person may be a driver or a passenger. The information gleaned from the sensors within the vehicle 100 may then be provided to the CPU 5608. In steps 4412, 4428, the CPU 5608 can receive the biometric information associated with the driver/passenger; [0250]: The CPU 5608 can receive information from internal sensors 5437 that indicate the presence of a user within the vehicle, in step 4508. As described in conjunction with FIG. 44, the internal sensors 5437 can send information to the CPU 5608 indicating that a person is within the vehicle 100. In step 4512, the CPU 5608 can identify the person by comparing the biometric information received from the internal sensors 5437 with biometric information 2408 in data structure 2404), (see paragraphs [0326], [0239] and [0314]). Regarding claim 38: Ricci discloses the limitations of claim 21 above. Ricci further discloses: The at least one non-transitory computer-readable storage medium of Claim 37, wherein the instructions are further executable to cause the at least one processor to receive the input biometric ID from the candidate user from a biometric input device associated with a user computer device wirelessly communicatively coupled to the vehicle computing device (Ricci [0239]: The internal sensors 5437 may sense the presence of a person within the vehicle 100. This person may be a driver or a passenger. The information gleaned from the sensors within the vehicle 100 may then be provided to the CPU 5608. In steps 4412, 4428, the CPU 5608 can receive the biometric information associated with the driver/passenger; [0178]: The biometrics field 2408 can include biometric information for the user. This information 2408 can include one of more of, but is not limited to: facial structure, facial recognition information, voiceprint, voice recognition information, eye color, DNA information, fingerprint information, or other types of biometric information that could be used to identify the user. This information 2408 may be gathered by sensors and stored in data structure 2408; [0180]: The mobile device information 2420 can include any information about one or more mobile devices or other types of devices that may be associated with the user and linked with the vehicle 100), (see paragraphs [0326] and [0314] and Fig. 44). Claim Rejections - 35 USC § 103 This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. 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. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 26, 34 and 39 are rejected under 35 U.S.C. 103 as being unpatentable over Christopher P. Ricci (US 20180013211 A1, “Ricci”) in view of Michael Charles Todasco (US 20180099630 A1, “Todasco”). Regarding claims 26, 34 and 39: Ricci, discloses the limitations of claim 21 above. Ricci does not explicitly disclose, however, Todasco discloses: The vehicle of Claim 21, wherein the vehicle computing device is further configured to: retrieve, from a GPS device of a user computer device wirelessly communicatively coupled to the vehicle computing device, a current location of the user computer device (Todasco [0058]: In some embodiments, the system 300 may determine a location 310 of the mobile device 304 that created the vehicle request. The location 310 of the mobile device 304 may correspond to a location 312 of the driver's device 306 associated with the request for the vehicle 308. For example, the location 310 may be proximate to and/or in range with the location 312 to receive wireless signals 318 from the vehicle 308 and/or the mobile device 306 as described further herein. The system 300 may retrieve data 322 from the mobile device 304 based on the location 310 of the mobile device 304); and transmit the current location of the user computer device as a current location of the vehicle to the payment processor for comparison of the current location of the vehicle to a location of the merchant (Todasco [0058]: The location 310 of the mobile device 304 may correspond to a location 312 of the driver's device 306 associated with the request for the vehicle 308. For example, the location 310 may be proximate to and/or in range with the location 312 to receive wireless signals 318 from the vehicle 308 and/or the mobile device 306 as described further herein. The system 300 may retrieve data 322 from the mobile device 304 based on the location 310 of the mobile device 304; [claim 1]: determining a location of the mobile device from the data retrieved from the operating system, wherein the location of the mobile device corresponds to a location of a merchant device). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Todasco in the Patent Document system. Moreover, in order to improve the payment transaction security of the Patent Document system, one of ordinary skill in the art would have been motivated to include utilizing location of the user computer device to process a transaction. Conclusion The prior art, made of record and not relied upon, is considered pertinent to the applicant’s disclosure. Gaddam et al. (US 20150058224 A1, “Gaddam”) discloses a vehicle interface device (VID) coupled to the vehicle is used for transmitting payment account information to a merchant access device. Azzam et al. (US 20220284440 A1, “Azzam”) discloses processing transactions based on biometric data used in connection with authenticating consumers to payment accounts to which the transactions are directed. Tunnell et al. (US 20170039568 A1, “Tunnell”) discloses provide a secure token for any type of sensitive information that a user may desire to store on a device and securely verify/validate with another party, server, system, or device without disclosing the original sensitive information during the transmission of the secure token. Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAHED ALI whose telephone number is (571)270-1085. The examiner can normally be reached 8:00 - 5:00 M-F. 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, Neha Patel can be reached on (571) 270-1492. 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. /JAHED ALI/ Examiner, Art Unit 3699
Read full office action

Prosecution Timeline

Jun 02, 2025
Application Filed
Sep 25, 2025
Response after Non-Final Action
Mar 07, 2026
Non-Final Rejection — §102, §103, §DP (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12579532
AUTOMATED DEVICE PAIRING
2y 5m to grant Granted Mar 17, 2026
Patent 12572927
SYSTEMS AND METHODS FOR GENERATING AND TRANSMITTING ELECTRONIC TRANSACTION ACCOUNT INFORMATION MESSAGES
2y 5m to grant Granted Mar 10, 2026
Patent 12547993
System, Method, and Computer Program Product for Managing Operation of a Remote Terminal
2y 5m to grant Granted Feb 10, 2026
Patent 12511643
USER ASSUMPTION OF IDENTITY OF NFT IN CRYPTO WALLET
2y 5m to grant Granted Dec 30, 2025
Patent 12499436
DETERMINING AN OPTIMUM QUANTITY OF FRACTIONAL NON-FUNGIBLE TOKENS TO GENERATE FOR CONTENT AND A CONTENT EXCHANGE
2y 5m to grant Granted Dec 16, 2025
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

1-2
Expected OA Rounds
60%
Grant Probability
99%
With Interview (+59.6%)
3y 6m
Median Time to Grant
Low
PTA Risk
Based on 141 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