Detailed Action
Acknowledgements
This action is in reply to the Amendment filed on August 4, 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. 20261002 for references purposes only.
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-19 are rejected under 35 U.S.C. 103(a) as being unpatentable over Zhang (US 2019/0347667) in view of Li et al. (US 8,655,719).
Claims 1, 9, 18
Zhang discloses:
receiving, by a payment network computer (transaction service provider, see [0127]), a token request (request, see figure 2) from an application running on a client device (requesting device, see [0141]), wherein the token request comprises user contact information (user identifiers, see [0134]) and a merchant identifier (merchant name or ID, see [0180]);
mapping, by the payment network computer, the token (token ID, see [0180]) to the user contact information (name, contact information, see [0180]) and the merchant identifier (merchant ID, see [0180]);
storing, by the payment network computer, the token, the user contact information, and the merchant identifier in a database (first data structure, see [0180]);
receiving, by the payment network computer, a validation request from a network service provider, the validation request comprising a second token (second token ID, see [0183]) and a second merchant identifier (second token data may be the same or different from first token data, e.g. second merchant ID, see [0180, 0183]) received by the network service provider;
mapping, by the payment network computer, the second token and the second merchant identifier received by the network service provider to the user contact information stored in the database (does second token ID match the stored first token ID, see [0184]);
determining, by the payment network computer, a validation (e.g. whether first token data and second token data are duplicates, whether fraudulent token, see [0186, 0190]) of the mapping of the second token and the second merchant identifier to the user contact information stored in the database.
Zhang does not disclose:
Generating… identifier;
Determining… database;
Prohibiting… database.
Li teaches:
generating, by a token server computer, a token (token, see C10 L66-67) associated with the merchant identifier (merchant identifier, see C11 L1-28);
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.
Zhang discloses receiving a token request; mapping the token; storing the token, receiving a validation request; mapping the second token; and determining a validation of the mapping of the second token. Zhang does not disclose generating a token, 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 determining an event in a distributed data system of Zhang with the generating a token, determining whether a data breach occurred, and prohibiting communication of Li because 1) a need exists for preventing duplicate processing of a payment transaction (see Zhang [0009]); and 2) a need exists for developing an accurate profile of a customer (see Li C1 L16-27). Generating a token, determining whether a data breach occurred, and prohibiting communication can help prevent processing of a duplicate transaction.
Claims 2, 19
Furthermore, Zhang discloses:
authorizing, by the payment network computer (transaction processing server, see [0226]), the network service provider (merchant, see [0226]) to communicate with the account holder (user, see [0213]) using the user contact information based on a valid mapping (not duplicate data, may redeem offer, see [0226]) 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.
Response to Arguments
101 arguments
The 101 rejection has been withdrawn for the reasons cited in the Amendment p 7-11.
103 arguments
Applicant argues that the claims recite a specific three-party validation architecture in which the network service provider is a distinct intermediary between the merchant and the payment network computer (see Amendment p 12), whereas Bayat discloses a direct two-party request in which the merchant transmits the token and request to the platform server.
Please see revised mapping. Zhang discloses a three-party validation architecture.
Claim Interpretation
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure (see attached form PTO-892).
Ledwell et al. (US 12,699,987) discloses a transaction system with account mapping.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry 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