DETAILED ACTION
This action is responsive to the request for continued examination filed 06/01/2026.
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 .
Status of the Claims
Claims 1-12, 14, 16, 18-25, and 27 are rejected under 35 U.S.C. 103.
Claims 13, 15, 17, and 26 are cancelled.
Response to Arguments
Applicant’s arguments on Pages 7-9 of the Remarks regarding the prior art in view of the amendments to claim 1 have been fully considered but are respectfully moot given the new grounds for rejection necessitated by the amendments to claim 1. Since claims 5 and 9 were not amended, they remain rejected over the previous grounds of rejection, as Kuca still teaches the limitation “verifying the user or a user's signature using a vital document, a third-party signature service, or an electronic token exchange”, as discussed in the rejections of claim 5 and 9 below.
Applicant argues on Page 10 of the Remarks that Semenovskiy does not teach the limitations of claims 24-25 and cannot be combined with Eigner, Lopata, and Kuca (replaced by Patil). The examiner respectfully disagrees.
In response to applicant's arguments, the test for obviousness is not whether the features of a secondary reference may be bodily incorporated into the structure of the primary reference; nor is it that the claimed invention must be expressly suggested in any one or all of the references. Rather, the test is what the combined teachings of the references would have suggested to those of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981).
Claim 1 and claims 24-25 recite “verifying the user or a user's signature using a vital document, a third-party signature service, or an electronic token exchange… wherein the verifying step uses an electronic token exchange… wherein the electronic token exchange comprises a public or private key”. Semenovskiy teaches verification of a user, including their signature, using a vital document (i.e. a government-issued identification) and a third party signatory service. See Paragraphs 71, 78, and 89, which discuss the user verification, and Figure 12B, which illustrates a third-party signature service that verifies the user’s identity. In particular:
“a signatory (or user) unlocks the blockchain wallet using the associated password to sign a document” ¶ 78
“Before signing any documents, users are required to verify their identity using government-issued identification… once the user verifies their identity, the system allows the user to start signing the documents using the wallet as cryptographic key pair ” ¶ 89
Semenovskiy therefore teaches the plain meaning of the limitations recited by claims 24-25 as further discussed in the detailed 103 rejections below. Semenovskiy is in the same field of endeavor and is concerned with a similar problem as the claimed invention since it is directed to user verification methods for users filling out and signing electronic forms. Semenovskiy is therefore analogous prior art.
Furthermore, Semenovskiy also teaches that the verification includes an electronic token exchange comprising a public or private key. See Paragraphs 7, 73, and 85-87, which teaches that the electronic documents are signed and that the signatures are verified using private-public key pairs, which would involve a token exchange. For example, Semenovskiy (Paragraph 7) teaches “This DID serves as a pointer to the DID document, which is stored in a decentralized fashion and contains a set of public keys, used by the subject person or organization to produce cryptographic signatures and for third-party verifiers to validate the signature afterwards.” Therefore, the public or private keys are used to verify a user and their signature and is not merely for encryption of the documents between parties as asserted by the applicant.
The teachings of Semenovskiy therefore at least suggest verification of a user or their signature using an electronic token exchange comprising a public or private key. Filling a form automatically with encrypted data and signature verification are both security features that one of ordinary skill in the art would have considered incorporating into a secure system that maintains personal user information, especially when filing government applications. The specific software architecture used to implement these features would be dependent on the designer of the system.
Applicant’s argument that Semenovskiy does not teach the newly added limitation of claim 1 is respectfully moot given the new grounds of rejection of claim 1, which now use Patil instead of Kuca.
Claim Rejections – 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4, 14, 19-22, and 27 are rejected under 35 U.S.C. 103 as being unpatentable over EIGNER (US 2014/0122508 A1) in view of LOPATA (US 2010/0153441 A1) and further in view of PATIL (US 2020/0211031 A1).
Regarding Claim 1, EIGNER discloses a computerized method for automatically completing a form, the method comprising the steps of: (See Fig. 12 and Paragraph 0093, which provide an overview of the method for automatically completing a form.)
storing encrypted data filled by a user into a first form (“Each time the user populates information into a form, the system can save the final version of the form within a specific database table known as the customerFieldContent. The information stored in the form can be locked and will not be updated as other user information is updated, unless the user specifically accesses the previously-completed form, edits the form itself and creates a new version. The stored completed forms may be time and date stamped, to create a complete archive of the user’s activities within the system.” Paragraph 0070. Also see Paragraph 0040-42, which discusses a user filling out a “master form” or inputting already completed forms that are then stored in an online vault.
Each of the items of information filled by a user are encrypted: “Information is obtained from a plurality of different sources and classified through field mapping and other information classification techniques to build an organized database of information related to a user known as an information vault. The information is securely stored via encryption and disassociation techniques in one or more user databases to ensure the security of the information. A forms database is utilized for storing electronic forms and documents as well as the field information needed to complete the form or document.” Paragraph 0031. Also see Paragraphs 62-64, which discuss individually encrypting each item of information of a user.)
to encrypted cloud storage; (“The user profile may be encrypted and stored remotely in a cloud-based system at a remote server, with portions of the profile stored in separate locations with separate encryption to minimize the risk of unauthorized access to one portion of the information.” Paragraph 0010. Also see Paragraphs 31, 53, and 64, which discuss that the user’s information is encrypted and stored in separate databases.)
autofilling a second form having at least one field matching a field from the first form with the stored encrypted data from the encrypted cloud storage in the at least one matching field… (“The user can access their information to automatically populate the fields of an online form or an electronic document by selecting a document from the forms database or by utilizing a browser plug-in to populate an online form being displayed in a web browser.” Paragraph 0031. “The communications interface 104 will also include one or more information processing units within the server 106 to process the collected information, including a classification unit 106a which classifies the information to identify fields applicable to the information and values for the fields; a profile creation unit 106b which creates a user profile with the classified information; and an information populating unit 106c which populates at least one form field of an electronic form or database by matching the at least one form field with the classified information” Paragraph 0035. Also see Paragraphs 54-59, which further discuss the process of matching a field from a first form to a field in a second form in order to automatically populate a form.)
filling in by the user any non-matching fields with new encrypted data; (“The completion indicator may also provide the user with an indication of how much of a given category has been mapped or how much work is required to complete the unfilled fields… Although the system will populate any field for which it has information, certain fields may have no values or may have multiple values, in which case the field will not be automatically filled. In this situation, the user must take some action in order to populate the field.” Paragraphs 0083-84. Fields that are not automatically filled are manually filled by the user with new data. As discussed in Paragraphs 31 and 62-64, all data entered by the user is individually encrypted.)
storing the new encrypted data to the encrypted cloud storage… (“if the user manually alters a field value for a particular field after the system has populated the field, the system will denote the changed value and store the newly-input value in the system database, preferably in the information vault of the user’s profile. The user can therefore update their profiles automatically while changing the information being input into a form.” Paragraph 0091. Any new information input the by the user is stored on the user’s encrypted profile, which as discussed in Paragraph 0010, is an encrypted cloud storage.)
While EIGNER teaches utilizing the disclosed method within a government environment (Paragraph 33), EIGNER does not explicitly teach wherein the first form and the second form are governmental applications from different government agencies.
However, LOPATA, which is directed to a single access point for filling and filing government forms, teaches wherein the first form and the second form are governmental applications from different government agencies. (See Paragraphs 13, 28-30, 34, 51, 53, 55: A user accesses a plurality of government forms using a single access point. User data that was previously entered and stored in a database is used to pre-populate fields in a selected form. After the user completes the form, it is submitted to the appropriate government agency, including with the compatible format corresponding to the government agency.)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the auto-filling of forms using previously submitted information stored in an encrypted cloud database taught by EIGNER by applying the system in order to auto-fill and file multiple governmental applications as taught by LOPATA. Since EIGNER (¶ 33) at least suggests applying the encrypted autofill system to a government application, the combination would have yielded predictable results. Furthermore, as suggested by LOPATA (¶ 10, 12-13), providing a single access point for a user to fill and file multiple government forms with multiple different agencies would reduce inefficiencies in the filing system and save the user time.
EIGNER in view of LOPATA further teaches wherein two or more second forms having at least one field matching a field from the first form are autofilled with the stored encrypted cloud storage in the at least one matching field of the two or more second forms. (EIGNER, See Paragraph 35, 54-60, which discuss the process of matching a field from a first form to a field in a second form in order to automatically populate a form. ¶ 35: “The user, through any type of device 110a-c, may then request that one or more forms 112 be completed using the information in their profile… The user can interact with the communications interface 104 through the device 110 to complete one or more forms 112a-c, such as an image viewer 112a, a form displayed in an internet-browser application 112b, or a form displayed via an application 112c running on the portable electronic device 110c”. ¶ 60: “different forms may have different ways to refer to the same user field name… When a subsequent field called “First Name” in encountered, its value would have already been stored and easily located through the “userFieldCollections” table”.
Also see LOPATA, ¶ 13: “Multiple electronic forms are accessible to the customer at a single access point, such as on a web site”; ¶ 51: “a database server 908 is queried to determine whether data specific to this customer and pertinent to any of the blank data fields of the selected form have been previously stored. If so, the data is used to populated those blank data fields prior to presenting the form”)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to autofill matching fields in multiple different forms from previously saved form data as taught by EIGNER. This is further supported by LOPATA (¶ 13, 51), which teaches a single access point for filling multiple forms from different agencies. When a user chooses a form, the previously stored data is pre-populated in matching fields of the form. This would occur again if the user selects multiple other forms. Such an implementation would have therefore been advantageous for improving the convenience of the form filling process for the user, especially in a situation where they have three or more forms to fill.
EIGNER in view of LOPATA does not teach and verifying the user or a user’s signature using a vital document, a third-party signature service, or an electronic token exchange… and wherein the verifying step comprises: a) storing a government-issued identity document in the encrypted cloud storage; and b) reusing the stored government-issued identity document for verification during submission of a later governmental application associated with a different government agency, wherein the stored government-issued identity document is saved in the encrypted cloud storage for later use to: a) verify the user's identity, b) verify the user's signature, or c) submit as supporting documentation for a later governmental application.
However, PATIL, which is directed to verifying a user that is processing electronic applications, teaches and verifying the user or a user’s signature using a vital document, a third-party signature service, or an electronic token exchange… (¶ 27, 37, 40, 69: A vital document, such as a passport, is used as one of multiple user authentication factors, both for authenticating the user using the system and confirming the authenticity of the user and the documents provided for use in filling out a government application. The uploaded vital document is also verified.)
and wherein the verifying step comprises: a) storing a government-issued identity document in the encrypted cloud storage (¶ 37, 50, 52, 81, 69: The vital document is stored in an encrypted storage in association with a profile of the user. It would have been obvious in view of EIGNER (¶ 10), which also calls it a “vault”, for this encrypted storage to be an encrypted cloud storage.);
and b) reusing the stored government-issued identity document for verification during submission of a later governmental application associated with a different government agency, wherein the stored government-issued identity document is saved in the encrypted cloud storage for later use to: a) verify the user's identity, b) verify the user's signature, or c) submit as supporting documentation for a later governmental application. (¶ 37-38, 69: The government-issued identity document, such as a passport, is stored in a “vault”, an encrypted storage, so that “they do not need to be re-entered or re-confirmed each time a transaction is desired through the app.” (¶ 37), ¶ 69: “All documents uploaded by the user are preferably encrypted and stored in the biometric vault for future use”. Future use of the vital document in this visa application interface (see ¶ 8-9) would be for verification of the user’s identity and submission as supporting documentation for later governmental (visa) applications.)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the method of securely auto-filling and filing government forms taught by EIGNER in view of LOPATA by incorporating the method of verifying a user using a vital document and storing the vital document in encrypted storage for future use as taught by PATIL. Since PATIL is also directed to completing electronic documents, including government forms, the combination would have yielded predictable results. As suggested by PATIL (¶ 3-5), automating the verification of government applications, such as visa applications, would improve the user experience and save resources. PATIL (¶ 40, 69) also teaches that secure storage of the vital document would protect sensitive data while still enabling the user to have access to their vital documents for future use, i.e. filing another application.
Regarding Claim 2, EIGNER in view of LOPATA and PATIL further teaches logging, by the user, into a platform for the first form having fields. (EIGNER, “a website run by an academic institution may integrate access to the system into their application for applying for admission, such that upon loading the admissions application, the user can log in and then access their information to populate the admissions application directly through the website. In addition, an internet shopping website may integrate access to the system database so that when the user is ready to check out and purchase goods or services from the website, a button, link or authentication dialogue will be available for the user to select and then populate their information onto a payment screen.” Paragraph 0078. Also see Paragraphs 0063-64, which teaches that the user must log in to access the encrypted form data.)
Regarding Claim 3, EIGNER in view of LOPATA and PATIL further teaches further comprising sending the filled first form to the user. (EIGNER, “the system may be offered as a mobile application running on a smartphone, tablet or other portable electronic device that would enable a user to complete forms or other documents” Paragraph 0033. “The information stored in the form can be locked and will not be updated as other user information is updated, unless the user specifically accesses the previously-completed form, edits the form itself and creates a new version.” Paragraph 0070. The filled first form is accessed by a user using their device, which would involve the form being sent to the user device from the encrypted cloud storage upon request by the user.)
Regarding Claim 4, EIGNER in view of LOPATA and PATIL further teaches further comprising providing to the user a set of computer-executed instructions that, when executed by a user’s user device, generate a user interface displayable on an electronic display coupled to the user’s user device. (EIGNER, “Users 116 can access the system via the various devices 110 described above… The UI/UX 104b includes a web and interface server 106f connected with a forms and applications output database 108a.” Paragraphs 0035-36. See Figure 5, which illustrates an example user interface.)
Regarding Claim 14, EIGNER in view of LOPATA and PATIL further teaches further comprises verifying that the encrypted data and the new encrypted data are correct per a government standard with a computer-implemented verification process. (LOPATA, Paragraph 30, 51: Data mapping software and translator components are used to convert submitted form data into the proper format for submission to the appropriate government agency: “business process orchestration software determines the proper format for data from the submitted form in order to be properly received and processed by the government agency systems 302, 304”. Therefore, there is a process of verifying that the data is correct per a government standard.)
Before the effective filing date of the invention, it would have been further obvious to one of ordinary skill in the art to incorporate the method of verifying that the completed fields of a form are correct per a government standard taught by LOPATA within the system of securely auto-filling forms taught by EIGNER. Incorporating the determination of a proper data format and conversion process taught by LOPATA would aid the user in the submission of a government form without errors, saving time for both the user and the government agency.
Regarding Claim 19, EIGNER in view of LOPATA and PATIL further teaches wherein the verifying step uses a vital document. (PATIL, ¶ 36-38, 40, 69: The verifying step uses a vital document, such as a passport.)
The same motivation to combine discussed in the rejection of claim 1 applies to claim 19.
Regarding Claim 20, EIGNER in view of LOPATA and PATIL further teaches wherein the vital document is an image file or a certified electronic copy from an issuing government authority. (PATIL, ¶ 40, 69: The vital document is an image file of a passport from an issuing government authority.)
The same motivation to combine discussed in the rejection of claim 1 applies to claim 20.
Regarding Claim 21, EIGNER in view of LOPATA and PATIL further teaches wherein the vital document is chosen from a birth certificate, driver’s license, or passport. (PATIL, ¶ 36, 40, 56, 69: The vital document is a passport and/or driver’s license.)
The same motivation to combine discussed in the rejection of claim 1 applies to claim 21.
Regarding Claim 22, EIGNER in view of LOPATA and PATIL further teaches wherein the vital document is saved in the encrypted cloud drive for the user to use later to verify the user’s identity, to verify the user’s signature, or to submit as supporting documentation for a government application. (PATIL, ¶ 37, 40, 56, 69: The vital document is “encrypted and stored in the biometric vault for future use”. Future use would involve other government applications, such as visa applications. See ¶ 8.)
Regarding Claim 27, EIGNER in view of LOPATA and PATIL further teaches further comprising displaying a completion status of further forms, which is automatically updated when the second form is completed. (PATIL, ¶ 73, Fig. 18L: The completion status of a form is displayed at the end of the application process. It would have been obvious for this completion screen to be displayed for a second form or any number of forms. See ¶ 74 and Fig. 19B.)
Before the effective filing date of the invention, it would have been further obvious to one of ordinary skill in the art to modify the system for securely filling and filing multiple forms taught by EIGNER in view of LOPATA and PATIL by incorporating a user interface for displaying the completion status of the forms the user submitted for completion as taught by PATIL. Such an implementation would improve the user experience and reduce frustration by providing a notification to the user of the completion status of their submitted forms.
Claims 23-25 are rejected under 35 U.S.C. 103 as being unpatentable over EIGNER (US 2014/0122508 A1) in view of LOPATA (US 2010/0153441 A1) and further in view of PATIL (US 2020/0211031 A1) and SEMENOVSKIY (US 2021/0281421 A1).
Regarding Claim 23, EIGNER in view of LOPATA and PATIL teaches all the limitations of claim 1, on which claim 23 depends.
While PATIL suggest signature verification (¶ 44, 73: Signature analysis is suggested among other processes to cross-reference a user’s data against multiple parameters for verification of identity) EIGNER in view of LOPATA and PATIL does not teach wherein the verifying step uses a third-party signature service.
However, SEMENOVSKIY, which is similarly directed to verifying signatories of an electronic document, teaches wherein the verifying step uses a third-party signature service. (¶ 14, 19, 67, 71, Fig. 12B: A digital signature is verified to belong to a user and uploaded to a third-party service that maintains an authenticity report of the signed document in a database.)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the automatic completion of a government form and verification of a user and their signature taught by EIGNER in view of LOPATA and PATIL by incorporating the teachings of electronic signature verification and encrypted communication taught by SEMENOVSKIY. Since SEMENOVISKY is also directed to electronic submission of user data, the combination would have yielded predictable results and would have aided user’s and agencies in quickly verifying the authenticity of a signed document. As taught by SEMENOVSKIY (Paragraphs 12-13), such an implementation would ensure that a document is signed by the correct signatory, which one of ordinary skill in the art would have been motivated to apply to the submission of government forms, such as those taught by LOPATA and PATIL.
Regarding Claim 24, EIGNER in view of LOPATA and PATIL teaches all the limitations of claim 1, on which claim 24 depends.
EIGNER in view of LOPATA and PATIL does not teach wherein the verifying step uses an electronic token exchange.
However, SEMENOVSKIY, which is similarly directed to verifying signatories of an electronic document, teaches wherein the verifying step uses an electronic token exchange. (“FIG. 12B depicts a user input-output device 324 presenting a verified authentication report 350, which includes information on, among other things, the verification status of the document (e.g., “Verified”, “This is a valid document”), the total number of pages, number of signatories, name and contact information of signatory, status of identity verification for the signatory, status of document signature… the present invention preferably uses Blockchain wallets (i.e., private-public key pairs) to encrypt the document on a peer-to-peer basis between signatories so only authorized (i.e., predetermined) parties can sign and read these sensitive documents.” Paragraphs 85-87. Also see Paragraphs 7 and 73. Electronic documents are signed and the signatures are verified using an electronic token exchange that includes private-public key pairs.)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the automatic completion of a government form and verification of a user and their signature taught by EIGNER in view of LOPATA and PATIL by incorporating the teachings of electronic signature verification and encrypted communication taught by SEMENOVSKIY. Since SEMENOVISKY is also directed to electronic submission of user data, the combination would have yielded predictable results. Such an implementation would have improved the security of the system and protect the user’s data. Furthermore, as taught by SEMENOVSKIY (Paragraphs 12-13), such an implementation would ensure that a document is signed by the correct signatory, which one of ordinary skill in the art would have been motivated to apply to the submission of government forms, such as those taught by LOPATA and PATIL.
Regarding Claim 25, EIGNER in view of LOPATA, PATIL, and SEMENOVSKIY further teaches wherein the electronic token exchange comprises a public or private key. (SEMENOVSKIY, “the present invention preferably uses Blockchain wallets (i.e., private-public key pairs) to encrypt the document on a peer-to-peer basis between signatories so only authorized (i.e., predetermined) parties can sign and read these sensitive documents.” Paragraph 87. The documents (i.e. forms) are verified using a blockchain that includes private-public key pairs.)
The same motivation to combine discussed in the rejection of claim 24 applies to claim 25.
Claims 5-12, 16, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over EIGNER (US 2014/0122508 A1) in view of LOPATA (US 2010/0153441 A1) and further in view of KUCA (US 2021/0019504 A1).
Regarding Claim 5, EIGNER discloses a non-transient computer-readable storage medium comprising instructions being executable by one or more processors to perform a method, the method comprising: (Paragraph 95, Fig. 13 processor 1302, memory 1303)
storing encrypted data filled by a user into a first form (“Each time the user populates information into a form, the system can save the final version of the form within a specific database table known as the customerFieldContent. The information stored in the form can be locked and will not be updated as other user information is updated, unless the user specifically accesses the previously-completed form, edits the form itself and creates a new version. The stored completed forms may be time and date stamped, to create a complete archive of the user’s activities within the system.” Paragraph 0070. Also see Paragraph 0040-42, which discusses a user filling out a “master form” or inputting already completed forms that are then stored in an online vault.
Each of the items of information filled by a user are encrypted: “Information is obtained from a plurality of different sources and classified through field mapping and other information classification techniques to build an organized database of information related to a user known as an information vault. The information is securely stored via encryption and disassociation techniques in one or more user databases to ensure the security of the information. A forms database is utilized for storing electronic forms and documents as well as the field information needed to complete the form or document.” Paragraph 0031. Also see Paragraphs 62-64, which discuss individually encrypting each item of information of a user.)
to encrypted cloud storage; (“The user profile may be encrypted and stored remotely in a cloud-based system at a remote server, with portions of the profile stored in separate locations with separate encryption to minimize the risk of unauthorized access to one portion of the information.” Paragraph 0010. Also see Paragraphs 31, 53, and 64, which discuss that the user’s information is encrypted and stored in separate databases.)
autofilling a second form having at least one field matching a field from the first form with the stored encrypted data from the encrypted cloud storage in the at least one matching field; (“The user can access their information to automatically populate the fields of an online form or an electronic document by selecting a document from the forms database or by utilizing a browser plug-in to populate an online form being displayed in a web browser.” Paragraph 0031. “The communications interface 104 will also include one or more information processing units within the server 106 to process the collected information, including a classification unit 106a which classifies the information to identify fields applicable to the information and values for the fields; a profile creation unit 106b which creates a user profile with the classified information; and an information populating unit 106c which populates at least one form field of an electronic form or database by matching the at least one form field with the classified information” Paragraph 0035. Also see Paragraphs 54-59, which further discuss the process of matching a field from a first form to a field in a second form in order to automatically populate a form.)
filling in by the user any non-matching fields with new encrypted data… (“The completion indicator may also provide the user with an indication of how much of a given category has been mapped or how much work is required to complete the unfilled fields… Although the system will populate any field for which it has information, certain fields may have no values or may have multiple values, in which case the field will not be automatically filled. In this situation, the user must take some action in order to populate the field.” Paragraphs 0083-84. Fields that are not automatically filled are manually filled by the user with new data. As discussed in Paragraphs 31 and 62-64, all data entered by the user is individually encrypted.)
and storing the new encrypted data to the encrypted cloud storage. (“if the user manually alters a field value for a particular field after the system has populated the field, the system will denote the changed value and store the newly-input value in the system database, preferably in the information vault of the user’s profile. The user can therefore update their profiles automatically while changing the information being input into a form.” Paragraph 0091. Any new information input the by the user is stored on the user’s encrypted profile, which as discussed in Paragraph 0010, is an encrypted cloud storage.)
While EIGNER teaches utilizing the disclosed method within a government environment (Paragraph 33), EIGNER does not explicitly teach wherein the first form and the second form are governmental applications from different government agencies.
However, LOPATA, which is directed to a single access point for filling and filing government forms, teaches wherein the first form and the second form are governmental applications from different government agencies. (See Paragraphs 13, 28-30, 34, 51, 53, 55: A user accesses a plurality of government forms using a single access point. User data that was previously entered and stored in a database is used to pre-populate fields in a selected form. After the user completes the form, it is submitted to the appropriate government agency, including with the compatible format corresponding to the government agency.)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the auto-filling of forms using previously submitted information stored in an encrypted cloud database taught by EIGNER by applying the system in order to auto-fill and file multiple governmental applications as taught by LOPATA. Since EIGNER (¶ 33) at least suggests applying the encrypted autofill system to a government application, the combination would have yielded predictable results. Furthermore, as suggested by LOPATA (¶ 10, 12-13), providing a single access point for a user to fill and file multiple government forms with multiple different agencies would reduce inefficiencies in the filing system and save the user time.
EIGNER in view of LOPATA further teaches wherein two or more second forms having at least one field matching a field from the first form are autofilled with the stored encrypted cloud storage in the at least one matching field of the two or more second forms. (EIGNER, See Paragraph 35, 54-60, which discuss the process of matching a field from a first form to a field in a second form in order to automatically populate a form. ¶ 35: “The user, through any type of device 110a-c, may then request that one or more forms 112 be completed using the information in their profile… The user can interact with the communications interface 104 through the device 110 to complete one or more forms 112a-c, such as an image viewer 112a, a form displayed in an internet-browser application 112b, or a form displayed via an application 112c running on the portable electronic device 110c”. ¶ 60: “different forms may have different ways to refer to the same user field name… When a subsequent field called “First Name” in encountered, its value would have already been stored and easily located through the “userFieldCollections” table”.
Also see LOPATA, ¶ 13: “Multiple electronic forms are accessible to the customer at a single access point, such as on a web site”; ¶ 51: “a database server 908 is queried to determine whether data specific to this customer and pertinent to any of the blank data fields of the selected form have been previously stored. If so, the data is used to populated those blank data fields prior to presenting the form”)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to autofill matching fields in multiple different forms from previously saved form data as taught by EIGNER. This is further supported by LOPATA (¶ 13, 51), which teaches a single access point for filling multiple forms from different agencies. When a user chooses a form, the previously stored data is pre-populated in matching fields of the form. This would occur again if the user selects multiple other forms. Such an implementation would have therefore been advantageous for improving the convenience of the form filling process for the user, especially in a situation where they have three or more forms to fill.
EIGNER in view of LOPATA does not teach verifying the user or a user’s signature using a vital document, a third-party signature service, or an electronic token exchange.
However, KUCA, which is directed to verifying a signatory of an electronic document, teaches and verifying the user or a user’s signature using a vital document, a third-party signature service, or an electronic token exchange. (See Paragraph 2, which teaches that the disclosure of KUCA is directed to a third-party service for authenticating a user signing an electronic document, including legal documents. See Figure 2 and Paragraphs 47, 53, 55, 59, 62, and 75-76: A process is described in which both an image of a user and a user’s signature is obtained and compared to verified signature data and vital documents in a user profile in order to determine if the user signing the document is the intended signatory of the document. If there is a high enough confidence that the correct user is signing the document, the user and user’s signature data is verified and the signed document is generated.)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the method of securely auto-filling government forms taught by EIGNER in view of LOPATA by incorporating the method of verifying a user and a user’s signature using a vital document and third-party signature service as taught by KUCA. Since KUCA is also directed to completing electronic documents, including forms, the combination would have yielded predictable results. As taught by KUCA (Paragraphs 4-5), verifying a user and a user’s signature would improve the electronic form completion process by reducing fraud and enabling a faster verification process.
Regarding Claim 6, EIGNER in view of LOPATA and KUCA further teaches logging, by the user, into a platform for the first form having fields. (EIGNER, “a website run by an academic institution may integrate access to the system into their application for applying for admission, such that upon loading the admissions application, the user can log in and then access their information to populate the admissions application directly through the website. In addition, an internet shopping website may integrate access to the system database so that when the user is ready to check out and purchase goods or services from the website, a button, link or authentication dialogue will be available for the user to select and then populate their information onto a payment screen.” Paragraph 0078. Also see Paragraphs 0063-64, which teaches that the user must log in to access the encrypted form data.)
Regarding Claim 7, EIGNER in view of LOPATA and KUCA further teaches further comprising sending the filled first form to the user. (EIGNER, “the system may be offered as a mobile application running on a smartphone, tablet or other portable electronic device that would enable a user to complete forms or other documents” Paragraph 0033. “The information stored in the form can be locked and will not be updated as other user information is updated, unless the user specifically accesses the previously-completed form, edits the form itself and creates a new version.” Paragraph 0070. The filled first form is accessed by a user using their device, which would involve the form being sent to the user device from the encrypted cloud storage upon request by the user.)
Regarding Claim 8, EIGNER in view of LOPATA and KUCA further teaches further comprising providing to the user a set of computer-executed instructions that, when executed by a user’s user device, generate a user interface displayable on an electronic display coupled to the user’s user device. (EIGNER, “Users 116 can access the system via the various devices 110 described above… The UI/UX 104b includes a web and interface server 106f connected with a forms and applications output database 108a.” Paragraphs 0035-36. See Figure 5, which illustrates an example user interface.)
Regarding Claim 9, EIGNER discloses a system, comprising: one or more hardware processors configured by machine-readable instructions to: (Paragraph 95, Fig. 13 processor 1302, memory 1303)
store encrypted data filled by a user into a first form (“Each time the user populates information into a form, the system can save the final version of the form within a specific database table known as the customerFieldContent. The information stored in the form can be locked and will not be updated as other user information is updated, unless the user specifically accesses the previously-completed form, edits the form itself and creates a new version. The stored completed forms may be time and date stamped, to create a complete archive of the user’s activities within the system.” Paragraph 0070. Also see Paragraph 0040-42, which discusses a user filling out a “master form” or inputting already completed forms that are then stored in an online vault.
Each of the items of information filled by a user are encrypted: “Information is obtained from a plurality of different sources and classified through field mapping and other information classification techniques to build an organized database of information related to a user known as an information vault. The information is securely stored via encryption and disassociation techniques in one or more user databases to ensure the security of the information. A forms database is utilized for storing electronic forms and documents as well as the field information needed to complete the form or document.” Paragraph 0031. Also see Paragraphs 62-64, which discuss individually encrypting each item of information of a user.)
to encrypted cloud storage; (“The user profile may be encrypted and stored remotely in a cloud-based system at a remote server, with portions of the profile stored in separate locations with separate encryption to minimize the risk of unauthorized access to one portion of the information.” Paragraph 0010. Also see Paragraphs 31, 53, and 64, which discuss that the user’s information is encrypted and stored in separate databases.)
autofill a second form having at least one field matching a field from the first form with the stored encrypted data from the encrypted cloud storage in the at least one matching field; (“The user can access their information to automatically populate the fields of an online form or an electronic document by selecting a document from the forms database or by utilizing a browser plug-in to populate an online form being displayed in a web browser.” Paragraph 0031. “The communications interface 104 will also include one or more information processing units within the server 106 to process the collected information, including a classification unit 106a which classifies the information to identify fields applicable to the information and values for the fields; a profile creation unit 106b which creates a user profile with the classified information; and an information populating unit 106c which populates at least one form field of an electronic form or database by matching the at least one form field with the classified information” Paragraph 0035. Also see Paragraphs 54-59, which further discuss the process of matching a field from a first form to a field in a second form in order to automatically populate a form.)
fill in by the user any non-matching fields with new encrypted data; (“The completion indicator may also provide the user with an indication of how much of a given category has been mapped or how much work is required to complete the unfilled fields… Although the system will populate any field for which it has information, certain fields may have no values or may have multiple values, in which case the field will not be automatically filled. In this situation, the user must take some action in order to populate the field.” Paragraphs 0083-84. Fields that are not automatically filled are manually filled by the user with new data. As discussed in Paragraphs 31 and 62-64, all data entered by the user is individually encrypted.)
and store the new encrypted data to the encrypted cloud storage. (“if the user manually alters a field value for a particular field after the system has populated the field, the system will denote the changed value and store the newly-input value in the system database, preferably in the information vault of the user’s profile. The user can therefore update their profiles automatically while changing the information being input into a form.” Paragraph 0091. Any new information input the by the user is stored on the user’s encrypted profile, which as discussed in Paragraph 0010, is an encrypted cloud storage.)
While EIGNER teaches utilizing the disclosed method within a government environment (Paragraph 33), EIGNER does not explicitly teach wherein the first form and the second form are governmental applications from different government agencies.
However, LOPATA, which is directed to a single access point for filling and filing government forms, teaches wherein the first form and the second form are governmental applications from different government agencies. (See Paragraphs 13, 28-30, 51, 53, 55: A user accesses a plurality of government forms using a single access point. User data that was previously entered and stored in a database is used to pre-populate fields in a selected form. After the user completes the form, it is submitted to the appropriate government agency, including with the compatible format corresponding to the government agency.)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the auto-filling of forms using previously submitted information stored in an encrypted cloud database taught by EIGNER by applying the system in order to auto-fill and file multiple governmental applications as taught by LOPATA. Since EIGNER (¶ 33) at least suggests applying the encrypted autofill system to a government application, the combination would have yielded predictable results. Furthermore, as suggested by LOPATA (¶ 10, 12-13), providing a single access point for a user to fill and file multiple government forms with multiple different agencies would reduce inefficiencies in the filing system and save the user time.
EIGNER in view of LOPATA further teaches wherein two or more second forms having at least one field matching a field from the first form are autofilled with the stored encrypted cloud storage in the at least one matching field of the two or more second forms. (EIGNER, See Paragraph 35, 54-60, which discuss the process of matching a field from a first form to a field in a second form in order to automatically populate a form. ¶ 35: “The user, through any type of device 110a-c, may then request that one or more forms 112 be completed using the information in their profile… The user can interact with the communications interface 104 through the device 110 to complete one or more forms 112a-c, such as an image viewer 112a, a form displayed in an internet-browser application 112b, or a form displayed via an application 112c running on the portable electronic device 110c”. ¶ 60: “different forms may have different ways to refer to the same user field name… When a subsequent field called “First Name” in encountered, its value would have already been stored and easily located through the “userFieldCollections” table”.
Also see LOPATA, ¶ 13: “Multiple electronic forms are accessible to the customer at a single access point, such as on a web site”; ¶ 51: “a database server 908 is queried to determine whether data specific to this customer and pertinent to any of the blank data fields of the selected form have been previously stored. If so, the data is used to populated those blank data fields prior to presenting the form”)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to autofill matching fields in multiple different forms from previously saved form data as taught by EIGNER. This is further supported by LOPATA (¶ 13, 51), which teaches a single access point for filling multiple forms from different agencies. When a user chooses a form, the previously stored data is pre-populated in matching fields of the form. This would occur again if the user selects multiple other forms. Such an implementation would have therefore been advantageous for improving the convenience of the form filling process for the user, especially in a situation where they have three or more forms to fill.
EIGNER in view of LOPATA does not teach and verifying the user or a user’s signature using a vital document, a third-party signature service, or an electronic token exchange.
However, KUCA, which is directed to verifying a signatory of an electronic document, teaches and verifying the user or a user’s signature using a vital document, a third-party signature service, or an electronic token exchange. (See Paragraph 2, which teaches that the disclosure of KUCA is directed to a third-party service for authenticating a user signing an electronic document, including legal documents. See Figure 2 and Paragraphs 47, 53, 55, 59, 62, and 75-76: A process is described in which both an image of a user and a user’s signature is obtained and compared to verified signature data and vital documents in a user profile in order to determine if the user signing the document is the intended signatory of the document. If there is a high enough confidence that the correct user is signing the document, the user and user’s signature data is verified and the signed document is generated.)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the method of securely auto-filling government forms taught by EIGNER in view of LOPATA by incorporating the method of verifying a user and a user’s signature using a vital document and third-party signature service as taught by KUCA. Since KUCA is also directed to completing electronic documents, including forms, the combination would have yielded predictable results. As taught by KUCA (Paragraphs 4-5), verifying a user and a user’s signature would improve the electronic form completion process by reducing fraud and enabling a faster verification process.
Regarding Claim 10, EIGNER in view of LOPATA and KUCA further teaches logging, by the user, into a platform for the first form having fields. (EIGNER, “a website run by an academic institution may integrate access to the system into their application for applying for admission, such that upon loading the admissions application, the user can log in and then access their information to populate the admissions application directly through the website. In addition, an internet shopping website may integrate access to the system database so that when the user is ready to check out and purchase goods or services from the website, a button, link or authentication dialogue will be available for the user to select and then populate their information onto a payment screen.” Paragraph 0078. Also see Paragraphs 0063-64, which teaches that the user must log in to access the encrypted form data.)
Regarding Claim 11, EIGNER in view of LOPATA and KUCA further teaches sending the filled first form to the user. (EIGNER, “the system may be offered as a mobile application running on a smartphone, tablet or other portable electronic device that would enable a user to complete forms or other documents” Paragraph 0033. “The information stored in the form can be locked and will not be updated as other user information is updated, unless the user specifically accesses the previously-completed form, edits the form itself and creates a new version.” Paragraph 0070. The filled first form is accessed by a user using their device, which would involve the form being sent to the user device from the encrypted cloud storage upon request by the user.)
Regarding Claim 12, EIGNER in view of LOPATA and KUCA further teaches further comprising providing to the user a set of computer-executed instructions that, when executed by a user’s user device, generate a user interface displayable on an electronic display coupled to the user’s user device. (EIGNER, “Users 116 can access the system via the various devices 110 described above… The UI/UX 104b includes a web and interface server 106f connected with a forms and applications output database 108a.” Paragraphs 0035-36. See Figure 5, which illustrates an example user interface.)
Regarding Claim 16, EIGNER in view of LOPATA and KUCA further teaches further comprises verifying that the encrypted data and the new encrypted data are correct per a government standard with a computer-implemented verification process. (LOPATA, Paragraph 30, 51: Data mapping software and translator components are used to convert submitted form data into the proper format for submission to the appropriate government agency: “business process orchestration software determines the proper format for data from the submitted form in order to be properly received and processed by the government agency systems 302, 304”. Therefore, there is a process of verifying that the data is correct per a government standard.)
Before the effective filing date of the invention, it would have been further obvious to one of ordinary skill in the art to incorporate the method of verifying that the completed fields of a form are correct per a government standard taught by LOPATA within the system of securely auto-filling forms taught by EIGNER. Incorporating the determination of a proper data format and conversion process taught by LOPATA would aid the user in the submission of a government form without errors, saving time for both the user and the government agency.
Regarding Claim 18, EIGNER in view of LOPATA and KUCA further teaches further comprises verifying that the encrypted data and the new encrypted data are correct per a government standard with a computer-implemented verification process. (LOPATA, Paragraph 30, 51: Data mapping software and translator components are used to convert submitted form data into the proper format for submission to the appropriate government agency: “business process orchestration software determines the proper format for data from the submitted form in order to be properly received and processed by the government agency systems 302, 304”. Therefore, there is a process of verifying that the data is correct per a government standard.)
Before the effective filing date of the invention, it would have been further obvious to one of ordinary skill in the art to incorporate the method of verifying that the completed fields of a form are correct per a government standard taught by LOPATA within the system of securely auto-filling forms taught by EIGNER. Incorporating the determination of a proper data format and conversion process taught by LOPATA would aid the user in the submission of a government form without errors, saving time for both the user and the government agency.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
King (US 2015/0332082 A1) teaches storing a vital, government-issued document that is used for user verification while signing documents for later use. (¶ 46, 172, 179)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RAMI RAFAT OKASHA whose telephone number is (571)272-0675. The examiner can normally be reached M-F 10-6 EST.
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, SCOTT BADERMAN can be reached at (571) 272-3644. 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.
/RAMI R OKASHA/Primary Examiner, Art Unit 2118
Prosecution Insights