DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 05/13/2026 has been entered.
Acknowledgements
This Office Action is in response to the RCE filed on 05/13/2026:
Claims 8, 13 and 15 were amended.
Claims 6 and 14 were canceled.
Claims 1-5 and 7 were previously withdrawn.
Claim 21 was newly introduced.
Claims 8-13 and 15-21 are pending.
Claims 8-13 and 15-21 were examined.
Claim Objections
Claims 8 and 15 are objected to because of the following informalities: Claims 8 and 15 recite "the key". Examiner interprets the language as "the encryption key". Examiner notes the only key recited by the claims is the encryption key. Appropriate correction is required.
Claim Rejections - 35 USC § 101
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 8-13 and 15-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
According to MPEP 2106 II, It is essential that the broadest reasonable interpretation (BRI) of the claim be established prior to examining a claim for eligibility. Further, MPEP 2103 I C establishes that the subject matter of a properly construed claim is defined by the terms that limit the scope of the claim when given their broadest reasonable interpretation. It is this subject matter that must be examined. Regarding the independent claims, claims 8 and 15 recite “an encrypted payload for a payment transaction comprising at least the following data: data of a payment device, information of the merchant, and information of the payment transaction”, language directed to non-functional descriptive material. See MPEP 2111.05. Lastly, claim 15 is a method claim and recites “wherein the payment facilitator server stores a unique ID and encryption key that links to an identification of the payment facilitator server...”; language directed to not positively recited method steps.
With respect to the Eligibility Step 1 of the Alice/Mayo two-part test of the subject matter eligibility analysis (see MPEP 2106), in the instant case, claims 8-13 and 21 are directed to a system, and claims 15-20 are directed to a method. Therefore, these claims fall within the four statutory categories of invention.
Following step 2A, prong one of the analysis, the language of the independent claims reciting an abstract idea are marked in bold below:
a. registering with a payment processing server, wherein the payment facilitator server stores a unique ID and encryption key that links to an identification of the payment facilitator server
b. receiving, by a payment facilitator server within a restricted computer network firewall, an encrypted payload for a payment transaction comprising at least the following data: data of a payment device, information of the merchant, and information of the payment transaction, the encrypted payload having been encrypted using the encryption keyc. decrypting, by the payment facilitator server, the encrypted payload using the key to form a decrypted payload comprising the datad. after decryption of the encrypted payload, transmitting, by the payment facilitator server, the decrypted payload in one payment packet to a payment processing server outside the restricted computer network firewall, wherein the payment packet comprises the datae. receiving, by the payment facilitator server, a transaction ID and an acknowledgement indicative of a success of the transaction
Therefore, the portions highlighted in bold above recite intermediary settlement, which is an abstract idea grouped within the certain methods of organizing human activity grouping of abstract ideas in prong one of step 2A. The claims are grouped within certain methods of organizing human activity because the steps recited describe the fundamental economic practice of processing of payments and the commercial or legal interaction of processing information through a clearing-house. In situations like this where a series of steps recite judicial exceptions, examiners should combine all recited judicial exceptions and treat the claim as containing a single judicial exception for purposes of further eligibility analysis. See MPEP 2106.04 and 2106.05(II). Thus, the language identified in the certain methods of organizing human activity groupings were considered as a single abstract idea. Accordingly, the claims recite an abstract idea.
With respect to step 2A, prong two of the analysis, this judicial exception is not integrated into a practical application. Specifically, with respect to using a payment facilitator to perform the recited steps/functions, this additional element perform the steps or functions such as: “registering…”, “receiving… payload…”, “decrypting… payload…”, “transmitting… payload…”, “receive… ID and acknowledgement… (Claim 8)”. This additional element is recited at a high-level of generality such that it represents no more than mere instructions to apply the exception using a generic computer component, which only serves to use computers as a tool to perform the abstract idea. Therefore, this element does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional element(s) of a payment processing server, a wallet application, a merchant, a restricted computer network firewall amount to generally linking the use of the judicial exception to a particular technological environment or field of use. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, following the analysis of step 2A, prong two, the claims are still directed to an abstract idea.
With respect to step 2B of the analysis, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into a practical application, the additional computer elements, such as a payment facilitator, a payment processing server, a wallet application, a merchant, a restricted computer network firewall. The a payment facilitator performs the steps/functions of “registering…”, “receiving… payload…”, “decrypting… payload…”, “transmitting… payload…”, “receive… ID and acknowledgement… (Claim 8)”, and amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept beyond the abstract idea of intermediary settlement. The additional element(s) of a payment processing server, a wallet application, a merchant, a restricted computer network firewall amount to generally linking the use of the judicial exception to a particular technological environment or field of use. As discussed above, taking the claim elements separately, these additional elements perform the steps or functions that correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of intermediary settlement. Therefore, the independent claims are not eligible.Examiner notes that, for elements recited in the dependent claims which were previously analyzed as additional elements of the independent claims above (i.e. a payment facilitator), the assessment of these elements under step 2A and step 2B for the dependent claims is inherited from the analysis of the independent claims and omitted for brevity, unless noted by Examiner below. Dependent claims 9-13 and 16-21 further recite the following additional language, in which elements which merely further define the identified abstract idea are marked in bold below:
f) wherein the payment facilitator server is configured to: receive a token from a URL of a webpage, a merchant ID, and an amount for the transaction; and append the token to the URL as a fragment to the URL. g) wherein the payment facilitator server is configured to process the webpage; and execute a function call to a payment processor. h) wherein the payment facilitator server is configured to facilitate the transaction for a consumer and the merchant. i) wherein the encrypted payload includes at least the following data: data of a payment device, information of the merchant, and information of the payment transaction. j) wherein/comprising the restricted computer network firewall limits outbound transactions except for permitted URL sites, wherein the encrypted payload is transmitted via a URL formatted address, and wherein the URL formatted address is one of the permitted URL sites. k) wherein the payment facilitator server is configured to store a unique ID and encryption key. l) wherein the encrypted payload contains at least a primary account number (PAN) and an expiration date of a payment device.
With respect to the eligibility analysis of claims 9 and 16, Item f) above introduces the additional elements/functions of loading a webpage, retrieve a token and appending token to URL. This language further elaborates the abstract idea of intermediary settlement identified in the analysis of independent claims 8 and 15. Therefore, this language does not significantly alter the analysis with respect to the independent claims 8 and 15. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer. Examiner notes the claim further detail the mental process of collecting information, analyzing it, and displaying certain results of the collection and analysis.
With respect to the eligibility analysis of claims 10 and 17, Item g) above introduces the additional elements/functions of processing a webpage and executing a call. This language further elaborates the abstract idea of intermediary settlement identified in the analysis of independent claims 8 and 15. Therefore, this language does not significantly alter the analysis with respect to the independent claims 8 and 15. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer. Examiner notes the claim further detail the mental process of collecting information, analyzing it, and displaying certain results of the collection and analysis.
With respect to the eligibility analysis of claims 11 and 18, item h) above introduces the additional elements/functions of facilitating a transaction. This language further elaborates the abstract idea of intermediary settlement identified in the analysis of independent claims 8 and 15. Therefore, this language does not significantly alter the analysis with respect to the independent claims 8 and 15. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer. Examiner notes the claims further detail the fundamental economic practice of processing payments.
With respect to claim 12, the claim recites item i) above, language which does not introduce additional elements/functions. The additional language merely represents statements directed to directed to non-functional descriptive material by describing what the payload "includes" (i.e. data). Those statements are insufficient to significantly alter the eligibility analysis. This language further elaborates the abstract idea of intermediary settlement identified in the analysis of independent claims 8 and 15. Therefore, this language does not significantly alter the analysis with respect to the independent claims 8 and 15. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because no further additional elements/functions are introduced to the BRI of the claims. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because no further additional elements/functions are introduced to the BRI of the claims.
With respect to claims 13 and 20, the claims recite item j) above, language which does not introduce additional elements/functions. The additional language merely represents statements directed to directed to non-functional descriptive material by describing what a URL formatted address is (i.e. a type of data). Those statements are insufficient to significantly alter the eligibility analysis. This language further elaborates the abstract idea of intermediary settlement identified in the analysis of independent claims 8 and 15. Therefore, this language does not significantly alter the analysis with respect to the independent claims 8 and 15. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because no further additional elements/functions are introduced to the BRI of the claims. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because no further additional elements/functions are introduced to the BRI of the claims. Examiner notes the language directed to the "restricted computer network firewall" merely further describe the additional element identified and analyzed in conjunction with the independent claims
With respect to the eligibility analysis of claim 19, item k) above introduces the additional elements/functions of storing an ID and a key. This language further elaborates the abstract idea of intermediary settlement identified in the analysis of independent claims 8 and 15. Therefore, this language does not significantly alter the analysis with respect to the independent claims 8 and 15. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer. Examiner notes the claim further detail the mental process of collecting information
With respect to claim 21, the claim recites item l) above, language which does not introduce additional elements/functions. The additional language merely represents statements directed to directed to non-functional descriptive material by describing what the payload "contains" (i.e. data). Those statements are insufficient to significantly alter the eligibility analysis. This language further elaborates the abstract idea of intermediary settlement identified in the analysis of independent claims 8 and 15. Therefore, this language does not significantly alter the analysis with respect to the independent claims 8 and 15. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because no further additional elements/functions are introduced to the BRI of the claims. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because no further additional elements/functions are introduced to the BRI of the claims.
Therefore, while the additional language f) - l) of dependent claims 9-13 and 16-21 slightly modify the analysis provided with respect to independent claims 8 and 15, these additional elements/functions are insufficient to render the dependent claims eligible, as detailed above. Therefore, these dependent claims are also ineligible.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 8-13 and 15-21 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 8 and 15 were amended to recite “decrypt the encrypted payload using the key”. The specification as filed recites, inter alia:
“[0046] In one embodiment, the payment facilitator 124 may decrypt the token and the decrypted data packet may include the PAN that it needs to send into the server or payment processor 102. As one may recall from the above, the tokenization may occur via the ARM 202 in FIG. 2...[0057]In one embodiment and as discussed above, the payment facilitator 124 may decrypt the encrypted PAN and may send the data packet..”
Therefore, the specification as filed does not recite using the encryption key to decrypt the encrypted payload. In other words, the specification is silent regarding the particular manner in which the payload is decrypted (i.e. decryption using the same encryption key, as claimed). Therefore, the specification as filed does not provide sufficient written description for the claimed language (see MPEP 2161.01). In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed. Dependent claims 9-13 and 16-21 are also rejected since they depend on claims 8 and 15, respectively.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 15-21 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 15 recites “the payment facilitator server” in line 3. There is insufficient antecedent basis for this language in the claim. Dependent claims 16-21 are also rejected since they depend on claim 15.
Claims 8, 10-13, 15 and 18-21 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Dooley et al. (US 2018/0232728 A1), hereinafter Dooley, in view of Fleishman et al. (US 2015/0278816 A1), hereinafter Fleishman and in view of Angrish et al. (US 2015/0178862 A1), hereinafter Angrish.
With respect to claims 8 and 15, Dooley teaches a computer-implemented system for streamlining encryption payload of a card transaction from a merchant inside a restricted computer network firewall comprising: a payment facilitator server within the restricted computer network firewall coupled between a payment processing server and a wallet application (see Fig. 1, issuer processor 140, paragraphs [0034] and [0035]); and a computer-implemented method for limiting a number of encrypted transaction data packet transmission between a merchant and a server (Payment tokenization using encryption) comprising:
registering with a payment processing server, wherein the payment facilitator server stores a unique ID and encryption key that links to an identification of the payment facilitator server (see Fig. 1, enrollment request, paragraph [0036]: “At operation 104, the issuer processor 140 transmits the enrollment request to the issuer 150. Generally, after the enrollment request is received at the issuer 150, the credentials and domain information are verified, and a payment token is generated using encryption..."; paragraph [0037]: “In accordance with some implementations, the payment token may be generated using issuer-specific token keys. As such, the issuer 150 has control over the token keys and can share the token keys, if desired, with entities with which the issuer 150 has a trusted relationship. Token keys can be used to tokenize payment account identifiers into payment tokens and detokenize payment tokens back into payment account identifiers. Token keys can be used in conjunction with encryption functions and provided by standard hardware/software encryption platforms, such as a HSM.”; paragraph [0038]: “The encryption used in accordance with implementations of the present disclosure generates a payment token that is unique..." Examiner notes the unique ID is the payment token and the token keys are the encryption key, used to tokenize and detokenize payment tokens.);
receiving, by a payment facilitator server..., an encrypted payload for a payment transaction comprising at least the following data: data of a payment device, information of the merchant, and information of the payment transaction, the encrypted payload having been encrypted using the encryption key; (see Fig. 2, paragraph [0045]: “After a payment token has been generated for a payment account identifier, the payment token may be employed during a payment transaction by using decryption to detokenize the payment token…"; paragraph [0046]: “At operation 201, the user 110 initiates a payment transaction using payment token generated, for instance, in accordance with the process 100 of FIG. 1...": paragraph [0047]: “...At operation 204, the acquirer aggregator 130 routes the payment transaction request to an appropriate issuer processor 140...”);
decrypting, by the payment facilitator server, the encrypted payload using the key to form a decrypted payload comprising the data (see paragraph [0048]: “The payment token in the payment transaction request is detokenized to obtain a corresponding payment account identifier and, in some implementations, domain information. The detokenization includes decrypting the payment token using the token keys employed to generate the payment token (e.g., during the process 100 of FIG. 1). This detokenization can be performed by or on behalf of the issuer processor 140 or the issuer 150. For instance, in some implementations, the issuer processor 140 requests the HSM 160B to detokenize the payment token at operation 204A. The HSM 160B can also verify the EMV cryptography, if applicable. In such implementations, the HSM 160B responds to the issuer processor 140 with the original payment account identifier and, in some instances, domain information...”);
after decryption of the encrypted payload, transmitting, by the payment facilitator server, the decrypted payload in one payment packet to a payment processing server..., wherein the payment packet comprises the data (see paragraph [0048]: “The issuer processor 140 would then transmit the payment transaction request with the payment account identifier (and domain information, if applicable) to the issuer 150 for authorization of the payment transaction.”); and
receiving, by the payment facilitator server, a transaction ID and an acknowledgement indicative of a success of the transaction (see paragraph [0050]: “In either implementation, after the issuer 150 authorizes the payment transaction based on the payment account identifier and/or domain information, the issuer 150 responds back to the issuer processor 140 with an approval transaction that includes the payment account identifier or the payment token, as shown at operation 206”).
Dooley does not explicitly disclose a system and method comprising: the payment facilitator server is within a restricted computer network firewall; and the payment processing server is outside the restricted computer network firewall; the computer network firewall is "restricted".
However, Fleishman discloses a system and method (Online payment transfer and identity management system and method) comprising:
the payment facilitator server is within a restricted computer network firewall; and the payment processing server is outside the restricted computer network firewall (see paragraph [0082]).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the several isolation and security zones with restricted access among zones as disclosed by Fleishman in the system and method of Dooley, the motivation being to ensure the security of customer data. (see Fleishman, paragraph [0082]).
The combination of Dooley and Fleishman does not explicitly disclose a system and method comprising: the computer network firewall is "restricted".
However, Angrish discloses a system and method (Mobile payments) comprising:
the computer network firewall is "restricted" (see paragraph [0048]: "In some embodiments, merchant LAN 108 may include or incorporate a firewall or other protective computing device that regulates the entry of messages, requests or command from computers that are on or outside of the public internetwork 120.").
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the firewall or other protective computing devices as disclosed by Angrish in the system and method of Dooley and Fleishman, the motivation being to regulate the entry of messages, requests or command from computers that are on or outside of a public network (see Angrish, paragraphs [0048] and [0081]).
With respect to the BRI of the claims, Examiner notes that claims 8 and 15 recite “an encrypted payload for a payment transaction comprising at least the following data: data of a payment device, information of the merchant, and information of the payment transaction”, language directed to non-functional descriptive material. See MPEP 2111.05. In addition, claim 15 is a method claim and recites “wherein the payment facilitator server stores a unique ID and encryption key that links to an identification of the payment facilitator server...”; language directed to not positively recited method steps.
With respect to claims 9 and 16, the combination of Dooley, Fleishman and Angrish teaches all the subject matter of the system and method as described above with respect to claims 8 and 15. The combination of Dooley, Fleishman and Angrish does not explicitly teach a system and method wherein the payment facilitator server is configured to: receive a token from a URL of a webpage, a merchant ID, and an amount for the transaction; and append the token to the URL as a fragment to the URL. However, Starai discloses a system and method (Transmission of sensitive customer information during electronic-based transactions) wherein the payment facilitator server is configured to: receive a token from a URL of a webpage, a merchant ID, and an amount for the transaction; and append the token to the URL as a fragment to the URL (see paragraph [0019]: “In step 112 the merchant server 12 generates and transmits to PC 10 by communication 26 an HTML form to collect payment details from the customer, where the form points to the "form URL" received from the gateway 14. In step 114 the customer views the received form from the merchant server 12 which includes the "form URL" contained requested credit card information, e.g. the credit cardholder's name, credit card number, expiration date, cvv number, etc.”; paragraph [0020]: “FIG. 4 illustrates a second series of exemplary steps associated with the electronic transaction. At the beginning of these steps, the customer of PC 10 has received the HTML form from the merchant server 12. In step 120 the customer completes the HTML form and transmits by communication 30 the completed form with credit card information to the payment gateway 14. In step 122 a determination is made by the gateway 14 of whether the submission is valid, e.g. is the credit card information and token-ID valid? A NO determination by step 122 results in gateway 14 storing an error message associated with the token-ID in step 124. A YES determination by step 122 results in the gateway 14 encrypting and storing the sensitive credit card information in association with the assigned token-ID in step 126. In step 128 Gateway 14 transmits in communication 32 a request to the PC 10 to utilize the "redirect URL" that points to the address of the merchant server 12. In step 130 the PC 10 is redirected at communication 34 in accordance with the redirect URL address containing the unique token-ID to the merchant server 12.”). Regarding the BRI of the claims, Examiner notes that claim 16 is a method claim and recites “wherein the payment facilitator server is configured to: receive a token from a URL of a webpage, a merchant ID, and an amount for the transaction; and append the token to the URL as a fragment to the URL....”; language directed to not positively recited method steps. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 12, the combination of Dooley, Fleishman and Angrish teaches all the subject matter of the system as described above with respect to claim 8. Furthermore, Dooley discloses a system wherein the encrypted payload includes at least the following data: data of a payment device, information of the merchant, and information of the payment transaction (see paragraph [0032]: “At a minimum, the credentials provided with the enrollment request include the payment account identifier for the payment instrument. As used herein, “credentials” associated with a payment instrument can also include other attributes and/or parameters that govern outcome of processing transactions for the payment instrument. Such credentials may include card limits, card balances, card status (e.g., open, closed, hot card, etc.), temporary card block and/or other credentials. In some implementations, the enrollment request also includes domain information. As used herein, “domain information” corresponds to attributes and/or parameters that govern access by entities in a particular access point (e.g., user device, internet browser, mobile client application, e-commerce URL, etc.) to services such as tokenization and detokenization during payment processing. For example, the domain information can specify a particular user device identifier (e.g., MAC address, IP address, cookie, mobile device identifier, etc.) or channel identifier (e.g., website URL, e-commerce URL, etc.).”;). The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claims 13 and 20, the combination of Dooley, Fleishman and Angrish teaches all the subject matter of the system and method as described above with respect to claims 8 and 15. Furthermore, Angrish discloses a system and method wherein/comprising the restricted computer network firewall limits outbound transactions except for permitted URL sites, wherein the encrypted payload is transmitted via a URL formatted address, and wherein the URL formatted address is one of the permitted URL sites (see paragraph [0048]: "...As a result, typically the service provider computer system 130 cannot issue HTTP calls to the payment logic 118, payment plug-in 114, or other functional units of the merchant booking computer 110 and/or merchant POS computer 112. Therefore, in some embodiments, the elements of FIG. 1 are configured to use socket level third party protocols and messaging systems to communicate with the merchant POS computer 112 and other units that are behind firewalls. In one embodiment, HTTP long polling is used to implement a publish-subscribe mechanism. In this embodiment, payment plug-in 114, which resides on the merchant POS computer 112 within the restaurant firewall, subscribes to a channel that is hosted by a third-party server such as the service provider computer system 130. The booking application 132 and/or payment application 134 of computer system 130 sends messages to the in-restaurant POS plug-in 114 by publishing to this channel. Pubnub is an example of one third-party service providing this functionality."; Fig. 4, paragraph [0081]: "In an embodiment, at block 416, a success or failure message is received from the payment network gateway computer 140 at the service provider computer system 130. Operations performed in response to a failure of the payment transaction are not critical and may vary in various embodiments. If the payment transaction was successful, then at block 418, an electronic receipt is generated and communicated both to the merchant POS computer 112 and to the mobile computing device 102. For example, the e-receipt may be sent to the payment plug-in 114 and then communicated from the plug-in to the merchant POS computer 112 using an appropriate request or message. Concurrently the e-receipt is sent over the network to the mobile app 103."). Regarding the BRI of the claims, Examiner notes that claim 20 is a method claim and recites “wherein the restricted computer network firewall limits outbound transactions except for permitted URL sites, wherein the encrypted payload is transmitted via a URL formatted address, and wherein the URL formatted address is one of the permitted URL sites....”; language directed to not positively recited method steps. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 19, the combination of Dooley, Fleishman and Angrish teaches all the subject matter of the method as described above with respect to claim 15. Furthermore, Dooley discloses a method wherein the payment facilitator server is configured to store a unique ID and encryption key (see paragraph [0040]: “At operation 105, the issuer 150 responds to the enrollment request by providing an issuer approval and the generated payment token to the issuer processor 140. In some implementations, the issuer 150 may also provide issuer-specific, EMV-related cryptographic keys to the issuer processor 140. Such cryptographic keys may be useful with domain-specific credentials that represent an NFC-based provisioning request for securely associating and storing payment tokens within a secure element or HCE-equivalent.”). Regarding the BRI of the claim, Examiner notes that claim 19 is a method claim and recites “wherein the payment facilitator server is configured to store a unique ID and encryption key....” language directed to not positively recited method steps. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 21, the combination of Dooley, Fleishman and Angrish teaches all the subject matter of the system as described above with respect to claim 8. Furthermore, Dooley discloses a system wherein the encrypted payload contains at least a primary account number (PAN) and an expiration date of a payment device (see paragraph [0032]: “At a minimum, the credentials provided with the enrollment request include the payment account identifier for the payment instrument. As used herein, “credentials” associated with a payment instrument can also include other attributes and/or parameters that govern outcome of processing transactions for the payment instrument. Such credentials may include card limits, card balances, card status (e.g., open, closed, hot card, etc.), temporary card block and/or other credentials. In some implementations, the enrollment request also includes domain information. As used herein, “domain information” corresponds to attributes and/or parameters that govern access by entities in a particular access point (e.g., user device, internet browser, mobile client application, e-commerce URL, etc.) to services such as tokenization and detokenization during payment processing. For example, the domain information can specify a particular user device identifier (e.g., MAC address, IP address, cookie, mobile device identifier, etc.) or channel identifier (e.g., website URL, e-commerce URL, etc.).”).
Claims 10, 11, 16 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Dooley (US 2018/0232728 A1), in view of Fleishman (US 2015/0278816 A1), in view of Angrish (US 2015/0178862 A1), and in view of Starai (US 2010/0241565 A1)
With respect to claims 10 and 17, the combination of Dooley, Fleishman and Angrish teaches all the subject matter of the system and method as described above with respect to claims 9 and 16. The combination of Dooley, Fleishman and Angrish does not explicitly teach a system and method wherein the payment facilitator server is configured to process the webpage; and execute a function call to a payment processor. However, Starai discloses a system and method (Transmission of sensitive customer information during electronic-based transactions) wherein the payment facilitator server is configured to process the webpage; and execute a function call to a payment processor (see paragraph [0021]: “FIG. 5 illustrates a third series of exemplary steps associated with the electronic transaction... A YES determination by step 158 results in the gateway 14 in association with the processor system 16 processing the credit card payment request in step 160. It should be noted that the actual processing of the debit to be made to the account of the cardholder associated with the transaction did not begin until specifically requested by the merchant server 12 in step 150. In step 162 a determination is made of whether the transaction processed successfully, i.e. was the cardholder's account successfully debited with the amount associated with the transaction? A NO determination by step 162 results in an error response being transmitted to the merchant at step 154. A YES determination by step 162 results in the merchant server 12 being transmitted a message indicating successful transaction completion in step 164. The communication 42 represents either the transmission of an error message or successful completion from the gateway 14 to the merchant server 12.”).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the URLs and associated token-IDs as disclosed by Starai in the system and method of Dooley, Fleishman and Angrish, the motivation being to providing the merchant with the ability to control the initial interaction with the gateway 14 without having received a customer transaction request (see Starai, paragraph [0022]).
Regarding the BRI of the claims, Examiner notes that claim 17 is a method claim and recites “wherein the payment facilitator server is configured to process the webpage; and execute a function call to a payment processor....”; language directed to not positively recited method steps.
With respect to claims 11 and 18, the combination of Dooley, Fleishman and Angrish teaches all the subject matter of the system and method as described above with respect to claims 10 and 17. Furthermore, Dooley discloses a system and method wherein the payment facilitator server is configured to facilitate the transaction for a consumer and the merchant (see Fig. 1, issuer processor 140 between merchant 220 and issuer 150 paragraphs [0034] and [0035]). Regarding the BRI of the claims, Examiner notes that claim 18 is a method claim and recites “wherein the payment facilitator server is configured to facilitate the transaction for a consumer and the merchant....” language directed to not positively recited method steps. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the parent claims.
Response to Arguments/Amendments
Claim rejections - 35 USC § 101
Applicant’s amendments and arguments (see remarks, pages 6-9, filed on 05/13/2026), with respect to the rejection of claims 8-20 under 35 USC § 101 as being directed to an abstract idea have been fully considered but are not persuasive. With respect to the eligibility analysis, Applicant asserts “the Office Action stripped each limitation of its technological context, the specific cryptographic operations, the specific network architecture, the specific firewall boundary, and characterized the resulting abstracted description as an abstract idea”. Examiner respectfully disagrees. Examiner is in position that every aspect of the BRI of the claims was addressed in the analysis, following the criteria established by the analysis in MPEP 2106. With respect to Step 2A Prong 1, Applicant asserts “the Office Action's characterization of the decryption step as a "mental process" is incorrect. The Office Action grouped the claim steps, including decrypting the encrypted payload, within "mental processes" because they describe collecting information, analyzing it, and displaying certain results of the collection and analysis, which is a concept that can be performed in the human mind or by pen and paper. These claim recitations cannot practically be performed by a human mind or by pen and paper”. Examiner respectfully disagrees. MPEP 2106.04(a)(2) C III establishes: "The courts consider a mental process (thinking) that "can be performed in the human mind, or by a human using a pen and paper" to be an abstract idea. CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372, 99 USPQ2d 1690, 1695 (Fed. Cir. 2011).". One of ordinary skill would reasonably recognize that encryption and decryption mechanisms can be performed manually using simple ciphers or pen-and-paper algorithms. The process is the same in principle: encryption converts readable text (plaintext) into an unreadable form (ciphertext) using a key, while decryption reverses this process to recover the original text. In fact, encryption and decryption have roots that stretch back thousands of years, even before computers existed. Therefore, Examiner is unpersuaded by Applicants' arguments directed to eligibility under Step 2A, prong one. With respect to Step 2A Prong 2 , Applicant asserts “Under Step 2A, Prong 2, the Office Action argued that the claim limitations do not integrate the abstract concept into a practical application. Applicant disagrees... Claim 8 provides the improvement to the existing technology. Paragraph [0047] confirms that this streamlined transmission approach reduces the frequency of passing between the merchants and the server and reduces the time needed for approval. This is a measurable technical benefit, reduced transmission frequency and reduced processing latency through a constrained network boundary, that results directly from the specific architectural design of the claims. It is an improvement to the functioning of the networked system, not merely the use of a computer to perform an abstract economic task.”. Examiner respectfully disagrees. MPEP 2106.04(d)(1) establishes: "While the courts usually evaluate "improvements" as part of the "directed to" inquiry in part one of the Alice/Mayo test (equivalent to Step 2A), they have also performed this evaluation in part two of the Alice/Mayo test (equivalent to Step 2B). See, e.g., BASCOM Global Internet v. AT&T Mobility LLC, 827 F.3d 1341, 1349-50, 119 USPQ2d 1236, 1241-42 (Fed. Cir. 2016). However, the improvement analysis at Step 2A Prong Two differs in some respects from the improvements analysis at Step 2B. Specifically, the "improvements" analysis in Step 2A determines whether the claim pertains to an improvement to the functioning of a computer or to another technology without reference to what is well-understood, routine, conventional activity. That is, the claimed invention may integrate the judicial exception into a practical application by demonstrating that it improves the relevant existing technology although it may not be an improvement over well-understood, routine, conventional activity. It should be noted that while this consideration is often referred to in an abbreviated manner as the "improvements consideration," the word "improvements" in the context of this consideration is limited to improvements to the functioning of a computer or any other technology/technical field, whether in Step 2A Prong Two or in Step 2". It appears Applicant places undue weight into the BRI of the claims. Particularly, Examiner notes the claims do not involve "restrictive computer network firewalls to restrict network data flows to and from the country" as quoted by Applicant from paragraph [0004]. Examiner also notes the claims do not encompass "modify the data packet to be streamlined so that the consumer may not realize the difference in how the server handles the transaction", as quoted by Applicant from paragraph [0029], as the claims do not require a modification of a package but rather processing a transaction. Further, the improvements identified in paragraph [0047] do not appear to be encompassed by the subject matter described in the BRI of the claims. Specifically, the asserted improvement appears to be directed to improvements over a hypothetical transaction not encompassed by the claims. Those do not appear to be improvements to technology, but rather to business processes. Therefore, Examiner is unpersuaded by Applicants' arguments directed to eligibility under Step 2A, prong two. Therefore, Examiner is unpersuaded by Applicants' arguments directed to eligibility under Step 2A, prong two. With respect to Step 2B, Applicant asserts “The Office Action found at Step 2B that the additional computer elements, payment facilitator server, payment processing server, wallet application, merchant, restricted computer network firewall, amount to no more than mere instructions to apply the exception using generic computer components, and that, viewed as a whole, the combination of elements merely recites the concept of payment transactions. This analysis is legally deficient in a fundamental respect: the Office Action evaluated the elements individually, found each to be generic, and then stated that the combination "merely recites the concept of payment transactions." This is not an analysis of the ordered combination, it is a restatement of the Prong 1 abstract idea identification applied as a label to the combination without any substantive engagement with whether the specific arrangement of elements is conventional in the art.”. Examiner respectfully disagrees. Examiner is unpersuaded by Applicant's arguments since the analysis was provided with an evaluation of the additional elements both individually and in combination. Examiner notes Applicant does not identify which combination of elements Applicant considers to amount to significantly more than the judicial exception itself. Therefore, Examiner is in the position that the amended claims are still directed to an abstract idea without significantly more, as detailed in the analysis above. The new and amended claims do not offer significantly more than the abstract idea itself, therefore the claims are still rejected under 35 USC § 101 as further detailed above.
Claim rejections - 35 USC § 112(a)
Applicant’s amendments and arguments (see remarks, pages 9 and 10, filed on 05/13/2026), with respect to the rejection of claims 8-20 under 35 USC § 112(a) have been fully considered. Examiner finds Applicant's arguments persuasive, therefore the rejection was withdrawn.
Claim rejections - 35 USC § 112(b)
Applicant’s amendments and arguments (see remarks, page 10, filed on 05/13/2026), with respect to the rejection of claims 8-20 under 35 USC § 112(b) have been fully considered. Examiner finds Applicant's arguments persuasive, therefore the rejection was withdrawn.
Claim rejections - 35 USC § 103
Applicant’s amendments and arguments (see remarks, pages 10-13, filed on 05/13/2026), with respect to the rejection of claims 8-20 under 35 USC § 103 have been fully considered , but are moot because the arguments do not apply to the reference being used in the current rejection of the amended claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Montero et al. (US 2012/0323735 A1) disclose payment system and clearinghouse of internet transactions, including token URLs.
Le Saint et al. (US 2016/0065370 A1) disclose methods for secure cryptogram generation, including a “single use key” (SUK), which is a LUK that can be only used once. For example, a SUK may be used to encrypt and/or decrypt data related to a single transaction. In some embodiments, a SUK can be derived from a LUK.
Shauh et al. (US 2017/0046671 A1) disclose online mobile payment system and method using a QR code, including a merchant module including a QR code generator to generate a QR code associated with the online purchase and a mobile device module including a QR code reader to decipher the information carried by the QR code and a mobile payment interface, coupling module functions with a mobile payment core within the mobile device.
Voldman (US 2018/0268411 A1) discloses apparatus and method for payment authorization and authentication based tokenization, including a payment authorization server operating transparently to the issuer. When the payment authorization server authenticates a tokenized transaction message it generates a corresponding untokenized transaction message in which at least some of the cardholder information linked to the account identifier, such as the card account number, cardholder name, etc. is substituted back in to replace the tokenized data.
Ozvat et al. (US 2014/0040145 A1) disclose systems and methods for distributed enhanced payment processing, including a tokenizer encryption service decrypting a payment token to retrieve account numbers, expiration dates, group ID, and optionally the generation of an updated token.
Elgaard et al. (WO 2017080755 A1) disclose a method, apparatus, system, and computer readable medium for processing an electronic payment transaction with improved security, including an environment component configured to provide a highly secure environment. The perimeter security is configured to be enforced by a double layer of firewalls (one gateway level and one application level). The environment component is configured such that all network traffic inside the firewalls is based on IPsec (VPN).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDUARDO D CASTILHO whose telephone number is (571)270-1592. The examiner can normally be reached Mon-Fri 8-5.
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, Patrick McAtee can be reached at (571) 272-7575. 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.
/EDUARDO CASTILHO/Primary Examiner, Art Unit 3698
Prosecution Insights