DETAILED ACTION
Status of the Claims
1. This action is in reply to the Request for Reconsideration dated October 16, 2025.
2. Claims 1-3, 5, 8-12, 14, and 17-20 are currently pending and have been examined.
3. Claims 1, 9-10, and 18-20 have been amended.
4. Claims 4, 6-7, 13, 15-16 and 21-23 have been cancelled.
Notice of Pre-AIA or AIA Status
5. 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
6. 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.
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.
Similarly, a method step exercised or triggered upon the satisfaction of a condition, where there remains the possibility that the condition was not satisfied under the broadest reasonable interpretation, is an optional claim limitation. see MPEP § 2103(I)(C); In re Johnson, 77 USPQ2d 1788 (Fed Cir 2006). As the Applicant does not address what happens should the optional claim limitations fail, Examiner assumes that nothing happens (i.e., the method stops). An alternate interpretation is that merely the claim limitations based upon the condition are not triggered or performed.
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, grammar and the plain meaning of terms as understood by one having ordinary skill in the art used in a claim will dictate whether, and to what extent, the language limits the claim scope. see MPEP §2013(I)(C). 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. see MPEP §2013(I)(C).
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.
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.
The following types of claim language may raise a question as to its limiting effect (this list is not exhaustive):
Statements of intended use or field of use, including statements of purpose or intended use in the 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.
In the instant case, the following italicized limitations are expressing the intended use or result of a process step positively recited and are not given weight:
As in Claim 1:
identifying, by the backend computer program, fraud or a threat from the merchant behavioral activity by providing the merchant behavioral activity to a merchant behavioral threat modeler that is trained with prior merchant behavior and/or terminal configuration behavior.
This limitation is reciting training that has taken place outside of the process claimed.
executing, by the backend computer program, a preventative action in response to the identified fraud or threat, wherein the preventative action comprises sending a signal to the point-of-sale terminal that causes the payment terminal to log the merchant out of the payment application.
As in Claims 8 and 17:
wherein the preventative action further comprises sending a second signal to the point-of-sale terminal that causes the point-of-sale terminal to disable the point-of-sale terminal by erasing keys stored by the point-of-sale terminal.
As in Claims 9 and 18:
wherein the preventative action further comprises rejecting a transaction authorization request.
As in Claim 10:
an electronic device executing a backend computer program that is configured to receive the merchant behavioral activity from the threat collector agent computer program, to identity fraud or a threat from the merchant behavioral activity by providing the merchant behavioral activity to a merchant behavioral threat modeler that is trained with prior merchant behavior and/or terminal configuration behavior, and to execute a preventative action in response to the identified fraud or threat, wherein the preventative action comprises sending a signal to the point-of-sale terminal that causes the payment terminal to log the merchant out of the payment application
This limitation is reciting training that has taken place outside of the process claimed.
As in Claim 19:
identifying fraud or a threat from the merchant behavioral activity by providing the merchant behavioral activity to a merchant behavioral threat modeler that is trained with prior merchant behavior and/or terminal configuration behavior
This limitation is reciting training that has taken place outside of the process claimed.
executing a preventative action in response to the identified fraud or threat, wherein the preventative action is based on a merchant profile or a merchant risk category for the merchant, wherein the preventative action comprises sending a signal to the point-of-sale terminal that causes the payment terminal to log the merchant out of the payment application.
As in Claim 20:
wherein the preventative action further comprises requiring out-of-band authentication from the merchant, sending a signal to the payment application that logs the merchant out of the payment application, or rejecting a transaction authorization request.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
7. Claims 1-3, 5, 8-12, 14, and 17-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
The amendment filed June 30, 2025 (previously submitted with the After Final consideration request on May 30, 2025) and the instant amendment filed on October 16, 2025 are objected to under 35 U.S.C. 132(a) because it introduces new matter into the disclosure. 35 U.S.C. 132(a) states that no amendment shall introduce new matter into the disclosure of the invention. The added material which is not supported by the original disclosure is as follows:
As in Claim 1:
“identifying, by the backend computer program, fraud or threat from the merchant behavioral activity by providing the merchant behavioral activity to a merchant behavioral threat modeler that is trained with prior merchant behavior and/or terminal configuration behavior; and
As in Claim 8:
“wherein the preventative action further comprises sending a second signal to the point-of-sale terminal that causes the point-of-sale terminal to disable the point-of-sale terminal by erasing keys stored by the point-of-sale terminal.”
As in Claim 10:
- “an electronic device executing a backend computer that is configured to receive the merchant behavioral activity from the threat collector agent computer program, to identify fraud or a threat from the merchant behavioral activity by providing the merchant behavioral activity to a merchant behavioral threat modeler that is trained with prior merchant behavior and/or terminal configuration behavior…”
As in Claim 17:
“wherein the preventative action further comprises sending a second signal to the point-of-sale terminal that causes the point-of- sale terminal to disable the point-of-sale terminal by erasing keys stored by the point-of-sale terminal.”
As in Claim 19:
“identifying fraud or a threat from the merchant behavioral activity by providing the merchant behavioral activity to a merchant behavioral threat modeler that is trained with prior merchant behavior and/or terminal configuration behavior; and
As to the limitation in Claims 1 and 19 (and similarly in Claim 10) regarding the “identifying, by the backend computer program, fraud or threat from the merchant behavioral activity by providing the merchant behavioral activity to a merchant behavioral threat modeler that is trained with prior merchant behavior and/or terminal configuration behavior”, Examiner will attempt to further clarify the issue.
As seen in Claim 1, for example, the method is receiving, by a backend computer program and from a threat collector agent computer program executed on a POS for a merchant, merchant behavioral activity comprising merchant interaction with a payment application executed by the POS that was captured by the threat collector agent computer program. This is receiving merchant behavioral activity from the POS to the backend computer program.
The second step, which is currently at issue is identifying fraud or a threat from the merchant behavioral activity by providing the merchant behavioral activity to a merchant behavioral threat modeler that is trained with prior merchant behavior and/or terminal configuration behavior.
Therefore, at this juncture in the claim, merchant behavioral activity from the POS has been received by a backend computer program and the backend computer identifies fraud or a threat from the merchant behavioral activity by providing the merchant behavioral activity to a merchant behavioral threat modeler. At this juncture, the merchant behavioral activity from the POS received by the backend computer is being used to identify fraud or a threat by providing the merchant behavioral activity to a merchant behavioral threat modeler. The last part of the limitation is “that is trained with prior merchant behavior and/or terminal configuration behavior” in the manner claimed does not clearly limit this to an embodiment where the merchant behavioral activity from the POS is using a merchant behavioral threat modeler that was trained outside the method in the past and is simply being used as is seen in the specification.
Applicant’s specification indicates that merchant behavioral activity can be provided to a trained merchant behavioral threat modeler. (See Applicant Spec at least paras 4, 13)
Applicant’s specification further indicates that “the trained merchant behavioral threat modeler may be trained on prior merchant behavior and/or terminal configuration behavior”. (See Applicant Spec at least paras 9, 18)
Applicant’s specification further discloses the following:
“In step 220, a computer program executed by the backend may provide the merchant behavioral activity to a trained merchant behavioral threat modeler to determine whether there is a fraud or a threat. For example, the behavioral threat modeler may be trained on prior merchant behavior (e.g., weekday behavior, weekend behavior, peak time behavior, off season behavior, primary user behavior, sub-user behavior, etc.), terminal configuration behavior, mode (offline/online) behavior, etc.” (See Applicant Spec para 46)
Rather, in the manner claimed, the limitation can be read as providing the merchant behavioral activity to the merchant behavioral modeler as part of a training function and being added to the prior merchant behavior and/or terminal configuration behavior, implying a recursive training step. Further, as the limitation is recited in the present tense and presented as if the new merchant behavioral activity is being provided to update the model to identify fraud or threat, the recitations are broader than the specification discloses.
Claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved. See MPEP 2161.01.
Specifically, for software, this can occur when the algorithm or steps/procedure for performing the computer function are not explained at all or are not explained in sufficient detail (simply restating the function recited in the claim is not necessarily sufficient). In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed. See MPEP §§ 2163.02 and 2181, subsection IV. It is not enough that one skilled in the art could write a program to achieve the claimed function, because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. See MPEP 2161.01 (citing Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681-683 (Fed. Cir. 2015)).
However, the specification lacks sufficient support in the disclosure for what computer components and algorithm (e.g., the necessary steps and/or flowcharts) that perform the claimed functions, specifically the training a merchant behavioral threat modeler on prior merchant behavior and/or terminal configuration behavior”, in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor possessed the claimed subject matter at the time of filing.
Instead, the specification merely discloses that a computer program is executed by the backend and may provide the merchant behavioral activity to a “trained merchant behavioral threat modeler” and then ending up with the claimed functional result of “to determine whether there is fraud or a threat”. It appears that the “training” function is actually occurring outside of the bounds of the specification and is being utilized by the backend computer to compare information to an established trained merchant behavioral threat modeler. The analysis performed that results in the claimed functional result amounts to a block box.
Regarding Claims 8 and 17, as seen in paragraph 47, which is the only mention of keys in the entire specification, there is no indication of a second signal. Further, as these claims are dependent on Claims 1 and 10, there is also no embodiment that indicates the limitations of Claim 1 and Claim 8 together or Claim 10 and Claim 17 together.
“If, in step 225, fraud or a threat is detected, in step 230, the backend computer program may take a preventative action with the terminal (e.g., additional authentication, deactivation, etc.) or with the merchant account (e.g., merchant lockout, alerts). The preventative action may be based on, for example, a merchant profile and/or risk category for the merchant. The preventative actions may include soft and hard actions that may be taken by the backend, including issuing a warning, temporary suspending the merchant account suspension, rejecting a transaction, requiring out-of-band authentication, forcing logout from the payment application, etc. For example, the backend may require that the merchant login to the terminal again, may require that the merchant provide out-of-bank authentication, may refuse communications from the terminal, may send a signal to the terminal that causes the terminal to log out of the merchant account, may disable the terminal (e.g., erase keys), etc. The backend computer program may also notify the merchant of the fraud or threat.” (See Applicant Spec para 47)
As such Claims 1-3, 5, 8-12, 14, and 17-20 are rejected under 112(a) for failing to comply with the written description requirement.
Applicant is required to cancel the new matter in the reply to this Office Action.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
8. Claims 1-3, 5, 8-12, 14 and 17-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1, as amended, recites the limitation "…that causes the payment terminal to log the merchant out of the payment application" in the last line of the claim. There is insufficient antecedent basis for this limitation in the claim. The previous references have been to a point-of-sale terminal for a merchant, thus there is insufficient antecedent basis for this limitation in the claim. The specification does not refer to a payment terminal, rather it makes reference to the terminal, appearing to be referring to the POS terminal and will be interpreted in this manner for purposes of examination, however appropriate clarification and correction is required. Claim 10 and Claim 19 recite a substantially similar limitations which are similarly rejected.
Dependent Claims 2-3, 5, 8-9, 11-14, 17-18 and 20 are further rejected as dependent upon a rejected base claim.
As amended, Claim 19 now recites in part “wherein the preventative action comprises sending a signal to the point-of-sale terminal that causes the payment terminal to log the merchant out of the payment application”
Claim 20, as amended, recites “wherein the preventative action further comprises requiring out-of-band authentication from the merchant, sending a signal to the payment application that logs the merchant out of the payment application, or rejecting a transaction authorization request”
It is unclear if Applicant intended to amend Claim 20 in accordance with the recitations (as amended) of Claim 19 to comply with the previous 112(a) rejection and this is a typographical error. For purposes of examination, Examiner will assume that Applicant intended to correct the claim. This issue also raises 112(d) issues, below and may raise a 112(a) rejection if this is not a typographical error.
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.
9. Claim 20 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 20 recites “wherein the preventative action further comprises requiring out-of-band authentication from the merchant, sending a signal to the payment application that logs the merchant out of the payment application, or rejecting a transaction authorization request.”
This claim recites dependency on Claim 19 which indicates executing a preventative action in response to the identified fraud or threat… wherein the preventative action comprises sending a signal to the point-of-sale terminal that causes the payment terminal to log the merchant out of the payment application.
Claim 19 again recites a singular preventative action in the wherein clause, thus either Claim 20 is failing to further limit the claim, is or is attempting to recite a different singular preventative action, which would indicate that the claim is failing to include all of the limitations of Claim 19.
As amended, the merchant has already been logged out of the payment application in Claim 19, thus this option of the three alternatives presented does not further limit the claim.
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.
10. Claims 1-3, 5, 8-12, 14, and 17-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 10 purports to be a system claim. Claim 19 recites a non-transitory computer readable storage medium claim.
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 recites the abstract idea of fraud and threat detection prevention. The idea is described by the following limitations:
receiving from a threat collector agent merchant behavioral activity comprising merchant interaction activity with a payment that was captured by the threat collector agent;
identifying fraud or a threat from the merchant behavioral activity by providing the merchant behavioral activity to a merchant behavioral threat modeler that is trained with prior merchant behavior and/or terminal configuration behavior; and
executing a preventative action in response to the identified fraud or threat, wherein the preventative action comprises sending a signal to the point of sale that causes to log the merchant account out of the payment application.
Claim 10 recites the abstract idea of fraud and threat detection prevention. The idea is described by the following limitations:
to capture merchant behavioral activity comprising merchant interaction activity involving the payment;
to receive the merchant behavioral activity from the threat collector agent, to identify fraud or a threat from the merchant behavioral activity by providing the merchant behavioral activity to a merchant behavioral threat modeler, that is trained with prior merchant behavior and/or terminal configuration behavior; and to execute a preventative action in response to the identified fraud or threat, wherein the preventative action comprises sending a signal to the point of sale that causes to log the merchant account out of the payment application.
Claim 19 recites the abstract idea of fraud and threat detection prevention. The idea is described by the following limitations:
receiving from a threat collector agent for a merchant, merchant behavioral activity comprising merchant interaction activity with a payment that was captured by the threat collector agent, wherein the merchant behavioral activity comprises a login time and/or a merchant login account;
identifying fraud or a threat from the merchant behavioral activity by providing the merchant behavioral activity to a merchant behavioral threat modeler that is trained with prior merchant behavior and/or terminal configuration behavior; and
executing a preventative action in response to the identified fraud or threat, wherein the preventative action is based on a merchant profile or a merchant risk category for the merchant, wherein the preventative action comprises sending a signal to the point of sale that causes to log the merchant out of the payment application.
The Applicant Specification indicates that embodiments may monitor user behavior and collect data to derive potential fraud/threats in real time. (See Applicant Spec paras 29-31) Once identified, a set of rules may be applied to determine whether to take preventative action and may be set by an operations team. (See Applicant Spec para 32)
The specification further indicates that a variety of user interfaces may be used to provide communication between a user and a processing machine. (See Applicant Spec para 67) The user interface is typically used by the processing machine for interacting with a user either to convey information or receive information from the user. (See Applicant Spec para 68)
Under a BRI, the claims reflect no more than a user capturing merchant behavioral activity data, providing the data to be compared to prior merchant behavior to identify fraud or a threat and then applying rules to the data to identify a preventative action in response to the identified fraud or threat. As amended, the wherein clause recites sending a signal to the POS terminal that causes the payment application to log the merchant out of the payment application. This could, under a BRI, still be a human actor being instructed to log out of the payment application.
As a result, the abstract ideas describe mental processes and certain methods of organizing human activity.
As to mental processes, the steps describe concepts performed in the human mind including an observation, evaluation, judgment and/or opinion (i.e., receiving merchant behavioral activity; identifying fraud or a threat from the merchant behavioral activity; executing a preventative action in response to the identified fraud or threat) These steps are performing a mental process in a computer environment that recites limitations receiving and evaluating information and with the exception of generic computer-implemented steps, there is nothing in the claims themselves that foreclose them from being practically performed by a human mentally.
As to certain methods of organizing human activity, the steps involve fundamental economic practices of mitigating risk; commercial sales activities or behaviors, business relations; and/or managing personal behavior or relationships between people including following rules or instructions (i.e., receiving merchant behavioral activity involving a payment, identifying fraud or a threat from merchant behavioral activity and executing a preventative action in response to the identified fraud or threat)
In the case of the instant claims, the claims may recite no more than receiving information that a user manually recorded and using generic computer technology to analyze the received information to identify fraud or a threat from the received information and executing a preventative action in response to identified fraud or threat. (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.
In particular, Claim 1 recites a backend computer program; a threat collector agent computer program; a point-of-sale terminal for a merchant; a trained merchant behavioral threat modeler; a payment terminal and a payment application.
Claim 10 recites a point-of-sale terminal for a merchant; a payment application; a threat collector agent computer program; an electronic device executing a backend computer program; a trained merchant behavioral threat modeler and a payment terminal.
Claim 19 recites a non-transitory computer readable storage medium; instructions; one or more computer processors; a threat collector agent computer program executed on a point-of-sale terminal for a merchant; a payment application; a trained merchant behavioral threat modeler and a payment terminal.
In particular, the claims only recite a backend computer program, a threat collector agent computer program, a point of sale terminal for a merchant, a payment application, instructions, one or more computer processors, a non-transitory computer readable storage medium, an electronic device executing a backend computer program, payment terminal, and a trained merchant behavior threat modeler 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. (See MPEP 2106.05(f)) Use of a computer in its ordinary capacity for economic or other tasks (e.g., to receive, store or transmit data) or simply adding a general-purpose computer or computer components after the fact to the abstract idea does not integrate a judicial exception into a practical application or provide significantly more.)
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, 10 and 19 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 (Symantec, TLI, OIP Techs – MPEP 2106.05(d)(II); storing and retrieving information in memory (Versata, OIP Techs – MPEP 2106.05(d)(II) and electronically scanning or extracting data (Content Extraction – MPEP 2106.05(d)(II)– 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:
“Referring to Figure 1, a system for intelligent threat detection and prevention in point-of-sale terminals is disclosed according to an embodiment. System 100 may include electronic device 110, such as a server (e.g., physical and/or cloud-based), a computer (e.g., workstation, desktop, notebook, tablet, etc.), Internet of Things (IoT) appliance, etc. that may execute backend computer program 112. Backend computer program 112 may receive terminal data for point-of-sale terminal 120, such as login time, location (e.g., latitude and longitude, GPS location, etc.), configuration information, merchant account information, etc., as well as terminal activity data (e.g., sales, refunds, declines, account switches, etc.) from point-of-sale terminal 120.” (See Applicant Spec para 0033)
“Point-of-sale terminal 120 may be any suitable device, including dedicated point-of-sale terminals, computer (e.g., tablet computer) executing a payment application, kiosks, etc. Point-of-sale terminal 120 may execute a plurality of computer applications, including threat collector agent 122, payment application 124, etc. Threat collector agent 122 may be a program, application, script, etc. executed by point-of-sale terminal 120 that may collect the terminal data and the terminal activity data and may communicate the data to backend computer program 112. For example, threat collector agent 122 may monitor activities involving payment application 124, such as merchant logins to payment application 124, results of payment authorizations submitted by payment application 124, etc.” (See Applicant Spec para 0034)
“Payment application 124 may be a program, application, script, etc. executed by point-of-sale terminal 120 that may interface with a payment gateway (not shown) for a financial institution. Payment application 124 may capture payment information for a transaction.” (See Applicant Spec para 0035)
“Figure 3 depicts an exemplary computing system for implementing aspects of the present disclosure. Figure 3 depicts exemplary computing device 300. Computing device 300 may represent the system components described herein. Computing device 300 may include processor 305 that may be coupled to memory 310. Memory 310 may include volatile memory. Processor 305 may execute computer-executable program code stored in memory 310, such as software programs 315. Software programs 315 may include one or more of the logical steps disclosed herein as a programmatic instruction, which may be executed by processor 305. Memory 310 may also include data repository 320, which may be nonvolatile memory for data persistence. Processor 305 and memory 310 may be coupled by bus 330. Bus 330 may also be coupled to one or more network interface connectors 340, such as wired network interface 342 or wireless network interface 344. Computing device 300 may also have user interface components, such as screen for displaying graphical user interfaces and receiving input from the user, a mouse, a keyboard and/or other input/output components (not shown).” (See Applicant Spec para 0049)
“Embodiments of the system or portions of the system may be in the form of a “processing machine,” such as a general-purpose computer, for example. As used herein, the term “processing machine is to be understood to include at least one processor that uses at least one memory. The at least one memory stores a set of instructions. The instructions may be either permanently or temporarily stored in the memory or memories of the processing machine. The processor executes the instructions that are stored in the memory or memories in order to process data. The set of instructions may include various instructions that perform a particular task or tasks, such as those tasks described above. Such a set of instructions for performing a particular task may be characterized as a program, software program, or simply software.” (See Applicant Spec para 0052)
“As noted above, the processing machine executes the instructions that are stored in the memory or memories to process data. This processing of data may be in response to commands by a user or users of the processing machine, in response to previous processing, in response to a request by another processing machine and/or any other input, for example.” (See Applicant Spec para 0055)
“As noted above, the processing machine used to implement embodiments may be a general-purpose computer. However, the processing machine described above may also utilize any of a wide variety of other technologies including a special purpose computer, a computer system including, for example, a microcomputer, mini-computer or mainframe, a programmed microprocessor, a micro-controller, a peripheral integrated circuit element, a CSIC (Customer Specific Integrated Circuit) or ASIC (Application Specific Integrated Circuit) or other integrated circuit, a logic circuit, a digital signal processor, a programmable logic device such as a FPGA (Field-Programmable Gate Array), PLD (Programmable Logic Device), PLA (Programmable Logic Array), or PAL (Programmable Array Logic), or any other device or arrangement of devices that is capable of implementing the steps of the processes disclosed herein.” (See Applicant Spec para 0056)
“As described above, a set of instructions may be used in the processing of embodiments. The set of instructions may be in the form of a program or software. The software may be in the form of system software or application software, for example. The software might also be in the form of a collection of separate programs, a program module within a larger program, or a portion of a program module, for example. The software used might also include modular programming in the form of object-oriented programming. The software tells the processing machine what to do with the data being processed.” (See Applicant Spec para 0062)
“As described above, the embodiments may illustratively be embodied in the form of a processing machine, including a computer or computer system, for example, that includes at least one memory. It is to be appreciated that the set of instructions, i.e., the software for example, that enables the computer operating system to perform the operations described above may be contained on any of a wide variety of media or medium, as desired. Further, the data that is processed by the set of instructions might also be contained on any of a wide variety of media or medium. That is, the particular medium, i.e., the memory in the processing machine, utilized to hold the set of instructions and/or the data used in embodiments may take on any variety of physical forms or transmissions, for example. Illustratively, the medium may be in the form of a compact disc, a DVD, an integrated circuit, a hard disk, a floppy disk, an optical disc, a magnetic tape, a RAM, a ROM, a PROM, an EPROM, a wire, a cable, a fiber, a communications channel, a satellite transmission, a memory card, a SIM card, or other remote transmission, as well as any other medium or source of data that may be read by the processors.” (See Applicant Spec para 0065)
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 claims 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, 10 and 19 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
The dependent claims 2-3, 5, 8-9, 11-12, 14, 17-18 and 20 further define the abstract ideas presented in respective Independent Claims 1, 10 and 19 and are further grouped as mental processes and certain methods of organizing human activities and are abstract for the same reasons and basis as presented above.
Dependent Claims 2 and 11 provide further details as to the merchant behavioral activity comprising a login time to the payment application and/or a merchant login account. This still describes the abstract ideas described above.
Dependent Claims 3 and 12 provide further details as to the merchant behavioral activity comprising a geolocation of the point-of-sale terminal. This still describes the abstract ideas described above.
Dependent Claims 5 and 14 provide further details as to the preventative action being based on a merchant profile or a merchant risk category for the merchant. This still describes the abstract ideas described above.
Dependent Claims 8 and 17 provide further details as to the preventative action further comprising sending a second signal to the point-of-sale terminal that causes the point-of-sale terminal to disable the point-of-sale terminal by erasing keys stored by the point-of-sale terminal. The disclosure describes this signal at a high level and may be nothing more than timing out of the application and wiping out stored credentials (disabling the terminal), thus requiring full credentials to re-enter the POS. This still describes the abstract ideas described above as there is no particular description to determine what erasing keys entails, Examiner must view this under the broadest reasonable interpretation which may still be describing abstract ideas (i.e., following rules)
Dependent Claims 9 and 18 provide further details as to the preventative action further comprising rejecting a transaction authorization request. The disclosure describes this concept at a high level and without detail as to how it is accomplished. Under a broadest reasonable interpretation, this is following rules to reject a transaction authorization request. This still describes the abstract ideas described above.
Dependent Claim 20 provides further details as to the preventative action further comprising requiring out-of-band authentication, sending a signal to the payment application that logs the merchant out of the payment application, or rejecting a transaction authorization request. The disclosure describes these concepts at a high level and without detail as to how the steps are accomplished. Under a broadest reasonable interpretation, this may be a human actor making a call, timing out of the application or following rules to reject a transaction authorization request. The disclosure describes the concept at a high level and without detail as to how it is accomplished.
No further additional elements 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-3, 5, 8-12, 14, and 17-20 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
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.
11. Claims 1-3, 5, 8-12, 14, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Hamilton et al. (AU2022204195B2) (“Hamilton”) in view of Hosseinali et al. (US PG Pub. 2024/0211966) (“Hosseinali”)
Regarding Claim 1, Hamilton discloses the following:
A method comprising:
receiving, by a backend computer program and from a threat collector agent computer program executed on a point-of-sale terminal for a merchant, merchant behavioral activity comprising merchant interaction activity with a payment application executed by the point-of-sale terminal that was captured by the threat collector agent computer program; (See Hamilton paras 14, 17, 19-21, 25-26, 28, 30-34, 57, 68, 80-81, 84, 98, 114-116, 141, 148, 156 – POS terminal may be a mobile device running a point-of-sale application. In order to manage its connections, the payment reader may establish a procedure for maintaining a connection with a mobile device belonging to the merchant [merchant POS terminal]; on detecting that a new state that is a deviation from a predicted state as defined by the model has occurred, and exceeds a threshold indicative of risky behavior, the server sends notification to the merchant to check if the deviation is normal and if abnormal, the server cancels any ongoing transactions and alerts the merchant; registration application or payment application, as used here, refers to any registration application that enables communication between users. The registration application can include, for example, a mobile payment application, a text messaging application or a cross-platform instant messaging application. In an implementation, the merchant uses the registration application to register the payment reader with an account association with the registration application; the state machine stores the states of the reader(s) associated with a merchant account or payment application in a database as a data structure; device detection component is configured to generate a behavioral profile of the reader(s) associated with a payment application, for example in response to a received device characteristic over time and then register the reader with a payment processor, such as payment service system for detection during future use)
identifying, by the backend computer program, fraud or a threat from the merchant behavioral activity by providing the merchant behavioral activity to a merchant behavioral threat modeler that is trained with prior merchant behavior and/or terminal configuration behavior; (See Hamilton paras 17-21, 33-34, 43, 57, 80-81, 84, 93, 98, 108-109, 111, 114-116, 141, 146, 158) and
executing, by the backend computer program, a preventative action in response to the identified fraud or threat, wherein the preventative action comprises sending a signal to the point-of-sale terminal that causes the payment terminal to log the merchant out of the payment application. (See Hamilton paras 17-21, 33-34, 43, 86-90, 93, 98, 114-116, 136, 138, 141, 154, 158, 175-177, 186, and Cl. 16)
A payment system may include a point-of-sale (POS) terminal and a payment reader. (See Hamilton para 13) The payment reader and the POS terminal may communicate over a wireless connection such as Bluetooth low energy (BLE). (See Hamilton para 14) The POS terminal may be a mobile device running a point-of-sale application. (See Hamilton para 14)
In one implementation, the present disclosure discloses methods and systems to prevent swapping of a payment reader with another reader by tracking behavior of readers in the field and developing a specific model for the reader based on the behavioral analysis. (See Hamilton para 17) In some embodiments, the behavioral model also predicts and includes within the model past, current, or predicated future state of the entire merchant environment. (See Hamilton para 17 – behavioral model [trained merchant behavioral threat modeler]) Any new state that is a deviation from the predicted state as defined by the model and where the deviation exceeds a threshold, is indicative of an unknown and risky behavior, akin to a fraud attack. (See Hamilton para 17) On detecting that a behavior has changed, the server that perform the behavioral analysis sends notification to the merchant to check if the deviation in behavior is normal. (See Hamilton para 17) If the behavior is indicated to be normal, the server initiates the process of authorizing the new reader. (See Hamilton para 17) If the behavior is not indicated to be normal, the server cancels any ongoing transactions and alerts the merchant. (See Hamilton para 17)
In another implementation, a merchant reader can learn its regular position in relation to the merchant’s point of sale terminal, in terms of either consistent movement or consistent same location or both. (See Hamilton para 18) In the event of a “switcharoo” attack, the merchant reader would change to a new location across the room and remain relatively stable. (See Hamilton para 18) This should trigger the reader purge the connection to the seller’s point of sale terminal, forcing them to repair. (See Hamilton para 18)
In another implementation, a method to obtain an original state of a payment entity, such as a payment reader or a POS terminal, based on a behavioral model that defines an expected behavior of the payment entity. (See Hamilton para 19) The methods and systems detect a change in the original state of the payment entity, for example, if the payment entity moves in a manner different from its normal behavior, disconnects or connects with a new device, and so on. (See Hamilton para 19) The server compares the change of the original state with a threshold value, also referred to as threshold deviation, defined by the behavioral model and if the change of state is not within the threshold deviation, the server either reverts the payment entity to the original state or notifies the merchant to take corrective actions. (See Hamilton para 19 – the server compares the change of the original state with a threshold deviation defined by the behavioral model and if the change is not within the threshold deviation either reverts the payment entity to the original state or notifies the merchant to take corrective action [identifying fraud or a threat from merchant behavioral activity (including merchant behavior and/or terminal configuration behavior) by comparing it with the behavioral model threshold and executing a preventative action to the fraud or threat])
Another kind of attack disclosed by Hamilton is a fraudulent user converting the merchant’s reader into a skimmer by wirelessly connecting to the merchant’s payment reader and downloading malware on the reader. (See Hamilton para 20) To do so, the fraudulent user pairs his/her mobile device to the merchant mobile device by providing a user input such as a button push, when the merchant is not looking. (See Hamilton para 20) Then through the mobile device of the fraudulent user, the fraudulent user can download suspicious software scripts or malware on the payment card reader, thereby taking complete control of the reader and all the data stored thereon unbeknownst to the merchant. (See Hamilton para 20) Once the software or hardware of the payment reader is successfully tampered with, fraudulent user does not even need to be at the merchant location to carry out fraudulent activities. (See Hamilton para 20)
To this end, in one implementation, the payment server [backend computer] stores the association between a payment application [payment application] executing on a mobile device, such as a payment terminal, and a payment reader. (See Hamilton para 21 – merchant POS terminal) Each payment application is connected to a merchant and thus their financial account. (See Hamilton para 21 – merchant payment application executing on POS] Anytime there is a fraudulent user attempting to connect their device, and thereby, their financial account, to the reader, a request is sent to the server to compare whether the payment application executing on the new device, if any, is connecting to the card reader. (See Hamilton para 21 –request sent to the backend computer to determine if there is a fraudulent attempt to connect to the payment application [threat collector agent sends request to the backend]) If not, the primary merchant on the original payment application is sent a notification to confirm association of the second device executing a different payment application. (See Hamilton para 21) Various other conditions may trigger the generation of request, for example, introduction of a new reader, introduction of a previously known but disabled reader, and so on. (See Hamilton para 21)
The electronic interactions between the merchant and the customer take place between the customer’s payment instrument 10 and the merchant’s payment terminal 20. (See Hamilton para 25) The merchant has a payment terminal 20 such as a payment terminal or other electronic device that is capable of processing payment information (e.g., encrypted payment card data and user authentication data) and transaction information (e.g., purchase amount and point-of-purchase information), such as a smart phone or tablet running a payment application. (See Hamilton para 25 – merchant POS [payment terminal] running a payment application) In embodiments, the payment terminal may communicate with payment server over the network. (See Hamilton para 26) Although the payment server may be operated by a single entity, in one embodiment the payment server may include any suitable number of servers operated by any suitable entities, such as a payment service system and one or more banks of the merchant and customer. (See Hamilton para 26)
The payment terminal and the payment server communicate payment and transaction information to determine whether the transaction is authorized. (See Hamilton para 26) For example, payment terminal may provide encrypted payment data, user authentication data, purchase amount information, and point-of-purchase information to payment server over a network. (See Hamilton para 26) The payment server may determine whether the transaction is authorized based on this received information as well as information relating to customer or merchant accounts, and responds to the payment network terminal over the network to indicate whether or not the payment transaction is authorized. (See Hamilton para 26 – receiving payment information from the POS by the payment server and determining whether the transaction is authorized [receiving by the backend computer program payment application information from the merchant POS] In one implementation, the payment server includes payment service system and a bank server collectively operating to permit or reject payment transactions. (See Hamilton para 26)
Hamilton discloses that the term “registration application” or “payment application” as used here, refers to any registration application that enables communication between users (e.g., sender and recipient of a message) over a wired or wireless communications network. (See Hamilton para 30) The registration application can be employed by a service provider that delivers a communication service to users, e.g., chat capability or capability to enter payment information, for example, through a form. (See Hamilton para 30) In an implementation, the merchant uses the registration application to register the payment reader with an account association with the registration application, for example, at the time of pairing or bonding the payment reader with the POS terminal. (See Hamilton para 32) The server can store such relationships between the payment reader and the POS terminal either locally or within the server in specific data structures and in the case of multiple readers, similar to the payment reader being connected to the POS terminal, the server can also store the hierarchy of readers, the identity of such readers, profile of the readers and location of the readers with respect to the POS terminal, among other things. (See Hamilton para 32)
If the payment reader or any other reader connected to the POS terminal changes state with respect to a current state, the server generates a notification, e.g., via the state machine, to indicate to the merchant than an anomaly has occurred. (See Hamilton para 33 – notification sent indicating an anomaly if the payment reader or any other connected reader to the POS changes with respect to the current state) In one implementation, any current transactions may be paused until the merchant has verified the state of all readers, or if the server indicates presence of an unknown reader in proximity to the POS terminal. (See Hamilton para 33) The server can also determine change of state in the context of change in hierarchy of payment readers, detection of another merchant account by detection of a new registration application. (See Hamilton para 34)
The state machine stores the states of the reader or readers associated with a merchant account or payment application in a database as a data structure hereinafter referred to as a reader profile, which corresponds to the identity of the reader in terms of registration number, unique identifier, association of the reader with a payment or merchant account, the association of the reader with a mobile or POS terminal on which a payment application is executing and so on. (See Hamilton para 34 – POS terminal on which a payment application is executing) The reader model or profile can also correspond to the behavior or behaviors associated with the reader and collected and analyzed over time, or even an explicit or desired behavior set at the time of registration. (See Hamilton para 34 - prior merchant and/or terminal configuration behavior) Examples of such behavior includes determination of territory in which the reader operates and accordingly determine, the “movement” profile, for example the merchant may move the reader from one terminal to another terminal, may move the reader laterally or only in a certain direction, or may not move the reader at all, such “movement” behaviors can be stored in movement profiles. (See Hamilton para 34 - prior merchant and/or terminal configuration behavior) The state machine checks the system at predefined time intervals or at random time intervals to determine whether the state of the reader has deviated, above or below a threshold level, from the reader profile. (See Hamilton para 34) If the state machine identifies a deviation of behavior, the state machine contacts the merchant through a communication identifier, e.g., email address, phone number, etc., stored in the payment server. (See Hamilton para 34 – if deviation of behavior is identified, the merchant is contacted) The notification may indicate to the merchant that there is potentially a new reader or new behavior, which may be a fraudulent attempt. (See Hamilton para 34 – notification may indicate fraudulent activity)
The state machine stores a reader profile including behavior at the time of registration of the reader and subsequent association of the reader to a payment application. (See Hamilton para 34, page 8) The state machine can also store the behavior of the reader with respect to the POS terminal and in an implementation also includes device detection components including, but not limited to sensors, detectors, radio frequency transmitters and/or receivers. (See Hamilton para 34, page 8) By leveraging the sensing capabilities of these components, the POS terminal can determine a state of the payment reader at any time and can set a geo-fence within which to track reader profiles. (See Hamilton para 34, page 8) The POS terminal also tracks the movement of the reader and stores such behavior in the reader profile. (See Hamilton para 43) Over time, the POS terminal can track, over time, the movement behavior of the reader, thus the behavior indicates that the reader moves within a certain geo-fence or stays stable on certain days, times, or months. (See Hamilton para 43)
Hamilton discloses that a POS terminal may be any suitable device such as tablet payment instrument 24, mobile payment instrument 26, or payment terminal 28. (See Hamilton para 43 – POS terminal) In the case of a computing device such as tablet payment instrument 24 or mobile payment instrument 26, a point-of-sale application may provide for the entry of purchase and payment information interaction with a customer, and communications with a payment server. (See Hamilton para 43) For example, a payment application may provide a menu of services that merchant is able to select and a series of menus or screens for automating a transaction and may also facilitate the entry of customer authentication information such as signatures, PIN numbers, or biometric information. (See Hamilton para 43 – -payment application)
In some embodiments, a cryptographic processing unit may encrypt and decrypt data based on one or more encryption keys, in a manner that isolates the encryption functionality from other components of payment reader 5 and protects the encryption keys from being exposed to other components of the payment reader. (See Hamilton para 55) In some embodiments, cryptographic memory may be any suitable memory or combination thereof and may include a plurality of sets of instructions for performing cryptographic operations, such as payment processing instructions and cryptographic instructions. (See Hamilton para 56) In some embodiments, cryptographic memory may be any suitable memory and may include a plurality of sets of instructions for performing operations of a payment reader, such as reader profile instructions, any of which may be implemented entirely or partially in firmware stored at memory 148. (See Hamilton para 56)
The reader profile instructions may include instructions for communicating with the payment terminal and payment server to provide information related to characteristics, such as location, signal strength, power levels, radiation levels, and the like, to the payment terminal and server. (See Hamilton para 57) The execution of the reader profile instructions causes collection of reader characteristics, including behavioral characteristics such as geographic locations where the merchant carries the reader, the reader that the merchant uses to sell categories items, the time of day the readers are active, the average amount spent by the buyers in certain merchant categories, the average time the merchant spends in interacting with the reader, and so forth. (See Hamilton para 57)
Operating instructions 130 may also include instructions for interacting with a payment server 40. (See Hamilton para 68) In one embodiment, a payment server 40 may be associated with the payment reader 5 and the point-of-sale application of the POS terminal 15. (See Hamilton para 68) For example, the payment server 40 may have information about payment readers 22 and POS terminals 15 that are registered with the payment server 40 (e.g., based on unique identifiers). (See Hamilton para 68) This information may be used to process transactions with servers of the merchant and customer financial institutions, for providing analysis and reports to a merchant, and aggregating transaction data. (See Hamilton para 68) The payment reader 5 may process payment information (e.g., based on operation of reader chip 100 and transaction chip 140) and communicate that processed payment information to the point-of-sale application, which in turn communicates with the payment server 40. (See Hamilton para 68 – receiving by a backend computer from the POS application) In this manner, messages from the payment reader 5 may be forwarded to the payment server 40, such that the payment reader 5 and payment server 40 may collectively process the payment transaction. (See Hamilton para 68 – processing instructions)
In one implementation, the POS terminal includes one or more components configured specifically to allow the merchant to associate readers with the terminal and track reader characteristics and behavior over time as fraud detection and payment authentication tools. (See Hamilton para 80 – trained fraud/threat detection tools) The POS terminal also includes a signal conditioning and monitoring component, a device detection component, a state machine, and payload or detection sequences, and a registration application, all of which may be within a memory, even if a separate component. (See Hamilton para 80 – threat collector agent) The reader profile includes reader characteristics that include, but are not limited to: detection of location based on change in timing parameters, radiated performance, wireless performance, quality of communication links, radio frequency response, transmission measurements, receiver measurements, location values, and engineering tolerances. (See Hamilton para 80)
In one implementation, the device detection component is configured to detect and track movement of devices, such as readers, through change in reader characteristics, such as location or mechanical and operational differences. (See Hamilton para 81) The device detection component is also configured to generate a behavioral profile of the reader or readers associated with a payment application, for example in response to a received device characteristic over time, and then register the reader with a payment processor, such as payment service system (“PSS”) for detection during a future use. (See Hamilton para 81 – merchant behavioral activity provided to the payment service system via a threat collector agent) The reader profile also includes the mapping of the reader with a payment application and is sent to the PSS coupled to the payment object reader. (See Hamilton para 81)
The behaviors including the reader-terminal-merchant relationship, also referred to as the reader profile or store signature, can be stored in a central payment service system. (See Hamilton para 84 – merchant behavioral activity stored at the payment service system) Similar to the POS terminal, the PSS may include the state machine, the reader profile as received from the POS terminal, and a merchant profile, which is a database of all merchant data and connections of readers to merchants. (See Hamilton para 84)
In an implementation, a merchant launches or opens a registration application or a mobile payment portal (e.g., a payment application installed on the device or a web application in web browser) executing on a mobile device, e.g., a phone or a laptop, or the POS terminal. (See Hamilton para 86 – payment application executed on POS terminal) The registration application can be employed by a service provider that delivers a communication service to users and may include one or more components and/or engines, or a component and/or engine can include one or more applications. (See Hamilton para 86)
The registration application further facilitates collection of and connection between the reader’s behavior and characteristics as profile 246. (See Hamilton para 88) At the time of both detection and validation of the device fingerprint for authentication, it may be useful to have data corresponding to all possible parameters, protocols and test sequences, however the reader may not be prepared or available for all kinds of communication. (See Hamilton para 89) To communicate with the reader, the device detection component 228 determines whether the corresponding communication ports in the reader are available or accessible and/or appropriate software permissions have been obtained to make the communication. (See Hamilton para 89)
The device detection component 228 may also implement logic to interact with the hardware and software components of the device 202-1 to measure the tiniest behavioral differences in the reader and record them as deviations to compare to the reader profile. (See Hamilton para 90)
The device detection component 228 may provide functionality for determining whether a reader is an outlier and for notifying merchants when an outlier is determined. (See Hamilton para 93) For example, the device detection component 228 may determine a fraud score for a reader based [on] comparison with the reader profiles. (See Hamilton para 93) The component may determine whether to associated the reader with fraudulent activity based on the fraud score and may further notify one or more merchants when a reader associated with one or more payment application or merchants has been associated with fraudulent activity. (See Hamilton para 93 – sending a signal [notification] to the reader [POS] associated with the payment application)
After the registration of the device as an authentication tool for any subsequent payment transaction is complete, the relationships that have been set up allow the terminal authenticate a transaction as being safe every time a user presents the payment object. (See Hamilton para 95)
Once saved, the registered device fingerprints or the device-object relationships can be retrieved and used as valid authentication tools for payment instruments at the time of a payment transaction, for example, through a POS terminal. (See Hamilton para 96)
In an implementation, the terminal sends the current state to the payment service system via the communication network for comparison with the reader profile that includes behaviors and previous states of readers connected to the merchant account. (See Hamilton para 98 – merchant POS terminal sends current state to the payment service system to be compared with a reader profile containing behaviors and previous reader states) The device detection component can also fetch the registered reader profile from a local storage unit. (See Hamilton para 98) The device detection component subsequently verifies reader identity based on the comparison – for example, the payment service system compares previously stored reader profiles or fingerprints of the devices registered by the merchant or profile obtained at the POS terminal through the state machine. (See Hamilton para 98) If the state does not match with a reader profile, which means that there is a deviation in behavior, the POS terminal generates a notification for the merchant to authenticate the new reader by providing an authorization code. (See Hamilton para 98) Once authenticated, the reader is added to the merchant list of authorized readers and payment transaction is fulfilled through the issuer, acquirer and card processing network. (See Hamilton para 98)
FIGS. 5A and 5B are sequence flows illustrating an example process 400 of a method of registering a reader as an authorized reader with a payment processing system. (See Hamilton para 106, Fig. 5A-5B) The process 400 can be performed by one or more components, devices, or components such as, but not limited to, the mobile device, the payment service system, merchant device or POS terminal, the payment reader, or payment beacon or other components or devices. (See Hamilton para 107) It will be understood that the method can be carried out by any component of the payment system, e.g., POS terminal, PSS or both, for example contemporaneous to the payment reader. (See Hamilton para 107) As seen above, the relationship between the merchant, the payment application, financial account and reader information is stored either locally on a merchant terminal or on a server. (See Hamilton para 107) This information is then looked up if another reader attempts to connect with the merchant application or terminal. (See Hamilton para 107) The relationship may also store the location coordinates of the reader and other devices and behavioral characteristics as the reader profile. (See Hamilton para 108) Such [behavioral and location coordinates] data is constantly and periodically updated as the behavior of a reader is learned. (See Hamilton para 108) Behavioral characteristics include locations where the reader moves, the items purchased through the reader the time when the reader is active, and so on. (See Hamilton para 108) At time t2, or contemporaneous to the above step, the payment terminal, as part of routine or in response to a trigger condition such as detection of a new device in the near field range, scans the environment to collect state of readers. (See Hamilton para 109) The entry of a new device, such as an unknown reader, may be detected through location detection techniques, such as techniques based on angulation, lateration, proximity detection, dead reckoning, geo-fence, global or local positioning systems, Bluetooth Technology, Near-Field Communication Technology, sensors-based technology, Radio frequency identification (RFID) system, or the like. (See Hamilton para 109) In an embodiment, the present subject matter, the geo-fence is defined and established based on a current location of an asset, for example using GPS data comprising latitude and longitude along with some predetermined area based on range or distance. (See Hamilton para 109)
The POS terminal then determines how it can interact with the devices by detecting devices that are within a communication range dictated by a communication protocol and then establishes communication channels with all or selected readers or other devices in its communication range. (See Hamilton para 111) Accordingly, the device detection component of the terminal generates payload and/or detection sequences adapted based on the available communication ports and in accordance with the communication protocols on which the ports operate and the detection sequences can also be information-gathering requests configured to obtain device fingerprints from the readers. (See Hamilton para 111) The response form the digital device fingerprints, which are to be used for device identification and association of a reader as a registered reader and analyzed. (See Hamilton para 114) The analysis involves decryption of the responses and generation of behavior or trends based on the responses, for example, the analysis involves comparison of the new behavior with an existing reader profile to see if there are any deviations. (See Hamilton para 114) A threshold or confidence score is also set to compare the deviation with. (See Hamilton para 114)
In an embodiment, the server or terminal then compares the deviation with the threshold. (See Hamilton para 115) If the match operation as a result of the comparison yields a “Yes”, the new reader is authenticated as being previously registered or otherwise not fraudulent. (See Hamilton para 115) However, if the match operation yields a “No”, the merchant is sent a notification on his device indicating a potential attempt to fraudulently add a new reader or payment application to the merchant’s account or the merchant is asked to key in a card verification value or some other kind of authentication code into a field in the terminal’s display message. (See Hamilton para 115) The decision of whether or not a new device is potentially fraudulent is thus determined, for example, based on deviation in known behavior of a merchant environment of readers and terminals and their intention with each other and any anomaly there is indicative of a potentially fraudulent event. (See Hamilton para 115)
Hamilton discloses a method to detect swapping of a payment card reader associated with a merchant with another payment card reader associated with a fraudulent user that discloses if a current state of the payment card reader, wherein the current state is capable of reflecting change of behavior of the payment card reader with respect to the POS terminal as a result of swapping between the payment card reader and the other card reader; comparing, by the payment service system, the current state of the payment card reader with the behavioral model of payment card reader, and if the current state indicates a deviation from the behavioral model of the payment object reader due to the other payment card reader and the deviation exceeds a threshold level, generating a notification on the POS terminal to indicate that an attempt to fraudulently swap the payment card reader with the other payment object reader is in progress. (See Hamilton para 136 - generating a notification on the POS terminal [sending a signal to the POS])
Hamilton further discloses that the method further comprises canceling one or more transactions involving the payment card reader and the other payment card reader; and automatically disabling connection between the other payment card reader or the payment card reader and the POS terminal. (See Hamilton para 138 – automatically disabling connection between the other payment card reader and the POS terminal) The disclosure further indicates if the change of state is not within a threshold deviation the method may perform one or more actions to revert the payment entity to the original state. (See Hamilton para 141)
A payment system to perform an action based on a change in behavior of a payment entity is disclosed to include obtaining an original state of a payment entity based on a behavioral model, wherein the behavioral model defines an expected behavior of the payment entity and wherein the payment entity is registered to a merchant and detecting a change in the original state of the payment entity, wherein the change in the original state is triggered by another payment entity not authorized by the merchant. (See Hamilton para 158) The change of the original state is compared with a threshold deviation defined by the behavioral model and if the change of state is not within the threshold deviation, performing one or more actions to revert the payment entity to the original state. (See Hamilton para 158) The system is further described as engaging with a merchant using a communication identifier selected from a group of a name, address, an email address, a phone number, and a payment application to indicate possibility of fraud attack involving the payment entity. (See Hamilton para 167)
A method for detecting a security threat with a payment card reader capable of communicating with a point-of-sale (POS) terminal where the method comprises receiving, from a POS terminal a request for establishing a wireless connection with the payment card reader, the payment card reader and the POS terminal together forming a POS system for processing a payment transaction between the merchant and a buyer, wherein the request includes hardware and/or software data pertaining to the POS terminal and applications executing thereon. (See Hamilton para 175) The method then discloses detecting, by a sensor of the payment card reader and based on the request, whether a payment application is executing on the POS terminal; if the payment application is executing on the POS terminal, further determining, by a processor of a payment server system, whether the payment card reader is linked with the payment application, wherein the links between payment card readers and payment applications are stored in a data-structure within the payment service system. (See Hamilton para 175) If the data-structure indicates a link between the payment card reader and the payment application, the method establishes the wireless connection between the payment card reader and the POS terminal; and if the data structure indicates a link between the payment card reader and another payment application, generating a notification for the POS terminal connected to the other payment application to indicate that an unrecognized POS terminal is attempting to connect. (See Hamilton para 175 – generating a notification for the POS terminal connected to the other payment application)
Further, the method continues that in response to determining that the payment card reader is not linked to the payment application, canceling the payment transaction involving the payment card reader and the POS terminal executing the payment application; and automatically disabling the wireless connection between the payment card reader and the POS terminal. (See Hamilton para 177 – automatically disabling the wireless connection between the payment card reader and the POS terminal)
Hamilton further discloses generating a predictive model where the generating further includes obtaining at least one characteristic corresponding to the first payment entity, wherein the characteristic is related to the operational or physical features of the first payment entity, including information of the payment application with which the first payment entity interacts; tracking the characteristic over a period of time; and analyzing the tracked characteristic to generate the predictive model. (See Hamilton para 182) Further, the predictive model to indicate a probability of the request being fraudulent, and wherein the predictive model is based on one or more characteristics of the second payment entity selected from a group of characteristics including timing parameters, radiated performance, wireless performance, quality of communication links, radio frequency response, transmission measurements, receiver measurements, and engineering tolerances. (See Hamilton para 183)
The predictive model can also be based on an external state of the payment entity as sampled by one or more sensors including: a geographical or physical location of the payment entity; a linear or angular velocity or acceleration of the payment entity; a directional heading of the payment entity; a temperature external to the payment entity; a tilt or rotation of the payment entity; and intensity of light external to the payment entity; a level of sound external to the payment entity; or a time. (See Hamilton para 185) The predictive model further includes one or more conditions to be applied during authorization of the other payment entity, wherein the conditions include at least one of: a time period within which the payment entity is authorized; a particular merchant requesting the authorization; a particular category of the merchant requesting the authorization; a particular location from where the buyer is requesting the authorization; a predefined limit of the authorization; an identity of the merchant associated with the other payment entity; and a particular type of goods or services corresponding to a payment transaction. (See Hamilton para 187)
While Hamilton discloses the invention as noted above and discloses identifying a fraud or threat from merchant behavioral activity, the use of a predictive model and analyzing tracked characteristics to generate a behavioral model thus implies training a merchant behavioral threat modeler, it is not fully taught.
Hosseinali discloses a system for fraudulent merchant detection that includes a commerce platform system and plurality of merchant systems. (Hosseinali para 23 and Fig. 1) In an embodiment, the one or more merchant systems may be mobile computing devices that utilize the services of the commerce platform system. (See Hosseinali para 23) In an embodiment, the commerce platform system provides financial processing services to one or more merchant systems. (See Hosseinali para 26) In embodiments, various services provided to the merchant systems are susceptible to fraud and in embodiments one or more fraudulent merchant systems are detected by merchant fraud detection system to identify fraudulent merchant system(s) and take one or more remediative actions against the fraudulent merchant systems. (See Hosseinali para 28) The merchant fraud detection system is a machine learning model based fraud detection system that employs an ensemble of different types of machine learning models to detect various types of fraudulent merchant activities. (See Hosseinali para 28)
In embodiments, the ensemble of machine learning models can include a first machine learning model trained to detect fraudulent activities utilizing structured data inputs indicative of merchant transaction data (e.g., a number of charge declines, a total amount charged, a number of accounts associated with a merchant system, a number of accounts established within a specific time period (i.e., last hour, last 24 hours, last week, etc.), a number of charges with a specific time period, etc.) as well as other numeric features associated with the merchant system. (See Hosseinali para 29) In further embodiments, the ensemble of machine learning models can include a third machine learning model trained to detect fraudulent activities utilizing time-based data, such as an identification of commerce platform system API events and an associated time of the events (e.g., to detect a number of events within a time period, a flow of events, an order of various events, as well as other time based events occurring at the commerce platform system on behalf of a merchant system. (See Hosseinali para 29 – trained merchant behavioral threat)
Each of these models in the ensemble includes a model for detecting a specific merchant’s activities as being indicative of fraud in real-time as they occur based on the properties of the detected activities. (See Hosseinali para 29 – real-time detection of specific merchant’s activities indicative of fraud) Furthermore, the fraud detection is performed at scale for each merchant and each merchant transaction processed by the commerce platform system(s). (See Hosseinali para 29 – fraud detection performed at scale for each merchant and each merchant transaction)
Each of the machine learning models is trained on annotated commerce platform systems data (e.g., past transaction data, past onboarding data, past time-based event data, etc.), where the annotation may be generated by a human review process, by a previously machine learning model fraud prediction verified as correct and/or incorrect as part of a feedback loop for retraining one or more machine learning models, or a combination thereof. (See Hosseinali para 31 – training machine learning models to detect fraudulent activities [training a merchant behavioral threat modeler based on prior merchant behavior]) Furthermore, each of the models is trained utilizing an appropriate iterative training process for the model being trained. (See Hosseinali para 31- iterative training of the model)
In embodiments, a merchant system, remotely engages with services provided by the commerce platform system(s) via a network. (See Hosseinali para 33) For example, merchant system may establish an account via a web interface of the commerce platform system(s), process transactions via one or more APIs or software development kits (SDKs) distributed by the commerce platform system(s), have agent accounts established and associated with merchant system, process API and/or SDK based transactions using the agents, etc. (See Hosseinali para 33 – software application for merchant systems) These actions are stored by the services of the commerce platform system(s), where the services are responsible for performing the merchant system requested actions, for example in data store(s) of those services. (See Hosseinali para 33) Then, the models discussed herein may input data indicative of one or more characteristics associated with the merchant system, the requested action, or a combination thereof, in-line with a transaction being requested to detect merchant system fraud as the transaction is occurring. (See Hosseinali para 33) When fraud is detected, the transaction can be blocked, a merchant system account can be frozen or suspended, a merchant account can be deactivated, and/or some other remediative action(s) performed by the commerce platform system(s) in real time to prevent the detected merchant system fraud. (See Hosseinali para 33)
The remediative actions are communicated from merchant fraud detection system(s) to the effected merchant system, which may contest the fraud determination by providing proof of lack of fraud, insufficiency of data used to detect fraud, or some other form of proof of legitimacy of a transaction or set of transactions. (See Hosseinali para 34) When verified, this proof may be used to annotate training data for retraining one or more machine learning models to further improve the function of those models in detecting fraud forming a feedback loop to ensure that usage of the models will result in improved fraud detection accuracy and improved avoidance of false fraud detections. (See Hosseinali para 34)
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 method and systems to prevent swapping of a payment reader with another reader by tracking behavior of readers and developing a specific model for the reader based on the behavioral analysis of Hamilton with the more detailed disclosure of training machine learning models to detect fraudulent merchant transactions and take one or more remediative actions against the fraudulent merchant systems as disclosed by Hosseinali in order to improve fraud detection accuracy.
Regarding Claim 10, Hamilton discloses the following:
A system, comprising:
a point of sale terminal for a merchant executing a payment application and a threat collector agent computer program, wherein the threat collector agent computer program is configured to capture merchant behavioral activity comprising merchant interaction activity with the payment application; and (See Hamilton paras 14, 17, 19-21, 25-26, 28, 30-34, 57, 68, 80-81, 84, 98, 114-116, 141, 148, 156 – POS terminal may be a mobile device running a point-of-sale application. In order to manage its connections, the payment reader may establish a procedure for maintaining a connection with a mobile device belonging to the merchant [merchant POS terminal]; on detecting that a new state that is a deviation from a predicted state as defined by the model has occurred, and exceeds a threshold indicative of risky behavior, the server sends notification to the merchant to check if the deviation is normal and if abnormal, the server cancels any ongoing transactions and alerts the merchant; registration application or payment application, as used here, refers to any registration application that enables communication between users. The registration application can include, for example, a mobile payment application, a text messaging application or a cross-platform instant messaging application. In an implementation, the merchant uses the registration application to register the payment reader with an account association with the registration application; the state machine stores the states of the reader(s) associated with a merchant account or payment application in a database as a data structure; device detection component is configured to generate a behavioral profile of the reader(s) associated with a payment application, for example in response to a received device characteristic over time and then register the reader with a payment processor, such as payment service system for detection during future use)
an electronic device executing a backend computer program that is configured to receive the merchant behavioral activity from the threat collector agent computer program, to identify fraud or a threat from the merchant behavioral activity by providing the merchant behavioral activity to a merchant behavioral threat modeler that is trained with prior merchant behavior and/or terminal configuration behavior, and to execute a preventative action in response to the identified fraud or threat, wherein the preventative action comprises sending a signal to the point-of-sale terminal that causes the payment terminal to log the merchant out of the payment application. (See Hamilton paras 17-21, 33-34, 43, 57, 80-81, 84, 86-90, 93, 98, 108-109, 111, 114-116, 136, 138, 141, 146, 154, 158, 175-177, 186 and Cl. 16)
A payment system may include a point-of-sale (POS) terminal and a payment reader. (See Hamilton para 13) The payment reader and the POS terminal may communicate over a wireless connection such as Bluetooth low energy (BLE). (See Hamilton para 14) The POS terminal may be a mobile device running a point-of-sale application. (See Hamilton para 14)
In one implementation, the present disclosure discloses methods and systems to prevent swapping of a payment reader with another reader by tracking behavior of readers in the field and developing a specific model for the reader based on the behavioral analysis. (See Hamilton para 17) In some embodiments, the behavioral model also predicts and includes within the model past, current, or predicated future state of the entire merchant environment. (See Hamilton para 17 – behavioral model [trained merchant behavioral threat modeler]) Any new state that is a deviation from the predicted state as defined by the model and where the deviation exceeds a threshold, is indicative of an unknown and risky behavior, akin to a fraud attack. (See Hamilton para 17) On detecting that a behavior has changed, the server that perform the behavioral analysis sends notification to the merchant to check if the deviation in behavior is normal. (See Hamilton para 17) If the behavior is indicated to be normal, the server initiates the process of authorizing the new reader. (See Hamilton para 17) If the behavior is not indicated to be normal, the server cancels any ongoing transactions and alerts the merchant. (See Hamilton para 17)
In another implementation, a merchant reader can learn its regular position in relation to the merchant’s point of sale terminal, in terms of either consistent movement or consistent same location or both. (See Hamilton para 18) In the event of a “switcharoo” attack, the merchant reader would change to a new location across the room and remain relatively stable. (See Hamilton para 18) This should trigger the reader purge the connection to the seller’s point of sale terminal, forcing them to repair. (See Hamilton para 18)
In another implementation, a method to obtain an original state of a payment entity, such as a payment reader or a POS terminal, based on a behavioral model that defines an expected behavior of the payment entity. (See Hamilton para 19) The methods and systems detect a change in the original state of the payment entity, for example, if the payment entity moves in a manner different from its normal behavior, disconnects or connects with a new device, and so on. (See Hamilton para 19) The server compares the change of the original state with a threshold value, also referred to as threshold deviation, defined by the behavioral model and if the change of state is not within the threshold deviation, the server either reverts the payment entity to the original state or notifies the merchant to take corrective actions. (See Hamilton para 19 – the server compares the change of the original state with a threshold deviation defined by the behavioral model and if the change is not within the threshold deviation either reverts the payment entity to the original state or notifies the merchant to take corrective action [identifying fraud or a threat from merchant behavioral activity (including merchant behavior and/or terminal configuration behavior) by comparing it with the behavioral model threshold and executing a preventative action to the fraud or threat])
Another kind of attack disclosed by Hamilton is a fraudulent user converting the merchant’s reader into a skimmer by wirelessly connecting to the merchant’s payment reader and downloading malware on the reader. (See Hamilton para 20) To do so, the fraudulent user pairs his/her mobile device to the merchant mobile device by providing a user input such as a button push, when the merchant is not looking. (See Hamilton para 20) Then through the mobile device of the fraudulent user, the fraudulent user can download suspicious software scripts or malware on the payment card reader, thereby taking complete control of the reader and all the data stored thereon unbeknownst to the merchant. (See Hamilton para 20) Once the software or hardware of the payment reader is successfully tampered with, fraudulent user does not even need to be at the merchant location to carry out fraudulent activities. (See Hamilton para 20)
To this end, in one implementation, the payment server [backend computer] stores the association between a payment application [payment application] executing on a mobile device, such as a payment terminal, and a payment reader. (See Hamilton para 21 – merchant POS terminal) Each payment application is connected to a merchant and thus their financial account. (See Hamilton para 21 – merchant payment application executing on POS] Anytime there is a fraudulent user attempting to connect their device, and thereby, their financial account, to the reader, a request is sent to the server to compare whether the payment application executing on the new device, if any, is connecting to the card reader. (See Hamilton para 21 –request sent to the backend computer to determine if there is a fraudulent attempt to connect to the payment application [threat collector agent sends request to the backend]) If not, the primary merchant on the original payment application is sent a notification to confirm association of the second device executing a different payment application. (See Hamilton para 21) Various other conditions may trigger the generation of request, for example, introduction of a new reader, introduction of a previously known but disabled reader, and so on. (See Hamilton para 21)
The electronic interactions between the merchant and the customer take place between the customer’s payment instrument 10 and the merchant’s payment terminal 20. (See Hamilton para 25) The merchant has a payment terminal 20 such as a payment terminal or other electronic device that is capable of processing payment information (e.g., encrypted payment card data and user authentication data) and transaction information (e.g., purchase amount and point-of-purchase information), such as a smart phone or tablet running a payment application. (See Hamilton para 25 – merchant POS [payment terminal] running a payment application) In embodiments, the payment terminal may communicate with payment server over the network. (See Hamilton para 26) Although the payment server may be operated by a single entity, in one embodiment the payment server may include any suitable number of servers operated by any suitable entities, such as a payment service system and one or more banks of the merchant and customer. (See Hamilton para 26)
The payment terminal and the payment server communicate payment and transaction information to determine whether the transaction is authorized. (See Hamilton para 26) For example, payment terminal may provide encrypted payment data, user authentication data, purchase amount information, and point-of-purchase information to payment server over a network. (See Hamilton para 26) The payment server may determine whether the transaction is authorized based on this received information as well as information relating to customer or merchant accounts, and responds to the payment network terminal over the network to indicate whether or not the payment transaction is authorized. (See Hamilton para 26 – receiving payment information from the POS by the payment server and determining whether the transaction is authorized [receiving by the backend computer program payment application information from the merchant POS] In one implementation, the payment server includes payment service system and a bank server collectively operating to permit or reject payment transactions. (See Hamilton para 26)
Hamilton discloses that the term “registration application” or “payment application” as used here, refers to any registration application that enables communication between users (e.g., sender and recipient of a message) over a wired or wireless communications network. (See Hamilton para 30) The registration application can be employed by a service provider that delivers a communication service to users, e.g., chat capability or capability to enter payment information, for example, through a form. (See Hamilton para 30) In an implementation, the merchant uses the registration application to register the payment reader with an account association with the registration application, for example, at the time of pairing or bonding the payment reader with the POS terminal. (See Hamilton para 32) The server can store such relationships between the payment reader and the POS terminal either locally or within the server in specific data structures and in the case of multiple readers, similar to the payment reader being connected to the POS terminal, the server can also store the hierarchy of readers, the identity of such readers, profile of the readers and location of the readers with respect to the POS terminal, among other things. (See Hamilton para 32)
If the payment reader or any other reader connected to the POS terminal changes state with respect to a current state, the server generates a notification, e.g., via the state machine, to indicate to the merchant than an anomaly has occurred. (See Hamilton para 33 – notification sent indicating an anomaly if the payment reader or any other connected reader to the POS changes with respect to the current state) In one implementation, any current transactions may be paused until the merchant has verified the state of all readers, or if the server indicates presence of an unknown reader in proximity to the POS terminal. (See Hamilton para 33) The server can also determine change of state in the context of change in hierarchy of payment readers, detection of another merchant account by detection of a new registration application. (See Hamilton para 34)
The state machine stores the states of the reader or readers associated with a merchant account or payment application in a database as a data structure hereinafter referred to as a reader profile, which corresponds to the identity of the reader in terms of registration number, unique identifier, association of the reader with a payment or merchant account, the association of the reader with a mobile or POS terminal on which a payment application is executing and so on. (See Hamilton para 34 – POS terminal on which a payment application is executing) The reader model or profile can also correspond to the behavior or behaviors associated with the reader and collected and analyzed over time, or even an explicit or desired behavior set at the time of registration. (See Hamilton para 34 - prior merchant and/or terminal configuration behavior) Examples of such behavior includes determination of territory in which the reader operates and accordingly determine, the “movement” profile, for example the merchant may move the reader from one terminal to another terminal, may move the reader laterally or only in a certain direction, or may not move the reader at all, such “movement” behaviors can be stored in movement profiles. (See Hamilton para 34 - prior merchant and/or terminal configuration behavior) The state machine checks the system at predefined time intervals or at random time intervals to determine whether the state of the reader has deviated, above or below a threshold level, from the reader profile. (See Hamilton para 34) If the state machine identifies a deviation of behavior, the state machine contacts the merchant through a communication identifier, e.g., email address, phone number, etc., stored in the payment server. (See Hamilton para 34 - if deviation of behavior is identified, the merchant is contacted) The notification may indicate to the merchant that there is potentially a new reader or new behavior, which may be a fraudulent attempt. (See Hamilton para 34 – notification may indicate fraudulent activity)
The state machine stores a reader profile including behavior at the time of registration of the reader and subsequent association of the reader to a payment application. (See Hamilton para 34, page 8) The state machine can also store the behavior of the reader with respect to the POS terminal and in an implementation also includes device detection components including, but not limited to sensors, detectors, radio frequency transmitters and/or receivers. (See Hamilton para 34, page 8) By leveraging the sensing capabilities of these components, the POS terminal can determine a state of the payment reader at any time and can set a geo-fence within which to track reader profiles. (See Hamilton para 34, page 8) The POS terminal also tracks the movement of the reader and stores such behavior in the reader profile. (See Hamilton para 43) Over time, the POS terminal can track, over time, the movement behavior of the reader, thus the behavior indicates that the reader moves within a certain geo-fence or stays stable on certain days, times, or months. (See Hamilton para 43)
Hamilton discloses that a POS terminal may be any suitable device such as tablet payment instrument 24, mobile payment instrument 26, or payment terminal 28. (See Hamilton para 43 – POS terminal) In the case of a computing device such as tablet payment instrument 24 or mobile payment instrument 26, a point-of-sale application may provide for the entry of purchase and payment information interaction with a customer, and communications with a payment server. (See Hamilton para 43) For example, a payment application may provide a menu of services that merchant is able to select and a series of menus or screens for automating a transaction and may also facilitate the entry of customer authentication information such as signatures, PIN numbers, or biometric information. (See Hamilton para 43 – -payment application)
In some embodiments, a cryptographic processing unit may encrypt and decrypt data based on one or more encryption keys, in a manner that isolates the encryption functionality from other components of payment reader 5 and protects the encryption keys from being exposed to other components of the payment reader. (See Hamilton para 55) In some embodiments, cryptographic memory may be any suitable memory or combination thereof and may include a plurality of sets of instructions for performing cryptographic operations, such as payment processing instructions and cryptographic instructions. (See Hamilton para 56) In some embodiments, cryptographic memory may be any suitable memory and may include a plurality of sets of instructions for performing operations of a payment reader, such as reader profile instructions, any of which may be implemented entirely or partially in firmware stored at memory 148. (See Hamilton para 56)
The reader profile instructions may include instructions for communicating with the payment terminal and payment server to provide information related to characteristics, such as location, signal strength, power levels, radiation levels, and the like, to the payment terminal and server. (See Hamilton para 57) The execution of the reader profile instructions causes collection of reader characteristics, including behavioral characteristics such as geographic locations where the merchant carries the reader, the reader that the merchant uses to sell categories items, the time of day the readers are active, the average amount spent by the buyers in certain merchant categories, the average time the merchant spends in interacting with the reader, and so forth. (See Hamilton para 57)
Operating instructions 130 may also include instructions for interacting with a payment server 40. (See Hamilton para 68) In one embodiment, a payment server 40 may be associated with the payment reader 5 and the point-of-sale application of the POS terminal 15. (See Hamilton para 68) For example, the payment server 40 may have information about payment readers 22 and POS terminals 15 that are registered with the payment server 40 (e.g., based on unique identifiers). (See Hamilton para 68) This information may be used to process transactions with servers of the merchant and customer financial institutions, for providing analysis and reports to a merchant, and aggregating transaction data. (See Hamilton para 68) The payment reader 5 may process payment information (e.g., based on operation of reader chip 100 and transaction chip 140) and communicate that processed payment information to the point-of-sale application, which in turn communicates with the payment server 40. (See Hamilton para 68 – receiving by a backend computer from the POS application) In this manner, messages from the payment reader 5 may be forwarded to the payment server 40, such that the payment reader 5 and payment server 40 may collectively process the payment transaction. (See Hamilton para 68 – processing instructions)
In one implementation, the POS terminal includes one or more components configured specifically to allow the merchant to associate readers with the terminal and track reader characteristics and behavior over time as fraud detection and payment authentication tools. (See Hamilton para 80 – trained fraud/threat detection tools) The POS terminal also includes a signal conditioning and monitoring component, a device detection component, a state machine, and payload or detection sequences, and a registration application, all of which may be within a memory, even if a separate component. (See Hamilton para 80 – threat collector agent) The reader profile includes reader characteristics that include, but are not limited to: detection of location based on change in timing parameters, radiated performance, wireless performance, quality of communication links, radio frequency response, transmission measurements, receiver measurements, location values, and engineering tolerances. (See Hamilton para 80)
In one implementation, the device detection component is configured to detect and track movement of devices, such as readers, through change in reader characteristics, such as location or mechanical and operational differences. (See Hamilton para 81) The device detection component is also configured to generate a behavioral profile of the reader or readers associated with a payment application, for example in response to a received device characteristic over time, and then register the reader with a payment processor, such as payment service system (“PSS”) for detection during a future use. (See Hamilton para 81 – merchant behavioral activity provided to the payment service system via a threat collector agent) The reader profile also includes the mapping of the reader with a payment application and is sent to the PSS coupled to the payment object reader. (See Hamilton para 81)
The behaviors including the reader-terminal-merchant relationship, also referred to as the reader profile or store signature, can be stored in a central payment service system. (See Hamilton para 84 – merchant behavioral activity stored at the payment service system) Similar to the POS terminal, the PSS may include the state machine, the reader profile as received from the POS terminal, and a merchant profile, which is a database of all merchant data and connections of readers to merchants. (See Hamilton para 84)
In an implementation, a merchant launches or opens a registration application or a mobile payment portal (e.g., a payment application installed on the device or a web application in web browser) executing on a mobile device, e.g., a phone or a laptop, or the POS terminal. (See Hamilton para 86 – payment application executed on POS terminal) The registration application can be employed by a service provider that delivers a communication service to users and may include one or more components and/or engines, or a component and/or engine can include one or more applications. (See Hamilton para 86)
The registration application further facilitates collection of and connection between the reader’s behavior and characteristics as profile 246. (See Hamilton para 88) At the time of both detection and validation of the device fingerprint for authentication, it may be useful to have data corresponding to all possible parameters, protocols and test sequences, however the reader may not be prepared or available for all kinds of communication. (See Hamilton para 89) To communicate with the reader, the device detection component 228 determines whether the corresponding communication ports in the reader are available or accessible and/or appropriate software permissions have been obtained to make the communication. (See Hamilton para 89)
The device detection component 228 may also implement logic to interact with the hardware and software components of the device 202-1 to measure the tiniest behavioral differences in the reader and record them as deviations to compare to the reader profile. (See Hamilton para 90)
The device detection component 228 may provide functionality for determining whether a reader is an outlier and for notifying merchants when an outlier is determined. (See Hamilton para 93) For example, the device detection component 228 may determine a fraud score for a reader based [on] comparison with the reader profiles. (See Hamilton para 93) The component may determine whether to associated the reader with fraudulent activity based on the fraud score and may further notify one or more merchants when a reader associated with one or more payment application or merchants has been associated with fraudulent activity. (See Hamilton para 93 – sending a signal [notification] to the reader [POS] associated with the payment application)
After the registration of the device as an authentication tool for any subsequent payment transaction is complete, the relationships that have been set up allow the terminal authenticate a transaction as being safe every time a user presents the payment object. (See Hamilton para 95)
Once saved, the registered device fingerprints or the device-object relationships can be retrieved and used as valid authentication tools for payment instruments at the time of a payment transaction, for example, through a POS terminal. (See Hamilton para 96)
In an implementation, the terminal sends the current state to the payment service system via the communication network for comparison with the reader profile that includes behaviors and previous states of readers connected to the merchant account. (See Hamilton para 98 – merchant POS terminal sends current state to the payment service system to be compared with a reader profile containing behaviors and previous reader states) The device detection component can also fetch the registered reader profile from a local storage unit. (See Hamilton para 98) The device detection component subsequently verifies reader identity based on the comparison – for example, the payment service system compares previously stored reader profiles or fingerprints of the devices registered by the merchant or profile obtained at the POS terminal through the state machine. (See Hamilton para 98) If the state does not match with a reader profile, which means that there is a deviation in behavior, the POS terminal generates a notification for the merchant to authenticate the new reader by providing an authorization code. (See Hamilton para 98) Once authenticated, the reader is added to the merchant list of authorized readers and payment transaction is fulfilled through the issuer, acquirer and card processing network. (See Hamilton para 98)
FIGS. 5A and 5B are sequence flows illustrating an example process 400 of a method of registering a reader as an authorized reader with a payment processing system. (See Hamilton para 106, Fig. 5A-5B) The process 400 can be performed by one or more components, devices, or components such as, but not limited to, the mobile device, the payment service system, merchant device or POS terminal, the payment reader, or payment beacon or other components or devices. (See Hamilton para 107) It will be understood that the method can be carried out by any component of the payment system, e.g., POS terminal, PSS or both, for example contemporaneous to the payment reader. (See Hamilton para 107) As seen above, the relationship between the merchant, the payment application, financial account and reader information is stored either locally on a merchant terminal or on a server. (See Hamilton para 107) This information is then looked up if another reader attempts to connect with the merchant application or terminal. (See Hamilton para 107) The relationship may also store the location coordinates of the reader and other devices and behavioral characteristics as the reader profile. (See Hamilton para 108) Such [behavioral and location coordinates] data is constantly and periodically updated as the behavior of a reader is learned. (See Hamilton para 108) Behavioral characteristics include locations where the reader moves, the items purchased through the reader the time when the reader is active, and so on. (See Hamilton para 108) At time t2, or contemporaneous to the above step, the payment terminal, as part of routine or in response to a trigger condition such as detection of a new device in the near field range, scans the environment to collect state of readers. (See Hamilton para 109) The entry of a new device, such as an unknown reader, may be detected through location detection techniques, such as techniques based on angulation, lateration, proximity detection, dead reckoning, geo-fence, global or local positioning systems, Bluetooth Technology, Near-Field Communication Technology, sensors-based technology, Radio frequency identification (RFID) system, or the like. (See Hamilton para 109) In an embodiment, the present subject matter, the geo-fence is defined and established based on a current location of an asset, for example using GPS data comprising latitude and longitude along with some predetermined area based on range or distance. (See Hamilton para 109)
The POS terminal then determines how it can interact with the devices by detecting devices that are within a communication range dictated by a communication protocol and then establishes communication channels with all or selected readers or other devices in its communication range. (See Hamilton para 111) Accordingly, the device detection component of the terminal generates payload and/or detection sequences adapted based on the available communication ports and in accordance with the communication protocols on which the ports operate and the detection sequences can also be information-gathering requests configured to obtain device fingerprints from the readers. (See Hamilton para 111) The response form the digital device fingerprints, which are to be used for device identification and association of a reader as a registered reader and analyzed. (See Hamilton para 114) The analysis involves decryption of the responses and generation of behavior or trends based on the responses, for example, the analysis involves comparison of the new behavior with an existing reader profile to see if there are any deviations. (See Hamilton para 114) A threshold or confidence score is also set to compare the deviation with. (See Hamilton para 114)
In an embodiment, the server or terminal then compares the deviation with the threshold. (See Hamilton para 115) If the match operation as a result of the comparison yields a “Yes”, the new reader is authenticated as being previously registered or otherwise not fraudulent. (See Hamilton para 115) However, if the match operation yields a “No”, the merchant is sent a notification on his device indicating a potential attempt to fraudulently add a new reader or payment application to the merchant’s account or the merchant is asked to key in a card verification value or some other kind of authentication code into a field in the terminal’s display message. (See Hamilton para 115) The decision of whether or not a new device is potentially fraudulent is thus determined, for example, based on deviation in known behavior of a merchant environment of readers and terminals and their intention with each other and any anomaly there is indicative of a potentially fraudulent event. (See Hamilton para 115)
Hamilton discloses a method to detect swapping of a payment card reader associated with a merchant with another payment card reader associated with a fraudulent user that discloses if a current state of the payment card reader, wherein the current state is capable of reflecting change of behavior of the payment card reader with respect to the POS terminal as a result of swapping between the payment card reader and the other card reader; comparing, by the payment service system, the current state of the payment card reader with the behavioral model of payment card reader, and if the current state indicates a deviation from the behavioral model of the payment object reader due to the other payment card reader and the deviation exceeds a threshold level, generating a notification on the POS terminal to indicate that an attempt to fraudulently swap the payment card reader with the other payment object reader is in progress. (See Hamilton para 136 - generating a notification on the POS terminal [sending a signal to the POS])
Hamilton further discloses that the method further comprises canceling one or more transactions involving the payment card reader and the other payment card reader; and automatically disabling connection between the other payment card reader or the payment card reader and the POS terminal. (See Hamilton para 138 – automatically disabling connection between the other payment card reader and the POS terminal) The disclosure further indicates if the change of state is not within a threshold deviation the method may perform one or more actions to revert the payment entity to the original state. (See Hamilton para 141)
A payment system to perform an action based on a change in behavior of a payment entity is disclosed to include obtaining an original state of a payment entity based on a behavioral model, wherein the behavioral model defines an expected behavior of the payment entity and wherein the payment entity is registered to a merchant and detecting a change in the original state of the payment entity, wherein the change in the original state is triggered by another payment entity not authorized by the merchant. (See Hamilton para 158) The change of the original state is compared with a threshold deviation defined by the behavioral model and if the change of state is not within the threshold deviation, performing one or more actions to revert the payment entity to the original state. (See Hamilton para 158) The system is further described as engaging with a merchant using a communication identifier selected from a group of a name, address, an email address, a phone number, and a payment application to indicate possibility of fraud attack involving the payment entity. (See Hamilton para 167)
A method for detecting a security threat with a payment card reader capable of communicating with a point-of-sale (POS) terminal where the method comprises receiving, from a POS terminal a request for establishing a wireless connection with the payment card reader, the payment card reader and the POS terminal together forming a POS system for processing a payment transaction between the merchant and a buyer, wherein the request includes hardware and/or software data pertaining to the POS terminal and applications executing thereon. (See Hamilton para 175) The method then discloses detecting, by a sensor of the payment card reader and based on the request, whether a payment application is executing on the POS terminal; if the payment application is executing on the POS terminal, further determining, by a processor of a payment server system, whether the payment card reader is linked with the payment application, wherein the links between payment card readers and payment applications are stored in a data-structure within the payment service system. (See Hamilton para 175) If the data-structure indicates a link between the payment card reader and the payment application, the method establishes the wireless connection between the payment card reader and the POS terminal; and if the data structure indicates a link between the payment card reader and another payment application, generating a notification for the POS terminal connected to the other payment application to indicate that an unrecognized POS terminal is attempting to connect. (See Hamilton para 175 – generating a notification for the POS terminal connected to the other payment application)
Further, the method continues that in response to determining that the payment card reader is not linked to the payment application, canceling the payment transaction involving the payment card reader and the POS terminal executing the payment application; and automatically disabling the wireless connection between the payment card reader and the POS terminal. (See Hamilton para 177 – automatically disabling the wireless connection between the payment card reader and the POS terminal)
Hamilton further discloses generating a predictive model where the generating further includes obtaining at least one characteristic corresponding to the first payment entity, wherein the characteristic is related to the operational or physical features of the first payment entity, including information of the payment application with which the first payment entity interacts; tracking the characteristic over a period of time; and analyzing the tracked characteristic to generate the predictive model. (See Hamilton para 182) Further, the predictive model to indicate a probability of the request being fraudulent, and wherein the predictive model is based on one or more characteristics of the second payment entity selected from a group of characteristics including timing parameters, radiated performance, wireless performance, quality of communication links, radio frequency response, transmission measurements, receiver measurements, and engineering tolerances. (See Hamilton para 183)
The predictive model can also be based on an external state of the payment entity as sampled by one or more sensors including: a geographical or physical location of the payment entity; a linear or angular velocity or acceleration of the payment entity; a directional heading of the payment entity; a temperature external to the payment entity; a tilt or rotation of the payment entity; and intensity of light external to the payment entity; a level of sound external to the payment entity; or a time. (See Hamilton para 185) The predictive model further includes one or more conditions to be applied during authorization of the other payment entity, wherein the conditions include at least one of: a time period within which the payment entity is authorized; a particular merchant requesting the authorization; a particular category of the merchant requesting the authorization; a particular location from where the buyer is requesting the authorization; a predefined limit of the authorization; an identity of the merchant associated with the other payment entity; and a particular type of goods or services corresponding to a payment transaction. (See Hamilton para 187)
While Hamilton discloses the invention as noted above and discloses identifying a fraud or threat from merchant behavioral activity, the use of a predictive model and analyzing tracked characteristics to generate a behavioral model thus implies training a merchant behavioral threat modeler, it is not fully taught.
Hosseinali discloses a system for fraudulent merchant detection that includes a commerce platform system and plurality of merchant systems. (Hosseinali para 23 and Fig. 1) In an embodiment, the one or more merchant systems may be mobile computing devices that utilize the services of the commerce platform system. (See Hosseinali para 23) In an embodiment, the commerce platform system provides financial processing services to one or more merchant systems. (See Hosseinali para 26) In embodiments, various services provided to the merchant systems are susceptible to fraud and in embodiments one or more fraudulent merchant systems are detected by merchant fraud detection system to identify fraudulent merchant system(s) and take one or more remediative actions against the fraudulent merchant systems. (See Hosseinali para 28) The merchant fraud detection system is a machine learning model based fraud detection system that employs an ensemble of different types of machine learning models to detect various types of fraudulent merchant activities. (See Hosseinali para 28)
In embodiments, the ensemble of machine learning models can include a first machine learning model trained to detect fraudulent activities utilizing structured data inputs indicative of merchant transaction data (e.g., a number of charge declines, a total amount charged, a number of accounts associated with a merchant system, a number of accounts established within a specific time period (i.e., last hour, last 24 hours, last week, etc.), a number of charges with a specific time period, etc.) as well as other numeric features associated with the merchant system. (See Hosseinali para 29) In further embodiments, the ensemble of machine learning models can include a third machine learning model trained to detect fraudulent activities utilizing time-based data, such as an identification of commerce platform system API events and an associated time of the events (e.g., to detect a number of events within a time period, a flow of events, an order of various events, as well as other time based events occurring at the commerce platform system on behalf of a merchant system. (See Hosseinali para 29 – trained merchant behavioral threat)
Each of these models in the ensemble includes a model for detecting a specific merchant’s activities as being indicative of fraud in real-time as they occur based on the properties of the detected activities. (See Hosseinali para 29 – real-time detection of specific merchant’s activities indicative of fraud) Furthermore, the fraud detection is performed at scale for each merchant and each merchant transaction processed by the commerce platform system(s). (See Hosseinali para 29 – fraud detection performed at scale for each merchant and each merchant transaction)
Each of the machine learning models is trained on annotated commerce platform systems data (e.g., past transaction data, past onboarding data, past time-based event data, etc.), where the annotation may be generated by a human review process, by a previously machine learning model fraud prediction verified as correct and/or incorrect as part of a feedback loop for retraining one or more machine learning models, or a combination thereof. (See Hosseinali para 31 – training machine learning models to detect fraudulent activities [training a merchant behavioral threat modeler based on prior merchant behavior]) Furthermore, each of the models is trained utilizing an appropriate iterative training process for the model being trained. (See Hosseinali para 31 – iterative training of the model)
In embodiments, a merchant system, remotely engages with services provided by the commerce platform system(s) via a network. (See Hosseinali para 33) For example, merchant system may establish an account via a web interface of the commerce platform system(s), process transactions via one or more APIs or software development kits (SDKs) distributed by the commerce platform system(s), have agent accounts established and associated with merchant system, process API and/or SDK based transactions using the agents, etc. (See Hosseinali para 33 – software application for merchant systems) These actions are stored by the services of the commerce platform system(s), where the services are responsible for performing the merchant system requested actions, for example in data store(s) of those services. (See Hosseinali para 33) Then, the models discussed herein may input data indicative of one or more characteristics associated with the merchant system, the requested action, or a combination thereof, in-line with a transaction being requested to detect merchant system fraud as the transaction is occurring. (See Hosseinali para 33) When fraud is detected, the transaction can be blocked, a merchant system account can be frozen or suspended, a merchant account can be deactivated, and/or some other remediative action(s) performed by the commerce platform system(s) in real time to prevent the detected merchant system fraud. (See Hosseinali para 33)
The remediative actions are communicated from merchant fraud detection system(s) to the effected merchant system, which may contest the fraud determination by providing proof of lack of fraud, insufficiency of data used to detect fraud, or some other form of proof of legitimacy of a transaction or set of transactions. (See Hosseinali para 34) When verified, this proof may be used to annotate training data for retraining one or more machine learning models to further improve the function of those models in detecting fraud forming a feedback loop to ensure that usage of the models will result in improved fraud detection accuracy and improved avoidance of false fraud detections. (See Hosseinali para 34)
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 method and systems to prevent swapping of a payment reader with another reader by tracking behavior of readers and developing a specific model for the reader based on the behavioral analysis of Hamilton with the more detailed disclosure of training machine learning models to detect fraudulent merchant transactions and take one or more remediative actions against the fraudulent merchant systems as disclosed by Hosseinali in order to improve fraud detection accuracy.
Regarding Claim 19, Hamilton discloses the following:
A non-transitory computer readable storage medium, including instructions stored thereon, which when read and executed by one or more computer processors, cause the one or more computer processors to perform steps comprising: (See Hamilton paras 47-48, 139, 156, 169 and 173)
receiving, from a threat collector agent computer program executed on a point-of-sale terminal for a merchant, merchant behavioral activity comprising merchant interaction activity with a payment application executed by the point-of-sale terminal that was captured by the threat collector agent computer program, wherein the merchant behavioral activity comprises a login time to the payment application and/or a merchant login account; (See Hamilton paras 17, 26, 30-34, 43, 46, 57, 80, 83-84, 91, 98, 108-109, 137, 143, 160, 176, 183, 187, 198, Cl. 3 - – POS terminal may be a mobile device running a point-of-sale application. In order to manage its connections, the payment reader may establish a procedure for maintaining a connection with a mobile device belonging to the merchant [merchant POS terminal]; on detecting that a new state that is a deviation from a predicted state as defined by the model has occurred, and exceeds a threshold indicative of risky behavior, the server sends notification to the merchant to check if the deviation is normal and if abnormal, the server cancels any ongoing transactions and alerts the merchant; registration application or payment application, as used here, refers to any registration application that enables communication between users. The registration application can include, for example, a mobile payment application, a text messaging application or a cross-platform instant messaging application. In an implementation, the merchant uses the registration application to register the payment reader with an account association with the registration application; the state machine stores the states of the reader(s) associated with a merchant account or payment application in a database as a data structure; device detection component is configured to generate a behavioral profile of the reader(s) associated with a payment application, for example in response to a received device characteristic over time and then register the reader with a payment processor, such as payment service system for detection during future use)
identifying fraud or a threat from the merchant behavioral activity by providing the merchant behavioral activity to a merchant behavioral threat modeler that is trained with prior merchant behavior and/or terminal configuration behavior; and (See Hamilton paras 17-21, 33-34, 43, 57, 80-81, 84, 93, 98, 100, 108-109, 111, 114-116, 141, 146, 158)
executing a preventative action in response to the identified fraud or threat, wherein the preventative action is based on a merchant profile or a merchant risk category for the merchant, wherein the preventative action comprises sending a signal to the point-of-sale terminal that causes the payment terminal to log the merchant out of the payment application. (See Hamilton paras 17, 19-21, 34, 98, 114-116, 136, 138, 141, 154-155, 187)
A payment system may include a point-of-sale (POS) terminal and a payment reader. (See Hamilton para 13) The payment reader and the POS terminal may communicate over a wireless connection such as Bluetooth low energy (BLE). (See Hamilton para 14) The POS terminal may be a mobile device running a point-of-sale application. (See Hamilton para 14)
In one implementation, the present disclosure discloses methods and systems to prevent swapping of a payment reader with another reader by tracking behavior of readers in the field and developing a specific model for the reader based on the behavioral analysis. (See Hamilton para 17) In some embodiments, the behavioral model also predicts and includes within the model past, current, or predicated future state of the entire merchant environment. (See Hamilton para 17 – behavioral model [trained merchant behavioral threat modeler]) Any new state that is a deviation from the predicted state as defined by the model and where the deviation exceeds a threshold, is indicative of an unknown and risky behavior, akin to a fraud attack. (See Hamilton para 17) On detecting that a behavior has changed, the server that perform the behavioral analysis sends notification to the merchant to check if the deviation in behavior is normal. (See Hamilton para 17) If the behavior is indicated to be normal, the server initiates the process of authorizing the new reader. (See Hamilton para 17) If the behavior is not indicated to be normal, the server cancels any ongoing transactions and alerts the merchant. (See Hamilton para 17)
In another implementation, a merchant reader can learn its regular position in relation to the merchant’s point of sale terminal, in terms of either consistent movement or consistent same location or both. (See Hamilton para 18) In the event of a “switcharoo” attack, the merchant reader would change to a new location across the room and remain relatively stable. (See Hamilton para 18) This should trigger the reader purge the connection to the seller’s point of sale terminal, forcing them to repair. (See Hamilton para 18)
In another implementation, a method to obtain an original state of a payment entity, such as a payment reader or a POS terminal, based on a behavioral model that defines an expected behavior of the payment entity. (See Hamilton para 19) The methods and systems detect a change in the original state of the payment entity, for example, if the payment entity moves in a manner different from its normal behavior, disconnects or connects with a new device, and so on. (See Hamilton para 19) The server compares the change of the original state with a threshold value, also referred to as threshold deviation, defined by the behavioral model and if the change of state is not within the threshold deviation, the server either reverts the payment entity to the original state or notifies the merchant to take corrective actions. (See Hamilton para 19 – the server compares the change of the original state with a threshold deviation defined by the behavioral model and if the change is not within the threshold deviation either reverts the payment entity to the original state or notifies the merchant to take corrective action [identifying fraud or a threat from merchant behavioral activity (including merchant behavior and/or terminal configuration behavior) by comparing it with the behavioral model threshold and executing a preventative action to the fraud or threat])
Another kind of attack disclosed by Hamilton is a fraudulent user converting the merchant’s reader into a skimmer by wirelessly connecting to the merchant’s payment reader and downloading malware on the reader. (See Hamilton para 20) To do so, the fraudulent user pairs his/her mobile device to the merchant mobile device by providing a user input such as a button push, when the merchant is not looking. (See Hamilton para 20) Then through the mobile device of the fraudulent user, the fraudulent user can download suspicious software scripts or malware on the payment card reader, thereby taking complete control of the reader and all the data stored thereon unbeknownst to the merchant. (See Hamilton para 20) Once the software or hardware of the payment reader is successfully tampered with, fraudulent user does not even need to be at the merchant location to carry out fraudulent activities. (See Hamilton para 20)
To this end, in one implementation, the payment server [backend computer] stores the association between a payment application [payment application] executing on a mobile device, such as a payment terminal, and a payment reader. (See Hamilton para 21 – merchant POS terminal) Each payment application is connected to a merchant and thus their financial account. (See Hamilton para 21 – merchant payment application executing on POS] Anytime there is a fraudulent user attempting to connect their device, and thereby, their financial account, to the reader, a request is sent to the server to compare whether the payment application executing on the new device, if any, is connecting to the card reader. (See Hamilton para 21 –request sent to the backend computer to determine if there is a fraudulent attempt to connect to the payment application [threat collector agent sends request to the backend]) If not, the primary merchant on the original payment application is sent a notification to confirm association of the second device executing a different payment application. (See Hamilton para 21) Various other conditions may trigger the generation of request, for example, introduction of a new reader, introduction of a previously known but disabled reader, and so on. (See Hamilton para 21)
The electronic interactions between the merchant and the customer take place between the customer’s payment instrument 10 and the merchant’s payment terminal 20. (See Hamilton para 25) The merchant has a payment terminal 20 such as a payment terminal or other electronic device that is capable of processing payment information (e.g., encrypted payment card data and user authentication data) and transaction information (e.g., purchase amount and point-of-purchase information), such as a smart phone or tablet running a payment application. (See Hamilton para 25 – merchant POS [payment terminal] running a payment application) In embodiments, the payment terminal may communicate with payment server over the network. (See Hamilton para 26) Although the payment server may be operated by a single entity, in one embodiment the payment server may include any suitable number of servers operated by any suitable entities, such as a payment service system and one or more banks of the merchant and customer. (See Hamilton para 26)
The payment terminal and the payment server communicate payment and transaction information to determine whether the transaction is authorized. (See Hamilton para 26) For example, payment terminal may provide encrypted payment data, user authentication data, purchase amount information, and point-of-purchase information to payment server over a network. (See Hamilton para 26) The payment server may determine whether the transaction is authorized based on this received information as well as information relating to customer or merchant accounts, and responds to the payment network terminal over the network to indicate whether or not the payment transaction is authorized. (See Hamilton para 26 – receiving payment information from the POS by the payment server and determining whether the transaction is authorized [receiving by the backend computer program payment application information from the merchant POS] In one implementation, the payment server includes payment service system and a bank server collectively operating to permit or reject payment transactions. (See Hamilton para 26)
Hamilton discloses that the term “registration application” or “payment application” as used here, refers to any registration application that enables communication between users (e.g., sender and recipient of a message) over a wired or wireless communications network. (See Hamilton para 30) The registration application can be employed by a service provider that delivers a communication service to users, e.g., chat capability or capability to enter payment information, for example, through a form. (See Hamilton para 30) In an implementation, the merchant uses the registration application to register the payment reader with an account association with the registration application, for example, at the time of pairing or bonding the payment reader with the POS terminal. (See Hamilton para 32) The server can store such relationships between the payment reader and the POS terminal either locally or within the server in specific data structures and in the case of multiple readers, similar to the payment reader being connected to the POS terminal, the server can also store the hierarchy of readers, the identity of such readers, profile of the readers and location of the readers with respect to the POS terminal, among other things. (See Hamilton para 32)
If the payment reader or any other reader connected to the POS terminal changes state with respect to a current state, the server generates a notification, e.g., via the state machine, to indicate to the merchant than an anomaly has occurred. (See Hamilton para 33 – notification sent indicating an anomaly if the payment reader or any other connected reader to the POS changes with respect to the current state) In one implementation, any current transactions may be paused until the merchant has verified the state of all readers, or if the server indicates presence of an unknown reader in proximity to the POS terminal. (See Hamilton para 33) The server can also determine change of state in the context of change in hierarchy of payment readers, detection of another merchant account by detection of a new registration application. (See Hamilton para 34)
The state machine stores the states of the reader or readers associated with a merchant account or payment application in a database as a data structure hereinafter referred to as a reader profile, which corresponds to the identity of the reader in terms of registration number, unique identifier, association of the reader with a payment or merchant account, the association of the reader with a mobile or POS terminal on which a payment application is executing and so on. (See Hamilton para 34 – POS terminal on which a payment application is executing) The reader model or profile can also correspond to the behavior or behaviors associated with the reader and collected and analyzed over time, or even an explicit or desired behavior set at the time of registration. (See Hamilton para 34 - prior merchant and/or terminal configuration behavior) Examples of such behavior includes determination of territory in which the reader operates and accordingly determine, the “movement” profile, for example the merchant may move the reader from one terminal to another terminal, may move the reader laterally or only in a certain direction, or may not move the reader at all, such “movement” behaviors can be stored in movement profiles. (See Hamilton para 34 - prior merchant and/or terminal configuration behavior) The state machine checks the system at predefined time intervals or at random time intervals to determine whether the state of the reader has deviated, above or below a threshold level, from the reader profile. (See Hamilton para 34) If the state machine identifies a deviation of behavior, the state machine contacts the merchant through a communication identifier, e.g., email address, phone number, etc., stored in the payment server. (See Hamilton para 34 – if deviation of behavior is identified, the merchant is contacted) The notification may indicate to the merchant that there is potentially a new reader or new behavior, which may be a fraudulent attempt. (See Hamilton para 34 - notification may indicate fraudulent activity)
The state machine stores a reader profile including behavior at the time of registration of the reader and subsequent association of the reader to a payment application. (See Hamilton para 34, page 8) The state machine can also store the behavior of the reader with respect to the POS terminal and in an implementation also includes device detection components including, but not limited to sensors, detectors, radio frequency transmitters and/or receivers. (See Hamilton para 34, page 8) By leveraging the sensing capabilities of these components, the POS terminal can determine a state of the payment reader at any time and can set a geo-fence within which to track reader profiles. (See Hamilton para 34, page 8) The POS terminal also tracks the movement of the reader and stores such behavior in the reader profile. (See Hamilton para 43) Over time, the POS terminal can track, over time, the movement behavior of the reader, thus the behavior indicates that the reader moves within a certain geo-fence or stays stable on certain days, times, or months. (See Hamilton para 43)
Hamilton discloses that a POS terminal may be any suitable device such as tablet payment instrument 24, mobile payment instrument 26, or payment terminal 28. (See Hamilton para 43 – POS terminal) In the case of a computing device such as tablet payment instrument 24 or mobile payment instrument 26, a point-of-sale application may provide for the entry of purchase and payment information interaction with a customer, and communications with a payment server. (See Hamilton para 43) For example, a payment application may provide a menu of services that merchant is able to select and a series of menus or screens for automating a transaction and may also facilitate the entry of customer authentication information such as signatures, PIN numbers, or biometric information. (See Hamilton para 43 – -payment application)
In some embodiments, a cryptographic processing unit may encrypt and decrypt data based on one or more encryption keys, in a manner that isolates the encryption functionality from other components of payment reader 5 and protects the encryption keys from being exposed to other components of the payment reader. (See Hamilton para 55) In some embodiments, cryptographic memory may be any suitable memory or combination thereof and may include a plurality of sets of instructions for performing cryptographic operations, such as payment processing instructions and cryptographic instructions. (See Hamilton para 56) In some embodiments, cryptographic memory may be any suitable memory and may include a plurality of sets of instructions for performing operations of a payment reader, such as reader profile instructions, any of which may be implemented entirely or partially in firmware stored at memory 148. (See Hamilton para 56)
The reader profile instructions may include instructions for communicating with the payment terminal and payment server to provide information related to characteristics, such as location, signal strength, power levels, radiation levels, and the like, to the payment terminal and server. (See Hamilton para 57) The execution of the reader profile instructions causes collection of reader characteristics, including behavioral characteristics such as geographic locations where the merchant carries the reader, the reader that the merchant uses to sell categories items, the time of day the readers are active, the average amount spent by the buyers in certain merchant categories, the average time the merchant spends in interacting with the reader, and so forth. (See Hamilton para 57)
Operating instructions 130 may also include instructions for interacting with a payment server 40. (See Hamilton para 68) In one embodiment, a payment server 40 may be associated with the payment reader 5 and the point-of-sale application of the POS terminal 15. (See Hamilton para 68) For example, the payment server 40 may have information about payment readers 22 and POS terminals 15 that are registered with the payment server 40 (e.g., based on unique identifiers). (See Hamilton para 68) This information may be used to process transactions with servers of the merchant and customer financial institutions, for providing analysis and reports to a merchant, and aggregating transaction data. (See Hamilton para 68) The payment reader 5 may process payment information (e.g., based on operation of reader chip 100 and transaction chip 140) and communicate that processed payment information to the point-of-sale application, which in turn communicates with the payment server 40. (See Hamilton para 68 – receiving by a backend computer from the POS application) In this manner, messages from the payment reader 5 may be forwarded to the payment server 40, such that the payment reader 5 and payment server 40 may collectively process the payment transaction. (See Hamilton para 68 – processing instructions)
In one implementation, the POS terminal includes one or more components configured specifically to allow the merchant to associate readers with the terminal and track reader characteristics and behavior over time as fraud detection and payment authentication tools. (See Hamilton para 80 – trained fraud/threat detection tools) The POS terminal also includes a signal conditioning and monitoring component, a device detection component, a state machine, and payload or detection sequences, and a registration application, all of which may be within a memory, even if a separate component. (See Hamilton para 80 – threat collector agent) The reader profile includes reader characteristics that include, but are not limited to: detection of location based on change in timing parameters, radiated performance, wireless performance, quality of communication links, radio frequency response, transmission measurements, receiver measurements, location values, and engineering tolerances. (See Hamilton para 80)
In one implementation, the device detection component is configured to detect and track movement of devices, such as readers, through change in reader characteristics, such as location or mechanical and operational differences. (See Hamilton para 81) The device detection component is also configured to generate a behavioral profile of the reader or readers associated with a payment application, for example in response to a received device characteristic over time, and then register the reader with a payment processor, such as payment service system (“PSS”) for detection during a future use. (See Hamilton para 81 – merchant behavioral activity provided to the payment service system via a threat collector agent) The reader profile also includes the mapping of the reader with a payment application and is sent to the PSS coupled to the payment object reader. (See Hamilton para 81)
The behaviors including the reader-terminal-merchant relationship, also referred to as the reader profile or store signature, can be stored in a central payment service system. (See Hamilton para 84 – merchant behavioral activity stored at the payment service system) Similar to the POS terminal, the PSS may include the state machine, the reader profile as received from the POS terminal, and a merchant profile, which is a database of all merchant data and connections of readers to merchants. (See Hamilton para 84)
In an implementation, a merchant launches or opens a registration application or a mobile payment portal (e.g., a payment application installed on the device or a web application in web browser) executing on a mobile device, e.g., a phone or a laptop, or the POS terminal. (See Hamilton para 86 – payment application executed on POS terminal) The registration application can be employed by a service provider that delivers a communication service to users and may include one or more components and/or engines, or a component and/or engine can include one or more applications. (See Hamilton para 86)
The registration application further facilitates collection of and connection between the reader’s behavior and characteristics as profile 246. (See Hamilton para 88) At the time of both detection and validation of the device fingerprint for authentication, it may be useful to have data corresponding to all possible parameters, protocols and test sequences, however the reader may not be prepared or available for all kinds of communication. (See Hamilton para 89) To communicate with the reader, the device detection component 228 determines whether the corresponding communication ports in the reader are available or accessible and/or appropriate software permissions have been obtained to make the communication. (See Hamilton para 89)
The device detection component 228 may also implement logic to interact with the hardware and software components of the device 202-1 to measure the tiniest behavioral differences in the reader and record them as deviations to compare to the reader profile. (See Hamilton para 90)
The device detection component 228 may provide functionality for determining whether a reader is an outlier and for notifying merchants when an outlier is determined. (See Hamilton para 93) For example, the device detection component 228 may determine a fraud score for a reader based [on] comparison with the reader profiles. (See Hamilton para 93) The component may determine whether to associated the reader with fraudulent activity based on the fraud score and may further notify one or more merchants when a reader associated with one or more payment application or merchants has been associated with fraudulent activity. (See Hamilton para 93 – sending a signal [notification] to the reader [POS] associated with the payment application)
After the registration of the device as an authentication tool for any subsequent payment transaction is complete, the relationships that have been set up allow the terminal authenticate a transaction as being safe every time a user presents the payment object. (See Hamilton para 95)
Once saved, the registered device fingerprints or the device-object relationships can be retrieved and used as valid authentication tools for payment instruments at the time of a payment transaction, for example, through a POS terminal. (See Hamilton para 96)
In an implementation, the terminal sends the current state to the payment service system via the communication network for comparison with the reader profile that includes behaviors and previous states of readers connected to the merchant account. (See Hamilton para 98 – merchant POS terminal sends current state to the payment service system to be compared with a reader profile containing behaviors and previous reader states) The device detection component can also fetch the registered reader profile from a local storage unit. (See Hamilton para 98) The device detection component subsequently verifies reader identity based on the comparison – for example, the payment service system compares previously stored reader profiles or fingerprints of the devices registered by the merchant or profile obtained at the POS terminal through the state machine. (See Hamilton para 98) If the state does not match with a reader profile, which means that there is a deviation in behavior, the POS terminal generates a notification for the merchant to authenticate the new reader by providing an authorization code. (See Hamilton para 98) Once authenticated, the reader is added to the merchant list of authorized readers and payment transaction is fulfilled through the issuer, acquirer and card processing network. (See Hamilton para 98)
FIGS. 5A and 5B are sequence flows illustrating an example process 400 of a method of registering a reader as an authorized reader with a payment processing system. (See Hamilton para 106, Fig. 5A-5B) The process 400 can be performed by one or more components, devices, or components such as, but not limited to, the mobile device, the payment service system, merchant device or POS terminal, the payment reader, or payment beacon or other components or devices. (See Hamilton para 107) It will be understood that the method can be carried out by any component of the payment system, e.g., POS terminal, PSS or both, for example contemporaneous to the payment reader. (See Hamilton para 107) As seen above, the relationship between the merchant, the payment application, financial account and reader information is stored either locally on a merchant terminal or on a server. (See Hamilton para 107) This information is then looked up if another reader attempts to connect with the merchant application or terminal. (See Hamilton para 107) The relationship may also store the location coordinates of the reader and other devices and behavioral characteristics as the reader profile. (See Hamilton para 108) Such [behavioral and location coordinates] data is constantly and periodically updated as the behavior of a reader is learned. (See Hamilton para 108) Behavioral characteristics include locations where the reader moves, the items purchased through the reader the time when the reader is active, and so on. (See Hamilton para 108) At time t2, or contemporaneous to the above step, the payment terminal, as part of routine or in response to a trigger condition such as detection of a new device in the near field range, scans the environment to collect state of readers. (See Hamilton para 109) The entry of a new device, such as an unknown reader, may be detected through location detection techniques, such as techniques based on angulation, lateration, proximity detection, dead reckoning, geo-fence, global or local positioning systems, Bluetooth Technology, Near-Field Communication Technology, sensors-based technology, Radio frequency identification (RFID) system, or the like. (See Hamilton para 109) In an embodiment, the present subject matter, the geo-fence is defined and established based on a current location of an asset, for example using GPS data comprising latitude and longitude along with some predetermined area based on range or distance. (See Hamilton para 109)
The POS terminal then determines how it can interact with the devices by detecting devices that are within a communication range dictated by a communication protocol and then establishes communication channels with all or selected readers or other devices in its communication range. (See Hamilton para 111) Accordingly, the device detection component of the terminal generates payload and/or detection sequences adapted based on the available communication ports and in accordance with the communication protocols on which the ports operate and the detection sequences can also be information-gathering requests configured to obtain device fingerprints from the readers. (See Hamilton para 111) The response form the digital device fingerprints, which are to be used for device identification and association of a reader as a registered reader and analyzed. (See Hamilton para 114) The analysis involves decryption of the responses and generation of behavior or trends based on the responses, for example, the analysis involves comparison of the new behavior with an existing reader profile to see if there are any deviations. (See Hamilton para 114) A threshold or confidence score is also set to compare the deviation with. (See Hamilton para 114)
In an embodiment, the server or terminal then compares the deviation with the threshold. (See Hamilton para 115) If the match operation as a result of the comparison yields a “Yes”, the new reader is authenticated as being previously registered or otherwise not fraudulent. (See Hamilton para 115) However, if the match operation yields a “No”, the merchant is sent a notification on his device indicating a potential attempt to fraudulently add a new reader or payment application to the merchant’s account or the merchant is asked to key in a card verification value or some other kind of authentication code into a field in the terminal’s display message. (See Hamilton para 115) The decision of whether or not a new device is potentially fraudulent is thus determined, for example, based on deviation in known behavior of a merchant environment of readers and terminals and their intention with each other and any anomaly there is indicative of a potentially fraudulent event. (See Hamilton para 115)
Hamilton discloses a method to detect swapping of a payment card reader associated with a merchant with another payment card reader associated with a fraudulent user that discloses if a current state of the payment card reader, wherein the current state is capable of reflecting change of behavior of the payment card reader with respect to the POS terminal as a result of swapping between the payment card reader and the other card reader; comparing, by the payment service system, the current state of the payment card reader with the behavioral model of payment card reader, and if the current state indicates a deviation from the behavioral model of the payment object reader due to the other payment card reader and the deviation exceeds a threshold level, generating a notification on the POS terminal to indicate that an attempt to fraudulently swap the payment card reader with the other payment object reader is in progress. (See Hamilton para 136 - generating a notification on the POS terminal [sending a signal to the POS])
Hamilton further discloses that the method further comprises canceling one or more transactions involving the payment card reader and the other payment card reader; and automatically disabling connection between the other payment card reader or the payment card reader and the POS terminal. (See Hamilton para 138 – automatically disabling connection between the other payment card reader and the POS terminal) The disclosure further indicates if the change of state is not within a threshold deviation the method may perform one or more actions to revert the payment entity to the original state. (See Hamilton para 141)
A payment system to perform an action based on a change in behavior of a payment entity is disclosed to include obtaining an original state of a payment entity based on a behavioral model, wherein the behavioral model defines an expected behavior of the payment entity and wherein the payment entity is registered to a merchant and detecting a change in the original state of the payment entity, wherein the change in the original state is triggered by another payment entity not authorized by the merchant. (See Hamilton para 158) The change of the original state is compared with a threshold deviation defined by the behavioral model and if the change of state is not within the threshold deviation, performing one or more actions to revert the payment entity to the original state. (See Hamilton para 158) The system is further described as engaging with a merchant using a communication identifier selected from a group of a name, address, an email address, a phone number, and a payment application to indicate possibility of fraud attack involving the payment entity. (See Hamilton para 167)
A method for detecting a security threat with a payment card reader capable of communicating with a point-of-sale (POS) terminal where the method comprises receiving, from a POS terminal a request for establishing a wireless connection with the payment card reader, the payment card reader and the POS terminal together forming a POS system for processing a payment transaction between the merchant and a buyer, wherein the request includes hardware and/or software data pertaining to the POS terminal and applications executing thereon. (See Hamilton para 175) The method then discloses detecting, by a sensor of the payment card reader and based on the request, whether a payment application is executing on the POS terminal; if the payment application is executing on the POS terminal, further determining, by a processor of a payment server system, whether the payment card reader is linked with the payment application, wherein the links between payment card readers and payment applications are stored in a data-structure within the payment service system. (See Hamilton para 175) If the data-structure indicates a link between the payment card reader and the payment application, the method establishes the wireless connection between the payment card reader and the POS terminal; and if the data structure indicates a link between the payment card reader and another payment application, generating a notification for the POS terminal connected to the other payment application to indicate that an unrecognized POS terminal is attempting to connect. (See Hamilton para 175 – generating a notification for the POS terminal connected to the other payment application)
Further, the method continues that in response to determining that the payment card reader is not linked to the payment application, canceling the payment transaction involving the payment card reader and the POS terminal executing the payment application; and automatically disabling the wireless connection between the payment card reader and the POS terminal. (See Hamilton para 177 – automatically disabling the wireless connection between the payment card reader and the POS terminal)
Hamilton further discloses generating a predictive model where the generating further includes obtaining at least one characteristic corresponding to the first payment entity, wherein the characteristic is related to the operational or physical features of the first payment entity, including information of the payment application with which the first payment entity interacts; tracking the characteristic over a period of time; and analyzing the tracked characteristic to generate the predictive model. (See Hamilton para 182) Further, the predictive model to indicate a probability of the request being fraudulent, and wherein the predictive model is based on one or more characteristics of the second payment entity selected from a group of characteristics including timing parameters, radiated performance, wireless performance, quality of communication links, radio frequency response, transmission measurements, receiver measurements, and engineering tolerances. (See Hamilton para 183)
The predictive model can also be based on an external state of the payment entity as sampled by one or more sensors including: a geographical or physical location of the payment entity; a linear or angular velocity or acceleration of the payment entity; a directional heading of the payment entity; a temperature external to the payment entity; a tilt or rotation of the payment entity; and intensity of light external to the payment entity; a level of sound external to the payment entity; or a time. (See Hamilton para 185) The predictive model further includes one or more conditions to be applied during authorization of the other payment entity, wherein the conditions include at least one of: a time period within which the payment entity is authorized; a particular merchant requesting the authorization; a particular category of the merchant requesting the authorization; a particular location from where the buyer is requesting the authorization; a predefined limit of the authorization; an identity of the merchant associated with the other payment entity; and a particular type of goods or services corresponding to a payment transaction. (See Hamilton para 187)
While Hamilton discloses the invention as noted above and discloses identifying a fraud or threat from merchant behavioral activity, the use of a predictive model and analyzing tracked characteristics to generate a behavioral model thus implies training a merchant behavioral threat modeler, it is not fully taught.
Hosseinali discloses a system for fraudulent merchant detection that includes a commerce platform system and plurality of merchant systems. (Hosseinali para 23 and Fig. 1) In an embodiment, the one or more merchant systems may be mobile computing devices that utilize the services of the commerce platform system. (See Hosseinali para 23) In an embodiment, the commerce platform system provides financial processing services to one or more merchant systems. (See Hosseinali para 26) In embodiments, various services provided to the merchant systems are susceptible to fraud and in embodiments one or more fraudulent merchant systems are detected by merchant fraud detection system to identify fraudulent merchant system(s) and take one or more remediative actions against the fraudulent merchant systems. (See Hosseinali para 28) The merchant fraud detection system is a machine learning model based fraud detection system that employs an ensemble of different types of machine learning models to detect various types of fraudulent merchant activities. (See Hosseinali para 28)
In embodiments, the ensemble of machine learning models can include a first machine learning model trained to detect fraudulent activities utilizing structured data inputs indicative of merchant transaction data (e.g., a number of charge declines, a total amount charged, a number of accounts associated with a merchant system, a number of accounts established within a specific time period (i.e., last hour, last 24 hours, last week, etc.), a number of charges with a specific time period, etc.) as well as other numeric features associated with the merchant system. (See Hosseinali para 29) In further embodiments, the ensemble of machine learning models can include a third machine learning model trained to detect fraudulent activities utilizing time-based data, such as an identification of commerce platform system API events and an associated time of the events (e.g., to detect a number of events within a time period, a flow of events, an order of various events, as well as other time based events occurring at the commerce platform system on behalf of a merchant system. (See Hosseinali para 29 – trained merchant behavioral threat)
Each of these models in the ensemble includes a model for detecting a specific merchant’s activities as being indicative of fraud in real-time as they occur based on the properties of the detected activities. (See Hosseinali para 29 – real-time detection of specific merchant’s activities indicative of fraud) Furthermore, the fraud detection is performed at scale for each merchant and each merchant transaction processed by the commerce platform system(s). (See Hosseinali para 29 – fraud detection performed at scale for each merchant and each merchant transaction)
Each of the machine learning models is trained on annotated commerce platform systems data (e.g., past transaction data, past onboarding data, past time-based event data, etc.), where the annotation may be generated by a human review process, by a previously machine learning model fraud prediction verified as correct and/or incorrect as part of a feedback loop for retraining one or more machine learning models, or a combination thereof. (See Hosseinali para 31 – training machine learning models to detect fraudulent activities [training a merchant behavioral threat modeler based on prior merchant behavior]) Furthermore, each of the models is trained utilizing an appropriate iterative training process for the model being trained. (See Hosseinali para 31 – iterative training of the model)
In embodiments, a merchant system, remotely engages with services provided by the commerce platform system(s) via a network. (See Hosseinali para 33) For example, merchant system may establish an account via a web interface of the commerce platform system(s), process transactions via one or more APIs or software development kits (SDKs) distributed by the commerce platform system(s), have agent accounts established and associated with merchant system, process API and/or SDK based transactions using the agents, etc. (See Hosseinali para 33 – software application for merchant systems) These actions are stored by the services of the commerce platform system(s), where the services are responsible for performing the merchant system requested actions, for example in data store(s) of those services. (See Hosseinali para 33) Then, the models discussed herein may input data indicative of one or more characteristics associated with the merchant system, the requested action, or a combination thereof, in-line with a transaction being requested to detect merchant system fraud as the transaction is occurring. (See Hosseinali para 33) When fraud is detected, the transaction can be blocked, a merchant system account can be frozen or suspended, a merchant account can be deactivated, and/or some other remediative action(s) performed by the commerce platform system(s) in real time to prevent the detected merchant system fraud. (See Hosseinali para 33)
The remediative actions are communicated from merchant fraud detection system(s) to the effected merchant system, which may contest the fraud determination by providing proof of lack of fraud, insufficiency of data used to detect fraud, or some other form of proof of legitimacy of a transaction or set of transactions. (See Hosseinali para 34) When verified, this proof may be used to annotate training data for retraining one or more machine learning models to further improve the function of those models in detecting fraud forming a feedback loop to ensure that usage of the models will result in improved fraud detection accuracy and improved avoidance of false fraud detections. (See Hosseinali para 34)
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 method and systems to prevent swapping of a payment reader with another reader by tracking behavior of readers and developing a specific model for the reader based on the behavioral analysis of Hamilton with the more detailed disclosure of training machine learning models to detect fraudulent merchant transactions and take one or more remediative actions against the fraudulent merchant systems as disclosed by Hosseinali in order to improve fraud detection accuracy.
Regarding Claims 2 and 11, these substantially similar claims recite the limitations of Claims 1 and 10 and as to those limitations are rejected for the same basis and reasons as disclosed above. Further, Hamilton in view of Hosseinali discloses the following:
wherein the merchant behavioral activity comprises a login time to the payment application and/or a merchant login account. (See Hamilton paras 32-34, 86, and 115 – change of state notifications when a payment reader is connected to the POS terminal that is collected and analyzed over time corresponding to the behaviors associated with the reader; stores subsequent association of the reader to a payment application)
Regarding Claims 3 and 12, these substantially similar claims recite the limitations of Claims 1 and 10 and as to those limitations are rejected for the same basis and reasons as disclosed above. Further, Hamilton in view of Hosseinali discloses the following:
wherein the merchant behavioral activity comprises a geolocation of the point-of-sale terminal. (See Hamilton paras 32-34, 43, 57, 86, 109, 141, and 185)
Regarding Claims 5 and 14, these substantially similar claims recite the limitations of Claims 1 and 10 and as to those limitations are rejected for the same basis and reasons as disclosed above. Further, Hamilton in view of Hosseinali discloses the following:
wherein the preventative action is based on a merchant profile or a merchant risk category for the merchant. (See Hamilton paras 84, 155, 187, 198 and Cl. 15)
Regarding Claims 8 and 17, these substantially similar claims recite the limitations of Claims 1 and 10 and as to those limitations are rejected for the same basis and reasons as disclosed above. Further, Hamilton in view of Hosseinali discloses the following:
wherein the preventative action further comprises sending a second signal to the point-of-sale terminal that causes the point-of-sale terminal to disable the point-of-sale terminal by erasing keys stored by the point-of-sale terminal. (See Hamilton paras 17-21, 92, 111-115, 138, 141, 158, 175, 177, 190 – connection is purged, requiring repair; automatically disabling; performing one or more actions to revert the payment entity to the original state)
Regarding Claims 9 and 18, these substantially similar claims recite the limitations of Claims 1 and 10 and as to those limitations are rejected for the same basis and reasons as disclosed above. Further, Hamilton in view of Hosseinali discloses the following:
wherein the preventative action further comprises rejecting a transaction authorization request. (See Hamilton paras 17, 138, 177, 186, Cl. 16)
Regarding Claim 20, this claim recites the limitations of Claim 19 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Hamilton in view of Hosseinali discloses the following:
wherein the preventative action further comprises requiring out-of-band authentication from the merchant, sending a signal to the payment application that logs the merchant out of the payment application, or rejecting a transaction authorization request. (See Hamilton paras 17, 21, 46, 98, 115, 122, 136, 138, 141, 177, 186 and Cl. 14 & 16)
Regarding Claims 21-23, these substantially similar claims recite the limitations of Claims 1, 10 and 19 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Hamilton in view of Hosseinali discloses the following:
wherein the preventative action comprises deactivating the point-of-sale terminal. (See Hamilton paras 136-138, 177, Cl. 16)
Response to Arguments
Applicant's arguments filed October 16, 2025 have been fully considered as disclosed below.
As to the Claim Objections:
Applicant is thanked for the corrections made to obviate the claim objections previously raised. (See Applicant’s Arguments dated 10/16/2025, page 6)
As to the Claim Interpretation:
Applicant notes that they do not necessarily agree with the claim interpretation section. (Id. at page 6) Examiner acknowledges Applicant’s statement.
As to the 112(a) Rejections:
As to the limitations amending Claims 1, 10 and 19 to recite “wherein the preventative action comprises sending a signal to the point-of-sale terminal that causes the payment terminal to log the merchant out of the payment application” this correction has resolved this portion of the previously asserted 112(a). (Id. at pages 7-8)
As to the issue regarding the limitation in Claim 1 (and substantially similarly in Claims 10 and 19) reciting “identifying, by the backend computer program, fraud or threat from the merchant behavioral activity by providing the merchant behavioral activity to a merchant behavioral threat model that is trained with prior merchant behavior and/or terminal configuration behavior”, Applicant asserts that they are unclear what the “implication” is. (Id. at page 9) As further clarified in the revised 112(a) rejection of record, the structure of the recitation leaves open the possibility that the process of training the modeler is attempting to be claimed as within the scope of the method recited. While Examiner appreciates Applicant’s argument that they are not attempting to claim the process of training, the claim language will need to reflect exclusion of that possibility. (Id.) The issue raised with regards to the algorithm is reflective of the possibility of that reading as currently claimed. Examiner does not contest that there is sufficient support for the use of a modeler that is trained outside of the method claimed that can be utilized by a computer program running on a backend computer, the issue lies within the current claim language that leaves open the possibility of an attempt to claim a recursive training process in the claims.
As to Claims 8 and 17, Applicant argues that the recitation of a second signal would have been recognized by one of ordinary skill, even though it is not disclosed directly. (Id. at page 10) Examiner disagrees. The specification indicates a preventative action in response to the identified fraud or threat and discloses different embodiments for distinct preventative actions. (See Applicant Spec paras 4, 8, 10-13, 17, 19-23) Even in paragraph 47, the backend computer program is disclosed to take a preventative action (singular) with the terminal or with the merchant account. While paragraph 47 provides a number of examples, it appears that in each instance disclosed in the specification, there is a preventative action taken, not multiple, layered actions with separate signals. The rejection is maintained as to the remaining issues, as seen in the rejection in chief.
Regarding the 112(d) Rejections:
Applicant alleges that they have appropriately addressed the 112(d), however Examiner disagrees. (See Applicant Arguments dated 10/16/2025, page 10) The issues still remain as disclosed in the rejection in chief.
Regarding the 101 Rejections:
Examiner has updated the rejection in chief to account for the newly amended limitations, as seen in the rejection in chief.
Applicant argues that the previous response reciting “…wherein the preventative action comprises sending a signal to the point-of-sale terminal that that causes the payment application to log the merchant out of the payment application” and argues that like Example 46 from the October 2019 PEG the claims receive merchant behavioral activity and uses that behavioral activity to control the point-of-sale terminal. (Id. at pages 10-11) Applicant then replicates a portion of Examiner’s previous response where it was noted that the claims did not recite a monitoring or sensing component. (Id. at page 11)
Applicant disagrees and argues that Claim 3 of Example 46 does not include a “monitoring step” – it recites “obtaining by a radio frequency reader mounted on or near the sorting gate, animal-specific information from the animal sensor when the animal sensor is within proximity to the radio frequency reader, the animal-specific information comprising animal identification data and at least one of body position data, body temperature data, feeding behavior data, and movement pattern data.” Applicant continues, arguing that even if this was the alleged monitoring that the example indicates that the steps conducted by automatically operating the sorting gate, by the processor sending a control signal to the sorting gate to route the animal either into a holding pen when the animal exhibits an aberrant behavioral pattern or to send a control signal to the sorting gate to permit the animal to pass through freely is a meaningful limitation that integrates the operating of the gate and routing of the animals in a particular way. (Id. at pages 11-12)
Applicant then asserts that the instant limitations are analogous and argues that the computer program receives merchant behavioral data and uses that behavioral activity to control the point-of-sale terminal. (Id. at page 12) Applicant argues that the executing by the backend computer program, a preventative action in response to the identified fraud or threat, wherein the preventative action comprises sending a signal to the point-of-sale terminal that causes the payment terminal to log out of the payment application recitation practically applies the exception. (Id. at page 12) Applicant further references the August 4, 2025 for the assertion that close calls should only have rejections asserted when it is more likely than not that the claim is ineligible. (Id. at page 13)
Examiner is of another opinion as to subject matter patent eligibility. Based on the specification, the merchant logs onto a point-of-sale terminal by entering login information. (See Applicant Spec para 42) The merchant behavioral activity is sent to the backend and processed by a computer program to determine whether there is fraud or a threat. The backend computer program may take soft or hard preventative actions including requiring a merchant to login again, may refuse communications, may send a signal that causes the payment terminal to log the merchant out of the payment application. The signal is not recited in the claims or the specification to be a control signal and the type of signal is not defined or bounded. The use of “causes” does not exclude the possibility that there are interim steps before the terminal logs out of the merchant account. This may be nothing more than a signal sent telling the merchant to log out of the merchant account.
The 101 rejection is maintained.
Regarding the 103 Rejections:
Applicant argues that the prior art does not disclose “…wherein the preventative action comprises sending a signal to the point-of-sale terminal that that [sic] causes the payment application to log the merchant out of the payment application” and alleges that none of the cited paragraphs disclose a backend computer program sending a control signal to the point-of-sale terminal that causes the payment terminal to log the merchant out of the payment application. (See Applicant Arguments dated 10/16/2025, page 13)
Examiner disagrees with Applicant’s assertions. First, there is no “control signal” recited, the claim and the specification only disclose a signal. This signal is not defined and is broadly construed.
Secondly, the disclosure of Hamilton does disclose the claim limitations as annotated by Examiner in the previous rejection. Applicant refers to five of the cited paragraphs and concludes that the limitations are not taught. Examiner disagrees and highlights at least the following as previously presented in the rejection in chief (indented) with additional explanation:
In another implementation, a method to obtain an original state of a payment entity, such as a payment reader or a POS terminal, based on a behavioral model that defines an expected behavior of the payment entity. (See Hamilton para 19) The methods and systems detect a change in the original state of the payment entity, for example, if the payment entity moves in a manner different from its normal behavior, disconnects or connects with a new device, and so on. (See Hamilton para 19) The server compares the change of the original state with a threshold value, also referred to as threshold deviation, defined by the behavioral model and if the change of state is not within the threshold deviation, the server either reverts the payment entity to the original state or notifies the merchant to take corrective actions. (See Hamilton para 19 – the server compares the change of the original state with a threshold deviation defined by the behavioral model and if the change is not within the threshold deviation either reverts the payment entity to the original state or notifies the merchant to take corrective action [identifying fraud or a threat from merchant behavioral activity (including merchant behavior and/or terminal configuration behavior) by comparing it with the behavioral model threshold and executing a preventative action to the fraud or threat])
Hamilton thus discloses that the server compares the original state with a threshold value as defined by the behavioral model and if the change of state is not within the threshold deviation, the server either reverts the payment entity to the original state or notifies the merchant to take corrective actions. This disclosure corresponds to identifying fraud or a threat from merchant behavioral activity and executing a preventative action to the identified fraud or threat.
The electronic interactions between the merchant and the customer take place between the customer’s payment instrument 10 and the merchant’s payment terminal 20. (See Hamilton para 25) The merchant has a payment terminal 20 such as a payment terminal or other electronic device that is capable of processing payment information (e.g., encrypted payment card data and user authentication data) and transaction information (e.g., purchase amount and point-of-purchase information), such as a smart phone or tablet running a payment application. (See Hamilton para 25 – merchant POS [payment terminal] running a payment application) In embodiments, the payment terminal may communicate with payment server over the network. (See Hamilton para 26) Although the payment server may be operated by a single entity, in one embodiment the payment server may include any suitable number of servers operated by any suitable entities, such as a payment service system and one or more banks of the merchant and customer. (See Hamilton para 26)
Here, Hamilton is establishing that the merchant has a payment terminal capable of processing payment information such as a smart phone or tablet running a payment application that communicates with the payment server.
Hamilton discloses that the term “registration application” or “payment application” as used here, refers to any registration application that enables communication between users (e.g., sender and recipient of a message) over a wired or wireless communications network. (See Hamilton para 30) The registration application can be employed by a service provider that delivers a communication service to users, e.g., chat capability or capability to enter payment information, for example, through a form. (See Hamilton para 30) In an implementation, the merchant uses the registration application to register the payment reader with an account association with the registration application, for example, at the time of pairing or bonding the payment reader with the POS terminal. (See Hamilton para 32) The server can store such relationships between the payment reader and the POS terminal either locally or within the server in specific data structures and in the case of multiple readers, similar to the payment reader being connected to the POS terminal, the server can also store the hierarchy of readers, the identity of such readers, profile of the readers and location of the readers with respect to the POS terminal, among other things. (See Hamilton para 32)
Hamilton is further disclosing that the registration application or payment application (used interchangeably within Hamilton) enables communication between the users and can be used by the service provider to deliver the capability to enter payment information and register the payment reader with an account association.
If the payment reader or any other reader connected to the POS terminal changes state with respect to a current state, the server generates a notification, e.g., via the state machine, to indicate to the merchant than an anomaly has occurred. (See Hamilton para 33 – notification sent indicating an anomaly if the payment reader or any other connected reader to the POS changes with respect to the current state) In one implementation, any current transactions may be paused until the merchant has verified the state of all readers, or if the server indicates presence of an unknown reader in proximity to the POS terminal. (See Hamilton para 33) The server can also determine change of state in the context of change in hierarchy of payment readers, detection of another merchant account by detection of a new registration application. (See Hamilton para 34)
The state machine stores the states of the reader or readers associated with a merchant account or payment application in a database as a data structure hereinafter referred to as a reader profile, which corresponds to the identity of the reader in terms of registration number, unique identifier, association of the reader with a payment or merchant account, the association of the reader with a mobile or POS terminal on which a payment application is executing and so on. (See Hamilton para 34 – POS terminal on which a payment application is executing) The reader model or profile can also correspond to the behavior or behaviors associated with the reader and collected and analyzed over time, or even an explicit or desired behavior set at the time of registration. (See Hamilton para 34 - prior merchant and/or terminal configuration behavior) Examples of such behavior includes determination of territory in which the reader operates and accordingly determine, the “movement” profile, for example the merchant may move the reader from one terminal to another terminal, may move the reader laterally or only in a certain direction, or may not move the reader at all, such “movement” behaviors can be stored in movement profiles. (See Hamilton para 34 - prior merchant and/or terminal configuration behavior) The state machine checks the system at predefined time intervals or at random time intervals to determine whether the state of the reader has deviated, above or below a threshold level, from the reader profile. (See Hamilton para 34) If the state machine identifies a deviation of behavior, the state machine contacts the merchant through a communication identifier, e.g., email address, phone number, etc., stored in the payment server. (See Hamilton para 34 – if deviation of behavior is identified, the merchant is contacted) The notification may indicate to the merchant that there is potentially a new reader or new behavior, which may be a fraudulent attempt. (See Hamilton para 34 – notification may indicate fraudulent activity)
These paragraphs disclose that the server generates a notification indicating an anomaly (threat or fraud) and pauses any current transactions until the merchant verifies the state of all readers.
The device detection component 228 may provide functionality for determining whether a reader is an outlier and for notifying merchants when an outlier is determined. (See Hamilton para 93) For example, the device detection component 228 may determine a fraud score for a reader based [on] comparison with the reader profiles. (See Hamilton para 93) The component may determine whether to associated the reader with fraudulent activity based on the fraud score and may further notify one or more merchants when a reader associated with one or more payment application or merchants has been associated with fraudulent activity. (See Hamilton para 93 – sending a signal [notification] to the reader [POS] associated with the payment application)
In an embodiment, the server or terminal then compares the deviation with the threshold. (See Hamilton para 115) If the match operation as a result of the comparison yields a “Yes”, the new reader is authenticated as being previously registered or otherwise not fraudulent. (See Hamilton para 115) However, if the match operation yields a “No”, the merchant is sent a notification on his device indicating a potential attempt to fraudulently add a new reader or payment application to the merchant’s account or the merchant is asked to key in a card verification value or some other kind of authentication code into a field in the terminal’s display message. (See Hamilton para 115) The decision of whether or not a new device is potentially fraudulent is thus determined, for example, based on deviation in known behavior of a merchant environment of readers and terminals and their intention with each other and any anomaly there is indicative of a potentially fraudulent event. (See Hamilton para 115)
Hamilton discloses a method to detect swapping of a payment card reader associated with a merchant with another payment card reader associated with a fraudulent user that discloses if a current state of the payment card reader, wherein the current state is capable of reflecting change of behavior of the payment card reader with respect to the POS terminal as a result of swapping between the payment card reader and the other card reader; comparing, by the payment service system, the current state of the payment card reader with the behavioral model of payment card reader, and if the current state indicates a deviation from the behavioral model of the payment object reader due to the other payment card reader and the deviation exceeds a threshold level, generating a notification on the POS terminal to indicate that an attempt to fraudulently swap the payment card reader with the other payment object reader is in progress. (See Hamilton para 136 - generating a notification on the POS terminal [sending a signal to the POS])
These paragraphs indicate that the device detection component may determine fraudulent activity based on a determined fraud score and notify one or merchants when fraud is associated with a payment application or merchant. Further, the merchant may be asked to key in a card verification value or some other kind of authentication code when sent a notification indicating a potential fraudulent attempt.
Hamilton further discloses that the method further comprises canceling one or more transactions involving the payment card reader and the other payment card reader; and automatically disabling connection between the other payment card reader or the payment card reader and the POS terminal. (See Hamilton para 138 – automatically disabling connection between the other payment card reader and the POS terminal) The disclosure further indicates if the change of state is not within a threshold deviation the method may perform one or more actions to revert the payment entity to the original state. (See Hamilton para 141)
A method for detecting a security threat with a payment card reader capable of communicating with a point-of-sale (POS) terminal where the method comprises receiving, from a POS terminal a request for establishing a wireless connection with the payment card reader, the payment card reader and the POS terminal together forming a POS system for processing a payment transaction between the merchant and a buyer, wherein the request includes hardware and/or software data pertaining to the POS terminal and applications executing thereon. (See Hamilton para 175) The method then discloses detecting, by a sensor of the payment card reader and based on the request, whether a payment application is executing on the POS terminal; if the payment application is executing on the POS terminal, further determining, by a processor of a payment server system, whether the payment card reader is linked with the payment application, wherein the links between payment card readers and payment applications are stored in a data-structure within the payment service system. (See Hamilton para 175) If the data-structure indicates a link between the payment card reader and the payment application, the method establishes the wireless connection between the payment card reader and the POS terminal; and if the data structure indicates a link between the payment card reader and another payment application, generating a notification for the POS terminal connected to the other payment application to indicate that an unrecognized POS terminal is attempting to connect. (See Hamilton para 175 – generating a notification for the POS terminal connected to the other payment application)
Further, the method continues that in response to determining that the payment card reader is not linked to the payment application, canceling the payment transaction involving the payment card reader and the POS terminal executing the payment application; and automatically disabling the wireless connection between the payment card reader and the POS terminal. (See Hamilton para 177 – automatically disabling the wireless connection between the payment card reader and the POS terminal)
Here, Hamilton discloses automatically disabling the connection between the other payment card reader and the POS terminal and if the change of state is not within a threshold deviation, the method may perform one or more actions to revert the payment entity to the original state. Further, the process of establishing a wireless connection between the payment card reader and the POS to form a POS system for processing a payment between a merchant and buyer is disclosed. If the data structure indicates a link between the payment card reader and the payment application, the method establishes a wireless connection. This disclosure indicates that there is a procedure for establishing (or logging into) a payment application to enable the POS to take payments.
The method further indicates that if a link between the payment card reader and another payment application is detected, the POS terminal is notified that an unrecognized POS terminal is attempting to connect. In the event that it is determined that the payment card reader is not linked to the payment application, the payment transaction involving the payment card reader and POS terminal is canceled and the wireless connection between the payment card reader and the POS terminal is disabled. Disabling the POS terminal and the wireless connection will also disable the payment application (as it requires the wireless connection), thus effectively logging the merchant out of the payment application.
The limitations are taught by the prior art and the 103 rejection is maintained.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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 February 6, 2026