DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on November 12, 2025 has been entered.
Status of Claims
• This action is in reply to the RCE filed on November 12, 2025.
• Claims 1, 14, and 20 have been amended and are hereby entered.
• Claims 4, 6-13, and 17-19 have been canceled.
• Claims 1-3, 5, 14-16, and 20 are currently pending and have been examined.
• This action is made Non-FINAL.
Response to Arguments
Applicant’s arguments filed October 13, 2025 have been fully considered but they are not persuasive.
The Examiner is withdrawing the 35 USC § 112 rejections due to Applicant’s amendments.
New 35 USC § 112 rejections have been entered due to applicant’s amendments.
Applicant’s arguments with respect to 35 USC § 101 have been fully considered and are not persuasive.
Regarding Applicant’s argument on page 6, that the claims recite a technical solution for a technical problem, the Examiner respectfully disagrees. Applicant’s reliance upon the cited portions of the Specification are not persuasive. In response to Applicant’s arguments, the Examiner notes that the pending claims do not describe a technical solution to a technical problem. The pending claims are directed to solving the problem of mitigating fraud associated with payment transactions between parties (see at least [0002]-[0003] and [0012] of the Specification). The claims of the instant application describe an improvement to a business process i.e., mitigating fraud associated with payment transactions between parties, not improvement in the functioning of the computer itself or an improvement to any other technology or technological field
Regarding Applicant’s arguments on page 7, regarding DDR, Applicant’s reliance upon DDR is misplaced. The claims here are not like those the Court found patent eligible in DDR, in which the inventive concept was in the modification of conventional mechanics behind website display to produce a dual-source integrated hybrid display because Applicant’s claims here in the instant application do not address problems unique to the Internet or require an arguably inventive device or technique for displaying information. Rather, the pending claims are directed to solving the problem of mitigating fraud associated with payment transactions between parties (see at least [0002]-[0003] and [0012] of the Specification). The claims of the instant application describe an improvement to a business process i.e., mitigating fraud associated with payment transactions between parties, not improvement in the functioning of the computer itself or an improvement to any other technology or technological field.
Regarding Applicant’s arguments on pages 7-8, that the claims impose a meaningful limitation on the abstract idea and that the claims integrate a practical application, the argument has been considered and is not persuasive. Under the Patent Subject Matter Eligibility analysis, Step 2A, prong two, integration into a practical application requires an additional element(s) or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the exception. Limitations that are not indicative of integration into a practical application are those that generally link the use of the judicial exception into a particular technological environment or field of use-see MPEP 2106.05(h). Here the additional elements of claim 1 include network-initiated transactions; a host computing device; network details; a virtual product; a computing device; a data repository. The Examiner notes that the host computer of claim 1 is also in communication with an issuer and acquirer. The additional elements of claim 14 include a system for use in associating a confirmed user (CU) to network-initiated transactions, the system comprising a host computing device configured to perform claim functions; network details; a computing device; a data repository. The Examiner notes that the host computer of claim 14 is also in communication with an issuer and acquirer. The additional elements are such that they amount to no more than generally linking the use of the judicial exception to a particular technological environment or field of use (e.g., a computer network) (see MPEP 2106.05(h)).
Furthermore, and in response to Applicant’s arguments on page 8 where Applicant argues the claims provide improvement to technology, in determining whether a claim integrates a judicial exception into a practical application, a determination is made of whether the claimed invention pertains to an improvement in the functioning of the computer itself or any other technology or technical field (i.e., a technological solution to a technological problem). Here, the claims recite generic computer components, i.e., a generic processor, a memory storing a computer program executable by the processor to perform the claimed method steps and system functions. The processor, memory and system are recited at a high level of generality and are recited as performing generic computer functions customarily used in computer applications.
Furthermore, the Specification describes a problem and improvement to a business or commercial process at least at [0002]-[0003] and [0012] of the Specification, describing improving mitigating fraud associated with payment transactions between parties.
Regarding Applicant’s arguments on pages 8-9, regarding Bascom, Applicant’s reliance upon Bascom is misplaced. The claims here are not like those the Court found patent eligible in Bascom, in which the inventive concept was the unconventional arrangement of the installation of a filtering tool at a specific location, remote from the end-users, with customizable filtering features specific to each end user, this design permitted the filtering tool to have both the benefits of a filter on a local computer and the benefits of a filter on the [Internet Service Provider] server and was not conventional or generic, instead, the patent claimed and explained how a particular arrangement of elements was “a technical improvement over prior art ways of filtering such content.” (BASCOM, 827 F.3d at 1345.). In the instant application the claims do not have an inventive concept found in the non-conventional and non-generic arrangement of the additional elements.
The claims are not patent eligible.
Applicant’s arguments with respect to 35 USC § 103 have been fully considered and are not persuasive.
Regarding Applicant’s argument on pages 10-11, that the AReq of Gosset is not an authorization message (as claimed), the Examiner respectfully disagrees. As an initial matter, the Examiner is interpreting an “authorization message” consistent with the Specification at [0056], which gives an example of an authorization message being an authorization request message. Furthermore regarding this argument, it is noted that the features upon which applicant relies (i.e., “an authentication phase consistent with EMV 3DS”) are not recited in the rejected claim(s). 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, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Therefore, the Examiner is interpreting the AReq message of Gosset as an authorization message.
Regarding Applicant’s arguments on page 11, that the cited art of record does not teach appending a flag to the authorization message based on the authorization message including the transaction ID, the Examiner respectfully disagrees. Gosset teaches appending a flag to the authorization message at least at [0133]-[0135], disclosing generating an RBA result and embedding the RBA result into an AReq message. And Gosset teaches appending based on the authorization message including the transaction ID at least at [0044] which describes that AReq data includes authentication data, and at least at [0067]-[0068] describing authentication data includes transaction data (amount, currency, date, and time), device data (IP address, device info, and channel data), cardholder data (account number and shipping address), and merchant data (name, category, and country), and at least at [0133] describing analyzing the data in the AReq message to generate the RBA result. The prior art of record therefore teaches this limitation.
Regarding Applicant’s arguments on page 11, that there is no proper motivation to combine Prendergast with Gosset, the Examiner respectfully disagrees. In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, from the teaching of Prendergast, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify Gosset with the teachings of Prendergast, in order to decrease errors and delays of processing transactions, and in order to prevent transactions from failing, and in order to improve security (see Prendergast at least at [0002]-[0003]).
Regarding Applicant’s arguments on pages 11-12 regarding claim 5, the Examiner respectfully disagrees that these are two separate embodiments. Gosset at [0032] states “Any feature of any drawing may be referenced and/or claimed in combination with any feature of any other drawing.” And, Gosset at [0086] states “The systems and processes are not limited to the specific embodiments described herein. In addition, components of each system and each process can be practiced independent and separate from other components and processes described herein. Each component and process also can be used in combination with other assembly packages and processes.” Applicant’s argument is therefore unpersuasive.
Regarding Applicant’s arguments on page 13, that the AReq message of Gosset is distinguishable from the authorization message of the claims, the Examiner respectfully disagrees and again notes the Examiner is interpreting an “authorization message” consistent with the Specification at [0056], which gives an example of an authorization message being an authorization request message.
Applicant further argues, on page 13, that there is no motivation to combine Gosset with the teaching of Dee. The Examiner respectfully disagrees. In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, from the teaching of Dee it would have been obvious to one having ordinary skill in the art before the effective filing date to modify Gosset with the teachings of Dee in order to improve security and reduce friction in payment systems (see Dee at least at [0002] and [0018]-[0020]).
For the reasons above, Applicant’s arguments are not persuasive.
Examiner’s Note
In view of the Specification at [0039]-[0044], the Examiner is interpreting a computing device as comprising hardware. A software per se rejection would therefore not be appropriate for claim 14.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-3, 5, 14-16, and 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 recites the limitation "the authorization request.” There is insufficient antecedent basis for this limitation in the claim.
Claim 14 has similar limitations found in claim 1 above, and therefore is rejected by the same rationale.
The rest of the dependent claims are rejected due to their dependency to a rejected claim.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-3, 5, 14-16, and 20 are rejected under 35 U.S.C. 101 because the claimed invention recites an abstract idea without significantly more. Independent claims 1 and 14 are directed to a method (claim 1) and a system (claim 14). Therefore, on its face, each independent claim 1 and 14 are directed to a statutory category of invention under Step 1 of the Patent Subject Matter Eligibility analysis (see MPEP 2106.03).
Under Step 2A, Prong One of the Patent Subject Matter Eligibility analysis (see MPEP 2106.04), claims 1 and 14 recite, in part, a system, a method, and an apparatus of organizing human activity. Claim 1 recites a computer-implemented method for use in associating a confirmed user (CU) to transactions, the method comprising: receiving, in connection with an authentication message associated with a transaction, details for the transaction for a product between an account of a user and a first party, the details including at least a delivery data element specific to delivery of the product and an identifier of the user involved in the transaction, and the details associated with a transaction identifier for the transaction; identifying details for multiple prior transactions between the account of the user and the first party; accessing details for the multiple prior transactions; comparing the details for said transaction and the details for the multiple prior transactions; receiving an authorization message from an acquirer associated with the first party, the host computing device being part of a processing network; and based on the authorization request including the transaction identifier for the transaction and a match between the details for said transaction and the details for the multiple prior transactions, appending a confirmed user flag to the authorization message for the transaction and transmitting the authorization request with the flag to an issuer of the account of the user designated to fund the transaction, whereby the issuer relies on the confirmed user flag in deciding to approve or decline the transaction for the virtual product.
Claim 14 recites similar limitations as claim 1 above. And claim 14 further recites store the details in association with the transaction identifier; transmit the authorization message, with the confirmed user flag, to the issuer.
The limitations, as drafted, is a process that, under its broadest reasonable interpretation, covers commercial and legal interactions (certain methods of organizing human activity), but for the recitation of generic computer components. The claims as a whole recite a method of organizing human activity. The claimed inventions allows for comparing past transaction data to current transaction data to determine to approve or decline the transaction, which is a fundamental economic principle or practice of mitigating risk and commercial and legal interaction of sales activities or behaviors. The mere nominal recitation of a host computing device and network details do not take the claim out of the methods of organizing human activity grouping. Thus, the claims recite an abstract idea.
Under Step 2A, Prong Two of the Patent Subject Matter Eligibility analysis (see MPEP 2106.04), the judicial exception is not integrated into a practical application. In particular, the additional elements of claim 1 include network-initiated transactions; a host computing device; network details; a virtual product; a computing device; a data repository. The Examiner notes that the host computer of claim 1 is also in communication with an issuer and acquirer.
The additional elements of claim 14 include a system for use in associating a confirmed user (CU) to network-initiated transactions, the system comprising a host computing device configured to perform claim functions; network details; a computing device; a data repository. The Examiner notes that the host computer of claim 14 is also in communication with an issuer and acquirer.
The additional elements are recited at a high-level of generality (i.e., as a generic computer components performing a generic computer function receiving transaction data, storing transaction data, comparing past transaction data to current transaction data, and appending an authorization message with a flag that indicates to an issuer to approve or decline a transaction) such that it amounts to no more than generally linking the use of the judicial exception to a particular technological environment or field of use (e.g., a computer network).-see MPEP 2106.05(h).
Accordingly, the combination of the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
Under Step 2B of the Patent Subject Matter Eligibility analysis (see MPEP 2106.05), the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements in the claims amount to no more than generally linking the use of the judicial exception to a particular technological environment or field of use (see MPEP 2106.05(h)). Generally linking the use of the judicial exception to a particular technological environment or field of use using generic computer components cannot provide an inventive concept.
The claims are not patent eligible.
The dependent claims have been given the full two part analysis including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. Dependent claims 2-3, 5, 15-16, and 20 simply help to define the abstract idea. The additional limitations of the dependent claim(s) when considered individually and as an ordered combination do not amount to significantly more than the abstract idea.
Viewing the claim limitations as an ordered combination does not add anything further than looking at the claim limitations individually. When viewed either individually, or as an ordered combination, the additional limitations do not amount to a claim as a whole that is significantly more than the abstract idea. Accordingly, claims 1-3, 5, 14-16, and 20 are ineligible.
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.
Claims 1-3, 5, 14-16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20220122087 A1 (“Gosset”) in view of US 20230046068 A1 (“Prendergast”), and in further view of US 20220086153 A1 (“Dee”).
Regarding claim 1, Gosset discloses a computer-implemented method for use in associating a confirmed user (CU) to network-initiated transactions, the method comprising (see at least FIG. 7.):
receiving, by a host computing device, in connection with an authentication message associated with a transaction, network details for the transaction for a product between an account of a user and a first party (Receiving an authentication request message, the authentication request message includes authentication data. See at least [0149] and FIG. 7, step 702. Transaction is between a cardholder and merchant, see at least [0172]. The authentication data may also be divided by category, such as: transaction data (amount, currency, date, and time), device data (IP address, device info, and channel data), cardholder data (account number and shipping address), and merchant data (name, category, and country). See at least [0067]-[0068].),
the network details including at least a delivery data element specific to delivery of the product (Authentication data includes cardholder email address. See at least [0067]-[0068].) and
an identifier of a computing device of the user involved in the transaction (The authentication data may also be divided by category, such as: transaction data (amount, currency, date, and time), device data (IP address, device info, and channel data), cardholder data (account number and shipping address), and merchant data (name, category, and country). See at least [0067]-[0068].), and
the network details associated with a transaction identifier for the transaction (The authentication data may also be divided by category, such as: transaction data (amount, currency, date, and time), device data (IP address, device info, and channel data), cardholder data (account number and shipping address), and merchant data (name, category, and country). See at least [0067]-[0068].);
identifying, by the host computing device, from a data repository, multiple prior transactions (RBA engine may compare the data in the AReq message to one or more long term variables (“LTV”). The one or more LTV may include historical authentication data associated with the PAN at issue, historical authorization data associated with the PAN, other historical data associated with the PAN, etc. The LTV may include cardholder shipping address, cardholder billing address, cardholder email address, cardholder phone number, merchant name, merchant category, merchant location, and/or at least one environment-related variable (e.g., device details, browser details) including device ID, IP address, device channel, etc. Further, the LTV may be stored in a database accessible by RBA engine. See at least [0133]. See also [0075]. Storing authentication data for multiple past transactions, see at least [0139]-[0142]);
accessing, by the host computing device, from the data repository, network details for the multiple prior transactions (the payment card system includes a risk-based authentication (RBA) server. The RBA platform provides enhanced meta-data collection to capture information, including meta-data from the payment transactions processed by the payment card system. The RBA platform stores this meta-data to use to provide as historical data when performing an authentication process prior to performing an authorization process. See at least [0091]. Storing historical authentication data. See at least [0046] and [0133]. The LTV may include cardholder shipping address, cardholder billing address, cardholder email address, cardholder phone number, merchant name, merchant category, merchant location, and/or at least one environment-related variable (e.g., device details, browser details) including device ID, IP address, device channel, etc. Further, the LTV may be stored in a database accessible by RBA engine. See at least [0133]. See also [0075].);
comparing the network details for said transaction and the network details for the multiple prior transactions (RBA engine may compare the data in the AReq message to one or more long term variables (“LTV”). The one or more LTV may include historical authentication data associated with the PAN at issue, historical authorization data associated with the PAN, other historical data associated with the PAN, etc. See at least [0133]. See also [0075].);
receiving, by the host computing device, from an acquirer associated with the first party (This financial institution is usually called the “merchant bank,” the “acquiring bank,” or the “acquirer.” Merchant bank may authorize a third party to perform transaction processing on its behalf. See at least [0089]. The RBA platform may receive historical data from one or more of the acquirer bank See at least [0091].),
the host computing device being part of a processing network (See at least [0094] and FIG. 1.); and
based on the authorization request including the transaction identifier for the transaction a match between the network details for said transaction and the network details for the multiple prior transactions, appending a confirmed user flag to the authorization message for the transaction (Analyzes the data in the AReq message to generate RBA result data. For example, RBA engine may compare the data in the AReq message to one or more long term variables (“LTV”). See at least [0133]. the RBA result data generated by RBA engine 612 includes a risk score, a risk analysis, and at least one reason code. See at least [0135]. After RBA engine generates the RBA result data (including the reason codes), RBA-enabled directory server embeds the RBA result data into the AReq message to generate an enhanced AReq message. For example, in some embodiments, the RBA result data is appended to the AReq message as an extensible markup language (XML) extension of the AReq message. See at least [0145]. A payment processor could indicate if a particular device is associated with fraud, and flag that device for issuers in future transactions. The issuer may then reject transactions involving that device or prompt for additional authentication (e.g., through two-factor authentication). See at least [0127]. AReq data includes authentication data, see at least [0044] and the authentication data may also be divided by category, such as: transaction data (amount, currency, date, and time), device data (IP address, device info, and channel data), cardholder data (account number and shipping address), and merchant data (name, category, and country). See at least [0067]-[0068].); and
transmitting the authorization request with the flag to an issuer of the account of the user designated to fund the transaction whereby the issuer relies on the confirmed user flag in deciding to approve or decline the transaction for the product (Transmitting to the issuer, see at least [0155]. A payment processor could indicate if a particular device is associated with fraud, and flag that device for issuers in future transactions. The issuer may then reject transactions involving that device or prompt for additional authentication (e.g., through two-factor authentication). See at least [0127].).
While Gosset discloses a product, Gosset does not expressly disclose a virtual product. Furthermore, while Gosset discloses identifying prior transactions, Gosset does not expressly disclose identifying prior transactions between the account of the user and the first party. Furthermore, while Gosset discloses receiving from an acquirer, Gosset does not expressly disclose receiving an authorization message from an acquirer.
However, Prendergast discloses a virtual product (digital product, see at least [0046].);
prior transactions between the account of the user and the first party (past transactions between the merchant with the merchant, see at least [0031].).
From the teaching of Prendergast, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the product of Gosset to be a virtual product, as taught by Prendergast, and to modify the identified prior transactions of Gosset to be transactions between the account of the user and the first party, as taught by Prendergast, in order to decrease errors and delays of processing transactions, and in order to prevent transactions from failing, and in order to improve security (see Prendergast at least at [0002]-[0003]).
While Gosset discloses receiving from an acquirer, Gosset does not expressly disclose receiving an authorization message from an acquirer.
However, Dee discloses receiving an authorization message from an acquirer (The requestor processor may then receive the authorization response and authentication status data from the acquirer system. See at least [0029].).
From the teaching of Dee it would have been obvious to one having ordinary skill in the art before the effective filing date to modify Gosset to receive the authorization message from an acquirer, as taught by Dee in order to improve security and reduce friction in payment systems (see Dee at least at [0002] and [0018]-[0020]).
Regarding claim 2, the combination of Gosset, Prendergast, and Dee discloses the limitations of claim 1, as discussed above, and Gosset further discloses the identifier of the computing device includes an IP address of the computing device (The authentication data may also be divided by category, such as: transaction data (amount, currency, date, and time), device data (IP address, device info, and channel data), cardholder data (account number and shipping address), and merchant data (name, category, and country). See at least [0067]-[0068].);
wherein the delivery data element includes an email address (Authentication data includes cardholder email address. See at least [0067]-[0068].); and
wherein the network details further include a telephone number (the LTV may include cardholder shipping address, cardholder billing address, cardholder email address, cardholder phone number, merchant name, merchant category, merchant location, and/or at least one environment-related variable (e.g., device details, browser details) including device ID, IP address, device channel, etc. See at least [0046].).
Regarding claim 3, the combination of Gosset, Prendergast, and Dee discloses the limitations of claim 1, as discussed above, and Gosset further discloses a device location of the computing device of the user (the LTV may include cardholder shipping address, cardholder billing address, cardholder email address, cardholder phone number, merchant name, merchant category, merchant location, and/or at least one environment-related variable (e.g., device details, browser details) including device ID, IP address, device channel, etc. See at least [0046]. The Examiner interprets IP address as a device location.).
Regarding claim 5, the combination of Gosset, Prendergast, and Dee discloses the limitations of claim 1, as discussed above, and Gosset further discloses identifying multiple prior transactions includes identifying the multiple transactions as being outside a prior defined interval from a current date, such that the multiple prior transactions are older than the prior defined interval (Graphic visualization also includes a list of selectable time intervals for the link analysis. When the analyst “clicks” or otherwise selects a time interval from the list, the client application generates an API call to visualization engine. In response to the API call, visualization engine retrieves stored authentication data previously generated by RBA engine for transactions occurring within the selected time interval. Alternatively, graphic visualization does not include time interval list and/or visualization engine automatically applies a default time interval for retrieving the data. Visualization engine analyzes the retrieved data to identify “linked” transactions, i.e., transactions in the applicable time interval that have values in one or more anchor fields that match the values in the corresponding anchor fields for the selected transaction. See at least [0243]. See also [0250].).
Claim 14 has similar limitations found in claim 1 above, and therefore is rejected by the same art and rationale. And, Gosset further discloses store the network details, in associate with the transaction identifier, in a data repository (the payment card system includes a risk-based authentication (RBA) server. The RBA platform provides enhanced meta-data collection to capture information, including meta-data from the payment transactions processed by the payment card system. The RBA platform stores this meta-data to use to provide as historical data when performing an authentication process prior to performing an authorization process. See at least [0091]. Storing historical authentication data. See at least [0046] and [0133].); and
transmit the authorization message, with the confirmed user flag, to the issuer (Transmitting an ARes message approving the transaction to the issuer, see at least [0182] and FIG. 11B, step 1144. a payment processor could indicate if a particular device is associated with fraud, and flag that device for issuers in future transactions. The issuer may then reject transactions involving that device or prompt for additional authentication (e.g., through two-factor authentication). See at least [0127].).
Claim 15 has similar limitations found in claim 2 above, and therefore is rejected by the same art and rationale.
Regarding claim 16, the combination of Gosset, Prendergast, and Dee disclose the limitations of claim 14, as discussed above, and Gosset further discloses the network details for the transaction and the network details for the user include one or more of: an address, a name, and a device location of the user computing device (the LTV may include cardholder shipping address, cardholder billing address, cardholder email address, cardholder phone number, merchant name, merchant category, merchant location, and/or at least one environment-related variable (e.g., device details, browser details) including device ID, IP address, device channel, etc. See at least [0046]. ).
Regarding claim 20, the combination of Gosset, Prendergast, and Dee discloses the limitations of claim 1, as discussed above, and Gosset further discloses a value of the confirmed user flag is based on a number of the multiple prior transaction, which include network details that match the network details for said transaction (For example, RBA engine may detect that the device profile of the device used to initiate the transaction does not match the device profile used to initiate previous online transactions associated with the payment account in the historical data. See at least [0199]. Appending result of RBA to message, see at least [0145]. A payment processor could indicate if a particular device is associated with fraud, and flag that device for issuers in future transactions. The issuer may then reject transactions involving that device or prompt for additional authentication (e.g., through two-factor authentication). See at least [0127]. The Examiner interprets comparing the current transaction to one previous transaction as a number of the multiple prior transactions, the number being one transaction of the multiple prior transactions.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20210192532 A1 (“Thomson”) discloses a data optimization computer system for optimizing transaction authorization request messages directed to an authorizing party. The computer system includes a historical transaction database, a merchant database, and a data optimization computing device. The historical transaction database stores a plurality of historical transaction records. The merchant database stores a first merchant registered with the optimization computer system. The data optimization computing device may analyze at least a subset of the historical transaction records to generate a set of optimization rules. The set of optimization rules identifies optimal values for an optimized transaction authorization request message. The optimized transaction authorization request message may be associated with an improved likelihood of resulting in a positive request outcome.
US 11704666 B1 (“Barakat”) discloses authorizing transactions without a payment card present. One method includes receiving a habitual transaction request including a customer indicator and identifying characteristics of the habitual transaction request. The method further includes identifying, utilizing the customer indicator, habit information of a customer and authenticating the habitual transaction request based on the characteristics of the habitual transaction request conforming with the habit information. The method further includes, in response to authenticating the habitual transaction request, authorizing the habitual transaction request and receiving a non-habitual transaction request including the customer indicator. The method further includes determining that the customer is active, and the customer indicator is approved to conduct a non-habitual transaction and authorizing the non-habitual transaction request based on the determination and the customer indicator being approved to conduct the non-habitual transaction and transmitting a notification indicating the non-habitual transaction request was authorized.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RAVEN E YONO whose telephone number is (313)446-6606. The examiner can normally be reached Monday - Friday 8-5PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett M Sigmond can be reached on (303) 297-4411. 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.
/RAVEN E YONO/Primary Examiner, Art Unit 3694