Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Applicant filed an amendment on October 27, 2025. Claims 1-6 were pending in the Application. Claims 1 and 4 are amended. No new claims have been added. No claims have been canceled. Claim 1 and 4 are the independent claims, the remaining claims depend on claims 1 and 4. Thus claims 1-6 are currently pending. After careful and full consideration of Applicant arguments and amendments, the Examiner finds them to be moot and/or not persuasive.
Response to Arguments
In the context of Claim Interpretation, Intended Use, paragraph 3 of the Non-Final Rejection Office Action dated July 17, 2025, Applicant has not adequately amended to render the Claim Interpretation, Intended Use, moot. Claim 4 recites “a processor-based server in electronic communication with the data warehouse, the processor-based server configured to: receive an authentication request …; …, retrieve from the data warehouse, …; execute one or more checks and clears …; display multiple eligible transactions …; receive authenticating input, …; generate a response to …; and designate an eligible transaction …”, which are intended uses of a “processor-based server” and therefore carries limited patentable weight. (MPEP § 2103 I C). Examiner hereby maintains the Claim Interpretation, Intended Use, paragraph 3 of the Non-Final Rejection Office Action dated July 17, 2025.
In the context of 35 U.S.C. §101, Applicant respectfully disagrees with the rejection. Applicant is of the opinion that the claims are statutory and respectfully asserts that “with reference to Step 2A-Prong 1, Applicant disagrees that the claims, when properly viewed as a whole, are directed to a fundamental economic practice; Applicant disagrees with the limitations recited in the claims, when properly viewed as a whole, do not integrate into a practical application, to the extent that the claims recite any judicial exception, Applicant submits that any such judicial exceptions are integrated into practical applications of those concepts; with reference to Step 2A-Prong 2, Applicant argues that the pending claims should be found patent-eligible under the proper application of the PEG and framework as defined by the PTAB; the disclosed methods effectively address technical problems associated with prior art cardholder authentication systems and processes; these prior art methods often lack security, are time-consuming, and can be expensive; the Applicant’s Specification provides a technical solution to the above-described technical problem; the claims 1 and 4 are focused on improvements in a technical field through a software-implemented method that provides tangible and non-abstract improvements to computer technology; claims 1 and 4 have been amended to recite two distinct technical improvements: first, the step of eliminating ineligible transactions has been amended to require 'filtering the transaction history data to remove at least one of: recurring transactions, transactions associated with high-risk merchant category codes, or transactions associated with sensitive transaction category codes'; and second, the claims have been amended to further include the step of 'subsequent to displaying a transaction as an eligible transaction, designating said transaction as ineligible for future authentication events’; these improvements are relevant to show both integration into a practical application under Step 2A (MPEP § 2106.04(d) (I)) and to demonstrate substantially more than an abstract idea under Step 2B (MPEP § 2106.05(1) (A)); the claimed method offers technical benefits due to several improvements in the technical field; as amended, the independent claims recite significantly more than the alleged abstract idea; the combination of (1) specific, rule-based pre-filtering of transaction data and (2) post-use invalidation of that data for future authentication constitutes a concrete, technological improvement to computer security; amended independent claims 1 and 4 do not merely recite an abstract idea implemented on a generic computer, rather, they recite a specific solution to technical problems inherent in computer-based authentication; that the claims are directed to improvements in a technical field, namely to improvements in cardholder authentication systems, and more particularly to real-time cardholder authentication during an enrollment event using cardholder transaction history; and that the claims are directed to a practical application of any included exceptions and, therefore, are not an abstract idea.”
Initially, the Examiner would like to point out that the basis of the rejection is Alice, by applying the subject matter eligibility analysis and flowchart according to MPEP § 2106, which applies a two-step framework, earlier set out in Mayo Collaborative Services v. Prometheus Laboratories, Inc., 566 U.S. 66 (2012), "for distinguishing patents that claim laws of nature, natural phenomena, and abstract ideas from those that claim patent-eligible applications of those concepts." Alice, 573 U.S. at 217.
Under the two-step framework, it must first be determined if "the claims at issue are directed to a patent-ineligible concept." If the claims are determined to be directed to a patent-ineligible concept, e.g., an abstract idea, then the second step of the framework is applied to determine if "the elements of the claim ... contain an "inventive concept" sufficient to 'transform' the claimed abstract idea into a patent-eligible application." (citing Mayo, 566 U.S. at 72-73, 79).
With regard to step one of the Alice framework, we apply a "directed to" two-prong test: 1) evaluate whether the claim recites a judicial exception, and 2) if the claim recites a judicial exception, evaluate whether the claim "applies, relies on, or uses the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception," i.e., whether the claim integrates the judicial exception into a practical application. (MPEP §2106.04 II.A.1. and II.B.2.).
The Specification, (PG Pub US 20250245661 A1, para 1), provides evidence as to what the claimed invention is directed. In this case, the specification, (‘661 A1, para 1), discloses that the invention relates to real time cardholder authentication, and is grouped under “Certain Methods of Organizing Human Activity, commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations)”, in prong one of step 2A. (MPEP §2106.04 II.A.1.).
Claim 1 provides additional evidence, and recites the limitations “receiving an authentication request comprising a user’s bank account data; using the user’s bank account data, retrieving from a data warehouse, transaction history data associated with said bank account data; executing one or more checks and clears on the user’s transaction history data and eliminating ineligible transactions, where eliminating ineligible transactions comprises filtering the transaction history data to remove at least one of: recurring transactions, transactions associated with high-risk merchant category codes, or transactions associated with sensitive transaction category codes; displaying multiple eligible transactions to a user on a user interface of a computing device; receiving authentication input, wherein the authenticating input comprises transaction identifying data; generating a response to the request for authentication; and designating an eligible transaction corresponding to the received authenticating input as ineligible”, where the italicized claim language represents the abstract idea of an “authentication protocol”. (MPEP §2106.04 II.A.1.).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP §2106.04 II.A.2.), the additional elements of the claim (the bolded claim language), such as “a data warehouse” and “displaying multiple eligible transactions to a user on a user interface of a computing device”, represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of an “authentication protocol.”
Examiner notes the basis of the rejection was, and is not as any mental process covering performance in the mind, but classified as an abstract idea of an “authentication protocol”, grouped under “Certain Methods of Organizing Human Activity, commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations)”.
With respect to the additional elements operating in a non-conventional and non-generic way and reflecting an improvement to a particular technological environment, the cited additional elements represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of an “authentication protocol.” The claims are not directed to improving computers or related technologies, but improving the method for an “authentication protocol”. For potential improvement in an abstract idea of an “authentication protocol”, it is important to keep in mind that an improvement in the abstract idea itself (e.g. an authentication protocol concept) is not an improvement in technology. (MPEP § 2106.04(d)(1)). Therefore, claim 1 is non-statutory.
Claim 4 also recites the abstract idea of an “authentication protocol”, as well as the additional elements of “a system”, “a data warehouse”, “a processor-based server in electronic communication with the data warehouse”, and “display multiple eligible transactions to a user on a user interface of a computing device”, which represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of an “authentication protocol.”
When analyzed under step 2B (MPEP 2106.05 I.A.), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describe the concept of an “authentication protocol” using computer technology (e.g., “a processor-based server” and “a data warehouse”). Therefore, the use of these additional elements do no more than employ a computer as a tool to implement the abstract idea. And as the computer does no more than serve as a tool to implement the abstract idea, they do not improve computer functionality or improve another technology or technical field. (MPEP 2106.05 I A (f) & (h)). Therefore, claim 4 is non-statutory.
Finally, Examiner notes the basis of the rejection is Alice, by applying the subject matter eligibility analysis and flowchart according to MPEP § 2106. And, based on this standard, the claims are non-statutory, and correctly rejected under 35 U.S.C. § 101.
In the context of 35 U.S.C. § 102, for paragraphs 13-16 of the Non-Final Rejection Office Action dated July 17, 2025, Applicant has not adequately amended to render the rejections under 35 U.S.C. § 102 moot. Applicant’s arguments are not persuasive. With respect to the limitations “receive an authentication request …; …, retrieve from the data warehouse, …; execute one or more checks and clears …; display multiple eligible transactions …; receive authenticating input, …; generate a response to …; and designate an eligible transaction …”, these merely represent the intended uses of the processor-based server in claim 4, and it has been held that they will not differentiate (MPEP § 2114 IV) the claims from the prior art. As Rapowitz teaches the claimed structure (FIG. 1, 3, items 101, 103, 111, 302, 303, 304, 305, 306, 307; C/L 2/57-66; C/L 6/43-67; C/L 7/1-12; C/L 8/52-56; C/L C/L 9/13-16, 20-24; C/L 10/4-11; C/L 20/1-5), it is therefore, sufficient in terms of prior art. Dependent claims 5-6, which depend from claim 4 are also similarly rejected. Examiner maintains the rejection under 35 U.S.C. § 102.
In the context of 35 U.S.C. § 103, in the Non-Final Rejection Office Action dated July 17, 2025, Applicant has adequately amended to overcome the current record of art and not render the rejection under 35 U.S.C. § 103 moot. The cited references of record individually, and in combination, fail to teach, disclose, or render obvious at least “executing one or more checks and clears on the user’s transaction history data and eliminating ineligible transactions, wherein eliminating ineligible transactions comprises filtering the transaction history data to remove at least one of: recurring transactions, transactions associated with high-risk merchant category codes, or transactions associated with sensitive transaction category codes” and “designating an eligible transaction corresponding to the received authenticating input as ineligible”. After further consideration and search, no prior art was found to render at least these limitations obvious. Examiner hereby rescinds the rejection under 35 U.S.C. § 103.
Claim Interpretation – Intended Use
Regarding claim 4, Examiner notes that the following limitations: “a processor-based server in electronic communication with the data warehouse, the processor-based server configured to: receive an authentication request …; using…, retrieve from the data warehouse, …; execute one or more checks and clears …; display multiple eligible transactions …; receive authenticating input, …; generate a response to the request …; and designate an eligible transaction …” are intended uses of the “processor-based server” and therefore carries limited patentable weight. (MPEP § 2103 I C).
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-6 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-3 are directed to a “method”, and claims 4-6 are directed to a “system”. Therefore, these claims are directed to one of the four statutory categories of invention.
Claim 1 recites an “authentication protocol”, which is a form of commercial or legal interactions (i.e., organizing human activity), and therefore, an abstract idea. Specifically, the claim recites “receiving an authentication request comprising a user’s bank account data; using the user’s bank account data, retrieving from a data warehouse, transaction history data associated with said bank account data; executing one or more checks and clears on the user’s transaction history data and eliminating ineligible transactions, where eliminating ineligible transactions comprises filtering the transaction history data to remove at least one of: recurring transactions, transactions associated with high-risk merchant category codes, or transactions associated with sensitive transaction category codes; displaying multiple eligible transactions to a user on a user interface of a computing device; receiving authentication input, wherein the authenticating input comprises transaction identifying data; generating a response to the request for authentication; and designating an eligible transaction corresponding to the received authenticating input as ineligible”. The abstract idea is in italics, and the additional elements are in bold. (MPEP §2106.04 II.A.1.).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP §2106.04 II.A.2.), the additional elements of the claim, such as “a data warehouse” and “displaying multiple eligible transactions to a user on a user interface of a computing device”, represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of an “authentication protocol.”
When analyzed under step 2B (MPEP 2106.05 I.A.), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describes the concept of an “authentication protocol” using computer technology (e.g., “a computing device” and “a data warehouse”). Therefore, the use of these additional elements do no more than employ a computer as a tool to implement the abstract idea. And as the computer does no more than serve as a tool to implement the abstract idea, they do not improve computer functionality or improve another technology or technical field. (MPEP 2106.05 I A (f) & (h)). Therefore, claim 1 is non-statutory.
Claim 4 also recites the abstract idea of an “authentication protocol”, as well the additional elements of “a system”, “a data warehouse”, “a processor-based server in electronic communication with the data warehouse”, and “display multiple eligible transactions to a user on a user interface of a computing device”, which represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of an “authentication protocol.”
When analyzed under step 2B (MPEP 2106.05 I.A.), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describes the concept of an “authentication protocol” using computer technology (e.g., “a processor-based server” and “a data warehouse”). Therefore, the use of these additional elements do no more than employ a computer as a tool to implement the abstract idea. And as the computer does no more than serve as a tool to implement the abstract idea, they do not improve computer functionality or improve another technology or technical field. (MPEP 2106.05 I A (f) & (h)). Therefore, claim 4 is non-statutory.
Dependent claims 2-3 and 5-6 further describe the abstract idea of an “authentication protocol”, which is insufficient to overcome the rejections of claims 1 and 4.
Dependent claims 2 and 5 do not recite any new additional elements that integrate the abstract idea into a practical application, and that do no more than represent a computer performing functions that correspond to implementing the acts of an “authentication protocol”, when analyzed under Step 2A, Prong Two.
Dependent claims 3 and 6 recite a new additional element of “an application programming interface”, which does no more than employ a computer as a tool to implement the abstract idea. And, as it does no more than employ a computer as a tool to implement the abstract idea, it does not improve computer functionality or improve another technology or technical field.
Hence, claims 1-6 are not patent eligible.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-6 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The term “high-risk” in claims 1 and 4 is a relative term which renders the claim indefinite. The term “high-risk” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. One of ordinary skill int the art would now be reasonably apprised as to which merchant category codes are “high-risk” versus those which are an acceptable level of risk.
Dependent claims are rejected by virtue of their dependency.
The following is a quotation of the first paragraph of 35 U.S.C. § 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. § 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-6 are rejected under 35 U.S.C. § 112(a) or 35 U.S.C. § 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. § 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
New Matter
Claim 1 recites, “executing one or more checks and clears …, wherein eliminating ineligible transactions comprises filtering the transaction history data to remove at least one of: recurring transactions, transactions associated with high-risk merchant category codes, or transactions associated with sensitive transaction category codes.” Specification, (PG Pub US 20250245661 A1, para 16), recites “… ineligible transactions may include transactions labeled with a transaction category code that may be deemed sensitive. Other types of ineligible transactions may include recurring transactions because they may be easier for a user to remember thereby reducing the reliability of the authentication; transactions with high-risk merchant category codes …”, which is directed to what ineligible transactions may include, but is not directed to eliminating ineligible transactions comprising filtering the transaction history data, as being claimed. Under the broadest reasonable interpretation (BRI), and using the plain language definition of filtering, as related to computers, as using a filter to block or restrict access to: i.e., a program that filters spam (The American Heritage® Dictionary of the English Language, Fifth Edition copyright ©2022 by HarperCollins Publishers. All rights reserved.), the specification, (‘661 A1, para 16), is silent and lacks support for any filter or program being applied in eliminating ineligible transactions comprising the transaction history data. Thus, the specification, (‘661 A1, para 16), lacks sufficient details so that one of ordinary skill in the art would understand how “eliminating ineligible transactions comprising filtering the transaction history data” is performed. Therefore, this is an issue of new matter, which is matter not present on the filing date of the application in the specification, claims, or drawings that has been added after the application filing. Additionally, similar language is recited in claim 4. Dependent claims 2-3, which depend from claim 1, and dependent claims 5-6, which depend from claim 4, are also similarly rejected. (MPEP § 2163.06 I).
Claim 1 recites, “designating an eligible transaction corresponding to the received authenticating input as ineligible.” Specification, (PG Pub US 20250245661 A1, para 20), recites “The authenticating input is received and an authentication response is provided. If the authentication input accurately reflects genuine transaction data, the user authentication is confirmed 210. If the authenticating input does not accurately reflect genuine transaction data, the user authentication is denied 212. When a user authentication is denied, the user may be presented with a new set of eligible transactions to reattempt the authentication process 214”, which is directed to the authentication input accurately reflecting genuine transaction data, then the user authentication being confirmed, and to when the authentication input does not accurately reflect genuine transaction data, the user authentication being denied, but is not directed to designating an eligible transaction corresponding to the received authentication input as ineligible, as being claimed. Thus, the specification, (‘661 A1, para 20), lacks sufficient details so that one of ordinary skill in the art would understand how “designating an eligible transaction corresponding to the received authenticating input as ineligible” is performed.
Specification, (PG Pub US 20250245661 A1, para 21), recites “To avoid fraud, each genuine transaction may only be presented to a user once and is thereafter deemed ineligible …”, which is directed to deeming ineligible each genuine transaction being presented to a user once, but is not directed to designating an eligible transaction corresponding to the received authentication input as ineligible, as being claimed. Thus, the specification, (‘661 A1, para 21), lacks sufficient details so that one of ordinary skill in the art would understand how “designating an eligible transaction corresponding to the received authenticating input as ineligible” is performed. Therefore, this is an issue of new matter, which is matter not present on the filing date of the application in the specification, claims, or drawings that has been added after the application filing. Additionally, similar language is recited in claim 4. Dependent claims 2-3, which depend from claim 1, and dependent claims 5-6, which depend from claim 4, are also similarly rejected. (MPEP § 2163.06 I).
Claim Rejections - 35 USC § 102
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 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 the appropriate paragraphs of 35 U.S.C. § 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 4-6 are rejected under 35 U.S.C. § 102 (a)(1) being anticipated by Rapowitz et al U. S. Patent No. US 12056221 B2.
Regarding claim 4, Rapowitz discloses “A system for authenticating a user during an enrollment event, the system comprising: a data warehouse (FIG. 3, items 303, 304, 305, 306, 307; C/L 2/57-66; C/L 8/52-56) capable of storing (FIG. 3, items 302, 303, 304; C/L 9/13-16, 20-24; C/L 10/4-11) and retrieving data (FIG. 1, item 101, and C/L 6/43-60; C/L 20/1-5); and a processor-based server (FIG. 1, items 101, 111, and C/L 6/43-55; C/L 7/5-12) in electronic communication (FIG. 1, item 103, and C/L 6/56-67; C/L 7/1-4) with the data warehouse, the processor-based server configured to: …”
With respect to claim 4, the limitations “receive an authentication request …; using …, retrieve from the data warehouse, …; execute one or more checks and clears …; display multiple eligible transactions …; receive authenticating input, …; generate a response to …; and designate an eligible transaction …”, merely represent the intended uses of the processor-based server, and it has been held that they will not differentiate (MPEP § 2114 IV) the claim from the prior art. Therefore as Rapowitz teaches the claimed structure (FIG. 1, 3, items 101, 103, 111, 302, 303, 304, 305, 306, 307; C/L 2/57-66; C/L 6/43-67; C/L 7/1-12; C/L 8/52-56; C/L C/L 9/13-16, 20-24; C/L 10/4-11; C/L 20/1-5), it is sufficient in terms of prior art.
Regarding claim 5, Rapowitz discloses the limitations of claim 4. Claim 5 is further directed to the intended use of the limitation “receive authenticating input, wherein the authenticating comprises transaction identifying data” and to the intended use of “the processor-based server” of claim 4, and therefore will not differentiate the claim from the prior art. (MPEP § 2103 I C).
Regarding claim 6, Rapowitz discloses the limitations of claim 4. Claim 6 is further directed to the intended use of the limitations “using the user’s bank account data, retrieve from the data warehouse, transaction history …” and “execute one or more checks and clears on the user’s transaction data and eliminating ineligible transactions”, and the intended use of the “the processor-based server” of claim 4, and therefore will not differentiate the claim from the prior art. (MPEP § 2103 I C).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Maheshwari et al (U. S. Patent Application Publication No. 20200372495 A1) – Authenticating A User For A Transaction Based On Device-Based Authentication Data By A Payment Network
Maheshwari discloses authentication of a user based on device-based user authentication data for transactions associated with a payment account. A service receives a registration message including device-based user authen-tication data and a payment account identifier. Based on the device-based user authentication data matching an authentication data type of issuer-approved data types, the device-based user authentication data is linked with the payment account. An authentication request associated with a transaction from the payment account is received including device-based user authentication data of the user. The user is authenticated based on the device-based user authentication data of the authentication request matching the device-based user authentication data linked with the payment account, whereby authentication of the identity of the user for the transaction is delegated to the service by the issuer of the payment account based on the linking of the device-based user authentication data with the payment account.
Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEVEN CHISM whose telephone number is (571) 272-5915. The examiner can normally be reached during 9:00 AM – 3:00 PM Monday – Thursday, EST.
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, Ryan D. Donlon can be reached (571) 270-3602. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/STEVEN R CHISM/Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692 February 6, 2026