Prosecution Insights
Last updated: October 22, 2026
Application No. 17/897,047

COMPUTER SYSTEM FOR FACILITATING FINANCIAL TRANSACTIONS AND REDUCING FRAUD

Non-Final OA §112
Filed
Aug 26, 2022
Priority
Jun 05, 2015 — provisional 62/171,944 +7 more
Examiner
NILFOROUSH, MOHAMMAD A
Art Unit
3697
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Life365 Inc.
OA Round
3 (Non-Final)
31%
Grant Probability
At Risk
3-4
OA Rounds
1y 0m
Est. Remaining
68%
With Interview

Examiner Intelligence

Grants only 31% of cases
31%
Career Allowance Rate
129 granted / 416 resolved
-21.0% vs TC avg
Strong +37% interview lift
Without
With
+36.8%
Interview Lift
resolved cases with interview
Typical timeline
5y 2m
Avg Prosecution
16 currently pending
Career history
437
Total Applications
across all art units

Statute-Specific Performance

§101
26.3%
-13.7% vs TC avg
§103
35.4%
-4.6% vs TC avg
§102
7.6%
-32.4% vs TC avg
§112
30.0%
-10.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 416 resolved cases

Office Action

§112
DETAILED ACTION Acknowledgements The amendment filed on 6/3/2026 is acknowledged. Claims 1-9 and 21-33 are pending. Claims 1-9 and 21-33 have been examined. 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 . Continued Examination Under 37 CFR 1.114 A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 6/3/2026 has been entered. Response to Amendment/Arguments Applicant’s remarks have been considered, but are moot in view of the new grounds of rejection. Claim Rejections - 35 USC § 112 The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112: The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention. Claims 1-9 and 21-33 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claim 1 recites “wherein the merchant payment server is configured to: receive one or more sensor readings relative to the start of the drive-through, the speaker in the drive-through, and the window of the drive-through; determine where the user device is in line within the drive-through based on the one or more sensor readings.” Claim 33 similarly recites “receive, by the merchant payment server, one or more sensor readings relative to the start of the drive-through, the speaker in the drive-through, and the window of the drive-through” and “determine, by the merchant payment server, where the user device is in line within the drive-through based on the one or more sensor readings.” These limitations require that the merchant payment server receive the one or more sensor readings and determine where the use is in line within the drive-through based on the sensor readings. Claim 21 recites “receive one or more sensor readings relative to the start of the drive-through, the speaker in the drive-through, and the window of the drive-through; determine where the user device is in line within the drive-through based on the one or more sensor readings,” where the method utilizes a merchant server, a merchant payment server, a merchant account, and a merchant device. This requires that one of the merchant server, merchant payment server, merchant account, and merchant device receive the one or more sensor readings and determine where the use is in line within the drive-through based on the sensor readings. The specification does not provide support for any of the merchant server, merchant payment server, merchant account, and merchant device performing these functions. The specification states that the application on the user device “can be used to calculate where the customer is located relative to a drive-through restaurant or facilities thereof, so as to engage the user at the appropriate time” (Specification ¶ 46). Further, paragraph 42 discloses “GPS-enabled features of the user device.” These paragraphs describe functions performed by the user device, rather than any of the merchant server, merchant payment server, merchant account, and merchant device. Additionally, paragraphs 54-55 describe a merchant application on the merchant device being used to mark the GPS coordinates of locations associated with the drive-through, but these paragraphs do not disclose the merchant device receiving any sensor readings. Therefore, the specification does not disclose any of the merchant server, merchant payment server, merchant account, or merchant device receiving the one or more sensor readings and determining where the use is in line within the drive-through based on the sensor readings. Claims 2-9 and 22-32 are also rejected as each depends on either claim 1 or 21. Claim 1 recites “wherein the merchant payment server is configured to: . . . cause an order interface to be displayed on the user device when the user device is at or approaching the start of the drive-through” and claim 33 recites “cause, by the merchant payment server, an order interface to be displayed on the user device when the user device is at or approaching the start of the drive-through.” Additionally, claim 21 recites that the method comprises “cause an order interface to be displayed on the user device when the user device is at or approaching the start of the drive-through,” where the method utilizes a merchant server, a merchant payment server, a merchant account, and a merchant device. The specification does not provide support for this limitation because it does not support a merchant payment server causing such an interface to be displayed on the user device specifically when the user device is at or approaching the start of the drive-through, as claimed in claims 1 and 33, not does it disclose that any of the merchant server, merchant account, or merchant device cause such an interface to be displayed on the user device when the user device is at or approaching the start of the drive-through, as claimed in claim 21. The specification states that the application on the user device can display an interface when the user is at the start of the drive-through (Specification ¶ 46), and popping up a user interface on the user device when the user is close to the merchant (Specification ¶ 55), but does not disclose what, if anything, the merchant payment server causes, and specifically does not disclose that the merchant payment server causes the order interface to be displayed on the user device when the user device is at or approaching the start of the drive-through as required by claims 1 and 33. Nor does the specification disclose that any of the merchant server, merchant account, or merchant device causes the order interface to be displayed on the user device when the user device is at or approaching the start of the drive-through, as required by claim 21. Claims 2-9 and 22-32 are also rejected as each depends on either claim 1 or 21. Claim 1 recites “wherein the merchant payment server is configured to: . . . cause the merchant device to indicate that an order corresponding to the user request is in a merchant system when the user device is at or approaching the speaker.” Claim 33 similarly recites “cause, by the merchant payment server, the merchant device to indicate that an order corresponding to the user request is in a merchant system when the user device is at or approaching the speaker.” These limitations require that the merchant payment server cause the merchant device to indicate that an order is in a merchant system when the user is at or approaching the speaker, specifically. Claim 21 recites “cause the merchant device to indicate that an order corresponding to the user request is in a merchant system when the user device is at or approaching the speaker,” where the method utilizes a merchant server, a merchant payment server, and a merchant account, in addition to the merchant device. This requires that at least one of the merchant server, merchant payment server, or merchant account cause the merchant device to indicate that an order corresponding to the user request is in a merchant system when the user device is at or approaching the speaker, specifically. The specification does not provide support for this limitation because it does not disclose that the merchant payment server, or any of the merchant server, or merchant account cause the merchant to indicate that an order corresponding to the user request is in a merchant system, and further that these entities cause any such indication specifically “when the user device is at or approaching the speaker.” The specification states that at the speaker, the user is asked to pull forward because the order is already in the system (Specification ¶ 46). The discussion of the actions performed at the speaker in the specification is limited to what the user is asked to do. The specification also discloses the customer can have the option presented on the user device to “prepare now”, in which case the order is placed in the merchant queue (Specification ¶ 47), but does not disclose that this done at the speaker. The specification additionally generically discloses popping up a user interface on the user device when the user is close to the merchant (Specification ¶ 55). Therefore, the specification does not disclose that any of the merchant payment server, merchant server, or merchant account cause the merchant to indicate that an order corresponding to the user request is in a merchant system, and further that these entities cause any such indication specifically “when the user device is at or approaching the speaker.” Claims 2-9 and 22-32 are also rejected as each depends on either claim 1 or 21. Claim 1 recites “wherein the merchant payment server is configured to: . . . causing a payment request interface to be displayed on the user device prior to or at the window of the drive-through. Claim 33 similarly recites “request, by the merchant payment server, payment information by causing a payment request interface to be displayed on the user device prior to or at the window of the drive-through.” Claim 21 recites “at a predetermined point within the drive-through, request payment information by causing a payment request interface to be displayed on the user device prior to or at the window of the drive-through,” where the method utilizes a merchant server, a merchant payment server, a merchant account, and a merchant device. The specification does not provide support for this limitation because it does not disclose that the displaying of the payment request interface is caused by the merchant payment server as required by claims 1 and 33 or by any of the merchant server, merchant payment server, merchant account, or merchant device as required by claim 21 The specification discloses that prior to or at a payment window, the application provides a display requesting payment prior to or after receiving the user's order (Specification ¶ 46). This describes what the user device does but does not describe this as being caused by the merchant payment server as required by claims 1 and 33, or by any of the merchant server, merchant payment server, merchant account, or merchant device as required by claim 21. The specification additionally generically discloses popping up a user interface on the user device when the user is close to the merchant (Specification ¶ 55). However, the specification does not disclose the merchant payment server causes a payment request interface to be displayed on the user device prior to or at the window of the drive-through as required by claims 1 and 33, or that any of the merchant server, merchant payment server, merchant account, or merchant device cause a payment request interface to be displayed on the user device prior to or at the window of the drive-through as required by claim 21. Claims 2-9 and 22-32 are also rejected as each depends on either claim 1 or 21. Statement Regarding Prior Art for Claims 1-9 and 21-33 The closest prior art of Kravitz (US 6,029,150) discloses (a) a merchant server configured to communicate with a user device and to receive instructions sent from the user device (Kravitz Figure 1, Merchant Network Server 110 in communication with Customer Network Software 104; 11:64-12:2; 17:64-67; 24:33-38; 25:32-39); (b) a merchant payment server in communication with the merchant server (Kravitz Figure 1, Merchant Clearing Corporation 114 in communication with Merchant Network Server 110; 12:3-14, 22-28); (c) a merchant account in communication with the merchant payment server (Kravitz 12:6-10); and (d) a merchant configured to (i) receive at least some of the instructions sent by the user device to the merchant server, and (ii) communicate at least a portion of the at least some of the instructions sent by the user device in order to fulfill a user request (Kravitz 12:45-54; 17:64-67; 24:33-38; 25:32-39; 35:54-59); wherein the merchant payment server is configured to: receive a token from the user device that indicates payment for the user request was made to the merchant account, wherein the token does not include an account number of the user (Kravitz 7:26-29, 39-43; 13:2-19, 26-36; 15:14-28; 32:59-64; 34:51-35:40). L’Heureux, et al. (US 2014/0257877) (“L’Heureux”) further discloses that the merchant comprises a merchant device in communication with the user device, and that the merchant device receives the instructions sent by the user device and sent by the merchant server to the merchant device (L’Heureux ¶¶ 13-15, 19, 27-28, 34-36). L’Heureux also discloses communicating the instructions to fulfill the user request to a merchant agent (L’Heureux ¶¶ 13, 19, 35, 60). Additionally, Theobald (US 2015/0379650) discloses a merchant device marking a GPS location for a start of a drive- through, mark a GPS location for a speaker in the drive-through, and mark a GPS location for a window of the drive-through and merchant payment server receiving one or more sensor readings relative to a start of a drive-through, a speaker in the drive-through, and a window of the drive-through, and at a predetermined point within the drive-through, requesting payment information (Theobald ¶¶ 10-16, 19, 26, 31, 33-35, 41-42, 45-46, 50, 52-53, 82). However, the prior art does not disclose, neither singly nor in combination, the particular use of sensor readings of GPS locations by the merchant payment server to determine where the use is in line at a drive-through and cause various interfaces to be displayed on the user device based on the user’s position in the drive-through. Specifically, the prior art does not disclose that the merchant payment server is configured to: receive one or more sensor readings relative to the start of the drive- through, the speaker in the drive-through, and the window of the drive-through, determine where the user device is in line within the drive-through based on the one or more sensor readings, cause an order interface to be displayed on the user device when the user device is at or approaching the start of the drive-through, cause the merchant device to indicate that an order corresponding to the user request is in a merchant system when the user device is at or approaching the speaker, and at a predetermined point within the drive-through, request payment information by causing a payment request interface to be displayed on the user device prior to or at the window of the drive-through. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to Mohammad A. Nilforoush whose telephone number is (571)270-5298. The examiner can normally be reached Monday-Friday 12pm-7pm. 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, John W. Hayes can be reached at 571-272-6708. 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. /Mohammad A. Nilforoush/Primary Examiner, Art Unit 3697
Read full office action

Prosecution Timeline

Show 1 earlier event
Feb 21, 2025
Non-Final Rejection mailed — §112
Jul 16, 2025
Applicant Interview (Telephonic)
Jul 17, 2025
Examiner Interview Summary
Aug 19, 2025
Response Filed
Dec 10, 2025
Final Rejection mailed — §112
Jun 03, 2026
Request for Continued Examination
Jun 09, 2026
Response after Non-Final Action
Oct 05, 2026
Non-Final Rejection mailed — §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12770148
COOPERATIVE FRAUD-DETECTION PROCESSING
9y 0m to grant Granted Oct 20, 2026
Patent 12770136
Non Fungible Token (NFT) Based Licensing and Digital Rights Management (DRM) for Software and Other Digital Assets
1y 2m to grant Granted Oct 20, 2026
Patent 12762568
SYSTEMS AND METHODS FOR ORDERING AND PAYMENT
2y 7m to grant Granted Oct 13, 2026
Patent 12737735
MIXED TECHNIQUE TRANSACTION CLASSIFICATION
2y 10m to grant Granted Sep 15, 2026
Patent 12718230
SECURE CRYPTO CURRENCY POINT-OF-SALE (POS) MANAGEMENT
4y 9m to grant Granted Aug 25, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

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

Prosecution Projections

3-4
Expected OA Rounds
31%
Grant Probability
68%
With Interview (+36.8%)
5y 2m (~1y 0m remaining)
Median Time to Grant
High
PTA Risk
Based on 416 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

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

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

Free tier: 3 strategy analyses per month