DETAILED ACTION
This action is responsive to the request for continued examination filed 11/10/2025.
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 argument regarding the prior art on Pages 2-4 of the Remarks have been fully considered but are not persuasive.
Applicant argues on Page 2 of the Remarks that neither Eigner nor Lopata teaches “cross-agency interoperability”, “sharing data among distinct agencies”, and “inter-agency data exchange”. It appears applicant is relying on the claim language “wherein the first form ad the second form are governmental applications from different government agencies”. However, the claims do not recite sharing or exchanging data between different government agencies or “cross-agency interoperability”. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Lopata teaches the plain meaning of the limitations “wherein the first form and the second form are governmental applications from different government agencies” since Lopata teaches a single access point for a user to fill out and file a plurality of governmental applications for different government agencies. While the claim does not require “inter-agency data exchange” and “cross-agency interoperability”, Lopata teaches these features, as well. Therefore, even if these features are considered to be implied by the BRI of the claim, these features do not distinguish the claim from Lopata. See Paragraphs 13, 28-30, 34, 51, 53, and 55. In particular:
“utilizing the published electronic forms for web-based transactional services between government agencies and customers” ¶ 13
“Multiple electronic forms are accessible to the customer at a single access point, such as on a web site. At the web site, the customer selects a form for filing with a government agency… a back-end system integrated with the web site handles the completed form, determines the appropriate government agency for filing the form… and transmits it as a transaction to the determined government agency.” ¶ 13
“The present invention provides a single access point 306 for submitting filings of forms to one or more of a plurality of government agencies” ¶ 28
“A customer 900 accesses web services 902 at a single access point for submitting filings to one of a plurality of government agencies” ¶ 51
“A secondary forms controller 1004 provides common forms services for all applications, associated with all government agencies” ¶ 53
Applicant argues on Pages 2-3 of the Remarks that the prior art doe not teach the limitations “storing encrypted data filled by a user into a first form to encrypted cloud storage” and “storing the new encrypted data to the encrypted cloud storage”. Applicant asserts that Eigner’s data population relies on unencrypted or locally encrypted form fields and therefore does not teach these limitations. The examiner respectfully disagrees. Again, Eigner teaches the plan claim language of storing data filled by a user into a first form, as well as new data, the data being encrypted and stored in a cloud storage. See the detailed description of the teachings of Eigner in the 103 rejections below. In particular, Paragraph 31 teaches that the user data is encrypted and Paragraph 10 teaches that the encrypted data is stored in a cloud storage. Paragraph 91 teaches storing the new encrypted data to the encrypted cloud storage, which Eigner calls “the information vault”.
Applicant argues on Page 3 of the Remarks that Kuca “teaches encryption, not authentication”, and argues none of the references, including Kuca, teaches the limitations “verifying the user or a user’s signature using a vital document, a third-party signature service, or an electronic token exchange”. The examiner respectfully disagrees. Kuca explicitly teaches user authentication of both a user and their signature, the authentication using a vital document of the user (i.e. a government issued ID). See the following relevant citations:
“The described embodiments relate to authenticating a user signing an electronic document, and in particular to systems and methods of electronically authenticating one or more users signing an electronic document, such as a contract or other legal document” ¶ 2
“signature data is received. Signature data may refer to any data associated with a user's signature… the signature data may be compared to previously recorded data about a user's signature in order to verify that the received signature data was created by (or was likely created by) the user of interest.” ¶ 47
“At 220, first image data is received. The first image data may include an identification document… the identification document may be a government issued ID card that included an image of the individual. The image of the individual include a facial image. The identification document may also include the individual's signature” ¶ 53
“a confidence level for the correspondence between the collected data (about the person signing the electronic document) and stored data (associated with a known user) is generated. This correspondence may be determined based on the first image data, the second image data, the signature data, and verified data (including for example verified signature data, and/or verified image data about a known user)” ¶ 59
Applicant argues on Page 3 of the Remarks that there is no reason to combine the teachings of Eigner, Lopata, and Kuca to arrive at the claimed invention since Eigner is directed to convenience of web-form completion, Lopata addresses submission within a particular agency, and Kuca focuses on generic cloud storage and that all the references have different architectures. The examiner respectfully disagrees.
First, Eigner substantially teaches the automatic form filling, encryption of user data, and cloud-based storage recited by the claims as discussed in the detailed 103 rejections below. Lopata is directed to filling and filing forms for all government agencies using a single access point, not merely a particular agency. Kuca is directed to user authentication and signature verification for legal forms; it is not focused on cloud storage infrastructure. Rather, Eigner is the reference relied upon for teaching user data encryption and cloud storage.
Second, in response to applicant's argument that the architectures of the references cannot be combined, 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). As discussed above, Eigner teaches the automatic filling of forms with user data that is also encrypted and stored in cloud storage. Lopata is relied upon to teach applying such a form filling and filing system as taught by Eigner to filling out a plurality of government forms for different agencies and filing the forms with the different government agencies. Kuca is relied upon to teach user authentication and signature verification using a vital document, which would have been reasonably incorporated into a form filling and filing system, especially for governmental or legal applications. The combination of the teachings of the prior art therefore renders the claim obvious as discussed in further detail in the 103 rejections below.
Applicant argues on Page 4 of the Remarks that Semenovskiy does not teach the limitations of claims 24-25 and cannot be combined with Eigner, Lopata, and Kuca. The examiner respectfully disagrees.
In response to applicant's argument that Seminovskiy’s procedure would be “incompatible” with the teachings Eigner, Lopata, and Kuca, 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. While Kuca is relied upon to teach the first limitation, Semenovskiy also 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 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 not required to teach “government-form autofill”, as asserted by the applicant on Page 4 of the Remarks. This limitation is taught by the other prior art references. Rather, 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 on Page 4 of the Remarks.
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.
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-12, 14, 16, 18-23, 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 KUCA (US 2021/0019504 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.
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 and filing 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 2, 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 3, 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 4, 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 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 14, 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 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.
Regarding Claim 19, EIGNER in view of LOPATA and KUCA further teaches wherein the verifying step uses a vital document. (KUCA, “The first image data may include an identification document. The identification document may refer to a document which may be used to identify an individual. For example, the identification document may be a government issued ID card that included an image of the individual.” Paragraph 0053.)
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 KUCA further teaches wherein the vital document is an image file or a certified electronic copy from an issuing government authority. (KUCA, “The first image data may include an identification document. The identification document may refer to a document which may be used to identify an individual. For example, the identification document may be a government issued ID card that included an image of the individual.” Paragraph 0053.)
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 KUCA further teaches wherein the vital document is chosen from a birth certificate, driver's license, or passport. (KUCA, “the identification document may be issued by a government or other organization. The identification document may be, for example, a driver's licence, a passport, or a health card.” Paragraph 0054.)
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 KUCA 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. (KUCA, “The user device 140 may allow the user to enter data to generate an verified or authenticated user profile, for example by taking a photograph, storing signature information, or uploading identifying information.” Paragraph 45. “Once this verification process is complete, the verified user profile can be used as a baseline for future signing transactions.” Paragraph 0098.)
In addition to the motivation to combine discussed in the rejection of claim 1, it would have been further obvious to store the vital document to use in future signing transactions as taught by KUCA. Such a combination would have amounted to a mere data storing step that would improve the convenience of the interface for the user by allowing for faster transactions in the future.
Regarding Claim 23, EIGNER in view of LOPATA and KUCA further teaches wherein the verifying step uses a third-party signature service. (KUCA, See Figures 15-21 and Paragraphs 92-98, which illustrate the third-party signature service being used to verify the user and their signature.)
The same motivation to combine discussed in the rejection of claim 1 applies to claim 23.
Regarding Claim 27, EIGNER in view of LOPATA and KUCA further teaches further comprising displaying a completion status of further forms, which is automatically updated when the second form is completed. (KUCA, See ¶ 82 and Fig. 5: a completion states of multiple documents are displayed. When a form is completed (i.e. signed and verified by the required users), the completion state is updated.)
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 KUCA by incorporating a user interface for displaying the completion status of the forms as taught by KUCA. 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 24-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 KUCA (US 2021/0019504 A1) and SEMENOVSKIY (US 2021/0281421 A1).
Regarding Claim 24, EIGNER in view of LOPATA and KUCA teaches all the limitations of claim 1, on which claim 24 depends.
EIGNER in view of LOPATA and KUCA 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 KUCA 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.
Regarding Claim 25, EIGNER in view of LOPATA, KUCA, 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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Iasi (US 2017/0277773 A1) teaches another embodiment of the primary reference, Eigner, including automatically populating fields of a form using encrypted user information stored in a database. (¶ 65, 102, 119-120)
Sharfman (US 11,038,677 B2) teaches encryption and decryption of form fields. (Abstract, Figs. 5B-5C)
All claims are identical to or patentably indistinct from, or have unity of invention with claims in the application prior to the entry of the submission under 37 CFR 1.114 (that is, restriction (including a lack of unity of invention) would not be proper) and all claims could have been finally rejected on the grounds and art of record in the next Office action if they had been entered in the application prior to entry under 37 CFR 1.114. Accordingly, THIS ACTION IS MADE FINAL even though it is a first action after the filing of a request for continued examination and the submission under 37 CFR 1.114. See MPEP § 706.07(b). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry 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 on (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