Prosecution Insights
Last updated: April 19, 2026
Application No. 18/208,616

SYSTEM AND METHOD FOR PROTECTING FORM FIELD SENSITIVE DATA WITH DYNAMIC USER FEEDBACK

Non-Final OA §103
Filed
Jun 12, 2023
Examiner
STRAUB, D'ARCY WINSTON
Art Unit
2491
Tech Center
2400 — Computer Networks
Assignee
Capital One Services LLC
OA Round
3 (Non-Final)
77%
Grant Probability
Favorable
3-4
OA Rounds
3y 1m
To Grant
97%
With Interview

Examiner Intelligence

Grants 77% — above average
77%
Career Allow Rate
168 granted / 218 resolved
+19.1% vs TC avg
Strong +20% interview lift
Without
With
+20.0%
Interview Lift
resolved cases with interview
Typical timeline
3y 1m
Avg Prosecution
27 currently pending
Career history
245
Total Applications
across all art units

Statute-Specific Performance

§101
7.2%
-32.8% vs TC avg
§103
57.6%
+17.6% vs TC avg
§102
6.1%
-33.9% vs TC avg
§112
24.3%
-15.7% vs TC avg
Black line = Tech Center average estimate • Based on career data from 218 resolved cases

Office Action

§103
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Continued Examination Under 37 CFR 1.114 A request for continued examination (RCE) under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on November 14, 2025 has been entered. Response to Amendments This office action is responsive to application 18/208,616 and the RCE filed on November 14, 2025. Claims 1, 6, 8, 13, and 15 are amended, and claims 1-20 remain pending in the application. Response to Arguments The Examiner has fully considered the Applicant’s arguments filed with the RCE, and the Examiner responds as provided below. Regarding the Applicant’s response at pages 7-9 of the Remarks that concerns the § 103 rejection, the Applicant’s arguments in conjunction with the claim amendments are persuasive, and consequently the Examiner conducted a new prior art search. The Applicant’s arguments are now moot with respect to the pending claims because the arguments do not apply to some of the references currently used in the rejection of the aforementioned claims as detailed below. 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. The following conventions apply to the mapping of the prior art to the claims: Italicized text – claim language. Parenthetical plain text – Examiner’s citation and explanation. Citation without an explanation – an explanation has been previously provided for the respective limitation(s). Quotation marks – language quoted from a prior art reference. Underlining – language quoted from a claim. Brackets – material altered from either a prior art reference or a claim, which includes the Examiner’s explanation that relates a claim limitation to the quoted material of a reference. Braces – a limitation taught by another reference, but the limitation is presented with the mapping of the instant reference for context. Numbered superscript – a first phrase to be moved upwards to the primary reference analysis. Lettered superscript – a second phrase to be moved after the movement of the first phrase from which it was lifted, or more succinctly, move numbered material first, lettered material last. A. Claims 1-2, 4-6, 8-9, 11-13, and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Sanchez-Rola et al. (US 11,947,692, “Sanchez”) in view of Crandell et al. (US 2002/0198935, “Crandell”) and Toomey (US 2007/0101427, “Toomey”), and further in view of Brown et al. (US 2016/0335239, “Brown”). Regarding Claim 1 Sanchez discloses A data entry security system (abstract, Fig. 3) comprising: a transceiver (Fig. 2, Col. 5:53-6:9, “As shown in FIG. 2, system 200 may include a computing device 202 in communication [via a transceiver] with a server 206 via a network 204.”; and Fig. 6, Col. 13:23-39, “In certain embodiments, communication interface [transceiver] 622 may also represent a host adapter configured to facilitate communication between computing system 610 and one or more additional network or storage devices via an external bus or communications channel.”) configured to communicate with an external device (Col. 5:53-6:9, “As shown in FIG. 2, system 200 may include a computing device 202 in communication with a server [external device] 206 via a network 204.”); a display configured to display a user interface to a user (Fig. 6, Col. 12:40-49, “As illustrated in FIG. 6, computing system 610 may also include at least one display device 624 coupled to I/O controller 620 via a display adapter 626.”; and (Fig. 4A, Col. 7:4-11, “FIG. 4A illustrates a website 400 as may be shown in a browser [user interface]. Website 400 may correspond to a webform and more specifically, an online shopping checkout form in which a user may input their sensitive data (e.g., credit card information) to complete an online purchase.”), the user interface including a form field (Fig. 4A, Col. 7:4-11, “Website 400 may include at least one input [form] field 422 (which may correspond to input field 122) to allow the user to input their sensitive data.”); an input device configured to receive user inputs (Fig. 6, Col. 12:60-13:2, “Additionally or alternatively, example computing system 610 may include additional I/O devices. For example, example computing system 610 may include I/O device 636. In this example, I/O device 636 may include and/or represent a user interface that facilitates [receives] human interaction [user inputs] with computing system 610.”); and one or more processors (Fig. 6, Col. 13:40-54, “In some examples, system memory 616 may store and/or load a network communication program 638 for execution by processor 614.”) configured to: detect that the user has selected the form field (Fig. 3, Col. 7:65-8:6, “Returning to method 300, at step 306 one or more of the systems described herein may collect, via the secure isolated container, real input data intended [and detected] for the sensitive data input field element. For example, collection module 108 (which may correspond to isolated container 124) may, as part of computing device 202 in FIG. 2, collect real input data 126 that may be intended for input [form] field 122.”); determine whether the form field requests sensitive data (Fig. 3, Col. 8:7-16, “FIG. 4B illustrates how real input data 426 (which may correspond to real input data 126) may be input into and collected by isolated container [after determining the form field request sensitive data] 424. Because isolated container 424 is overlaid onto input field 422, the user may input real input data 426 into isolated container 424 rather than input field 422.”); and in response to the form field requesting sensitive data (Fig. 3, Col. 7:65-8:16): generate an alternative data entry field in the user interface configured to receive form field data from the user (Col. 8:17-43, “Turning back to FIG. 3, at step 304 one or more of the systems described herein may create [generate] a secure isolated container [alternative data entry field] overlaid on the identified sensitive data input field element.”; and “Isolated container [alternative data entry field] 124 may act as a secure input field [to receive form field data from the user] to replace input field 122, as will be described further below.”); receive the form field data from the user via the alternative data entry field (Fig. 3, Col. 7:6-8:6, “Returning to method 300, at step 306 one or more of the systems described herein may collect [receive], via the secure isolated container [alternative data entry field], real input [form field] data intended for the sensitive data input field element.”); 1 …; and 2 …; and in response to the form field requesting non-sensitive data (Col. 7:12-23, “Identification module 104 may identify the sensitive data input field element based on an element attribute of the sensitive data input field element that is indicative of sensitive data.”, i.e., there are a limited number of form fields, and upon the identification module determining a field is not requesting “sensitive data”, then the identification module has determined the form field is requesting non-sensitive data): 3 …; and 4 …. Sanchez doesn’t disclose 1 validate the form field data, the validating including determining that a data type of the form field data entered into the alternative data entry field corresponds to a data type requested by the form field; 2 automatically enter, in response to the validating, the form field data into the form field; 3 monitoring data as it is being entered into the form field; 4 notifying the user in response to the monitoring detecting that the data being entered into the form field may include sensitive data. Crandall, however, discloses 1 validate the form field data,…a (¶ [0048], “As the data provided by the end user are entered into any particular field of the form, it is validated in step 60 on the server computing device.”); 3 monitoring data as it is being entered into the form field (¶ [0048], “As the data provided by the end user are entered into any particular [form] field of the form, it is validated [and thereby monitored] in step 60 on the server computing device.”); 4 notifying the user in response to the monitoring detecting that the data being entered into the form field may include sensitive data (¶¶ [0048]-[0050], “If the data inputted within any particular field are not correct [i.e., detecting all errors will detect entering sensitive data into a form field requesting non-sensitive data], the end user is notified electronically in step 80.”). Regarding the combination of Sanchez and Crandall, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the security system of Sanchez to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C). To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C): 1) the prior art contained a base system, namely the security system of Sanchez, upon which the claimed invention can be seen as an “improvement” through the use of an input validation feature; 2) the prior art contained a “comparable” system, namely the form-field system of Crandall, that has been improved in the same way as the claimed invention through the input validation feature; and 3) one of ordinary skill in the art could have applied the known improvement technique of applying the input validation feature to the base security system of Sanchez, and the results would have been predictable to one of ordinary skill in the art. Toomey, however, discloses a …, the validating including determining that a data type of the form field data entered into the alternative data entry field corresponds to a data type requested by the form field (Fig. 2C, ¶ [0054], “FIG. 2C illustrates aspects of the exemplary process 210 that involves using the stored sensitive-data-based string-matching patterns [corresponding to the data type requested by the form field] to determine [validate] if the user has entered sensitive data [as a data type of the form field data entered into the alternative data entry field] or a variation of the sensitive data.”; and ¶¶ [0046]-[0049], “FIG. 2B illustrates aspects of the exemplary process 210 that involve generating string-matching patterns based on the sensitive data for use by a matcher program or object to determine if input text matches sensitive data or a variation.” ); Regarding the combination of Sanchez-Crandall and Toomey, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the security system of Sanchez-Crandall to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C). To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C): 1) the prior art contained a base system, namely the security system of Sanchez-Crandall, upon which the claimed invention can be seen as an “improvement” through the use of a format validation feature; 2) the prior art contained a “comparable” system, namely the form-field system of Toomey, that has been improved in the same way as the claimed invention through the format validation feature; and 3) one of ordinary skill in the art could have applied the known improvement technique of applying the format validation feature to the base security system of Sanchez-Crandall, and the results would have been predictable to one of ordinary skill in the art. Brown, however, discloses 2 automatically enter, in response to the validating, the form field data into the form field (Fig. 1A, ¶ [0023], “The first display area [as alternative data entry field] 104 may be used to display one or more information requests [that are validated via Crandall ¶ [0048]] 116 and its corresponding one or more answer [form] fields 120.”; and “In this example, the user editable field associated with the item description, ‘Name’, has been populated with ‘Mary’. Each of the one or more user editable [form] fields 128 may be automatically populated after text has been input by way of a user inputting text using an answer field [alternative data entry field] 120.”); Regarding the combination of Sanchez-Crandall-Toomey and Brown, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the security system of Sanchez-Crandall-Toomey to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C). To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C): 1) the prior art contained a base system, namely the security system of Sanchez-Crandall-Toomey, upon which the claimed invention can be seen as an “improvement” through the use of an automated fillable-field feature; 2) the prior art contained a “comparable” system, namely the form-field system of Brown, that has been improved in the same way as the claimed invention through the automated fillable-field feature; and 3) one of ordinary skill in the art could have applied the known improvement technique of applying the automated fillable-field feature to the base security system of Sanchez-Crandall-Toomey, and the results would have been predictable to one of ordinary skill in the art. Regarding Claim 2 Sanchez in view of Crandall and Toomey, and further in view of Brown “Sanchez-Crandall-Toomey-Brown” discloses the data entry security system of claim 1, and Sanchez further discloses wherein the alternative data entry field is an overlay that includes a visual copy of the form field (Figs. 4A & 4B, Col. 7:33-44, “FIG. 4B illustrates a website 401 that may correspond to website 400. As compared to FIG. 4A, FIG. 4B illustrates an isolated container [alternative data entry field] 424 (which may correspond to isolated container 124) that may be overlaid at least [as a visual copy of] input [form] field 422.”). Regarding Claim 4 Sanchez-Crandall-Toomey-Brown discloses the data entry security system of claim 1, and Sanchez further discloses wherein the one or more processors (Fig. 6, Col. 13:40-54) are further configured to…1 Crandall further discloses 1 …detect a data type associated with the form field (¶¶ [0030]-[0032], “Where the HTML tag string “<td align=center>” indicates that a label tag follows which is to be centered, that label tag [that enables the processor to detect a data type associated with the form field] is “Name:” [as a data type] and will be displayed to the end user as a label for an input field which follows the label. This input field is defined by the HTML tagging “<input TYPE=“TEXT” NAME=“NAME”>.””). Regarding the combination of Sanchez and Crandall, the rationale to combine is the same as provided for claim 1 due to the overlapping subject matter of claims 1 and 4. Regarding Claim 5 Sanchez-Crandall-Toomey-Brown discloses the data entry security system of claim 1, and Sanchez further discloses wherein the alternative data entry field (Col. 8:17-43) is…1 Brown further discloses 1 …labeled with the data type (Fig. 1A, ¶ [0023], “Fig. 1A, ¶ [0023], “The example screen 100 illustratively describes example item descriptions 124 such as ‘Name’, ‘Phone’, ‘Address’, and ‘Email’. In this example, the user editable field associated with the item description, ‘Name’ [as the data type label], has been populated with ‘Mary’. Each of the one or more user editable fields 128 may be automatically populated after text has been input by way of a user inputting text using an answer field 120.”). Regarding the combination of Sanchez-Crandall-Toomey and Brown, the rationale to combine is the same as provided for claim 1 due to the overlapping subject matter of claims 1 and 5. Regarding Claim 6 Sanchez-Crandall-Toomey-Brown discloses the data entry security system of claim 1, and Crandall further discloses wherein the validating (¶ [0048]) includes: identifying the data type associated with the form field data (¶¶ [0030]-[0032], “Where the HTML tag string “<td align=center>” indicates that a label tag follows which is to be centered, that label tag [that enables the processor to detect a data type associated with the form field] is “Name:” [as a data type] and will be displayed to the end user as a label for an input field which follows the label. This input field is defined by the HTML tagging “<input TYPE=“TEXT” NAME=“NAME”>.””); 1 …; and validating or not validating the form field data based on the comparing (¶ [0048], “As the [form field] data provided by the end user are entered into any particular field of the form, it is validated [via the comparing as taught by Toomey Fig. 2C, ¶ [0054]] in step 60 on the server computing device. As previously presented, this validation may occur as the user enters data within a single field or as the user attempts to exit a field upon completely entering data for the exited field.”). Regarding the combination of Sanchez and Crandall, the rationale to combine is the same as provided for claim 1 due to the overlapping subject matter of claims 1 and 6. Toomey further discloses 1 comparing the data type of the form field data to the data type of the form field (Fig. 2C, ¶ [0054], “FIG. 2C illustrates aspects of the exemplary process 210 that involves using the stored sensitive-data-based string-matching patterns [representing the data type of the form field] to determine [compare] if the user has entered sensitive data [indicative of the data type of the form field data] or a variation of the sensitive data.”); Regarding the combination of Sanchez-Crandall and Toomey, the rationale to combine is the same as provided for claim 1 due to the overlapping subject matter of claims 1 and 6. Regarding Independent Claim 8 With respect to independent claim 8, a corresponding reasoning as given earlier for independent claim 1 applies, mutatis mutandis, to the subject matter of claim 8. Therefore, claim 8 is rejected, for similar reasons, under the grounds set forth for claim 1. Regarding Dependent Claims 9 and 11-13 With respect to dependent claims 9 and 11-13, a corresponding reasoning as given earlier for dependent claims 2 and 4-6 applies, mutatis mutandis, to the subject matter of claims 9 and 11-13. Therefore, claims 9 and 11-13 are rejected, for similar reasons, under the grounds set forth for claims 2 and 4-6. Regarding Independent Claim 15 With respect to independent claim 15, a corresponding reasoning as given earlier for independent claim 1 applies, mutatis mutandis, to the subject matter of claim 15. Therefore, claim 15 is rejected, for similar reasons, under the grounds set forth for claim 1. Regarding Dependent Claim 16 With respect to dependent claim 16, a corresponding reasoning as given earlier for dependent claim 2 applies, mutatis mutandis, to the subject matter of claim 16. Therefore, claim 16 is rejected, for similar reasons, under the grounds set forth for claim 2. B. Claims 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Sanchez in view of Crandell and Toomey, and further in view of Brown and Bierner et al. (US 2008/0215976, “Bierner”). Regarding Claim 3 Sanchez-Crandall-Toomey-Brown discloses the data entry security system of claim 1, and Sanchez further discloses wherein the alternative data entry field is…1 that includes the alternative data entry field (Col. 8:17-43). Sanchez-Crandall-Toomey-Brown 1 …a pop-up window… Bierner, however, discloses 1 …a pop-up window… (Fig. 2, ¶ [0035], i.e., the “popup window 62” is a popup window) Regarding the combination of Sanchez-Crandall-Toomey-Brown and Bierner, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the security system of Sanchez-Crandall-Toomey-Brown to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C). To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C): 1) the prior art contained a base system, namely the security system of Sanchez-Crandall-Toomey-Brown, upon which the claimed invention can be seen as an “improvement” through the use of an popup window feature; 2) the prior art contained a “comparable” system, namely the form-field system of Bierner, that has been improved in the same way as the claimed invention through the popup window feature; and 3) one of ordinary skill in the art could have applied the known improvement technique of applying the popup window feature to the base security system of Sanchez-Crandall-Toomey-Brown, and the results would have been predictable to one of ordinary skill in the art. Regarding Dependent Claims 10 and 17 With respect to dependent claims 10 and 17, a corresponding reasoning as given earlier for dependent claim 3 applies, mutatis mutandis, to the subject matter of claims 10 and 17. Therefore, claims 10 and 17 are rejected, for similar reasons, under the grounds set forth for claim 3. C. Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Sanchez in view of Crandell, Toomey, and Brown, and further in view of Dakin (US 2016/0217119, “Dakin”) and Carbune et al. (US 2016/0300573, “Carbune”). Regarding Claim 7 Sanchez-Crandall-Toomey-Brown discloses the data entry security system of claim 1, and Sanchez further discloses wherein the one or more processors (Fig. 6, Col. 13:40-54 are further configured to, in response to {not validating the form field data (Crandall ¶ [0048], i.e., Crandall literally teaches the validation of form field data, the alternative is an obvious variation)}: 1 …; 2 …; 3 …; and 4 …. Sanchez-Crandall-Toomey-Brown doesn’t disclose 1 request confirmation from the user of the validation decision; 2 receive reply data from the user that denies the confirmation request; 3 in response to the reply data, request an actual data type from the user; 4 provide the form field data and the actual data type to a model. Dakin, however, discloses 1 request confirmation from the user of the validation decision (Figs. 5 & 6, ¶¶ [0030]-[0031], “In some embodiments, if the user accepts [confirms the validation decision] any or all of the suggested responses [serving as a request] for filling the form 130 b, such as shown in FIG. 5, those suggested responses can be automatically entered into the corresponding fillable form field candidates. However, the user may choose to reject [does not confirm the validation decision] any or all of the suggested responses.”); 2 receive reply data from the user the denies the confirmation request (¶ [0047], “However, the user may choose to reject [to deny] any or all of the suggested responses [of the confirmation request]. For example, as shown in the screenshot 600 of FIG. 6, the user is typing a different number [as reply data] into the telephone form field, which overrides the suggested response for that field shown in the screenshot 500 of FIG. 5.”); Regarding the combination of Sanchez-Crandall-Toomey-Brown and Dakin, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the data validation system of Sanchez-Crandall-Toomey-Brown to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C). To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C): 1) the prior art contained a base system, namely the data validation system of Sanchez-Crandall-Toomey-Brown, upon which the claimed invention can be seen as an “improvement” through the use of a feedback feature; 2) the prior art contained a “comparable” system, namely the form system of Dakin, that has been improved in the same way as the claimed invention through a feedback feature; and 3) one of ordinary skill in the art could have applied the known improvement technique of applying the feedback feature to the base data validation system of Sanchez-Crandall-Toomey-Brown, and the results would have been predictable to one of ordinary skill in the art. Carbune, however, discloses 3 in response to the reply data, request an actual data type from the user (¶ [0111], “In some implementations, a user may be provided with one or more opportunities to confirm and/or correct a populated form. For instance, the user may be presented with an interface [to implement a request] that may allow the user to indicate that they would like to begin providing input for populating the form, indicate that the form has been populated erroneously, confirm a current state of the form, and indicate that they have finished providing input for populating the form. In some implementations, this feedback may be utilized to train the machine learning system.”; see also Dakin ¶ [0019], “In some embodiments, machine learning can be used to perform semantic reasoning for distinguishing multiple contexts [actual data type] of a given word or set of words, as well as finding similar terms. For example, if a field label is ‘address’ instead of ‘street address, ‘address’ might mean ‘street address’ [as a first actual data type], but it might also mean ‘email address’ [as a second actual data type], which is a completely different meaning. Machine learning techniques can use words near this field to improve selection of the appropriate meaning. For example, ‘city’ and ‘state’ near one another may suggest that ‘address’ more likely means ‘street address’ than ‘email address.’” i.e., collectively Carbune and Dakin suggest an opportunity for a user to provide feedback relating to a street address or an email address as actual data types that may be in error and need correcting); 4 provide the form field data and the actual data type to a model (¶ [0111], “For instance, the user may be presented with an interface that may allow the user to indicate that they would like to begin providing input for populating the form, indicate that the form has been populated erroneously, confirm a current state of the form, and indicate that they have finished providing input for populating the form. In some implementations, this feedback [as form field data and actual data type] may be utilized to train the machine learning system [model].”). Regarding the combination of Sanchez-Crandall-Toomey-Brown-Dakin and Carbune, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the data validation system of Sanchez-Crandall-Toomey-Brown-Dakin to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C). To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C): 1) the prior art contained a base system, namely the data validation system of Sanchez-Crandall-Toomey-Brown-Dakin, upon which the claimed invention can be seen as an “improvement” through the use of a machine learning feature; 2) the prior art contained a “comparable” system, namely the form system of Carbune, that has been improved in the same way as the claimed invention through a machine learning feature; and 3) one of ordinary skill in the art could have applied the known improvement technique of applying the machine learning feature to the base data validation system of Sanchez-Crandall-Toomey-Brown-Dakin, and the results would have been predictable to one of ordinary skill in the art. Regarding Dependent Claim 14 With respect to dependent claim 14, a corresponding reasoning as given earlier for dependent claim 7 applies, mutatis mutandis, to the subject matter of claim 14. Therefore, claim 14 is rejected, for similar reasons, under the grounds set forth for claims 7. D. Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Sanchez in view of Crandell, Toomey, and Brown, and further in view of Dakin (US 2016/0217119, “Dakin”) and Schnitt (US 2011/0225485, “Schnitt”). Regarding Claim 18 Sanchez-Crandall-Toomey-Brown discloses the method of claim 16, and Crandall further discloses wherein the validating (¶ [0048]) includes: 1 …; 2 …; and 3 …. Sanchez-Crandall-Toomey-Brown doesn’t disclose 1 detecting a first data type associated with the form field; 2 detecting a second data type associated with the form field data; 3 comparing the first data type and the second data type. Schnitt, however, discloses 1 detecting a first data type associated with the form field (¶¶ [0030]-[0032], “Where the HTML tag string “<td align=center>” indicates that a label tag follows which is to be centered, that label tag [that enables the detection of a first data type associated with the form field] is “Name:” [as a data type] and will be displayed to the end user as a label for an input field which follows the label. This input field is defined by the HTML tagging “<input TYPE=“TEXT” NAME=“NAME”>.””); 3 comparing the first data type and the second data type (¶ [0084], “In accordance with the present invention, the form designer 12 allows a form author to design without code programming, by dragging and dropping information onto the form, complex validations of the data entered into form fields for individual or multiple fields to ensure that the form is filled out correctly, such as ensuring [via a comparison] that a social security number [as a first data type] is numeric and in the format XXX-XX-XXX [as opposed to a second data type as an e-mail address possessing “.com”], ensuring that all required fields are complete before a form can be submitted, or ensuring that if a certain box is checked then one of three other boxes need to be checked as well.”). Regarding the combination of Sanchez-Crandall-Toomey-Brown and Schnitt, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the data validation system of Sanchez-Crandall-Toomey-Brown to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C). To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C): 1) the prior art contained a base system, namely the data validation system of Sanchez-Crandall-Toomey-Brown, upon which the claimed invention can be seen as an “improvement” through the use of a data validation feature; 2) the prior art contained a “comparable” system, namely the data entry system of Schnitt, that has been improved in the same way as the claimed invention through a data validation feature; and 3) one of ordinary skill in the art could have applied the known improvement technique of applying the data validation feature to the base data validation system of Sanchez-Crandall-Toomey-Brown, and the results would have been predictable to one of ordinary skill in the art. Dakin, however, discloses 2 detecting a second data type associated with the form field data (¶ [0019], “For example, if a field label is ‘address’ instead of ‘street address’, ‘address’ might mean ‘street address’ [first data type], but it might also mean ‘email address’ [second data type], which is a completely different meaning. Machine learning techniques can use words near this field to improve selection of the appropriate meaning.”); Regarding the combination of Sanchez-Crandall-Toomey-Brown-Schnitt and Dakin, the rationale to combine is the same as provided for claim 7 due to the overlapping subject matter of claims 7 and 18. E. Claims 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Sanchez in view of Crandell, Toomey, and Brown, and further in view of Dakin, Schnitt, and Carbune. Regarding Claim 19 Sanchez in view of Crandall, Toomey, and Brown, and further in view of Schnitt and Dakin (“Sanchez-Crandall-Toomey-Brown-Schnitt-Dakin”) discloses the method of claim 18, and Crandall further discloses wherein the validating (¶ [0048]) further includes: 1 …; 2 …; and 3 …. Schnitt and Dakin further disclose 1 determining that the first data type and the second data type do not match (¶ [0084], “In accordance with the present invention, the form designer 12 allows a form author to design without code programming, by dragging and dropping information onto the form, complex validations of the data entered into form fields for individual or multiple fields to ensure that the form is filled out correctly, such as ensuring [via a comparison] that a social security number is numeric and in the format XXX-XX-XXX [as data type of the form field], ensuring that all required fields are complete before a form can be submitted, or ensuring that if a certain box is checked then one of three other boxes need to be checked as well.”; and Dakin ¶ [0019], “For example, if a field label is ‘address’ instead of ‘street address’, ‘address’ might mean ‘street address’ [first data type], but it might also mean ‘email address’ [second data type], which is a completely different meaning. Machine learning techniques can use words near this field to improve selection of the appropriate meaning.”, i.e., a comparison of a SSN and an email address would indicate the first and second data types do not match); Regarding the combination of Sanchez-Crandall-Toomey-Brown and Schnitt, the rationale to combine is the same as provided for claim 18 due to the overlapping subject matter of claims 18 and 19. Regarding the combination of Sanchez-Crandall-Toomey-Brown-Schnitt and Dakin, the rationale to combine is the same as provided for claim 7 due to the overlapping subject matter of claims 7 and 19. Sanchez-Crandall-Toomey-Brown-Schnitt-Dakin doesn’t disclose 2 request an actual data type from the user; 3 perform an updated comparison between the second data type and the actual data type. Carbune, however, discloses (¶ [0111], “In some implementations, a user may be provided with one or more opportunities to confirm and/or correct a populated form. For instance, the user may be presented with an interface [to implement a request] that may allow the user to indicate that they would like to begin providing input for populating the form, indicate that the form has been populated erroneously, confirm a current state of the form, and indicate that they have finished providing input for populating the form. In some implementations, this feedback may be utilized to train the machine learning system.”; see also Dakin ¶ [0019], “In some embodiments, machine learning can be used to perform semantic reasoning for distinguishing multiple contexts [actual data type] of a given word or set of words, as well as finding similar terms. For example, if a field label is ‘address’ instead of ‘street address, ‘address’ might mean ‘street address’ [as a first actual data type], but it might also mean ‘email address’ [as a second actual data type], which is a completely different meaning. Machine learning techniques can use words near this field to improve selection of the appropriate meaning. For example, ‘city’ and ‘state’ near one another may suggest that ‘address’ more likely means ‘street address’ than ‘email address.’” i.e., collectively Carbune and Dakin suggest an opportunity for a user to provide feedback relating to a street address or an email address as actual data types that may be in error and need correcting); 3 perform an updated comparison between the second data type and the actual data type (¶ [0083], “For example, user 102 may have previously provided “rpond@example.com” to an email text entry field of another form displayed on user device 106. Through the use of machine learning techniques, the computing device 122 may determine that “rpond@example.com” is most likely the user's email address [second data type]. It follows that the computing device 122 may determine that the last name [first data type] of “Pond” more suitably maps to name field 140 than “Ponder” does, since the “r” received following “Pond” is most likely part of an email address. The computing device 122 may provide updated form 108F to the user device 106 for display. In some implementations, user device 106 receives information to modify the text entry fields 140-148 of form 108's association with transcription portions, e.g., transcribed text, of input 104. The user device 106 may, for instance, update form 108E to form 108F for display.”). Regarding the combination of Sanchez-Crandall-Toomey-Brown-Schnitt-Dakin and Carbune, the rationale to combine is the same as provided for claim 7 due to the overlapping subject matter of claims 7 and 19. Regarding Claim 20 Sanchez in view of Crandall, Toomey, and Brown, and further in view of Schnitt, Dakin, and Carbune, discloses the method of claim 18, and Carbune further discloses further comprising: providing the {form field data (Sanchez Col. 8:17-43)}, the {detected first data type (Dakin ¶ [0019])} and the {actual data type (Dakin ¶ [0019])} to an external model (¶ [0111], “For instance, the user may be presented with an interface that may allow the user to indicate that they would like to begin providing input for populating the form, indicate that the form has been populated erroneously, confirm a current state of the form, and indicate that they have finished providing input for populating the form. In some implementations, this feedback [as form field data, first data type, and actual data type] may be utilized [provided] to train the machine learning system [model].”); and updating the model based on the form field data, the detected first data type, and the actual data type (¶ [0111], “For instance, the user may be presented with an interface that may allow the user to indicate that they would like to begin providing input for populating the form, indicate that the form has been populated erroneously, confirm a current state of the form, and indicate that they have finished providing input for populating the form. In some implementations, this feedback [as form field data, first data type, and actual data type] may be utilized to train [update] the machine learning system [model].”). Regarding the combination of Sanchez-Crandall-Toomey-Brown-Schnitt and Dakin, the rationale to combine is the same as provided for claim 7 due to the overlapping subject matter of claims 7 and 20. Regarding the combination of Sanchez-Crandall-Toomey-Brown-Schnitt-Dakin and Carbune, the rationale to combine is the same as provided for claim 7 due to the overlapping subject matter of claims 7 and 20. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to D'ARCY WINSTON STRAUB whose telephone number is (303)297-4405. The examiner can normally be reached Monday-Friday 9:00-5:00 Mountain Time. 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, AMIR MEHRMANESH can be reached at (571)270-3351. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /D'Arcy Winston Straub/Primary Examiner, Art Unit 2491
Read full office action

Prosecution Timeline

Jun 12, 2023
Application Filed
Mar 17, 2025
Non-Final Rejection — §103
Jun 20, 2025
Response Filed
Aug 11, 2025
Final Rejection — §103
Nov 14, 2025
Request for Continued Examination
Nov 22, 2025
Response after Non-Final Action
Jan 14, 2026
Non-Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12591706
PROACTIVE DATA SECURITY USING FILE ACCESS PERMISSIONS
2y 5m to grant Granted Mar 31, 2026
Patent 12579304
PURPOSE-BASED PROCESSING BY PURPOSE-ACTION ASSOCIATION
2y 5m to grant Granted Mar 17, 2026
Patent 12566886
DYNAMIC PROGRAMMING SOLUTION FOR PRIVACY PROTECTION EVALUATION
2y 5m to grant Granted Mar 03, 2026
Patent 12566887
Multi-Tiered Data Security and Auditing System
2y 5m to grant Granted Mar 03, 2026
Patent 12561410
SYSTEM AND METHOD TO PROVIDE DUMMY DATA FOR SOURCE ATTRIBUTION FOR PROPRIETARY DATA TRANSMISSION
2y 5m to grant Granted Feb 24, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
77%
Grant Probability
97%
With Interview (+20.0%)
3y 1m
Median Time to Grant
High
PTA Risk
Based on 218 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

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

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

Free tier: 3 strategy analyses per month