DETAILED ACTION
Status of the Claims
1. This action is in reply to the application filed on May 7, 2025.
2. Claims 1-20 are currently pending and have been examined.
Notice of Pre-AIA or AIA Status
3. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Interpretation – Broadest Reasonable Interpretation
4. In determining patentability of an invention over the prior art, all claim limitations have been considered and interpreted using the “broadest reasonable interpretation consistent with the specification during the examination of a patent application since the applicant may then amend his claims.” See In re Prater and Wei, 162 USPQ 541, 550 (CCPA 1969); MPEP § 2111. Applicant always has the opportunity to amend the claims during prosecution, and broad interpretation by the examiner reduces the possibility that the claim, once issued, will be interpreted more broadly than is justified. See In re Prater, 162 USPQ 541, 550-51 (CCPA 1969); MPEP § 2111. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 26 USPQ2d 1057 (Fed. Cir. 1993). See also MPEP 2173.05(q) All claim limitations have been considered. Additionally, all words in the claims have been considered in judging the patentability of the claims against the prior art. See MPEP 2143.03.
Language in a method or system claim that states only the intended use or intended result, but does not result in a manipulative difference in the steps of the method claim nor a structural difference between the system claim and the prior art, fails to distinguish the claims from the prior art. In other words, if the prior art structure is capable of performing the intended use, then it meets the claim.
Claim limitations that contain statement(s) such as “if, may, might, can, could”, are treated as containing optional language. As matter of linguistic precision, optional claim elements do not narrow claim limitations, since they can always be omitted.
Claim limitations that contain statement(s) such as “wherein, whereby”, that fail to further define the steps or acts to be performed in method claims or the discrete physical structure required of system claims.
The subject matter of a properly construed claim is defined by the terms that limit its scope. It is this subject matter that must be examined. As a general matter, the grammar and intended meaning of terms used in a claim will dictate whether the language limits the claim scope.
Language that suggests or makes a feature or step optional but does not require that feature or step does not limit the scope of a claim under the broadest reasonable claim interpretation. Claim scope is not limited by claim language that suggests or makes optional but does not require steps to be performed, or by claim language that does not limit a claim to a particular structure. In addition, when a claim requires selection of an element from a list of alternatives, the prior art teaches the element if one of the alternatives is taught by the prior art. See, e.g., Fresenius USA, Inc. v. Baxter Int’l, Inc., 582 F.3d 1288, 1298 (Fed. Cir. 2009). See MPEP 2111.04, 2143.03. The following types of claim language may raise a question as to its limiting effect (this list is not exhaustive):
Preamble (MPEP 2111.02);
Clauses such as “adapted to”, “adapted for”, “wherein”, and “whereby” (MPEP 2111.04)
Contingent limitations (MPEP 2111.04)
Printed matter (MPEP 2111.05) and
Functional language associated with a claim term (MPEP 2181)
Examiner notes that during examination, “claims … are to be given their broadest reasonable interpretation consistent with the specification, and … claim language should be read in light of the specification as it would be interpreted by one of ordinary skill in the art.” See In re Bond, 15 USPQ 1566, 1568 (Fed. Cir. 1990), citing In re Sneed, 218 USPQ 385, 388 (Fed. Cir. 1983). However, "in examining the specification for proper context, [the examiner] will not at any time import limitations from the specification into the claims". See CollegeNet, Inc. v. ApplyYourself, Inc., 75 USPQ2d 1733, 1738 (Fed. Cir. 2005). Construing claims broadly during prosecution is not unfair to the applicant, because the applicant has the opportunity to amend the claims to obtain more precise claim coverage. See In re Yamamoto, 222 USPQ 934, 936 (Fed. Cir. 1984), citing In re Prater, 162 USPQ 541, 550 (CCPA 1969).
As such, while all claim limitations have been considered and all words in the claims have been considered in judging the patentability of the claimed invention, the following language is interpreted as not further limiting the scope of the claimed invention.
As in Claims 1, 19 and 20:
Each of the independent claims recites in part:
receiving a payment request for a payment transaction from a consumer to a merchant using a payment account of the consumer; and
at least one of:
evaluating fraud risk for the payment transaction based on an integration of (i) a verification that the consumer owns the payment account, and (ii) an authentication of the consumer and a verification of the payment request through a mobile device of the consumer; or
processing the payment transaction using a FBO account to make funds from the payment transaction available to the merchant in an instant, comprising:
pulling funds from the payment account to the FBO account; and one of:
(i) transferring funds from a consumer ledger of the FBO account to a merchant ledger of the FBO account; and sending funds from the merchant ledger of the FBO account to a merchant account of the merchant;
(ii) sending funds from the FBO account for consumers to a second FBO account for merchants; and sending funds from the second FBO account to a merchant account of the merchant; or
(iii) sending funds from the FBO account to a DDA account for the merchant; and sending funds from the DDA account for the merchant to a merchant account of the merchant.
Here, in each independent claim, the claim requires receiving a payment request for a payment transaction from a consumer to a merchant using a payment account of the consumer and then at least one of: evaluating fraud risk… or processing the payment transaction using a FBO account comprising pulling funds and one of three limitations noted as (i), (ii) or (iii)… as claimed above. Under a reasonable broadest interpretation, only one of the alternatives needs to be disclosed to teach the claim limitations as the claims do not require both steps to occur and further, only one of the additional limitations under pulling the funds need to be disclosed in order to teach the limitations. This issue cascades into the dependent claims as some of the dependent claims are predicated on the first alternative limitation and others are predicated on the second alternative limitation, which, as noted below, violates 112(d).
As in Claim 6:
comprising evaluating the fraud risk for the payment transaction, wherein the verification of the payment request through the mobile device of the consumer comprises:
sending a message to the mobile device requesting confirmation of authorization for the payment transaction.
Here, the active step is sending a message to the mobile device. The intended use of the message is requesting confirmation of authorization for the payment transaction, however there is no indication that confirmation is provided in the claim, thus the claim requires no more than sending the message for the intended purpose of requesting confirmation.
As in Claim 7:
comprising evaluating the fraud risk for the payment transaction, further comprising:
performing email risk monitoring to assess risks associated with the consumer based on an email address of the consumer.
Here, the active step is performing email risk monitoring, which is recited without any specificity and for the intended use of “to assess risks associated with the consumer based on an email address of the consumer”.
As in Claim 18:
determining whether the consumer is a new user or an existing user for the payment transaction; and
performing a different verification process based on whether the consumer is the new user or the existing user.
Here, the use of the word “whether” presents two alternatives, either the consumer is a new user or an existing user, however the unspecified different verification processes are based on the whether condition does not limit the claim to a particular action based on if the consumer is determined to be a new user or an existing user.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
5. Claims 3-14 are rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
Claim 1, from which each of Claims 3-14 ultimately depend, recites receiving a payment request and “at least one of” two different options. As a matter of interpretation, only one of the two options is required to meet the limitations of the claim recitations. Dependent Claims 3-7 all refer to the first option “evaluating fraud risk…” and then recite additional limitations drawn to those options. Dependent Claims 8-14 all refer to the second option “processing the payment transaction…” and then recite additional limitations drawn to the alternative option.
The dependent claims thus either fail to further limit the subject matter of the claim upon which it depends, dependent on which alternative limitation is engaged in the independent claim and/or fails to include all of the limitations of the claim upon which it depends – again dependent upon the limitations engaged.
Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
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.
6. Claims 1-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
ANALYSIS:
STEP 1:
Does the claimed invention fall within one of the four statutory categories of invention (process, machine, manufacture or composition matter?
Claim 1 recites a method claim. Claim 19 recites a system claim. Claim 20 recites a computer readable medium claim. Currently, the method and computer readable medium claims have separate rejections as being non-statutory (as shown below) however Examiner assumes Applicant will rectify the claims to properly claim the invention as within statutory categories.
STEP 2A:
Prong One: Does the Claim Recite A Judicial Exception (An Abstract Idea, Law of Nature or Natural Phenomenon)? (If Yes, Proceed to Prong Two, If No, the claim is not directed to a judicial exception and qualifies as subject matter patent eligible material)
Claim 1 (and substantially similarly in Claims 19-20) recite the abstract idea of receiving a payment request and at least one of evaluating a fraud risk for the payment transaction or processing the payment transaction. The idea is described by the following limitations:
receiving a payment request for a payment transaction from a consumer to a merchant using a payment account of the consumer; and
at least one of:
evaluating fraud risk for the payment transaction based on an integration of (i) a verification that the consumer owns the payment account, and (ii) an authentication of the consumer and a verification of the payment request of the consumer; or
processing the payment transaction using a FBO account to make funds from the payment transaction available to the merchant in an instant, comprising:
pulling funds from the payment account to the FBO account; and one of:
(i) transferring funds from a consumer ledger of the FBO account to a merchant ledger of the FBO account; and sending funds from the merchant ledger of the FBO account to a merchant account of the merchant;
(ii) sending funds from the FBO account for consumers to a second FBO account for merchants; and sending funds from the second FBO account to a merchant account of the merchant; or
(iii) sending funds from the FBO account to a DDA account for the merchant; and sending funds from the DDA account for the merchant to a merchant account of the merchant.
Under a BRI, the claims reflect no more than an existing approach receiving a payment request and at least one of evaluating a fraud risk or processing a payment transaction by transferring funds using interbank transactions.
As a result, the abstract ideas describe certain methods of organizing human activity.
As to certain methods of organizing human activity, the steps involve fundamental economic practices or practices (including mitigating risk; payment transactions) commercial or legal interactions (business relations – payment transactions) and/or managing personal behavior or relationships or interactions between people (including following rules or instructions) as disclosed above.
In the case of the instant claims, the claims recite no more than receiving a payment request for a payment transaction and at least one of evaluating a fraud risk for the payment transaction by verifying and authenticating of the consumer and a verification of the payment request using generic computer technology to process information or processing the payment transaction by pulling, transferring and sending funds that is only computer-implemented. (Step 2A, Prong 1 – Yes, the claims are abstract)
Prong Two: Does the Claim Recite Additional Elements That Integrate The Judicial Exception Into A Practical Application of the Exception? (If Yes, the claim is not directed to a judicial exception and qualifies as subject matter patent eligible material. If No, Proceed to Step 2B)
The claims do not include additional elements that integrate the judicial exception into a practical application of the exception because the claims do not provide improvements to another technology or technical field, improvements to the functioning of the computer itself, are not applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, are not applying the judicial exception with, or by use of a particular machine, are not effecting a transformation or reduction of a particular article to a different state or thing, and are not applying the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment.
Claim 1 recites that the method is computer-implemented and a mobile device.
Claim 19 recites one or more processors, one or more non-transitory computer-readable media storing computing instructions, and a mobile device.
Claim 20 recites one or more non-transitory computer-readable media, computer instructions, one or more processors and a mobile device.
Further, the method outlined in Claim 1 does not sufficiently tie the method steps to a particular machine within the body of the claim. As such, the recitations are further failing to integrate the judicial exception into a practical application on this basis.
In particular, the claims only recite a mobile device, one or more processors, one or more non-transitory computer-readable media, and computing instructions which are recited at a high level of generality (i.e., as a generic processor performing generic computer functions) such that it amounts to no more than mere instructions to apply the exception using a generic computer component.
Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, Claims 1 and 19-20 are directed to an abstract idea without a practical application. (Step 2A – Prong 2: No, the additional claimed elements are not integrated into a practical application)
STEP 2B: If there is an exception, determine if the claim as a whole recites significantly more than the judicial exception itself.
The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity: i) receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added)); ii) performing repetitive calculations, Flook, 437 U.S. at 594, 198 USPQ2d at 199 (recomputing or readjusting alarm limit values); Bancorp Services v. Sun Life, 687 F.3d 1266, 1278, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012) ("The computer required by some of Bancorp’s claims is employed only for its most basic function, the performance of repetitive calculations, and as such does not impose meaningful limits on the scope of those claims."); iii) electronic recordkeeping, Alice Corp., 134 S. Ct. at 2359, 110 USPQ2d at 1984 (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); iv) storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; v) electronically scanning or extracting data from a physical document, Content Extraction and Transmission, LLC v. Wells Fargo Bank, 776 F.3d 1343, 1348, 113 USPQ2d 1354, 1358 (Fed. Cir. 2014) (optical character recognition); and vi) a web browser’s back and forward button functionality, Internet Patent Corp. v. Active Network, Inc., 790 F.3d 1343, 1348, 115 USPQ2d 1414, 1418 (Fed. Cir. 2015). (MPEP §2106.05(d)(II))
This listing is not meant to imply that all computer functions are well‐understood, routine, conventional activities, or that a claim reciting a generic computer component performing a generic computer function is necessarily ineligible. Courts have held computer‐implemented processes not to be significantly more than an abstract idea (and thus ineligible) where the claim as a whole amounts to nothing more than generic computer functions merely used to implement an abstract idea, such as an idea that could be done by a human analog (i.e., by hand or by merely thinking). On the other hand, courts have held computer-implemented processes to be significantly more than an abstract idea (and thus eligible), where generic computer components are able in combination to perform functions that are not merely generic. (MPEP §2106.05(d)(II) – emphasis added)
Below are examples of other types of activity that the courts have found to be well-understood, routine, conventional activity when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity: recording a customer’s order, Apple, Inc. v. Ameranth, Inc., 842 F.3d 1229, 1244, 120 USPQ2d 1844, 1856 (Fed. Cir. 2016); shuffling and dealing a standard deck of cards, In re Smith, 815 F.3d 816, 819, 118 USPQ2d 1245, 1247 (Fed. Cir. 2016); restricting public access to media by requiring a consumer to view an advertisement, Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 716-17, 112 USPQ2d 1750, 1755-56 (Fed. Cir. 2014); identifying undeliverable mail items, decoding data on those mail items, and creating output data, Return Mail, Inc. v. U.S. Postal Service, -- F.3d --, -- USPQ2d --, slip op. at 32 (Fed. Cir. August 28, 2017); presenting offers and gathering statistics, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93; determining an estimated outcome and setting a price, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93; and arranging a hierarchy of groups, sorting information, eliminating less restrictive pricing information and determining the price, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1331, 115 USPQ2d 1681, 1699 (Fed. Cir. 2015) (MPEP 2106.05(d))
Here, the steps are receiving or transmitting data over a network; performing repetitive calculations; storing and retrieving information in memory and electronically scanning or extracting data– all of which have been recognized by the courts as well-understood, routine and conventional functions.
The claims are directed to an abstract idea with additional generic computer elements that do not add meaningful limitations to the abstract idea because they require no more than a generic computer to perform generic computer functions that are well-understood, routine, and conventional activities previously known in the industry.
For the next step of the analysis, it must be determined whether the limitations present in the claims represent a patent-eligible application of the abstract idea. A claim directed to a judicial exception must be analyzed to determine whether the elements of the claim, considered both individually and as an ordered combination are sufficient to ensure that the claim as a whole amounts to significantly more than the exception itself.
For the role of a computer in a computer implemented invention to be deemed meaningful in the context of this analysis, it must involve more than performance of “well-understood, routine, [and] conventional activities previously known to the industry.” Further, “the mere recitation of a generic computer cannot transform a patent ineligible abstract idea into a patent-eligible invention.”
Applicant’s specification discloses the following:
“Turning to the drawings, FIG. 1 illustrates an exemplary embodiment of a computer system 100, all of which or a portion of which can be suitable for (i) implementing part or all of one or more embodiments of the techniques, methods, and systems and/or (ii) implementing and/or operating part or all of one or more embodiments of the non-transitory computer readable media described herein. As an example, a different or separate one of computer system 100 (and its internal components, or one or more elements of computer system 100) can be suitable for implementing part or all of the techniques described herein. Computer system 100 can comprise chassis 102 containing one or more circuit boards (not shown), a Universal Serial Bus (USB) port 112, a Compact Disc Read-Only Memory (CD-ROM) and/or Digital Video Disc (DVD) drive 116, and a hard drive 114. A representative block diagram of the elements included on the circuit boards inside chassis 102 is shown in FIG. 2. A central processing unit (CPU) 210 in FIG. 2 is coupled to a system bus 214 in FIG. 2. In various embodiments, the architecture of CPU 210 can be compliant with any of a variety of commercially distributed architecture families.” (See Applicant Spec para 22)
“As used herein, “processor” and/or “processing module” means any type of computational circuit, such as but not limited to a microprocessor, a microcontroller, a controller, a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction work (VLIW) microprocessor, a graphics processor, a digital signal processor, or any other type of processor or processing circuit capable of performing the desired functions. In some examples, the one or more processors of the various embodiments disclosed can comprise CPU 210.” (See Applicant Spec para 24)
“When computer system 100 in FIG. 1 is running, program instructions stored on a USB drive in USB port 112, on a CD-ROM or DVD in CD-ROM, and/or DVD drive 116, on hard drive 114, or in memory storage unit 208 (FIG. 2) are executed by CPU 210 (FIG. 2). A portion of the program instructions, stored on these devices can be suitable for carrying out all or at least part of the techniques described herein. In various embodiments, computer system 100 can be reprogrammed with one or more modules, system, applications, and/or databases, such as those described herein, to convert a general purpose computer to a special purpose computer. For purposes of illustration, programs and other executable program components are shown herein as discrete systems, although it is understood that such programs and components may reside at various times in different storage components of computer system 100, and can be executed by CPU 210. Alternatively, or in addition to, the systems and procedures described herein can be implemented in hardware, or a combination of hardware, software, and/or firmware. For example, one or more application specific integrated circuits (ASICs) can be programmed to carry out one or more of the systems and procedures described herein. For example, one or more of the programs and/or executable program components described herein can be implemented in one or more ASICs.” (See Applicant Spec para 28)
“Although computer system 100 is illustrated as a desktop computer in FIG. 1, there can be examples where computer system 100 may take a different form factor while still having functional elements similar to those described for computer system 100. In some embodiments, computer system 100 may comprise a single computer, a single server, or a cluster or collection of computers or servers, or a cloud of computers or servers. Typically, a cluster or collection of servers can be used when the demand on computer system 100 exceeds the reasonable capability of a single server or computer. In certain embodiments, computer system 100 may comprise a portable computer, such as a laptop computer. In certain other embodiments, computer system 100 may comprise a mobile device, such as a smartphone. In certain additional embodiments, computer system 100 may comprise an embedded system.” (See Applicant Spec para 29)
“In some embodiments, backend payment system 310 and/or frontend payment system 320 can each be a computer system, such as computer system 100 (FIG. 1), as described above, and can each be a single computer, a single server, or a cluster or collection of computers or servers, or a cloud of computers or servers. In another embodiment, a single computer system can host backend payment system 310 and/or frontend payment system 320. Additional details regarding backend payment system 310 and/or frontend payment system 320 are described herein.” (See Applicant Spec para 31)
“In certain embodiments, each of the devices or systems shown in FIG. 3, such as consumer device 340, merchant device 350,) used by merchants (e.g., a merchant 351), merchant eCommerce websites (e.g., a merchant eCommerce website hosted by merchant eCommerce server 352 of merchant 351), eCommerce integration client 353, partner financial institution 360, consumer financial institution 370, merchant financial institution 380, can be servers, desktop computers, laptop computers, mobile devices, and/or other endpoint devices. A mobile device can refer to a portable electronic device (e.g., an electronic device easily conveyable by hand by a person of average size) with the capability to present audio and/or visual data (e.g., text, images, videos, music, etc.). For example, a mobile device can include at least one of a digital media player, a cellular telephone (e.g., a smartphone), a personal digital assistant, a handheld digital computer device (e.g., a tablet personal computer device), a laptop computer device (e.g., a notebook computer device, a network computer device), a wearable user computer device, or another portable computer device with the capability to present audio and/or visual data (e.g., images, videos, music, etc.). Thus, in many examples, a mobile device can include a volume and/or weight sufficiently small as to permit the mobile device to be easily conveyable by hand. For examples, in some embodiments, a mobile device can occupy a volume of less than or equal to approximately 1790 cubic centimeters, 2434 cubic centimeters, 2876 cubic centimeters, 4056 cubic centimeters, and/or 5752 cubic centimeters. Further, in these embodiments, a mobile device can weigh less than or equal to 15.6 Newtons, 17.8 Newtons, 22.3 Newtons, 31.2 Newtons, and/or 44.5 Newtons.” (See Applicant Spec para 34)
“Exemplary mobile devices can include (i) an iPod®, iPhone®, iTouch®, iPad®, MacBook® or similar product by Apple Inc. of Cupertino, California, United States of America, or (ii) a Galaxy™ or similar product by the Samsung Group of Samsung Town, Seoul, South Korea. Further, in the same or different embodiments, a mobile device can include an electronic device configured to implement one or more of (i) the iPhone® operating system by Apple Inc. of Cupertino, California, United States of America, (ii) the Android™ operating system developed by the Open Handset Alliance, or (iii) the Windows Mobile™ operating system by Microsoft Corp. of Redmond, Washington, United States of America.” (See Applicant Spec para 35)
“In many embodiments, various systems of backend payment system 310 can be modules of computing instructions (e.g., software modules) stored at non-transitory computer readable media that operate on one or more processors. These systems can perform one or more functions of backend payment system 310. In some embodiments, various systems of backend payment system 310 can be implemented in hardware.” (See Applicant Spec para 40)
“In addition, the methods and system described herein can be at least partially embodied in the form of computer-implemented processes and apparatus for practicing those processes. The disclosed methods may also be at least partially embodied in the form of tangible, non-transitory machine-readable storage media encoded with computer program code. For example, the steps of the methods can be embodied in hardware, in executable instructions executed by a processor (e.g., software), or a combination of the two. The media may include, for example, RAMs, ROMs, CD-ROMs, DVD-ROMs, BD-ROMs, hard disk drives, flash memories or any other non-transitory machine-readable storage medium. When the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the method. The methods may also be at least partially embodied in the form of a computer into which computer program code is loaded or executed, such that, the computer becomes a special purpose computer for practicing the methods. When implemented on a general-purpose computer, the computer program code segments configure the processor to create specific logic circuits. The methods may alternatively be at least partially embodied in application specific integrated circuits for performing the methods.” (See Applicant Spec para 96)
Generic computer components recited as performing generic computer functions that are well-understood, routine and conventional activities amount to no more than implementing the abstract idea with a computerized system.
Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. The collective functions appear to be implemented using conventional computer systemization.
The claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Upon reconsideration of the indicia noted under Step 2A in concert with the Step 2B considerations, the additional claim element(s) amounts to no more than mere instructions to apply the exception using generic computer components. The same analysis applies in Step 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The claim does not provide an inventive concept significantly more than the abstract idea.
Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
The independent claims 1 and 19-20 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent Claims 2-18 further define the abstract idea that is presented in the respective independent Claims 1 and 19-20 and are further grouped as certain methods of organizing human activity and are abstract for the same reasons and basis as presented above.
Dependent claims 15-17 disclose tokenizing sensitive information, creating a user record and detokenizing sensitive information – however do not claim how such steps occur. No additional hardware components other than those found in the respective independent claims is recited, thus it is presumed that the claim is further utilizing the same generic systemization as presented above. The dependent claims do not include any additional elements that integrate the abstract idea into a practical application of the exception or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination.
Therefore, the dependent claims are also directed to an abstract idea.
Thus, Claims 1-20 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Regarding Claims 1-18, Examiner notes that the method of Claims 1-18 would also have been rejected under the earlier §101 standards based upon In re Bilski, which have been superseded by the current §101 standards based upon the Alice-Mayo test. Specifically, Claim 1 contains an insufficient recitation of a machine or transformation as the involvement of the machine. As recited, the machine is merely nominally, insignificantly or tangentially related to the performance of the steps. Examiner notes that the only explicit reference to a machine is in the preamble of Independent Claim 1 as being “computer-implemented” and, in a limitation that authentication and verification of the payment request is through a mobile device of the consumer. There is no direct tie between a machine and the limitations of the independent claim, nor to the subsequent dependent claims. Examiner is only noting this as §101 under the Alice-Mayo test is considered a substantially higher bar than under In re Bilski. Examiner suggests Applicant incorporate language into the body of the claim reciting the machine elements performing the recited process.
Claim 20 is further rejected under 35 U.S.C. §101 because, in order to comply with §101, a computer program product claim must recite that the computer program product comprises a non-transitory computer readable medium having program instructions (or code) embodied thereon and said instructions are configured to control a computer to perform specific functional steps. The claim must then recite the specific functional steps performed by execution of the instructions contained on the computer-readable medium by the computer, rather than reciting the code or software itself (i.e. software per se is not patentable). A computer program product, when properly claimed, describes the method steps performed when executed by a computer system, not the code or software itself.
The preamble for a computer program product has to state that (1) the product is stored on a non-transitory computer-readable medium (which is not fully present), (2) the product can be executed on a computer (which is present) and (3) when executed the product causes the computer to perform a method (which is present) where the further claim limitations are written as method steps. It is the actual the method being performed by the computer which is patentable, rather than the software itself.
Here, the claimed preamble does not indicate that the product is stored on the non-transitory computer-readable media. Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
7. Claim(s) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Teitel et al. (US PG Pub. 2024/0144209) (“Teitel”) in view of Caldwell (US PG Pub. 2021/0241256) (“Caldwell”)
Regarding Claim 1, Teitel discloses the following:
A computer-implemented method comprising:
receiving a payment request for a payment transaction from a consumer to a merchant using a payment account of the consumer; and (See Teital paras 17-20, 22, 49-51 - user data received from user device including a device ID unique to the user device, a purchaser ID that uniquely identifies the purchaser, an indication that the purchaser intends to pay via the payment rail and/or an account number that identifies the institution account operated by the purchase; user device initiates the transaction)
at least one of:
evaluating fraud risk for the payment transaction based on an integration of (i) a verification that the consumer owns the payment account, and (ii) an authentication of the consumer and a verification of the payment request through a mobile device of the consumer; or (See Teital paras 27-30, 36-37, 52-54, 57, 60-64– user device may be a cellular phone, smart phone, etc.; additionally the screen may be used to request credential information (e.g., a biometric scan, PIN, passcode, a combination thereof, etc.) from the user to initiate a payment [additional verification through a mobile device of the consumer]; user application is downloaded to user device; account database stores information regarding accounts of users or customers of the first institution computing system, also stores transaction location, transaction ID, transaction time for each financial transaction; device ID unique to the user device, purchaser ID uniquely identifying purchaser
processing the payment transaction using a FBO account to make funds from the payment transaction available to the merchant in an instant, comprising: (See Teital paras 23-25, 48, 60-66 – funds may immediately or near immediately hit a recipient’s (e.g., merchant) account
pulling funds from the payment account to the FBO account; and one of: (See Teital paras 60-66
(i) transferring funds from a consumer ledger of the FBO account to a merchant ledger of the FBO account; and sending funds from the merchant ledger of the FBO account to a merchant account of the merchant; (ii) sending funds from the FBO account for consumers to a second FBO account for merchants; and sending funds from the second FBO account to a merchant account of the merchant; or (iii) sending funds from the FBO account to a DDA account for the merchant; and sending funds from the DDA account for the merchant to a merchant account of the merchant. (See Teital paras 17-20, 25-26, 43-47, 60-66 – payment or transaction system includes a user device operated by a purchaser, a terminal device operated by a merchant, a first institution computing system holding an institution account associated with the purchaser, a second institution computing system associated with an institution account held by the merchant and a payment rail computing system.)
While Teital discloses the invention as noted above and in view of the alternate limitations, Teital does not fully disclose evaluating fraud risk for the payment transaction based on an integration of verification that the consumer owns the payment account and an authentication of the consumer and a verification of the payment request through a mobile device of the consumer.
Caldwell discloses his invention as to apparatuses, methods, computer program products, and systems for payment processing. (See Caldwell Abstract) Caldwell discloses that while a credit card, debit card, a prepaid card, or the like may be used as a funding source by a payment module, in certain embodiments, a payment module may replace a payment card in a transaction card with a user’s identity, authenticated on a hardware computing device for the user (e.g., a user’s mobile telephone or the like), verifying funds and directly transferring funds electronically (e.g., using an electronic funds transfer (ETF), an automatic clearing house (ACH) electronic payment, a real-time gross settlement (RTGS) transfer, a wire transfer, a giro transfer or the like) instead of using a card-based payment network. (See Caldwell para 37)
By authenticating an identity of a user on a hardware computing device for the user and accessing aggregated financial accounts of the user, in some embodiments, a payment module may expedite payment to the third-party entity in the transaction (e.g., by verifying funds in at or real time, by transferring funds in at or real time, or the like). (See Caldwell para 38)
In one embodiment, a payment module may determine a likelihood that a proposed transaction is fraudulent, based at least in part on aggregated transaction data for the user, on a location of a user’s hardware computing device and/or of a hardware payment device for a merchant or other third party entity on item level transaction data aggregated for the user, or the like. (See Caldwell para 39) For example, a payment module may compare one or more elements of a transaction to one or more previous transactions aggregated for the user (e.g., to determine a variance from the one or more previous transactions or the like), may compare a location of a mobile hardware computing device to a location of a merchant and/or of a hardware payment terminal for the merchant. (See Caldwell para 39)
In response to determining that a likelihood that a proposed transaction is fraudulent satisfies a fraud threshold, in some embodiments, a payment module may deny the transaction, request a user select a different funding source, notify a user of the fraudulent transaction, request approval for the transaction from the user (e.g., using a separate communications channel such as a text message, a phone call, an email, a push notification on a hardware computing device or the like) and/or take another remedial action. (See Caldwell para 40)
In certain embodiments, a payment module may prompt a user with an offer and/or other message to the user on a hardware computing device of the user based on location data for the hardware computing device in response to location data for the hardware computing device indicating that the user has approached within at least a predefined distance of the merchant or other third-party entity. (See Caldwell para 43)
In one embodiment, a payment module may be part of, integrated with, and/or in communication with a personal financial management (PFM) mobile application executing on a hardware computing device for the user, and may already have access to and authorization from the user to access one or more of the user’s financial accounts (e.g., accounts with a plurality of third-party financial institutions using the user’s electronic credentials. (See Caldwell para 47) A payment module may use the user’s electronic credentials to aggregate transaction data for the user, to verify an availability of funds and/or credit, to send payment for a transaction, or the like. (See Caldwell para 47) In some embodiments, since the user and/or the one or more of the user’s payment sources are already authenticated by a payment module on a hardware computing device for the user, the payment module may offer expedited and/or simplified preorders and/or prepayments (e.g., payment and/or availability of funds/credit may be verified and/or authenticated at time of preorder and/or prepayment, so that a user can simply pick up the order without presenting a card or providing further authentication, or the like). (See Caldwell para 48) In one embodiment, a payment module for a third party entity, in response to a completed transaction or the like may provide item level data for the transaction to a payment module for the user to a backend payment module or the like. (See Caldwell para 49) In other embodiments, a payment module may provide item level data prior to completion of a transaction, and a payment module may use the item level data for fraud detection of the transaction. (See Caldwell para 49)
In one embodiment, a payment module is configured to determine and/or receive a user’s electronic credentials (e.g., username and password, fingerprint scan, retinal scan, digital certificate, PIN, challenge response, security token, hardware token, software token, DNA sequence, signature, facial recognition, voice pattern recognition, bio-electric signals, two-factor authentication credentials, or the like) for one or more third-party entities, financial institutions or the like. (See Caldwell para 50)
In one embodiment, the one or more backend servers and/or one or more backend payment modules provide central management of the networked payment modules – for example, the one or more backend payment modules and/or a backend server may manage validation of availability of funds/credit for an account of a user with a financial institution, may manage electronic transfer of funds between accounts for users and merchants, may store and/or provide access to downloaded user data or the like. (See Caldwell para 63)
The validation module, in one embodiment, may provide a merchant with a risk score for a transaction based on the estimated likelihood that a user will be able to pay for the transaction. (See Caldwell paras 80-85, 87-91)
A further embodiment of a payment module includes an exchange module, a validation module and a transfer module and further includes an authentication module, an access module, an interface module, a route module, a frequence module, a test module, an item level data module, a location module, and a prompt module. (See Caldwell para 96) In one embodiment, the authentication module authenticates a user on a hardware computing device for the user prior to a transaction for the user with a merchant, for example, the authentication module may verify a user’s electronic credentials for an executable application and/or an online account associated with the payment module, a backend server, or the like. (See Caldwell para 97)
The authentication module, in some embodiments, may be configured to verify an identity of an associated user (e.g., to a backend server, to a merchant, or other merchant or other third-party entity to a third-party financial institution or the like) based on data from a sensor of a hardware computing device for the user, based on downloaded and/or aggregated data from a payment module, based on the user’s usage history of a hardware computing device, based on information queried from the user, and/or based on other information available to a hardware computing device in association with a transaction. (See Caldwell para 98) In one embodiment, an authentication module may comprise a trusted repository of a user’s identity information, which the user may authorize to provide certain identity information to one or more merchants or other third party entities which may include user identity information including name, address, telephone number, email address, etc. (See Caldwell para 99)
An authentication module may require verification and/or authentication from a user (e.g., electronic credentials such as username and password, fingerprint scan, etc.) and in certain embodiments, may monitor, store, and/or track certain sensor information (e.g., location data from a GPS sensor, a history of valid and/or invalid authentication or other identity verification events of a user, a transaction history, application install or usage history, mobile wallet or other electronic payment information, health information and/or other information) with the user’s permission, in order to verifying and/or authenticate a user at a later time or the like. (See Caldwell para 100)
In one embodiment, an authentication module may use sensor information, a transaction history, data aggregated by a payment module, or the like, to dispute one or more transactions, verify and/or authenticate a transaction or other event, or the like for a user. (See Caldwell para 101) For example, in certain embodiments, an authentication module may automatically and/or dynamically cross-reference a location of a transaction with a location indicated by sensor information to authenticate, validate, and/or verify that the transaction is being made by the user. (See Caldwell para 101) In one embodiment, for example, an authentication module may determine that a user authenticated in one geographic location, at least a certain distance away from a geographic location at which a transaction occurred, and therefore determine the transaction was fraudulent. (See Caldwell paras 101-102, 107)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the systems and methods for real time or near real time transactions as disclosed by Teital with the fraud risk evaluation, verification and authentication of a consumer in payment transactions as taught by Caldwell in order reduce fraudulent transactions.
Regarding Claim 19, this claim recites substantially similar limitations as those seen in Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Teital discloses the following:
A system comprising one or more processors and one or more non-transitory computer-readable media storing computing instructions that, when executed the one or more processors, cause the one or more processors to perform operations comprising: (See Teital paras 22-23, 30, 34, 40)
Regarding Claim 20, this claim recites substantially similar limitations as those seen in Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Teital discloses the following:
One or more non-transitory computer-readable media comprising computer instructions that, when executed on one or more processors, cause one or more processors to perform operations comprising: (See Teital paras 22-23, 30, 34, 40)
Regarding Claim 2, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Teital discloses the following:
comprising evaluating the fraud risk for the payment transaction, wherein the verification that the consumer owns the payment account comprises: verifying at least one of a name, an address, or a card verification value of a card associated with the payment account. (See Teital paras 73-75)
Regarding Claim 3, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Teital discloses the following:
comprising evaluating the fraud risk for the payment transaction, wherein the verification that the consumer owns the payment account comprises: performing account verification using a zero-dollar authorization. (See Teital paras 73-75)
Regarding Claim 4, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Teital discloses the following:
comprising evaluating the fraud risk for the payment transaction, wherein the authentication of the consumer through the mobile device of the consumer comprises: verifying ownership and possession of the mobile device and a phone number associated with the mobile device. (See Teital paras 73-75 – request biometric scan from user to provision a payment as part of user verification)
Regarding Claim 5, this claim recites the limitations of Claim 4 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Teital in view of Caldwell discloses the following:
wherein the authentication of the consumer through the mobile device of the consumer further comprises: determining a likelihood score that the mobile device or the phone number has been compromised or used for fraud.
While Teital discloses the invention as noted above and in view of the alternate limitations, Teital does not fully disclose evaluating fraud risk for the payment transaction based on an integration of verification that the consumer owns the payment account and an authentication of the consumer and a verification of the payment request through a mobile device of the consumer or determining a likelihood score that the mobile device or phone number has been compromised or used for fraud.
Caldwell discloses his invention as to apparatuses, methods, computer program products, and systems for payment processing. (See Caldwell Abstract) Caldwell discloses that while a credit card, debit card, a prepaid card, or the like may be used as a funding source by a payment module, in certain embodiments, a payment module may replace a payment card in a transaction card with a user’s identity, authenticated on a hardware computing device for the user (e.g., a user’s mobile telephone or the like), verifying funds and directly transferring funds electronically (e.g., using an electronic funds transfer (ETF), an automatic clearing house (ACH) electronic payment, a real-time gross settlement (RTGS) transfer, a wire transfer, a giro transfer or the like) instead of using a card-based payment network. (See Caldwell para 37)
By authenticating an identity of a user on a hardware computing device for the user and accessing aggregated financial accounts of the user, in some embodiments, a payment module may expedite payment to the third-party entity in the transaction (e.g., by verifying funds in at or real time, by transferring funds in at or real time, or the like). (See Caldwell para 38)
In one embodiment, a payment module may determine a likelihood that a proposed transaction is fraudulent, based at least in part on aggregated transaction data for the user, on a location of a user’s hardware computing device and/or of a hardware payment device for a merchant or other third party entity on item level transaction data aggregated for the user, or the like. (See Caldwell para 39) For example, a payment module may compare one or more elements of a transaction to one or more previous transactions aggregated for the user (e.g., to determine a variance from the one or more previous transactions or the like), may compare a location of a mobile hardware computing device to a location of a merchant and/or of a hardware payment terminal for the merchant. (See Caldwell para 39)
In response to determining that a likelihood that a proposed transaction is fraudulent satisfies a fraud threshold, in some embodiments, a payment module may deny the transaction, request a user select a different funding source, notify a user of the fraudulent transaction, request approval for the transaction from the user (e.g., using a separate communications channel such as a text message, a phone call, an email, a push notification on a hardware computing device or the like) and/or take another remedial action. (See Caldwell para 40)
In certain embodiments, a payment module may prompt a user with an offer and/or other message to the user on a hardware computing device of the user based on location data for the hardware computing device in response to location data for the hardware computing device indicating that the user has approached within at least a predefined distance of the merchant or other third-party entity. (See Caldwell para 43)
In one embodiment, a payment module may be part of, integrated with, and/or in communication with a personal financial management (PFM) mobile application executing on a hardware computing device for the user, and may already have access to and authorization from the user to access one or more of the user’s financial accounts (e.g., accounts with a plurality of third-party financial institutions using the user’s electronic credentials. (See Caldwell para 47) A payment module may use the user’s electronic credentials to aggregate transaction data for the user, to verify an availability of funds and/or credit, to send payment for a transaction, or the like. (See Caldwell para 47) In some embodiments, since the user and/or the one or more of the user’s payment sources are already authenticated by a payment module on a hardware computing device for the user, the payment module may offer expedited and/or simplified preorders and/or prepayments (e.g., payment and/or availability of funds/credit may be verified and/or authenticated at time of preorder and/or prepayment, so that a user can simply pick up the order without presenting a card or providing further authentication, or the like). (See Caldwell para 48) In one embodiment, a payment module for a third party entity, in response to a completed transaction or the like may provide item level data for the transaction to a payment module for the user to a backend payment module or the like. (See Caldwell para 49) In other embodiments, a payment module may provide item level data prior to completion of a transaction, and a payment module may use the item level data for fraud detection of the transaction. (See Caldwell para 49)
In one embodiment, a payment module is configured to determine and/or receive a user’s electronic credentials (e.g., username and password, fingerprint scan, retinal scan, digital certificate, PIN, challenge response, security token, hardware token, software token, DNA sequence, signature, facial recognition, voice pattern recognition, bio-electric signals, two-factor authentication credentials, or the like) for one or more third-party entities, financial institutions or the like. (See Caldwell para 50)
In one embodiment, the one or more backend servers and/or one or more backend payment modules provide central management of the networked payment modules – for example, the one or more backend payment modules and/or a backend server may manage validation of availability of funds/credit for an account of a user with a financial institution, may manage electronic transfer of funds between accounts for users and merchants, may store and/or provide access to downloaded user data or the like. (See Caldwell para 63)
The validation module, in one embodiment, may provide a merchant with a risk score for a transaction based on the estimated likelihood that a user will be able to pay for the transaction. (See Caldwell paras 80-85, 87-91)
A further embodiment of a payment module includes an exchange module, a validation module and a transfer module and further includes an authentication module, an access module, an interface module, a route module, a frequence module, a test module, an item level data module, a location module, and a prompt module. (See Caldwell para 96) In one embodiment, the authentication module authenticates a user on a hardware computing device for the user prior to a transaction for the user with a merchant, for example, the authentication module may verify a user’s electronic credentials for an executable application and/or an online account associated with the payment module, a backend server, or the like. (See Caldwell para 97)
The authentication module, in some embodiments, may be configured to verify an identity of an associated user (e.g., to a backend server, to a merchant, or other merchant or other third-party entity to a third-party financial institution or the like) based on data from a sensor of a hardware computing device for the user, based on downloaded and/or aggregated data from a payment module, based on the user’s usage history of a hardware computing device, based on information queried from the user, and/or based on other information available to a hardware computing device in association with a transaction. (See Caldwell para 98) In one embodiment, an authentication module may comprise a trusted repository of a user’s identity information, which the user may authorize to provide certain identity information to one or more merchants or other third party entities which may include user identity information including name, address, telephone number, email address, etc. (See Caldwell para 99)
An authentication module may require verification and/or authentication from a user (e.g., electronic credentials such as username and password, fingerprint scan, etc.) and in certain embodiments, may monitor, store, and/or track certain sensor information (e.g., location data from a GPS sensor, a history of valid and/or invalid authentication or other identity verification events of a user, a transaction history, application install or usage history, mobile wallet or other electronic payment information, health information and/or other information) with the user’s permission, in order to verifying and/or authenticate a user at a later time or the like. (See Caldwell para 100)
In one embodiment, an authentication module may use sensor information, a transaction history, data aggregated by a payment module, or the like, to dispute one or more transactions, verify and/or authenticate a transaction or other event, or the like for a user. (See Caldwell para 101) For example, in certain embodiments, an authentication module may automatically and/or dynamically cross-reference a location of a transaction with a location indicated by sensor information to authenticate, validate, and/or verify that the transaction is being made by the user. (See Caldwell para 101) In one embodiment, for example, an authentication module may determine that a user authenticated in one geographic location, at least a certain distance away from a geographic location at which a transaction occurred, and therefore determine the transaction was fraudulent. (See Caldwell paras 101-102, 107)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the systems and methods for real time or near real time transactions as disclosed by Teital with the fraud risk evaluation, verification and authentication of a consumer in payment transactions as taught by Caldwell in order reduce fraudulent transactions.
Regarding Claim 6, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Teital in view of Caldwell discloses the following:
comprising evaluating the fraud risk for the payment transaction, wherein the verification of the payment request through the mobile device of the consumer comprises: sending a message to the mobile device requesting confirmation of authorization for the payment transaction.
While Teital discloses the invention as noted above and in view of the alternate limitations, Teital does not fully disclose evaluating fraud risk for the payment transaction based on an integration of verification that the consumer owns the payment account and an authentication of the consumer and a verification of the payment request through a mobile device of the consumer or requesting confirmation for authorization for the payment transaction.
Caldwell discloses his invention as to apparatuses, methods, computer program products, and systems for payment processing. (See Caldwell Abstract) Caldwell discloses that while a credit card, debit card, a prepaid card, or the like may be used as a funding source by a payment module, in certain embodiments, a payment module may replace a payment card in a transaction card with a user’s identity, authenticated on a hardware computing device for the user (e.g., a user’s mobile telephone or the like), verifying funds and directly transferring funds electronically (e.g., using an electronic funds transfer (ETF), an automatic clearing house (ACH) electronic payment, a real-time gross settlement (RTGS) transfer, a wire transfer, a giro transfer or the like) instead of using a card-based payment network. (See Caldwell para 37)
By authenticating an identity of a user on a hardware computing device for the user and accessing aggregated financial accounts of the user, in some embodiments, a payment module may expedite payment to the third-party entity in the transaction (e.g., by verifying funds in at or real time, by transferring funds in at or real time, or the like). (See Caldwell para 38)
In one embodiment, a payment module may determine a likelihood that a proposed transaction is fraudulent, based at least in part on aggregated transaction data for the user, on a location of a user’s hardware computing device and/or of a hardware payment device for a merchant or other third party entity on item level transaction data aggregated for the user, or the like. (See Caldwell para 39) For example, a payment module may compare one or more elements of a transaction to one or more previous transactions aggregated for the user (e.g., to determine a variance from the one or more previous transactions or the like), may compare a location of a mobile hardware computing device to a location of a merchant and/or of a hardware payment terminal for the merchant. (See Caldwell para 39)
In response to determining that a likelihood that a proposed transaction is fraudulent satisfies a fraud threshold, in some embodiments, a payment module may deny the transaction, request a user select a different funding source, notify a user of the fraudulent transaction, request approval for the transaction from the user (e.g., using a separate communications channel such as a text message, a phone call, an email, a push notification on a hardware computing device or the like) and/or take another remedial action. (See Caldwell para 40 – request approval for the transaction)
In certain embodiments, a payment module may prompt a user with an offer and/or other message to the user on a hardware computing device of the user based on location data for the hardware computing device in response to location data for the hardware computing device indicating that the user has approached within at least a predefined distance of the merchant or other third-party entity. (See Caldwell para 43)
In one embodiment, a payment module may be part of, integrated with, and/or in communication with a personal financial management (PFM) mobile application executing on a hardware computing device for the user, and may already have access to and authorization from the user to access one or more of the user’s financial accounts (e.g., accounts with a plurality of third-party financial institutions using the user’s electronic credentials. (See Caldwell para 47) A payment module may use the user’s electronic credentials to aggregate transaction data for the user, to verify an availability of funds and/or credit, to send payment for a transaction, or the like. (See Caldwell para 47) In some embodiments, since the user and/or the one or more of the user’s payment sources are already authenticated by a payment module on a hardware computing device for the user, the payment module may offer expedited and/or simplified preorders and/or prepayments (e.g., payment and/or availability of funds/credit may be verified and/or authenticated at time of preorder and/or prepayment, so that a user can simply pick up the order without presenting a card or providing further authentication, or the like). (See Caldwell para 48) In one embodiment, a payment module for a third party entity, in response to a completed transaction or the like may provide item level data for the transaction to a payment module for the user to a backend payment module or the like. (See Caldwell para 49) In other embodiments, a payment module may provide item level data prior to completion of a transaction, and a payment module may use the item level data for fraud detection of the transaction. (See Caldwell para 49)
In one embodiment, a payment module is configured to determine and/or receive a user’s electronic credentials (e.g., username and password, fingerprint scan, retinal scan, digital certificate, PIN, challenge response, security token, hardware token, software token, DNA sequence, signature, facial recognition, voice pattern recognition, bio-electric signals, two-factor authentication credentials, or the like) for one or more third-party entities, financial institutions or the like. (See Caldwell para 50)
In one embodiment, the one or more backend servers and/or one or more backend payment modules provide central management of the networked payment modules – for example, the one or more backend payment modules and/or a backend server may manage validation of availability of funds/credit for an account of a user with a financial institution, may manage electronic transfer of funds between accounts for users and merchants, may store and/or provide access to downloaded user data or the like. (See Caldwell para 63)
The validation module, in one embodiment, may provide a merchant with a risk score for a transaction based on the estimated likelihood that a user will be able to pay for the transaction. (See Caldwell paras 80-85, 87-91)
A further embodiment of a payment module includes an exchange module, a validation module and a transfer module and further includes an authentication module, an access module, an interface module, a route module, a frequence module, a test module, an item level data module, a location module, and a prompt module. (See Caldwell para 96) In one embodiment, the authentication module authenticates a user on a hardware computing device for the user prior to a transaction for the user with a merchant, for example, the authentication module may verify a user’s electronic credentials for an executable application and/or an online account associated with the payment module, a backend server, or the like. (See Caldwell para 97)
The authentication module, in some embodiments, may be configured to verify an identity of an associated user (e.g., to a backend server, to a merchant, or other merchant or other third-party entity to a third-party financial institution or the like) based on data from a sensor of a hardware computing device for the user, based on downloaded and/or aggregated data from a payment module, based on the user’s usage history of a hardware computing device, based on information queried from the user, and/or based on other information available to a hardware computing device in association with a transaction. (See Caldwell para 98) In one embodiment, an authentication module may comprise a trusted repository of a user’s identity information, which the user may authorize to provide certain identity information to one or more merchants or other third party entities which may include user identity information including name, address, telephone number, email address, etc. (See Caldwell para 99)
An authentication module may require verification and/or authentication from a user (e.g., electronic credentials such as username and password, fingerprint scan, etc.) and in certain embodiments, may monitor, store, and/or track certain sensor information (e.g., location data from a GPS sensor, a history of valid and/or invalid authentication or other identity verification events of a user, a transaction history, application install or usage history, mobile wallet or other electronic payment information, health information and/or other information) with the user’s permission, in order to verifying and/or authenticate a user at a later time or the like. (See Caldwell para 100)
In one embodiment, an authentication module may use sensor information, a transaction history, data aggregated by a payment module, or the like, to dispute one or more transactions, verify and/or authenticate a transaction or other event, or the like for a user. (See Caldwell para 101) For example, in certain embodiments, an authentication module may automatically and/or dynamically cross-reference a location of a transaction with a location indicated by sensor information to authenticate, validate, and/or verify that the transaction is being made by the user. (See Caldwell para 101) In one embodiment, for example, an authentication module may determine that a user authenticated in one geographic location, at least a certain distance away from a geographic location at which a transaction occurred, and therefore determine the transaction was fraudulent. (See Caldwell paras 101-102, 107)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the systems and methods for real time or near real time transactions as disclosed by Teital with the fraud risk evaluation, verification and authentication of a consumer in payment transactions as taught by Caldwell in order reduce fraudulent transactions.
Regarding Claim 7, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Teital in view of Caldwell discloses the following:
comprising evaluating the fraud risk for the payment transaction, further comprising:
performing email risk monitoring to assess risks associated with the consumer based on an email address of the consumer.
While Teital discloses the invention as noted above and in view of the alternate limitations, Teital does not fully disclose evaluating fraud risk for the payment transaction based on an integration of verification that the consumer owns the payment account and an authentication of the consumer and a verification of the payment request through a mobile device of the consumer or determining a likelihood score that the mobile device or phone number has been compromised or used for fraud or assessing risks based on an email address of the consumer.
Caldwell discloses his invention as to apparatuses, methods, computer program products, and systems for payment processing. (See Caldwell Abstract) Caldwell discloses that while a credit card, debit card, a prepaid card, or the like may be used as a funding source by a payment module, in certain embodiments, a payment module may replace a payment card in a transaction card with a user’s identity, authenticated on a hardware computing device for the user (e.g., a user’s mobile telephone or the like), verifying funds and directly transferring funds electronically (e.g., using an electronic funds transfer (ETF), an automatic clearing house (ACH) electronic payment, a real-time gross settlement (RTGS) transfer, a wire transfer, a giro transfer or the like) instead of using a card-based payment network. (See Caldwell para 37)
By authenticating an identity of a user on a hardware computing device for the user and accessing aggregated financial accounts of the user, in some embodiments, a payment module may expedite payment to the third-party entity in the transaction (e.g., by verifying funds in at or real time, by transferring funds in at or real time, or the like). (See Caldwell para 38)
In one embodiment, a payment module may determine a likelihood that a proposed transaction is fraudulent, based at least in part on aggregated transaction data for the user, on a location of a user’s hardware computing device and/or of a hardware payment device for a merchant or other third party entity on item level transaction data aggregated for the user, or the like. (See Caldwell para 39) For example, a payment module may compare one or more elements of a transaction to one or more previous transactions aggregated for the user (e.g., to determine a variance from the one or more previous transactions or the like), may compare a location of a mobile hardware computing device to a location of a merchant and/or of a hardware payment terminal for the merchant. (See Caldwell para 39)
In response to determining that a likelihood that a proposed transaction is fraudulent satisfies a fraud threshold, in some embodiments, a payment module may deny the transaction, request a user select a different funding source, notify a user of the fraudulent transaction, request approval for the transaction from the user (e.g., using a separate communications channel such as a text message, a phone call, an email, a push notification on a hardware computing device or the like) and/or take another remedial action. (See Caldwell para 40)
In certain embodiments, a payment module may prompt a user with an offer and/or other message to the user on a hardware computing device of the user based on location data for the hardware computing device in response to location data for the hardware computing device indicating that the user has approached within at least a predefined distance of the merchant or other third-party entity. (See Caldwell para 43)
In one embodiment, a payment module may be part of, integrated with, and/or in communication with a personal financial management (PFM) mobile application executing on a hardware computing device for the user, and may already have access to and authorization from the user to access one or more of the user’s financial accounts (e.g., accounts with a plurality of third-party financial institutions using the user’s electronic credentials. (See Caldwell para 47) A payment module may use the user’s electronic credentials to aggregate transaction data for the user, to verify an availability of funds and/or credit, to send payment for a transaction, or the like. (See Caldwell para 47) In some embodiments, since the user and/or the one or more of the user’s payment sources are already authenticated by a payment module on a hardware computing device for the user, the payment module may offer expedited and/or simplified preorders and/or prepayments (e.g., payment and/or availability of funds/credit may be verified and/or authenticated at time of preorder and/or prepayment, so that a user can simply pick up the order without presenting a card or providing further authentication, or the like). (See Caldwell para 48) In one embodiment, a payment module for a third party entity, in response to a completed transaction or the like may provide item level data for the transaction to a payment module for the user to a backend payment module or the like. (See Caldwell para 49) In other embodiments, a payment module may provide item level data prior to completion of a transaction, and a payment module may use the item level data for fraud detection of the transaction. (See Caldwell para 49)
In one embodiment, a payment module is configured to determine and/or receive a user’s electronic credentials (e.g., username and password, fingerprint scan, retinal scan, digital certificate, PIN, challenge response, security token, hardware token, software token, DNA sequence, signature, facial recognition, voice pattern recognition, bio-electric signals, two-factor authentication credentials, or the like) for one or more third-party entities, financial institutions or the like. (See Caldwell para 50)
In one embodiment, the one or more backend servers and/or one or more backend payment modules provide central management of the networked payment modules – for example, the one or more backend payment modules and/or a backend server may manage validation of availability of funds/credit for an account of a user with a financial institution, may manage electronic transfer of funds between accounts for users and merchants, may store and/or provide access to downloaded user data or the like. (See Caldwell para 63)
The validation module, in one embodiment, may provide a merchant with a risk score for a transaction based on the estimated likelihood that a user will be able to pay for the transaction. (See Caldwell paras 80-85, 87-91)
A further embodiment of a payment module includes an exchange module, a validation module and a transfer module and further includes an authentication module, an access module, an interface module, a route module, a frequence module, a test module, an item level data module, a location module, and a prompt module. (See Caldwell para 96) In one embodiment, the authentication module authenticates a user on a hardware computing device for the user prior to a transaction for the user with a merchant, for example, the authentication module may verify a user’s electronic credentials for an executable application and/or an online account associated with the payment module, a backend server, or the like. (See Caldwell para 97)
The authentication module, in some embodiments, may be configured to verify an identity of an associated user (e.g., to a backend server, to a merchant, or other merchant or other third-party entity to a third-party financial institution or the like) based on data from a sensor of a hardware computing device for the user, based on downloaded and/or aggregated data from a payment module, based on the user’s usage history of a hardware computing device, based on information queried from the user, and/or based on other information available to a hardware computing device in association with a transaction. (See Caldwell para 98) In one embodiment, an authentication module may comprise a trusted repository of a user’s identity information, which the user may authorize to provide certain identity information to one or more merchants or other third party entities which may include user identity information including name, address, telephone number, email address, etc. (See Caldwell para 99 – based on email address)
An authentication module may require verification and/or authentication from a user (e.g., electronic credentials such as username and password, fingerprint scan, etc.) and in certain embodiments, may monitor, store, and/or track certain sensor information (e.g., location data from a GPS sensor, a history of valid and/or invalid authentication or other identity verification events of a user, a transaction history, application install or usage history, mobile wallet or other electronic payment information, health information and/or other information) with the user’s permission, in order to verifying and/or authenticate a user at a later time or the like. (See Caldwell para 100)
In one embodiment, an authentication module may use sensor information, a transaction history, data aggregated by a payment module, or the like, to dispute one or more transactions, verify and/or authenticate a transaction or other event, or the like for a user. (See Caldwell para 101) For example, in certain embodiments, an authentication module may automatically and/or dynamically cross-reference a location of a transaction with a location indicated by sensor information to authenticate, validate, and/or verify that the transaction is being made by the user. (See Caldwell para 101) In one embodiment, for example, an authentication module may determine that a user authenticated in one geographic location, at least a certain distance away from a geographic location at which a transaction occurred, and therefore determine the transaction was fraudulent. (See Caldwell paras 101-102, 107)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the systems and methods for real time or near real time transactions as disclosed by Teital with the fraud risk evaluation, verification and authentication of a consumer in payment transactions as taught by Caldwell in order reduce fraudulent transactions.
Regarding Claim 8, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Teital discloses the following:
performing an original credit transaction. (See Teital paras 17, 46-48)
Regarding Claim 9, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Teital discloses the following:
performing a real-time payment. (See Teital paras 17, 46-48)
Regarding Claim 10, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Teital discloses the following:
performing a FedNow payment. (See Teital paras 17, 46-48)
Regarding Claim 11, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Teital in view of Caldwell discloses the following:
comprising processing the payment transaction using the FBO account, further comprising:
transferring funds from the merchant ledger to a payment system fees ledger of the FBO account for processing fees. (See Teital paras 17, 23, 48)
While Teital discloses the invention as noted above and in view of the alternate limitations, Teital does not fully disclose evaluating fraud risk for the payment transaction based on an integration of verification that the consumer owns the payment account and an authentication of the consumer and a verification of the payment request through a mobile device of the consumer or determining a likelihood score that the mobile device or phone number has been compromised or fully transferring fees.
Caldwell discloses his invention as to apparatuses, methods, computer program products, and systems for payment processing. (See Caldwell Abstract) Caldwell discloses that while a credit card, debit card, a prepaid card, or the like may be used as a funding source by a payment module, in certain embodiments, a payment module may replace a payment card in a transaction card with a user’s identity, authenticated on a hardware computing device for the user (e.g., a user’s mobile telephone or the like), verifying funds and directly transferring funds electronically (e.g., using an electronic funds transfer (ETF), an automatic clearing house (ACH) electronic payment, a real-time gross settlement (RTGS) transfer, a wire transfer, a giro transfer or the like) instead of using a card-based payment network. (See Caldwell para 37)
By authenticating an identity of a user on a hardware computing device for the user and accessing aggregated financial accounts of the user, in some embodiments, a payment module may expedite payment to the third-party entity in the transaction (e.g., by verifying funds in at or real time, by transferring funds in at or real time, or the like) and in embodiments, may reduce transaction fees (See Caldwell para 38)
In one embodiment, a payment module may determine a likelihood that a proposed transaction is fraudulent, based at least in part on aggregated transaction data for the user, on a location of a user’s hardware computing device and/or of a hardware payment device for a merchant or other third party entity on item level transaction data aggregated for the user, or the like. (See Caldwell para 39) For example, a payment module may compare one or more elements of a transaction to one or more previous transactions aggregated for the user (e.g., to determine a variance from the one or more previous transactions or the like), may compare a location of a mobile hardware computing device to a location of a merchant and/or of a hardware payment terminal for the merchant. (See Caldwell para 39)
In response to determining that a likelihood that a proposed transaction is fraudulent satisfies a fraud threshold, in some embodiments, a payment module may deny the transaction, request a user select a different funding source, notify a user of the fraudulent transaction, request approval for the transaction from the user (e.g., using a separate communications channel such as a text message, a phone call, an email, a push notification on a hardware computing device or the like) and/or take another remedial action. (See Caldwell para 40) In some embodiments, a payment module may reduce or eliminate interchange fees. (See Caldwell para 41)
In certain embodiments, a payment module may prompt a user with an offer and/or other message to the user on a hardware computing device of the user based on location data for the hardware computing device in response to location data for the hardware computing device indicating that the user has approached within at least a predefined distance of the merchant or other third-party entity. (See Caldwell para 43)
In one embodiment, a payment module may be part of, integrated with, and/or in communication with a personal financial management (PFM) mobile application executing on a hardware computing device for the user, and may already have access to and authorization from the user to access one or more of the user’s financial accounts (e.g., accounts with a plurality of third-party financial institutions using the user’s electronic credentials. (See Caldwell paras 46-47) A payment module may use the user’s electronic credentials to aggregate transaction data for the user, to verify an availability of funds and/or credit, to send payment for a transaction, or the like. (See Caldwell para 47) In some embodiments, since the user and/or the one or more of the user’s payment sources are already authenticated by a payment module on a hardware computing device for the user, the payment module may offer expedited and/or simplified preorders and/or prepayments (e.g., payment and/or availability of funds/credit may be verified and/or authenticated at time of preorder and/or prepayment, so that a user can simply pick up the order without presenting a card or providing further authentication, or the like). (See Caldwell para 48) In one embodiment, a payment module for a third party entity, in response to a completed transaction or the like may provide item level data for the transaction to a payment module for the user to a backend payment module or the like. (See Caldwell para 49) In other embodiments, a payment module may provide item level data prior to completion of a transaction, and a payment module may use the item level data for fraud detection of the transaction. (See Caldwell para 49)
In one embodiment, a payment module is configured to determine and/or receive a user’s electronic credentials (e.g., username and password, fingerprint scan, retinal scan, digital certificate, PIN, challenge response, security token, hardware token, software token, DNA sequence, signature, facial recognition, voice pattern recognition, bio-electric signals, two-factor authentication credentials, or the like) for one or more third-party entities, financial institutions or the like. (See Caldwell para 50)
In one embodiment, the one or more backend servers and/or one or more backend payment modules provide central management of the networked payment modules – for example, the one or more backend payment modules and/or a backend server may manage validation of availability of funds/credit for an account of a user with a financial institution, may manage electronic transfer of funds between accounts for users and merchants, may store and/or provide access to downloaded user data or the like. (See Caldwell para 63)
The validation module, in one embodiment, may provide a merchant with a risk score for a transaction based on the estimated likelihood that a user will be able to pay for the transaction. (See Caldwell paras 80-85, 87-91)
A further embodiment of a payment module includes an exchange module, a validation module and a transfer module and further includes an authentication module, an access module, an interface module, a route module, a frequence module, a test module, an item level data module, a location module, and a prompt module. (See Caldwell para 96) In one embodiment, the authentication module authenticates a user on a hardware computing device for the user prior to a transaction for the user with a merchant, for example, the authentication module may verify a user’s electronic credentials for an executable application and/or an online account associated with the payment module, a backend server, or the like. (See Caldwell para 97)
The authentication module, in some embodiments, may be configured to verify an identity of an associated user (e.g., to a backend server, to a merchant, or other merchant or other third-party entity to a third-party financial institution or the like) based on data from a sensor of a hardware computing device for the user, based on downloaded and/or aggregated data from a payment module, based on the user’s usage history of a hardware computing device, based on information queried from the user, and/or based on other information available to a hardware computing device in association with a transaction. (See Caldwell para 98) In one embodiment, an authentication module may comprise a trusted repository of a user’s identity information, which the user may authorize to provide certain identity information to one or more merchants or other third party entities which may include user identity information including name, address, telephone number, email address, etc. (See Caldwell para 99 – based on email address)
An authentication module may require verification and/or authentication from a user (e.g., electronic credentials such as username and password, fingerprint scan, etc.) and in certain embodiments, may monitor, store, and/or track certain sensor information (e.g., location data from a GPS sensor, a history of valid and/or invalid authentication or other identity verification events of a user, a transaction history, application install or usage history, mobile wallet or other electronic payment information, health information and/or other information) with the user’s permission, in order to verifying and/or authenticate a user at a later time or the like. (See Caldwell para 100)
In one embodiment, an authentication module may use sensor information, a transaction history, data aggregated by a payment module, or the like, to dispute one or more transactions, verify and/or authenticate a transaction or other event, or the like for a user. (See Caldwell para 101) For example, in certain embodiments, an authentication module may automatically and/or dynamically cross-reference a location of a transaction with a location indicated by sensor information to authenticate, validate, and/or verify that the transaction is being made by the user. (See Caldwell para 101) In one embodiment, for example, an authentication module may determine that a user authenticated in one geographic location, at least a certain distance away from a geographic location at which a transaction occurred, and therefore determine the transaction was fraudulent. (See Caldwell paras 101-102, 107)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the systems and methods for real time or near real time transactions as disclosed by Teital with the fraud risk evaluation, verification and authentication of a consumer in payment transactions as taught by Caldwell in order reduce fraudulent transactions.
Regarding Claim 12, this claim recites the limitations of Claim 11 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Teital in view of Caldwell discloses the following:
transferring funds from the merchant ledger to a payment system fees ledger to a client ledger of the FBO account for a revenue share payout. (See Teital paras 17, 23, 48)
While Teital discloses the invention as noted above and in view of the alternate limitations, Teital does not fully disclose evaluating fraud risk for the payment transaction based on an integration of verification that the consumer owns the payment account and an authentication of the consumer and a verification of the payment request through a mobile device of the consumer or determining a likelihood score that the mobile device or phone number has been compromised or fully transferring fees.
Caldwell discloses his invention as to apparatuses, methods, computer program products, and systems for payment processing. (See Caldwell Abstract) Caldwell discloses that while a credit card, debit card, a prepaid card, or the like may be used as a funding source by a payment module, in certain embodiments, a payment module may replace a payment card in a transaction card with a user’s identity, authenticated on a hardware computing device for the user (e.g., a user’s mobile telephone or the like), verifying funds and directly transferring funds electronically (e.g., using an electronic funds transfer (ETF), an automatic clearing house (ACH) electronic payment, a real-time gross settlement (RTGS) transfer, a wire transfer, a giro transfer or the like) instead of using a card-based payment network. (See Caldwell para 37)
By authenticating an identity of a user on a hardware computing device for the user and accessing aggregated financial accounts of the user, in some embodiments, a payment module may expedite payment to the third-party entity in the transaction (e.g., by verifying funds in at or real time, by transferring funds in at or real time, or the like) and in embodiments, may reduce transaction fees (See Caldwell para 38)
In one embodiment, a payment module may determine a likelihood that a proposed transaction is fraudulent, based at least in part on aggregated transaction data for the user, on a location of a user’s hardware computing device and/or of a hardware payment device for a merchant or other third party entity on item level transaction data aggregated for the user, or the like. (See Caldwell para 39) For example, a payment module may compare one or more elements of a transaction to one or more previous transactions aggregated for the user (e.g., to determine a variance from the one or more previous transactions or the like), may compare a location of a mobile hardware computing device to a location of a merchant and/or of a hardware payment terminal for the merchant. (See Caldwell para 39)
In response to determining that a likelihood that a proposed transaction is fraudulent satisfies a fraud threshold, in some embodiments, a payment module may deny the transaction, request a user select a different funding source, notify a user of the fraudulent transaction, request approval for the transaction from the user (e.g., using a separate communications channel such as a text message, a phone call, an email, a push notification on a hardware computing device or the like) and/or take another remedial action. (See Caldwell para 40) In some embodiments, a payment module may reduce or eliminate interchange fees. (See Caldwell para 41)
In certain embodiments, a payment module may prompt a user with an offer and/or other message to the user on a hardware computing device of the user based on location data for the hardware computing device in response to location data for the hardware computing device indicating that the user has approached within at least a predefined distance of the merchant or other third-party entity. (See Caldwell para 43)
In one embodiment, a payment module may be part of, integrated with, and/or in communication with a personal financial management (PFM) mobile application executing on a hardware computing device for the user, and may already have access to and authorization from the user to access one or more of the user’s financial accounts (e.g., accounts with a plurality of third-party financial institutions using the user’s electronic credentials. (See Caldwell paras 46-47) A payment module may use the user’s electronic credentials to aggregate transaction data for the user, to verify an availability of funds and/or credit, to send payment for a transaction, or the like. (See Caldwell para 47) In some embodiments, since the user and/or the one or more of the user’s payment sources are already authenticated by a payment module on a hardware computing device for the user, the payment module may offer expedited and/or simplified preorders and/or prepayments (e.g., payment and/or availability of funds/credit may be verified and/or authenticated at time of preorder and/or prepayment, so that a user can simply pick up the order without presenting a card or providing further authentication, or the like). (See Caldwell para 48) In one embodiment, a payment module for a third party entity, in response to a completed transaction or the like may provide item level data for the transaction to a payment module for the user to a backend payment module or the like. (See Caldwell para 49) In other embodiments, a payment module may provide item level data prior to completion of a transaction, and a payment module may use the item level data for fraud detection of the transaction. (See Caldwell para 49)
In one embodiment, a payment module is configured to determine and/or receive a user’s electronic credentials (e.g., username and password, fingerprint scan, retinal scan, digital certificate, PIN, challenge response, security token, hardware token, software token, DNA sequence, signature, facial recognition, voice pattern recognition, bio-electric signals, two-factor authentication credentials, or the like) for one or more third-party entities, financial institutions or the like. (See Caldwell para 50)
In one embodiment, the one or more backend servers and/or one or more backend payment modules provide central management of the networked payment modules – for example, the one or more backend payment modules and/or a backend server may manage validation of availability of funds/credit for an account of a user with a financial institution, may manage electronic transfer of funds between accounts for users and merchants, may store and/or provide access to downloaded user data or the like. (See Caldwell para 63)
The validation module, in one embodiment, may provide a merchant with a risk score for a transaction based on the estimated likelihood that a user will be able to pay for the transaction. (See Caldwell paras 80-85, 87-91)
A further embodiment of a payment module includes an exchange module, a validation module and a transfer module and further includes an authentication module, an access module, an interface module, a route module, a frequence module, a test module, an item level data module, a location module, and a prompt module. (See Caldwell para 96) In one embodiment, the authentication module authenticates a user on a hardware computing device for the user prior to a transaction for the user with a merchant, for example, the authentication module may verify a user’s electronic credentials for an executable application and/or an online account associated with the payment module, a backend server, or the like. (See Caldwell para 97)
The authentication module, in some embodiments, may be configured to verify an identity of an associated user (e.g., to a backend server, to a merchant, or other merchant or other third-party entity to a third-party financial institution or the like) based on data from a sensor of a hardware computing device for the user, based on downloaded and/or aggregated data from a payment module, based on the user’s usage history of a hardware computing device, based on information queried from the user, and/or based on other information available to a hardware computing device in association with a transaction. (See Caldwell para 98) In one embodiment, an authentication module may comprise a trusted repository of a user’s identity information, which the user may authorize to provide certain identity information to one or more merchants or other third party entities which may include user identity information including name, address, telephone number, email address, etc. (See Caldwell para 99 – based on email address)
An authentication module may require verification and/or authentication from a user (e.g., electronic credentials such as username and password, fingerprint scan, etc.) and in certain embodiments, may monitor, store, and/or track certain sensor information (e.g., location data from a GPS sensor, a history of valid and/or invalid authentication or other identity verification events of a user, a transaction history, application install or usage history, mobile wallet or other electronic payment information, health information and/or other information) with the user’s permission, in order to verifying and/or authenticate a user at a later time or the like. (See Caldwell para 100)
In one embodiment, an authentication module may use sensor information, a transaction history, data aggregated by a payment module, or the like, to dispute one or more transactions, verify and/or authenticate a transaction or other event, or the like for a user. (See Caldwell para 101) For example, in certain embodiments, an authentication module may automatically and/or dynamically cross-reference a location of a transaction with a location indicated by sensor information to authenticate, validate, and/or verify that the transaction is being made by the user. (See Caldwell para 101) In one embodiment, for example, an authentication module may determine that a user authenticated in one geographic location, at least a certain distance away from a geographic location at which a transaction occurred, and therefore determine the transaction was fraudulent. (See Caldwell paras 101-102, 107)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the systems and methods for real time or near real time transactions as disclosed by Teital with the fraud risk evaluation, verification and authentication of a consumer in payment transactions as taught by Caldwell in order reduce fraudulent transactions.
Regarding Claim 13, this claim recites the limitations of Claim 12 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Teital discloses the following:
sending funds from the client ledger to a client external bank account. (See Teital para 74)
Regarding Claim 14, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Teital in view of Caldwell discloses the following:
receiving a refund request from the merchant; (See Teital paras 22-24)
transferring funds from the merchant account to the merchant ledger of the FBO account;
transferring funds from the merchant ledger to the consumer ledger of the FBO account; and
sending funds from the consumer ledger of the FBO account to the payment account.
While Teital discloses the invention as noted above and in view of the alternate limitations, Teital does not fully disclose evaluating fraud risk for the payment transaction based on an integration of verification that the consumer owns the payment account and an authentication of the consumer and a verification of the payment request through a mobile device of the consumer or determining a likelihood score that the mobile device or phone number has been compromised or fully transferring funds and fees.
Caldwell discloses his invention as to apparatuses, methods, computer program products, and systems for payment processing. (See Caldwell Abstract) Caldwell discloses that while a credit card, debit card, a prepaid card, or the like may be used as a funding source by a payment module, in certain embodiments, a payment module may replace a payment card in a transaction card with a user’s identity, authenticated on a hardware computing device for the user (e.g., a user’s mobile telephone or the like), verifying funds and directly transferring funds electronically (e.g., using an electronic funds transfer (ETF), an automatic clearing house (ACH) electronic payment, a real-time gross settlement (RTGS) transfer, a wire transfer, a giro transfer or the like) instead of using a card-based payment network. (See Caldwell para 37)
By authenticating an identity of a user on a hardware computing device for the user and accessing aggregated financial accounts of the user, in some embodiments, a payment module may expedite payment to the third-party entity in the transaction (e.g., by verifying funds in at or real time, by transferring funds in at or real time, or the like) and in embodiments, may reduce transaction fees (See Caldwell para 38)
In one embodiment, a payment module may determine a likelihood that a proposed transaction is fraudulent, based at least in part on aggregated transaction data for the user, on a location of a user’s hardware computing device and/or of a hardware payment device for a merchant or other third party entity on item level transaction data aggregated for the user, or the like. (See Caldwell para 39) For example, a payment module may compare one or more elements of a transaction to one or more previous transactions aggregated for the user (e.g., to determine a variance from the one or more previous transactions or the like), may compare a location of a mobile hardware computing device to a location of a merchant and/or of a hardware payment terminal for the merchant. (See Caldwell para 39)
In response to determining that a likelihood that a proposed transaction is fraudulent satisfies a fraud threshold, in some embodiments, a payment module may deny the transaction, request a user select a different funding source, notify a user of the fraudulent transaction, request approval for the transaction from the user (e.g., using a separate communications channel such as a text message, a phone call, an email, a push notification on a hardware computing device or the like) and/or take another remedial action. (See Caldwell para 40) In some embodiments, a payment module may reduce or eliminate interchange fees. (See Caldwell para 41)
In certain embodiments, a payment module may prompt a user with an offer and/or other message to the user on a hardware computing device of the user based on location data for the hardware computing device in response to location data for the hardware computing device indicating that the user has approached within at least a predefined distance of the merchant or other third-party entity. (See Caldwell para 43)
In one embodiment, a payment module may be part of, integrated with, and/or in communication with a personal financial management (PFM) mobile application executing on a hardware computing device for the user, and may already have access to and authorization from the user to access one or more of the user’s financial accounts (e.g., accounts with a plurality of third-party financial institutions using the user’s electronic credentials. (See Caldwell paras 46-47) A payment module may use the user’s electronic credentials to aggregate transaction data for the user, to verify an availability of funds and/or credit, to send payment for a transaction, or the like. (See Caldwell para 47) In some embodiments, since the user and/or the one or more of the user’s payment sources are already authenticated by a payment module on a hardware computing device for the user, the payment module may offer expedited and/or simplified preorders and/or prepayments (e.g., payment and/or availability of funds/credit may be verified and/or authenticated at time of preorder and/or prepayment, so that a user can simply pick up the order without presenting a card or providing further authentication, or the like). (See Caldwell para 48) In one embodiment, a payment module for a third party entity, in response to a completed transaction or the like may provide item level data for the transaction to a payment module for the user to a backend payment module or the like. (See Caldwell para 49) In other embodiments, a payment module may provide item level data prior to completion of a transaction, and a payment module may use the item level data for fraud detection of the transaction. (See Caldwell para 49)
In one embodiment, a payment module is configured to determine and/or receive a user’s electronic credentials (e.g., username and password, fingerprint scan, retinal scan, digital certificate, PIN, challenge response, security token, hardware token, software token, DNA sequence, signature, facial recognition, voice pattern recognition, bio-electric signals, two-factor authentication credentials, or the like) for one or more third-party entities, financial institutions or the like. (See Caldwell para 50)
In one embodiment, the one or more backend servers and/or one or more backend payment modules provide central management of the networked payment modules – for example, the one or more backend payment modules and/or a backend server may manage validation of availability of funds/credit for an account of a user with a financial institution, may manage electronic transfer of funds between accounts for users and merchants, may store and/or provide access to downloaded user data or the like. (See Caldwell para 63)
The validation module, in one embodiment, may provide a merchant with a risk score for a transaction based on the estimated likelihood that a user will be able to pay for the transaction. (See Caldwell paras 80-85, 87-91)
A further embodiment of a payment module includes an exchange module, a validation module and a transfer module and further includes an authentication module, an access module, an interface module, a route module, a frequence module, a test module, an item level data module, a location module, and a prompt module. (See Caldwell para 96) In one embodiment, the authentication module authenticates a user on a hardware computing device for the user prior to a transaction for the user with a merchant, for example, the authentication module may verify a user’s electronic credentials for an executable application and/or an online account associated with the payment module, a backend server, or the like. (See Caldwell para 97)
The authentication module, in some embodiments, may be configured to verify an identity of an associated user (e.g., to a backend server, to a merchant, or other merchant or other third-party entity to a third-party financial institution or the like) based on data from a sensor of a hardware computing device for the user, based on downloaded and/or aggregated data from a payment module, based on the user’s usage history of a hardware computing device, based on information queried from the user, and/or based on other information available to a hardware computing device in association with a transaction. (See Caldwell para 98) In one embodiment, an authentication module may comprise a trusted repository of a user’s identity information, which the user may authorize to provide certain identity information to one or more merchants or other third party entities which may include user identity information including name, address, telephone number, email address, etc. (See Caldwell para 99 – based on email address)
An authentication module may require verification and/or authentication from a user (e.g., electronic credentials such as username and password, fingerprint scan, etc.) and in certain embodiments, may monitor, store, and/or track certain sensor information (e.g., location data from a GPS sensor, a history of valid and/or invalid authentication or other identity verification events of a user, a transaction history, application install or usage history, mobile wallet or other electronic payment information, health information and/or other information) with the user’s permission, in order to verifying and/or authenticate a user at a later time or the like. (See Caldwell para 100)
In one embodiment, an authentication module may use sensor information, a transaction history, data aggregated by a payment module, or the like, to dispute one or more transactions, verify and/or authenticate a transaction or other event, or the like for a user. (See Caldwell para 101) For example, in certain embodiments, an authentication module may automatically and/or dynamically cross-reference a location of a transaction with a location indicated by sensor information to authenticate, validate, and/or verify that the transaction is being made by the user. (See Caldwell para 101) In one embodiment, for example, an authentication module may determine that a user authenticated in one geographic location, at least a certain distance away from a geographic location at which a transaction occurred, and therefore determine the transaction was fraudulent. (See Caldwell paras 101-102, 107)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the systems and methods for real time or near real time transactions as disclosed by Teital with the fraud risk evaluation, verification and authentication of a consumer in payment transactions as taught by Caldwell in order reduce fraudulent transactions.
Regarding Claim 15, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Teital discloses the following:
tokenizing sensitive information associated with the consumer, wherein the sensitive information comprises at least one of card information of a card associated with the payment account or personal identifiable information of the consumer. (See Teital paras 21-23, 57-58, 61-63 – tokenized account information (e.g., DDA account) may be provided to POS)
Regarding Claim 16, this claim recites the limitations of Claim 15 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Teital discloses the following:
creating a user record for the consumer using the tokenized sensitive information. (See Teital paras 21-23, 57-58, 61-63 – stores tokenized account information)
Regarding Claim 17, this claim recites the limitations of Claim 16 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Teital discloses the following:
detokenizing the tokenized sensitive information before pulling funds from the payment account. (See Teital paras 37, 41, 45-46, 57-58, 66 – may include an account number used to complete transfer of funds)
Regarding Claim 18, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Teital in view of Caldwell discloses the following:
determining whether the consumer is a new user or an existing user for the payment transaction; and
performing a different verification process based on whether the consumer is the new user or the existing user.
While Teital discloses the invention as noted above and in view of the alternate limitations, Teital does not fully disclose evaluating fraud risk for the payment transaction based on an integration of verification that the consumer owns the payment account and an authentication of the consumer and a verification of the payment request through a mobile device of the consumer or determining whether a consumer is a new user or an existing user and performing a different verification process on that basis.
Caldwell discloses his invention as to apparatuses, methods, computer program products, and systems for payment processing. (See Caldwell Abstract) Caldwell discloses that while a credit card, debit card, a prepaid card, or the like may be used as a funding source by a payment module, in certain embodiments, a payment module may replace a payment card in a transaction card with a user’s identity, authenticated on a hardware computing device for the user (e.g., a user’s mobile telephone or the like), verifying funds and directly transferring funds electronically (e.g., using an electronic funds transfer (ETF), an automatic clearing house (ACH) electronic payment, a real-time gross settlement (RTGS) transfer, a wire transfer, a giro transfer or the like) instead of using a card-based payment network. (See Caldwell para 37)
By authenticating an identity of a user on a hardware computing device for the user and accessing aggregated financial accounts of the user, in some embodiments, a payment module may expedite payment to the third-party entity in the transaction (e.g., by verifying funds in at or real time, by transferring funds in at or real time, or the like). (See Caldwell para 38)
In one embodiment, a payment module may determine a likelihood that a proposed transaction is fraudulent, based at least in part on aggregated transaction data for the user, on a location of a user’s hardware computing device and/or of a hardware payment device for a merchant or other third party entity on item level transaction data aggregated for the user, or the like. (See Caldwell para 39) For example, a payment module may compare one or more elements of a transaction to one or more previous transactions aggregated for the user (e.g., to determine a variance from the one or more previous transactions or the like), may compare a location of a mobile hardware computing device to a location of a merchant and/or of a hardware payment terminal for the merchant. (See Caldwell para 39)
In response to determining that a likelihood that a proposed transaction is fraudulent satisfies a fraud threshold, in some embodiments, a payment module may deny the transaction, request a user select a different funding source, notify a user of the fraudulent transaction, request approval for the transaction from the user (e.g., using a separate communications channel such as a text message, a phone call, an email, a push notification on a hardware computing device or the like) and/or take another remedial action. (See Caldwell para 40)
In certain embodiments, a payment module may prompt a user with an offer and/or other message to the user on a hardware computing device of the user based on location data for the hardware computing device in response to location data for the hardware computing device indicating that the user has approached within at least a predefined distance of the merchant or other third-party entity. (See Caldwell para 43)
In one embodiment, a payment module may be part of, integrated with, and/or in communication with a personal financial management (PFM) mobile application executing on a hardware computing device for the user, and may already have access to and authorization from the user to access one or more of the user’s financial accounts (e.g., accounts with a plurality of third-party financial institutions using the user’s electronic credentials. (See Caldwell para 47 – existing user has a different verification process) A payment module may use the user’s electronic credentials to aggregate transaction data for the user, to verify an availability of funds and/or credit, to send payment for a transaction, or the like. (See Caldwell para 47) In some embodiments, since the user and/or the one or more of the user’s payment sources are already authenticated by a payment module on a hardware computing device for the user, the payment module may offer expedited and/or simplified preorders and/or prepayments (e.g., payment and/or availability of funds/credit may be verified and/or authenticated at time of preorder and/or prepayment, so that a user can simply pick up the order without presenting a card or providing further authentication, or the like). (See Caldwell para 48 – pre-existing relationship, different verification process) In one embodiment, a payment module for a third party entity, in response to a completed transaction or the like may provide item level data for the transaction to a payment module for the user to a backend payment module or the like. (See Caldwell para 49) In other embodiments, a payment module may provide item level data prior to completion of a transaction, and a payment module may use the item level data for fraud detection of the transaction. (See Caldwell para 49)
In one embodiment, a payment module is configured to determine and/or receive a user’s electronic credentials (e.g., username and password, fingerprint scan, retinal scan, digital certificate, PIN, challenge response, security token, hardware token, software token, DNA sequence, signature, facial recognition, voice pattern recognition, bio-electric signals, two-factor authentication credentials, or the like) for one or more third-party entities, financial institutions or the like. (See Caldwell para 50)
In one embodiment, the one or more backend servers and/or one or more backend payment modules provide central management of the networked payment modules – for example, the one or more backend payment modules and/or a backend server may manage validation of availability of funds/credit for an account of a user with a financial institution, may manage electronic transfer of funds between accounts for users and merchants, may store and/or provide access to downloaded user data or the like. (See Caldwell para 63)
The validation module, in one embodiment, may provide a merchant with a risk score for a transaction based on the estimated likelihood that a user will be able to pay for the transaction. (See Caldwell paras 80-85, 87-91)
A further embodiment of a payment module includes an exchange module, a validation module and a transfer module and further includes an authentication module, an access module, an interface module, a route module, a frequence module, a test module, an item level data module, a location module, and a prompt module. (See Caldwell para 96) In one embodiment, the authentication module authenticates a user on a hardware computing device for the user prior to a transaction for the user with a merchant, for example, the authentication module may verify a user’s electronic credentials for an executable application and/or an online account associated with the payment module, a backend server, or the like. (See Caldwell para 97)
The authentication module, in some embodiments, may be configured to verify an identity of an associated user (e.g., to a backend server, to a merchant, or other merchant or other third-party entity to a third-party financial institution or the like) based on data from a sensor of a hardware computing device for the user, based on downloaded and/or aggregated data from a payment module, based on the user’s usage history of a hardware computing device, based on information queried from the user, and/or based on other information available to a hardware computing device in association with a transaction. (See Caldwell para 98) In one embodiment, an authentication module may comprise a trusted repository of a user’s identity information, which the user may authorize to provide certain identity information to one or more merchants or other third party entities which may include user identity information including name, address, telephone number, email address, etc. (See Caldwell para 99)
An authentication module may require verification and/or authentication from a user (e.g., electronic credentials such as username and password, fingerprint scan, etc.) and in certain embodiments, may monitor, store, and/or track certain sensor information (e.g., location data from a GPS sensor, a history of valid and/or invalid authentication or other identity verification events of a user, a transaction history, application install or usage history, mobile wallet or other electronic payment information, health information and/or other information) with the user’s permission, in order to verifying and/or authenticate a user at a later time or the like. (See Caldwell para 100)
In one embodiment, an authentication module may use sensor information, a transaction history, data aggregated by a payment module, or the like, to dispute one or more transactions, verify and/or authenticate a transaction or other event, or the like for a user. (See Caldwell para 101) For example, in certain embodiments, an authentication module may automatically and/or dynamically cross-reference a location of a transaction with a location indicated by sensor information to authenticate, validate, and/or verify that the transaction is being made by the user. (See Caldwell para 101) In one embodiment, for example, an authentication module may determine that a user authenticated in one geographic location, at least a certain distance away from a geographic location at which a transaction occurred, and therefore determine the transaction was fraudulent. (See Caldwell paras 101-102, 107)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the systems and methods for real time or near real time transactions as disclosed by Teital with the fraud risk evaluation, verification and authentication of a consumer in payment transactions as taught by Caldwell in order reduce fraudulent transactions.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMBREEN A. ALLADIN whose telephone number is (571)270-3533. The examiner can normally be reached Monday - Friday 9-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Abhishek Vyas can be reached at 571-270-1836. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/AMBREEN A. ALLADIN/Primary Examiner, Art Unit 3691 July 11, 2026
Prosecution Insights