DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, 19/341,426, was filed on 09/26/2025, and claims priority from U.S. Provisional Application 63/700,021, filed 09/27/2024.
The effective filing date is after the AIA date of March 16, 2013, and so the application is being examined under the “first inventor to file” provisions of the AIA .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Status of the Application
This Non-Final Office Action is in response to Applicant’s communication of 09/26/2025.
Claims 1-20 are pending, of which claims 1 and 10 are independent.
All pending claims have been examined on the merits.
Information Disclosure Statement
The Information Disclosure Statement (IDS) submitted on 04/06/2026 has been considered.
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-20 are rejected under 35 U.S.C. §101 because the claimed invention is directed to non-statutory subject matter. The claimed invention is directed to an abstract idea, without “significantly more”.
Based on the flowchart in MPEP § 2106, Step 1 of the Alice/Mayo analysis is: “Is the claim to a process, machine, manufacture or composition of matter?”
In regards to Step 1 of the Alice/Mayo analysis, independent claim 1 is an apparatus claim, and claim 11 is a method claim.
For the sake of compact prosecution, we continue with the Alice/Mayo “abstract idea” analysis.
Step 2A, prong 1 of the Alice/Mayo analysis is: “Does the claim recite a law of nature, a natural phenomenon (product of nature), or an abstract idea?”
In regards to Step 2A, prongs 1 and 2 of the Alice/Mayo analysis, the abstract idea elements recited in independent claim 1 are shown in italic font. (The “additional elements” and “extra solution steps” are shown in italic and underlined font):
1. A system comprising:
one or more processors; and
a non-transitory, computer-readable medium including instructions which, when executed by the one or more processors, cause the one or more processors to:
receive, via a user interface, merchant input indicating a target level of security and a target level of transaction authorization;
determine, based on the merchant input, a set of analytic services to be applied to transactions of a merchant providing the merchant input, the set of analytic services configured to generate data regarding a transaction;
in response to receiving transaction data of a transaction associated with the merchant, automatically making one or more API calls to the set of analytic services requesting data regarding the transaction;
determine, based on the data regarding the transaction from the set of analytic services and the merchant input, whether to transmit an authorization request;
in response to determining to transmit the authorization request, generate the authorization request based on the data regarding the transaction from the set of analytic services and the merchant input; and
transmit the authorization request to an issuer system.
More specifically, claims 1-20 recite an abstract idea: “Certain Methods of Organizing Human Activity", specifically “Commercial or Legal Interactions (Including Agreements in the form of Contracts; Legal Obligations; Advertising, Marketing, or Sales Activities or Behaviors; Business Relations)”, as discussed in MPEP §2106(a)(2) Parts (I) and (II), and in the 2019 Revised Patent Subject Matter Eligibility Guidance.
The “Commercial or Legal Interactions” elements include:
“determine, based on the merchant input, a set of analytic services to be applied to transactions of a merchant providing the merchant input, the set of analytic services configured to generate data regarding a transaction”.
“determine, based on the data regarding the transaction from the set of analytic services and the merchant input, whether to transmit an authorization request”.
“in response to determining to transmit the authorization request, generate the authorization request based on the data regarding the transaction from the set of analytic services and the merchant input”.
Moreover, claims 1-20 recite “Mathematical Concepts", specifically “Mathematical Relationships”, “Mathematical Formulas or Equations”, and “Mathematical Calculations”, as discussed in MPEP §2106.04(a)(2) Part (IV), and in the 2019 Revised Patent Subject Matter Eligibility Guidance.
The mathematic elements include:
“determine, based on the data regarding the transaction from the set of analytic services and the merchant input, whether to transmit an authorization request”.
The “additional elements” include: “one or more processors”, “a non-transitory, computer-readable medium including instructions”, and “a user interface”.
Moreover, “additional extra-solution elements” include:
“including instructions”,
“receive, via a user interface, merchant input indicating a target level of security and a target level of transaction authorization”,
“in response to receiving transaction data of a transaction associated with the merchant, automatically making one or more API calls to the set of analytic services requesting data regarding the transaction”, and
“transmit the authorization request to an issuer system”.
Step 2A, prong 2 of the Alice/Mayo analysis is “Does the claim recite additional elements that integrate elements that integrate the judicial exception into a practical application?”
In regards to Step 2A, prong 2 of the Alice/Mayo analysis, this abstract idea is not integrated into a practical application, because:
The claim is directed to an abstract idea with additional generic computer elements. The generically recited computer elements (“one or more processors”, “a non-transitory, computer-readable medium including instructions”, and “a user interface”) do not add a meaningful limitation to the abstract idea, because they amount to simply implementing the abstract idea on a computer. The claim amounts to adding the words "apply it" (or an equivalent) with the abstract idea, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea.
The extra-solution activities (“including instructions”, “receive, via a user interface, merchant input indicating a target level of security and a target level of transaction authorization”, “in response to receiving transaction data of a transaction associated with the merchant, automatically making one or more API calls to the set of analytic services requesting data regarding the transaction”) do not add a meaningful limitation to the method, as they are insignificant extra-solution activity;
The combination of the abstract idea with the additional elements (generically recited computer elements), and/or with the extra-solution activities, does not integrate the abstract idea into a practical application.
Step 2B of the Alice/Mayo analysis is: “Does the claim recite additional elements that amount to significantly more than the judicial exception?”
In regards to Step 2B of the Alice/Mayo analysis, the claims do not include additional elements that are sufficient to amount to significantly more than the abstract idea, because:
When considering the elements "alone and in combination" (“one or more processors”, “a non-transitory, computer-readable medium”, and “a user interface”), they do not add significantly more (also known as an "inventive concept") to the exception, because they amount to simply implementing the abstract idea on a computer. Instead, they merely add the words "apply it" (or an equivalent) with the abstract idea, or mere instructions to implement an abstract idea on a computer, or merely use a computer as a tool to perform an abstract idea.
In regards to the extra solution activities (“including instructions”, “receiving”, “transmitting”, and “making one or more API calls”), these are recognized as such by the court decisions listed in MPEP § 2106.05(d).
More specifically, in regards to the “storing” step (“including instructions”), see the court cases Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015) (storing and retrieving information in memory); and OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1092-93 (Fed. Cir. 2015) (storing and retrieving information in memory).
More specifically, in regards to the “receiving”, “transmitting”, and “making one or more API calls” steps, see the court cases OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network) and (presenting offers and gathering statistics), OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93; 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).
Moreover, in regards to “apply it”, according to MPEP § 2106.05(f)(2):
Use of a computer or other machinery 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 an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit). Similarly, "claiming the improved speed or efficiency inherent with applying the abstract idea on a computer" does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1367, 115 USPQ2d 1636, 1639 (Fed. Cir. 2015).
In contrast, a claim that purports to improve computer capabilities or to improve an existing technology may integrate a judicial exception into a practical application or provide significantly more. McRO, Inc. v. Bandai Namco Games Am. Inc., 837 F.3d 1299, 1314-15, 120 USPQ2d 1091, 1101-02 (Fed. Cir. 2016); Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1335-36, 118 USPQ2d 1684, 1688-89 (Fed. Cir. 2016). See MPEP §§ 2106.04(d)(1) and 2106.05(a) for a discussion of improvements to the functioning of a computer or to another technology or technical field.
The Examiner holds that the independent claims “use a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data)” or “simply add a general purpose computer or computer components after the fact to an abstract idea”.
Independent claim 11 is rejected on the same grounds as independent claim 1.
All dependent claims are also rejected, because they merely further define the abstract idea.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 3-8, 10-11, 13-18, and 20 are rejected under 35 U.S.C. §102 (a)(2) as being anticipated by US 2025/0119428 A1 to Dee (“Dee”. Eff. Filed on Jan. 15, 2020).
In regards to claim 1,
1. A system comprising:
one or more processors; and
a non-transitory, computer-readable medium including instructions which, when executed by the one or more processors, cause the one or more processors to:
(See Dee, para. [0006]: “One embodiment provides a system for authenticating an electronic transaction using a hosted data service, comprising: a data storage device storing instructions for authenticating the electronic transaction with the hosted data service; and a processor configured to execute the instructions to perform a method comprising …”)
receive, via a user interface, merchant input indicating a target level of security and a target level of transaction authorization;
(See Dee, claim 3: “The computer-implemented method of claim 1, wherein determining the requirement for the security assessment for the payment request, further comprises: applying, by the one or more processors, transaction-specific criteria to determine whether the security assessment is required for the payment request, wherein the transaction-specific criteria includes one or more of risk level, compliance with exemption rules, merchant preferences, or transaction specification under a security protocol.”)
The Examiner interprets that “risk level” reads upon the claimed “target level of security”.
(See Dee, para. [0003]: “Under 3DS2, enhanced authentication methods (e.g., multi-factor authentication, risk-based authentication, and frictionless authentication) may be performed by using additional consumer transaction data obtained during the checkout process. In order to provide the additional consumer transaction data in accordance with 3DS2, merchants who host their own payment form, whether or not they already use a third party 3DS requestor to initiate the 3DS protocol flow, may be required to modify their technical integration.”)
The Examiner interprets that “enhanced authentication methods” that “may be performed” reads upon the claimed “target level of transaction authorization”.
(See Dee, para. [0037]: “Referring back to FIG. 4 , at step 404, HAS 140 may transmit the collected consumer transaction data to the issuer system 170. At step 406, HAS 140 may transmit an authentication request (e.g., a 3DS2 authentication request) to the issuer system 170, via the directory system 160, to determine whether the consumer authentication challenge is required. At step 408, the directory system 130 may also communicate with the issuer system 170 to perform a transaction risk analysis based on the collected consumer transaction data to confirm whether any exemptions may be applied. If the transaction risk analysis determines that no authentication is required for the payment transaction, the electronic payment transaction process may proceed to the payment transaction authorization stage. Otherwise, HAS 140 may perform the new authentication security protocol described in the security assessment phase 218 of FIG. 2 to determine whether the consumer authentication challenge is required.”)
determine, based on the merchant input, a set of analytic services to be applied to transactions of a merchant providing the merchant input, the set of analytic services configured to generate data regarding a transaction;
(See Dee, para. [0019]: “The demand for secure electronic payment transactions will continue to rise, and the security requirement standard for electronic payment transactions will continue to strengthen as well. In order to meet the continuing demand for changes in security requirements (e.g., SCA) for preventing data security fraud (e.g., CNP and e-Commerce fraud), merchants may be required to continually re-integrate their systems in accordance with new versions of an existing specification(s) or protocol(s) (specification and protocol may be used interchangeably hereinafter). However, the merchants may face various problems with re-integrating their systems according to new versions of the security protocol (e.g., 3DS2). For example, the merchants may be required to provide new, additional data (e.g., browser user agent, browser time zone, shipping details, consumer Internet Protocol (IP) addresses, etc.) that may not have been required in the previous versions of security protocols.”)
The Examiner interprets that “re-integrating their systems according to new versions of the security protocol (e.g., 3DS2)” in combination with “For example, the merchants may be required to provide new, additional data” reads upon “a set of analytic services to be applied to transactions of a merchant providing the merchant input”.
in response to receiving transaction data of a transaction associated with the merchant, automatically making one or more API calls to the set of analytic services requesting data regarding the transaction;
(See Dee, para. [0040]: “The requestor processor 150 may then receive an authorization result and the authentication status data of the new security protocol from the acquirer system 180 and may respond to the second message received from the merchant system 120. In one embodiment, to maintain backward compatibility, the new security protocol authentication status values (e.g., 3DS2 values) may be mapped to the previous security protocol status values (e.g., 3DS1 values), and all of the new security protocol data can be provided via a portal or query application programming interfaces (APIs).”)
determine, based on the data regarding the transaction from the set of analytic services and the merchant input, whether to transmit an authorization request;
(See Dee, para. [0028]: “In one embodiment, once the merchant system 120 sends a payment authorization request message to the requestor processor 150 according to an existing version of the security protocol, the requestor processor 150 may communicate with the issuer system 170 to determine whether a consumer authentication is required. The requestor processor 150 may or may not communicate with the issuer system 170 or the directory system 160 to determine whether the consumer authentication is required. If the requestor processor 150 determines that the consumer authentication is not required, the requestor processor 150 may communicate with the acquirer system 180 and the issuer system 170 for payment authorization and return the result the authorization request to the merchant system 120 as a payment authorization response message.”)
(See Dee, para. [0035]: “FIGS. 3 and 4 are schematic block diagrams for exemplary embodiments of the electronic payment system 100 performing an electronic payment transaction process utilizing HAS 140. In the description below, reference will be made to both FIG. 3 and FIG. 4 . According to an embodiment shown in FIG. 3, when the consumer 105 makes a purchase, the browser 110 may send a payment submission to the merchant system 120 at step 302. At step 304, the merchant system 120 may send a first message (e.g., a payment authorization request message) to the requestor processor 150. The requestor processor 150 may then determine whether a security assessment (or authentication) may be necessary (e.g., whether the payment is subject to a new specification, whether a blanket exemption applies, or whether the payment is considered low risk). For instance, as shown in FIG. 4, the requestor processor 150 may determine whether the authentication risk assessment phase 218 may be necessary. The requestor processor 150 may also determine whether a consumer challenge request is required based on a risk assessment determination. If the requestor processor 150 determines that a security assessment (or authentication) is not required (e.g., based on a blanket exemption or a predetermined merchant preference), the requestor processor 150 may skip the security assessment phase 218 shown in FIG. 2 and proceed to authorize the payment transaction with the acquirer system 180 at step 416.”)
in response to determining to transmit the authorization request, generate the authorization request based on the data regarding the transaction from the set of analytic services and the merchant input; and
transmit the authorization request to an issuer system.
(See Dee, para. [0033]: “During the authentication risk assessment phase 218, the new security protocol may be initiated by HAS 140, and in response, the security server 160A may send an authentication request to the issuer system 170 by way of a directory server 160B, to receive an authentication response. Further, during the authentication challenge execution phase 220, the issuer system 170 may receive a challenge request and may request the consumer 105 to provide consumer credentials. The issuer system 170 may then transmit a result request to the security server 160A by way of the directory server 160B, and receive a result response from the security server 160A. Thereafter, during the payment authorization phase 222, the issuer system 170 may provide a challenge response to HAS 10 and may complete the payment transaction. In one embodiment, the authentication challenge execution phase 220 may be optional. That is, if the issuer system 170 determines that the consumer authentication challenge is not required, the authentication challenge execution phases 220 may not occur.”)
In regards to claim 3,
3. The system of claim 1, wherein the target level of security includes a first target level of security for a first type of transaction and a second target level of security for a second type of transaction.
(See Dee, para. [0003]: “Electronic transaction technologies have advanced to permit merchants and consumers to conveniently transact business over the Internet. However, the proliferation of online payment transactions has made sensitive and secure electronic data to become potentially vulnerable to data breaches (e.g., card-not-present (CNP) fraud). In a drive to reduce such data breaches, legislative governmental entities and payment schemes have mandated a new authentication requirement (e.g., Strong Customer Authentication (SCA)). Consequently, card schemes have adopted EMVCo's new specification (e.g., Three-Domain Secure 2 (3DS2)) in order to meet the new authentication requirement. The new 3DS2 specification builds on an earlier version of Three-Domain Secure specification (3DS1). 3DS1 requires shoppers to enter payment credentials (e.g., a password or a passcode) during electronic payment transactions, resulting in friction during the checkout process. Under 3DS2, enhanced authentication methods (e.g., multi-factor authentication, risk-based authentication, and frictionless authentication) may be performed by using additional consumer transaction data obtained during the checkout process. In order to provide the additional consumer transaction data in accordance with 3DS2, merchants who host their own payment form, whether or not they already use a third party 3DS requestor to initiate the 3DS protocol flow, may be required to modify their technical integration.”)
The Examiner interprets that according to Dee’s disclosure, credit card transactions undergo “(e.g., Three-Domain Secure 2 (3DS2))”, which has “enhanced authentication methods”.
In regards to claim 4,
4. The system of claim 1, wherein the instructions further cause the one or more processors to:
receive additional data associated with the merchant; and
determine the set of analytic services based on the merchant input and the additional data.
(See Dee, para. [0003]: “Electronic transaction technologies have advanced to permit merchants and consumers to conveniently transact business over the Internet. However, the proliferation of online payment transactions has made sensitive and secure electronic data to become potentially vulnerable to data breaches (e.g., card-not-present (CNP) fraud). In a drive to reduce such data breaches, legislative governmental entities and payment schemes have mandated a new authentication requirement (e.g., Strong Customer Authentication (SCA)). Consequently, card schemes have adopted EMVCo's new specification (e.g., Three-Domain Secure 2 (3DS2)) in order to meet the new authentication requirement. The new 3DS2 specification builds on an earlier version of Three-Domain Secure specification (3DS1). 3DS1 requires shoppers to enter payment credentials (e.g., a password or a passcode) during electronic payment transactions, resulting in friction during the checkout process. Under 3DS2, enhanced authentication methods (e.g., multi-factor authentication, risk-based authentication, and frictionless authentication) may be performed by using additional consumer transaction data obtained during the checkout process. In order to provide the additional consumer transaction data in accordance with 3DS2, merchants who host their own payment form, whether or not they already use a third party 3DS requestor to initiate the 3DS protocol flow, may be required to modify their technical integration.”)
Examiner notes that Dee teaches that “Under 3DS2, enhanced authentication methods (e.g., multi-factor authentication, risk-based authentication, and frictionless authentication) may be performed by using additional consumer transaction data obtained during the checkout process”.
In regards to claim 5,
5. The system of claim 4, wherein the additional data includes one or more of historical transaction data of the merchant and historical fraud data of the merchant.
(See Dee, para. [0031]: “In another embodiment, a new security standard (e.g., SCA) may require the merchant system 120 to follow a new security protocol (e.g., 3DS2) for processing the consumer payment transaction. For example, the new security protocol may require the merchant system 120 to provide additional consumer payment transaction data in order to proceed with the consumer payment transaction process. The additional consumer payment transaction data may be browser user agent information, a browser time zone, a transaction history, and/or a consumer device identifier (ID).”)
(See Dee, para. [0043]: “At step 506, the requestor system 130 may receive, from the first data system, a first electronic form generated based on the HAS URL, the first electronic form comprising a first data system return URL and the dummy authentication request. The first electronic form may be, for example, an HTML form or any other markup language form. At step 508, upon receiving the first electronic form, the requestor system 130 may collect user transaction data from the first data system for a transaction risk analysis by a second data system to confirm the authentication is not required. The second data system may be the issuer system 170. The user transaction data may comprise at least one of a user transaction history, a browser user agent, and a browser time zone. The requestor system 130 may run JavaScript in the browser 110 to collect the user transaction data. At step 510, the requestor system 130 may communicate with the second data system to determine whether a user authentication challenge is required based on the transaction risk analysis.”)
In regards to claim 6,
6. The system of claim 4, wherein the instructions further cause the one or more processors to generate the authorization request based on the additional data associated with the merchant.
(See Dee, para. [0031]: “In another embodiment, a new security standard (e.g., SCA) may require the merchant system 120 to follow a new security protocol (e.g., 3DS2) for processing the consumer payment transaction. For example, the new security protocol may require the merchant system 120 to provide additional consumer payment transaction data in order to proceed with the consumer payment transaction process. The additional consumer payment transaction data may be browser user agent information, a browser time zone, a transaction history, and/or a consumer device identifier (ID).”)
(See Dee, para. [0043]: “At step 506, the requestor system 130 may receive, from the first data system, a first electronic form generated based on the HAS URL, the first electronic form comprising a first data system return URL and the dummy authentication request. The first electronic form may be, for example, an HTML form or any other markup language form. At step 508, upon receiving the first electronic form, the requestor system 130 may collect user transaction data from the first data system for a transaction risk analysis by a second data system to confirm the authentication is not required. The second data system may be the issuer system 170. The user transaction data may comprise at least one of a user transaction history, a browser user agent, and a browser time zone. The requestor system 130 may run JavaScript in the browser 110 to collect the user transaction data. At step 510, the requestor system 130 may communicate with the second data system to determine whether a user authentication challenge is required based on the transaction risk analysis.”)
In regards to claim 7,
7. The system of claim 1, wherein the instructions further cause the one or more processors to:
in response to receiving the transaction data, determine one or more characteristics of the transaction; and
based on the one or more characteristics of the transaction, select a subset of the set of analytic services to query using the one or more API calls.
(See Dee, para. [0040]: “The requestor processor 150 may then receive an authorization result and the authentication status data of the new security protocol from the acquirer system 180 and may respond to the second message received from the merchant system 120. In one embodiment, to maintain backward compatibility, the new security protocol authentication status values (e.g., 3DS2 values) may be mapped to the previous security protocol status values (e.g., 3DS1 values), and all of the new security protocol data can be provided via a portal or query application programming interfaces (APIs).”)
In regards to claim 8,
8. The system of claim 7, wherein the one or more characteristics include one or more of a time of day, a payment medium, the issuer system, a merchant location, and an identity of a customer associated with the transaction.
(See Dee, para. [0031]: “In another embodiment, a new security standard (e.g., SCA) may require the merchant system 120 to follow a new security protocol (e.g., 3DS2) for processing the consumer payment transaction. For example, the new security protocol may require the merchant system 120 to provide additional consumer payment transaction data in order to proceed with the consumer payment transaction process. The additional consumer payment transaction data may be browser user agent information, a browser time zone, a transaction history, and/or a consumer device identifier (ID).”)
In regards to claim 10,
10. The system of claim 1, wherein the instructions further cause the one or more processors to:
determine one or more characteristics of the issuer system; and
generate the authorization request based on the data regarding the transaction from the set of analytic services, the merchant input, and the one or more characteristics of the issuer system.
(See Dee, para. [0028]: “In one embodiment, once the merchant system 120 sends a payment authorization request message to the requestor processor 150 according to an existing version of the security protocol, the requestor processor 150 may communicate with the issuer system 170 to determine whether a consumer authentication is required. The requestor processor 150 may or may not communicate with the issuer system 170 or the directory system 160 to determine whether the consumer authentication is required. If the requestor processor 150 determines that the consumer authentication is not required, the requestor processor 150 may communicate with the acquirer system 180 and the issuer system 170 for payment authorization and return the result the authorization request to the merchant system 120 as a payment authorization response message.
In regards to claim 11, it is rejected on the same grounds as claim 1.
In regards to claim 13, it is rejected on the same grounds as claim 3.
In regards to claim 14, it is rejected on the same grounds as claim 4.
In regards to claim 15, it is rejected on the same grounds as claim 5.
In regards to claim 16, it is rejected on the same grounds as claim 6.
In regards to claim 17, it is rejected on the same grounds as claim 7.
In regards to claim 18, it is rejected on the same grounds as claim 8.
In regards to claim 20, it is rejected on the same grounds as claim 10.
Claim Rejections - 35 USC § 103
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
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 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over US 2025/0119428 A1 to Dee. (“Dee”. Eff. Filed on Jan. 15, 2020) in view of US 2022/0224685 A1 to Dhindsa et al. (“Dhindsa”. Filed on Jan. 11, 2021. Published on Jul. 14, 2022).
In regards to claim 9,
9. The system of claim 1, wherein the instructions further cause the one or more processors to assign weights to the set of analytic services, wherein the data regarding the transaction reflects responses from the set of analytic services, weighted according to their assigned weights.
However, under a conservative interpretation of Dee, it could be argued that Dee does not explicitly teach the italicized portions below:
[0048]: “The authentication system may authenticate User A based on the context-based authentication score and/or the media-based authentication score. For example, the authentication system may use a weighted average of the context-based authentication score and/or the media-based authentication score. In such an example, different weights may be assigned to the context-based authentication score and/or the media-based authentication score according to settings of the user account, the security level, and/or one or more of the parameters of the operation. Additionally, or alternatively, the authentication system may compare an authentication score (e.g., the context-based authentication score, the media-based authentication score, and/or a weighted average of the context-based authentication score and the media-based authentication score) to one or more authentication threshold scores associated with validating an authentication response. For example, an authentication score that satisfies the one or more authentication threshold scores may indicate that the contextual description was likely provided by an authenticated user of the user account (e.g., based on a context-based authentication score indicating that the described characteristic satisfies a threshold score that is indicative of an authorized user accurately describing a context of requesting the performance of the operation). Additionally, or alternatively, an authentication score that satisfies the one or more authentication threshold scores may indicate that media content was associated with or included a feature of an authorized user of the user account. Accordingly, the authentication system may utilize one or more authentication scores and/or one or more authentication threshold scores to authenticate User A.”)
It would have been obvious to a person having ordinary skill in the art (PHOSITA), before the effective filing date of the claimed invention, to include in the “Systems and methods for hosted authentication service”, as taught by Dee above, with “Context-Based Authentication of a User”, as further taught by Dhindsa above, because both references are in the same art of user identification, and Dhindsa .
In regards to claim 19, it is rejected on the same grounds as claim 9.
Conclusion
Applicants are invited to contact the Office to schedule an in-person interview to discuss and resolve the issues set forth in this Office Action. Although an interview is not required, the Office believes that an interview can be of use to resolve any issues related to a patent application in an efficient and prompt manner.
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.
Any inquiry concerning this communication or earlier communications should be directed to Examiner Ayal Sharon, whose telephone number is (571) 272-5614, and fax number is (571) 273-1794. The Examiner can normally be reached from Monday to Friday between 9 AM and 6 PM. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, SPE Christine Behncke can be reached at (571) 272-8103 or at christine.behncke@uspto.gov. The fax 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.
Sincerely,
/Ayal I. Sharon/
Examiner, Art Unit 3695
June 19, 2026
Prosecution Insights