Prosecution Insights
Last updated: April 19, 2026
Application No. 18/801,188

FACILITATING LOCATION-BASED SALES VENUE TRANSACTION PAYMENTS USING NON-LOCATION-BASED IDENTITY TARGETS

Non-Final OA §101§103§112§DP
Filed
Aug 12, 2024
Examiner
CHAMPAGNE, LUNA
Art Unit
3627
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Iqmetrix Software Development Corporation
OA Round
1 (Non-Final)
46%
Grant Probability
Moderate
1-2
OA Rounds
4y 0m
To Grant
80%
With Interview

Examiner Intelligence

Grants 46% of resolved cases
46%
Career Allow Rate
267 granted / 585 resolved
-6.4% vs TC avg
Strong +34% interview lift
Without
With
+34.5%
Interview Lift
resolved cases with interview
Typical timeline
4y 0m
Avg Prosecution
44 currently pending
Career history
629
Total Applications
across all art units

Statute-Specific Performance

§101
23.6%
-16.4% vs TC avg
§103
50.1%
+10.1% vs TC avg
§102
5.5%
-34.5% vs TC avg
§112
15.7%
-24.3% vs TC avg
Black line = Tech Center average estimate • Based on career data from 585 resolved cases

Office Action

§101 §103 §112 §DP
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 Applicant’s submission filed 8/12/24 has been entered. Claim 1 is presented for examination. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. Claim 1 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as failing to set forth the subject matter which the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the applicant regards as the invention. Claim 1 recites “wherein each physical identity target contains no human- or device-readable indication of the associated sales venue or customer location.” It is unclear if the physical identity target contains ‘no human or no-device readable indication’ or if the physical identity target contains ‘no human-readable’ indication but contains ‘device-readable indication’. Appropriate action is required. Double Patenting A rejection based on double patenting of the “same invention” type finds its support in the language of 35 U.S.C. 101 which states that “whoever invents or discovers any new and useful process... may obtain a patent therefor...” (Emphasis added). Thus, the term “same invention,” in this context, means an invention drawn to identical subject matter. See Miller v. Eagle Mfg. Co., 151 U.S. 186 (1894); In re Vogel, 422 F.2d438, 164 USPQ 619 (CCPA 1970); In re Ockert, 245 F.2d 467, 114 USPQ 330 (CCPA 1957). A statutory type (35 U.S.C. 101) double patenting rejection can be overcome by canceling or amending the claims that are directed to the same invention so they are no longer coextensive in scope. The filing of a terminal disclaimer cannot overcome a double patenting rejection based upon 35 U.S.C. 101. Claim 1 is rejected under 35 U.S.C. 101 as claiming the same invention as that of claim 1 of prior U.S. Patent No. 10817863, and U.S. Patent No. 11481755. This is a statutory double patenting rejection. Please see claim 1 of U.S. Patent No. 10817863 below as an example. App.# 18801188 Patent No. 10817863 1. A method of processing payments for at least one location-based sales venue containing a plurality of customer locations and at least one network-connected venue-associated POS system, wherein each customer location has a physical identity target attached in proximity thereto comprising a unique identifier readable by mobile customer devices, the method comprising: 1. A method of processing payments for at least one location-based sales venue containing a plurality of customer locations and at least one network-connected venue-associated POS system, wherein each customer location has a physical identity target attached in proximity thereto comprising a unique identifier readable by mobile customer devices, the method comprising: a) providing a server including a payment processing software component, a) providing a server including a payment processing software component, a network interface capable of two-way communication via at least one data network with mobile customer devices as well as with all of the venue-associated POS systems, a network interface capable of two-way communication via at least one data network with mobile customer devices as well as with all of the venue-associated POS systems, a transaction gateway through which customer payments can be processed, a transaction gateway through which customer payments can be processed, and a location database comprising a venue record corresponding to each location-based sales venue and containing venue payment details via which payments to the venue can be electronically processed by the transaction gateway and and a location database comprising a venue record corresponding to each location-based sales venue and containing venue payment details via which payments to the venue can be electronically processed by the transaction gateway and network address details for each venue-associated POS system by which the server can communicate with same, and network address details for each venue-associated POS system by which the server can communicate with same, --a location record corresponding to each physical customer location in each managed venue and containing the unique identifier of the associated physical identity target and identification of a venue-associated POS system affiliated with the customer location; and a location record corresponding to each physical customer location in each managed venue and containing the unique identifier of the associated physical identity target and identification of a venue-associated POS system affiliated with the customer location; b) in a customer-initiated payment step using the server and the payment processing software component, facilitating a desired payment transaction by a customer seeking to pay the outstanding service bill in respect of at least one selected customer location by: b) in a customer-initiated payment step using the server and the payment processing software component, facilitating a desired payment transaction by a customer seeking to pay the outstanding service bill in respect of at least one selected customer location by: i) receiving at the server a location transmission containing the identifier of the physical identity target of the at least one selected customer location from a customer mobile device having read and captured the identifier; i) receiving at the server a location transmission containing the identifier of the physical identity target of the at least one selected customer location from a customer mobile device having read and captured the identifier; ii) parsing the location transmission to extract the received identifier of the physical identity target for each of the at least one selected customer locations contained therein; ii) parsing the location transmission to extract the received identifier of the physical identity target for each of the at least one selected customer locations contained therein; iii) selecting the location records corresponding to each selected customer location by matching the received identifiers with the details of associated identifiers stored within the location records; iii) selecting the location records corresponding to each selected customer location by matching the received identifiers with the details of associated identifiers stored within the location records; iv) querying the venue-associated POS system for each selected customer location to obtain the required payment details and determining the total payment amount required from the customer; iv) querying the venue-associated POS system for each selected customer location to obtain the required payment details and determining the total payment amount required from the customer; v) receiving customer payment method details from the mobile customer device of the customer; v) receiving customer payment method details from the mobile customer device of the customer; vi) triggering a payment transaction for the total payment amount via the transaction gateway using the customer payment method details from the mobile customer device and the venue payment details from the venue record associated with the selected customer locations; and vi) triggering a payment transaction for the total payment amount via the transaction gateway using the customer payment method details from the mobile customer device and the venue payment details from the venue record associated with the selected customer locations; and vii) on completion of the payment transaction, transmitting a payment completion indication in respect of the selected customer locations to each associated venue-associated POS system; vii) on completion of the payment transaction, transmitting a payment completion indication in respect of the selected customer locations to each associated venue-associated POS system; --wherein the unique identifier displayed on each identity target is not duplicated on any two location records; and wherein each physical identity target contains no human- or device-readable indication of the associated sales venue or customer location. wherein the unique identifier displayed on each identity target is not duplicated on any two location records; and wherein each physical identity target contains no human- or device-readable indication of the associated sales venue or customer location. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over MCCAUGHT et al. (US 20160104155A1) in view of Bueno (US 20020013734 A1). Re-claim 1, MCCAUGHT et al. teach b) in a customer-initiated payment step using the server and the payment processing software component, facilitating a desired payment transaction by a customer seeking to pay the outstanding service bill in respect of at least one selected customer location by: i) receiving at the server a location transmission containing the identifier of the physical identity target of the at least one selected customer location from a customer mobile device having read and captured the identifier; (see e.g. paragraphs [0086] Point-of-sale terminals 102 may be associated with unique individual and/or group identifiers, such as suitably-configured optical or wirelessly-readable codes. Such codes may, for example, be displayed proximate to the corresponding POS terminal(s) 102 so that a user 104 of, for example, a mobile device 106 may be able to use the device 106 to identify the POS terminal 102 and associate it with a proposed transaction. [0096] Transaction request processing subsystem(s) 118 may be configured for receiving transaction requests from one or more device(s) 106 via network(s) 150 requesting that a mobile device be provisioned with data sets or elements that may be used in conjunction with payment transactions. Such transaction requests may be issued and/or received for various reasons, such as a user 104 requesting that a mobile device be provisioned in anticipation of a transaction, etc. [0097] Transaction request processing subsystem(s) 118 may be configured to receive inputs from a mobile device 106 identifying a particular POS terminal or merchant backend system 102, 103, or group(s) thereof. Such inputs may include information such as a code identifying the POS or merchant systems 102, 103. Identifying information may include the location of a merchant, department of a store or other merchant premises, a particular check-out lane or area associated with the point-of-sale terminal 102, etc.). ii) parsing the location transmission to extract the received identifier of the physical identity target for each of the at least one selected customer locations contained therein; iii) selecting the location records corresponding to each selected customer location by matching the received identifiers with the details of associated identifiers stored within the location records; (see e.g. paragraph [0097] The transaction request processing subsystem 118, in some embodiments, may determine which code matches with which point-of-sale terminal 102 through stored information on a database 124, for example, a stored look-up table.) ******The Examiner notes by matching the codes to identify the point-of-sale terminal, the code/identifier must be extracted from the transaction request/message. iv) querying the venue-associated POS system for each selected customer location to obtain the required payment details and determining the total payment amount required from the customer; (see e.g. paragraphs [0147] At 308, the backend system 108 may transmit a transaction confirmation message or data set to the identified point-of-sale terminal 102, or an associated merchant back-end system 103 to provide notification that the user 104 wishes to pay or otherwise complete the requested transaction electronically, and request confirmation that the merchant system 102, 103 wishes to proceed.) [0148] At 310, the point-of-sale terminal 102 can transmit relevant transaction information or other confirmation, such as a total price, and optionally quantities and/or item identification and pricing data). v) receiving customer payment method details from the mobile customer device of the customer; (see e.g. [0086] the mobile device 106 may be able to push transaction information to the point-of-sale terminal 102, and/or route it independently to a third-party system 108, such as a payment processor, for processing. [0107] In some embodiments, transaction messages generated at a mobile device provisioning subsystem 122 may include further locators or references that identify, for example, IP addresses where the payment tags or data sets (e.g., EMV data tags), or other information, associated with a particular transaction are stored, or to be stored (e.g., at a system 100, 114, etc). Such locators, when relayed by a mobile device 106 to a POS terminal or merchant system 102, 103, allow the payment tags to be retrieved by the point-of-sale terminal 102 (e.g., by way of network 150). [0140] The user 104 may then use the user's mobile device 106 to provide information in regards to a transaction involving the point-of-sale terminal 102, 103 to a transaction adjudicator or other transaction processor 108, etc. Payment flow push transactions to pre-authorize future purchases and payment flow push transactions to authorize real time, contemporaneously-pending transactions are contemplated. Further types of payment flow push transactions are also enabled by the disclosure herein.) vi) triggering a payment transaction for the total payment amount via the transaction gateway using the customer payment method details from the mobile customer device and the venue payment details from the venue record associated with the selected customer locations; and (see e.g. [0158] At 410, the back end/adjudication system 108 can match the request received from the user 106 with the message received from the point-of-sale terminal 102, based on an identifier of the point-of-sale terminal 102 included in each message. In this way, a particular user 104 and/or device may be confidently associated by system 108 with a particular proposed transaction. [0152] At 318, the backend system 108 may complete processing of the transaction using the payment information received at 306. [0123] At 214, the external backend system 108 may process the transaction. This may, for example, involve provisionally or finally clearing the transaction with a financial institution server 110, 114 associated with a payment token or account identified by, or otherwise associated with, the user system 106's transaction request, through the use of suitably-configured signal exchanges) vii) on completion of the payment transaction, transmitting a payment completion indication in respect of the selected customer locations to each associated venue-associated POS system; (see e.g. [0124] At 216, a message confirming or otherwise indicating that the transaction was approved or not approved may be transmitted back to the POS/merchant terminal 102, 103, and/or to the controller 106. For example, an electronic alert may be provided to the user (e.g., through the mobile device 106) indicating whether or not the payment was approved, using the same, partially the same, or different data sets.) --wherein the unique identifier displayed on each identity target is not duplicated on any two location records; and wherein each physical identity target contains no human- or device-readable indication of the associated sales venue or customer location. (see e.g. [0050] In some embodiments, a POS or other merchant transaction processing system may simply be represented by an image or graphically-embedded code, such as a machine-readable quick response (QR) code or a bar code; or by a radio frequency identification (RFID) or NFC tag comprising a machine-readable coded identifier which serves to adequately or uniquely identify the merchant system.) NOTE: The Examiner is interpreting the term” no human- or device-readable indication” as “no human-readable, but device-readable indication. Furthermore, MCCAUGHT et al. teach the unique identifier. No reference to a duplicate identifier is found in MCCAUGHT et al.. The unique identifier is also a QR code or barcode. MCCAUGHT et al. anticipate some of the limitations below: However, Bueno explicitly teaches-- a location database comprising a venue record corresponding to each location-based sales venue and containing venue payment details via which payments to the venue can be electronically processed by the transaction gateway and (see e.g. abstract ---A computer implemented on-line system service manages an exchange between consumers and vendors located throughout different geographic locations. The on-line system service is particularly useful for a restaurant delivery and take-out environment. The on-line system service manages the exchange with databases that track menus from a variety of restaurants located in different geographic locations and profiles from a variety of consumers located in different geographic locations as well. Each menu is stored in a restaurant record that denotes the restaurant's city and neighborhood. [0013] In an alternative preferred embodiment, an accounting and transactional system for clearing all transactions related with the orders received by the restaurants may also be provided and linked to merchant account systems. Claim 15. The method of claim 13, wherein the vendor database comprises a database of restauranteurs, and the order is for food provided by at least one restauranteur. [0044] 4-Clear transactions: This sub application will be using for the supervisor to summarize all transactions in a segment of time in a select country, state, city and connecting to a merchant account system to begin to collect the revenues based on the information that the vendor have in the profile.) --network address details for each venue-associated POS system by which the server can communicate with same, and (see e. g. claim 13 --sending via a network interface at least one message to at least one vendor communication device according to the at least one vendor record corresponding to the at least one vendor, the at least one message including the order information for at least one of goods and services provided by the at least one vendor in the geographic area. --a location record corresponding to each physical customer location in each managed venue and containing the unique identifier of the associated physical identity target and identification of a venue-associated POS system affiliated with the customer location; [(see e. g. 0089] In this sample screen, will appear the stores related to your neighborhood, based on the information of the member. [0090] DESCRIPTION: Is the description of the store, basically the main activity in the category. [0091] NAME: The name of the store. [0092] ADRESS: The physical address of the vendor [0093] DESCRIPTION2: Additional information about the vendor. [0049] Description: This form is used by the APL Members. Basically the member can create and Modify information about the profile that they have on the system. The information is stored in the Member Database.---2 Exhibit B - FORM: APL_VENDORS: This application is used by the vendor to create/modify the profile on the system. B-General Information for Vendor: (1). Access Information 1. Vendor User: 2. Vendor Password: 3. Confirm password: (2) Vendor Store Information: 1. Vendor Store: 2. Manager (Complete Name): 3. Description Line of services: 4. Line 1 (optional) 5. Line 2 (optional) Vendor Store: Is the name of the company that want to deliver or bring services. Manager: Will be the name of the manager of the Store Description: Will be the kind of services or products that the Store carry out. Line 1/2: Are more detail information about the Store [0050] 3 (3) Location Information: 15. Country: 16. State: 17. City: 18. Neighborhoods: 19. Address: 20. Zip: 21. Telephone: 22. Fax: 23. General E-Mail: 24. Web site: 25. Additional Comments (optional) [0051] This is all the information related to the store. It is important that the name (identification) of the neighborhood be provided.) Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the various embodiments of MCGAUGH et al. include the structure taught by Bueno, in order to provide an on-line service that facilitates the creation of member records with specific profile, regardless of geographic location, permit on-line access to a restaurant database through a region locator (see e.g. [0010], [0003]). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to LUNA CHAMPAGNE whose telephone number is (571)272-7177. The examiner can normally be reached M-F 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, Florian Zeender can be reached at 571 272-6790. 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. /LUNA CHAMPAGNE/ Primary Examiner, Art Unit 3627 March 17, 2026
Read full office action

Prosecution Timeline

Aug 12, 2024
Application Filed
Mar 17, 2026
Non-Final Rejection — §101, §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12591846
MOBILE FULFILLMENT SYSTEM
2y 5m to grant Granted Mar 31, 2026
Patent 12572939
MULTI NODAL AUTHENTICATION TECHNOLOGY
2y 5m to grant Granted Mar 10, 2026
Patent 12555168
CHARGE-BACK/SHOW-BACK OPERATIONS USING DYNAMIC DATASETS IN A CONTENT-BASED DATA PROTECTION SYSTEM
2y 5m to grant Granted Feb 17, 2026
Patent 12548003
APPARATUS AND METHOD FOR FACILITATING NFC TRANSACTIONS WITHIN PAYMENT SLOT
2y 5m to grant Granted Feb 10, 2026
Patent 12524787
SYSTEMS AND METHODS FOR DETERMINING AN EVENT VALIDATION STATUS
2y 5m to grant Granted Jan 13, 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

1-2
Expected OA Rounds
46%
Grant Probability
80%
With Interview (+34.5%)
4y 0m
Median Time to Grant
Low
PTA Risk
Based on 585 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