Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the pre-AIA first to invent provisions as the present application is claiming a priority to U. S. Provisional Application 61/211, 335, filed on March 30, 2009.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on May 08, 2026, has been entered.
Status of Claims
Applicant filed an amendment on May 08, 2026. Claims 1-6 were pending in the Application. Claims 1, 3-4, and 6 are amended. No new claims have been added. No new claims have been canceled. 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 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 “the pending claims provide a technical solution to a technical problem; the computer-implemented method is carried out in real-time; real-time authentication, which is limited by the information input by the user, is a further demonstration of the technical solution of the pending claims; the pending claims are therefore focused on improvements in a technical field through a software-implemented method that provides tangible, non-abstract improvements to computer technology; the functionality of the computer is improved, as it is enabled to do things it could not do before (Finjan); with the advent of real-time authentication, the computer is improved to operate with the constraint, in real-time, to authenticate the user based on limited information, even reducing that information further by eliminating certain transactions (e.g., high risk categories, sensitive transaction, recurring transaction, etc.); the computer deems "used" transactions as also being ineligible, whereby still further eligible transactions are then needed for further transactions; the reduction in transaction data, and continued performance of the real-time authentication is an improvement in technology; the claims are in fact directed to none of the enumerated examples; there is no contract, marketing, sales, business, etc., recited in the claims; the claims are not directed to commercial interactions; there is no business component to this concept; the claims are directed to authentication, in real-time, and whether that authentication, in turn, is specifically used in connection with business is irrelevant; there is NO inherent commercial interaction in "authentication protocol"; the Office asserts that the computer is merely a tool to perform the alleged idea, and Applicant respectfully disagrees; there is no way to perform the recited operation outside of the computer, in real-time, whereby the computer is in fact integrated to performance of the recited operations; given the authentication protocol is the alleged idea, there are various additional elements to consider, and these additional elements in combination with the data warehouse, and displaying operation, and the processor-based server, provide meaningful limitations that go beyond merely linking the alleged idea to a specific technology; the additional limitations establish a specific practical application for the alleged authentication protocol, in the context, as claimed, of enrollment of the user in real-time, and therefore, the additional elements amount to significantly more than the alleged idea; the pending claims recite a narrowly tailored technical solution to the above problem; and that solution leverages specific data, for authenticating cardholders in real-time during an enrollment event using cardholder transaction history that eliminates password sharing and has higher levels of confidence, and thus, the pending claims are eligible .”
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)” and grouped under “Certain Methods of Organizing Human Activity, fundamental economic principles or practices (including hedging, insurance, mitigating risk)”, 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, by a processor-based server, from a data warehouse, transaction history data associated with said bank account data; executing, by the processor-based server, one or more checks and clears on the user's transaction history data to eliminate recurring transactions and/or transactions associated with certain category codes as ineligible transactions; displaying multiple eligible transactions to a user on a user interface of a computing device; receiving, by the processor-based server, authenticating input, wherein the authenticating input comprises transaction identifying data; generating, by the processor-based server, a response to the request for authentication; and deeming, by the processor-based server, the multiple eligible transactions as ineligible to be presented to the user for said authentication request”, which represent the abstract idea of an “authentication protocol”. 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 processor-based server, from a data warehouse” and “displaying multiple eligible transactions to a user on a user interface of a computing device”, which amount to merely “apply it”, as they 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)” and grouped under “Certain Methods of Organizing Human Activity, fundamental economic principles or practices (including hedging, insurance, mitigating risk)”.
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 claim is not directed to improving computer functionality nor improving another technology or technical field, 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 for authenticating a user in real-time during an enrollment event, the system comprising: a data warehouse capable of storing and retrieving data; and a processor-based server in electronic communication with the data warehouse, the processor-based server configured to: …”, and “display multiple eligible transactions to a user on a user interface of a computing device”, which amount to merely “apply it”, as they 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, 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. 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. § 112(a), New Matter, for paragraph 20 of the Final Rejection Office Action dated February 10, 2026, Applicant has adequately amended to render the rejection under 35 U.S.C. § 112(a), New Matter, moot. Applicant has amended so that claim 1 now recites “executing, by the processer-based server, one or more checks and clears on the user’s transaction history data to eliminate recurring transactions and/or transactions associated with certain category codes as ineligible transactions”, which finds support in the specification, (PG Pub US 20250245661 A1, para 16), which recites “… The processor-based server executes certain checks and clears on the user's retrieved transaction data to eliminate ineligible transactions 204. One of the purposes of the disclosed systems and methods is to eliminate the need for users to disclose sensitive information during an enrollment event such as passwords, healthcare transaction data, travel and location data and the like. As such, 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. …”. Additionally, similar language is recited in claim 4. Examiner hereby rescinds the rejection under 35 U.S.C. § 112(a), New Matter, paragraph 20 (claims 1-6) of the Final Rejection Office Action dated February 10, 2026.
In the context of 35 U.S.C. § 112(a), New Matter, for paragraph 21 of the Final Rejection Office Action dated February 10, 2026, Applicant has adequately amended to render the rejection under 35 U.S.C. § 112(a), New Matter, moot. Applicant has amended so that claim 1 now recites “deeming, by the processor-based server, the multiple eligible transactions as ineligible to be presented to the user for said authentication request”, which finds support in the specification, (PG Pub US 20250245661 A1, para 16), which recites “… As such, ineligible transac-tions 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 …”.
The specification, (‘661 A1, para 20), which recites “… When a user authentication is denied the user may be presented with a new set of eligible transactions to reattempt the authentication process 214 …”, and specification, (‘661 A1, para 21), which recites “… To avoid fraud, each genuine transaction may only be presented to a user once and is thereafter deemed ineli-gible …”, also provides support. Additionally, similar language is recited in claim 4. Examiner hereby rescinds the rejection under 35 U.S.C. § 112(a), New Matter, paragraph 21 (claim 1-6) of the Final Rejection Office Action dated February 10, 2026.
In the context of 35 U.S.C. § 112(b), Relative Terminology, of the Final Rejection Office Action dated February 10, 2026, Applicant has amended to eliminate the relative terminology “high risk” to render the rejection under 35 U.S.C. § 112(b), Relative Terminology, moot. Examiner hereby rescinds the rejection under 35 U.S.C. § 112(b), Relative Terminology, for claims 1-6 of the Final Rejection Office Action dated February 10, 2026.
In the context of 35 U.S.C. § 102, in the Final Rejection Office Action dated February 10, 2026, Applicant’s argument is persuasive to overcome the rejection under 35 U.S.C. § 102. Claim 4 recites a processor-based server in electronic communication with the data warehouse, the processor-based server configured to perform certain specific operations related to eligible transactions. The recitation is not a mere expression of intended use. The "configured to" language of the claims provides specific, structural limitations to the claimed device, such that a device must be able to perform the recited features in order to satisfy the claims. The form of the limitations has long been held to impact structure. Examiner is persuaded and hereby rescinds the rejection under 35 U.S.C. § 102 for claims 4-6 of the Final Rejection Office Action dated February 10, 2026.
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 and a form of fundamental economic principles or practices (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, by a processor-based server, from a data warehouse, transaction history data associated with said bank account data; executing, by the processor-based server, one or more checks and clears on the user's transaction history data to eliminate recurring transactions and/or transactions associated with certain category codes as ineligible transactions; displaying multiple eligible transactions to a user on a user interface of a computing device; receiving, by the processor-based server, authenticating input, wherein the authenticating input comprises transaction identifying data; generating, by the processor-based server, a response to the request for authentication; and deeming, by the processor-based server, the multiple eligible transactions as ineligible to be presented to the user for said authentication request”. 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 processor-based server, from a data warehouse” and “displaying multiple eligible transactions to a user on a user interface of a computing device”, which amount to merely “apply it”, as they 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, 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 nor improve another technology or technical field. 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 for authenticating a user in real-time during an enrollment event, the system comprising: a data warehouse capable of storing and retrieving data; and a processor-based server in electronic communication with the data warehouse, the processor-based server configured to: …”, and “display multiple eligible transactions to a user on a user interface of a computing device”, which amount to merely “apply it”, as they 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 “displaying multiple eligible transactions to a user on a user interface of a computing device”). Therefore, 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 nor improve another technology or technical field. 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. And, as they do no more than employ a computer as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or a technical field, when analyzed under Step 2B.
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 nor improve another technology or technical field.
Hence, claims 1-6 are not patent eligible.
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 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U. S. 1. 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2 and 4-5 are rejected under 35 U.S.C. 103 as being unpatentable over Saville (U. S. Patent Application Publication No. 20080185429 A1), herein referred to as Saville, in view of Rapowitz et al (U. S. Patent Application Publication No. 20230004972 A1), herein referred to as Rapowitz, and in further view of Demir (TR 201214588 A2), herein referred to as Demir.
Regarding claims 1 and 4, Saville specifically discloses a method of real-time authenticating a user in real-time during an enrollment event, the method comprising the steps:
receiving an authentication request comprising a user's bank account data (para 27, “… the cardholder agrees to a PIN-less transaction with a merchant. The merchant, accordingly, requests authentication for the transaction by forwarding details to a financial network host computer system … the system determines whether the transaction card's issuing institution participates in authenticating PIN-less transaction card transactions. If so, the financial network host computer system sends to the cardholder an Internet link to the issuing institutions webpage for authentication. The issuing institution then authenticates the card-holder for Internet PIN-less transactions, and the transaction may proceed …”; FIG. 12, item 1210; para 55, “… first block 1210 the system receives an authorization request for a merchant. The authorization request may include transaction data including the transaction card number, cardholder information, merchant information and transaction information …”);
using the user's bank account data (FIG. 1, items 110, 140; para 30, “… The financial institution 140 may … communicate transaction information, account numbers, authentication, and PINs through the financial network 115, the Internet 125, or other networks to the financial network host computer system 110 …”; para 39, “… The cardholder may also request a transaction using other accounts such as a credit card, a checking account, a savings account, other bank account, or a stored-value account …”), retrieving, by a processor-based server (FIG. 1, items 110, 140; para 30, “… A financial institution 140 may also communicate with the financial network host computer system 110. The financial institution 140 may include … one or more server computers, workstations, web servers, or other suitable computing devices …”; para 34, “… The financial network host computer system 110 and database 112 may be directly connected or coupled through a network 150. The financial network host computer system 110 may include … one or more server computers, workstations, web servers, or other suitable computing devices … A financial network host computer system 110 may comprise any comput-ing device configured to process, manage, complete, analyze, or otherwise address a request to authenticate a cardholder, a request to authorize a PIN-less transaction card transaction, a request to notify financial institutions of compromised accounts, request authentication for a cardholder using a transaction card from a financial institution, receive physical identifiers from the cardholder, retrieve and compare physical identifiers though a network or directly, as well as other similar tasks ...” , from a data warehouse, transaction history data associated with said bank account data (FIG. 9, item 950; para 51, “… A transaction card number is received 805 and a determination is made whether the transaction card has previously enrolled in PIN-less transaction card transactions 807 … If the transaction card has previously been enrolled then the process proceeds as shown in the flowchart 800 in FIG. 8 along blocks 810, 815, 820, 825, 830, 835, 840 and 855. Enrollment begins at block 945. At block 950, the system retrieves past transactions associated with the transaction card number. A combination of valid and invalid transactions are presented to the cardholder at block 955 and the cardholder is asked to select a valid transaction from the list 960. Any number of valid and invalid transaction may be presented in the list …”); …
displaying multiple eligible transactions to a user on a user interface of a computing device (FIG. 9, item 955, and para 51, “… At block 950, the system retrieves past transactions associated with the transaction card number. A combination of valid and invalid transactions are presented to the cardholder at block 955 and the cardholder is asked to select a valid transaction from the list 960. Any number of valid and invalid transaction may be presented in the list … );
receiving, by the processing-based server (FIG. 1, items 110, 140; paras 30 and 34), authenticating input, wherein the authenticating input comprises transaction identifying data (FIG. 10, item 1010, 1020; para 53, “… A transaction card number is received by the financial network host computer system 110 at block 1010. The financial network host computer system 110 determines whether the issuing intuition 140 participates in PIN-less ATM authentication 1015. If not, the authentication is rejected 1040 and the transaction is rejected 1045. If the issuing institution does participate, the financial network host computer system 110 may create a unique transaction token that properly identifies the transaction 1020 and may include transaction details, such as, transaction card number, transaction card holder name, transaction amount, merchant name and location or other transaction identifying information The financial network host computer system 110 then sends a URL to the cardholder that includes and/or refers to the token at block 125. The URL may include the Internet address of the issuing institutions webpage for PIN-less transaction card Internet transaction authentication …”; FIG. 12, items 1210, 1215, 1250; para 55, “… first block 1210 the system receives an authorization request for a merchant. The authorization request may include transaction data including the transaction card number, cardholder information, merchant information and transaction information. The system then determines whether the cardholder's bank participates in PIN-less transaction card transactions in block 1215. While a bank is used to describe this embodiment, the invention is not limited to banks; other financial institutions may be used. If the cardholder's bank participates, the system may create a unique transaction token that identifies the transaction and may contain transaction information at block 1250 …”; );
generating, by the processor-based server (FIG. 1, items 110, 140; paras 30 and 34), a response to the request for authentication (FIG. 12, item 1250, 1255, 1260, 1265, 1270, 1275, 1280; para 55, “… While a bank is used to describe this embodiment, the invention is not limited to banks; other financial institutions may be used. If the cardholder's bank participates, the system may create a unique transaction token that identifies the transaction and may contain transaction information at block 1250. At block 1255 the authorization request is stored in the system. A URL pointing to the bank's webpage and that may include the token is sent to the merchant at block 1260. The merchant may then forward the token to the cardholder 1265. Whereupon the bank's webpage related to the URL is opened either automatically or by initiation by the cardholder. The cardholder logs in and completes any authenticating steps required by the bank. The bank may require any number of authenticating schemes of methods including, but not limited to, passwords, querying for identifying information, biometrics, PINs, PC signatures, and/or other security identifiers. The bank is free to authenticate the cardholder based on any authentication scheme according to the banks specification. If the bank denies authentication at block 1275, the transaction is rejected 1240. If the bank authorizes the transaction at 1275 the bank digitally signs the authentication request 1280 and sends it to the merchant 1285 …”); and …
With respect to claim 4, Saville further discloses a system (FIG. 1, item 100; para 28, “… FIG. 1 illustrates an example of a communications system 100 within which various embodiments of the present invention may be implemented. The system components may be directly connected, or may be connected via a network 150 which may be any combination of the following: the Internet, an IP network, an intranet, a wide-area network ("WAN"), a local-area network ("LAN"), a virtual private network, the Public Switched Telephone Network ("PSTN"), a financial network, a mobile phone network, or any other type of net-work supporting data communication between devices described herein… The financial network may comprise a debit network, an ATM network, a credit card network or any other financial network. A network 150 may include both wired and wireless connections, including optical links. Many other examples are possible and apparent to those skilled in the art in light of this disclosure. In the discussion that follows, a network 150 may or may not be noted specifically. If no specific means of connection is noted, it may be assumed that the link, communication or other connection between devices may be via a network 115 …”) for authenticating a user during an enrollment event, the system comprising:
a data warehouse (FIG. 1, item 112; para 37, “… The financial network host computer system 110 is coupled with a database 112. The database 112 may be coupled to the financial network host computer system 110 either through a network 150 or directly. The database 112 may maintain past transaction card transaction records, hashes of physical identifiers and information regarding whether financial institutions issuing transaction cards participate in online Internet authentication of PIN-less transaction card transactions. The database 112 may comprise one or more different databases, which may be located within a single facility or distributed geographically, in which case a Network 150, as described above, may be used to integrate different components. According to different embodiments of the invention, the database 112 may include any number of tables and sets of tables. One or more of the databases may be a relational database. The database 112 may be incorporated within the financial network host computer system 110 (e.g., within its storage media), or may be a part of a separate system. The financial network host computer system 110 may, therefore, comprise the database 112. The database 112 may be organized in any manner different than described above to provide the functionality called for by the various embodiments, as known by those skilled in the art …”) capable of storing and retrieving data (FIG. 4, item 415; para 44, “… The transaction card may require a PIN to access the funds at block 415. The financial network host computer system 110 retrieves past transaction card transactions associated with the transaction card. The financial network host computer …”; FIG. 8, item 820, para 50, “… A stored PC signature that is associated with the transaction card number is retrieved at block 820. A comparison between the stored and receive PC signature hashes is made at block 825 …”); and
a processor-based server in electronic communication with the data warehouse (FIG. 1, items 110, 115, 120, 125, 140, 150; para 30, “… The financial network 115 in its simplest form provides communication with a financial network host computer system 110, merchants 120, financial institutions 140, ATMs 155, etc. … A financial institution 140 may also communicate with the financial network host computer system 110. The financial institution 140 may include … one or more server computers, workstations, web servers, or other suitable computing devices. The financial institution 140 may be fully located within a single facility or distributed geographically, in which case a financial network 115, the Internet 125, or other network 150, as described above, may be used to integrate different components. The financial institution 140 may … communicate transaction information, account numbers, authentication, and PINs through the financial network 115, the Internet 125, or other networks to the financial network host computer system 110. The financial institution 140 may also communicate with a merchant 120 and/or the cardholder 135 through the financial network 115, the Internet 125, or other networks to the financial network host computer system 110 …”; FIG. 1, items 110, 112, 115, 125, 150; para 34, “… The financial network host computer system 110 and database 112 may be directly connected or coupled through a network 150. The financial network host computer system 110 may include … one or more server computers, workstations, web servers, or other suitable computing devices. The financial network host computer system 110 may be fully located within a single facility or distributed geographically, in which case a financial network 115, the Internet 125, or other Network 150, as described above, may be used to integrate different components. A financial network host computer system 110 may comprise any computing device configured to process, manage, complete, analyze, or otherwise address a request to authenticate a cardholder, a request to authorize a PIN-less transaction card transaction, a request to notify financial institutions of compromised accounts, request authentication for a cardholder using a transaction card from a financial institution, receive physical identifiers from the cardholder, retrieve and compare physical identifiers though a network or directly, as well as other similar tasks …”) the processor-based server configured to: …
Saville does not specifically disclose, however, Rapowitz discloses executing, by the processor-based server (FIG. 1, item 101; para 24, “… FIG. 1 illustrates one example of a computing device 101 that may be used to implement one or more illustrative aspects discussed herein … computing device 101 may … implement one or more aspects of the disclosure by reading and/or executing instructions and performing one or more actions based on the instructions … computing device 101 may represent, be incorporated in, and/or include various devices such as a desktop computer, a computer server, a mobile device (e.g., a laptop computer, a tablet computer, a smart phone, any other types of mobile computing devices, and the like), and/or any other type of data processing device …”, one or more checks and clears on the user's transaction history data to eliminate recurring transactions and/or transactions associated with certain category codes as ineligible transactions (para 55, “… The computing device may determine a merchant category code of the first transaction … the computing device might determine that a merchant category code of a first transaction indicates that the transaction related to a fuel purchase, such that the first authentication question (e.g., generated based on that first transaction) related to the fuel purchase … the second transaction might not have the same merchant category code (e.g., it might relate to a coffee purchase), but the third transaction might the same merchant category code (e.g., it might relate to another fuel purchase). The second transaction (e.g., with a different merchant category code) might be the selected transaction when the response to the first authentication question is incorrect … if a legitimate user has difficulty answering questions about a certain category of transactions (e.g., fuel transactions), that difficulty need not prevent them from accessing their account, as subsequent authentication questions might relate to a different type of transaction. In contrast, the third transaction (e.g., with the same merchant category code as compared to the first transaction) might be the selected transaction when the response to the first authentication question is correct ...”); …
Rapowitz discloses excluding fraudulent transactions in transaction based authentication. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include excluding fraudulent transactions in transaction based authentication, as in Rapowitz, to improve and/or enhance the technology for authentication of pin-less transactions, as in Saville, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a method excluding fraudulent transactions from being presented to the user in an authentication process, which are not memorable to the user or are confusing for a user, enabling a user to be verified in a more reliable and robust manner, thereby improving the safety of financial accounts and computer transaction systems, and positively enhancing the user experience during the authentication process.
Saville and Rapowitz do not specifically disclose, however, Demir discloses deeming, by the processor-based server (FIG. 1, item 6; “… It includes at least one processor (6), which enables the evaluation of whether the answer given by the customer to the question is correct or wrong, and whether the customer's identity should be confirmed in line with the customer's answers to the questions …”), the multiple eligible transactions as ineligible to be presented to the user for said authentication request (“… The processor (6) selects a mandatory question from the pool of questions, which the customer is obliged to answer, within the framework of the predetermined rules (104). The processor (6) records the selected mandatory question (105), thus preventing the customer from being asked the question again in the same meeting ...”).
Demir discloses a call center confirmation system and method. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include a call center confirmation system and method, as in Demir; and to include excluding fraudulent transactions in transaction based authentication, as in Rapowitz, to improve and/or enhance the technology for authentication of pin-less transactions, as in Saville, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a system and method that ensures the security of customer information, and that allows the customer to be asked the most appropriate questions for identity confirmation, thus providing more reliable security, and a better and more user-friendly customer identity confirmation experience.
Regarding claims 2 and 5, Saville, Rapowitz, and Demir disclose the limitations of claims 1 and 4. Saville further discloses the method of claim 1, wherein the authenticating input comprising transaction identifying data includes a merchant's name, transaction date and transaction amount (para 51, “… The list may comprise the date, merchant name, and amount of the transaction, as well as any other transaction identifying information …”; FIG. 10, item 1020; para 53, “… The financial network host computer system 110 determines whether the issuing intuition 140 participates in PIN-less ATM authentication 1015. If not, the authentication is rejected 1040 and the transaction is rejected 1045. If the issuing institution does participate, the financial network host computer system 110 may create a unique transaction token that prop-erly identifies the transaction 1020 and may include transaction details, such as, transaction card number, transaction card holder name, transaction amount, merchant name and location or other transaction identifying information …” ; FIG. 12, item 1210; para 55, “… first block 1210 the system receives an authorization request for a merchant. The authorization request may include transaction data including the transaction card number, cardholder information, merchant information and transaction information …”).
Claims 3 and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Saville (U. S. Patent Application Publication No. 20080185429 A1), herein referred to as Saville, in view of Rapowitz et al (U. S. Patent Application Publication No. 20230004972 A1), herein referred to as Rapowitz, in view of Demir (TR 201214588 A2), herein referred to as Demir, and in further view of Parker et al (U. S. Patent No. 11216805 B2), herein referred to as Parker.
Regarding claims 3 and 6, Saville, Rapowitz, and Demir disclose the limitations of claims 1 and 4. Saville, Rapowitz, and Demir do not specifically disclose, however, Parker discloses the method of claim 1, wherein the steps of receiving transaction history data and executing one or more checks and clears on the user's transaction data is executed by an application programming interface (FIG. 1B, items 147-149; C/L 7/37-41, “… App server 160, 165 may allow a user (payer or payee) to interact with hub 130 via an application programming interface such as COIN API 147 or vault API 148. Vault API 148 can allow user to view historical transaction data, or other stored data, in vault database 149 …”; C/L 10/63-11/13, “… Another aspect of the COIN system can include restful API services, Restful API services are the preferred means by which requests are made of the system. The COIN system can be compatible with a variety of user interface experiences. The restful API is a simple limited noun/verb API that enables a developer to request money movement services within the context of a COIN transaction. The COIN structure can abstract the underlying payment services complexity from the developer for the full lifecycle of those transactions. The API has nouns for COIN, account (of various kinds, such as card, digital network, bank, and others), people, and business. Benefits and capabilities of restful API services can include: defining simple noun/verb pairs for requesting services from COIN transaction service; providing secure authentication mechanism for requesters; securing payload of requests made through the API; and performing validation of API inputs, including scrubbing for malicious inputs …”).
Parker discloses a digital payments hub. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include a digital payments hub, as in Parker; to include a call center confirmation system and method, as in Demir; and to include excluding fraudulent transactions in transaction based authentication, as in Rapowitz, to improve and/or enhance the technology for authentication of pin-less transactions, as in Saville, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a payment event data hub providing instructions or translations through APIs to the bank in the bank’s own language or formatting, so that the bank can provide banking services through the hub to related external or third party systems. The hub can be updated or track the updates of all the related external or third party systems so the bank does not have to update its system when every single possible counter party to a payment event implements an update.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Ghatage et al (U. S. Patent Application Publication No. 20190266610 A1) – Transaction Management Using Machine Learning And Similarity Analysis
Ghatage discloses a device determining one or more trends by using one or more machine learning techniques to process historical transactional information included in a set of historical transactional documents. The device may receive a set of transactional documents associated with transactions between a client organization and a vendor organization. The device may generate, based on the one or more trends, a first set of exceptions indicating that one or more transactional documents are problematic transactional documents. The device may generate, using a similarity analysis technique, a second set of exceptions indicating that one or more additional transactional documents are duplicate transactional documents. The device may generate a set of claims based on one or more exceptions. The device may perform, based on the set of claims, one or more actions associated with correction or prevention of transaction processing errors relating to the set of transactional documents.
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 CHISM/
Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692 August 28, 2026
Prosecution Insights