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 .
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 (i.e., changing from AIA to pre-AIA ) 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.
FINAL ACTION
This action is in response to applicant’s claim amendment(s) submitted on 02/13/2026. Claims 1-17 are pending.
Response to Arguments
Examiner’s Remarks – Specification Objection (Title)
The examiner withdraws the objection after further consideration.
Examiner’s Remarks – Claim Objection
The examiner notes that applicant’s current claim 3 recites:
3. (Original) The method according to claim 2, wherein the tweak input comprises another a second part of the cleartext input.
The examiner is not sure if the term “another” is a typo.
Examiner’s Remarks – Double Patenting Rejection
The examiner maintains the Double Patenting rejection view of the following applicant’s remarks: “Applicant acknowledges this rejection and respectfully requests that it be held in abeyance until the claims are otherwise found to be in condition for allowance. At that time, Applicant will file a terminal disclaimer if necessary”.
Examiner’s Remarks - 35 U.S.C. Section 103 - Independent Claim 1
Applicant argues:
“The claim recites a defined pipeline with discrete, sequentially ordered steps. These steps are: (1) encoding a first data set via a lookup table to produce encoded input data, (2) separately encoding a tweak input and hashing that encoded tweak input with a unique hashing key to generate a secure tweak, (3) feeding the encoded input data, secure tweak, and unique encryption key into a format-preserving encryption algorithm to produce ciphertext, and (4) encoding the ciphertext output into a token. Each step operates on the output of a prior step. The claim architecture is a multi-stage pipeline in which pre-encryption encoding, tweak generation through keyed hashing, FPE encryption, and post-encryption tokenization are each distinct operations. “.
The examiner respectfully disagrees.
With regards to applicant’s argument concerning claim limitation of, “encoding a first data set via a lookup table to produce encoded input data”, the examiner notes that applicant’s independent claims as currently constructed, do not recite the argued limitation(s) of, “via a lookup table”. (emphasis)
With regards to applicant’s claim limitation element of, “separately encoding a tweak input and hashing that encoded tweak input with a unique hashing key to generate a secure tweak”, the examiner notes that applicant’s independent claims as currently constructed, do not recite the argued limitation(s) of, “separately encoding a tweak input and…”. (emphasis)
With regards to applicant’s claim limitation element of, “feeding the encoded input data, secure tweak, and unique encryption key into a format-preserving encryption algorithm to produce ciphertext”, the examiner notes that applicant’s independent claims as currently constructed, do not recite the argued limitation(s) of, “ feeding the encoded input data, secure tweak, and unique encryption key into a format-preserving encryption algorithm to produce ciphertext”. (emphasis)
With regards to applicant’s remarks of, “The claim architecture is a multi-stage pipeline in which pre-encryption encoding, tweak generation through keyed hashing, FPE encryption, and post-encryption tokenization are each distinct operations“, the examiner respectfully contends that applicant’s independent claims 1, 12 and 17 do not recite the argued limitation(s) of, “a multi-stage pipeline in which pre-encryption encoding, tweak generation through keyed hashing, FPE encryption, and post-encryption tokenization are each distinct operations”. (emphasis)
Applicant argues:
“Shrimpton does not teach this pipeline. The Office's claim mappings conflate structurally and functionally distinct operations, and no reasonable interpretation of the claim language supports the Office's readings.”.
The examiner respectfully disagrees. The examiner notes that applicant’s independent claims 1, 12 and 17 as currently constructed do not recite applicant’s argued feature(s) of a “pipeline”.
Applicant argues:
"Encoding a First Data Set to Produce Encoded Input Data" -- Shrimpton Does Not Teach This Limitation The Office maps this limitation to Shrimpton's discussion of VILTC construction and permutation lookup tables at paragraph 0012. Paragraph 0012 of Shrimpton describes the internal construction of tweakable block ciphers (TBCs), stating that the VILTC and its constituent TBCs can be constructed from randomly generated permutation lookup tables. The claimed "encoding a first data set to produce encoded input data" is a pre-encryption step that transforms raw input data through a lookup table before that data is fed into the FPE algorithm. The Specification makes this architecture explicit. At paragraph 0026, the table encoding module 108 applies a lookup table to the first data set [7,8,9,0,0,1] to produce encoded input data [9,0,5,2,2,4]. Only after this encoding step is completed does the system proceed to generate the secure tweak and apply the FPE algorithm to the encoded input data. The encoded input data, not the raw first data set, is what enters the FPE algorithm. Shrimpton's permutation lookup tables, by contrast, are not a pre-encryption encoding step. They are components of the cipher itself. Shrimpton's TBCs are the encryption mechanism. The permutation lookup tables that Shrimpton discusses at paragraph 0012 form the internal structure of the TBC; they are the cipher's round functions. ”.
The examiner respectfully disagrees. The examiner notes that the current claim structure of applicant’s independent claims 1, 12 and 17 do not restrict the implementation of applicant’s recited claim limitation feature(s), “Encoding a First Data Set to Produce Encoded Input Data”. As such, the examiner notes that there are many reasonable interpretation(s)/implementation(s).
The examiner notes that the applicant states the following: “The Specification makes this architecture explicit. At paragraph 0026, the table encoding module 108 applies a lookup table to the first data set [7,8,9,0,0,1] to produce encoded input data [9,0,5,2,2,4]. Only after this encoding step is completed does the system proceed to generate the secure tweak and apply the FPE algorithm to the encoded input data. The encoded input data, not the raw first data set, is what enters the FPE algorithm. Shrimpton's permutation lookup tables, by contrast, are not a pre-encryption encoding step. They are components of the cipher itself.”. The examiner respectfully notes that the examiner cannot read limitation(s) into the claim language from the specification.
With regards to applicant’s remarks of, “Shrimpton's permutation lookup tables, by contrast, are not a pre-encryption encoding step. They are components of the cipher itself. Shrimpton's TBCs are the encryption mechanism. The permutation lookup tables that Shrimpton discusses at paragraph 0012 form the internal structure”, the examiner respectfully disagrees with applicant’s subjective characterization of Shrimpton’s teachings. Again, the examiner notes that applicant’s current independent claim structure does not restrict the implementation of applicant’s recited claim limitation feature(s), “Encoding a First Data Set to Produce Encoded Input Data”. Therefore, examiner notes that there are many reasonable interpretation/implementation.
Applicant argues:
“In the present claims, the first data set is encoded through a lookup table to produce encoded input data, and then that encoded input data is separately fed into the FPE algorithm as an input.”.
The examiner respectfully disagrees. The examiner notes that applicant’s independent claims 1, 12 and 17 as currently constructed do not recite applicant’s argued feature(s) of a “the first data set is encoded through a lookup table to produce”. (emphasis) … Moreover, the examiner contends that such argument is improperly based on a claim limitation that is not explicitly recited in applicant’s current independent claims 1, 12 and 17 claim structure. Therefore, the argument(s) lacks merit. (emphasis)
Applicant argues:
“In Shrimpton, the data enters the TBC directly and the permutation tables operate on the data as part of the encryption process. This distinction is not a matter of labeling. It is a structural and functional difference.”.
The examiner respectfully disagrees with applicant’s above assertions. Again, the examiner notes that applicant’s current independent claim structure does not restrict the implementation of applicant’s recited claim limitation feature(s), “Encoding a First Data Set to Produce Encoded Input Data”.
Therefore, examiner notes that there are many reasonable interpretation/implementation.
Shrimpton teaches in par. 0012 the following: “The first N-character TBC, the VILTC and the second N-character TBC can be constructed from randomly generated permutation look-up tables.”.
Applicant argues:
“In the present claims, there are two distinct transformations: (a) a lookup-table encoding that transforms the first data set into encoded input data, and (b) the FPE algorithm that operates on the encoded input data.”.
The examiner respectfully disagrees. The examiner notes that applicant’s independent claims 1, 12 and 17 as currently constructed do not recite applicant’s argued feature(s) of a “a lookup-table encoding that transforms”. (emphasis) … Moreover, the examiner contends that such argument is improperly based on a claim limitation that is not explicitly recited in applicant’s current independent claims 1, 12 and 17 claim structure. Therefore, the argument(s) lacks merit. (emphasis)
Shrimpton teaches in par. 0058 the following: “format-preserving encryption (“FPE”), the encryption/decryption service (222) encrypts data”. Shrimpton further teaches in pars. 102 & 103 the following: “The system obscures (440) the fixed-length initialization vector. For example, the fixed-length initialization vector is obscured by a FIL TBC, which produces a fixed-length output string (e.g., N-bit output string, N-character output string) based on the fixed-length initialization vector, as input for the FIL TBC, and a combination of the system tweak and the variable-length output string, as tweak for the FIL TBC. The FIL TBC can be an N-bit TBC or N-character TBC, for example. Alternatively, the fixed-length initialization vector is obscured in some other way.[0103] Finally, the system outputs (450) the fixed-length output string and the variable-length output string. For encryption (e.g., during FDE, FPE, AEAD or another encryption scenario),”. Accordingly, Shrimpton teaches that the initial input data is obscured and then the system applies a FDE, FPE, AEAD or another encryption scenario to the obscured data to output encrypted data.
Applicant argues:
“In Shrimpton, there is a single transformation: the TBC (whose internals may include permutation tables) that encrypts data. The Office has collapsed two distinct operations into one and then asserted that Shrimpton's single operation teaches both. Even under the broadest reasonable interpretation, "encoding a first data set to produce encoded input data" followed by "applying a format preserving encryption algorithm that utilizes the encoded input data" requires two separate operations.”.
The examiner respectfully disagrees with applicant’s above assertions. Shrimpton teaches in par. 0058 the following: “format-preserving encryption (“FPE”), the encryption/decryption service (222) encrypts data”. Shrimpton further teaches in pars. 102 & 103 the following: “The system obscures (440) the fixed-length initialization vector. For example, the fixed-length initialization vector is obscured by a FIL TBC, which produces a fixed-length output string (e.g., N-bit output string, N-character output string) based on the fixed-length initialization vector, as input for the FIL TBC, and a combination of the system tweak and the variable-length output string, as tweak for the FIL TBC. The FIL TBC can be an N-bit TBC or N-character TBC, for example. Alternatively, the fixed-length initialization vector is obscured in some other way. Accordingly, Shrimpton teaches that the initial input data is obscured and then the system applies a FDE, FPE, AEAD or another encryption scenario to the obscured data to output encrypted data.
Applicant argues:
“Shrimpton's TBC is one operation. No reasonable reading of the claims permits them to be equated. Moreover, Shrimpton's permutation lookup tables are cipher internals that are not individually addressable or separable from the encryption operation. The present claims require that the encoding of the first data set be a discrete step that produces a discrete intermediate output (the "encoded input data") which is then separately consumed by the FPE algorithm. Shrimpton does not disclose this architecture and paragraph 0012 cannot reasonably be read to teach it. “.
The examiner respectfully disagrees with applicant’s above assertions. Shrimpton teaches in par. 0058 the following: “format-preserving encryption (“FPE”), the encryption/decryption service (222) encrypts data”. Shrimpton further teaches in pars. 102 & 103 the following: “The system obscures (440) the fixed-length initialization vector. For example, the fixed-length initialization vector is obscured by a FIL TBC, which produces a fixed-length output string (e.g., N-bit output string, N-character output string) based on the fixed-length initialization vector, as input for the FIL TBC, and a combination of the system tweak and the variable-length output string, as tweak for the FIL TBC. The FIL TBC can be an N-bit TBC or N-character TBC, for example. Alternatively, the fixed-length initialization vector is obscured in some other way. Accordingly, Shrimpton teaches that the initial input data is obscured and then the system applies a FDE, FPE, AEAD or another encryption scenario to the obscured data to output encrypted data.
Applicant argues:
"Generating a Secure Tweak ... Based on a Token Format Schema" -- Shrimpton Does Not Teach This Limitation The Office identifies no passage in Shrimpton that teaches or discloses a "token format schema."
The examiner respectfully disagrees. The examiner notes that applicant’s current claim structure of applicant’s independent claims 1, 12 and 17 does not restrict the implementation of applicant’s recited claim limitation feature(s), “Token Format Schema”. As such, the examiner notes that there are many reasonable interpretation(s)/implementation(s).
Applicant argues:
“The present specification defines the token format schema as a configuration construct that dictates, among other things, which portions of the cleartext input are subject to tokenization and which are preserved, the method of tweak assignment, encryption key assignment instructions, encoding instructions, and the character set of the token. See Specification at paragraphs 20-21 and 23. This is a governance layer that sits above and controls the tokenization pipeline. “.
The examiner respectfully disagrees. The examiner notes that applicant’s current claim structure of applicant’s independent claims 1, 12 and 17 does not restrict the implementation of applicant’s recited claim limitation feature(s) of, “Token Format Schema”. As such, the examiner notes that there are many reasonable interpretation(s)/implementation(s). Additionally, the examiner notes that the applicant’s is arguing that the specification defines and limits the claim feature(s) “Token Format Schema”. In this instance the examiner notes that the applicant appears to differentiate based on what the applicant has disclosed in their specification rather than the claim language itself.
Applicant argues:
“Shrimpton is a cryptographic primitives reference that describes the theoretical construction of VILTCs and TBCs. Shrimpton has no concept of selective tokenization, no concept of preserving portions of cleartext while tokenizing others, and no concept of a configurable schema that controls these operations. “.
The examiner respectfully disagrees with applicant’s subjective characterization of Shrimpton’s teachings. Moreover, the examiner notes that the applicant’s argued feature(s) of, “selective tokenization, preserving portions of cleartext while tokenizing others, and a configurable schema that controls these operations”, is/are not currently recited in applicant’s current independent claims 1, 12 and 17. (emphasis) … Additionally, the examiner contends that such argument is improperly based on a claim limitation that is not explicitly recited in applicant’s current independent claims 1, 12 and 17 claim structure. Therefore, the argument(s) lacks merit. (emphasis)
Applicant argues:
“The Office does not identify any passage in Shrimpton that corresponds to this limitation, and for good reason: no such passage exists.”.
The examiner kindly notes that applicant’s argument(s) targeting Shrimpton alone, as opposed to the combination made, is not sufficient. Moreover, the examiner contends that, per office action dated 08/13/2025, secondary prior art reference Davis (US 2016/0019396) not Shrimpton was relied upon to meet the limitation element(s) of, “based on a Token Format Schema”. The examiner notes for the record that the applicant does not rebut the teachings of Davis in this instance.
Applicant argues:
“The claimed "token format schema" is not merely a formatting preference. It is the control structure that determines the inputs to the entire process, including what constitutes the "first data set" versus the "tweak input," which lookup tables to apply, and how the resulting token is assembled. Shrimpton's TBC operates uniformly on whatever data it receives; there is no schema-driven selection of data subsets for differential treatment. “.
The examiner notes that applicant’s current claim structure of applicant’s independent claims 1, 12 and 17 does not restrict the implementation of applicant’s recited claim limitation feature(s), “Token Format Schema”. As such, the examiner notes that there are many reasonable interpretation(s)/implementation(s). Again, the examiner contends that, per office action dated 08/13/2025, secondary prior art reference Davis (US 2016/0019396) not Shrimpton, was noted to meet the limitation element(s) of, “based on a Token Format Schema”. The examiner notes for the record that the applicant did not dispute that the teachings of Davis did not teach applicant’s claim limitation element of, “based on a Token Format Schema”.
Applicant argues:
“Even under the broadest reasonable interpretation, "based on a token format schema" requires that the secure tweak generation be governed by some configurable format specification. Shrimpton contains no such thing. “.
Again, the examiner contends that, per office action dated 08/13/2025, secondary prior art reference Davis (US 2016/0019396) was noted to meet the limitation element(s) of, “based on a Token Format Schema”. The examiner notes for the record that the applicant did not dispute that the teachings of Davis did not teach applicant’s claim limitation element of, “based on a Token Format Schema”.
Applicant argues:
"Hashing the Encoded Tweak Input Along With a Unique Hashing Key to Generate the Secure Tweak" -- Shrimpton Does Not Teach This Limitation The Office maps this limitation to Shrimpton paragraph 0006, which states that a tweakable block cipher is a generalization of a block cipher and that each permutation in the TBC is associated with a key and a tweak. The Office concludes that because Shrimpton's TBC associates permutations with a key and a tweak, Shrimpton teaches hashing an encoded tweak input with a unique hashing key to generate a secure tweak. This mapping is a fundamental misreading. “.
The examiner respectfully disagrees. The examiner notes that Shrimpton teaches in par. 0088 the following: “a LRW2 TBC construction is adapted to produce an n-bit LRW2 output string by computing an XOR between (1) an encrypted version of an XOR between (a) an n-bit LRW2 input string and (b) an n-bit hash of a tweak input, and (2) the n-bit hash of the tweak input”.
Applicant argues:
“Shrimpton paragraph 0006 describes the use of a tweak and key within the TBC's encryption operation. It says nothing about how the tweak is generated. “.
The examiner respectfully notes that this is simply not true. Shrimpton teaches as early as their abstract the following: “The VILTC is adapted to produce a variable-length output string using the fixed-length initialization vector as a tweak.”.
Applicant argues:
“The present claims do not merely require that a tweak be used in encryption. The claims require a specific tweak generation process: (1) a tweak input is encoded to produce an encoded tweak input, and (2) that encoded tweak input is then hashed along with a unique hashing key to produce the secure tweak.”.
The examiner notes that applicant’s current claim structure of applicant’s independent claims 1, 12 and 17 does not restrict the implementation of applicant’s recited claim limitation feature(s), “a unique hashing key to produce the secure tweak”. As such, the examiner notes that there are many reasonable interpretation(s)/implementation(s). (emphasis)
The examiner notes that Shrimpton teaches in par. 0088 the following: “a LRW2 TBC construction is adapted to produce an n-bit LRW2 output string by computing an XOR between (1) an encrypted version of an XOR between (a) an n-bit LRW2 input string and (b) an n-bit hash of a tweak input, and (2) the n-bit hash of the tweak input”.
Applicant argues:
“The Specification identifies this as an HMAC operation (paragraphs 34-35), such as HMAC SHA256, applied to the encoded tweak input and a unique hashing key.”.
Again, the examiner notes that the applicant notes teachings from their specification rather than the actual claim limitation(s) of their independent claims 1, 12 and 17 in order to differentiate their independent claims from the teachings of Shrimpton. Again, the examiner notes that applicant’s current claim structure of applicant’s independent claims 1, 12 and 17 does not restrict the implementation of applicant’s recited claim limitation feature(s), “a unique hashing key to produce the secure tweak”. As such, the examiner notes that there are many reasonable interpretation(s)/implementation(s). (emphasis).
Applicant argues:
“Shrimpton's TBC takes a tweak as an input but does not disclose generating that tweak by hashing an encoded tweak input with a separate, unique hashing key. “.
The examiner respectfully notes that this is simply not true. Again, the examiner notes that applicant’s current claim structure of applicant’s independent claims 1, 12 and 17 does not restrict the implementation of applicant’s recited claim limitation feature(s), “a unique hashing key to produce the secure tweak”. As such, the examiner notes that there are many reasonable interpretation(s)/implementation(s). (emphasis)
The examiner notes that Shrimpton teaches in par. 0088 the following: “a LRW2 TBC construction is adapted to produce an n-bit LRW2 output string by computing an XOR between (1) an encrypted version of an XOR between (a) an n-bit LRW2 input string and (b) an n-bit hash of a tweak input, and (2) the n-bit hash of the tweak input”.
Applicant argues:
“The distinction is between using a tweak (which Shrimpton does) and generating a tweak through keyed hashing of encoded input (which Shrimpton does not do).”.
The examiner respectfully disagrees with applicant’s subjective characterization of Shrimpton’s teachings. Moreover, the examiner notes that the applicant’s argued feature(s) of, “generating a tweak through keyed hashing of encoded input”, is/are not currently recited in applicant’s current independent claims 1, 12 and 17. (emphasis) … Additionally, the examiner contends that such argument is improperly based on a claim limitation that is not explicitly recited in applicant’s current independent claims 1, 12 and 17 claim structure. Therefore, the argument(s) lacks merit. (emphasis)
Applicant argues:
“Shrimpton teaches any and all methods of tweak generation. That reasoning, taken to its logical conclusion, would render obvious any tweak generation method when combined with any reference that uses a tweak, which collapses the entire analysis into a tautology. Furthermore, the claims require a "unique hashing key" that is separate from the "unique encryption key.".
Again, the examiner notes that the current claim structure of applicant’s independent claims 1, 12 and 17 does not restrict the implementation of applicant’s recited claim limitation feature(s) of, “unique hashing key”. As such, the examiner notes that there are many reasonable interpretation(s)/implementation(s). (emphasis)
Applicant argues:
“Claim 1 recites both terms distinctly: the unique hashing key is used to generate the secure tweak, while the unique encryption key is used in the FPE algorithm. The Specification confirms this two-key architecture at paragraph 19, which discloses that the system utilizes "a unique encryption key for use in the FPE algorithm, a hashing function, a unique hashing key for use with the hashing function." These are two separate cryptographic keys serving two separate functions in two separate operations. “.
Again, the examiner notes that applicant’s current claim structure of applicant’s independent claims 1, 12 and 17 does not restrict the implementation of applicant’s recited claim limitation feature(s), “unique hashing key” and “a unique encryption key”. As such, the examiner notes that there are many reasonable interpretation(s)/implementation(s). (emphasis)
Applicant argues:
“While paragraph 35 of the Specification describes one embodiment in which an encryption key participates in the HMAC function, the claims as written require two distinct keys, and the Specification at paragraphs 19, 51, and 57 supports this architecture by consistently describing the unique hashing key and the unique encryption key as separate inputs. Shrimpton's TBC uses a single key. There is no teaching in Shrimpton of maintaining and using two distinct keys for two distinct operations as the claims require. “.
Again, the examiner notes that the applicant relies on teachings from their specification rather than the actual claim limitation(s) of their independent claims 1, 12 and 17 in order to differentiate their independent claims from the teachings of Shrimpton. The examiner notes that limitation(s) of the applicant’s specification cannot be read into the claims.
Applicant argues:
“Encoding the Ciphertext Output Into Token" -- Neither Shrimpton Nor Davis Teaches This Limitation as Claimed”.
Again, the examiner notes that the current claim structure of applicant’s independent claims 1, 12 and 17 does not restrict the implementation of applicant’s recited claim limitation feature(s), “Encoding the Ciphertext Output Into Token”. As such, the examiner notes that there are many reasonable interpretation(s)/implementation(s). (emphasis)
Applicant argues:
“The Office relies on Davis paragraph 0044 for this limitation. Paragraph 0044 of Davis describes a computing device that merges a generated token with original preserved input (e.g., "23456") to generate a merged token (e.g., "6745911474123456"), where the generated token is merged with characters preserved from the original input, and the computing device may further repackage the token or merged token in the file at the appropriate location. The Office's motivation to combine is that utilizing enhanced data tokenization as taught by Davis affords a system with comprehensive data integrity, and that combining the references yields enhanced data security. “.
The examiner respectfully disagrees. The examiner respectfully contends that both Shrimpton and Davis discloses tweaks and FPE-based encryption operations.
Applicant argues:
“Davis's token merging process is not the claimed encoding of ciphertext into a token. The present claims require "encoding the ciphertext output into token," which is a conversion step that transforms the output of the FPE algorithm (ciphertext) into a token. “.
The examiner notes that the applicant has miss-characterized the teachings of Davis. Davis teaches in par. 0041 the following: “During the first stage transformation, the computing device 100 performs FPE-based encryption on the extracted data to generate encrypted data: ENC.sub.FPE (key.sub.stage1,(tweak.sub.stage1 [|preserved]),”.
Davis teaches in par. 0043 the following: “[0043] During the third stage transformation, the computing device 100 performs FPE-based encryption on the extracted data or, more particularly, the alternative data to generate the token:”.
Applicant argues:
“In the context of the Specification, this involves applying a lookup table to ciphertext output to produce a token in a potentially different character set. At paragraphs 38-40, the Specification describes the tokenization module 114 encoding ciphertext output [15,35,40,16,16,37] into a token "kJjnnZ," converting numeric ciphertext values into alphabetic token characters through a lookup table. This is a character-set conversion applied to ciphertext to produce a token. “.
The examiner notes that applicant states in the context of the Specification. The examiner notes that limitation(s) of the applicant’s specification cannot be read into the claims.
Applicant argues:
“Davis paragraph 0044, by contrast, does not describe encoding ciphertext into a token at all. Davis 0044 describes merging an already-generated token with preserved input characters. The token in Davis already exists at the point described in paragraph 0044; the operation is a concatenation or assembly step that combines the token with preserved cleartext portions. “.
The examiner notes that applicant’s above assertion is simply not true. Davis teaches in par. 0041 the following: “During the first stage transformation, the computing device 100 performs FPE-based encryption on the extracted data to generate encrypted data: ENC.sub.FPE (key.sub.stage1,(tweak.sub.stage1 [|preserved]),”.
Davis teaches in par. 0043 the following: “[0043] During the third stage transformation, the computing device 100 performs FPE-based encryption on the extracted data or, more particularly, the alternative data to generate the token:”.
Applicant argues:
“This is analogous to the "assembled token" construction recited in dependent claim 9 (assembling a concatenation of non-tokenized cleartext portions and the token), not the "encoding the ciphertext output into token" step of independent claim 1. The Office has mapped a post- tokenization assembly operation (merging a token with preserved characters) to a pre-assembly encoding operation (converting ciphertext into a token through a lookup table). These are different operations that occur at different points in their respective processes and serve different purposes. Encoding ciphertext into a token produces the token itself. Merging a token with preserved input produces a composite output that includes the token. One is the creation of the token; the other is the use of a token that has already been created. “.
The examiner notes that the applicant has miss-characterized the teachings of Davis. Davis teaches in par. 0041 the following: “During the first stage transformation, the computing device 100 performs FPE-based encryption on the extracted data to generate encrypted data: ENC.sub.FPE (key.sub.stage1,(tweak.sub.stage1 [|preserved])”.
Davis teaches in par. 0043 the following: “During the third stage transformation, the computing device 100 performs FPE-based encryption on the extracted data or, more particularly, the alternative data to generate the token:”.
Applicant argues:
“Even under the broadest reasonable interpretation, "encoding the ciphertext output into token" requires a transformation that takes ciphertext and produces a token from it. Davis paragraph 0044 takes a token that already exists and merges it with other data.”.
The examiner notes that applicant’s current claim structure does not limit or restrict encoding. As such, the examiner notes that there are many reasonable interpretation(s)/implementation(s). (emphasis)
Applicant argues:
“No passage in Davis teaches encoding or converting ciphertext output into a token through a lookup table or any equivalent encoding mechanism. The mapping fails. “.
The examiner notes that applicant’s current claim structure of applicant’s independent claims 1, 12 and 17 do not recite applicant’s argued feature(s) of, “encoding or converting ciphertext output into a token through a lookup table or any equivalent encoding mechanism”. … Moreover, the examiner contends that such argument is improperly based on a claim limitation that is not explicitly recited in applicant’s current independent claims 1, 12 and 17 claim structure. Therefore, the argument(s) lacks merit. (emphasis)
Applicant argues:
“The motivation to combine is also deficient. The Office states that combining Shrimpton and Davis provides "comprehensive data integrity" and "enhanced data security." These are conclusory statements that could be applied to justify combining virtually any two references in the data security field. “.
The examiner respectfully disagrees. The examiner respectfully contends that both Shrimpton and Davis discloses tweaks and FPE-based encryption operations.
Applicant argues:
“The Office does not explain why a person of ordinary skill in the art, confronted with Shrimpton's theoretical VILTC framework, would have looked to Davis's multi- stage encryption and token merging system and combined them in the specific manner claimed. Shrimpton is a foundational cryptographic theory reference; Davis is an applied data masking system. The Office provides no articulated rationale for why these particular references would be combined in the particular manner the claims require, rather than in some other manner or not at all. See KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 418 (2007) (rejections must include an
articulated reasoning with a rational underpinning to support the legal conclusion of obviousness). “.
The examiner respectfully disagrees. The examiner respectfully contends that both Shrimpton and Davis discloses tweaks and FPE-based encryption operations.
Applicant argues:
“The Claimed Pipeline as a Whole Is Not Taught by the Combination Even setting aside each individual deficiency, the claims as a whole recite a specific multi-stage pipeline: pre-encryption lookup table encoding produces encoded input data; a separate tweak input is encoded and then hashed with a unique hashing key to generate a secure tweak governed by a token format schema; the encoded input data, secure tweak, and a unique encryption key are fed into an FPE algorithm to produce ciphertext; and the ciphertext is encoded into a token.“.
The examiner notes that the current claim structure of applicant’s independent claims 1, 12 and 17 do not explicitly recite applicant’s argued feature(s) of, “pipeline”. … Moreover, the examiner contends that such argument is improperly based on a claim limitation that is not explicitly recited in applicant’s current independent claims 1, 12 and 17 claim structure. Therefore, the argument(s) lacks merit. (emphasis)
Applicant argues:
“None of the cited references, alone or in combination, teaches or suggests this pipeline. Shrimpton teaches theoretical cryptographic constructions for format-preserving encryption. Davis teaches multi-stage encryption with token merging.”.
The examiner notes that applicant’s current claim structure of applicant’s independent claims 1, 12 and 17 do not recite applicant’s argued feature(s) of, “pipeline”. … Moreover, the examiner contends that such argument is improperly based on a claim limitation that is not explicitly recited in applicant’s current independent claims 1, 12 and 17 claim structure. Therefore, the argument(s) lacks merit. (emphasis)
Applicant argues:
“Neither reference teaches or suggests the combination of pre-encryption encoding via lookup tables, keyed-hash tweak generation from encoded tweak input, FPE encryption of the pre-encoded data, and post-encryption tokenization of ciphertext through lookup table encoding, all governed by a token format schema. “.
The examiner notes that applicant’s current claim structure of applicant’s independent claims 1, 12 and 17 do not recite applicant’s argued feature(s) of, “pre-encryption encoding via lookup tables, keyed-hash tweak generation from encoded tweak input, FPE encryption of the pre-encoded data, and post-encryption tokenization of ciphertext through lookup table encoding, all governed by a token format schema”. As such the examiner notes that applicant’s argument has no merit.
Applicant argues:
“The Office has deconstructed the claims into isolated fragments and then matched each fragment to the loosest possible analog in the cited art, without accounting for how the elements interact as a unified pipeline. This approach does not satisfy the requirements of Section 103. See MPEP 2141.02(VI) ("the test for obviousness is what the combined teachings of the references would have suggested to those of ordinary skill in the art"). “.
The examiner respectfully disagrees with the applicant’s above assertion. The examiner has noted prior art reference(s) to record that in combination, teaches each element of applicant’s recited claims.
Examiner’s Remarks - 35 U.S.C. Section 103 - Independent Claim 12
Applicant argues:
“II. INDEPENDENT CLAIM 12 IS NOT RENDERED OBVIOUS FOR THE SAME REASONS, AND ADDITIONALLY FOR THE "DISCARD" LIMITATION”.
Again, the examiner notes that applicant’s current claim 12 structure does not limit or restrict applicant’s operation of Discard. The examiner contends that the applicant points to and relies upon paragraph 0052 of their specification as a point of differentiation in this instance rather than the current claim structure of claim 12. The examiner respectfully suggest that the applicant should consider amending the current claim structure to include the argued feature(s) of paragraph 0052, if the applicant contentions are based on their par. 0052.
Applicant argues:
“Independent claim 12 recites the same pipeline as claim 1 in system form and additionally requires the processor to "discard the first data set or a cleartext input that comprises the first data set." The Office maps this to Davis paragraph 0044, asserting that Davis's process of merging a generated token with preserved input constitutes discarding. This mapping fails. Davis's token merging is an assembly operation in which preserved characters from the original input are concatenated with the generated token. The original data remains recoverable by reversing the process.”.
Again, the examiner notes that applicant’s current claim structure of applicant’s independent claims 1, 12 and 17 does not restrict the implementation of applicant’s recited claim limitation feature(s), “discard the first data set or a cleartext input that comprises the first data set”. As such, the examiner notes that there are many reasonable interpretation(s)/implementation(s). (emphasis)
Applicant argues:
"Discard" as claimed means permanent disposal such that the cleartext is not retained by any party and is only recoverable through the full detokenization and decryption process.”.
Again, the examiner notes that applicant’s current claim structure of applicant’s independent claim 12 does not restrict the implementation of applicant’s recited claim limitation feature(s), “discard the first data set or a cleartext input that comprises the first data set”. As such, the examiner notes that there are many reasonable interpretation(s)/implementation(s). (emphasis)
The examiner notes that Davis teaches in par. 0029 the following: “The data mapping module 210 is configured to replace “chunks” of data”.
Again, the examiner notes that the applicant argues a restriction(i.e., "Discard" as claimed means permanent disposal such that the cleartext is not retained by any party and is only recoverable through the full detokenization and decryption process”), however the current claim structure simply recites “discard the first data set or a cleartext input that comprises the first data set” and does not restrict the implementation or understanding of Discard.
Applicant argues:
“The Specification is explicit on this point: "no copy of the first data set or a cleartext input are stored after the token is generated" and the cleartext is disposed of "using any means that results in the first data set or the cleartext input being permanently inaccessible such as through deletion." See Specification at paragraph 0052.”.
The examiner contends that the applicant points to and relies upon paragraph 0052 of their specification as a point of differentiation in this instance. The examiner respectfully suggest that the applicant should consider amending the current claim structure to include the argued feature(s) of paragraph 0052.
Applicant argues:
“Even under the broadest reasonable interpretation, "discard" requires that the data be disposed of, not merely merged or assembled with other data into a composite output. Merging a token with preserved input characters does not discard anything; it combines data elements into a larger construct. The Office's equation of assembly with discarding is unreasonable. All other deficiencies identified with respect to claim 1 apply with equal force to claim 12. Claim 12 should be allowed independent of the discard limitation for the same reasons claim 1 should be allowed. “.
Again, the examiner notes that applicant’s current claim structure of applicant’s independent claim 12 does not restrict the implementation of applicant’s recited claim limitation feature(s), “discard the first data set or a cleartext input that comprises the first data set”. As such, the examiner notes that there are many reasonable interpretation(s)/implementation(s). (emphasis)
The examiner notes that Davis teaches in par. 0029 the following: “The data mapping module 210 is configured to replace “chunks” of data”.
The examiner notes that the applicant argues a restriction(i.e., "Discard" as claimed means permanent disposal such that the cleartext is not retained by any party and is only recoverable through the full detokenization and decryption process”), however the current claim structure simply recites “discard the first data set or a cleartext input that comprises the first data set” and does not restrict the implementation or understanding of Discard.
Examiner’s Remarks - 35 U.S.C. Section 103 - Independent Claim 17
Applicant argues:
“III. INDEPENDENT CLAIM 17 IS NOT RENDERED OBVIOUS FOR THE SAME REASONS, AND ADDITIONALLY FOR THE DETOKENIZATION AND DECRYPTION STEPS”.
The examiner contends that applicant’s remarks are not commensurate in scope with claim 17, as applicant’s claim 17 does not explicitly recite applicant’s argued feature(s) of, “DETOKENIZATION”. As such applicant’s above remarks concerning “DETOKENIZATION” has no merit.
The examiner notes that Davis teaches in par. 0013 the following: “the computing device 100 is configured to tokenize and detokenize data in a secure and efficient manner.”.
Applicant argues:
“Independent claim 17 recites both the tokenization path and the full round-trip detokenization and decryption path: decoding the ciphertext output from the token, regenerating the encoded tweak input, recovering the secret tweak by hashing the encoded tweak input along with the unique hashing key, decrypting the encoded input data by applying the FPE algorithm, decoding the first data set from the encoded input data, and reassembling the cleartext input. “.
The examiner notes that applicant’s claim 17 does not explicitly recite applicant’s argued feature(s) of, “round-trip detokenization”. The examiner contends that such argument is improperly based on a claim limitation that is not explicitly recited in applicant’s current independent claim 17 claim structure. Therefore, the argument(s) lacks merit. (emphasis)
The examiner notes that Davis teaches in par. 0013 the following: “the computing device 100 is configured to tokenize and detokenize data in a secure and efficient manner.”.
Applicant argues:
“The Office maps these detokenization steps to various passages in Shrimpton. For "regenerating the encoded tweak input," the Office cites Shrimpton paragraph 0158, which describes how the header H is typically transmitted in the clear along with the ciphertext in AEAD schemes with VILTCs, and that AEAD schemes may encode H into some related H for internal use. The Office then asserts that Shrimpton teaches that the tweak is in the header (citing paragraph 0177). This mapping is unreasonable. Shrimpton's header H is a protocol-level construct in an authenticated encryption with associated data (AEAD) scheme. It is metadata transmitted alongside ciphertext for routing and authentication purposes. It is not an "encoded tweak input" that is regenerated from stored or preserved data during a detokenization process. “.
First, the examiner notes that applicant’s current claim structure of applicant’s independent claim 17 does not restrict the implementation of applicant’s recited claim limitation feature(s), “regenerating the encoded tweak input”. As such, the examiner notes that there are many reasonable interpretation(s)/implementation(s). (emphasis) …
Second, the examiner notes that applicant’s claim 17 does not explicitly recite applicant’s argued feature(s) of, “detokenization process”. As such applicant’s above remarks concerning “detokenization process” has no merit.
The examiner notes that Davis teaches in par. 0013 the following: “the computing device 100 is configured to tokenize and detokenize data in a secure and efficient manner.”.
Applicant argues:
“The present claims require regenerating the encoded tweak input as part of a recovery process, which in the specification involves reassembling the tweak input from preserved portions of the cleartext (or from an entity-provided value) and then re-encoding it through the same lookup table used during the original encoding. See Specification at paragraphs 57-59. Shrimpton's transmission of header H alongside ciphertext in an AEAD protocol is a fundamentally different operation from the claimed regeneration of an encoded tweak input during detokenization. “.
The examiner respectfully contends that the applicant reads limitation(s) from their specification into the claims (i.e. “The present claims require regenerating the encoded tweak input as part of a recovery process, which in the specification involves reassembling the tweak input from preserved portions of the cleartext (or from an entity-provided value) and then re-encoding it through the same lookup table used during the original encoding”). The examiner notes that the current claim structure of applicant’s independent claim 17 does not restrict the implementation of applicant’s recited claim limitation feature(s), “regenerating the encoded tweak input” as argued. As such, the examiner notes that there are many reasonable interpretation(s)/implementation(s). (emphasis) …
Applicant argues:
“For recovering the secret tweak by hashing the encoded tweak input along with the unique hashing key," the Office again cites Shrimpton paragraph 0006 (TBC as a family of permutations associated with a key and a tweak). This mapping fails for the same reasons articulated with respect to claim 1: associating a permutation with a key and a tweak in a TBC does not teach recovering a secret tweak by applying a keyed hashing function to a regenerated encoded tweak input. The Office conflates the mathematical structure of the TBC (parameterized by key and tweak) with a specific operational step (hashing encoded tweak input to recover the tweak).”.
The examiner notes that applicant’s claim 17 does not explicitly recite applicant’s argued feature(s) of, “recovering a secret tweak by applying a keyed hashing function to a regenerated encoded tweak input”. As such applicant’s above remarks concerning “recovering a secret tweak by applying a keyed hashing function to a regenerated encoded tweak input” has no merit.
The claim language simply reads, “recovering the secret tweak by hashing the encoded tweak input along with the unique hashing key”. (emphasis)
Applicant argues:
“ For "decoding the ciphertext output from the token," the Office cites Shrimpton paragraph 0166 regarding Decode functions. Shrimpton's decode function is a mathematical construct in the formal definition of a codec, operating on abstract message spaces. It is not a practical operation of reversing a lookup-table-based tokenization to recover ciphertext from a token.“.
The examiner notes that the current claim structure of applicant’s independent claim 17 does not restrict the implementation of applicant’s recited claim limitation feature(s), “decoding the ciphertext output from the token”. As such, the examiner notes that there are many reasonable interpretation(s)/implementation(s). (emphasis)
Applicant argues:
“The present claims require decoding ciphertext from a token, which presupposes that a token was previously generated from ciphertext through a lookup table encoding. Shrimpton does not generate tokens from ciphertext and therefore does not teach decoding ciphertext from tokens. All deficiencies identified with respect to claim 1 apply with equal force to the tokenization-path steps of claim 17. The additional detokenization steps of claim 17 are separately not taught by any cited reference.“.
The examiner notes that the current claim structure of applicant’s independent claim 17 does not restrict the implementation of applicant’s recited claim limitation feature(s), “decoding the ciphertext output from the token”. As such, the examiner notes that there are many reasonable interpretation(s)/implementation(s). (emphasis)
The examiner contends that applicant’s “presupposes” cannot be done. (emphasis)
Again, the examiner notes that applicant’s claim 17 does not explicitly recite applicant’s argued feature(s) of, “DETOKENIZATION”. As such applicant’s above remarks concerning “DETOKENIZATION” has no merit.
The examiner notes that Davis teaches in par. 0013 the following: “the computing device 100 is configured to tokenize and detokenize data in a secure and efficient manner.”.
Examiner’s Remarks - 35 U.S.C. Section 103 - Dependent Claims 2-11 AND 13-16
Applicant argues:
“IV. DEPENDENT CLAIMS 2-11 AND 13-16 ARE NOT RENDERED OBVIOUS Each of claims 2-11 depends directly or indirectly from claim 1. Each of claims 13-16 depends directly or indirectly from claim 12. Because claims 1 and 12 are not rendered obvious for the reasons stated above, none of the dependent claims is rendered obvious. “.
The examiner respectfully disagrees for reasons noted above.
Applicant argues:
“Applicant additionally notes specific deficiencies in the Office's mappings for the dependent claims. For claim 5 (secure tweak created from an entity-provided value), the Office cites Shrimpton paragraph 0010 for "system tweak." A "system tweak" in Shrimpton is a parameter of the VILTC construction. It is not an entity-provided value in the sense claimed, where a specific entity (e.g., a company processing credit cards) provides a tweak input that is unique to that entity and that is then encoded and hashed to generate the secure tweak. See Specification at paragraphs 0050 and 0062. “.
The examiner notes that applicant’s current claim structure of applicant’s dependent claim 5 does not restrict the implementation of applicant’s recited claim limitation feature(s), “system tweak”. As such, the examiner notes that there are many reasonable interpretation(s)/implementation(s). (emphasis)
The examiner contends that the applicant points to and relies upon paragraph 0050 and 0062 of their specification as a point of differentiation in this instance rather than the current constructed claim language. The examiner respectfully suggest that the applicant should consider amending the current claim structure to include the argued feature(s) of paragraphs 0050 and 0062.
Applicant argues:
“For claims 6-8 (first, second, and third lookup tables for encoding the first data set, encoding the tweak input, and converting ciphertext to a token, respectively), the Office cites Shrimpton paragraph 0012 (permutation lookup tables) and paragraph 0081 (tweak used to select among permutation lookup tables). The claims require three distinct lookup tables used at three distinct stages of the pipeline. Shrimpton's permutation lookup tables are internal cipher components. The Office's mapping of paragraph 0081 (where the tweak selects among a family of randomly generated permutation lookup tables) to the claimed second and third lookup tables is unreasonable. In Shrimpton, the tweak selects which permutation lookup table the cipher uses during encryption. In the present claims, the second lookup table encodes the tweak input into an encoded tweak input (a pre-hashing encoding step), and the third lookup table converts ciphertext output into a token (a post-encryption tokenization step). These are completely different operations. The tweak in Shrimpton governs internal cipher behavior. The lookup tables in the present claims perform external encoding and tokenization operations that bracket the cipher on both ends. “.
The examiner notes applicant’s dependent claims 6-8:
6. (Original) The method according to claim 5, wherein the first data set is encoded into the encoded input data using a first lookup table, wherein the first lookup table is unique to an entity that provided the cleartext input.
7. (Original) The method according to claim 6, wherein the tweak input is encoded using a second lookup table.
8. (Original) The method according to claim 7, wherein generating the token from the ciphertext output includes using a third lookup table to convert the ciphertext output into the token.
The examiner notes that the current claim structure of applicant’s dependent claims 6-8 do not recite the claim limitation feature(s) as argued (i.e., …”a pre-hashing encoding step” & “post-encryption tokenization step”).
Applicant argues:
“For claim 9 (assembling an assembled token as a concatenation of non-tokenized cleartext portions and the token), neither Shrimpton nor Davis teaches constructing a composite output that preserves the format and length of the original cleartext by concatenating untokenized cleartext portions with the generated token.“.
The examiner notes that applicant’s claim 9 does not explicitly recite applicant’s argued feature(s) of, “constructing a composite output that preserves the format and length of the original cleartext by concatenating untokenized cleartext portions with the generated token”. As such applicant’s above remarks concerning “constructing a composite output that preserves the format and length of the original cleartext by concatenating untokenized cleartext portions with the generated token” has no merit.
The examiner notes applicant’s dependent claim 9:
9. (Original) The method according to claim 8, wherein generating the token from the ciphertext output further comprises assembling an assembled token as a concatenation of the one or more portions of the cleartext input that are not tokenized and the token, as specified in the token format schema.
Applicant argues:
“Shrimpton operates on the entirety of its input through the TBC. Davis's merging operation at paragraph 0044 concatenates a token with preserved input, but Davis does not generate the token through the multi-stage pipeline claimed (pre-encryption encoding, keyed-hash tweak generation, FPE, lookup-table tokenization) and therefore does not teach the assembled token recited in claim 9, which requires assembly "as specified in the token format schema" of a token generated through the claimed pipeline. “.
The examiner notes that applicant’s claim 9 does not explicitly recite applicant’s argued feature(s) of, “generate the token through the multi-stage pipeline claimed (pre-encryption encoding, keyed-hash tweak generation, FPE, lookup-table tokenization”. As such applicant’s above remarks concerning “generate the token through the multi-stage pipeline claimed (pre-encryption encoding, keyed-hash tweak generation, FPE, lookup-table tokenization” has no merit.
The examiner notes applicant’s dependent claim 9:
9. (Original) The method according to claim 8, wherein generating the token from the ciphertext output further comprises assembling an assembled token as a concatenation of the one or more portions of the cleartext input that are not tokenized and the token, as specified in the token format schema.
Applicant argues:
“For claim 10 (third lookup table comprises alphabetic characters while first and second lookup tables comprise numeric characters), Shrimpton contains no disclosure of lookup tables with differentiated character sets. Shrimpton's permutation tables are abstract mathematical objects.”.
The examiner notes applicant’s dependent claim 10:
10. (Original) The method according to claim 8, wherein the third lookup table comprises alphabetic characters, whereas the first lookup table and the second lookup table comprise numeric characters.
The examiner notes that there are many reasonable interpretation(s)/implementation(s) for applicant’s recited alphabetic characters & numeric characters feature(s). (emphasis)
The examiner notes that applicant’s current claim structure of applicant’s dependent claim 10 does not restrict the implementation of applicant’s recited claim limitation feature(s), “alphabetic characters & numeric characters” as argued.
Applicant argues:
“The present claim requires a practical implementation where different encoding stages use tables with different character types, specifically alphabetic characters for the tokenization table and numeric characters for the data encoding and tweak encoding tables. “.
The examiner notes that applicant’s claim 10 does not explicitly recite applicant’s argued feature(s) of, “specifically alphabetic characters for the tokenization table and numeric characters for the data encoding and tweak encoding tables”. As such applicant’s above remarks concerning “specifically alphabetic characters for the tokenization table and numeric characters for the data encoding and tweak encoding tables” has no merit.
The examiner notes applicant’s dependent claim 10:
10. (Original) The method according to claim 8, wherein the third lookup table comprises alphabetic characters, whereas the first lookup table and the second lookup table comprise numeric characters.
Applicant argues:
“None of the cited references, alone or in combination, teaches or renders obvious the subject matter of claims 1-17. “.
The examiner respectfully disagrees, for reasons noted above.
Applicant argues:
“The Office's mappings rely on interpretations that, while perhaps the broadest possible readings of the claim language, are not the broadest reasonable readings consistent with the specification and the understanding of one skilled in the art. Shrimpton's theoretical VILTC/TBC constructions are not the multi-stage applied tokenization pipeline recited in the claims. Davis's token merging system does not supply the missing limitations. The motivation to combine is conclusory. Applicant respectfully requests withdrawal of all rejections under 35 U.S.C. 103 and allowance of claims 1-17.“.
The examiner respectfully disagrees. The examiner contends that applicant’s arguments are not commensurate in scope with the broadest reasonable interpretation of their independent claims. The examiner contends that the current claim structure of applicant’s independent claims 1, 12 and 17 are very board and encompassing. As such, the examiner notes that there are many reasonable interpretation(s)/implementation(s). (emphasis) … The applicant relies on exerts noted from their specification to support their argued deficiency assertions on the part of the cited prior art and “presupposed” claim limitation(s) rather than relying on the current claim structure of their independent claims 1, 12 and 17.
The examiner respectfully suggest that the applicant really consider amending the current claim structure of their independent claims 1, 12 and 17 to more clearly and distinctly reflect the necessary subject matter the applicant believes the cited prior art of record does not teach.
Claim Objections
Claim 3 objected to because of the following informalities: “another…”. Appropriate correction is required.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1, 12 and 17 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1, 10 and 15 of U.S. Patent No. 11,979,500 and 500’ hereinafter. Although the claims at issue are not identical, they are not patentably distinct from each other because both sets of claims are drawn to the following:
(18630737) Claim 1. A method, comprising: encoding a first data set to produce encoded input data; generating a secure tweak for the encoded input data based on a token format schema by: encoding a tweak input to produce an encoded tweak input; and hashing the encoded tweak input along with a unique hashing key to generate the secure tweak; applying a format preserving encryption algorithm that utilizes the encoded input data, the secure tweak, and a unique encryption key to generate ciphertext output; and encoding the ciphertext output into token; maps to (764’) claim 1 A method, comprising: receiving clear text data; identifying a first data set from the clear text data, the first data set including at least some sensitive data; identifying a specific endpoint from which the clear text data was received; identifying a lookup table linked to the specific endpoint; shuffling the lookup table one or more times; encoding the first data set using the lookup table to produce encoded input data; generating a secure tweak for the encoded input data based on a token format schema by: encoding a tweak input to produce an encoded tweak input; and hashing the encoded tweak input along with a unique hashing key to generate the secure tweak; applying a format preserving encryption algorithm that utilizes the encoded input data, the secure tweak, and a unique encryption key to generate ciphertext output; and encoding the ciphertext output into token.
(18630737) Claim 12. A system, comprising: a processor; and memory for storing executable instructions, the processor being configured to execute the instructions to: encode a first data set to produce encoded input data; generate a secure tweak for the encoded input data based on a token format schema by: encode a tweak input to produce an encoded tweak input; and hash the encoded tweak input along with a unique hashing key to generate the secure tweak; apply a format preserving encryption algorithm that utilizes the encoded input data, the secure tweak, and a unique encryption key to generate ciphertext output; generate a token from the ciphertext output; and discard the first data set or a cleartext input that comprises the first data set; maps to (500’) claim 10. A system, comprising: a processor; and memory for storing executable instructions, the processor being configured to execute the instructions to: receive clear text data; identify a first data set from the clear text data, the first data set including at least some sensitive data; identify a specific endpoint from which the clear text data was received; identify a lookup table linked to the specific endpoint; shuffle the lookup table one or more times; encode the first data set using the lookup table to produce encoded input data; generate a secure tweak for the encoded input data based on a token format schema by: encode a tweak input to produce an encoded tweak input; and hash the encoded tweak input along with a unique hashing key to generate the secure tweak; apply a format preserving encryption algorithm that utilizes the encoded input data, the secure tweak, and a unique encryption key to generate ciphertext output; generate a token from the ciphertext output; and discard the first data set or a cleartext input that comprises the first data set.
(18630737) Claim 17. A method, comprising: encoding a first data set of a cleartext input to produce encoded input data; encoding a tweak input to produce an encoded tweak input; hashing the encoded tweak input along with a unique hashing key to generate a secure tweak; applying a format preserving encryption algorithm that utilizes the encoded input data,the secure tweak, and a unique encryption key to generate ciphertext output; generating a token from the ciphertext output; receiving a request to obtain the cleartext input; decoding the ciphertext output from the token; regenerating the encoded tweak input; recovering the secret tweak by hashing the encoded tweak input along with the unique hashing key; decrypting the encoded input data by applying the format preserving encryption algorithm that utilizes the ciphertext output, the secure tweak, and the unique encryption key; decoding the first data set from the encoded input data; and reassembling the cleartext input using the first data set; maps to (500’) claim 15. A method, comprising: receiving clear text data; identifying a first data set from the clear text data, the first data set including at least some sensitive data; identifying a specific endpoint from which the clear text data was received; identifying a lookup table linked to the specific endpoint; shuffling the lookup table one or more times; encoding the first data set using the lookup table to produce encoded input data; encoding a tweak input to produce an encoded tweak input; hashing the encoded tweak input along with a unique hashing key to generate a secure tweak; applying a format preserving encryption algorithm that utilizes the encoded input data, the secure tweak, and a unique encryption key to generate ciphertext output; generating a token from the ciphertext output; receiving a request to obtain the cleartext input; decoding the ciphertext output from the token; regenerating the encoded tweak input; recovering the secret tweak by hashing the encoded tweak input along with the unique hashing key; decrypting the encoded input data by applying the format preserving encryption algorithm that utilizes the ciphertext output, the secure tweak, and the unique encryption key; decoding the first data set from the encoded input data; and reassembling the cleartext input using the first data set.
Claim Rejections - 35 USC § 103
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.
Claims 1-17 are rejected under 35 U.S.C. 103 as being unpatentable over Shrimpton et al. (US Patent Publication No. 2015/0349950 and Shrimpton hereinafter (cited from IDS date 04/09/2024)) in view of Davis et al. (US Patent Publication No. 2016/0019396 and Davis hereinafter (cited from IDS date 04/09/2024)).
As to claim 1, Shrimpton teaches a method, comprising:
encoding a first data set to produce encoded input data (i.e., … Shrimpton teaches in paragraph 0102 the following: “system obscures (440) the fixed-length initialization vector. For example, the fixed-length initialization vector is obscured by a FIL TBC, which produces a fixed-length output string (e.g., N-bit output string, N-character output string) based on the fixed-length initialization vector,”);
and hashing the encoded tweak input along with a unique hashing key to generate the secure tweak (i.e., … Shrimpton teaches in paragraph 0112 the following: “NH[r, s].sub.L takes r-bit keys (|L|=r), maps r-bit strings to s-bit strings, and is 2.sup.s/2-AU. Given a TBC [tilde over (E)], [tilde over (E)].sup.NH denotes the resulting TBC whose tweak space is now the domain of NH, rather than its range.”).
The system of Shrimpton does not expressly teach:
generating a secure tweak for the encoded input data based on a token format schema by;
encoding a tweak input to produce an encoded tweak input;
applying a format preserving encryption algorithm that utilizes the encoded input data, the secure tweak, and a unique encryption key to generate ciphertext output;
and encoding the ciphertext output into token.
In this instance the examiner notes the teachings of Davis.
With regards to applicant’s claim limitation of, “generating a secure tweak for the encoded input data based on a token format schema by”, Davis teaches in paragraph 0014 the following: “the computing device 100 applies an initial FPE-based transformation that ensures that the plaintext (e.g., clear-text) input to be tokenized is a pseudo-random value for which all positional dependence has been obfuscated.”. Davis teaches in paragraph 0014 the following: “tweaks in the first and/or third stage FPE-based transformations may be utilized to uniquely multiplex the generated tokens to be unique for individual merchants, merchant groups, services, and/or other suitable entities.”.
With regards to applicant’s claim limitation of, “encoding a tweak input to produce an encoded tweak input”, Davis teaches in paragraph 0047 the following: “in block 516, include the preserved character(s) in the third stage cryptographic tweak (e.g., by appending the preserved character(s) to the cryptographic tweak) as described above.”.
With regards to applicant’s claim limitation element of, “applying a format preserving encryption algorithm that utilizes the encoded input data, the secure tweak, and a unique encryption key to generate ciphertext output”, Davis teaches in paragraph 0047 the following: “the computing device 100 may utilize data domain-specific FPE encryption with the pre-computed application third stage symmetric key and tweak described above. As discussed above, in some embodiments, the computing device 100 may identify one or more character(s) of the input data to preserve. As such, in block 514, the computing device 100 may preserve the identified character(s), for example, by storing those characters in the memory 114, the data storage 116, and/or the database 124. Further, in some embodiments, the computing device 100 may, in block 516, include the preserved character(s) in the third stage cryptographic tweak (e.g., by appending the preserved character(s) to the cryptographic tweak) as described above.”.
With regards to applicant’s claim limitation element of, “and encoding the ciphertext output into token”, Davis teaches in paragraph 0044 the following: “The computing device 100 may merge the generated token with the original preserved input (e.g., "23456") if any to generate a merged token (e.g., "6745911474123456"). That is, the generated token is merged with the characters preserved from the original input. As discussed above, the computing device 100 may further repackage the token (or merged token) in the file at the appropriate location.”.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Shrimpton with the teachings of Davis by including the feature of enhanced data tokenization. Utilizing enhanced data tokenization as taught by Davis above affords a system to provide comprehensive data integrity and therefore provides the motivation in this instance to combine the references. The examiner contends that by combining the references, Shrimpton's system will obtain the capability to provide enhanced data security.
As to claim 2, the system of Shrimpton and Davis as applied to claim 1 above teaches tweak value, specifically Shrimpton teaches a method according to claim 1, further comprising receiving a cleartext input, wherein the first data set is a part of the cleartext input (i.e., …teaches in paragraph 0074 the following: “variable-length input string”).
As to claim 3, the system of Shrimpton and Davis as applied to claim 1 above teaches tweak value, specifically Shrimpton teaches a method according to claim 2, wherein the tweak input comprises another part of the cleartext input (i.e., …teaches in his abstract the following: “the fixed-length initialization vector as a tweak”).
As to claim 4, the system of Shrimpton and Davis as applied to claim 1 above teaches tweak value, specifically Shrimpton teaches a method according to claim 3, wherein the secure tweak is created from one or more portions of the cleartext input that are not tokenized (i.e., …teaches in paragraph 0006 the following: “A tweakable block cipher ("TBC") is a generalization of a block cipher. An n-character TBC [tilde over (E)] is a family of permutations over .SIGMA..sup.n, where each permutation in the TBC is associated with a key and a tweak. Often, .SIGMA.=[0,1], in which case the TBC can be termed an n-bit TBC [tilde over (E)].) For an input string, the key and tweak together specify the permutation of the input string that is produced by the TBC.”).
As to claim 5, the system of Shrimpton and Davis as applied to claim 1 above teaches tweak value, specifically Shrimpton teaches a method according to claim 4, wherein the secure tweak is created from an entity-provided value (i.e., …teaches in paragraph 0010 the following: “system tweak”).
As to claim 6, the system of Shrimpton and Davis as applied to claim 1 above teaches tweak value, specifically Shrimpton teaches a method according to claim 5, wherein the first data set is encoded into the encoded input data using a first lookup table (i.e., …teaches in paragraph 0012 the following: “… look-up tables”),
wherein the first lookup table is unique to an entity that provided the cleartext input (i.e., …teaches in paragraph 0012 the following: “permutation look-up tables”).
As to claim 7, the system of Shrimpton and Davis as applied to claim 1 above teaches tweak value, specifically Shrimpton teaches a method according to claim 6, wherein the tweak input is encoded using a second lookup table (i.e., …teaches in paragraph 0081 the following: “tweak is used to select among a family of randomly generated permutation look-up tables”).
As to claim 8, the system of Shrimpton and Davis as applied to claim 1 above teaches tweak value, specifically Shrimpton teaches a method according to claim 7, wherein generating the token from the ciphertext output includes using a third lookup table to convert the ciphertext output into the token (i.e., …teaches in paragraph 0081 the following: “tweak is used to select among a family of randomly generated permutation look-up tables”).
As to claim 9, the system of Shrimpton and Davis as applied to claim 1 above teaches tweak value, specifically Shrimpton teaches a method according to claim 8, wherein generating the token from the ciphertext output further comprises assembling an assembled token as a concatenation of the one or more portions of the cleartext input that are not tokenized and the token, as specified in the token format schema (i.e., …teaches in paragraph 0079 the following: “the second N-character TBC (340b) is adapted to produce the N-character output string (351b) using the N-character initialization vector (328b), as its input, and a combination (e.g., concatenation or other adjustment) of the tweak (318) and the variable-length output string (352), as its tweak”).
As to claim 10, the system of Shrimpton and Davis as applied to claim 1 above teaches tweak value, specifically Shrimpton teaches a method according to claim 8, wherein the third lookup table comprises alphabetic characters (i.e., …teaches in paragraph 0081 the following: “a family of randomly generated permutation look-up tables”),
whereas the first lookup table and the second lookup table comprise numeric characters (i.e., …teaches in paragraph 0081 the following: “a family of randomly generated permutation look-up tables”).
As to claim 11, the system of Shrimpton and Davis as applied to claim 1 above teaches tweak value, specifically Shrimpton teaches a method according to claim 1, further comprising:
decoding the ciphertext output from the token (i.e., …teaches in paragraph 004 the following: “decode the ciphertext’);
regenerating the encoded tweak input (i.e., …teaches in paragraph 0158 the following: “the header H is typically transmitted in the clear along with the ciphertext (e.g., when the header is needed for routing), but AEAD schemes with VILTCs may also encode H into some related H for internal use. If this encoding is non-deterministic, the reconstruction information R delivers whatever is used by decryption to properly reconstruct this H from H.” …The examiner notes that Shrimpton tells us that tweak is in the Header. (e.g., par.0177 “header providing the tweak” );
recovering the secret tweak by hashing the encoded tweak input along with the unique hashing key (i.e., …teaches in paragraph 0006 the following; “A tweakable block cipher ("TBC") is a generalization of a block cipher. An n-character TBC [tilde over (E)] is a family of permutations over .SIGMA..sup.n, where each permutation in the TBC is associated with a key and a tweak.)”;
decrypting the encoded input data by applying the format preserving encryption algorithm that utilizes the ciphertext output, the secure tweak, and the unique encryption key (i.e., …teaches in paragraph 0020 the following: “format-preserving decryption”);
decoding the first data set from the encoded input data (i.e., …teaches in paragraph 0166 the following: “Decode.sub.M( H, M)=M.di-elect cons. if and only if Pr[Encode.sub.M( H, M)= M]>0 for some state of Encode.sub.M; otherwise. Decode.sub.M ( H, M) .di-elect cons.”);
and reassembling the cleartext input using the first data set (i.e., …teaches in paragraph 0073 the following: “the generalized constructions (300, 301, 302) can be used for decryption, in which a fixed-length input string Y.sub.L and variable-length input string Y.sub.R of ciphertext are converted to a fixed-length output string X.sub.L and variable-length output string X.sub.R of plaintext..” …teaches in paragraph 0027 the following: “A corresponding decryption system receives a header and an encrypted message (along with any reconstruction information).”).
As to claim 12, Shrimpton teaches a system, comprising:
a processor (i.e., … Shrimpton teaches in par. 0046 the following: “the computing system (100) includes one or more processing units (110, 115) and memory (120, 125). The processing units (110, 115) execute computer-executable instructions. A processing unit can be a general-purpose central processing unit ("CPU"), processor in an application-specific integrated circuit ("ASIC") or any other type of processor. In a multi-processing system, multiple processing units execute computer-executable instructions to increase processing power”),
memory for storing executable instructions, the processor being configured to execute the instruction to (i.e., … Shrimpton teaches in par. 0046 the following: “the computing system (100) includes one or more processing units (110, 115) and memory (120, 125). The processing units (110, 115) execute computer-executable instructions. A processing unit can be a general-purpose central processing unit ("CPU"), processor in an application-specific integrated circuit ("ASIC") or any other type of processor. In a multi-processing system, multiple processing units execute computer-executable instructions to increase processing power”);
encode a first data set to produce encoded input data (i.e., … Shrimpton teaches in paragraph 0102 the following: “system obscures (440) the fixed-length initialization vector. For example, the fixed-length initialization vector is obscured by a FIL TBC, which produces a fixed-length output string (e.g., N-bit output string, N-character output string) based on the fixed-length initialization vector”);
hash the encoded tweak input along with a unique hashing key to generate a secure tweak (i.e., … Shrimpton teaches in paragraph 0112 the following: “NH[r, s].sub.L takes r-bit keys (|L|=r), maps r-bit strings to s-bit strings, and is 2.sup.s/2-AU. Given a TBC [tilde over (E)], [tilde over (E)].sup.NH denotes the resulting TBC whose tweak space is now the domain of NH, rather than its range.”);
generate a token from the ciphertext output (i.e., … Shrimpton teaches in paragraph 0012 the following: “The first N-character TBC, the VILTC and the second N-character TBC can be constructed from randomly generated permutation look-up tables”. …The examiner notes paragraph 0014 states the following: “N-bit tweakable block ciphers ("TBCs")”).
Shrimpton does not expressly teach:
generate a secure tweak for the encoded input data based on a token format schema by: encode a tweak input to produce an encoded tweak input;
apply a format preserving encryption algorithm that utilizes the encoded input data, the secure tweak, and a unique encryption key to generate ciphertext output,
discard the first data set or a cleartext input that comprises the first data set.
In this instance the examiner notes the teachings of Davis.
With regards to applicant’s claim limitation element of, “generate a secure tweak for the encoded input data based on a token format schema by: encode a tweak input to produce an encoded tweak input”, Davis teaches in paragraph 0044 the following: “The computing device 100 may merge the generated token with the original preserved input (e.g., "23456") if any to generate a merged token (e.g., "6745911474123456"). That is, the generated token is merged with the characters preserved from the original input. As discussed above, the computing device 100 may further repackage the token (or merged token) in the file at the appropriate location. ”.
With regards to applicant’s claim limitation element of, “applying a format preserving encryption algorithm that utilizes the encoded input data, the secure tweak, and a unique encryption key to generate ciphertext output”, Davis teaches in paragraph 0047 the following: “the computing device 100 may utilize data domain-specific FPE encryption with the pre-computed application third stage symmetric key and tweak described above. As discussed above, in some embodiments, the computing device 100 may identify one or more character(s) of the input data to preserve. As such, in block 514, the computing device 100 may preserve the identified character(s), for example, by storing those characters in the memory 114, the data storage 116, and/or the database 124. Further, in some embodiments, the computing device 100 may, in block 516, include the preserved character(s) in the third stage cryptographic tweak (e.g., by appending the preserved character(s) to the cryptographic tweak) as described above.”.
With regards to applicant’s claim limitation element of, “discard the first data set or a cleartext input that comprises the first data set”, Davis teaches in par. 0036 the following: “the computing device 100 looks up each chunk or portion of the encrypted data from the first stage in the appropriate static mapping data and replaces it with the alternative data”. The examiner notes that the process of replacing discards the initial values.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Shrimpton with the teachings of Davis by including the feature of enhanced data tokenization. Utilizing enhanced data tokenization as taught by Davis above affords a system to provide comprehensive data integrity and therefore provides the motivation in this instance to combine the references. The examiner contends that by combining the references, Shrimpton's system will obtain the capability to provide enhanced data security.
As to claim 13, the system of Shrimpton and Davis as applied to claim 12 above teaches tweak value, specifically Shrimpton teaches a system according to claim 12, wherein the processor is further configured to encode the first data set using a lookup table (i.e., …teaches in paragraph 0012 the following: “The first N-character TBC, the VILTC and the second N-character TBC can be constructed from randomly generated permutation look-up tables”).
As to claim 14, the system of Shrimpton and Davis as applied to claim 12 above teaches tweak value, specifically Shrimpton teaches a system according to claim 13, wherein the processor is further configured to encode the tweak input using the lookup table (i.e., …teaches in paragraph 0012 the following: “The first N-character TBC, the VILTC and the second N-character TBC can be constructed from randomly generated permutation look-up tables”. …The examiner notes paragraph 0014 states the following: “N-bit tweakable block ciphers ("TBCs")”).
As to claim 15, the system of Shrimpton and Davis as applied to claim 12 above teaches tweak value, specifically Shrimpton teaches a system according to claim 14, wherein the processor is further configured to generate the token from the ciphertext output using the lookup table (i.e., …teaches in paragraph 0012 the following: “The first N-character TBC, the VILTC and the second N-character TBC can be constructed from randomly generated permutation look-up tables”. …The examiner notes paragraph 0014 states the following: “N-bit tweakable block ciphers ("TBCs")”).
As to claim 16, the system of Shrimpton and Davis as applied to claim 12 above teaches tweak value, specifically Shrimpton teaches a system according to claim 12, further comprising:
decode the ciphertext output from the token using the lookup table (i.e., …teaches in paragraph 004 the following: “decode the ciphertext’ … teaches in paragraph 0012 the following: “The first N-character TBC, the VILTC and the second N-character TBC can be constructed from randomly generated permutation look-up tables”.);
regenerate the encoded tweak input (i.e., …teaches in paragraph 0158 the following: “the header H is typically transmitted in the clear along with the ciphertext (e.g., when the header is needed for routing), but AEAD schemes with VILTCs may also encode H into some related H for internal use. If this encoding is non-deterministic, the reconstruction information R delivers whatever is used by decryption to properly reconstruct this H from H.” …The examiner notes that Shrimpton tells us that tweak is in the Header. (e.g., par.0177 “header providing the tweak” );
recover the secret tweak by hashing the encoded tweak input along with the unique hashing key (i.e., …teaches in paragraph 0006 the following; “A tweakable block cipher ("TBC") is a generalization of a block cipher. An n-character TBC [tilde over (E)] is a family of permutations over .SIGMA..sup.n, where each permutation in the TBC is associated with a key and a tweak.)”;
decrypt the encoded input data by applying the format preserving encryption algorithm that utilizes the ciphertext output, the secure tweak, and the unique encryption key (i.e., …teaches in paragraph 0020 the following: “format-preserving decryption”);
decode the first data set from the encoded input data (i.e., …teaches in paragraph 0166 the following: “Decode.sub.M( H, M)=M.di-elect cons. if and only if Pr[Encode.sub.M( H, M)= M]>0 for some state of Encode.sub.M; otherwise. Decode.sub.M ( H, M) .di-elect cons.”);
and reassemble the cleartext input using the first data set (i.e., …teaches in paragraph 0073 the following: “the generalized constructions (300, 301, 302) can be used for decryption, in which a fixed-length input string Y.sub.L and variable-length input string Y.sub.R of ciphertext are converted to a fixed-length output string X.sub.L and variable-length output string X.sub.R of plaintext..” …teaches in paragraph 0027 the following: “A corresponding decryption system receives a header and an encrypted message (along with any reconstruction information).”).
As to claim 17, Shrimpton teaches a method, comprising:
encoding a first data set of a cleartext input to produce encoded input data (i.e., … Shrimpton teaches in paragraph 0102 the following: “system obscures (440) the fixed-length initialization vector. For example, the fixed-length initialization vector is obscured by a FIL TBC, which produces a fixed-length output string (e.g., N-bit output string, N-character output string) based on the fixed-length initialization vector”);
hashing the encoded tweak input along with a unique hashing key to generate a secure tweak (i.e., … Shrimpton teaches in paragraph 0112 the following: “NH[r, s].sub.L takes r-bit keys (|L|=r), maps r-bit strings to s-bit strings, and is 2.sup.s/2-AU. Given a TBC [tilde over (E)], [tilde over (E)].sup.NH denotes the resulting TBC whose tweak space is now the domain of NH, rather than its range.”);
generating a token from the ciphertext output (i.e., … Shrimpton teaches in paragraph 0012 the following: “The first N-character TBC, the VILTC and the second N-character TBC can be constructed from randomly generated permutation look-up tables”. …The examiner notes paragraph 0014 states the following: “N-bit tweakable block ciphers ("TBCs")”);
receiving a request to obtain the cleartext input (i.e., … Shrimpton teaches in paragraph 0102 the following: “system obscures (440) the fixed-length initialization vector. For example, the fixed-length initialization vector is obscured by a FIL TBC, which produces a fixed-length output string (e.g., N-bit output string, N-character output string) based on the fixed-length initialization vector”);
decoding the ciphertext output from the token (i.e., … Shrimpton teaches in paragraph 0166 the following: “Decode.sub.M( H, M)=M.di-elect cons. if and only if Pr[Encode.sub.M( H, M)= M]>0 for some state of Encode.sub.M; otherwise. Decode.sub.M ( H, M) .di-elect cons.”);
regenerating the encoded tweak input (i.e., … Shrimpton teaches in paragraph 0158 the following: “the header H is typically transmitted in the clear along with the ciphertext (e.g., when the header is needed for routing), but AEAD schemes with VILTCs may also encode H into some related H for internal use. If this encoding is non-deterministic, the reconstruction information R delivers whatever is used by decryption to properly reconstruct this H from H.” …The examiner notes that Shrimpton tells us that tweak is in the Header. (e.g., par.0177 “header providing the tweak”);
recovering the secret tweak by hashing the encoded tweak input along with the unique hashing key (i.e., … Shrimpton teaches in paragraph 0006 the following; “A tweakable block cipher ("TBC") is a generalization of a block cipher. An n-character TBC [tilde over (E)] is a family of permutations over .SIGMA..sup.n, where each permutation in the TBC is associated with a key and a tweak.);
decrypting the encoded input data by applying the format preserving encryption algorithm that utilizes the ciphertext output, the secure tweak, and the unique encryption key (i.e., … Shrimpton teaches in paragraph 0020 the following: “format-preserving decryption”);
decoding the first data set from the encoded input data (i.e., … Shrimpton teaches in paragraph 0166 the following: “Decode.sub.M( H, M)=M.di-elect cons. if and only if Pr[Encode.sub.M( H, M)= M]>0 for some state of Encode.sub.M; otherwise. Decode.sub.M ( H, M) .di-elect cons.”);
and reassembling the cleartext input using the first data set (i.e., … Shrimpton teaches in paragraph 0073 the following: “the generalized constructions (300, 301, 302) can be used for decryption, in which a fixed-length input string Y.sub.L and variable-length input string Y.sub.R of ciphertext are converted to a fixed-length output string X.sub.L and variable-length output string X.sub.R of plaintext..” …teaches in paragraph 0027 the following: “A corresponding decryption system receives a header and an encrypted message (along with any reconstruction information).”).
The system of Shrimpton does not expressly teach:
encoding a tweak input to produce an encoded tweak input;
applying a format preserving encryption algorithm that utilizes the encoded input data, the secure tweak, and a unique encryption key to generate ciphertext output.
In this instance the examiner notes the teachings of Davis.
With regards to applicant’s claim limitation element of, “encoding a tweak input to produce an encoded tweak input”, Davis teaches in paragraph 0044 the following: “The computing device 100 may merge the generated token with the original preserved input (e.g., "23456") if any to generate a merged token (e.g., "6745911474123456"). That is, the generated token is merged with the characters preserved from the original input. As discussed above, the computing device 100 may further repackage the token (or merged token) in the file at the appropriate location. ”.
With regards to applicant’s claim limitation element of, “applying a format preserving encryption algorithm that utilizes the encoded input data, the secure tweak, and a unique encryption key to generate ciphertext output”, Davis teaches in paragraph 0047 the following: “the computing device 100 may utilize data domain-specific FPE encryption with the pre-computed application third stage symmetric key and tweak described above. As discussed above, in some embodiments, the computing device 100 may identify one or more character(s) of the input data to preserve. As such, in block 514, the computing device 100 may preserve the identified character(s), for example, by storing those characters in the memory 114, the data storage 116, and/or the database 124. Further, in some embodiments, the computing device 100 may, in block 516, include the preserved character(s) in the third stage cryptographic tweak (e.g., by appending the preserved character(s) to the cryptographic tweak) as described above.”.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Shrimpton with the teachings of Davis by including the feature of enhanced data tokenization. Utilizing enhanced data tokenization as taught by Davis above affords a system to provide comprehensive data integrity and therefore provides the motivation in this instance to combine the references. The examiner contends that by combining the references, Shrimpton's system will obtain the capability to provide enhanced data security.
Conclusion
THIS ACTION IS MADE FINAL. 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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRYAN F WRIGHT whose telephone number is (571)270-3826.
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, Eleni Shiferaw can be reached on (571)272-3867. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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://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). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BRYAN F WRIGHT/Examiner, Art Unit 2497
Prosecution Insights