Prosecution Insights
Last updated: April 19, 2026
Application No. 19/028,570

SYSTEMS AND METHODS FOR SMART CARD MOBILE DEVICE AUTHENTICATION

Non-Final OA §103§DP
Filed
Jan 17, 2025
Examiner
CASTILHO, EDUARDO D
Art Unit
3698
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Wells Fargo Bank N A
OA Round
1 (Non-Final)
47%
Grant Probability
Moderate
1-2
OA Rounds
3y 9m
To Grant
69%
With Interview

Examiner Intelligence

Grants 47% of resolved cases
47%
Career Allow Rate
135 granted / 289 resolved
-5.3% vs TC avg
Strong +22% interview lift
Without
With
+22.1%
Interview Lift
resolved cases with interview
Typical timeline
3y 9m
Avg Prosecution
32 currently pending
Career history
321
Total Applications
across all art units

Statute-Specific Performance

§101
23.4%
-16.6% vs TC avg
§103
32.7%
-7.3% vs TC avg
§102
10.8%
-29.2% vs TC avg
§112
29.0%
-11.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 289 resolved cases

Office Action

§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 . Information Disclosure Statement The Information Disclosure Statements filed 03/18/2025; 06/13/2025; 10/10/2025 and 01/06/2026 have been considered. Initialed copies of the forms PTO-1449 are enclosed herewith. Acknowledgements This Office Action is in response to the claims originally filed on 01/17/2025. Claims 9-16 were withdrawn. Claims 1-8 and 17-20 are pending. Claims 1-8 and 17-20 were examined. 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 1-8 and 17-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-7 of U.S. Patent No. US 12,288,206 B1. Examiner notes the scope of claims 17-20, directed to a non-transitory computer readable medium disclose the same inventive concept recited in method claims 1-4 of the current application. Although the claims at issue are not identical, they are not patentably distinct from each other because they represent a broader embodiment of the patented claims, as follows (Examiner notes claims 17-20 were omitted for brevity, and the overlapping language is indicated in bold font): Current Application19/028570 Patent US 12,288,206 B1 1. A method of authenticating a payment card, comprising: offering, by a circuit of a mobile device, a mobile pay function; establishing, by the circuit via a near-field communication (NFC) data connection, a wireless communication1 between the mobile device and a payment card; receiving, by the circuit via the wireless communication2, information of a first financial account associated with the payment card, wherein the first financial account is one of a plurality of financial accounts of a customer; receiving, by a contactless logic of the mobile device via the wireless communication, an authentication code from a contactless chip of the payment card, wherein the authentication code includes a cryptogram and non-cryptogram information, the non- cryptogram information including identifying customer information; transmitting, by the circuit to a computing system associated with an issuer of the payment card, a transaction request for a payment transaction, the transaction request including the identifying customer information, the account information, the authentication code, and a predefined payment amount, the predefined payment amount configured to indicate that the payment transaction is an authentication request; receiving, by the circuit at a first time, an authentication decision from the computing system based on the authentication request; in response to an approved authentication decision, enabling, by the circuit, (1) the payment card for use with the mobile pay function of the mobile device to conduct a transaction and (2) an additional financial operation on the mobile device without requiring additional authentication information, the additional financial operation involving at least one of the plurality of financial accounts of the customer; and performing, at a second time and based on the approved authentication decision received at the first time, the additional financial operation on the mobile device without requiring additional authentication information from the customer. 1. A method of authenticating a payment card for a mobile pay function of a mobile device, the method comprising: offering, by a mobile pay circuit of the mobile device, the mobile pay function; establishing, by the mobile pay circuit via a near-field communication (NFC) data connection, a wireless data handshake between the mobile device and the payment card; in response to a notification provided on the mobile device, receiving, by the mobile pay circuit via the NFC data connection between the mobile device and the payment card, account information of a first financial account including an account number of the payment card, wherein the first financial account is one of a plurality of financial accounts of a customer; wirelessly receiving, by a contactless logic of the mobile device via the NFC data connection between the mobile device and the payment card, an authentication code from a contactless chip of the payment card, wherein the authentication code includes a cryptogram and non-cryptogram information, the non-cryptogram information including identifying customer information; presenting, by the mobile pay circuit, a graphical user interface on a display of the mobile device, the graphical user interface including one or more fields; in response to routing the authentication code that includes the cryptogram and the non-cryptogram information to the mobile pay circuit, automatically populating, by the mobile pay circuit, the one or more fields of the graphical user interface with the received identifying customer information included in the non-cryptogram information; transmitting, by the mobile pay circuit, a transaction request for a payment transaction to a card issuer computing system associated with a card issuer of the payment card, the transaction request including the identifying customer information, the account information, the authentication code, and a predefined payment amount, the predefined payment amount configured to indicate that the payment transaction is an authentication request; receiving, by the mobile pay circuit at a first time, an authentication decision from the card issuer computing system based on the authentication request, the authentication decision including proxy payment card information; in response to an approved authentication decision, enabling, by the mobile pay circuit, (1) the payment card for use with the mobile pay function of the mobile device to conduct a transaction via the proxy payment card information and (2) an additional financial operation on the mobile device without requiring additional authentication information, the additional financial operation involving at least one of the plurality of financial accounts of the customer; and performing, at a second time and based on the approved authentication decision received at the first time, the additional financial operation on the mobile device without requiring additional authentication information from the customer. 2. The method of claim 1, wherein the additional financial operation is an operation to provide access to a user to financial information associated with the payment card, the financial information associated with the payment card including at least one of an account balance, an amount of available credit, or a payment due date. 5. The method of claim 1, wherein the additional financial operation is an operation to provide access to the user to financial information associated with the payment card, the financial information associated with the payment card including at least one of an account balance, an amount of available credit, or a payment due date. 3. The method of claim 1, wherein the additional financial operation is an operation to provide access to a user to a web page including financial information associated with the payment card, the financial information associated with the payment card including at least one of an account balance, an amount of available credit, or a payment due date. 6. The method of claim 1, wherein the additional financial operation is an operation to provide access to the user to a web page including financial information associated with the payment card, the financial information associated with the payment card including at least one of an account balance, an amount of available credit, or a payment due date. 4. The method of claim 1, wherein the additional financial operation is a second transaction involving a second financial account of the plurality of financial accounts, wherein the second financial account is a non-credit account. 7. The method of claim 1, wherein the additional financial operation is a second transaction involving a second financial account of the plurality of financial accounts, wherein the second financial account is a non-credit account. 5. The method of claim 1, wherein the predefined payment amount is $0.00 or $0.01. 2. The method of claim 1, wherein the predefined payment amount is $0.00 or $0.01. 6. The method of claim 1, wherein the payment card is one of a credit card or a debit card. 3. The method of claim 1, wherein the payment card is one of a credit card or a debit card. 7. The method of claim 1, further comprising: presenting, by the circuit of the mobile device, a graphical user interface on a display of the mobile device, the graphical user interface including one or more fields, wherein the graphical user interface includes an enabling trigger; and in response to enabling the payment card for use with the mobile pay function of the mobile device, permitting selection of the enabling trigger. 4. The method of claim 1, wherein the graphical user interface includes an enabling trigger, the method further comprising in response to enabling the payment card for use with the mobile pay function of the mobile device, permitting selection of the enabling trigger. 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-8 and 17-20 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Singh et al. (US 2013/0152185 A1), in view of Mullen et al. (US 2012/0286928 A1), and in view of EMV 4.3 Book 3 (NPL 2011). With respect to claims 1 and 17, Singh teaches a non-transitory computer readable medium having computer-executable instructions (see Fig. 9 (10), mobile wireless communications device 1000, processing device 1800, memories 1160, 1180 and paragraphs [0036]-[0047] ); and a method of authenticating a payment card (Transaction provisioning for mobile wireless communications devices and related methods) comprising: offering, by a circuit of a mobile device, a mobile pay function (see Fig. 2, controller 36, mobile wallet or electronic ("e-wallet") configuration, paragraph [0021]); establishing, by the circuit via a near-field communication (NFC) data connection, a wireless communication between the mobile device and a payment card (see Fig. 3, security token 32 and mobile device 34, paragraphs [0022] and [0023]; paragraph [0025]: "More particularly, the controller 36 may receive the first authentication data from the security token 32 via NFC communication between the first NFC device 33 and the second NFC device 35."); receiving, by the circuit via the wireless communication, information of a first financial account associated with the payment card, wherein the first financial account is one of a plurality of financial accounts of a customer (see PAN, paragraph [0011], Fig. 3, block 51, paragraph [0022]. See also paragraph [0025]: "More particularly, the controller 36 may receive the first authentication data from the security token 32 via NFC communication between the first NFC device 33 and the second NFC device 35."; Examiner notes this step is conducted after the notification displayed in Fig. 4, i.e. "New payment card detected. Add card to mobile wallet?" See also paragraph [0030]: "a GUI prompt inquiring whether this new credit card is to be added to the mobile wallet. For example, the mobile wallet may determine, based upon a PAN number of the security token 32, bank identification information, or other information stored on the security token 32 the type of credit card with which it is communicating."); receiving, by a contactless logic of the mobile device via the wireless communication, an authentication code from a contactless chip of the payment card, wherein the authentication code includes... non-cryptogram information, the non- cryptogram information including identifying customer information (see Fig. 6, paragraph [0032]: "The installed mobile wallet interface application for the XYZ credit card may then initiate an EMV payment verification transaction with the authentication server 31 to download a secure payment applet for the secure element 38 (see FIG. 6)"); transmitting, by the circuit to a computing system associated with an issuer of the payment card, a transaction request for a payment transaction, the transaction request including the identifying customer information, the account information, the authentication code, and a predefined payment amount, the predefined payment amount configured to indicate that the payment transaction is an authentication request (see paragraph [0032]: "The installed mobile wallet interface application for the XYZ credit card may then initiate an EMV payment verification transaction with the authentication server 31 to download a secure payment applet for the secure element 38 (see FIG. 6). For example, the EMV transaction may be for a nominal or designated amount (e.g., 1 cent), for example, although in some embodiments a transaction amount is not required. That is, the transaction may be designated as a special provisioning request (either by a designated transaction amount or otherwise) that will be recognized by the authentication server 31. The controller 36 receives the first authentication data and any other information typically provided by the security token 32 for payment transactions from the security token via NFC communication. "); receiving, by the circuit at a first time, an authentication decision from the computing system based on the authentication request (see paragraph [0028]: "As such, the authentication server 31 may provide, or cause a TSM to provide, second authentication data to the mobile device 34 that may be stored in the secure element 38 and used by the mobile device for requesting future transactions from the authentication server 31, at Blocks 53-54, which concludes the illustrated method (Block 55). That is, the mobile device 34 may then initiate future payment (or security, transportation, etc.) transactions as if it were the security token 32 itself (i.e., using the same account already associated with the security token). It should be noted that, while the security token 32 and the mobile device 34 may both be associated with a same account, they do not have to have identical numbers associated therewith (although they may be identical in some embodiments). For example, the security token 32 may have a first PAN associated therewith, and the mobile device 34 may have a second PAN associated therewith, but both the first and second PANs may be associated with a same account at the given financial institution (e.g., both PANs are linked with a same user, family, etc., account, for example)."); in response to an approved authentication decision, enabling, by the circuit, (1) the payment card for use with the mobile pay function of the mobile device to conduct a transaction… (see Fig. 7, paragraph [0035]: "[0035] Once the new XYZ VISA payment card is provisioned with the mobile wallet (see FIG. 7), a user may proceed to make a payment by selecting this card from the mobile wallet GUI and bringing the mobile device 34 within NFC communication range of an NFC-enabled point-of-sale (POS) terminal 61, as shown in FIG. 9. Here, the POS terminal 61 is associated with a merchant named Brown's Coffee Shop, and the mobile wallet displays a confirmation message via the GUI that a transaction for $10.75 from the XYZ Bank VISA account to Brown's Coffee Shop has been approved and completed by the authentication server 31. The POS terminal 61 and the authentication server 31 may communicate over the internet via a wired or wireless network, for example." see also paragraph [0028]: "the mobile device 34 may then initiate future payment (or security, transportation, etc.) transactions as if it were the security token 32 itself (i.e., using the same account already associated with the security token). It should be noted that, while the security token 32 and the mobile device 34 may both be associated with a same account, they do not have to have identical numbers associated therewith (although they may be identical in some embodiments). For example, the security token 32 may have a first PAN associated therewith, and the mobile device 34 may have a second PAN associated therewith, but both the first and second PANs may be associated with a same account at the given financial institution (e.g., both PANs are linked with a same user, family, etc., account, for example)"). Singh does not explicitly disclose a method and medium comprising: enabling… (2) an additional financial operation on the mobile device without requiring additional authentication information, the additional financial operation involving at least one of the plurality of financial accounts of the customer; and performing, at a second time and based on the approved authentication decision received at the first time, the additional financial operation on the mobile device without requiring additional authentication information from the customer. wherein the authentication code (i.e. EMV Data) includes a cryptogram. However, Mullen discloses a method and medium (Systems and methods for mobile authorizations) comprising: enabling… (2) an additional financial operation on the mobile device without requiring additional authentication information, the additional financial operation involving at least one of the plurality of financial accounts of the customer (see paragraph [0011]: “Any function may, for example, be authorized to be performed by a processor of a mobile device. Accordingly, for example, any decision to perform a function by a mobile device may be authorized by a processor of the mobile device. In so doing, for example, any function (e.g., checking a balance of a banking account or transitioning from paper bank statements to e-statements) that may be performed by a processor of a mobile device may be authorized by the processor upon verification that security credentials (e.g., a bank account number) communicated to the processor from a contactless communication device (e.g., a bank card associated with the bank account) matches at least a portion of security credentials (e.g., banking information) that may be stored within a memory of the mobile device.”; paragraph [0085]: “Banking functions performed by a mobile device may, for example, be authorized as defined by options 904. A mobile device may, for example, be equipped with scanning capability, such that biometrics (e.g., fingerprints) may be taken from the user of the mobile device and verified before banking functions may be authorized. As per another example, a dynamic security code communicated to a processor of a mobile device by a powered payment card via a contactless communication channel may authorize banking functions to be performed by the mobile device.”); and performing, at a second time and based on the approved authentication decision received at the first time, the additional financial operation on the mobile device without requiring additional authentication information from the customer (see remote server authorization, Fig. 10, paragraph [0091]: “In step 1041 of sequence 1040, a user of a mobile device may request a function to be performed by a mobile device. Upon receipt of security credentials communicated by a contactless communication device to a processor of the mobile device (e.g., as in step 1042), the security credentials may be forwarded (e.g., as in step 1043) to a remote authorization server for verification. In step 1044, the remote authorization server may communicate a message to a processor of the mobile device to either grant or deny authorization for the mobile device to perform the requested function.”; ). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the additional financial operation as disclosed by Mullen in the method and medium of Singh, the motivation being to allow any function to be authorized to be performed by a processor of a mobile device (see Mullen, paragraph [0011]). Although Singh discloses that challenge-response data may be generated by the security token 32 using a cryptographic key, from which the authentication server may verify that the security token 32 is valid (see paragraph [0018]), the combination of Singh and Mullen does not explicitly disclose a method and medium comprising: wherein the authentication code (i.e. EMV Data) includes a cryptogram. While this language represents non-functional descriptive material and is therefore not given patentable weight, this difference is insufficient to distinguish the claims over Singh However, in the interest of compact prosecution and assuming weight was to be given to the non-functional descriptive material recitations above, EMV 4.3 Book 3 discloses a method and medium (EMV Integrated Circuit Card Specifications for Payment Systems) comprising: wherein the authentication code (i.e. EMV Data) includes a cryptogram (see page 54. Generate Application Cryptogram Command-Response APDUs; page 56: "Format 2: The data object returned in the response message is a constructed data object with tag equal to '77'. The value field may contain several BERTLV coded objects, but shall always include the Cryptogram Information Data, the Application Transaction Counter, and the cryptogram computed by the ICC (either an AC or a proprietary cryptogram)"). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the details of EMV challenge-response data as disclosed by EMV 4.3 Book 3 in the method and medium of Singh and Mullen, the motivation being to comply with the structure of the command and response messages according to ISO/IEC 7816-4, and the coding of the messages, which is defined within the context of these specifications by the EMV specifications in order to verify that the card is valid (see EMV 4.3 Book 3, page 42). With respect to claims 2 and 18, the combination of Singh, Mullen and EMV 4.3 Book 3 teaches all the subject matter of the method and medium as described above with respect to claims 1 and 17. Furthermore, Mullen disclose a method and medium wherein the additional financial operation is an operation to provide access to a user to financial information associated with the payment card, the financial information associated with the payment card including at least one of an account balance, an amount of available credit, or a payment due date (see checking a balance of a banking account, paragraph [0011]). Regarding the BRI of the claims, Examiner notes that claims 2 and 18 recite “wherein the additional financial operation is an operation to provide access to a user to financial information associated with the payment card, the financial information associated with the payment card including at least one of an account balance, an amount of available credit, or a payment due date”, language directed to non-functional descriptive material. See MPEP 2111.05. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims. With respect to claims 3 and 19, the combination of Singh, Mullen and EMV 4.3 Book 3 teaches all the subject matter of the method and medium as described above with respect to claims 1 and 17. Furthermore, Mullen disclose a method and medium wherein the additional financial operation is an operation to provide access to a user to a web page including financial information associated with the payment card, the financial information associated with the payment card including at least one of an account balance, an amount of available credit, or a payment due date (see checking a balance of a banking account, paragraph [0011]). Regarding the BRI of the claims, Examiner notes that claims 3 and 19 recite “wherein the additional financial operation is an operation to provide access to a user to a web page including financial information associated with the payment card, the financial information associated with the payment card including at least one of an account balance, an amount of available credit, or a payment due date”, language directed to non-functional descriptive material. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims. With respect to claims 4 and 20, the combination of Singh, Mullen and EMV 4.3 Book 3 teaches all the subject matter of the method and medium as described above with respect to claims 1 and 17. Furthermore, Mullen disclose a method and medium wherein the additional financial operation is a second transaction involving a second financial account of the plurality of financial accounts, wherein the second financial account is a non-credit account (see Fig. 5, virtual card, paragraph [0072]: “FIG. 5 shows GUI 500, that may be generated by a processor of a mobile device and provided onto a display of the mobile device. GUI 500 may, for example, allow a selection of a virtual card contained within a memory of a mobile device to be authorized for use by its physical counterpart. Accordingly, for example, a user may touch anywhere within the vicinity of virtual card 504 as it is being displayed by GUI 500. Such a selection may be verified by highlighting attributes of a selected card (e.g., highlighting an outline of virtual card 504) and by displaying the selected virtual card within verification region 502. In so doing, for example, a user of a mobile device may view a virtual card that is selected for authorization (e.g., as viewed within region 502) so that the user may retrieve the physical card that corresponds to the virtual card that is to be authorized.”; paragraph [0089]: “A memory of a mobile device may, for example, contain a number of virtual cards that may correspond to information communicated to a processor of the mobile device via physical card counterparts to the virtual cards. Such virtual cards may, for example, be selected (e.g., as in step 1021 of sequence 1020) to perform a function in conjunction with the mobile device (e.g., payment information associated with a virtual payment card may be selected to complete a purchase transaction using the mobile device)"). Regarding the BRI of the claims, Examiner notes that claims 4 and 20 recite “wherein the additional financial operation is a second transaction involving a second financial account of the plurality of financial accounts, wherein the second financial account is a non-credit account”, language directed to non-functional descriptive material. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims. With respect to claim 5, the combination of Singh, Mullen and EMV 4.3 Book 3 teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Singh discloses a method wherein the predefined payment amount is $0.00 or $0.01 (see paragraph [0032]: "For example, the EMV transaction may be for a nominal or designated amount (e.g., 1 cent), for example, although in some embodiments a transaction amount is not required." Examiner notes $0.00 is the default amount when an amount is not required.). Regarding the BRI of the claim, Examiner notes that claim 5 recites “wherein the predefined payment amount is $0.00 or $0.01.”, language directed to non-functional descriptive material. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims. With respect to claim 6, the combination of Singh, Mullen and EMV 4.3 Book 3 teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Singh discloses a method wherein the payment card is one of a credit card or a debit card (see Fig. 2, security token 33, paragraph [0012]: "One example security token may comprise an Integrated Circuit Card (ICC). Other example security token embodiments may comprise a credit card, a debit card, etc."; ; paragraph [0018]: "the security token 32 may be a credit or debit card issued by the bank or financial institution and associated with the account"). Regarding the BRI of the claim, Examiner notes that claim 6 recites “wherein the payment card is one of a credit card or a debit card”, language directed to non-functional descriptive material. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims. With respect to claim 7, the combination of Singh, Mullen and EMV 4.3 Book 3 teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Singh disclose a method further comprising: presenting, by the circuit of the mobile device, a graphical user interface on a display of the mobile device, the graphical user interface including one or more fields, wherein the graphical user interface includes an enabling trigger; and in response to enabling the payment card for use with the mobile pay function of the mobile device, permitting selection of the enabling trigger (see Figs. 7 and 8, card selection "ABC Mastercard" and "XYZ Visa" and paragraph [0035]: Once the new XYZ VISA payment card is provisioned with the mobile wallet (see FIG. 7), a user may proceed to make a payment by selecting this card from the mobile wallet GUI and bringing the mobile device 34 within NFC communication range of an NFC-enabled point-of-sale (POS) terminal 61, as shown in FIG. 9." Examiner notes that Fig. 9 is omitted from US 2013/0152185 A1 but is found in US Patent US 8,918,855B2, and is herein provided: PNG media_image1.png 484 780 media_image1.png Greyscale The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims. With respect to claim 8, the combination of Singh, Mullen and EMV 4.3 Book 3 teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Singh disclose a method further comprising: automatically populating one or more fields of a graphical user interface displayed by the mobile device with the received identifying customer information (see Fig. 8, GUI populating ABC Mastercard, XYZ Visa, paragraph [0035]: "Once the new XYZ VISA payment card is provisioned with the mobile wallet (see FIG. 7), a user may proceed to make a payment by selecting this card from the mobile wallet GUI and bringing the mobile device 34 within NFC communication range of an NFC-enabled point-of-sale (POS) terminal 61, as shown in FIG. 9"). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDUARDO D CASTILHO whose telephone number is (571)270-1592. The examiner can normally be reached Mon-Fri 8-5. 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, Patrick McAtee can be reached at (571) 272-7575. 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. /EDUARDO CASTILHO/Primary Examiner, Art Unit 3698 1 Examiner notes that a wireless data handshake is a narrow sub step of a wireless communication. 2 Examiner notes that an NFC data connection is a narrower type of wireless communication
Read full office action

Prosecution Timeline

Jan 17, 2025
Application Filed
Mar 02, 2026
Non-Final Rejection — §103, §DP (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12602699
Method for authenticating and anti-counterfeiting coffee machines or coffee grinders
2y 5m to grant Granted Apr 14, 2026
Patent 12567076
ELECTRONIC PAYMENT NETWORK SECURITY
2y 5m to grant Granted Mar 03, 2026
Patent 12561690
CONTACTLESS ACCESS TO SERVICE DEVICES TO FACILITATE SECURE TRANSACTIONS
2y 5m to grant Granted Feb 24, 2026
Patent 12536526
PAPERLESS TICKET MANAGEMENT SERVICE
2y 5m to grant Granted Jan 27, 2026
Patent 12536538
Method and System for Payment Device-Based Access
2y 5m to grant Granted Jan 27, 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
47%
Grant Probability
69%
With Interview (+22.1%)
3y 9m
Median Time to Grant
Low
PTA Risk
Based on 289 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