DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Application
This office action is in response to the most recent filings filed by applicants on 06/29/26:
Claims 1, 7, 8, and 15 are amended
Claims 4, 6, 10-11, 17-18, 20-21 and 24 are cancelled
No claims are added
Claims 1-3, 5, 7-9, 12-16, 19, 22-23 and 25-26 are pending
Note:
Regarding the claim limitations in claims 1, 8 and 15, it should be noted that limitations like, the “redirecting limitation” is simply redirecting address similar to clicking an ad on a webpage and being redirected to a different page or similarly receiving a link in an email that redirects the user from the email to a different site.
Regarding the amended claim limitations in claims 1, 8 and 15, it should be noted that limitations like “scanning, by the user terminal with the third party application, a two-dimensional code on the merchant terminal for online payment to be handled by an acquirer, the two-dimensional code including at least merchant terminal information and a code issuer classification code” given its broadest reasonable interpretation can be reasonably interpreted as a bar code or QR code. The limitations are also simply an inputting information step.
In addition, it is unclear who or what is performing the steps discussed in the claims. Since the scope of the claim limitations is ambiguous, it could be reasonably interpreted that a human being is performing the steps. For instance, the limitation “receiving, by the system terminal from the user terminal…” is still broadly recited so it could be reasonably interpreted that a human is performing the step by using the system terminal.
Similarly, the claim limitation “in response to that the two-dimensional code is the acquirer issued code, obtaining the corresponding merchant terminal information and jump target information by a Look-up Table method based on the code issuer classification code which is an acquirer code; in response to that the two-dimensional code is the system issued code, first obtaining a corresponding acquirer code by a Look-up Table method based on the acquirer ID, and then obtaining the jump target information by a Look- up Table method based on the acquirer code and the corresponding merchant terminal information” is still very broadly recited so it could be reasonably interpreted that a human is performing the step of manually using a scanner to scan a two-dimensional code and in response to the results of the scan using the code to look up in a database – a Lookup Table – to figure out a payment code.
In light of these notes, the amended claims do not overcome previously presented rejections under 101 and 103. As is discussed below. This note is intended as a conversation starter to help applicants understand the examiner’s perspective.
Claim Objections
Claim 8 is objected to because of the following informalities: claim 8 has lots of amendments, but the claim label says “Previously Presented”. This appears to be a typo, and the claim is reasonably understood as being amended. Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-3, 5, 7-9, 12-16, 19, 22-23 and 25-26 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without significantly more.
Step One - First, pursuant to step 1 in the January 2019 Guidance on 84 Fed. Reg. 53, the claims 1-3, 5, 7-9, 12-14, 22, and 25-26 is/are directed to a method which is a statutory category.
Step One - First, pursuant to step 1 in the January 2019 Guidance on 84 Fed. Reg. 53, the claims 15-16, 19 and 23 is/are directed to a system which is a statutory category.
Under the 2019 PEG, Step 2A under which a claim is not “directed to” a judicial exception unless the claim satisfies a two-prong inquiry. Further, particular groupings of abstract ideas are consistent with judicial precedent and are based on an extraction and synthesis of the key concepts identified by the courts as being abstract.
With respect to the Step 2A, Prong One, the claims as drafted, and given their broadest reasonable interpretation, fall within the Abstract idea grouping of “certain methods of organizing human activity” (business relations; relationships or interactions between people). For instance, independent Method Claim 1 is directed to an abstract idea, as evidenced by claim limitations “receiving, a first access request corresponding to payment information, wherein the first access request is generated by the user terminal based on the two-dimensional code and comprises at least user terminal information, the merchant terminal information, the code issuer classification code, and an acquirer identification (ID); generating, redirection address information based on the first access request to identify the acquirer for handling the online payment regardless whether the acquirer is the code issuer, wherein the redirection address information comprises jump target information corresponding to the acquirer and including a network address, and order information corresponding to a transaction order to be paid; and transmitting, the redirection address information to the user terminal through the third party application; the user terminal generating a second access request to the acquirer based on the redirection address, the second access request configured to cause the acquirer to generate an order and transmit a payment request to the user terminal, wherein the generating, redirection address information based on the first access request comprises: determining a source of access based on the user terminal information, the source of access including the identity of the third party application; determining whether the two-dimensional code scanned by the user terminal is a system issued code or an acquirer issued code based on the code issuer classification code; in response to that the two-dimensional code is the acquirer issued code, obtaining the corresponding merchant terminal information and jump target information by a Look-up Table method based on the code issuer classification code which is an acquirer code; in response to that the two-dimensional code is the system issued code, first obtaining a corresponding acquirer code by a Look-up Table method based on the acquirer ID, and then obtaining the jump target information by a Look- up Table method based on the acquirer code and the corresponding merchant terminal information.”
For instance, independent Method Claim 8 is directed to an abstract idea, as evidenced by claim limitations “acquiring, with the user terminal, from a merchant terminal, payment information of an order; acquiring dynamic data with the third party application; generating a first access request on the basis of the payment information and the dynamic data, wherein the first access request comprises at least user terminal information, merchant terminal information, a code issuer classification code, and an acquirer identification (ID); receiving redirection address information generated based on the first access request to identify the acquirer for handling the online payment regardless whether the acquirer is the code issuer, wherein the redirection address information comprises jump target information corresponding to the acquirer and containing a network address and order information corresponding to the order; generating a second access request on the basis of the redirection address information; receiving a payment request based on the second access request; and making payment on the basis of the payment request, wherein the redirection address information is generated based on the first access request by: determining a source of access based on the user terminal information the source of access including the identity of the third party application; determining whether the two-dimensional code scanned by the user terminal is a system issued code or an acquirer issued code based on the code issuer classification code; in response to that the two-dimensional code is the acquirer issued code, obtaining the corresponding merchant terminal information and jump target information by a Look-up Table method based on the code issuer classification code which is an acquirer code; in response to that the two-dimensional code is the system issued code, first obtaining a corresponding acquirer code by a Look-up Table method based on the acquirer ID, and then obtaining the jump target information by a Look-up Table method based on the acquirer code and the corresponding merchant terminal information.”
Applicants’ specification in [0003] discusses the following as the existing problem that the current application is trying to solve. [0003]: in the process of code scanning payment, the certain situations often occur, in which users scan two-dimensional codes through different third-party applications on their devices, so that a merchant is required to show the two-dimensional codes corresponding to the third-party applications used by the users; a payee needs to access the corresponding accounts to confirm whether the payment is successful; and in particular, when the merchant provides a specific type of two- dimensional code, a user has to use a third-party application interfacing with the provider of the two- dimensional code for scanning the code, resulting in poor user experience, and payment failure may be led to.
In light of the specification, these claim limitations belong to the grouping of “certain methods of organizing human activity” because the claims are related to supporting multiple third-party applications to scan a two-dimensional code for payment. Managing and supporting multiple third-party applications to scan a two-dimensional code for payment for one or more human entities involves organizing human activity based on the description of “certain methods of organizing human activity” provided by the courts. The court have used the phrase “Certain methods of organizing human activity” as —fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions).
Managing user’s payment experience is a certain method of organizing human activity. Applicants are solving a business problem not a technical problem.
Similarly, in light of the specification, these claim limitations also belong to the grouping of “mental processes” because the claims are related to supporting multiple third-party applications to scan a two-dimensional code for payment thereby saving the user from having to use a third-party application interfacing with the provider of the two- dimensional code for scanning the code, resulting in poor user experience, and payment failure may be led to. Here, it unclear who or what is performing the steps, as such the steps could easily be performed by a human being. The court have used the phrase “mental processes” as — concepts performed in the human mind (including an observation, evaluation, judgment, opinion).
Independent Claim 15 is/are recite substantially similar limitations to independent claims 1 and 8 and is/are rejected under 2A for similar reasons to claims 1 and 8 above.
With respect to the Step 2A, Prong Two - This judicial exception is not integrated into a practical application. In particular, the claim only recites “A method for integrated payment in an online environment including a user terminal, a merchant terminal, a system terminal, and a plurality of acquirers, using a third party application on a user terminal, comprising: scanning, by the user terminal with the third party application, a two-dimensional code on the merchant terminal for online payment to be handled by an acquirer, the two-dimensional code including at least merchant terminal information and a code issuer classification code; by the system terminal from the user terminal, by the system terminal, by the system terminal,” (claim 1) and “A method for integrated payment in an online environment including a user terminal, a merchant terminal, a system terminal, and a plurality of acquirers, using a third party application on the user terminal, comprising: scanning a two-dimensional code, for online payment to be handled by an acquirer, with the third party application on the user terminal, the two-dimensional code including at least merchant terminal information and a code issuer classification code; on the user terminal; from the user terminal; at the user terminal through the third party application from a proxy service; from the user terminal; at the user terminal;” (claim 8) such that it amounts to no more than: adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, as discussed in MPEP 2106.05(f).
As a result, claims 1, 8 and 15 do not provide any specifics regarding the integration into a practical application when recited in a claim with a judicial exception.
Similarly, dependent claims 2-3, 5, 7, 9, 12-14, 16, 19, 22-23 and 25-26 are also directed to an abstract idea under 2A, first and second prong. In the present application, all of the dependent claims have been evaluated and it was found that they all inherit the deficiencies set forth with respect to the independent claims. For instance, dependent claims 2 recite “wherein the order information comprises an order number and/or one or more pieces of information of order details” and dependent claims 3 recite “wherein the generating redirection address information is performed by a proxy service.” Dependent claims 5 recites “wherein the redirection address information further comprises acquirer information”. Dependent claims 13 recites “wherein the acquiring, from a merchant terminal, payment information of an order comprises: acquiring the order information by acquiring two-dimensional code information.” Dependent claims 14 recites “wherein the making payment on the basis of the payment request comprises: making payment by invoking a payment control.” Dependent claims 16 recites “wherein the order information comprises an order number and/or one or more pieces of information of order details.” Dependent claims 19 recites “wherein the redirection address information further comprises acquirer information.” Dependent claims 22 recites “wherein the network address is a universal resource locator.” Here, these claims offer further descriptive limitations of elements found in the independent claims which are similar to the abstract idea noted in the independent claim above.
Dependent claims 7 recites “wherein transmitting the redirection address information to the user terminal includes transmitting the redirection address information to the third-party application at the user terminal”. Dependent claims 25 recites “wherein the transmitting the redirection address information to the user terminal comprises: transmitting the redirection address information to the user terminal via a merchant terminal; or transmitting the redirection address information to the user terminal via an acquirer”. Dependent claims 26 recites “further comprising: based on the identity of the third-party application, converting the redirection address information into a form suitable for the third-party application.” In this claim, “user terminal via a merchant terminal” is an additional element, but it is still being recited such that it amounts to no more than: adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, as discussed in MPEP 2106.05(f). As a result, Examiner asserts that dependent claims, such as dependent claims 2-3, 5, 7, 9, 12-14, 16, 19, 22-23 and 25-26 are also directed to the abstract idea identified above.
With respect to Step 2B, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. First, the invention lacks improvements to another technology or technical field [see Alice at 2351; 2019 IEG at 55], and lacks meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment [Alice at 2360, 2019 IEG at 55], and fails to effect a transformation or reduction of a particular article to a different state or thing [2019 IEG, 55]. For the reasons articulated above, the claims recite an abstract idea that is limited to a particular field of endeavor (MPEP § 2106.05(h)) and recites insignificant extra-solution activity (MPEP § 2106.05(g)). By the factors and rationale provided above with respect to these MPEP sections, the additional elements of the claims that fail to integrate the abstract idea into a practical application also fail to amount to “significantly more” than the abstract idea.
As discussed above with respect to integration of the abstract idea into a practical application, the additional element(s) of “A method for integrated payment in an online environment including a user terminal, a merchant terminal, a system terminal, and a plurality of acquirers, using a third party application on a user terminal, comprising: scanning, by the user terminal with the third party application, a two-dimensional code on the merchant terminal for online payment to be handled by an acquirer, the two-dimensional code including at least merchant terminal information and a code issuer classification code; by the system terminal from the user terminal, by the system terminal, by the system terminal,” (claim 1) and “A method for integrated payment in an online environment including a user terminal, a merchant terminal, a system terminal, and a plurality of acquirers, using a third party application on the user terminal, comprising: scanning a two-dimensional code, for online payment to be handled by an acquirer, with the third party application on the user terminal, the two-dimensional code including at least merchant terminal information and a code issuer classification code; on the user terminal; from the user terminal; at the user terminal through the third party application from a proxy service; from the user terminal; at the user terminal;” (claim 8) are insufficient to amount to significantly more. Applicants originally submitted specification describes the computer components above at least in paragraphs [0031]-[0034], [0032]: general purpose computer. In light of the specification, it should be noted that the components discussed above did not meaningfully limit the abstract idea because they merely linked the use of the abstract idea to a particular technological environment (i.e., "implementation via computers"). In light of the specification, it should be noted that the claim limitations discussed above are merely instructions to implement the abstract idea on a computer. See MPEP 2106.05(f). (See MPEP 2106.05(f) - Mere Instructions to Apply an Exception - “Thus, for example, claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible.” Alice Corp., 134 S. Ct. at 235). Mere instructions to apply an exception using computer component cannot provide an inventive concept.).
Additionally, in Paragraph [0006] of the instant specification, by generating a redirection address to route a request that would, in existing systems, undergo multiple rounds of communication as described in Paragraphs [0004] and [0005] of the instant disclosure” is not an improvement to the technological environment. The benefit of the claimed invention argued by applicants is something any type of filtering process will provide.
The claim fails to recite any improvements to another technology or technical field, improvements to the functioning of the computer itself, use of a particular machine, effecting a transformation or reduction of a particular article to a different state or thing, adding unconventional steps that confine the claim to a particular useful application, and/or meaningful limitations beyond generally linking the use of an abstract idea to a particular environment. See 84 Fed. Reg. 55. Viewed individually or as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself.
Independent Claim 15 is/are recite substantially similar limitations to independent claims 1 and 8 and is/are rejected under 2B for similar reasons to claims 1 and 8 above.
Further, it should be noted that additional elements of the claimed invention such as claim limitations when considered individually or as an ordered combination along with the other limitations discussed above in method claims 1 and 8 also do not meaningfully limit the abstract idea because they merely linked the use of the abstract idea to a particular technological environment (i.e., "implementation via computers"). In light of the specification, it should be noted that the claim limitations discussed above are merely instructions to implement the abstract idea on a computer. See MPEP 2106.
Similarly, dependent claims 2-3, 5, 7, 9, 12-14, 16, 19, 22-23 and 25-26 also do not include limitations amounting to significantly more than the abstract idea under the second prong or 2B of the Alice framework. In the present application, all of the dependent claims have been evaluated and it was found that they all inherit the deficiencies set forth with respect to the independent claims. Further, it should be noted that the dependent claims do not include limitations that overcome the stated assertions. Here, the dependent claims recite features/limitations that include computer components identified above in part 2B of analysis of independent claims 1, 8 and 15. As a result, Examiner asserts that dependent claims, such as dependent claims 2-3, 5, 7, 9, 12-14, 16, 19, 22-23 and 25-26 are also directed to the abstract idea identified above.
For more information on 101 rejections, see MPEP 2106, January 2019 Guidance at https://www.govinfo.gov/content/pkg/FR-2019-01 -07/pdf/2018-28282.pdf
Claim Rejections - 35 USC § 103 - withdrawn
In the most recent filings, applicants have amended independent claims 1, 8 and 15. Please see the Remarks dated 06/29/26, especially on pages 10-11 from applicants’ remarks show why the 103 rejection is overcome are persuasive.
In light of applicants’ arguments and the amendments filed by applicants to previously presented claims in light of the originally filed disclosure the previously made rejection under 35 U.S.C. 103 has been withdrawn for following reasons:
For claim 1:
A method for integrated payment in an online environment including a user terminal, a merchant terminal, a system terminal, and a plurality of acquirers, using a third-party application on a user terminal, comprising:
scanning, by the user terminal with the third party application, a two-dimensional code on the merchant terminal for online payment to be handled by an acquirer, the two-dimensional code including at least merchant terminal information and a code issuer classification code;
receiving, by the system terminal from the user terminal, a first access request corresponding to payment information, wherein the first access request is generated by the user terminal based on the two-dimensional code and comprises at least user terminal information, the merchant terminal information, the code issuer classification code, and an acquirer identification (ID);
generating, by the system terminal, redirection address information based on the first access request to identify the acquirer for handling the online payment regardless whether the acquirer is the code issuer, wherein the redirection address information comprises jump target information corresponding to the acquirer and including a network address, and order information corresponding to a transaction order to be paid; and
transmitting, by the system terminal, the redirection address information to the user terminal through the third party application;
the user terminal generating a second access request to the acquirer based on the redirection address, the second access request configured to cause the acquirer to generate an order and transmit a payment request to the user terminal,
wherein the generating, by the system terminal, redirection address information based on the first access request comprises:
determining a source of access based on the user terminal information, the source of access including the identity of the third party application;
determining whether the two-dimensional code scanned by the user terminal is a system issued code or an acquirer issued code based on the code issuer classification code;
in response to that the two-dimensional code is the acquirer issued code, obtaining the corresponding merchant terminal information and jump target information by a Look-up Table method based on the code issuer classification code which is an acquirer code;
in response to that the two-dimensional code is the system issued code, first obtaining a corresponding acquirer code by a Look-up Table method based on the acquirer ID, and then obtaining the jump target information by a Look- up Table method based on the acquirer code and the corresponding merchant terminal information.
None of the references cited - (US 2021/0065141) Batra et al., further in view of (US 2018/0300715) Wang, and (US 2011/0307710) McGuire et al. show the claim limitations discussed above in light of the specification.
Even though, Reference Batra shows in Batra: [0028]: System and Method. Batra: [0028] The merchant then forwards the transaction details to their payment gateway. This is another (SSL) encrypted connection to the payment server hosted by the payment gateway. The payment gateway converts the message, for example, from XML to ISO 8583 or a variant message format (format understood by EFT Switches) and then forwards the transaction information to the payment processor used by the merchant's acquiring bank. Here, the payment gateway receiving the message containing transaction information from the merchant reads on the above claim limitation. Further, Batra shows in [0180] The runtime application generator 920 dynamically builds and executes the virtual applications 928 in response to specific requests received from the user systems 940. The virtual applications 928 are typically constructed in accordance with the tenant-specific metadata 938, which describes the particular tables, reports, interfaces and/or other features of the particular application 928. In various embodiments, each virtual application 928 generates dynamic web content that can be served to a browser or other client program 942 associated with its user system 940, as appropriate. [0187] As noted above, the virtual application 928 may contain JAVA®, ActiveX, or other content that can be presented using conventional client software running on the user system 940; other embodiments may simply provide dynamic web or other content that can be presented and viewed by the user, as desired. As described in greater detail below, the query generator 914 suitably obtains the requested subsets of data 932 from the database 930 as needed to populate the tables, reports or other features of the particular virtual application 928. [0097]-[0098]: it should be appreciated that the same or similar code pattern or structure can be used to implement other types of payment transactions including requests such as an authorization reversal request, a capture request, a sale request, a void request, and a refund request, and responses such as an authorization reversal response, a capture response, a sale response, a void response, and a refund response. [0098] The code includes code for specifying a global class namespace for a payment gateway adapter; and a global namespace for specifying a gateway response process request and payment gateway context. The code includes a string request type used to specify payment gateway context for getting a payment request type. The code can be used to validate data and send an error response of the type gateway error response in the event there are any data validation errors. The code includes a body used to build an authorization request for a payment gateway context and to get a payment request, code to execute a call specified by the body, and code to create and return an authorization response. The code includes code for executing a call on string body for a private HTTP response. The code includes code for building an authorization request including a string for creating a request body and returning the request body. The private string for creating the request body includes a string transaction type, a string amount, a string currency iso-namespace, and a payment method. The code includes code for creating a JSON generator instance and writing data to a JSON string. If the payment method is a credit card, the code can write the card data to an end object and return a JSON generator instance as a string. The code includes code for specifying a private namespace and creating an authorization response. The code can be used to create a map of response values by parsing the response. The code includes code for populating an authorization response object and a payment method response. The code includes code for specifying a namespace for the payment method response and setting a gateway token by getting the map of response values and then returning the authorization response. The code includes code for parsing the JSON string of the authorization response to key-value pairs, and then returning a map of response values by key.
However, Batra does not show a two-dimensional code. However, Batra does not explicitly show “proxy service”. Batra also does not explicitly show “jump target information”. Batra does not show “the redirection address information”. Batra shows: [0028] The merchant then forwards the transaction details to their payment gateway. This is another (SSL) encrypted connection to the payment server hosted by the payment gateway. The payment gateway converts the message, for example, from XML to ISO 8583 or a variant message format (format understood by EFT Switches) and then forwards the transaction information to the payment processor used by the merchant's acquiring bank. Here, the payment gateway sending the message to the acquiring bank reads on the above claim limitation. Batra shows: [0196]: user information including, location, user account, etc. Batra shows: [0104]: merchant's bank account and a payment gateway ID [0159]. Additionally, in [0186], Batra shows: The user typically authenticates his or her identity to the server 902 to obtain a session identifier (“SessionID”) that identifies the user in subsequent communications with the server 902. Here, the user authentication also reads on the limitations above. Batra also shows multiple tenants and many different organizations in [0165]-[0166], [0168] The multi-tenant system 900 allows users of user systems 940 to establish a communicative connection to the multi-tenant system 900 over a network 945. All of this reads on “first” and “second” in the claim. However, Batra does not explicitly show how the merchant, merchant’s bank, etc. are identified. As such, the reference does not show the above claim limitations.
Reference Wang shows a two-dimensional code in [0128] Implementations of the subject matter described in this specification can be implemented so as to realize particular advantages or technical effects. For example, implementations of the subject matter permit a request for a two-dimensional code from a code display client to be made to a server. The server receives the request and generates the requested two-dimensional code for display on a two-dimensional code display client. The generated two-dimensional code can be scanned from the two-dimensional code display client through user interaction (for example, a touch or swipe interaction) with a graphical user interface of a two-dimensional code scanning client. The server provides a verification of the validity of the scanned two-dimensional code. The validity result can be displayed on a graphical user interface of the two-dimensional code scanning client. Based on the validity determination, a determination of whether to perform subsequent actions (for example, using the two-dimensional code scanning client to complete a transaction, transmit data, or store information) can be made. Wang also does not show “proxy service”. Reference Wang shows the above limitations at least in [0048] For example, assume that the source system account included in the first service request is “11”, and a name of the target system is “aa”, the account “22” of the target system can be retrieved from Table 1. That is, when a user corresponding to “11” logs in to the target system from the source system, the user does not need to input “22” and the password again, but instead, the service platform directly retrieves “22” corresponding to “11”, and adds the target system account to the payment request to be sent to the target system. Wang shows “jump target information” (Wang shows: [0033] The second service request sent by the service platform to the target system can include the converted payment amount. After receiving the second service request, the target system can return address information (such as a URL address) of the target system to the source system by using the service platform, so that the source system can implement a jump operation to the login interface of the target system (that is, the login interface of the target system is loaded) based on the address information of the target system. The target system can receive the account and password information of the target system that are input by the user on the login interface and perform verification on the received account and password of the target system. After passing verification, the target system can display an interface on which the user can select a payment tool and input a payment password. After the payment password received is verified, the target system can perform a service operation corresponding to the second service request, for example, deduct the converted payment amount from the target system account. Here, the jump operation to the login interface of the target system (that is, the login interface of the target system is loaded) based on the address information of the target system reads on the above limitations). Wang shows “the redirection address information” (Wang shows: [0033] The second service request sent by the service platform to the target system can include the converted payment amount. After receiving the second service request, the target system can return address information (such as a URL address) of the target system to the source system by using the service platform, so that the source system can implement a jump operation to the login interface of the target system (that is, the login interface of the target system is loaded) based on the address information of the target system. The target system can receive the account and password information of the target system that are input by the user on the login interface and perform verification on the received account and password of the target system. After passing verification, the target system can display an interface on which the user can select a payment tool and input a payment password. After the payment password received is verified, the target system can perform a service operation corresponding to the second service request, for example, deduct the converted payment amount from the target system account. Here, the jump operation to the login interface of the target system (that is, the login interface of the target system is loaded) based on the address information of the target system reads on the above limitations). Wang shows how the merchant, merchant’s bank, etc. are identified. at least in [0048] For example, assume that the source system account included in the first service request is “11”, and a name of the target system is “aa”, the account “22” of the target system can be retrieved from Table 1. That is, when a user corresponding to “11” logs in to the target system from the source system, the user does not need to input “22” and the password again, but instead, the service platform directly retrieves “22” corresponding to “11”, and adds the target system account to the payment request to be sent to the target system. Reference Wang does not explicitly show “proxy service” and “Look up tables”. As such, the reference does not show the claim limitations above.
Reference McGuire shows “proxy service” [0107]: payment-processing system 1000 initiates tokenization using a proxy server 1021. Proxy server 1021 forwards to token application 1024 packets containing tokenization requests originating from customer-service input module 1040 and web store 1010, and proxy server 1021 also forwards tokenized responses sent back to customer-service input module 1040 and web store 1010 from token application 1024, also see [0151]. Here, the service provided by the proxy server reads on the above claim limitation. McGuire also shows “Look-up tables” in [0049] Tokenizer 120 includes one or more computers containing a token database 122 and a token application 124. Token database 122, may be implemented using, e.g., a simple look-up table or a more complex database system, such as Oracle Database 10g available from Oracle Corporation of Redwood City, Calif. Token database 122 contains encrypted payment-card numbers, along with a corresponding token for each encrypted payment-card number in the database. However, the reference does not show the above claim limitations.
*Additionally, the prior art made of record and not relied upon is considered pertinent to applicant's disclosure; however, the reference does not show the above claim limitations:
NPL Reference:
Reference O. Tounekti, A. Ruiz-Martínez and A. F. Skarmeta Gómez, "Users Supporting Multiple (Mobile) Electronic Payment Systems in Online Purchases: An Empirical Study of Their Payment Transaction Preferences," in IEEE Access, vol. 8, pp. 735-766, 2020, doi: 10.1109/ACCESS.2019.2961785.
The online payment for products or for the access to payment-based services can be made by means of a range of (mobile) electronic payment systems - (M)EPS. Both the industrial sector and research community, mainly World Wide Web Consortium (W3C), are working on facilitating these payment methods on Web and supporting the multiple users on how they can select the suitable (M)EPS. However, to the best of our knowledge, there were no thorough studies considering consumer's preferences when they support multiple (M)EPS. To address this issue, we have performed a survey on an international participants (n=272) aiming to (i) developed a theoretical model to determine their preferences when they are supporting more than one (M)EPS, (ii) find the most valuable option according to them and (iii) determine the surrounding conditions that support their decision to use a specific (M)EPS. The theoretical framework of this study was based on the Technology Acceptance Model (TAM). According to our statistical analysis (Chi-square test), consumers that can pay using different (M)EPS during their online payment transaction, have a preferred payment system based on its security, fees, usefulness, and ease of use as well as on their favorite Web browser for these transactions. Factor analysis was also performed to identify factors that much influence the (M)EPS. Results revealed that the factors influencing online payment preferences differ from those involved in traditional payment methods. Our findings allowed, therefore, providing practical suggestions for supporting payment processes with Web browsers and the W3C payment Application Program Interface (API). However, the reference does not show the above claim limitations.
Foreign Reference:
Reference (CN 107578224 A) Chen Hai-cheng. Multi-platform Payment Method And Device. The invention claims a multi-platform payment method and device, comprising: generating an order based on the user purchasing the goods by the merchant of payment information and payment information to generate the collection request according to the order; receiving user end request response for the payee payment request and payment platform judges that said user terminal from the payment request of the type according to the type of the payment platform, invoking the corresponding payment platform and displaying trade order, the trade order comprises user terminal of payment amount; receiving user end through the corresponding payment platform returns the payment of the callback notification, the invention claims payment method and device for multi-platform polymerization, aggregating multiple payment platform to avoid conducting a payment transaction using a plurality of two-dimensional code.. However, the reference does not show the claim limitations above.
None of the prior art of record, taken individually or in combination, teach, interalia, the claimed invention as detailed in independent claims 1, 8 and 15, wherein the novelty of the claimed invention is in the combination of limitations and not in any single limitation.
Response to Arguments
Applicants’ arguments are moot in view of the new grounds of rejection necessitated by the amendments made to previously presented claims.
Applicant’s Argument #1
Applicants argue on page(s) 11-15 of applicants remarks that “related descriptions, and paragraphs [0017]-[0027] and [0029] of the Specification. Applicant respectfully submits that the amended independent claim 1 is eligible under 35 U.S.C. 101 using both the Step 2A, Prong Two test and Step 2A, Prong One test, especially in view of USPTO's August 4, 2025 Memorandum on "Reminders on evaluating subject matter eligibility of claims under 35 U.S.C. 101" ("Memorandum of 8/4/2025"), Appeal Review Panel's decision on Ex parte Guillaume Desjardins et al., Appeal 2024-000567 ("Ex parte Desjardins"), and the December 5, 2025 Memorandum titled "Advance notice of change to the MPEP in light of Ex parte Desjardins" ("Memorandum of 12/5/2025").” (See applicants’ remarks for more details).
Response to Argument #1
Applicants' arguments have been fully considered; however, the examiner respectfully disagrees.
While the amended claims are related to improvement to the business process, they are not an improvement to the field of machine learning or neural network methods.
Putting data through the machine learning model allows you to use better data, but this is not improving the field of the machine learning. This is different from the Desjardins case where improvement discussed in the specification is tied to the claim. The improvement in the claims of Desjardins is improving the machine learning model, because it is solving a technical problem of allowing the machine learning model to remember the past data process while working on a new data process.
Applicant’s Argument #2
Applicants argue on page(s) 16-18 of applicants remarks that “In fact, Memorandum of 8/4/2025 explicitly states that "Examiners are cautioned not to oversimplify claim limitations and expand the application of the 'apply it' consideration. Moreover, examiners are reminded that the 'apply it' consideration often overlaps with the improvements consideration." (Id. at 4) The Office Action also indicated that "Additionally, in Paragraph [0006] of the instant specification, by generating a redirection address to route a request that would, in existing systems, undergo multiple rounds of communication as described in Paragraphs [0004] and [0005] of the instant disclosure is not an improvement to the technological environment. The benefit of the claimed invention argued by applicants is something any type of filtering process will provide." (OA at 12)” (See applicants’ remarks for more details).
Response to Argument #2
Applicants' arguments have been fully considered; however, the examiner respectfully disagrees.
In Paragraph [0006] of the instant specification, by generating a redirection address to route a request that would, in existing systems, undergo multiple rounds of communication as described in Paragraphs [0004] and [0005] of the instant disclosure” is not persuasive as an improvement to the technological environment. The benefit of the claimed invention argued by applicants is something any type of filtering process will provide.
Applicants’ argument that the claims provide improved network monitoring because “the instant specification is directed to methods and systems in which "signaling overhead in the transaction process is saved" (Paragraph [0006] of the instant specification), among other benefits. This is achieved via the "redirection address" and “jump target” of claims 1, 8, and 15, which avoids the need for multiple rounds of communication found in existing systems and methods (see, Paragraphs [0004] and [0005] of the instant specification) It would be easy for any individual of skill in the art to determine that a technology which allows "signaling overhead" to be saved is also a technology that "avoids excess traffic volume on the network and hindrance of network performance" as described in the 2019 PEG example 40.”” is not persuasive as an improvement to the technological environment. The benefit of the claimed invention argued by applicants is something any type of filtering process and redirecting process will provide. For instance, an IRQ or interrupt request for cntrl+alt+del to restart the computer when a program is running on the computer is prioritized and as such the computer will jump or be redirected to shut down.
Redirection address is not novel, if you click on an ad in your email you are redirected to the ad from your email site. How does this improve technology or the technological environment?
Additionally, there is no support in the specification for “Efficient and automatic routing of network traffic”. Applicants are introducing these terms in the remarks, but they seem aspirational.
The facts of applicants’ claims are not similar to Example 42. In example 42, the claims are considered a practical application, because the claim recites a combination of additional elements including storing information, providing remote access over a network, converting updated information that was input by a user in a non-standardized form to a standardized format, automatically generating a message whenever updated information is stored, and transmitting the message to all of the users. The claim as a whole integrates the method of organizing human activity into a practical application. Specifically, the additional elements recite a specific improvement over prior art systems by allowing remote users to share information in real time in a standardized format regardless of the format in which the information was input by the user. Thus, the claim is eligible because it is not directed to the recited judicial exception (abstract idea). This is different from the current application.
Managing user’s payment experience is a certain method of organizing human activity. Applicants are solving a business problem not a technical problem.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
NPL Reference:
O. Tounekti, A. Ruiz-Martínez and A. F. Skarmeta Gómez, "Users Supporting Multiple (Mobile) Electronic Payment Systems in Online Purchases: An Empirical Study of Their Payment Transaction Preferences," in IEEE Access, vol. 8, pp. 735-766, 2020, doi: 10.1109/ACCESS.2019.2961785.
Foreign Reference:
(CN 107578224 A) Chen Hai-cheng.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NANCY PRASAD whose telephone number is (571)270-3265. The examiner can normally be reached M-F: 8:00 AM - 4:30 PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patricia Munson can be reached on (571)270-5396. 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.
/N.N.P/Examiner, Art Unit 3624 /PATRICIA H MUNSON/Supervisory Patent Examiner, Art Unit 3624
Prosecution Insights