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 Preliminary Amendment filed January 15, 2025 has been entered. Claims 27-36 are newly cancelled. 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 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]].
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 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; and
providing the updated partner data for display at the user device via the payment portal interface.
These limitations simply state that a payment portal interface provides the user access to (i.e., displays) a payment marketplace module, and that the partner data 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 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; and
providing the updated partner data for display at the user device via the payment portal interface.
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 as 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 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 § 102
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 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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(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.
12. Claims 1-7, 9, 10, 14-19, 22, and 23 are rejected under 35 U.S.C. 102(a)(1) and 35 U.S.C. 102(a)(2) as being anticipated by Allen (U.S. Pre-Grant Publication No. 20230316355).
Claim 1
Regarding Claim 1, Allen teaches:
A method comprising: at a 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).
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 an order of the plurality of partners 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 providing the updated partner data for display at the user device comprises displaying the rearranged order of the plurality of partners 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 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 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: 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]);
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).
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 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 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 updating the partner data comprises rearranging an order of the plurality of partners 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 providing the updated partner data for display at the user device comprises displaying the rearranged order of the plurality of partners 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 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").
Claim Rejections - 35 USC § 103
13. 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.
14. Claims 7, 8, 11, 12, 20, 21, 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 Soh (U.S. Pre-Grant Publication No. 20190095992).
Claim 7
Regarding Claim 7, Allen does not explicitly teach, but Soh, 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 86: Describes a system for processing data collected from a plurality of money services businesses servers. The system may comprise a user interface that allows the user to submit input search requests. The interface comprises a search icon which the user may select to request real-time data collected from decentralized heterogeneous money service business and market exchange rate data sources [i.e., live traffic data; Also see Paragraphs 109 and 110]).
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 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).
Claim 8
Regarding Claim 8, Allen does not explicitly teach, but Soh, however, does teach:
wherein the partner data is updated by utilizing live traffic data from a live traffic database based on the selection of the live traffic transaction option (See at least Paragraphs 109 and 110: The live dashboard may display various data related to the plurality of money service businesses [i.e., partners]. This data may include a transfer speed [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 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).
Claim 11
Regarding Claim 11, Allen 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 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, Allen 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 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 20
Regarding Claim 20, Allen does not explicitly teach, but Soh, 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 86: Describes a system for processing data collected from a plurality of money services businesses servers. The system may comprise a user interface that allows the user to submit input search requests. The interface comprises a search icon which the user may select to request real-time data collected from decentralized heterogeneous money service business and market exchange rate data sources [i.e., live traffic data; Also see Paragraphs 109 and 110]).
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 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).
Claim 21
Regarding Claim 21, Allen does not explicitly teach, but Soh, however, does teach:
wherein the partner data is updated by utilizing live traffic data from a live traffic database based on the selection of the live traffic transaction option (See at least Paragraphs 109 and 110: The live dashboard may display various data related to the plurality of money service businesses [i.e., partners]. This data may include a transfer speed [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 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).
Claim 24
Regarding Claim 24, Allen 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 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, Allen 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 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).
15. 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 Chu (U.S. Pre-Grant Publication No. 20060265361).
Claim 13
Regarding Claim 13, Allen 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 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, Allen 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 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).
Citation of Pertinent Prior Art
16. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Guyot (U.S. Patent No. 11004047): Describes methods and systems wherein payment options may be displayed in a tailored, customized, or personalized manner to a specific user so that the user may conduct transactions in connection with applications, products and/or services.
Ready (U.S. Pre-Grant Publication No. 20250104041): Describes a system that identifies and recommends the most applicable digital wallets for a user based on various factors, such as user location, type and amount of purchase, type of merchant, and/or mood of the user.
Conclusion
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