DETAILED ACTION
Priority
Applicant’s claim for the benefit to 17/207,435 filed March 19, 2021, PCT/US2021/021135 filed March 5, 2021 and 63/021968 filed May 8, 2020 is acknowledged. The effective filing date used for examination purposes is therefore May 8, 2020.
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 .
Information Disclosure Statement
The information disclosure statement filed November 22, 2023 fails to comply with 37 CFR 1.98(a)(2), which requires a legible copy of each cited foreign patent document; each non-patent literature publication or that portion which caused it to be listed; and all other information or that portion which caused it to be listed. It has been placed in the application file, but the information referred to therein has not been considered. Copies of the NPL documents considered were found in Parent application 18/236080. No copy of the following NPL has been provided:
-NPL #3 “Populate Web forms with JSP and XML – Tech Republic”
-NPL #18 International Search Report and Written Opinion Dated August 13, 2021 for Application Num PCT/US2021/021135.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed. The title is generic and does not articulate the specific focus of this particular patent application.
The following title is suggested: Creating Enhanced document based on semantic meaning of content.
Drawings
The drawings are objected to under 37 CFR 1.83(a). The drawings must show every feature of the invention specified in the claims. Therefore, the “generating an enhanced document from the content of the initial document that encodes the content in a structured form according to a defined schema, based on semantic meaning of elements of the content, and embeds the subset of content in non-visible metadata in the enhanced document.” must be shown or the feature(s) canceled from the claim(s). No new matter should be entered.
The drawings are objected to because figures 2-5 contain text that is blurred and unreadable (e.g. the text of the example structured data).
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
With regard to claims 1, 10, and 18, claim 1 recites “receiving content… wherein the content is unstructured… generating an enhanced document… that encodes the content in a structured form”. This claim limitation lacks antecedent basis.
Where applicant acts as his or her own lexicographer to specifically define a term of a claim contrary to its ordinary meaning, the written description must clearly redefine the claim term and set forth the uncommon definition so as to put one reasonably skilled in the art on notice that the applicant intended to so redefine that claim term. Process Control Corp. v. HydReclaim Corp., 190 F.3d 1350, 1357, 52 USPQ2d 1029, 1033 (Fed. Cir. 1999). The terms “structured” and “unstructured” are indefinite because the specification does not clearly redefine them.
Paragraph [0003] of the initial specification appears to describe DOCX and PDF formats as “unstructured” formats. Yet, Paragraphs [0023] and [0047] both describe DOCX and PDF as structured formats. It is unclear if the DOCX and PDF formats should be considered ‘structured’ or ‘unstructured’ within the invention.
Paragraph [0003]: Electronic documents are frequently stored in file formats, like Microsoft Word's DOCX format or Adobe Acrobat's PDF format, that allow for documents to be rendered in a manner that is visually appealing to a human reader. But these formats typically store information in an unstructured manner making it difficult for automated parsing software (or parsers) to interpret the electronic document accurately, resulting in misread or miscategorized data.
Paragraph [0023] In response to a user request to export the initial document 150 in a particular file format (e.g., in Microsoft Word's DOCX format or Adobe Acrobat's PDF format), the enhanced document creation system 110 may export the initial document 150 as an enhanced document 151, namely by encoding the document content according to a defined schema and embedding the structured content as non-visible metadata in the enhanced document 151.
Paragraph [0047] Rendering logic 123 may allow the enhanced document creation system 110 to render an encoded document (or desensitized or translated document, as the case may be) in a particular file format (e.g., Microsoft Word's DOCX format or Adobe Acrobat's PDF format), which in some embodiments, may be specified by a user 101. The rendering logic 123, for example, may be used to generate an intermediate file from the encoded content, where the visual appearance of the document content (i.e., the positioning and style of the document content) may be provided by a skin definition associated with initial document 150, which may be stored and retrieved from skin library 114a. The enhanced document creation system 110, for example, may generate an HTML file comprising different HTML elements, with specified CSS styles, along with a linked CSS stylesheet to control the position and style (i .e., the visual appearance) of the document content. The enhanced document creation system 110 may then convert the intermediate file into a particular file format, like Microsoft Word's DOCX format or Adobe Acrobat's PDF format. In doing so, the enhanced document creation system 110 may make use of publicly available conversion libraries, like Aspose (for HTML to DOCX conversion) or ABCpdf (for HTML to PDF conversion).
Paragraph [0026] of the original specification describes the ‘enhanced document’, which is supposed to be the structured document, as being in JSON, HTML, RTF, or TXT format. Yet one of ordinary skill in the art would typically recognize “TXT format” as being ‘unstructured’.
Paragraph [0026] “the enhanced document parsing system 130 may be able to specify the format in which the encoded content should be returned (e.g., a JSON, HTML, RTF, or TXT format).”
For examination purposes the ‘unstructured’ document has been interpreted as a basic text file as this is the one format that one of ordinary skill in the art typically identifies as being ‘unstructured’. For examination purposes the ‘structured’ document has interpreted as including DOCX, PDF, or HTML (as per Paragraph [0047]) XML or JSON (as per Paragraph [0003]) formats.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4-6, 8, 10, 13-15, 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Satyaki [Resume Parser with Natural Language Processing] in view of Nunes [2018/0082074]
With regard to claim 1 Satyaki teaches A method of creating an enhanced document as the structured document resulting from the transformation (Satyaki, Page 4484, Section I “To design a model this can parse information from unstructured resumes and transform it to a structured JSON format”), comprising:
receiving content as reading the content (Satyaki, Page 4485-Page 4486 Section A. The Uploader: “First, the client uploads a file. The algorithm blocks any file having an extension other than '.pdf, '.doc', '.docx', '.odt', ' .ads ', '.txt'. After the client has successfully uploaded the file , the algorithm takes the file, reads the contents and writes the content into a text file before passing on the data to the parser.”) associated with creating an initial document as the text file created (Id) such as the original unstructured text resume submitted by a user (Satyaki, Page 4485 “student trying to beautify his/her unstructured text resume and convert into a beautiful pdf format. In either case, the algorithm remains same.”) with a document creation platform as a resume created using a websites particular formatting (Satyaki, Page 4484, Section III. History of Hiring: “These agencies required the applicants to upload their resumes on their websites in particular formats”), wherein the content is unstructured as the uploaded file and the generated text file are both ‘unstructured’ (Page 4485-Page 4486 Section A. The Uploader: “First, the client uploads a file. The algorithm blocks any file having an extension other than '.pdf, '.doc', '.docx', '.odt', ' .ads ', '.txt'. After the client has successfully uploaded the file , the algorithm takes the file, reads the contents and writes the content into a text file before passing on the data to the parser.”; Please note that the term “unstructured” has been read interpreted as detailed in the 112b rejection above);
identifying a subset of the content (Satyaki, Page 4486 Section B. The Parser: “It parses all the relevant data from the uploaded resume including name, emails, contact numbers, social profile links, personal websites, years of work experience, work experiences, years of education, degrees, volunteer experiences, publications, skills, cluster(s) and languages through natural language processing and without any human interaction”) designated as [[ as the person’s name, email address, personal websites, ect (Satyaki, Page 4484 Section II Introduction: “Parsed information include name, email address, social profiles, personal websites, years of work experience, work experiences, years of education, education experiences, publications, certifications, volunteer experiences, keywords and finally the cluster of the resume (ex: computer science, human resource, etc.).”; Please note “non-visible” content has been interpreted in light of Paragraph [0042] of the original specification which recites: “A user 101 may be able to redact or hide certain information ( e.g., their personal identification information, the name of their current employer, references, or any other information they would like to protect) such that it is not visible on the resume, while still including it as encoded content embedded therein”); and
generating an enhanced document as generating a JSON resume (Satyaki, Page 4487 Section VI. Expected Outcome: “Once the user confirms the result of our parser the system generates a JSON resume and stores it in the NoSQL database.”) from the content as the results of our parser (Id) of the initial document as the text file that is passed to the parser (Satyaki, Page 4485-Page 4486 Section A. The Uploader: “First, the client uploads a file. The algorithm blocks any file having an extension other than '.pdf, '.doc', '.docx', '.odt', ' .ads ', '.txt'. After the client has successfully uploaded the file , the algorithm takes the file, reads the contents and writes the content into a text file before passing on the data to the parser.”) that encodes the content in a structured form as JSON format (Satyaki, Page 4487 Section VI. Expected Outcome: “Once the user confirms the result of our parser the system generates a JSON resume and stores it in the NoSQL database.”; Please note this claim limitation has been interpreted as detailed in the 112b rejection above) according to a defined schema as the defined JSON schema (Id), based on semantic meaning of elements of the content (Satyaki, Page 4486 Section II. Semantic Analysis: “Semantic analysis can be defined as the study of semantics i.e the structure and meaning of speech.”), and [[ as the user’s name and telephone (Satyaki, Page 4487 Figure E.9.1 Basic Information), personal website and email address (Satyaki, Page 4487 Figure E.9.2) in the enhanced document as generating a JSON resume (Satyaki, Page 4487 Section VI. Expected Outcome: “Once the user confirms the result of our parser the system generates a JSON resume and stores it in the NoSQL database.”).
Satyaki does not explicilty state that the content is designated as non-visible content, or embeds the subset of content in non-visible metadata.
Nunes teaches identify a subset of the content designated as non-visible content as a user wishing to encrypt part of the content (Nunes, ¶11 “In an example where a PDF includes both confidential and non-confidential content, a user may wish to encrypt only part of the content to minimize the file size of the PDF, and also to reduce the computational demands of assembling or encrypting the PDF file, or decrypting and/or disassembling or reassembling the PDF file. A user may also wish to include security mechanisms which provide for greater security than, for example, password protection alone, or greater than symmetric algorithms for encryption that may be vulnerable to, for example, key search techniques.”) such as when a user chooses to redact content (Nune, ¶26 “with certain content redacted or otherwise
unviewable as in PDF 124.”; and
generate an enhanced document as assembling a PDF (Nunes, ¶16 “Content provided by content provider 102 may be assembled into a format that is readable across various platforms. For example, content may be assembled into a PDF file that may follow or conform to a particular standard. In some examples, the PDF file may contain content and/or metadata, as well as custom fields or custom properties (hereinafter "custom fields") that may allow for custom values or data to be set or stored within the PDF, and with the PDF remaining readable across various platforms”) from the content as the content (Id) that encodes (Nunes, ¶29 “For example, metadata 204, data blocks 206, and a content map 208 may be signed and stored as a hash. e.g., hash 210. In some examples, the hash may be signed with a user's private key, e.g., private key 212. The resulting signature may then be stored in an assembled PDF, e.g., PDF 240, or in a custom field of the assembled PDF. Various signature techniques or cryptographic hash functions may be used, such as the Secure Hash Algorithm ("SHA"), at varying hash values, e.g., SHA-256. The signature, in some examples, may be encoded. e.g., in BASE64 or another encoding scheme.”) the content in a structured form as the Secure Hash Algorithm storing signatures in the PDF format (Id) according to a defined schema as the BASE 64 encoding scheme (Id), …, and embeds as storing the encryption key for the content in the PDF during assembly (¶17 “In some examples, the content assembled into a PDF file, such as PDF 110, may comprise both unencrypted content and encrypted content. Unencrypted content may represent non-confidential data, while encrypted content may represent confidential content.”; ¶29 “An encryption or assembly engine, such as encryption and assembly engine 106 may fetch and sign various parts of the content. For example, metadata 204, data blocks 206, and a content map 208 may be signed and stored as a hash. e.g., hash 210. In some examples, the hash may be signed with a user's private key, e.g., private key 212. The resulting signature may then be stored in an assembled PDF, e.g., PDF 240, or in a custom field of the assembled PDF.”) the subset of content in non-visible as redacted or otherwise encrypted confidential content (Nune, ¶26 “As shown in the examples of PDF 122 and 124, a PDF may be output with an of the PDF content visible, as in PDF 122, or with certain content redacted or otherwise unviewable as in PDF 124.”; ¶17 “Unencrypted content may represent non-confidential data, while encrypted content may represent confidential content.”) metadata as storing the encrypted content in the custom properties of the PDF (¶16 “In some examples, the PDF file may contain content and/or metadata, as well as custom fields or custom properties (hereinafter "custom fields") that may allow for custom values or data to be set or stored within the PDF, and with the PDF remaining readable across various platforms”) in the enhanced document as the PDF document (Id).
It would have been obvious to one of ordinary skill to which said subject matter pertains at the time the invention was filed to have incorporated the encryption techniques taught by Nune within the enhanced resume generation device taught by Satyaki as it would yield the predictable results of retaining the capability of PDF while increasing security and the ability to store unencrypted content within the single PDF file (Nune, ¶14; ¶11) this would allow users to redact (Nune, ¶26) certain parts of their resume while allowing other parts to remain visible (Nune, ¶26).
With regard to claims 4, 13, and 19 the proposed combination further teaches determining applicability of the non-visible content to a task as auto filling out a resume form (Satyaki, Abstract: “The parser parses all the necessary information from the resume and auto fills a form for the user to proofread”; Please note the limitation ‘task’ has been construed in light of paragraph [0044] as being the task of filling out a resume form. Paragraph [0044]: “By way of example, job applicants are frequently asked to provide basic bibliographic information (e.g., mailing address, work authorization status, etc.) or to submit a cover letter along with their resume. Repeatedly entering this information when applying for multiple jobs can be a laborious and monotonous task, frequently dissuading a job seeker from completing a job application.”;
requesting permission as presenting the auto filled form to the user to proofread and giving the user the ability to confirm (Satyaki, Page 4484 Abstract: “The parser parses all the necessary information from the resume and auto fills a form for the user to proofread. Once the user confirms, the resume is saved into our NoSQL database ready to show itself to the employers. Also, the user gets their resume in both JSON format and pdf.”; Page 4487 Section VI. Expected Outcome: “Some screen-shots of the result of our resume parser are portrayed below. Once the user confirms the result of our parser the system generates a JSON resume and stores it in the NoSQL database.”) to utilize the non-visible content as the user’s name and telephone (Satyaki, Page 4487 Figure E.9.1 Basic Information), personal website and email address (Satyaki, Page 4487 Figure E.9.2) to complete the task as the task of filling out the resume form (Satyaki, Page 4484 Abstract: “The parser parses all the necessary information from the resume and auto fills a form for the user to proofread. Once the user confirms, the resume is saved into our NoSQL database ready to show itself to the employers. Also, the user gets their resume in both JSON format and pdf.”; Page 4487 Section VI. Expected Outcome: “Some screen-shots of the result of our resume parser are portrayed below. Once the user confirms the result of our parser the system generates a JSON resume and stores it in the NoSQL database.”);
receiving permission to utilize the non-visible content as the user proofreading and confirming the auto filled resume form (Id); and
completing the task with the non-visible content as saving the resume once the user has confirmed the auto filled form (Id).
With regard to claims 5 and 14 the proposed combination further teaches wherein receiving the content associated with the initial document as the unstructured text resume (Satyaki, Page 4485 Section A. The Uploader: “The client may be a giant corporate firm who wants to parse and rank their tens and thousands of unstructured resumes or a student trying to beautify his/her unstructured text resume and convert into a beautiful pdf format. In either case, the algorithm remains same.”) comprises receiving a resume content as resume (Id) of an individual as a student (Id).
With regard to claims 6 and 15 the proposed combination further teaches wherein the non-visible content includes bibliographic information regarding an individual as the person’s name, email address, personal websites, ect (Satyaki, Page 4484 Section II Introduction: “Parsed information include name, email address, social profiles, personal websites, years of work experience, work experiences, years of education, education experiences, publications, certifications, volunteer experiences, keywords and finally the cluster of the resume (ex: computer science, human resource, etc.).”).
With regard to claims 8 and 17 the proposed combination further teaches encrypting the non-visible metadata prior to embedding the non-visible metadata in the enhanced document as encrypting using a hash, and then storing the generated signature in the PDF (Nune, ¶29 “An encryption or assembly engine, such as encryption and assembly engine 106 may fetch and sign various parts of the content. For example, metadata 204, data blocks 206, and a content map 208 may be signed and stored as a hash. e.g., hash 210. In some examples, the hash may be signed with a user's private key, e.g., private key 212. The resulting signature may then be stored in an assembled PDF, e.g., PDF 240, or in a custom field of the assembled PDF.”).
With regard to claim 10 Satyaki teaches An enhanced document creation system, comprising:
at least one processor coupled to at least one memory that includes instructions that, when executed by the at least one processor as the processor of the computer performing the algorithm (Satyaki, Page 4486, Section: Natural Language Processing: “Computer”; Page 4484 Section III. History of Hiring: “To overcome all the above problems an intelligent algorithm was required which could parse information from any unstructured resumes, sort it based on the clusters and rank it finally. The model uses natural language processing to understand the resume and then parse the information from it. Once information is parsed it is stored in the database.”, cause the system to:
receive content as reading the content (Satyaki, Page 4485-Page 4486 Section A. The Uploader: “First, the client uploads a file. The algorithm blocks any file having an extension other than '.pdf, '.doc', '.docx', '.odt', ' .ads ', '.txt'. After the client has successfully uploaded the file , the algorithm takes the file, reads the contents and writes the content into a text file before passing on the data to the parser.”) associated with creating an initial document as the text file created (Id) such as the original unstructured text resume submitted by a user (Satyaki, Page 4485 “student trying to beautify his/her unstructured text resume and convert into a beautiful pdf format. In either case, the algorithm remains same.”) with a document creation platform as a resume created using a websites particular formatting (Satyaki, Page 4484, Section III. History of Hiring: “These agencies required the applicants to upload their resumes on their websites in particular formats”), wherein the content is unstructured as the uploaded file and the generated text file are both ‘unstructured’ (Page 4485-Page 4486 Section A. The Uploader: “First, the client uploads a file. The algorithm blocks any file having an extension other than '.pdf, '.doc', '.docx', '.odt', ' .ads ', '.txt'. After the client has successfully uploaded the file , the algorithm takes the file, reads the contents and writes the content into a text file before passing on the data to the parser.”; Please note that the term “unstructured” has been read interpreted as detailed in the 112b rejection above);
identify a subset of the content (Satyaki, Page 4486 Section B. The Parser: “It parses all the relevant data from the uploaded resume including name, emails, contact numbers, social profile links, personal websites, years of work experience, work experiences, years of education, degrees, volunteer experiences, publications, skills, cluster(s) and languages through natural language processing and without any human interaction”) designated as [[ as the person’s name, email address, personal websites, ect (Satyaki, Page 4484 Section II Introduction: “Parsed information include name, email address, social profiles, personal websites, years of work experience, work experiences, years of education, education experiences, publications, certifications, volunteer experiences, keywords and finally the cluster of the resume (ex: computer science, human resource, etc.).”; Please note “non-visible” content has been interpreted in light of Paragraph [0042] of the original specification which recites: “A user 101 may be able to redact or hide certain information ( e.g., their personal identification information, the name of their current employer, references, or any other information they would like to protect) such that it is not visible on the resume, while still including it as encoded content embedded therein”); and
generate an enhanced document as generating a JSON resume (Satyaki, Page 4487 Section VI. Expected Outcome: “Once the user confirms the result of our parser the system generates a JSON resume and stores it in the NoSQL database.”) from the content as the results of our parser (Id) that encodes the content in a structured form as JSON format (Satyaki, Page 4487 Section VI. Expected Outcome: “Once the user confirms the result of our parser the system generates a JSON resume and stores it in the NoSQL database.”; Please note this claim limitation has been interpreted as detailed in the 112b rejection above) according to a defined schema as the defined JSON schema (Id), based on semantic meaning of elements of the content (Satyaki, Page 4486 Section II. Semantic Analysis: “Semantic analysis can be defined as the study of semantics i.e the structure and meaning of speech.”), and [[ as the user’s name and telephone (Satyaki, Page 4487 Figure E.9.1 Basic Information), personal website and email address (Satyaki, Page 4487 Figure E.9.2) in the enhanced document as generating a JSON resume (Satyaki, Page 4487 Section VI. Expected Outcome: “Once the user confirms the result of our parser the system generates a JSON resume and stores it in the NoSQL database.”).
Satyaki does not explicitly state that the content is designated as non-visible content, or embeds the subset of content in non-visible metadata.
Nunes teaches identify a subset of the content designated as non-visible content as a user wishing to encrypt part of the content (Nunes, ¶11 “In an example where a PDF includes both confidential and non-confidential content, a user may wish to encrypt only part of the content to minimize the file size of the PDF, and also to reduce the computational demands of assembling or encrypting the PDF file, or decrypting and/or disassembling or reassembling the PDF file. A user may also wish to include security mechanisms which provide for greater security than, for example, password protection alone, or greater than symmetric algorithms for encryption that may be vulnerable to, for example, key search techniques.”) such as when a user chooses to redact content (Nune, ¶26 “with certain content redacted or otherwise unviewable as in PDF 124.”; and
generate an enhanced document as assembling a PDF (Nunes, ¶16 “Content provided by content provider 102 may be assembled into a format that is readable across various platforms. For example, content may be assembled into a PDF file that may follow or conform to a particular standard. In some examples, the PDF file may contain content and/or metadata, as well as custom fields or custom properties (hereinafter "custom fields") that may allow for custom values or data to be set or stored within the PDF, and with the PDF remaining readable across various platforms”) from the content as the content (Id) that encodes (Nunes, ¶29 “For example, metadata 204, data blocks 206, and a content map 208 may be signed and stored as a hash. e.g., hash 210. In some examples, the hash may be signed with a user's private key, e.g., private key 212. The resulting signature may then be stored in an assembled PDF, e.g., PDF 240, or in a custom field of the assembled PDF. Various signature techniques or cryptographic hash functions may be used, such as the Secure Hash Algorithm ("SHA"), at varying hash values, e.g., SHA-256. The signature, in some examples, may be encoded. e.g., in BASE64 or another encoding scheme.”) the content in a structured form as the Secure Hash Algorithm storing signatures in the PDF format (Id) according to a defined schema as the BASE 64 encoding scheme (Id), …, and embeds as storing the encryption key for the content in the PDF during assembly (¶17 “In some examples, the content assembled into a PDF file, such as PDF 110, may comprise both unencrypted content and encrypted content. Unencrypted content may represent non-confidential data, while encrypted content may represent confidential content.”; ¶29 “An encryption or assembly engine, such as encryption and assembly engine 106 may fetch and sign various parts of the content. For example, metadata 204, data blocks 206, and a content map 208 may be signed and stored as a hash. e.g., hash 210. In some examples, the hash may be signed with a user's private key, e.g., private key 212. The resulting signature may then be stored in an assembled PDF, e.g., PDF 240, or in a custom field of the assembled PDF.”) the subset of content in non-visible as redacted or otherwise encrypted confidential content (Nune, ¶26 “As shown in the examples of PDF 122 and 124, a PDF may be output with an of the PDF content visible, as in PDF 122, or with certain content redacted or otherwise unviewable as in PDF 124.”; ¶17 “Unencrypted content may represent non-confidential data, while encrypted content may represent confidential content.”) metadata as storing the encrypted content in the custom properties of the PDF (¶16 “In some examples, the PDF file may contain content and/or metadata, as well as custom fields or custom properties (hereinafter "custom fields") that may allow for custom values or data to be set or stored within the PDF, and with the PDF remaining readable across various platforms”) in the enhanced document as the PDF document (Id).
It would have been obvious to one of ordinary skill to which said subject matter pertains at the time the invention was filed to have incorporated the encryption techniques taught by Nune within the enhanced resume generation device taught by Satyaki as it would yield the predictable results of retaining the capability of PDF while increasing security and the ability to store unencrypted content within the single PDF file (Nune, ¶14; ¶11) this would allow users to redact (Nune, ¶26) certain parts of their resume while allowing other parts to remain visible (Nune, ¶26).
With regard to claim 18 Satyaki teaches A method of creating an enhanced document, comprising:
receiving content as reading the content (Satyaki, Page 4485-Page 4486 Section A. The Uploader: “First, the client uploads a file. The algorithm blocks any file having an extension other than '.pdf, '.doc', '.docx', '.odt', ' .ads ', '.txt'. After the client has successfully uploaded the file , the algorithm takes the file, reads the contents and writes the content into a text file before passing on the data to the parser.”) of an initial document as the text file created (Id) such as the original unstructured text resume submitted by a user (Satyaki, Page 4485 “student trying to beautify his/her unstructured text resume and convert into a beautiful pdf format. In either case, the algorithm remains same.”) generated with a document creation platform as a resume created using a websites particular formatting (Satyaki, Page 4484, Section III. History of Hiring: “These agencies required the applicants to upload their resumes on their websites in particular formats”), wherein the content is unstructured as the uploaded file and the generated text file are both ‘unstructured’ (Page 4485-Page 4486 Section A. The Uploader: “First, the client uploads a file. The algorithm blocks any file having an extension other than '.pdf, '.doc', '.docx', '.odt', ' .ads ', '.txt'. After the client has successfully uploaded the file , the algorithm takes the file, reads the contents and writes the content into a text file before passing on the data to the parser.”; Please note that the term “unstructured” has been read interpreted as detailed in the 112b rejection above);
determining a first set of the content as parsing the years of word experience, work experiences, educational experiences, certifications, volunteer experiences, ect from the document (Satyaki, Page 4486 Section B. The Parser: “It parses all the relevant data from the uploaded resume including name, emails, contact numbers, social profile links, personal websites, years of work experience, work experiences, years of education, degrees, volunteer experiences, publications, skills, cluster(s) and languages through natural language processing and without any human interaction”) associated with the one or more attributes as segments of a resume (Satyaki, Page 4486 Section I. Lexical Analysis: “Considering our case, the resume is discriminated onto various segments including contact information, educational experiences, work experiences and more.”; Please note this claim limitation has been construed in light of Paragraph [0035] of the original specification which recites “a skill, hobby, or other attribute”) and a second set of the content as the person’s name, email address, personal websites, ect (Satyaki, Page 4484 Section II Introduction) [[ (Please note this claim limitation has been read in light of Paragraph [0042] of the original specification as users choosing to redact or hide certain information) the first set as parsing the years of word experience, work experiences, educational experiences, certifications, volunteer experiences, ect from the document (Satyaki, Page 4486 Section B. The Parser);
designating the second set of content as [[as the person’s name, email address, personal websites, ect (Satyaki, Page 4484 Section II Introduction: “Parsed information include name, email address, social profiles, personal websites, years of work experience, work experiences, years of education, education experiences, publications, certifications, volunteer experiences, keywords and finally the cluster of the resume (ex: computer science, human resource, etc.).”; Please note “non-visible” content has been interpreted in light of Paragraph [0042] of the original specification which recites: “A user 101 may be able to redact or hide certain information ( e.g., their personal identification information, the name of their current employer, references, or any other information they would like to protect) such that it is not visible on the resume, while still including it as encoded content embedded therein”);
generating an enhanced document as generating a JSON resume (Satyaki, Page 4487 Section VI. Expected Outcome: “Once the user confirms the result of our parser the system generates a JSON resume and stores it in the NoSQL database.”) from the content as the results of the parser (Id) of the initial document as the text file created (Page 4485-Page 4486 Section A) such as the original unstructured text resume submitted by a user (Satyaki, Page 4485 “student trying to beautify his/her unstructured text resume and convert into a beautiful pdf format. In either case, the algorithm remains same.”) that encodes the content in a structured form as JSON format (Satyaki, Page 4487 Section VI. Expected Outcome: “Once the user confirms the result of our parser the system generates a JSON resume and stores it in the NoSQL database.”; Please note this claim limitation has been interpreted as detailed in the 112b rejection above) according to a defined schema as the defined JSON schema (Id), based on semantic meaning of elements of the content (Satyaki, Page 4486 Section II. Semantic Analysis: “Semantic analysis can be defined as the study of semantics i.e the structure and meaning of speech.”), and [[ as the user’s name and telephone (Satyaki, Page 4487 Figure E.9.1 Basic Information), personal website and email address (Satyaki, Page 4487 Figure E.9.2) in the enhanced document as generating a JSON resume (Satyaki, Page 4487 Section VI. Expected Outcome: “Once the user confirms the result of our parser the system generates a JSON resume and stores it in the NoSQL database.”).
Satyaki does not explicilty teach a second set of content excluded from the first set; designating the second set of content as non-visible cotnent... embeds the subset of content in non-visible metadata.
Nunes teaches a second set as a user wishing to encrypt part of the content (Nunes, ¶11 “In an example where a PDF includes both confidential and non-confidential content, a user may wish to encrypt only part of the content to minimize the file size of the PDF, and also to reduce the computational demands of assembling or encrypting the PDF file, or decrypting and/or disassembling or reassembling the PDF file. A user may also wish to include security mechanisms which provide for greater security than, for example, password protection alone, or greater than symmetric algorithms for encryption that may be vulnerable to, for example, key search techniques.”) such as when a user chooses to redact content (Nune, ¶26 “with certain content redacted or otherwise unviewable as in PDF 124.”) of content excluded from the first set as the non-confidential content (Id);
designating the second set of content as a user wishing to encrypt part of the content (Nunes, ¶11 “In an example where a PDF includes both confidential and non-confidential content, a user may wish to encrypt only part of the content to minimize the file size of the PDF, and also to reduce the computational demands of assembling or encrypting the PDF file, or decrypting and/or disassembling or reassembling the PDF file. A user may also wish to include security mechanisms which provide for greater security than, for example, password protection alone, or greater than symmetric algorithms for encryption that may be vulnerable to, for example, key search techniques.”) such as when a user chooses to redact content (Nune, ¶26 “with certain content redacted or otherwise unviewable as in PDF 124.”) as non-visible content as redacted or otherwise encrypted confidential content (Nune, ¶26 “As shown in the examples of PDF 122 and 124, a PDF may be output with an of the PDF content visible, as in PDF 122, or with certain content redacted or otherwise unviewable as in PDF 124.”; ¶17 “Unencrypted content may represent non-confidential data, while encrypted content may represent confidential content.”);
generate an enhanced document as assembling a PDF (Nunes, ¶16 “Content provided by content provider 102 may be assembled into a format that is readable across various platforms. For example, content may be assembled into a PDF file that may follow or conform to a particular standard. In some examples, the PDF file may contain content and/or metadata, as well as custom fields or custom properties (hereinafter "custom fields") that may allow for custom values or data to be set or stored within the PDF, and with the PDF remaining readable across various platforms”) from the content as the content (Id) that encodes (Nunes, ¶29 “For example, metadata 204, data blocks 206, and a content map 208 may be signed and stored as a hash. e.g., hash 210. In some examples, the hash may be signed with a user's private key, e.g., private key 212. The resulting signature may then be stored in an assembled PDF, e.g., PDF 240, or in a custom field of the assembled PDF. Various signature techniques or cryptographic hash functions may be used, such as the Secure Hash Algorithm ("SHA"), at varying hash values, e.g., SHA-256. The signature, in some examples, may be encoded. e.g., in BASE64 or another encoding scheme.”) the content in a structured form as the Secure Hash Algorithm storing signatures in the PDF format (Id) according to a defined schema as the BASE 64 encoding scheme (Id), …, and embeds as storing the encryption key for the content in the PDF during assembly (¶17 “In some examples, the content assembled into a PDF file, such as PDF 110, may comprise both unencrypted content and encrypted content. Unencrypted content may represent non-confidential data, while encrypted content may represent confidential content.”; ¶29 “An encryption or assembly engine, such as encryption and assembly engine 106 may fetch and sign various parts of the content. For example, metadata 204, data blocks 206, and a content map 208 may be signed and stored as a hash. e.g., hash 210. In some examples, the hash may be signed with a user's private key, e.g., private key 212. The resulting signature may then be stored in an assembled PDF, e.g., PDF 240, or in a custom field of the assembled PDF.”) the subset of content in non-visible as redacted or otherwise encrypted confidential content (Nune, ¶26 “As shown in the examples of PDF 122 and 124, a PDF may be output with an of the PDF content visible, as in PDF 122, or with certain content redacted or otherwise unviewable as in PDF 124.”; ¶17 “Unencrypted content may represent non-confidential data, while encrypted content may represent confidential content.”) metadata as storing the encrypted content in the custom properties of the PDF (¶16 “In some examples, the PDF file may contain content and/or metadata, as well as custom fields or custom properties (hereinafter "custom fields") that may allow for custom values or data to be set or stored within the PDF, and with the PDF remaining readable across various platforms”) in the enhanced document as the PDF document (Id).
It would have been obvious to one of ordinary skill to which said subject matter pertains at the time the invention was filed to have incorporated the encryption techniques taught by Nune within the enhanced resume generation device taught by Satyaki as it would yield the predictable results of retaining the capability of PDF while increasing security and the ability to store unencrypted content within the single PDF file (Nune, ¶14; ¶11) this would allow users to redact (Nune, ¶26) certain parts of their resume while allowing other parts to remain visible (Nune, ¶26).
Claims 2, 3, 11 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Satyaki in view of Nunes and Austin [2077/0203776].
With regard to claims 2 and 11 the proposed combination further teaches wherein identifying the subset of content comprises:
determining one or more attributes as segments of a resume (Satyaki, Page 4486 Section I. Lexical Analysis: “Considering our case, the resume is discriminated onto various segments including contact information, educational experiences, work experiences and more.”; Please note this claim limitation has been construed in light of Paragraph [0035] of the original specification which recites “a skill, hobby, or other attribute”) associated with a context as in the resume context (Id) for job hiring (Satyaki, Page 4484, Section III History of Hiring: “When the employer posts a job opening, the system ranks the resumes based on keyword matching and shows the most relevant ones to the employer.”);
analyzing the content associated with the initial document given the one or more attributes to determine a first set of content associated with the one or more attributes as parsing the years of word experience, work experiences, educational experiences, certifications, volunteer experiences, ect from the document (Satyaki, Page 4484 Section II. Introduction: “Parsed information include name, email address, social profiles, personal websites, years of work experience, work experiences, years of education, education experiences, publications, certifications, volunteer experiences, keywords and finally the cluster of the resume (ex: computer science, human resource, etc.).”;
[[
designating remaining content as a user wishing to encrypt part of the content (Nunes, ¶11 “In an example where a PDF includes both confidential and non-confidential content, a user may wish to encrypt only part of the content to minimize the file size of the PDF, and also to reduce the computational demands of assembling or encrypting the PDF file, or decrypting and/or disassembling or reassembling the PDF file. A user may also wish to include security mechanisms which provide for greater security than, for example, password protection alone, or greater than symmetric algorithms for encryption that may be vulnerable to, for example, key search techniques.”) such as when a user chooses to redact content (Nune, ¶26 “with certain content redacted or otherwise unviewable as in PDF 124.”) as the non-visible content as redacted or otherwise encrypted confidential content (Nune, ¶26 “As shown in the examples of PDF 122 and 124, a PDF may be output with an of the PDF content visible, as in PDF 122, or with certain content redacted or otherwise unviewable as in PDF 124.”; ¶17 “Unencrypted content may represent non-confidential data, while encrypted content may represent confidential content.”).
Satyaki does not explicitly teach removing the first set of content from the content.
Austin teaches removing the first set of content from the content as providing the candidate the ability to define which sections are to be hidden from the public, such as the Objective, skills, or Experience sections (Austin, ¶61 “Initializing the resume requires the candidate to first define the sections of the resume (i.e. Contact Info, Objective, Skills, Experience, etc.), and then select out the corresponding text of the resume for each of the defined sections with a Graphical User Interface (GUI). The candidate has the ability to choose which of the defined sections are to be hidden from the public. However, the contact information is required to be hidden.”; Please note this claim limitation has been read in light of Paragraph [0034] where the user can remove sections from a resume); and designating remaining content as the user’s contact information (Id) as the non-visible content as the contact information is required to be hidden (Id).
It would have been obvious to one of ordinary skill to which said subject matter pertains at the time the invention was filed to have implemented the proposed combination to enable the user to select specific sections to hid from the public as taught by Austin as it yields the predictable results of increasing security for the user by allowing them control over which sections are available to the public (Austin, ¶13, ¶54, ¶61; ¶69) thereby preventing identity theft (Austin, ¶19).
With regard to claims 3 and 12 the proposed combination further teaches wherein determining the one or more attributes in a job search context as in the resume context (Id) for job hiring (Satyaki, Page 4484, Section III History of Hiring: “When the employer posts a job opening, the system ranks the resumes based on keyword matching and shows the most relevant ones to the employer.”), comprises analyzing a job description as a posted job opening (Satyaki, Page 4484, Section III History of Hiring: “When the employer posts a job opening, the system ranks the resumes based on keyword matching and shows the most relevant ones to the employer.”; Page 4487 Section VI. Expected Outcome: “Then it will rank them using Artificial Intelligence or AI and predict which candidate is best suited for the job, thus making the hiring system authentic. Some screen-shots of the result of our resume parser are portrayed below”) to determine one or more qualifications as keywords (Id) ass