Prosecution Insights
Last updated: August 15, 2026
Application No. 17/524,588

Table-Connected Tokenization

Final Rejection §103§112
Filed
Nov 11, 2021
Priority
Sep 30, 2013 — continuation of 9237006 +5 more
Examiner
SAVENKOV, VADIM
Art Unit
2432
Tech Center
2400 — Computer Networks
Assignee
Protegrity Corporation
OA Round
10 (Final)
61%
Grant Probability
Moderate
11-12
OA Rounds
0m
Est. Remaining
82%
With Interview

Examiner Intelligence

Grants 61% of resolved cases
61%
Career Allowance Rate
193 granted / 316 resolved
+3.1% vs TC avg
Strong +21% interview lift
Without
With
+20.8%
Interview Lift
resolved cases with interview
Typical timeline
3y 5m
Avg Prosecution
30 currently pending
Career history
371
Total Applications
across all art units

Statute-Specific Performance

§101
10.7%
-29.3% vs TC avg
§103
53.4%
+13.4% vs TC avg
§102
8.9%
-31.1% vs TC avg
§112
17.4%
-22.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 316 resolved cases

Office Action

§103 §112
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 12/21/2025 has been entered. Response to Amendment / Arguments Regarding claims rejected under 35 USC 112(b): Applicant’s amendment is considered to have overcome the applied rejection. As such, the rejection has been withdrawn. Regarding claims rejected under 35 USC 103: Applicant's arguments have been fully considered but they are not persuasive. Applicant argues that the amended claim language overcomes the prior art by pointing to the 10/16/2025 Office action, stating that “[t]he Office Action notes "further specifying, e.g., FIG. 2C of the instant specification concerning the Modifiers 215b, 215c, and 215d would likely overcome the applied prior art (i.e., [0038] of Mattsson based on a checksum rather than stages of IV operations before and after tokenization)."” In response, it is noted that the claimed second modification operation is unspecified beyond its timing. The amended claim recites “wherein a second modification operation is performed on an output of the replacement operation after the replacement operation.” As such, the claim merely requires “performing, by the hardware processor of the tokenization system, a replacement operation… wherein a second modification operation is performed on an output of the replacement operation after the replacement operation.” Therefore, the “second modification” has been interpreted as any modification performed after a replacement operation. According to [0038] of Mattsson, a substitution step takes place and then a check-sum test takes place. If the check-sum test is unsatisfactory, another operation is performed consisting of replacing the previous substitution result. This is considered to be the claimed “second modification.” As per the 10/16/2025 Office action, it is noted that Mattsson-Stockton-Bomar-Khaladkar does not teach the specific implementation of modification operations as in FIG. 2C and [0042] of the instant specification (e.g., “modifier 215a modifies D8...D11 using the first IV to produce first modified data. The token table 1 is queried with the first modified data to produce a first token… A second modifier, modifier 215b, receives the first token and the second IV, and modifies the first token using the second IV to produce second modified data. The token table 2 is queried with the second modified data to produce a second token…The token table 4 is queried with the fourth modified data to produce a fourth token. The tokenization module 125 replaces D8...D11 with the fourth token and outputs the result data as the tokenized data 280”). 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. Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mattsson (US 2011/0213807 A1) in view of Stockton (US 9,430,655 B1), Bomar (US 2011/0154467 A1), and Khaladkar (US 2008/0120351 A1). Regarding claim 1, Mattsson discloses: A method for improving the security of data in a tokenization environment, comprising: receiving, by a tokenization system via a network from a client device (e.g., FIG. 1 and [0063] of Mattsson, data to be tokenized; Refer to at least 10 in FIG. 2, [0013], [0063], and [0088] of Mattsson with respect to input data to be tokenized, including credit card or social security numbers. accessing, by the tokenization system via the network, two or more token tables […] receiving a first token table […] receiving a second token table; and Refer to at least FIG. 2, [0018], [0063], and [0072] of Mattsson with respect to token tables stored at a central server, used by a local server for tokenization. Refer to at least [0028] of Mattsson with respect to receiving at least two token tables from the central server. tokenizing, by the tokenization system, the received data by: modifying, by a hardware processor of the tokenization system, the received data by performing a first of a plurality of modification operations using a value corresponding to two or more bits of the received data to produce modified data; and Refer to at least [0040] and [0094] of Mattsson with respect to an initialization vector for modifying the data to be tokenized. Further see at least [0038] of Mattsson with respect to an additional token substitution based on a checksum of a previous tokenization output. for each token table of the accessed token tables, performing, by the hardware processor of the tokenization system, a replacement operation by replacing a portion of the modified received data with a token value mapped by the token table to a value of the portion of the modified received data to produce tokenized data; Refer to at least the abstract, FIG. 3-9, and [0072] of Mattsson with respect to using the token tables to implement tokenization. wherein the first modification operation is performed on the received data before the replacement operation and Refer to at least [0040] and [0094] of Mattsson—e.g., “it is possible to use an initialization vector, comprising a predetermined string of characters, to modify the substring to be tokenized before tokenization.” wherein a second modification operation is performed on an output of the replacement operation after the replacement operation; and Further see at least [0038] of Mattsson—e.g., “in case the result of said check-sum test is unsatisfactory, repeating said step of substituting with another token until said check-sum test is satisfied.” The repeat is considered a new operation subsequent to token substitution. transmitting, by the tokenization system via the network, the tokenized data to a computing device; Refer to at least [0032] of Mattsson with respect to transferring tokenized information to the central server. Mattsson by itself does not disclose: the token tables stored at a plurality of physically separated token servers, each token server associated with a different fixed portion of the received data and storing a plurality of token tables each associated with an index value comprising a plurality of bits equal to a number of bits of the different fixed portion of the received data associated with the token server; accessing the token tables by querying a first token server with a first value of a first fixed portion of the received data such; querying a second token server with a second value of a second fixed portion of the received data different than the first fixed portion of the received data; receiving the token tables further comprising the first token table associated with an index value that matches the first value and the second token table associated with an index value that matches the second value; replacing the portion of the modified data including data corresponding to one or more of the fixed portions of the received data used to query the token servers. However, Mattsson in view of Stockton discloses: the token tables stored at a plurality of physically separated token servers, each token server associated with a different fixed portion of the received data; Refer to at least the abstract, FIG. 1, and Col. 4, Ll. 8-46 of Stockton with respect to token servers associated with respective split shares of a secret such as an input credit card number. each token server storing a plurality of token tables each associated with an index value; Refer to at least Col. 1, Ll. 15-24 and Col. 8, Ll. 64-Col. 9, Ll. 18 of Stockton with respect to token servers utilizing tables of tokens for tokenization of respective servers’ secret shares. The token tables are associated with respective keys and/or hashes for referencing—e.g., Col. 7, Ll. 22-30 and Col. 9, Ll. 2-18 of Stockton. accessing the token tables by querying a first token server with a first value of a first fixed portion of the received data such; querying a second token server with a second value of a second fixed portion of the received data different than the first fixed portion of the received data; Refer to at least Col. 4, Ll. 34-53 and Col. 7, Ll. 16-21 of Stockton with respect to the token servers being sent their respective secret shares for tokenization, where the tokens are associated with a key/hash as above. replacing the portion of the modified data including data corresponding to one or more of the fixed portions of the received data used to query the token servers. Refer to at least the abstract, Col. 4, Ll. 54-61, and Col. 7, Ll. 22-30 of Stockton with respect to tokenizing the respective shares at the respective token servers. The teachings of both Mattsson and Stockton concern tokenization, and are considered to be within the same field of endeavor and combinable as such. Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Mattsson to include splitting input sensitive data into secret shares bound to respective tokenization servers for at least the reasons discussed in Col. 1, Ll. 28-64 and Col. 3, Ll. 10-32 (i.e., providing improved security by preventing full access to sensitive data in the case where a tokenization server is compromised—if a single share is detokenized, it would not provide enough information to recover the secret). Mattsson-Stockton has keys/hashes as an index, but does not specify: the index value further comprising a plurality of bits equal to a number of bits of the different fixed portion of the received data associated with the token server; the index value further equal to a value of one of the two or more portions of the received data. Mattsson-Stockton further does not disclose: receiving the token tables further comprising the first token table associated with an index value that matches the first value and the second token table associated with an index value that matches the second value. However, Mattsson-Stockton in view of Bomar discloses: the index value further comprising a plurality of bits equal to a number of bits of the different fixed portion of the received data associated with the token server; the index value further equal to a value of one of the two or more portions of the received data (interpreted in view of [0030] of the instant specification concerning index “12356” being a string “123456” of the received sensitive data). Refer to at least FIG. 4 and [0125] of Bomar with respect to part of the untokenized PAN (such as the middle digits) being utilized as an index, pointer, and/or basis for another type of linking mechanism to find a token in the token map. The teachings of Bomar likewise concern tokenization, and are considered to be within the same field of endeavor and combinable as such. Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Mattsson-Stockton to further implement a portion of the input data as an index because the substitution of one known element for another (the type of token map linking mechanism; [0125] of Bomar) would have yielded predictable results to one of ordinary skill in the art at the time (e.g., looking up token values based on the index portion as a linking mechanism). Mattsson-Stockton-Bomar discloses obtaining a token map based on input data portions (e.g., 912, 918, 922 in FIG. 9 of Bomar), but does not disclose: receiving the token tables further comprising the first token table associated with an index value that matches the first value and the second token table associated with an index value that matches the second value. However, Mattsson-Stockton-Bomar in view of Khaladkar discloses: receiving the token tables further comprising the first token table associated with an index value that matches the first value and the second token table associated with an index value that matches the second value. Refer to at least [0056] and [0064] of Khaladkar with respect to assigning a globally unique identifier (GUI) to token tables, and associated mapping. Refer to at least [0083] of Khaladkar with respect to querying tables based on the mapping. The teachings of Khaladkar likewise concern transporting token tables, and are considered to be within the same field of endeavor and combinable as such. Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Mattsson-Stockton-Bomar to further implement receiving the token tables according to identifiers mapped to respective tables for at least the purpose of avoiding having to query every token server (i.e., only query the ones storing desired token tables—e.g., Col. 11, Ll. 58-65 of US 7,406,501 B2). Regarding claim 2, it is rejected for substantially the same reasons as claim 1 above (i.e., [0088] of Mattsson). Regarding claim 3, Mattsson-Stockton-Bomar-Khaladkar discloses: The method of claim 1, wherein modifying the received value comprises modifying the received value using an initialization vector, and wherein the initialization vector is received from an initialization vector table server. Refer to at least [0040] and [0094] of Mattsson with respect to an initialization vector for modifying input data. Refer to at least FIG. 1-2 of Mattsson with respect to tokenization and tokenization information via local and central servers. Regarding claim 4, it is rejected for substantially the same reasons as claims 1 and 3 above (i.e., the citations concerning the IV). Regarding claim 5, it is rejected for substantially the same reasons as claim 1 above (i.e., the citations to Marchant concerning the PIN/public code as an entry point to obtaining encryption parameters). Regarding claim 6, Mattsson-Stockton-Bomar-Khaladkar discloses: The method of claim 1, wherein the two or more portions of the received data do not overlap. Refer to at least [0075], [0082], and [0084] of Mattsson with respect to embodiments concerning whether there is an overlap. Regarding claim 7, it is rejected for substantially the same reasons as claim 6 above (i.e., the citations). Regarding independent claim 8, it is substantially similar to independent claim 1 above, and is therefore rejected for substantially the same reasons (i.e., the citations and obviousness rationale). Regarding claims 9-11 and 13-14, they are substantially similar to claims 2-4 and 6-7 above, and are therefore likewise rejected. Regarding independent claim 15, it is substantially similar to independent claim 1 above, and is therefore rejected for substantially the same reasons (i.e., the citations and obviousness rationale). Regarding claims 16-18 and 20, they are substantially similar to claims 2-4 and 6 above, and are therefore likewise rejected. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Any inquiry concerning this communication or earlier communications from the examiner should be directed to VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM. 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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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. /Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432 /V.S/Examiner, Art Unit 2432
Read full office action

Prosecution Timeline

Show 16 earlier events
Jun 24, 2025
Non-Final Rejection mailed — §103, §112
Jun 29, 2025
Response Filed
Oct 16, 2025
Final Rejection mailed — §103, §112
Dec 21, 2025
Request for Continued Examination
Jan 08, 2026
Response after Non-Final Action
Apr 03, 2026
Non-Final Rejection mailed — §103, §112
May 08, 2026
Response Filed
Aug 11, 2026
Final Rejection mailed — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12639449
SYSTEM AND METHOD FOR SCANNING CONTAINERS FOR VULNERABILITIES
2y 4m to grant Granted May 26, 2026
Patent 12632534
ACCESSING SECURE SYSTEM RESOURCES BY LOW PRIVILEGE PROCESSES
7y 12m to grant Granted May 19, 2026
Patent 12613999
DETECTING ELECTRONIC SYSTEM MODIFICATION
6y 10m to grant Granted Apr 28, 2026
Patent 12608482
DETERMINING A SECURITY SCORE IN BINARY SOFTWARE CODE
6y 5m to grant Granted Apr 21, 2026
Patent 12608501
Privacy-Preserving Log Analysis
5y 11m to grant Granted Apr 21, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

11-12
Expected OA Rounds
61%
Grant Probability
82%
With Interview (+20.8%)
3y 5m (~0m remaining)
Median Time to Grant
High
PTA Risk
Based on 316 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month