Detailed Action
Continued Examination Under 37 CFR 1.114
A request for continued examination (RCE) 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 April 7, 2026 has been entered.
Acknowledgements
This action is in reply to the RCE filed on April 7, 2026.
Claims 3-4, 10-13, and 20 are cancelled.
Claims 1-2, 5-9, and 14-19 are pending.
Claims 1-2, 5-9, and 14-19 are examined.
This Office Action is given Paper No. 20260430 for references purposes only.
Claim Objections
Claim 9 recites “from a merchant.” Examiner assumes that Applicant intended “from the merchant.” Appropriate correction is required.
Claim 19 recites “machine executable instructions.” Examiner assumes that Applicant intended “the second machine executable instructions.” 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-2, 5-9, and 14-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 2A Prong 1: The claims recite an abstract idea of determining whether a data breach occurred based on received information matching stored information, which is a certain method of organizing human activity (e.g. 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).
Claim 1, representative of claims 9 and 18, includes the following limitations:
Receiving a token request, wherein the token request comprises user contact information and a merchant identifier;
Generating a token associated with the merchant identifier;
Mapping the token to the user contact information and the merchant identifier;
Receiving a second token and a second merchant identifier;
Mapping the second token and the second merchant identifier to the user contact information;
Determining a validation of the mapping of the second token and the second merchant identifier to the user contact information;
Determining a data breach occurred based on an invalid mapping;
Prohibiting communications with an account holder based on the invalid mapping.
Step 2A Prong 2: The claim limitations recite the following additional elements that are beyond the judicial exception:
A payment network computer;
A client device;
A token server computer;
Storing the token, the user contact information, and the merchant identifier in a database.
These additional elements are not indicative of integration into a practical application because:
They add the words “apply it” (or an equivalent) with the judicial exception, or are mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea. See MPEP 2106.05(f).
They add insignificant extra-solution activity to the judicial exception. Note that “extra-solution activity” can be understood as activities incidental to the primary process or product that are merely a nominal or tangential addition to the claim. Extra-solution activity can include both pre-solution and post-solution activity. An example of pre-solution activity is a step of gathering data for use in a claimed process. An example of post-solution activity is an element that is not integrated into the claim as whole. See MPEP 2106.05(g).
Step 2B: The claim limitations do not recite additional elements, or an ordered combination of additional elements, that are sufficient to amount to significantly more than the judicial exception.
As discussed with respect to step 2A prong 2 above, the additional elements of “a payment network computer”, “a client device”, and “a token server computer” are mere instructions to apply an exception, and do not integrate a judicial exception into a practical application at step 2A or provide an inventive concept at step 2B.
According to the 2019 PEG, a conclusion that an additional element is mere instructions to apply an exception under step 2A should be re-evaluated at step 2B. Thus, the additional elements of “a payment network computer”, “a client device”, and “a token server computer” are re-evaluated to determine whether they constitute significantly more. Examiner finds that the additional elements of “a payment network computer”, “a client device”, and “a token server computer” are simply the use of a computer in its ordinary capacity and do not provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262 and MPEP 2106.05(f). For example, the additional elements only provide a result-oriented solution and lack details as to how the computer performs the modifications, which is equivalent to “apply it”. See Alice Corp. v. CLS Bank, 134 S. Ct. 2347, 2357 and MPEP 2106.05(f).
As discussed with respect to step 2A prong 2 above, the additional element of “storing the token, the user contact information, and the merchant identifier in a database” is extra solution activity that does not integrate a judicial exception into a practical application at step 2A or provide an inventive concept at step 2B.
According to the 2019 PEG, a conclusion that an additional element is insignificant extra solution activity under step 2A should be re-evaluated at step 2B. The limitation “storing the token, the user contact information, and the merchant identifier in a database” is re-evaluated to determine whether it constitutes well-understood, routine, and conventional activity in the field. The “storing of data” is well-understood, routine, and conventional in the field. See Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 and MPEP 2106.05(d). Thus, a conclusion that the limitation “storing the token, the user contact information, and the merchant identifier in a database” is well-understood, routine, and conventional is supported under Berkheimer.
Therefore, when considering all the additional claim elements both individually and as an ordered combination, Examiner finds that the claim does not amount to significantly more than the exception.
The dependent claims fail to cure this deficiency and are rejected accordingly.
Claim 2 recites authorizing communications based on a valid mapping, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
Claim 5 recites notifying the network service provider of the data breach, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
Claim 6 recites notifying a merchant of the data breach, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
Claim 7 recites determining that the token associated with the merchant identified in the token request is not associated with the second merchant identifier, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
Claim 8 recites notifying a merchant associated with the token of the data breach, and notifying a merchant not associated with the token of the data breach, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 5-9, and 14-20 are rejected under 35 U.S.C. 103(a) as being unpatentable over Bayat (US 2022/0198036) in view of Li et al. (US 8,655,719).
Claims 1, 18
Bayat discloses:
receiving, by a payment network computer, a token request (purchase order, see [0075]) from an application (buyer app, see [0074]) running on a client device (customer device, see [0075]), wherein the token request comprises user contact information (e.g. recipient information, see [0075]) and a merchant identifier (merchant data field, see [0078]);
generating, by a token server computer, a token (generate the token, see [0089]) associated with the merchant identifier;
mapping, by the payment network computer, the token (token, see [0089]) to the user contact information (recipient information, see [0089]) and the merchant identifier (unique merchant identifier, see [0090]);
storing, by the payment network computer, the token (stores the token, see [0090]), the user contact information (recipient information, see [0090]), and the merchant identifier (unique merchant identifier, see [0090]) in a database (server memory, see [0090]);
receiving, by the payment network computer, a validation request (request for destination address, see [0124], figure 5) from a network service provider, the validation request comprising a second token (token, see [0124], figure 5) and a second merchant identifier (unique identifier of merchant device, see [0129]) received by the network service provider;
mapping the second token and the second merchant identifier received by the network service provider to the user contact information stored in the database (querying the database using the token to obtain destination address for recipient, see [0131]);
determining, by the payment network computer, a validation of the mapping of the second token (token received from merchant, see [0095]) and the second merchant identifier (unique merchant identifier, see [0090]) to the user contact information stored in the database (e.g. destination address for recipient, see [0095, 0120]).
Bayat does not disclose:
Determining… database;
Prohibiting… database.
Li teaches:
determining, by the payment network computer, where a data breach occurred based on an invalid mapping (service request or token is invalid, see C13 L10-13) associated with the second token, where the invalid mapping associated with the second token does not match the mapping associated with the token stored in the database;
prohibiting (based on the token expiration and privacy policy, see C11 L60 – C12 L19) (terminates query processing, see C13 L10-13), by the payment network computer, the network service provider from communicating with an account holder via the user contact information based on the invalid mapping (service request or token is invalid, see C13 L10-13) of the second token and the second merchant identifier received from the network service provider to the user contact information in the database.
Bayat discloses receiving a token request; generating a token; mapping the token; storing the token, user contact information, and merchant identifier in a database; receiving a validation request; mapping the second token and second merchant identifier; and determining a validation of the mapping of the second token. Bayat does not disclose determining whether a data breach occurred and prohibiting communication, but Li does. It would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to combine the systems and methods for facilitating protecting recipient privacy of Bayat with the determining whether a data breach occurred and prohibiting communication of Li because 1) a need exists for preventing a recipient’s personal information from being exploited by a third party (see Bayat); and 2) a need exists for developing an accurate profile of a customer (see Li C1 L16-27). Determining whether a data breach occurred and prohibiting communication can help prevent exploiting a recipient’s personal information by a third party.
Claims 2, 19
Furthermore, Bayat discloses:
authorizing, by the payment network computer, the network service provider to communicate with the account holder (send recipient destination address, see [0122]) using the user contact information based on a valid mapping of the second token and the second merchant identifier received from the network service provider.
Claims 5, 14
Furthermore, Li teaches:
notifying (notifies the merchant, see C4 L1-16), by the payment network computer, the network service provider of the data breach.
Claims 6, 15
Furthermore, Li teaches:
notifying, by the payment network computer, a merchant of the data breach (returns an exception to the merchant, see C13 L10-13).
Claims 7, 16
Furthermore, Li teaches:
determining, by the payment network computer, that the token associated with the merchant identifier in the token request is not associated (invalid request, see C4 L1-16) with the second merchant identifier received from the network service provider.
Claims 8, 17
Furthermore, Li teaches:
notifying, by the payment network computer, a merchant associated (returns exception to merchant, see C13 L10-13) with the token of the data breach; and
notifying, by the payment network computer, a second merchant not associated (returns exception to merchant, see C13 L10-13) with the token of the data breach.
Claim 9
Bayat discloses:
receiving, by a payment network computer, a token request (purchase order, see [0075]) from a mobile application (buyer app, see [0074]) running on a client device (customer device, see [0075]), wherein the token request is associated with user contact information (e.g. recipient information, see [0075]) and a merchant identifier (merchant data field, see [0078]);
generating, by a token server computer, a token (generate the token, see [0089]) based on the token request;
mapping, by the payment network computer, the token (token, see [0089]) to the user contact information (recipient information, see [0089]) and the merchant identifier (unique merchant identifier, see [0090]);
storing, by the payment network computer, the token (stores the token, see [0090]), the user contact information (recipient information, see [0090]), and the merchant identifier (unique merchant identifier, see [0090]) in a payment network computer database (server memory, see [0090]);
sending, by the payment network computer, the token to the client device (returns the token to customer device, see [0078, 0090]) to initiate a transaction with a merchant;
enable the merchant (merchant, see [0098]) to send information (product offered, see [0098]) to the client device using the token and the merchant identifier;
receiving, by the payment network computer, a validation request (request for destination address, see [0124], figure 5) from a network service provider, the validation request comprising a second token (token, see [0124], figure 5) and a second merchant identifier (unique identifier of merchant device, see [0129]) received by the network service provider from a merchant;
mapping, by the payment network computer, the second token to the second merchant identifier received from the network service provider to the user contact information in the payment network computer database (querying the database using the token to obtain destination address for recipient, see [0131]);
comparing, by the payment network computer, the mapping of the second token (token received from merchant, see [0095]) and the second merchant identifier (unique merchant identifier, see [0090]) received from the network service provider with the mapping of the token and the merchant identifier stored in the payment network computer database (e.g. destination address for recipient, see [0095, 0120]).
Bayat does not disclose:
Invalidating… database;
Determining… mapping;
Prohibiting… database.
Li teaches:
invalidating (service request or token is invalid, see C13 L10-13), by the payment network computer, a mapping of the second token and the second merchant identifier received from the network service provider, where the invalid mapping of the second token does not match the mapping associated with the token stored in the payment network computer database;
determining, by the payment network computer, where a data breach occurred based on the invalid mapping (service request or token is invalid, see C13 L10-13); and
prohibiting (terminates query processing, see C13 L10-13), by the payment network computer, the network service provider to send a communication to the user contact information stored in the payment network computer database.
Bayat discloses receiving a token request; generating a token; mapping the token; storing the token, user contact information, and merchant identifier in a database; sending the token to the client device; enabling the merchant to send information; receiving a validation request; mapping the second token and second merchant identifier; and comparing the mapping of the second token. Bayat does not disclose invalidating a mapping of the second token, determining where a data breach occurred, and prohibiting communications, but Li does. It would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to combine the systems and methods for facilitating protecting recipient privacy of Bayat with the invalidating a mapping of the second token, determining where a data breach occurred, and prohibiting communications of Li because 1) a need exists for preventing a recipient’s personal information from being exploited by a third party (see Bayat); and 2) a need exists for developing an accurate profile of a customer (see Li C1 L16-27). Invalidating a mapping of the second token, determining whether a data breach occurred, and prohibiting communication can help prevent exploiting a recipient’s personal information by a third party.
Response to Arguments
101 arguments
Applicant argues that the claimed invention is directed to a specific, architecture-constrained, token-and-identifier validation mechanism that improves secure routing in a payment network.
Examiner disagrees. The claimed invention is directed to an abstract idea of determining whether a data breach occurred based on received information matching stored information, which is a certain method of organizing human activity. The additional elements of a payment network computer, a client device, and a token server computer are simply the use of a computer in its ordinary capacity and do not provide significantly more. There is no specific architecture recited for performing the abstract idea. Please see revised 101 rejection above.
103 arguments
Applicant argues that Li does not disclose mapping a second token and second merchant identifier to the user contact information stored in a database.
Examiner cites a new reference Bayat, which discloses mapping the second token and the second merchant identifier received by the network service provider to the user contact information stored in the database (querying the database using the token to obtain destination address for recipient, see [0131]).
Claim Interpretation
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure (see attached form PTO-892).
Mazarim Fernandes (US 2015/0206137) discloses a secure method to store sensitive data.
Conclusion
Any inquiry of a general nature or relating to the status of this application or concerning this communication or earlier communications from Examiner should be directed to Chrystina Zelaskiewicz whose telephone number is 571-270-3940. Examiner can normally be reached on Monday-Friday, 9:30am-5:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, Neha Patel can be reached at 571-270-1492.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://portal.uspto.gov/external/portal/pair <http://pair-direct.uspto.gov>. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866.217.9197 (toll-free).
/CHRYSTINA E ZELASKIEWICZ/Primary Examiner, Art Unit 3699
Prosecution Insights