Prosecution Insights
Last updated: July 17, 2026
Application No. 18/919,031

SYSTEMS AND METHODS FOR USER AUTHENTICATION VIA A SUBSEQUENT AUTHENTICATION ON SOFTWARE APPLICATION

Final Rejection §103
Filed
Oct 17, 2024
Priority
Oct 20, 2023 — provisional 63/545,123
Examiner
IDIAKE, VINCENT I
Art Unit
3698
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Capital One Services LLC
OA Round
2 (Final)
71%
Grant Probability
Favorable
3-4
OA Rounds
1y 1m
Est. Remaining
92%
With Interview

Examiner Intelligence

Grants 71% — above average
71%
Career Allowance Rate
115 granted / 161 resolved
+19.4% vs TC avg
Strong +20% interview lift
Without
With
+20.3%
Interview Lift
resolved cases with interview
Typical timeline
2y 10m
Avg Prosecution
16 currently pending
Career history
189
Total Applications
across all art units

Statute-Specific Performance

§101
5.1%
-34.9% vs TC avg
§103
75.1%
+35.1% vs TC avg
§102
5.7%
-34.3% vs TC avg
§112
8.2%
-31.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 161 resolved cases

Office Action

§103
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 . DETAILED CORRESPONDENCE Acknowledgements The Amendment of claims 1, 5, 7, 10-12, 16 and 20, filed on 03/17/2026 is acknowledged. Claims 1-20 are currently pending and have been addressed below. Examiner’s Response to Amendment/Remarks The amendment to claims 7, 10 and 16 has overcome the 112 rejections in the previous Office Action, mailed out on 10/17/2025, therefore, the 112 rejection is hereby withdrawn. Applicant’s amendment/remarks filed on 03/17/2026 is acknowledged, and the arguments have been found not persuasive, by the Examiner. Applicants extensively argued that about the placement of the devices mostly with prior art Martin. On page 11-12 of the response filed on 03/17/2026, [Applicant submits that Martin and Li do not teach or suggest all features of claims 1-4, 6-17, 19, and 20. For example, in the rejection of claim 1 with reference to the limitation "receiving, by an administrator processor from a user device, a user datum," the Non-Final Office Action mapped the claimed administrator processor to the issuing bank server 160 (the shopper registration service 161) of Martin. Non-Final Office Action at pages 4-5. However, in the rejection of a different limitation of claim 1, "transmitting, by the administrator processor to each of a plurality of account processing systems, the encrypted user datum, wherein each account processing system is associated with a different account provider and has been provisioned with user datum encryption information," the Non-Final Office Action mapped the claimed administrator processor to the application server 150 (the payment method linking application 151) of Martin. Non- Final Office Action at pages 5-6. Applicant submits that the issuing bank server 160 (the shopper registration service 161) of Martin is different from the application server 150 (the payment method linking application 151) of Martin. Accordingly, Applicant submits that these mappings are inconsistent]. Examiner respectfully disagrees with this characterization, because according to the Applicant’s specification ¶ 0038 “The administrator processor 150 may be a network-enabled computer device. Exemplary network-enabled computer devices include, without limitation, a server, a network appliance, a personal computer, a workstation, a phone, a handheld personal computer, a personal digital assistant, a thin client, a fat client, an Internet browser, a mobile device, a kiosk, or other a computer device or communications device. For example, network-enabled computer devices may include an iPhone, iPod, iPad from Apple® or any other mobile device running Apple’s iOS® operating system, any device running Microsoft’s Windows® Mobile operating system, any device running Google’s Android® operating system, and/or any other smartphone, tablet, or like wearable mobile device”, and also ¶ 0039 “The administrator processor 150 may include a processor 151, a memory 152, and an application 153. The processor 151 may be a processor, a microprocessor, or other processor, and the administrator processor 150 may include one or more of these processors.” Therefore, under the broadest reasonable interpretation, from the disclosure in the specification, (the payment method linking application 151) and (the shopper registration service 161), are also the claimed administrator processor 150. Additionally, Applicant further disclose that “Assuming that the claimed administrator processor is mapped to the issuing bank server 160 (the shopper registration service 161) of Martin, Applicant submits that the issuing bank server 160 (the shopper registration service 161) of Martin does not "transmit, to each of a plurality of account processing systems, the encrypted user datum, wherein each account processing system is associated with a different account provider and has been provisioned with user datum encryption information," as recited by claim 1. Examiner asserts that Martin teaches this limitation in Fig. 3 step 304-305, ¶¶ 0048-0049, 0067 “…payment method linking application 151 receives the unencrypted SIC, either from online transaction application 133 or from user computing device 120 directly. Payment method linking application 151 then generates the encrypted SIC using shared key 152 that is employed by shopper registration service 161 in shopper registration process 300 of FIG. 3. Payment method linking application 151 then sends a query that includes the encrypted SIC to one or more issuing bank servers 160. Each query requests an indication from the receiving issuing bank whether the encrypted SIC is associated with an account for the receiving issuing bank”. Furthermore, in addition to the teaching of Martin in ¶¶ 0073-0074, Fig. 8 step 822-843 shows the user inputting the OTP to complete the checkout process. “In step 843, shopper registration service 161 determines whether the OTP value is valid. If yes, online transaction 800 proceeds to step 851; if no, shopper registration service 161 notifies online transaction application 133 and/or client application 125 that an alternative check-out process must be used to complete the online transaction, and online transaction 800 terminates” and also ¶¶ 0075-0078 “…For example, in some embodiments, the online shopper is given an opportunity to review and confirm the purchase before a request for payment settlement is made by payment method linking application 151”}. Therefore, the combination of Martin in view of Li still teaches these limitations. The 103 rejection is hereby maintained. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 3 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 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-4, 6-17 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Martin et al. (US 20230186298 A1), in view of Li et al., (US 20050065881 A1). With respect to claims 1, 10 and 20, Martin teaches a method, a system, comprising: an administrator processor configured to: and a non-transitory computer readable medium containing computer executable instructions that, when executed by an administrator processor, cause an administrator processor to perform procedures {see at least Fig., 1 and 2} comprising: receiving, by an administrator processor from a user device, a user datum for an online transaction initiated by a user of the user device [e.g., shopper identifier credential (SIC)] {see at least Fig. 2 step 201-202, ¶ 0045 “…the online shopper provides an unencrypted shopper identifier credential (SIC) and associated authorization-enabling information to the shopper registration service at the issuing bank. In some embodiments, the unencrypted SIC can be any alphanumeric string suitable for identifying the online shopper, such as a username for the online shopper, an email address associated with the online shopper, and/or the like. In such embodiments, the online shopper can manually enter the unencrypted SIC via user computing device 120”}. encrypting, by the administrator processor using user datum encryption information, the user datum {see at least Fig. 3 step 303-304, ¶ 0048 “…the issuing bank (e.g., via shopper registration service 161) generates an encrypted SIC based on the unencrypted SIC provided in step 303. For example, in some embodiments, shopper registration service 161 generates the encrypted SIC by “hashing” (employing a cryptographic has function) the unencrypted SIC with shared key 152 (shown in FIG. 1). As described below, shared key 152 is also available to payment method linking application 151. Thus, payment method linking application 151 can also generate the encrypted SIC associated with a particular online shopper based on the unencrypted SIC associated with the particular online shopper”, and also ¶ 0067}. transmitting, by the administrator processor to each of a plurality of account processing systems, the encrypted user datum, wherein each account processing system is associated with a different account provider and has been provisioned with user datum encryption information {see at least Fig. 3 step 304-305, ¶¶ 0048-0049, 0067 “…payment method linking application 151 receives the unencrypted SIC, either from online transaction application 133 or from user computing device 120 directly. Payment method linking application 151 then generates the encrypted SIC using shared key 152 that is employed by shopper registration service 161 in shopper registration process 300 of FIG. 3. Payment method linking application 151 then sends a query that includes the encrypted SIC to one or more issuing bank servers 160. Each query requests an indication from the receiving issuing bank whether the encrypted SIC is associated with an account for the receiving issuing bank”, ¶¶ 0067-0070}. receiving, by the administrator processor from at least one of the plurality of account processing systems, a response comprising a notification that an account holder has a transaction account processed by the at least one that account processing system {see at least ¶ 0068 “…when the encrypted SIC is found in registered customer table 175, shopper registration service 161 determines that there is an account associated with the online shopper at the issuing bank, and therefore the account is a linked payment method available to the online shopper”, and also ¶ 0069 “…shopper registration service 161 notifies payment method linking application 151 that the encrypted SIC is linked to an account at that issuing bank, and therefore an account at that issuing bank is available to the online shopper as a payment method for the online transaction”, and ¶ 0070}. receiving, by the administrator processor from the user device, a first confirmation response including identification of an account provider associated with the at least one account processing system {see at least ¶¶ 0068-0070}. transmitting, by the administrator processor, an authentication request to the user device {see at least ¶¶ 0071-0073 “In step 822, payment method linking application 151 requests that the issuing bank associated with the selection input transmit an OTP to the online shopper. Specifically, the request is for the OTP to be transmitted to the trusted device associated with the account at the issuing bank that is associated with the selection input (e.g., user computing device 120). In step 823, the issuing bank (e.g., via shopper registration service 161) receives the request for an OTP to be transmitted to the trusted device associated with the selected payment method. In step 824, client application 125 or web browser 126 displays an authorization UI 701, so that the online shopper can enter the OTP”}. receiving by the administrator processor an authentication credential from the user device, wherein the authentication credential comprises a one-time password (OTP) {see at least ¶¶ 0073-0074 “In step 831, the issuing bank transmits the OTP to the trusted device, using the authorization-enabling information registered with the account at the issuing bank in shopper registration process 300. For example, in some embodiments, the OTP is sent via a short message service (SMS) message to a mobile phone number. In other embodiments, the OTP is sent via email to an email address included in the authorization-enabling information. In yet other embodiments, the OTP is sent via a sound recording to a phone number and/or an email address included in the authorization-enabling information”}. transmitting, by the administrator processor to the user device, a confirmation request identifying the account providers associated with the at least one of the plurality of account processing system {see at least ¶ 0067 “…Payment method linking application 151 then sends a query that includes the encrypted SIC to one or more issuing bank servers 160. Each query requests an indication from the receiving issuing bank whether the encrypted SIC is associated with an account for the receiving issuing bank”, and also ¶ 0068 “…shopper registration service 161 receives the query and searches registered customer table 175 for the encrypted SIC… when the encrypted SIC is found in registered customer table 175, shopper registration service 161 determines that there is an account associated with the online shopper at the issuing bank, and therefore the account is a linked payment method available to the online shopper” ¶¶ 0069-0070 “…payment method linking application 151 receives a response from each issuing bank at which an account is linked to the encrypted SIC. In some embodiments, payment method linking application 151 notifies online transaction application 133 of the issuing banks or payment methods that are available to the online shopper associated with the encrypted SIC…”, and also ¶¶ 0075-0078 “…For example, in some embodiments, the online shopper is given an opportunity to review and confirm the purchase before a request for payment settlement is made by payment method linking application 151”}. receiving, by the administrator processor from the user device, a confirmation response including identification of a selected account provider{see at least ¶¶ 0069-0070 “…payment method linking application 151 receives a response from each issuing bank at which an account is linked to the encrypted SIC. In some embodiments, payment method linking application 151 notifies online transaction application 133 of the issuing banks or payment methods that are available to the online shopper associated with the encrypted SIC…”, Fig., 8 step 851-853, 861, ¶¶ 0075-0078 }. Although Martin discloses a URL, inherently the transition from a merchant checkout UI to a payment to a payment authorization UI to complete the transaction {see Fig. 7 ¶¶ 0061-0062}, but does not explicitly disclose, however, Li discloses generating, by the administrator processor a uniform resource location (URL) configured to launch a payment service software application on the user device, wherein the software application is associated with the account provider associated with the at least one account processing system {see at least Fig. 3, ¶ 0021 “…in block 208 the consumer (i.e., the browser on the consumer's device) is directed to merchant page 1.3, which comprises a blank page (with regard to visual content). Merchant page 1.3 is embedded with code to redirect the device's browser to page 1.6 hosted by the payment service. During this operation, information identifying the merchant (i.e., a merchant ID) is passed from the merchant's web server to the service's server. For example, in one embodiment, the browser is redirected to the service's server using a URL…”, and also claims 14 and 17}. transmitting, by the administrator processor, the URL to the user device {see at least ¶¶ 0021, 0024-0025 “Upon verifying that the merchant is enabled for API use, a CGI (common gateway interface) command (script) is executed on the service's server to interpret the consumer's service cookie. In conjunction with the redirect to service URL above, the browser on the consumer's device automatically forwards a copy of the cookie back to the service server. This is a process that is automatically performed by modern browser's that support cookies in response to being directed to a website that issued the cookie, and does not require any modification on the client (i.e., consumer device) side. In essence, a cookie is merely a pied of text that a web server sends to a client (e.g., a browser running on the consumer's device) to have stored on the client for subsequent use…”, and also claims 14 and 17}. receiving, by the administrator processor from the software application launched on the user device, a second confirmation response where the user has authenticated himself via the software application on the user device {see at least Fig. 3, ¶ 0024 “Upon receiving the merchant ID, the service server checks its user profile data to verify that the merchant is enabled for API use in block 210. In one embodiment, data embedded in the foregoing URL format provides a built-in security measure, wherein the MID and URL values are checked against user profile information for the merchant to authenticate the request…”}. transmitting, by the administrator processor to the at least one account processing system associated with the selected account provider, the second confirmation response {see at least ¶ 0027 “The merchant server extracts the reply variable passed from service page 1.6 and dynamically changes the flow of the checkout process beginning at merchant page 2. For example, if a cookie is not received from the consumer's device, the consumer is not authorized to use the payment service. Accordingly, the reply will indicate such, and the portion of the checkout flow beginning with merchant page 2 will continue with a check out process that doesn't present the consumer with an option to pay via the payment service. In contrast, if the reply indicates the consumer is an authorized user, the merchant page 2 will lead to one or more subsequent pages (not shown) that will enable the user to pay for the purchase via the payment service…”}, and receiving, by the administrator processor from the at least one account processing system associated with the account provider, transaction information sufficient to complete the online transaction {see at least Fig. 3, ¶ 0027 “…if the reply indicates the consumer is an authorized user, the merchant page 2 will lead to one or more subsequent pages (not shown) that will enable the user to pay for the purchase via the payment service. Typically, these pages will be coded by the merchant to fit the particular check-out process preferred by the merchant. Generally, the checkout process will perform a behind-the-scenes interaction with the payment service to complete a payment transaction in response to a consumer's authorization to pay for the product using the payment service. Further details of this process are known in the art, and, as Such, are not disclosed herein”}. Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Martin to include the elements of Li. One would have been motivated to do so, in order to provide a mechanism for enabling e-commerce merchants to offer customer payments via a third-party electronic payment service on an individual consumer basis on a consumer’s device. Furthermore, Martin discloses having electronic transactions conducted over a network using a mobile or other consumer electronic devices and, more particularly, to providing a secure device authentication. Li is merely relied upon to illustrate the functionality of providing a mechanism for enabling e-commerce merchants to offer customer payments via a third-party electronic payment service on a consumer device, in the same or similar context. Because both having electronic transactions conducted over a network using a mobile or other consumer electronic devices and, more particularly, to providing a secure device authentication, as well as providing a mechanism for enabling e-commerce merchants to offer customer payments via a third-party electronic payment service on a consumer’s device are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Martin, as well as Li would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Martin/Li. With respect to claim 2, the combination of Martin in view of Li teaches all the subject matter as disclosed in claims 1, above. Furthermore, Martin discloses wherein the user datum is one of a phone number or an email address {see at least ¶ 0045 “…the online shopper provides an unencrypted shopper identifier credential (SIC) and associated authorization-enabling information to the shopper registration service at the issuing bank. In some embodiments, the unencrypted SIC can be any alphanumeric string suitable for identifying the online shopper, such as a username for the online shopper, an email address associated with the online shopper, and/or the like.…”, and also ¶ 0047}. With respect to claim 3, the combination of Martin in view of Li teaches all the subject matter as disclosed in claims 1, above. Furthermore, Martin discloses, wherein the user datum includes at least one of a home address, a billing address, a mobile phone number, a home phone number, an Email address {see at least ¶¶ 0045, 0047}. With respect to claim 4, the combination of Martin in view of Li teaches all the subject matter as disclosed in claims 1, above. Furthermore, Martin discloses, wherein the software application associated with the selected account provider is a mobile banking app {see at least Fig. 4, ¶ 0031, 0056 “…However, express checkout button 526 is configured to direct the online shopper to a mobile payment service or digital wallet service, which requires redirecting web browser 126 to the website of the mobile payment service or digital wallet service and adds friction to the online transaction process…”}. With respect to claim 6, the combination of Martin in view of Li teaches all the subject matter as disclosed in claims 1, above. Furthermore, Martin discloses, wherein the authentication request is transmitted via a short message service (SMS) from the administrator processor to the user device {see at least ¶ 0074 “…the issuing bank transmits the OTP to the trusted device, using the authorization-enabling information registered with the account at the issuing bank in shopper registration process 300. For example, in some embodiments, the OTP is sent via a short message service (SMS) message to a mobile phone number. …”}. With respect to claims 7 and 16, the combination of Martin in view of Li teaches all the subject matter as disclosed in claims 1, above. Furthermore, Li discloses, wherein if the user device does not have the software application associated with the URL, the URL is configured to cause the user device to download the software application. Examiner Note: The URL is not a hardware and cannot be configured to cause the user device to download the software application, and therefore this limitation does not have patentable weight, however, for the purpose of examining this limitation, Examiner is interpreting this limitation as follows: As prior art teaches, the user selects the payment service to use for payment service presented to the user on the merchant’s website, a URL to the payment service page is embedded in the user’s selection, whereby the user is authenticated and payment is process before been redirected back to the merchant website to complete the transaction, is sufficient in art. {see at least Fig. 3, ¶ 0017-0028 “…The foregoing scheme provides an efficient mechanism for enabling e-commerce merchants to offer purchase payments via third-party payment services. This is advantageous to both the merchant and consumers. The cost associated with credit card transactions fees are eliminated for most payment service transactions. Like credit cards, payments issued by the payment services are trustworthy. Consumers also enjoy the benefit of being able to purchase products on-line in a secure manner that doesn't require disclosure of credit card information, or even require the consumer to possess a credit card” and also claims 14 and 17}. Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Martin to include the elements of Li. One would have been motivated to do so, in order to provide a mechanism for enabling e-commerce merchants to offer customer payments via a third-party electronic payment service on an individual consumer basis on a consumer’s device. Furthermore, Martin discloses having electronic transactions conducted over a network using a mobile or other consumer electronic devices and, more particularly, to providing a secure device authentication. Li is merely relied upon to illustrate the functionality of providing a mechanism for enabling e-commerce merchants to offer customer payments via a third-party electronic payment service on a consumer device, in the same or similar context. Because both having electronic transactions conducted over a network using a mobile or other consumer electronic devices and, more particularly, to providing a secure device authentication, as well as providing a mechanism for enabling e-commerce merchants to offer customer payments via a third-party electronic payment service on a consumer’s device are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Martin, as well as Li would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Martin/Li. With respect to claim 8, the combination of Martin in view of Li teaches all the subject matter as disclosed in claims 1, above. Furthermore, Li discloses, wherein the URL is configured to launch one of a plurality of software applications downloaded on the user device {see at least Fig. 3, ¶ 0027, and also claims 14 and 17}. Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Martin to include the elements of Li. One would have been motivated to do so, in order to provide a mechanism for enabling e-commerce merchants to offer customer payments via a third-party electronic payment service on an individual consumer basis on a consumer’s device. Furthermore, Martin discloses having electronic transactions conducted over a network using a mobile or other consumer electronic devices and, more particularly, to providing a secure device authentication. Li is merely relied upon to illustrate the functionality of providing a mechanism for enabling e-commerce merchants to offer customer payments via a third-party electronic payment service on a consumer device, in the same or similar context. Because both having electronic transactions conducted over a network using a mobile or other consumer electronic devices and, more particularly, to providing a secure device authentication, as well as providing a mechanism for enabling e-commerce merchants to offer customer payments via a third-party electronic payment service on a consumer’s device are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Martin, as well as Li would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Martin/Li. With respect to claim 9, the combination of Martin in view of Li teaches all the subject matter as disclosed in claims 1, above. Furthermore, Li discloses, wherein the URL is configured to launch the software application associated with the selected account provider {see at least Fig. 3, ¶ 0027, and also claims 14 and 17}. Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Martin to include the elements of Li. One would have been motivated to do so, in order to provide a mechanism for enabling e-commerce merchants to offer customer payments via a third-party electronic payment service on an individual consumer basis on a consumer’s device. Furthermore, Martin discloses having electronic transactions conducted over a network using a mobile or other consumer electronic devices and, more particularly, to providing a secure device authentication. Li is merely relied upon to illustrate the functionality of providing a mechanism for enabling e-commerce merchants to offer customer payments via a third-party electronic payment service on a consumer device, in the same or similar context. Because both having electronic transactions conducted over a network using a mobile or other consumer electronic devices and, more particularly, to providing a secure device authentication, as well as providing a mechanism for enabling e-commerce merchants to offer customer payments via a third-party electronic payment service on a consumer’s device are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Martin, as well as Li would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Martin/Li. With respect to claim 11, the combination of Martin in view of Li teaches all the subject matter as disclosed in claims 10, above. Furthermore, Martin discloses, wherein the user device is used by a user to perform the transaction on a website or application associated with the administrator processor {FIG. 1, ¶ 0073 “…client application 125 or web browser 126 transmits the selection input to payment method linking application 151. In step 822, payment method linking application 151 requests that the issuing bank associated with the selection input transmit an OTP to the online shopper. Specifically, the request is for the OTP to be transmitted to the trusted device associated with the account at the issuing bank that is associated with the selection input (e.g., user computing device 120)…”}. With respect to claim 12, the combination of Martin in view of Li teaches all the subject matter as disclosed in claims 10, above. Furthermore, Martin discloses, wherein the OTP is transmitted to the user device from the at least one account processing system associated with the account provider. {¶ 0007 “…sending a first query that includes the first encrypted shopper identifier credential to a first issuing bank, wherein the first query requests an indication that the first encrypted shopper identifier credential is associated with an account for the first issuing bank; receiving a response from the first issuing bank that includes the indication; and causing the checkout user interface to be modified with a selection field, wherein the selection field is associated with the first issuing bank”}. With respect to claim 13, the combination of Martin in view of Li teaches all the subject matter as disclosed in claims 10, above. Furthermore, Martin discloses, wherein the administrator processor is further configured to transmit, upon receiving the transaction information sufficient to complete a transaction, the transaction information to a transaction processor configured to process the transaction {see at least ¶ 0037 “…online transaction network 100 (e.g., payment method linking application 151) determines whether the online shopper has completed the checkout process, for example by selecting a suitable payment method for the online transaction and by clicking on, tapping, or otherwise selecting a “complete purchase” selection field displayed on a page of merchant website 140…”, ¶¶ 0038-0040 “…the payment processor completes the online transaction by performing the requested payment settlement, and funds associated with the online transaction are transferred from the account at the issuing bank selected in step 203 to a bank account associated with the merchant”}. With respect to claim 14, the combination of Martin in view of Li teaches all the subject matter as disclosed in claims 13, above. Furthermore, Martin discloses, wherein the administrator processor is further configured to receive a message indicating whether the transaction has been completed successfully {¶¶ 0038-0040, 0078 “…payment method linking application 151 performs order confirmation and completion, such as step 204 in online transaction 200… the online shopper is given an opportunity to review and confirm the purchase before a request for payment settlement is made by payment method linking application 151”}. With respect to claim 15, the combination of Martin in view of Li teaches all the subject matter as disclosed in claims 10, above. Furthermore, Martin discloses, wherein each of the account providers are associated with a transaction card owned by the user associated with the use device {see at least ¶ 0038 “…online transaction network 100 (e.g., payment method linking application 151) requests and receives account authorization information 172 from the issuing bank associated with the payment method selected in step 203. For example, the authorization information may include sensitive credit card information associated with the payment method selected in step 203 and associated with the online shopper, such as a primary account number (PAN) and/or a card verification value (CVV), or a card token”, and ¶ 0055}. With respect to claim 17, the combination of Martin in view of Li teaches all the subject matter as disclosed in claims 10, above. Furthermore, Li discloses, wherein the URL is configured to open the most recently used software application {see at least Fig. 3, ¶ 0027}. Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Martin to include the elements of Li. One would have been motivated to do so, in order to provide a mechanism for enabling e-commerce merchants to offer customer payments via a third-party electronic payment service on an individual consumer basis on a consumer’s device. Furthermore, Martin discloses having electronic transactions conducted over a network using a mobile or other consumer electronic devices and, more particularly, to providing a secure device authentication. Li is merely relied upon to illustrate the functionality of providing a mechanism for enabling e-commerce merchants to offer customer payments via a third-party electronic payment service on a consumer device, in the same or similar context. Because both having electronic transactions conducted over a network using a mobile or other consumer electronic devices and, more particularly, to providing a secure device authentication, as well as providing a mechanism for enabling e-commerce merchants to offer customer payments via a third-party electronic payment service on a consumer’s device are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Martin, as well as Li would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Martin/Li. With respect to claim 19, the combination of Martin in view of Li teaches all the subject matter as disclosed in claims 18, above. Furthermore, Li discloses, wherein upon determining that the current transaction is likely fraudulent, transmitting a third authentication request to the user device, and receiving from the user device a third authentication credential {see at least ¶ 0026 “Based on the merchant's return URL, the CGI command redirects the browser back to the merchant's web server to merchant page 2, which begins the augmented check out flow. In conjunction with this, a reply is passed to the server (e.g., embedded as a variable in a pre-formatted URL in one embodiment) that indicates whether or not the consumer is authorized to use the payment service. In one embodiment respective reply variable values are also used to indicate an authentication failure and a cookie cannot be interpreted”, ¶ 0027 “The merchant server extracts the reply variable passed from service page 1.6 and dynamically changes the flow of the checkout process beginning at merchant page 2. For example, if a cookie is not received from the consumer's device, the consumer is not authorized to use the payment service. Accordingly, the reply will indicate such, and the portion of the checkout flow beginning with merchant page 2 will continue with a check out process that doesn't present the consumer with an option to pay via the payment service. In contrast, if the reply indicates the consumer is an authorized user, the merchant page 2 will lead to one or more subsequent pages (not shown) that will enable the user to pay for the purchase via the payment service… Generally, the checkout process will perform a behind-the-scenes interaction with the payment service to complete a payment transaction in response to a consumer's authorization to pay for the product using the payment service. Further details of this process are known in the art, and, as such, are not disclosed herein”}. Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Martin to include the elements of Li. One would have been motivated to do so, in order to having a secure ecommerce payment transaction without disclosing payment card information. Furthermore, Martin discloses having electronic transactions conducted over a network using a mobile or other consumer electronic devices and, more particularly, to providing a secure device authentication. Li is merely relied upon to illustrate the functionality of having a secure ecommerce payment transaction without disclosing payment card information, in the same or similar context. Because both having electronic transactions conducted over a network using a mobile or other consumer electronic devices and, more particularly, to providing a secure device authentication, as well as having a secure ecommerce payment transaction without disclosing payment card information are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Martin, as well as Li would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Martin/Li. Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Martin et al. (US 20230186298 A1), in view of Li et al. (US 20050065881 A1), and further in view of Grassadonia et al., (US 20160125371 A1). With respect to claim 5, the combination of Martin in view of Li teaches all the subject matter as disclosed in claims 1, above but does not explicitly disclose, however, Grassadonia discloses, wherein the second confirmation response from the software application includes biometric authentication data {see at least ¶¶ 0106, 0120, claim 13 “…wherein the unique identifier is any of an IP address, a device ID, an application ID, or a biometric identifier”}. Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Martin in view of Li, to include the elements of Grassadonia. One would have been motivated to do so, in order to have a unique identifier in a payment transaction that includes a biometric data. Furthermore, Martin discloses having electronic transactions conducted over a network using a mobile or other consumer electronic devices and, more particularly, to providing a secure device authentication, and Li discloses providing a mechanism for enabling e-commerce merchants to offer customer payments via a third-party electronic payment service on a consumer device. Grassadonia is merely relied upon to illustrate the functionality of having a unique identifier in a payment transaction that includes a biometric data, in the same or similar context. Because both having electronic transactions conducted over a network using a mobile or other consumer electronic devices and, more particularly, to providing a secure device authentication, and providing a mechanism for enabling e-commerce merchants to offer customer payments via a third-party electronic payment service on a consumer’s device as well as having a unique identifier in a payment transaction that includes a biometric data are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Martin in view of Li, as well as Grassadonia would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Martin/Li/Grassadonia. Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Martin et al. (US 20230186298 A1), in view of Li et al. (US 20050065881 A1), and further in view of Das et al., (US 20210192641 A1). With respect to claim 18, the combination of Martin in view of Li teaches all the subject matter as disclosed in claims 10, above, but does not explicitly disclose, however, Das discloses, wherein upon receiving the user datum, the administrator processor retrieves one or more historical transaction data associated with the user and determines whether the current transaction is likely fraudulent {see at least ¶ 0137 “…the historical transaction data 607 may include data associated with (e.g., indicating) a payment account type involved in a payment transaction (e.g., a credit account, a debit account, and/or the like), data associated with (e.g., indicating) a payment channel involved in a payment transaction (e.g., an indicator associated with in-person payment transactions, an indicator associated with e-commerce (e.g., online) payment transactions, and/or the like), data associated with a fraud risk score (e.g., a score associated with a determination of whether a payment transaction is a fraudulent payment transaction or not a fraudulent payment transaction), data associated with a merchant type (e.g., an indicator associated with a transit merchant, an indicator associated with a retail department store merchant, and/or the like), data associated with an acquirer behavior (e.g., an indicator that an acquirer processes payment transactions within a period of time, and/or the like), and/or the like…”}. Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Martin in view of Li, to include the elements of Das. One would have been motivated to do so, in order to have a risk management analysis on the payment transaction data. Furthermore, Martin discloses having electronic transactions conducted over a network using a mobile or other consumer electronic devices and, more particularly, to providing a secure device authentication, and Li discloses providing a mechanism for enabling e-commerce merchants to offer customer payments via a third-party electronic payment service on a consumer device. Das is merely relied upon to illustrate the functionality of having a risk management analysis on the payment transaction data, in the same or similar context. Because both having electronic transactions conducted over a network using a mobile or other consumer electronic devices and, more particularly, to providing a secure device authentication, and providing a mechanism for enabling e-commerce merchants to offer customer payments via a third-party electronic payment service on a consumer’s device as well as having a risk management analysis on the payment transaction data are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Martin in view of Li, as well as Das would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Martin/Li/Das. The prior art made of record and not relied upon: 1) (US 20160117762 A1) – Mirza M. Ahmad, Menu Sharing Systems and Methods for Tele dining - relates generally to an automated restaurant experience for customers. An access unit that customers use to order food and drinks while seated at the table also allows a table's bill to be paid. The billing screen includes a series of payment buttons which allow the table to decide to pay individually, as couples, as a group, or any similar variations. 2) (WO 2019234801 A1) – Noboru Hishinuma, Service Provision System and Service Provision Method – relates generally to an OTP authentication request includes the OTP attached to the URL received from the user terminal 30 and the login user authentication information created. 3) (US 20140213343 A1) – Lucy Ma Zhao, Triggering in-Application Currency Transfer – relates generally to electronic currency transfers. In particular, the present disclosure relates to methods and systems for using a computing device to transfer currency from one account to another account in relation to a game application. 4) (US 20010023487 A1) – Akiko Kawamoto, Multicast System, Authentication Server Terminal, Multicast Receiver Terminal Controlling Method, and Storage Medium - relates to data communication by a multicast system, particularly, a system for identifying a user by individually authenticating the user using a specified authentication server. 5) (US 20130346302 A1) – Purves et al., Remote Portal Bill Payment Platform Apparatuses, Methods and Systems – relates to the user 102 may desire to pay the mobile phone bill 103. The user may pay the bill via various portals. For example, the user may log into a third-party site, such as an online banking site 108, wherein the banking site may allow the user to view a bank account 115, make a transfer 116, and/or pay the bill with a Bill-Pay widget 117 within the online banking site 108. Conclusion THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINCENT IDIAKE whose telephone number is (571)272-1284. The examiner can normally be reached on Mon-Fri from 10:30AM to 7:30PM ET. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PATRICK MCATEE, can be reached at telephone number (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 an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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) Form at https://www.uspto.gov/patents/uspto-automated-interview-request-air-form /V.I./Examiner, Art Unit 3698 /PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Read full office action

Prosecution Timeline

Oct 17, 2024
Application Filed
Oct 17, 2025
Non-Final Rejection mailed — §103
Mar 10, 2026
Applicant Interview (Telephonic)
Mar 11, 2026
Examiner Interview Summary
Mar 17, 2026
Response Filed
Jul 02, 2026
Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12675604
CONTROL TOWER FOR PROSPECTIVE TRANSACTIONS
1y 8m to grant Granted Jul 07, 2026
Patent 12646056
METHOD AND SYSTEM OF INTEGRATING BLOCKCHAIN TECHNOLOGY WITH EXISTING COMPUTER ARCHITECTURE
1y 9m to grant Granted Jun 02, 2026
Patent 12639712
System and Computer Implemented Method for Generating and Transmitting Tokenized Card Information
1y 6m to grant Granted May 26, 2026
Patent 12632858
CRYPTOGRAPHIC DIGITAL ASSET ARCHITECTURE WITH SELECTIVELY-LOCKABLE DYNAMIC EVOLUTION
2y 3m to grant Granted May 19, 2026
Patent 12561669
SYSTEMS AND METHODS FOR A TRANSACTION CARD HAVING A CRYPTOGRAPHIC KEY
1y 9m to grant Granted Feb 24, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

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

Prosecution Projections

3-4
Expected OA Rounds
71%
Grant Probability
92%
With Interview (+20.3%)
2y 10m (~1y 1m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 161 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

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

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

Free tier: 3 strategy analyses per month