Prosecution Insights
Last updated: April 17, 2026
Application No. 18/909,316

CARD PAYMENT SYSTEM AND METHOD HAVING FUNCTION OF IDENTIFYING LOCATION OF USE OF CARD REGISTERED IN DEDICATED APPLICATION AND LOCATION OF DEDICATED APPLICATION

Non-Final OA §101§103
Filed
Oct 08, 2024
Examiner
MASUD, ROKIB
Art Unit
3627
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
unknown
OA Round
1 (Non-Final)
68%
Grant Probability
Favorable
1-2
OA Rounds
3y 5m
To Grant
69%
With Interview

Examiner Intelligence

Grants 68% — above average
68%
Career Allow Rate
503 granted / 735 resolved
+16.4% vs TC avg
Minimal +0% lift
Without
With
+0.2%
Interview Lift
resolved cases with interview
Typical timeline
3y 5m
Avg Prosecution
34 currently pending
Career history
769
Total Applications
across all art units

Statute-Specific Performance

§101
30.5%
-9.5% vs TC avg
§103
46.8%
+6.8% vs TC avg
§102
14.3%
-25.7% vs TC avg
§112
4.8%
-35.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 735 resolved cases

Office Action

§101 §103
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 4–7 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (an abstract idea) without significantly more. Under the 35 U.S.C. §101 subject matter eligibility two-part analysis, Step 1 addresses whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. See MPEP §2106.03. If the claim does fall within one of the statutory categories, it must then be determined in Step 2A [prong 1] whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea). See MPEP §2106.04. If the claim is directed toward a judicial exception, it must then be determined in Step 2A [prong 2] whether the judicial exception is integrated into a practical application. See MPEP §2106.04(d). Finally, if the judicial exception is not integrated into a practical application, it must additionally be determined in Step 2B whether the claim recites "significantly more" than the abstract idea. See MPEP §2106.05. Examiner note: The Office's 2019 Revised Patent Subject Matter Eligibility Guidance (2019 PEG) is currently found in the Ninth Edition, Revision 10.2019 (revised June 2020) of the Manual of Patent Examination Procedure (MPEP), specifically incorporated in MPEP §2106.03 through MPEP §2106.07(c). Step 1 (Statutory Category) Claims 4–7 are drawn to a process, which is a statutory category of invention under 35 U.S.C. 101. However, these claims must also be evaluated for judicial exceptions under Step 2A and Step 2B of the eligibility analysis. Step 2A — Prong One Claims 4–7 recite steps that constitute commercial interactions involving payment authorization and fraud checking, which fall within the abstract idea category of certain methods of organizing human activity. For example, claim 4 recites limitations including: attempting to execute payment at an online affiliated store, logging into a dedicated application, transmitting IP address information and a payment request, recognizing and analyzing location information of a user terminal and a place where online payment is requested, determining whether the two pieces of location information exist in a set identification area, approving payment or blocking payment. These steps describe the concept of evaluating payment transaction information and location data to determine whether a payment should be authorized, which is analogous to longstanding commercial practices of verifying transactions to detect fraud. Similarly, claim 5 recites limitations including: attempting to execute payment at an online affiliated store by inputting a card number, transmitting a payment request, forwarding IP address information, analyzing transaction location information, approving or blocking payment based on location comparison. These steps likewise describe collecting and evaluating transaction information in order to authorize or deny a commercial transaction, which is a fundamental economic practice. Claim 6 further recites variations in the routing of transaction data between merchant systems, bank servers, and a central server. These limitations merely specify alternative arrangements for transmitting transaction information during payment authorization and therefore continue to recite the same abstract idea of payment authorization and fraud detection. Claim 7 recites additional steps including: requesting registration of a card through a dedicated application, transmitting the registration request to a bank/card company server, completing registration of the card, providing a pop-up notification, activating a card location identification function. These steps describe managing registration and activation of payment credentials and security features, which are also part of commercial transaction management and payment authentication, another example of a method of organizing human activity. Accordingly, claims 4–7 recite the abstract idea of processing payment transactions and determining whether to authorize the transaction based on location information, which is a form of commercial interaction and fraud prevention. Step 2A — Prong Two These claims do not integrate the abstract idea into a practical application. The additional elements recited in these claims include: user terminal, online affiliated store server, central server, bank/card company server, dedicated application, transmitting information, recognizing and analyzing location information, blocking or approving payment. These elements merely describe generic computer components performing generic computer functions, such as: receiving information, transmitting information, analyzing information, making a decision based on the information The specification does not indicate that the claimed servers, terminals, or applications are anything other than conventional computer components performing their ordinary functions. Further, these claims do not: improve the functioning of a computer itself, improve another technology or technical field, apply the abstract idea with a particular machine in a meaningful way, effect a transformation of an article to a different state or thing. Instead, these claims merely use generic computing components as tools to perform the abstract idea of verifying payment transactions using location information. Therefore, these claims do not integrate the abstract idea into a practical application. Step 2B These claims also do not include additional elements that amount to significantly more than the abstract idea. The additional elements recited in these claims—such as servers, terminals, and software applications used to transmit and analyze payment information—are well-understood, routine, and conventional activities previously known in the field of electronic payment processing. For example: transmitting payment requests between merchant systems and payment servers, collecting transaction information such as IP address data, analyzing transaction information to detect potential fraud, approving or blocking payment transactions are conventional activities widely used in payment processing systems. The ordered combination of these elements also does not amount to significantly more than the abstract idea, because the steps merely describe a generic sequence of collecting information, analyzing information, and making a payment authorization decision. Such activities represent routine data processing using generic computer technology, which does not constitute an inventive concept under Alice Corp. v. CLS Bank International, 573 U.S. 208 (2014). Accordingly, claims 4–7 are directed to an abstract idea without significantly more and are therefore not patent eligible under 35 U.S.C. 101. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 1–12 are rejected under 35 U.S.C. 103 as being unpatentable over Ranganathan (US20120209773A1), in view of Meredith et al. (US20160171499A1, hereinafter Meredith). With respect to claim 1, Ranganathan discloses a card payment system including a user terminal configured to perform card transactions, wherein a mobile device associated with a user performs payment or transaction authentication (see for example paragraphs [0018], [0022], and [0036] and Fig. 1); a user terminal configured to purchase an object or service online or offline by the card (see for example paragraphs [0022], [0042], and Fig. 2); an affiliated store POS device configured to sell the object and service offline and forward location information and a card payment approval request (see for example paragraphs [0030], [0035], and Fig. 3); a central server configured to forward card payment related requests and perform identification area recognition for location information of the POS device and the user terminal (see for example paragraphs [0037], [0040], [0043], and Fig. 3). a POS server configured to transmit location information and a card payment request to a bank/card company server or the central server (see for example paragraphs [0028] and [0033]). a bank/card company server configured to determine whether to approve payment and notify the POS server (see for example paragraphs [0032] and [0038]). a dedicated application configured to provide a card location identification function through the user terminal (see for example paragraphs [0041], [0044], and Fig. 2). Ranganathan does not explicitly disclose the feature of an online affiliated store configured to sell the object and service online and transmit IP address information and a payment approval request and an online affiliated store server configured to forward IP address information and card payment requests. However, Meredith teaches the feature of an online affiliated store configured to sell the object and service online and transmit IP address information and a payment approval request (see for example paragraphs [0045], [0049], and Fig. 4); and an online affiliated store server configured to forward IP address information and card payment requests (see for example paragraphs [0048] and [0052]). Therefore it would have been obvious to a person having ordinary skill in the art at the time of the invention to combine the teachings of Ranganathan with Meredith because Meredith teaches improving payment fraud detection by incorporating additional location-related data such as IP address information associated with online merchants and transaction requests (see for example paragraphs [0045]–[0050]). A person of ordinary skill in the art would have been motivated to integrate the IP-based transaction verification techniques of Meredith with the mobile device location verification system of Ranganathan in order to increase the reliability of transaction authentication and reduce fraudulent transactions in both online and offline payment environments. Combining these references would have been a predictable use of prior art elements according to their established functions. With respect to claim 2, Ranganathan discloses a card payment method having a function of identifying a location of use of a card and a location (see for example paragraphs [0022], [0036], and Fig. 1): transmitting a card payment approval request from an affiliated store POS device to a POS server when payment is executed using the card for which a card location identification function is activated (see for example paragraphs [0028], [0030], and Fig. 3); forwarding the card payment approval request from the POS server to a bank/card company server and simultaneously transmitting information of the card, transaction details, and location information of the affiliated store POS device (see for example paragraphs [0032], [0035], and [0037]); transmitting the location information of the affiliated store POS device to a central server after the bank/card company server recognizes a payment request (see for example paragraphs [0035], [0037], and Fig. 3); performing, by the central server, identification area recognition for the location information of the POS device and location information of a user terminal to determine whether to approve payment (see for example paragraphs [0039], [0040], [0042], and Fig. 3). transmitting, when the central server recognizes that the two pieces of location information exist together in a set identification area, payment approval information of a user to the bank/card company server after transaction detail recognition and final payment request approval are executed through the dedicated application (see for example paragraphs [0041], [0043], and Fig. 2); performing card validity verification and payment request approval and transmitting a payment completion signal by the bank/card company server to the POS server and the central server to complete card payment (see for example paragraphs [0038] and [0041]). Ranganathan does not disclose the feature of blocking payment when the central server recognizes that the two pieces of location information do not exist together in the set identification area. However, Meredith teaches the feature of blocking payment when the central server recognizes that the two pieces of location information do not exist together in the set identification area (see for example paragraphs [0052], [0053], and [0056]). Therefore it would have been obvious to a person having ordinary skill in the art at the time of the invention to combine the teachings of Ranganathan with Meredith because Meredith teaches improving payment fraud detection by incorporating additional location-related data such as IP address information associated with online merchants and transaction requests (see for example paragraphs [0045]–[0050]). A person of ordinary skill in the art would have been motivated to integrate the IP-based transaction verification techniques of Meredith with the mobile device location verification system of Ranganathan in order to increase the reliability of transaction authentication and reduce fraudulent transactions. With respect to claim 3, Ranganathan discloses a card payment method having a function of identifying a location of use of a card registered in a dedicated application and a location of the dedicated application (see for example paragraphs [0030], [0035], and Fig. 3): transmitting information of the card and location information of an affiliated store POS device from the affiliated store POS device to a central server when payment is executed using the card (see for example paragraphs [0032], [0035], and Fig. 3); performing, by the central server, identification area recognition for the location information of the POS device and location information of a user terminal to determine whether to approve payment (see for example paragraphs [0039], [0040], [0043], and Fig. 3). transmitting, when the central server recognizes that the two pieces of location information exist together in a set identification area, payment approval information of a user to a bank/card company server after transaction detail recognition and final payment request approval are executed through the dedicated application (see for example paragraphs [0041], [0044], and Fig. 2); performing card validity verification and payment request approval and forwarding a payment completion signal by the bank/card company server to the central server and transmitting the payment completion signal from the central server to the POS server and the dedicated application to complete card payment (see for example paragraphs [0038] and [0041]). Ranganathan does not disclose the feature of blocking payment when the central server recognizes that the two pieces of location information do not exist together in the set identification area. However, Meredith teaches the feature of blocking payment when the central server recognizes that the two pieces of location information do not exist together in the set identification area (see for example paragraphs [0052], [0053], and [0056]). Therefore it would have been obvious to a person having ordinary skill in the art at the time of the invention to combine the teachings of Ranganathan with Meredith because Meredith teaches improving payment fraud detection by incorporating additional location-related data such as IP address information associated with online merchants and transaction requests (see for example paragraphs [0045]–[0050]). A person of ordinary skill in the art would have been motivated to integrate the IP-based transaction verification techniques of Meredith with the mobile device location verification system of Ranganathan in order to increase the reliability of transaction authentication and reduce fraudulent transactions. With respect to claim 4, Ranganathan discloses a card payment method having a function of identifying a location of use of a card registered in a dedicated application and a location of the dedicated application (see for example paragraphs [0022], [0036], and Fig. 1): attempting to execute payment at an online affiliated store by selecting, as a payment means, the dedicated application in which the card for which a card location identification function is activated is registered (see for example paragraphs [0022], [0026], and Fig. 2); logging into the dedicated application and transmitting IP address information and a payment request from an online affiliated store server to a central server (see for example paragraphs [0045], [0048], [0049], and Fig. 4); recognizing and analyzing, through identification area recognition by the central server, location information of a user terminal and location information of a place where online payment is requested (see for example paragraphs [0039], [0040], [0042], and Fig. 3); transmitting, when the central server recognizes that the two pieces of location information exist correctly in a set identification area, payment approval information of a user to a bank/card company server after transaction detail recognition and final payment request approval are executed through the dedicated application (see for example paragraphs [0041], [0043], and Fig. 2); performing card validity verification and payment request approval and transmitting a payment completion signal by the bank/card company server to the online affiliated store server and the central server to complete card payment (see for example paragraphs [0038] and [0041]). Ranganathan does not disclose the feature of discloses determining the geographic location of an online transaction using IP address information associated with the transaction session and blocking payment when the central server recognizes that the two pieces of location information do not exist in the set identification area. However, Meredith teaches the feature of determining the geographic location of an online transaction using IP address information associated with the transaction session (see for example paragraphs [0048] and [0050]); and blocking payment when the central server recognizes that the two pieces of location information do not exist in the set identification area (see for example paragraphs [0052]–[0056]). Therefore it would have been obvious to a person having ordinary skill in the art at the time of the invention to combine the teachings of Ranganathan with Meredith because Meredith teaches improving payment fraud detection by incorporating additional location-related data such as IP address information associated with online merchants and transaction requests (see for example paragraphs [0045]–[0050]). A person of ordinary skill in the art would have been motivated to integrate the IP-based transaction verification techniques of Meredith with the mobile device location verification system of Ranganathan in order to increase the reliability of transaction authentication and reduce fraudulent transactions. With respect to claim 5, Ranganathan discloses a card payment method having a function of identifying a location of use of a card registered in a dedicated application and a location of the dedicated application (see for example paragraphs [0022], [0036], and Fig. 1): recognizing and analyzing, through identification area recognition by the central server, location information of a user terminal and location information of a place where online payment is requested (see for example paragraphs [0039], [0040], and Fig. 3). Ranganathan does not explicitly disclose the feature of deriving transaction location information from IP address data associated with the online payment request, transmitting, when the central server recognizes that the two pieces of location information exist correctly in a set identification area, payment approval information of a user to the bank/card company server after transaction detail recognition and final payment request approval are executed through the dedicated application, performing card validity verification and payment request approval and transmitting a payment completion signal by the bank/card company server to the online affiliated store server and the central server to complete card payment, attempting to execute payment at an online affiliated store by selecting, as a payment means, input of a card number of the card for which a card location identification function is activated; transmitting a card payment approval request from the online affiliated store to an online affiliated store server; transmitting IP address information and a payment request from the online affiliated store server to a bank/card company server; forwarding the IP address information from the bank/card company server to a central server and blocking payment when the central server recognizes that the two pieces of location information do not exist in the set identification area. However, Meredith teaches the feature of deriving transaction location information from IP address data associated with the online payment request (see for example paragraphs [0048] and [0050]); transmitting, when the central server recognizes that the two pieces of location information exist correctly in a set identification area, payment approval information of a user to the bank/card company server after transaction detail recognition and final payment request approval are executed through the dedicated application (see for example paragraphs [0041], [0044], and Fig. 2); performing card validity verification and payment request approval and transmitting a payment completion signal by the bank/card company server to the online affiliated store server and the central server to complete card payment (see for example paragraphs [0038] and [0041]). attempting to execute payment at an online affiliated store by selecting, as a payment means, input of a card number of the card for which a card location identification function is activated (see for example paragraphs [0043] and [0045]); transmitting a card payment approval request from the online affiliated store to an online affiliated store server (see for example paragraphs [0045] and [0047]); transmitting IP address information and a payment request from the online affiliated store server to a bank/card company server (see for example paragraphs [0048] and [0049]); forwarding the IP address information from the bank/card company server to a central server (see for example paragraphs [0050] and [0051]); blocking payment when the central server recognizes that the two pieces of location information do not exist in the set identification area (see for example paragraphs [0052]–[0056]). Therefore it would have been obvious to a person having ordinary skill in the art to combine the teachings of Ranganathan and Meredith in order to improve security and fraud detection for online card transactions. Ranganathan teaches verifying transactions using the location of a mobile device associated with the cardholder, while Meredith teaches determining the geographic location of an online transaction using IP address information and blocking transactions when inconsistencies are detected. Combining these teachings would have yielded a system capable of evaluating both mobile device location and IP-based transaction location information when determining whether to approve or block a payment transaction, which represents a predictable use of known fraud detection techniques in payment processing systems. With respect to claim 6, Ranganathan discloses subsequent transaction wherein the remaining steps are the same (see for example paragraphs [0039], [0040], and [0043]). Ranganathan does not disclose the feature of in an online card payment manner in which the online affiliated store having the function of identifying the location of use of the card registered in the dedicated application inputs the card number for payment, transmitting the IP address information and the payment request from the online affiliated store server to the central server, However, Meredith teaches the feature of in an online card payment manner in which the online affiliated store having the function of identifying the location of use of the card registered in the dedicated application inputs the card number for payment (see for example paragraphs [0043] and [0045]); transmitting the IP address information and the payment request from the online affiliated store server to the central server (see for example paragraphs [0048], [0049], and [0050]); wherein forwarding of the IP address information from the bank/card company server to the central server is excluded (see for example paragraphs [0049] and [0051]). With respect to claim 7, Ranganathan further discloses registering a payment card through a mobile payment application associated with a user device (see for example paragraphs [0022], [0026], and Fig. 2); making a request for registration of the card through the dedicated application installed on the user terminal (see for example paragraphs [0022] and [0026]); transmitting the request for registration of the card from the central server to the bank/card company server and approving the request (see for example paragraphs [0032] and [0035]). completing registration of the card in the central server (see for example paragraphs [0035] and [0037]); providing a pop-up notification indicating operation of the card location identification function on a screen of the user terminal (see for example paragraphs [0041] and [0044]); activating the card location identification function for the card through the dedicated application (see for example paragraphs [0022], [0041], and Fig. 2). With respect to claim 8, Ranganathan further discloses a method wherein the location information of the user terminal includes location information of any type of terminal that is identified through GPS and is running the dedicated application available for payment and E-commerce (see for example paragraphs [0022], [0041], and Fig. 2), and includes location information for determining the location of use of the card registered in the dedicated application (see for example paragraphs [0039], [0042], and [0043]). With respect to claim 9, Ranganathan further discloses a method, when payment is executed through the affiliated store POS device by the card registered in the dedicated application, the central server compares the location information of the user terminal and the location information of the affiliated store POS device (see for example paragraphs [0039] and [0043]); allowing payment within a set identification area or blocking payment outside the set identification area (see for example paragraphs [0042] and [0043]); With respect to the limitation concerning online payment transactions, Meredith discloses determining the location of an online transaction using IP address information and comparing that information with other location indicators associated with the cardholder or device to detect fraud (see for example paragraphs [0048], [0050], and [0052]). With respect to claim 10, Meredith discloses analyzing IP address information associated with an online transaction in order to determine the geographic location of the transaction and identify potential fraud (see for example paragraphs [0048], [0050], and Fig. 4); blocking payment when the central server recognizes that the location information of the place where online payment is requested is unrelated to an IP address of the online affiliated store or is an illegal place (see for example paragraphs [0052] and [0054]); Meredith further discloses identifying high-risk or suspicious transaction locations based on IP address analysis and other fraud detection rules (see for example paragraphs [0055] and [0056]). With respect to claim 11, Ranganathan discloses mobile payment applications and the card location identification function and a monitoring function are able to be turned off (see for example paragraphs [0022] and [0041]); payment request details are received through the dedicated application and transaction detail recognition is performed (see for example paragraphs [0041] and [0043]); final payment request approval is executed using various approval methods (see for example paragraphs [0041] and [0044]). With respect to claim 12, Meredith further discloses a method wherein through a separate location identification system server connected to a central server, the card is registered and communication for location information is performed (see for example paragraphs [0050] and [0051]); the location identification system server performs analyzing of the location information and identification area recognition (see for example paragraphs [0052] and [0054]). the central server performs only the remaining function of forwarding card payment-related requests and approvals (see for example paragraphs [0050]–[0052]). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROKIB MASUD whose telephone number is (571)270-5390. The examiner can normally be reached Mon-Fri 8:00-5:00. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Fahd Obeid can be reached at 571-270-3324. 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. /ROKIB MASUD/Primary Examiner, Art Unit 3627
Read full office action

Prosecution Timeline

Oct 08, 2024
Application Filed
Mar 07, 2026
Non-Final Rejection — §101, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12597077
Procure to Pay Deduction Management Process
2y 5m to grant Granted Apr 07, 2026
Patent 12555070
RFID KANBAN SYSTEM AND METHODS OF USE
2y 5m to grant Granted Feb 17, 2026
Patent 12555169
CREDIT ELIGIBILITY PREDICTOR
2y 5m to grant Granted Feb 17, 2026
Patent 12524753
Payment Device and Method with Detection of Falsified Payee Information Based on Weighted Location Data Obtained by the Payment Device
2y 5m to grant Granted Jan 13, 2026
Patent 12524818
OPT-IN DISTRIBUTED LEDGER CONSORTIUM
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
68%
Grant Probability
69%
With Interview (+0.2%)
3y 5m
Median Time to Grant
Low
PTA Risk
Based on 735 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in for Full Analysis

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

Free tier: 3 strategy analyses per month