Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
2. The Amendment filed May 15, 2026 has been entered. Claims 1-26 are pending and are rejected for the reasons set forth below.
Claim Rejections - 35 USC § 101
3. 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.
4. Claims 1-26 are rejected under 35 U.S.C. §101 because the claimed invention recites and is directed to a judicial exception to patentability (i.e., a law of nature, a natural phenomenon, or an abstract idea) and does not include an inventive concept that is “significantly more” than the judicial exception under the January 2019 and October 2019 patentable subject matter eligibility guidance (2019 PEG) analysis which follows.
Step 1
5. Under the 2019 PEG step 1 analysis, it must first be determined whether the claims are directed to one of the four statutory categories of invention (i.e., process, machine, manufacture, or composition of matter). Applying step 1 of the analysis for patentable subject matter to the claims, it is determined that the claims are directed to the statutory category of a process (claims 1-13) and a machine (claims 14-26). Therefore, we proceed to step 2A, Prong 1.
Step 2A, Prong 1
6. Under the 2019 PEG step 2A, Prong 1 analysis, it must be determined whether the claims recite an abstract idea that falls within one or more designated categories of patent ineligible subject matter (i.e., organizing human activity, mathematical concepts, and mental processes) that amount to a judicial exception to patentability.
Claim 1 recites the abstract idea of:
A method comprising: [[at a payment platform device comprising one or more processors]]:
receiving a provider search request from [[the user device via the payment portal interface]], wherein the provider search request comprises at least one marketplace criterion;
in response to receiving the provider search request, determining, based on [[a partner matching algorithm]] and the at least one marketplace criterion, partner data associated with a plurality of partners; and
updating the partner data based on at least one partner filtering criterion associated with a user of [[the user device]] and on live traffic data on partner capabilities from at least one of current and potential customers, the live traffic data including at least one of a transaction volume, an acceptance rate and a response time, and
rearranging an order of the plurality of partners based on the live traffic data; and
at [[the user device]]: sending the provider search request to [[the payment platform device]].
Here, the recited abstract idea falls within one or more of the three enumerated 2019 PEG categories of patent ineligible subject matter, to wit: certain methods of organizing human activity, which includes fundamental economic practices or principles and/or commercial interactions (e.g., matching users with travel providers and payment providers).
Step 2A, Prong 2
7. Under the 2019 PEG step 2A, Prong 2 analysis, the identified abstract idea to which claim 1 is directed does not include limitations or additional elements that integrate the abstract idea into a practical application.
Besides reciting the abstract idea, the limitations of claim 1 also recite generic computer components (e.g., a payment platform device comprising one or more processors, a payment portal interface, a user device, a payment marketplace module, and a partner matching algorithm). In particular, the recited features of the abstract idea are merely being applied on a computer or computing device or via software programming that is simply being used as a tool (“apply it”) to implement the abstract idea. (See e.g., MPEP §2106.05(f)). Therefore, these additional elements are recited at a high level of generality such that they amount to no more than mere instructions to apply the exception using generic computer components. In other words, the additional elements are simply used as tools to perform the abstract idea.
Claim 1 also recites the following limitation:
providing, via a payment portal interface, access for a user device to a payment marketplace module;
providing the updated partner data for display at the user device via the payment portal interface; and
displaying the rearranged order of the plurality of partners based on the live traffic data in association with links for the user to request a subscription to the displayed plurality of partners.
These limitations simply state that a payment portal interface provides the user access to (i.e., displays) a payment marketplace module, the partner data is displayed at the user device, and that the rearranged order of the plurality of partners is displayed at the user device. However, the claim does not provide significant technical detail regarding how the payment marketplace module and/or the partner data is presented via the payment portal interface, or how the user interacts with the payment portal interface. Therefore, these limitations amount to no more than merely outputting/displaying data, which is a form of insignificant extra-solution activity (See MPEP 2016.05(g): OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)).
Thus, claim 1 does not include any limitations or additional elements that integrate the abstract idea into a practical application. As a result, claim 1 is directed to an abstract idea.
Step 2B
8. Under the 2019 PEG step 2B analysis, the additional elements of claim 1 are evaluated to determine whether they amount to something “significantly more” than the recited abstract idea. (i.e., an innovative concept). Here, the recited additional elements (e.g., a payment platform device comprising one or more processors, a payment portal interface, a user device, a payment marketplace module, and a partner matching algorithm), do not amount to an innovative concept since, as stated above in the Step 2A, Prong 2 analysis, the claims are simply using the additional elements as a tool to carry out the abstract idea (i.e., “apply it”) on a computer or computing device and/or via software programming (See e.g., MPEP §2106.05(f)). The additional elements are specified at a high level of generality such that they are being used in the claims to simply implement the abstract idea and are not themselves being technologically improved (See e.g., MPEP 2106.05(I)(A)); (See also applicant’s Specification at least Paragraphs 100-11).
Additionally, the following limitation identified above as insignificant extra-solution activity (merely outputting/displaying data) has been reevaluated under Step 2B:
providing, via a payment portal interface, access for a user device to a payment marketplace module;
providing the updated partner data for display at the user device via the payment portal interface; and
displaying the rearranged order of the plurality of partners based on the live traffic data in association with links for the user to request a subscription to the displayed plurality of partners.
As stated in MPEP 2106.05(d), a factual determination is required to support a conclusion that an additional element (or combination of additional elements) is well-understood, routine, conventional activity (Berkheimer v. HP, Inc., 881 F.3d 1360, 1368 (Fed. Cir. 2018)). In view of this requirement set forth by Berkheimer, this limitation does not integrate the abstract idea into a practical application, or amount to significantly more than the abstract idea, because the courts have found the concept of merely outputting/displaying data to be well-understood, routine, and conventional activity (See MPEP 2106.05(d): OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)).
Thus, claim 1 does not recite any additional elements that amount to “significantly more” than the abstract idea.
Additional Independent Claims
9. Independent claim 14 is similarly rejected under 35 U.S.C. 101 for the reasons described below:
Claim 14 recites limitations that are substantially similar to those recited in claim 1. However, the primary difference between claims 14 and 1 is that claim 14 is drafted as a machine rather than as a process. Similarly, as described above regarding claim 1, claim 14 recites generic computer components (e.g., a payment platform device comprising a non-transitory computer-readable storage medium and one or more processors coupled to the non-transitory computer-readable storage medium, a payment portal interface, a user device, a payment marketplace module, and a partner matching algorithm) that are simply being used as a tool (“apply it”) to implement the abstract idea. Therefore, since the same analysis should be used for claims 1 and 14, claim 14 is not patent eligible (See Alice Corp. Pty. Ltd. V. CLS Bank Int’l, 134 S. Ct. 2347, 2354 (2014)).
Dependent Claims
10. Dependent claims 2-13 and 15-26 are also rejected under 35 U.S.C. 101 for the reasons described below:
Claims 2 and 15 simply provide further definition to the “marketplace criterion” recited in claims 1 and 14. Simply stating that the marketplace criterion comprises markets, currencies, products, product capabilities, live traffic, or a combination thereof does not provide an indication of an improvement to any technology or technological field. Rather, this merely defines the type of criteria used to determine the partner data.
Claims 3 and 16 simply refine the abstract idea because they recite a process step (e.g., determining markets, currencies, products, product capabilities, live traffic, or a combination thereof, associated with the plurality of partners) that falls under the category of organizing human activity, as described above regarding claim 1.
Claims 4 and 17 simply provide further definition to the “partner filtering criterion” recited in claims 1 and 14. Simply stating that the partner filtering criterion comprises contract agreement data that includes a location, a region, a type of product, or a combination thereof does not provide an indication of an improvement to any technology or technological field. Rather, this merely defines the type of criteria used to determine the partner data.
Claims 5, 6, 18, and 19 simply state that the system rearranges the order of the plurality of partners, and displays the rearranged order of partners via the user device. However, the claims do not provide significant technical detail regarding how the partners are rearranged, and/or how the rearranged order is displayed via the user device. Therefore, these limitations amount to no more than merely outputting/displaying data, which is a form of insignificant extra-solution activity (See MPEP 2016.05(g): OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)). In view of the requirement set forth by Berkheimer, these limitations do not integrate the abstract idea into a practical application, or amount to significantly more than the abstract idea, because the courts have found the concept of merely outputting/displaying data to be well-understood, routine, and conventional activity (See MPEP 2106.05(d): OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)).
Claims 7, 8, 20, and 21 simply refine the abstract idea because they recite process steps (e.g., selecting a live traffic option, and updating the partner databased on the selection of the live traffic option) that falls under the category of organizing human activity, as described above regarding claim 1. The claims do not provide significant technical detail regarding how the live traffic option is selected by the user and/or how the partner data is updated based on the live traffic data.
Claims 9 and 22 simply refine the abstract idea because they recite process steps (e.g., receiving an update request from the user to modify one or more portal elements associated with the user, and updating the one or more portal elements based on the update request) that fall under the category of organizing human activity, as described above regarding claim 1. The claims do not provide significant technical detail regarding how the policy elements are updated and/or how the request to update the policy elements is received.
Claims 10 and 23 simply provide further definition to the “portal elements” recited in claims 9 and 22. Simply stating that the portal elements are based on profile information, push notification options, subscriber features, ranking score structures, live traffic transaction options, or a combination thereof does not provide an indication of an improvement to any technology or technological field. Rather, this merely defines the type of information that is updated.
Claims 11, 12, 24, and 25 simply state that the payment portal interface comprises an API, and that the API is based on a representational state transfer protocol. However, such limitations do not provide any indication of a technical improvement to API technology, or any other technology or technological field. Therefore, such limitations amount to no more than merely applying a generic API to implement the abstract idea on a computer.
Claims 13 and 26 simply provide further definition to the “provider search request” recited in claims 1 and 14. Simply stating that the provider search request is received from a travel provider server does not provide an indication of an improvement to any technology or technological field. Rather, this amounts to no more than merely applying a generic computer-related device (e.g., a travel provider server) to implement the abstract idea on a computer.
Thus, the dependent claims do not add any additional element or subject matter that provides a technological improvement (i.e., an integration into a practical application) that results in the claims being directed to patent eligible subject matter or include an element or feature that is significantly more than the recited abstract idea (i.e., a technological inventive concept under Step 2B).
Claim Rejections - 35 USC § 103
11. 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.
12. Claims 1-10 and 14-23 are rejected under 35 U.S.C. 103 as being unpatentable over Allen (U.S. Pre-Grant Publication No. 20230316355) in view of Weyman (U.S. Pre-Grant Publication No. 20190114622) and Chandran (U.S. Patent No. 8799148).
Claim 1
Regarding Claim 1, Allen teaches:
A method comprising: at a payment platform device comprising one or more processors: providing, via a payment portal interface, access for a user device to a payment marketplace module (See at least Paragraph 42-45: Describes a system for matching leads [i.e., merchants] with partners [i.e., payment provider partners]. The system may display to the user a graphical user interface comprising a dashboard [i.e., a payment portal interface] for enabling the user to evaluate partners and match partners with one or more new leads. The interface may comprise a lead pairing tool [i.e., a payment marketplace module; See Paragraph 59 and Figure 10]. The system comprises a processor [See Paragraphs 35-41]);
receiving a provider search request from the user device via the payment portal interface, wherein the provider search request comprises at least one marketplace criterion (See at least Paragraphs 59-61: The user may fill out a questionnaire comprising information about the lead that is used to determine potential partners [e.g., marketplace criterion]. The user may select a "pair now" submission button in order to begin the pairing process [Also see Paragraphs 75-77: The questionnaire may be submitted in order to narrow the plurality of potential partners]. In other words, selecting the submission button corresponds to submitting a provider search request);
in response to receiving the provider search request, determining, based on a partner matching algorithm and the at least one marketplace criterion, partner data associated with a plurality of partners (See at least Paragraph 62: A matching engine may utilize an algorithm [i.e., a partner matching algorithm] to narrow down a list of eligible potential partners for pairing with the lead based on the answers provided via the questionnaire. In other words, receiving the list of eligible partners corresponds to receiving the partner data);
updating the partner data based on at least one partner filtering criterion associated with a user of the user device (See at least Paragraphs 62-64: The list of eligible partners may be sorted [i.e., filtered] based on various criteria. For example, the potential partners may be sorted based on a relative physical distance between the new lead and the potential partners [i.e., filtering criteria]); and
providing the updated partner data for display at the user device via the payment portal interface (See at least Paragraph 79: The narrowed plurality of partners may be displayed on the graphical user interface via the lead pairing tool); and
at the user device: sending the provider search request to the payment platform device (See at least Paragraphs 59-61: The user may fill out a questionnaire comprising information about the lead that is used to determine potential partners [e.g., marketplace criterion]. The user may select a "pair now" submission button in order to begin the pairing process [Also see Paragraphs 75-77: The questionnaire may be submitted in order to narrow the plurality of potential partners]. In other words, selecting the submission button corresponds to submitting a provider search request).
Regarding Claim 1, Allen does not explicitly teach, but Weyman, however, does teach:
and on live traffic data on partner capabilities from at least one of current and potential customers, the live traffic data including at least one of a transaction volume, an acceptance rate and a response time (See at least Paragraph 31: Describes a system for real-time online ranking of credit cards from a plurality of card providers [i.e., partners]. The ranking may be determined based on a plurality of information associated with the cards and card providers [i.e., live traffic data]. For example, one factor may be acceptance rate of the provider [i.e., an acceptance rate; See Paragraph 42]. The acceptance rate may correspond to the likelihood that the payment provider will be accepted at a merchant. The cards may be evaluated in "real time" [i.e., the card data is "live"; See Paragraphs 20 and 21]), and
rearranging an order of the plurality of partners based on the live traffic data (See at least Paragraph 23: The updated ranked list of credit cards is returned to the user device for display in real-time); and
displaying the rearranged order of the plurality of partners based on the live traffic data [[in association with links for the user to request a subscription to the displayed plurality of partners]] (See at least Paragraph 23: The updated ranked list of credit cards is returned to the user device for display in real-time. Examiner's note: The combination of Allen and Weyman does not explicitly teach that subscription "links" associated with the plurality of partners are displayed with the ranked list. However, this limitation is disclosed by Chandran as described below).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Allen and Weyman in order to provide a system that is able to evaluate payment providers [i.e., credit cards] holistically and in real time (Weyman: Paragraph 3). Utilizing real time data ensures that the user is provided with the most accurate recommendations possible.
Regarding Claim 1, the combination of Allen and Weyman does not explicitly teach, but Chandran, however, does teach:
displaying the rearranged order of the plurality of partners based on the live traffic data in association with links for the user to request a subscription to the displayed plurality of partners (See at least Col. 14, lines 15-44: Describes a system for providing borrowers with a ranked list of credit cards offered from a plurality of lending institutions. The system may provide a user interface comprising a link that, when selected, allows a user to apply [i.e., subscribe] to the plurality of offers [Also see Figure 8]).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Allen, Weyman, and Chandran in order to provide the ability for the user to easily apply for the services of the payment provider (Chandran: Col. 14, Lines 15-44). This also benefits the payment providers by allowing them to provide incentives for advertising their products to potential customers (Chandran: Col. 1, Lines 16-40).
Claim 2
Regarding Claim 2, Allen teaches:
wherein the at least one marketplace criterion comprises markets, currencies, products, product capabilities, live traffic, or a combination thereof (See at least Paragraph 62: The criteria used to determine potential partners may comprise whether the provider provides vertical coverage in the area of business of the new lead. For example, if the new lead is a bar, then partners that do not provide service to food and beverage service business may be removed from list. In other words, the criteria may include the markets served, or products provided by the partners).
Claim 3
Regarding Claim 3, Allen teaches:
wherein determining the partner data associated with the plurality of partners based on the partner matching algorithm and the at least one marketplace criterion comprises determining markets, currencies, products, product capabilities, live traffic, or a combination thereof, associated with the plurality of partners (See at least Paragraph 62: The potential partners are identified based on applying the algorithm to the criteria determined from the questionnaire [e.g., the markets served or products provided by the plurality of partners, as described above regarding claim 2]).
Claim 4
Regarding Claim 4, Allen teaches:
wherein the at least one partner filtering criterion associated with the user of the user device comprises contract agreement data that includes a location, a region, a type of product, or a combination thereof (See at least Paragraphs 62-64: The list of eligible partners may be sorted [i.e., filtered] based on various criteria. For example, the potential partners may be sorted based on a relative physical distance between the new lead and the potential partners [i.e., a location]).
Claim 5
Regarding Claim 5, Allen teaches:
wherein updating the partner data comprises rearranging the order of the plurality of partners further based on the contract agreement data (See at least Paragraphs 62-64: The list of eligible partners may be sorted [i.e., filtered] based on various criteria. For example, the potential partners may be sorted based on a relative physical distance between the new lead and the potential partners [i.e., a location]. In other words, "sorting" the potential partners comprises arranging them in an order of preference based on the criteria used to sort the potential partners).
Claim 6
Regarding Claim 6, Allen teaches:
wherein displaying the rearranged order of the plurality of partners at the user device is further based on the contract agreement data (See at least Paragraphs 77-79: The narrowed and sorted list of potential partners may be displayed on a graphical user interface via the lead pairing tool).
Claim 7
Regarding Claim 7, Allen does not explicitly teach, but Weyman, however, does teach:
wherein the provider search request comprises a live traffic transaction option that is selected via the payment portal interface at the user device (See at least Paragraph 31: The system receives input form the user regarding a plurality of user preferences [Also see Paragraphs 23-30 and Figures 3A-3G]. For example, the user may interact with a plurality of sliders [i.e., a live traffic transaction option] to select the features that are most important).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Allen and Weyman in order to provide a system that is able to evaluate payment providers [i.e., credit cards] holistically and in real time (Weyman: Paragraph 3). Utilizing real time data ensures that the user is provided with the most accurate recommendations possible.
Claim 8
Regarding Claim 8, Allen does not explicitly teach, but Weyman, however, does teach:
wherein the live traffic data comprising data from a live traffic database based on the selection of the live traffic transaction option (See at least Paragraph 31: The system receives input form the user regarding a plurality of user preferences [Also see Paragraphs 23-30 and Figures 3A-3G]. The various information selected by the user may be retrieved from a database comprising "card data sets" that store information associated with the plurality of cards, such as the acceptance and approval rates [i.e., live traffic data]).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Allen and Weyman in order to provide a system that is able to evaluate payment providers [i.e., credit cards] holistically and in real time (Weyman: Paragraph 3). Utilizing real time data ensures that the user is provided with the most accurate recommendations possible.
Claim 9
Regarding Claim 9, Allen teaches:
receiving, at the payment portal interface, an update request from the user to modify one or more portal elements associated with the user; and updating the one or more portal elements based on the update request (See at least Paragraphs 50 and 51: The system may comprise a "partner account profile tab" which stores profile information for the plurality of partners [i.e., one or more portal elements]. Depending on the permissions of the user, the user may edit the information viewable in the partner account profile tab. In other words, the user may request a change to the partner profile by providing input, and the profile may be updated based on the user input).
Claim 10
Regarding Claim 10, Allen teaches:
wherein the one or more portal elements are based on profile information, push notification options, subscriber features, ranking score structures, live traffic transaction options, or a combination thereof (See at least Paragraphs 50 and 51: The system may comprise a "partner account profile tab" which stores profile information for the plurality of partners [i.e., one or more portal elements]. Depending on the permissions of the user, the user may edit the information viewable in the partner account profile tab. In other words, the "partner account profile" corresponds to "profile information").
Claim 14
Regarding Claim 14, Allen teaches:
A system comprising: a payment platform device comprising: a non-transitory computer-readable storage medium; and one or more processors coupled to the non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium comprises program instructions that, when executed by the one or more processors, cause the one or more processors to (Describes a system for matching leads [i.e., merchants] with partners [i.e., payment provider partners]. The system comprises a processor [See Paragraphs 35-41] and a computer-readable medium storing instructions [See Claim 35]):
provide, via a payment portal interface, access for a user device to a payment marketplace module (See at least Paragraph 42-45: Describes a system for matching leads [i.e., merchants] with partners [i.e., payment provider partners]. The system may display to the user a graphical user interface comprising a dashboard [i.e., a payment portal interface] for enabling the user to evaluate partners and match partners with one or more new leads. The interface may comprise a lead pairing tool [i.e., a payment marketplace module; See Paragraph 59 and Figure 10]. The system comprises a processor [See Paragraphs 35-41]);
receive a provider search request from the user device via the payment portal interface, wherein the provider search request comprises at least one marketplace criterion (See at least Paragraphs 59-61: The user may fill out a questionnaire comprising information about the lead that is used to determine potential partners [e.g., marketplace criterion]. The user may select a "pair now" submission button in order to begin the pairing process [Also see Paragraphs 75-77: The questionnaire may be submitted in order to narrow the plurality of potential partners]. In other words, selecting the submission button corresponds to submitting a provider search request);
in response to receiving the provider search request, determine, based on a partner matching algorithm and the at least one marketplace criterion, partner data associated with a plurality of partners (See at least Paragraph 62: A matching engine may utilize an algorithm [i.e., a partner matching algorithm] to narrow down a list of eligible potential partners for pairing with the lead based on the answers provided via the questionnaire. In other words, receiving the list of eligible partners corresponds to receiving the partner data);
update the partner data based on at least one partner filtering criterion associated with a user of the user device (See at least Paragraphs 62-64: The list of eligible partners may be sorted [i.e., filtered] based on various criteria. For example, the potential partners may be sorted based on a relative physical distance between the new lead and the potential partners [i.e., filtering criteria]); and
provide the updated partner data for display at the user device via the payment portal interface (See at least Paragraph 79: The narrowed plurality of partners may be displayed on the graphical user interface via the lead pairing tool); and
the user device configured to: send the provider search request to the payment platform device (See at least Paragraphs 59-61: The user may fill out a questionnaire comprising information about the lead that is used to determine potential partners [e.g., marketplace criterion]. The user may select a "pair now" submission button in order to begin the pairing process [Also see Paragraphs 75-77: The questionnaire may be submitted in order to narrow the plurality of potential partners]. In other words, selecting the submission button corresponds to submitting a provider search request).
Regarding Claim 14, Allen does not explicitly teach, but Weyman, however, does teach:
and on live traffic data on partner capabilities from at least one of current and potential customers, the live traffic data including at least one of a transaction volume, an acceptance rate and a response time (See at least Paragraph 31: Describes a system for real-time online ranking of credit cards from a plurality of card providers [i.e., partners]. The ranking may be determined based on a plurality of information associated with the cards and card providers [i.e., live traffic data]. For example, one factor may be acceptance rate of the provider [i.e., an acceptance rate; See Paragraph 42]. The acceptance rate may correspond to the likelihood that the payment provider will be accepted at a merchant. The cards may be evaluated in "real time" [i.e., the card data is "live"; See Paragraphs 20 and 21]), and
rearrange an order of the plurality of partners based on the live traffic data (See at least Paragraph 23: The updated ranked list of credit cards is returned to the user device for display in real-time); and
display the rearranged order of the plurality of partners based on the live traffic data [[in association with links for the user to request a subscription to the displayed plurality of partners]] (See at least Paragraph 23: The updated ranked list of credit cards is returned to the user device for display in real-time. Examiner's note: The combination of Allen and Weyman does not explicitly teach that subscription "links" associated with the plurality of partners are displayed with the ranked list. However, this limitation is disclosed by Chandran as described below).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Allen and Weyman in order to provide a system that is able to evaluate payment providers [i.e., credit cards] holistically and in real time (Weyman: Paragraph 3). Utilizing real time data ensures that the user is provided with the most accurate recommendations possible.
Regarding Claim 14, the combination of Allen and Weyman does not explicitly teach, but Chandran, however, does teach:
display the rearranged order of the plurality of partners based on the live traffic data in association with links for the user to request a subscription to the displayed plurality of partners (See at least Col. 14, lines 15-44: Describes a system for providing borrowers with a ranked list of credit cards offered from a plurality of lending institutions. The system may provide a user interface comprising a link that, when selected, allows a user to apply [i.e., subscribe] to the plurality of offers [Also see Figure 8]).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Allen, Weyman, and Chandran in order to provide the ability for the user to easily apply for the services of the payment provider (Chandran: Col. 14, Lines 15-44). This also benefits the payment providers by allowing them to provide incentives for advertising their products to potential customers (Chandran: Col. 1, Lines 16-40).
Claim 15
Regarding Claim 15, Allen teaches:
wherein the at least one marketplace criterion comprises markets, currencies, products, product capabilities, live traffic, or a combination thereof (See at least Paragraph 62: The criteria used to determine potential partners may comprise whether the provider provides vertical coverage in the area of business of the new lead. For example, if the new lead is a bar, then partners that do not provide service to food and beverage service business may be removed from list. In other words, the criteria may include the markets served, or products provided by the partners).
Claim 16
Regarding Claim 16, Allen teaches:
wherein the payment platform device is configured to determine the partner data associated with the plurality of partners based on the partner matching algorithm and the at least one marketplace criterion comprises determining markets, currencies, products, product capabilities, live traffic, or a combination thereof, associated with the plurality of partners (See at least Paragraph 62: The potential partners are identified based on applying the algorithm to the criteria determined from the questionnaire [e.g., the markets served or products provided by the plurality of partners, as described above regarding claim 15]).
Claim 17
Regarding Claim 17, Allen teaches:
wherein the at least one partner filtering criterion associated with the user of the user device comprises contract agreement data that includes a location, a region, a type of product, or a combination thereof (See at least Paragraphs 62-64: The list of eligible partners may be sorted [i.e., filtered] based on various criteria. For example, the potential partners may be sorted based on a relative physical distance between the new lead and the potential partners [i.e., a location]).
Claim 18
Regarding Claim 18, Allen teaches:
wherein the payment platform device is configured to rearrange the order of the plurality of partners further based on the contract agreement data (See at least Paragraphs 62-64: The list of eligible partners may be sorted [i.e., filtered] based on various criteria. For example, the potential partners may be sorted based on a relative physical distance between the new lead and the potential partners [i.e., a location]. In other words, "sorting" the potential partners comprises arranging them in an order of preference based on the criteria used to sort the potential partners).
Claim 19
Regarding Claim 19, Allen teaches:
wherein the user device is configured to display the rearranged order of the plurality of partners further based on the contract agreement data (See at least Paragraphs 77-79: The narrowed and sorted list of potential partners may be displayed on a graphical user interface via the lead pairing tool).
Claim 20
Regarding Claim 20, Allen does not explicitly teach, but Weyman, however, does teach:
wherein the provider search request comprises a live traffic transaction option that is selected via the payment portal interface at the user device (See at least Paragraph 31: The system receives input form the user regarding a plurality of user preferences [Also see Paragraphs 23-30 and Figures 3A-3G]. For example, the user may interact with a plurality of sliders [i.e., a live traffic transaction option] to select the features that are most important).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Allen and Weyman in order to provide a system that is able to evaluate payment providers [i.e., credit cards] holistically and in real time (Weyman: Paragraph 3). Utilizing real time data ensures that the user is provided with the most accurate recommendations possible.
Claim 21
Regarding Claim 21, Allen does not explicitly teach, but Weyman, however, does teach:
wherein the live traffic data includes data from a live traffic database based on the selection of the live traffic transaction option (See at least Paragraph 31: The system receives input form the user regarding a plurality of user preferences [Also see Paragraphs 23-30 and Figures 3A-3G]. The various information selected by the user may be retrieved from a database comprising "card data sets" that store information associated with the plurality of cards, such as the acceptance and approval rates [i.e., live traffic data]).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Allen and Weyman in order to provide a system that is able to evaluate payment providers [i.e., credit cards] holistically and in real time (Weyman: Paragraph 3). Utilizing real time data ensures that the user is provided with the most accurate recommendations possible.
Claim 22
Regarding Claim 22, Allen teaches:
wherein the program instructions, when executed by the one or more processors, further cause the one or more processors to: receive, at the payment portal interface, an update request from the user to modify one or more portal elements associated with the user; and update the one or more portal elements based on the update request (See at least Paragraphs 50 and 51: The system may comprise a "partner account profile tab" which stores profile information for the plurality of partners [i.e., one or more portal elements]. Depending on the permissions of the user, the user may edit the information viewable in the partner account profile tab. In other words, the user may request a change to the partner profile by providing input, and the profile may be updated based on the user input).
Claim 23
Regarding Claim 23, Allen teaches:
wherein the one or more portal elements are based on profile information, push notification options, subscriber features, ranking score structures, live traffic transaction options, or a combination thereof (See at least Paragraphs 50 and 51: The system may comprise a "partner account profile tab" which stores profile information for the plurality of partners [i.e., one or more portal elements]. Depending on the permissions of the user, the user may edit the information viewable in the partner account profile tab. In other words, the "partner account profile" corresponds to "profile information").
13. Claims 11, 12, 24, and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Allen (U.S. Pre-Grant Publication No. 20230316355) in view of Weyman (U.S. Pre-Grant Publication No. 20190114622) and Chandran (U.S. Patent No. 8799148), and in further view of Soh (U.S. Pre-Grant Publication No. 20190095992).
Claim 11
Regarding Claim 11, the combination of Allen, Weyman, and Chandran does not explicitly teach, but Soh, however, does teach:
wherein the payment portal interface comprises a front-end application program interface (API) (See at least Paragraph 161 and 162: The displaying of the real-time data may be facilitated by an API).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Allen, Weyman, Chandran, and Soh in order to allow users to more accurately assess the cost and terms for completing cross-border money transfer transactions (Soh: Paragraphs 2-6). Applying technologies such as API facilitate the presentation of such information to the user (Soh: Paragraphs 161 and 162).
Claim 12
Regarding Claim 12, the combination of Allen, Weyman, and Chandran does not explicitly teach, but Soh, however, does teach:
wherein the API is based on a representational state transfer protocol (See at least Paragraph 161 and 162: The API may comprise a Representation State Transfer API).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Allen, Weyman, Chandran, and Soh in order to allow users to more accurately assess the cost and terms for completing cross-border money transfer transactions (Soh: Paragraphs 2-6). Applying technologies such as API facilitate the presentation of such information to the user (Soh: Paragraphs 161 and 162).
Claim 24
Regarding Claim 24, the combination of Allen, Weyman, and Chandran does not explicitly teach, but Soh, however, does teach:
wherein the payment portal interface comprises a front-end application program interface (API) (See at least Paragraph 161 and 162: The displaying of the real-time data may be facilitated by an API).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Allen, Weyman, Chandran, and Soh in order to allow users to more accurately assess the cost and terms for completing cross-border money transfer transactions (Soh: Paragraphs 2-6). Applying technologies such as API facilitate the presentation of such information to the user (Soh: Paragraphs 161 and 162).
Claim 25
Regarding Claim 25, the combination of Allen, Weyman, and Chandran does not explicitly teach, but Soh, however, does teach:
wherein the API is based on a representational state transfer protocol (See at least Paragraph 161 and 162: The API may comprise a Representation State Transfer API).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Allen, Weyman, Chandran, and Soh in order to allow users to more accurately assess the cost and terms for completing cross-border money transfer transactions (Soh: Paragraphs 2-6). Applying technologies such as API facilitate the presentation of such information to the user (Soh: Paragraphs 161 and 162).
14. Claims 13 and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Allen (U.S. Pre-Grant Publication No. 20230316355) in view of Weyman (U.S. Pre-Grant Publication No. 20190114622) and Chandran (U.S. Patent No. 8799148), and in further view of Chu (U.S. Pre-Grant Publication No. 20060265361).
Claim 13
Regarding Claim 13, the combination of Allen, Weyman, and Chandran does not explicitly teach, but Chu, however, does teach:
wherein the provider search request is received from a travel provider server (See at least Paragraphs 29-33: Describes a system that assists travel agencies in searching for travel services. The travel agent [i.e., the travel provider server] may implement a search strategy [i.e., a search request] to find one or more travel services. Examiner’s Note: The search request described by Chu is not a search request for a “provider” as described in claim 1 [e.g., a provider of payment services]. However, it would have been obvious to one of ordinary skill in the art that the search requests implemented by the travel agent described by Chu could be applied to search for providers of payment services, such as the “partners” described by Allen).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Allen, Weyman, Chandran, and Chu in order to provide travel agents with the tools needed to efficiently and effectively search multiple sources for services related to travel (Chu: Paragraphs 5-10).
Claim 26
Regarding Claim 26, the combination of Allen, Weyman, and Chandran does not explicitly teach, but Chu, however, does teach:
wherein the provider search request is received from a travel provider server (See at least Paragraphs 29-33: Describes a system that assists travel agencies in searching for travel services. The travel agent [i.e., the travel provider server] may implement a search strategy [i.e., a search request] to find one or more travel services. Examiner’s Note: The search request described by Chu is not a search request for a “provider” as described in claim 1 [e.g., a provider of payment services]. However, it would have been obvious to one of ordinary skill in the art that the search requests implemented by the travel agent described by Chu could be applied to search for providers of payment services, such as the “partners” described by Allen).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Allen, Weyman, Chandran, and Chu in order to provide travel agents with the tools needed to efficiently and effectively search multiple sources for services related to travel (Chu: Paragraphs 5-10).
Response to Arguments
15. Applicant’s arguments filed May 15, 2026 have been fully considered.
Arguments Regarding 35 U.S.C. 101
16. Applicant’s arguments (Amendment, Pgs. 7 and 8) concerning the prior rejection of the claims under 35 USC §101, including supposed deficiencies in the rejection, are not persuasive for the following reasons. Under the prior and current 101 analysis under 2019 PEG, the amended claims recite and are directed to a patent ineligible abstract idea, without something significantly more, for the reasons given above after consideration of the claimed features and elements. The abstract idea has been restated herein in line with the 2019 PEG guidance and the amended claims. Applicant is directed to the above full Alice/Mayo analysis in the 101 rejection.
Additionally, on page 7 of their remarks, the applicant argues, “As a result, the claimed methods/systems leverage the live traffic data to provide results to a partner search that are ordered according to the current capabilities of the partners, thereby facilitating a selection of a partner based on the partner’s actual current performance, the selection involving a subscription request to the partner. In doing so, the performance of the system is enhanced, as, for example, the selected partner will be more likely to 1) be capable of processing the request based on current transaction volume, 2) be more likely to accept the request based on current acceptance rate, and/or 3) be faster at providing a response to the transaction based on current response time.” Similar arguments are presented on Page 8 of the applicant’s arguments. The examiner respectfully disagrees. Specifically, the examiner notes that the claims do not provide sufficient technical detail regarding how the claimed processes are performed. For example, simply stating that the system utilizes “live traffic data” to provide results to the user does not provide an indication of an improvement to any technology or technological field. The claims do not provide significant technical detail regarding how the live traffic data is collected, and/or how the live traffic data is applied to filter/update the partner data. Therefore, such limitations simply further refine the abstract idea. Similarly, simply stating that the live traffic data is “from current and/or potential customers” does amount to significantly more than the abstract idea. The claims do not provide any technical detail regarding how the live traffic data is retrieved from the current an/or potential customers. Therefore, such limitations simply broadly define the source of the live traffic data.
Therefore, for these reasons and the reasons given above, the rejection of these claims under 35 U.S.C. §101 is maintained.
Arguments Regarding 35 U.S.C. 102/103
17. Applicant’s arguments regarding the prior art rejections are moot in view of the new grounds of rejection necessitated by applicant’s claim amendments.
Citation of Pertinent Prior Art
18. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Husak (U.S. Pre-Grant Publication No. 20240330875): Describes a marketplace tool and platform to connect payment processors and merchants via a matching system which utilizes a combination of algorithms and machine learning tools.
Niu (U.S. Patent No. 12650996): Describes a server and a method for processing a request for a search for an on-demand service. The system is configured to filter out a part of the first list of service providers based on the rank of each service provider in the first list of service providers.
Conclusion
THIS ACTION IS MADE FINAL. 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 WILLIAM D NEWLON whose telephone number is (571)272-4407. The examiner can normally be reached Mon - Fri 8:30 - 4:30.
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, Matthew Gart can be reached at (571) 272-3955. 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.
/WILLIAM D NEWLON/Examiner, Art Unit 3696
/MATTHEW S GART/Supervisory Patent Examiner, Art Unit 3696
Prosecution Insights