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 .
DETAILED ACTION
Response to Amendment
In the response filed 1/20/2026, the following occurred: Claims 1-18 and 20 are canceled; claim 19 is amended; and claims 21-29 are new.
Claims 19 and 21-29 are pending and have been examined.
Priority
The effective filing date is 11/09/2023.
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 19 and 21-29 are rejected under 35 U.S.C. 103 as being unpatentable over Broverman et al. (US 2004/0249664 A1; “Broverman” herein) in view of Ramanujam (US 2024/0086647 A1).
Re. Claim 19, Broverman teaches a computer-implemented method performed by one or more computing devices for processing and/or creation of clinical trial protocol documentation (Fig. 1, Title, abstract and [0004] teach a system used to perform a computer-assisted methodology for design assistance for clinical trial protocols.), the method comprising:
obtaining data indicating a set of clinical trial documents associated with a clinical trial (abstract teaches a user instantiates protocol elements in a structured clinical trial protocol database and then draws from them in the development of one or more protocol related documents. Alternately, [0087] teaches structured retrieval of content from the document set.);
receiving data indicating a user-specified change to a data field within a first document included in the set of clinical trial documents ([0095] teaches indicating the field or document sections that the user would like to work on next… For all of the entry methods (receiving), whenever the user changes document text or other document features (data indicating a user-specified change) that do not implicate iCP elements, the protocol design tool 110 updates the iCD instance 130 (the first document) with the revisions. [0095] also teaches a document collection.);
determining a key-value pair associated with the data field ([0096] also teaches the updating of the iCD instance 130… whenever the user commits to a change in any iCP elements that are referenced in the iCD instance (determined), which has visible indicators used for identifying the fields in the document that refer to the data in the iCP.), wherein the key-value pair comprises (i) a key specifying a classification for the data field ([0095] teaches the user is presented with a list (key) of iCP elements (key-value pairs) in a chooser pane, organized in topic groups (specifying classification), and from which the user can select elements to browse or insert into the protocol document (for the data fields).), and (ii) a value representing content of the data field as modified by the user-specified change ([0095] teaches whenever the user updates iCP elements (by adding elements, deleting elements or changing element values), the protocol design tool 110 updates an iCP instance 122 with all the revisions.);
extracting, […], unstructured data elements contained within other documents included in the set of clinical trial documents (Fig. 1, [0095] teach whenever the user changes document text or other document features that do not implicate iCP elements, the protocol design tool 110 updates the iCD instance 130 with the revisions… the protocol design tool 110 updates the iCP instance 122 with all the revisions (necessarily extracted) … the iCP instance 122 can at the same time be used to update and ensure consistency across references to protocol elements (the unstructured data elements) within an evolving document or document collection (contained within other documents included in the set).);
executing, […], a pairing algorithm to match the unstructured data elements from the other documents against the key (Fig. 9, [0244] teach, during an editing session, a link (pairing algorithm) is exercised to refresh the document image when the iCP is changed through the system's work panes or to refresh the document image from the iCP when an iCP element is edited from within a region in the document pane 1016… Thus, a bi-directional update path is realized by the Reference element in the context of the system (matching)… While a subject document is not being edited… the protocol references are represented by the text value (the unstructured data elements matched against the key) of their corresponding iCP elements (key-value pairs) at the time of last save. [0095] teaches the iCP instance 122 can at the same time be used to update and ensure consistency across references to protocol elements within an evolving document or document collection (other documents).);
identifying, […], a subset of documents from the other documents based on matching against the key, wherein each document included in the subset of documents contains at least one unstructured data element that matches the key ([0095] teaches, [a]s mentioned, the iCP instance 122 (key-value pairs) can at the same time be used to update (match against the key) and ensure consistency across references to protocol elements (each document containing the unstructured data elements) within an evolving document or document collection (necessitates identifying a subset).); and
propagating the value of the key-value pair to the at least one extracted unstructured data element within each document included in the subset of documents ([0095] teaches, [a]s mentioned, the iCP instance 122 can at the same time be used to update (propagate the value of the key-value pair) and ensure consistency across references to protocol elements within an evolving document or document collection (the extracted unstructured data element(s) referenced in collection documents).)
Broverman does not teach on using a machine learning model.
Ramanujam teaches
using a machine learning model (abstract teaches a system and method for automatically authoring a scientific document using a machine learning model and natural language processing (NLP). See, e.g., Fig. 1 at step 104b; and Fig. 3 and [0042].)
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date to have modified the system and computer-assisted methodologies for design assistance for clinical trial protocols to implement machine learning technology and to use this information as part of an artificial intelligence-enabled system and method for authoring a scientific document of Ramanujam, with the motivation of ensuring data consistency for referenced protocol elements, thereby improving the design and quality of clinical trial protocols and reducing time and cost impacts on clinical trials (see Broverman at para. 0014, 0095 and 0265); and with the motivation of improving clinical trial study results, mappings, and efficiency as well as improving machine learning technology (see Ramanujam at para. 0002, 0027, 0045).
Re. Claim 21, Broverman/Ramanujam teaches the computer-implemented method of claim 19, further comprising:
obtaining an indication of a registration body for the clinical trial (Ramanujam Abstract, Fig. 1, [0026] teaches configuring a CSR template including multiple sections based on / generated in accordance with scientific document requirements (indications obtained), e.g., regulatory authority guidelines.);
obtaining fields that need completing for each document that forms part of the set of clinical trial documents (Ramanujam [0032] teaches automated authoring engine highlights data fields in the automatically generated scientific document (obtained) that require attention and editing from a user as exemplarily illustrated in FIG. lOL.);
auto-populating at least some of the fields of the clinical trial documents with suggested text (Ramanujam [0006] teaches the automated authoring engine matches the sections defined in the scientific document template with target fields using section mapping… and generates the scientific document by rendering the content from the source documents (auto-populating at least some of the fields with suggested text) into the predicted sections of the scientific document template. Ramanujam [0085] teaches the automated authoring engine 909 allows convenient editing and correcting of scientific documents (the clinical trial documentation) and identifies and incorporates missing information therewithin.); and
outputting the set of completed clinical trial documentation (Ramanujam Fig. 3, [0042] teaches generating and outputting the CSR draft with the mapped sections on a user interface and allowing the user to add new sections or sub-sections 311… On receiving the newly added sections or sub-sections, the document generator generates the final CSR 314.) as a machine-readable file (Broverman [0096] teaches saving the current iCD instance on disk. See also Broverman at Abstract, Fig. 48.), in a format based on the indication of the registration body (Ramanujam [0026] teaches the automated authoring engine was configured with the predefined CSR template generated in accordance with the ICH E3 guidelines, which describe the format and content of the CSR (completed clinical trial documentation) that complies with regulatory authorities.)
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date to have modified the artificial intelligence-enabled system and method for authoring a scientific document of Ramanujam to save the final clinical study report or other scientific document on a computer (i.e., as a machine-readable file) and to use this information as part of a system for design assistance for clinical trial protocols as taught by Broverman (see Abstract), with the motivation of improving the design and quality of clinical trial protocols and reducing time and cost impacts on clinical trials (see Broverman at para. 0014 and 0265).
Re. claim 22, Broverman/Ramanujam teaches the computer-implemented method of claim 21, wherein auto-populating at least some of the fields of the set of clinical trial documents (see claim 21 prior art rejection) comprises using a natural language processing model to determine section headers for the fields of the clinical trial documents (Ramanujam Fig. 1, [0039], [0044] teaches automatically extract and pre-process content from the source documents using natural language processing 103 prior to mapping 104… Fig. 5 illustrates a flowchart of an embodiment of the section mapping algorithm (NLP model) executed for mapping the sections configured in the predefined CSR template with content from the multiple source documents... The section extractor 202 of the automated authoring engine (see FIG. 2) receives 501 source documents uploaded by a user and obtains the table of contents (TOC) (section headers) from the uploaded source documents… extracts 502 sections from the TOC of the uploaded source documents... also extracts 503 sections from the TOC of the predefined CSR template (determines section headers)… The section extractor 202 determines the TOC of the predefined CSR template by study type.), and auto-populating at least some of the fields of the set of clinical trial documents based on a corresponding determined section header (Ramanujam [0039]-[0040] teaches the section mapper 206 receives the ICH E3 metadata from the metadata database 204 and the extracted sections from the section repository 205 as inputs, and executes the section mapping algorithm for mapping the sections in the predefined CSR template with the content from the source documents 201 as disclosed in Fig. 5… the section mapper 206 generates a pre-filled CSR based on the section mapping predictions 207.)
Re. Claim 23, Broverman/Ramanujam teaches the computer-implemented method of claim 22, wherein the section headers (see claim 22 prior art rejection) comprise any of: Title Page, […] Objectives/Purpose […] (Ramanujam [0043] teaches the section extractor 202 (see Fig. 2) extracts 402 and passes sections listed in the Table of Contents (TOC) of the protocol document, e.g., “Title”, “Synopsis”. [0073] teaches the “study objectives” section. See also Fig. 10B, 10U showing named sections.)
Broverman/Ramanujam may not explicitly teach the section headers labeled Background Information, Study Design, Selection and Exclusion of Subjects, Treatment of Subjects, Assessment of Efficacy, Assessment of Safety, Adverse Events, Discontinuation of the Study, Statistics, Quality Control and Assurance, Ethics, Data handling and Recordkeeping, Publication Policy, Project Timetable/Flowchart, References, and Supplements/Appendices.
However, the limitation claims section name information/labels that do not result in a manipulative difference between the section name information/labels of the prior art and the functionality of the claimed method (see MPEP §2111.05). The function taught by the prior art would be performed the same regardless of whether the section name information/labels was substituted with nothing. Because at least Ramanujam teaches that data containing section name information/labels is extracted, substituting the section name information/labels of the claimed invention for the section name information/labels of the prior art would be an obvious substitution of one known element for another, producing predictable results. Therefore, it would have been prima facie obvious to one of ordinary skill in the art, before the effective filing date, to have substituted the section name information/labels applied to the extracted data of the prior art with any other section name information/labels because the results would have been predictable.
Re. Claim 24, Broverman/Ramanujam teaches the computer-implemented method of claim 21, wherein auto-populating at least some of the fields of the set of clinical trial documents (see claim 21 prior art rejection) comprises auto-populating at least some of the fields of the clinical trial documents with suggested text based on the registration body (Ramanujam [0006], [0040], [0072] teaches, for each template, generating the prefilled CSR (auto-populating)… matching the sections defined in the template with target fields using section mapping… and generating the scientific document by rendering the content from the source documents (necessarily suggested text) into the predicted sections of each of the scientific document template (based on the registration body)) and based on additional documents uploaded by a user (Ramanujam [0074] teaches allowing a user to upload the source documents (additional documents) and allowing the user to fetch and display, in response to user input, additional information from the source documents for selection and rendering into one or more of the sections in the predefined CSR template.)
Re. Claim 25, Broverman/Ramanujam teaches the computer-implemented method of claim 21, wherein auto-populating at least some of the fields of the set of clinical trial documents (see claim 21 prior art rejection) comprises auto-populating at least some of the fields of the set of clinical trial documents with suggested text (Ramanujam [0006], [0040], [0072] teaches, for each template, generating the prefilled CSR (auto-populating)… matching the sections defined in the template with target fields using section mapping… and generating the scientific document by rendering the content from the source documents (necessarily suggested text) into the predicted sections of each of the scientific document template) based on other fields or documents completed by a user (Broverman [0095] teaches for all of the entry methods, whenever the user changes document text (in some fields) or other document features that do not implicate iCP elements, the protocol design tool 110 updates the iCD instance 130 with the revisions. Whenever the user updates iCP elements (some fields) (by adding elements, deleting elements or changing element values), the protocol design tool 110 updates an iCP instance 122 with all the revisions (auto-populating at least some of the fields in the clinical trial documentation with suggested text). As mentioned, the iCP instance 122 can at the same time be used to update and ensure consistency across references to protocol elements within an evolving document or document collection.)
Re. Claim 26, Broverman/Ramanujam teaches the computer-implemented method of claim 19, further comprising:
obtaining an indication of the registration body for the clinical trial (Ramanujam Abstract, Fig. 1, [0026] teach configuring a CSR template including multiple sections based on / generated in accordance with scientific document requirements (indications obtained), e.g., regulatory authority guidelines (of the registration body).);
based on the obtained indication of the registration body (in step 101), determining which clinical trial documentation is required for that registration body (Ramanujam Fig. 1, [0028] teaches receiving and storing multiple source documents (necessarily determined), e.g., a protocol document, a statistical analysis plan, a case report form (CSF), safety narratives, etc.);
creating template documents for completion by a user based on the determination of which clinical trial documentation is required for that registration body (Ramanujam Fig. 1, [0072] teach rendering the predefined CSR templates based on the scientific document requirements (necessarily determined to configure the CSR template), e.g., the regulatory authority guidelines. Ramanujam Fig. 1 teaches subsequent receipt and storage of multiple source documents.), wherein the template documents comprise a plurality of fields (Broverman [0094]-[0095] teaches an iCD template 120 describing an overall structure of a desired document type, such as a clinical trial protocol document for regulatory approval… the document template 120 is created during a pre-design configuration step and becomes the initial iCD instance 130; and the document comprises document fields or sections.);
suggesting text for inclusion in the template documents based on the registration body and based on text entered by the user in additional documents or other sections of the same document (Ramanujam [0006], [0072] teach, for each template, matching the sections defined in the template with target fields using section mapping… and generates the scientific document by rendering the content from the source documents (necessarily suggested for inclusion in the template documents based on the registration body) into the predicted sections of each of the scientific document template. Ramanujam Figs. 1, 6, [0046] teach matching the sections of the template with sections extracted from the source documents, e.g., text content (based on text entered by the user in additional documents). Additionally, Ramanujam Fig. 1 teaches predict appropriate sections from among the sections in the scientific document template (other sections of the same document) for rendering the content from the source documents.); and
outputting the template documents as completed clinical trial documentation (Broverman at abstract teaches development of one or more protocol related documents (plural). Ramanujam Fig. 3, [0042] teach generating and outputting the CSR draft with the mapped sections on a user interface and allowing the user to add new sections or sub-sections 311… On receiving the newly added sections or sub-sections, the document generator generates the final CSR 314.) as a coded document (Broverman [0040] teaches encoding the clinical trial protocol within a selected meta-model.), in a format based on the indication of the registration body (Ramanujam [0026] teaches the automated authoring engine was configured with the predefined CSR template generated in accordance with the ICH E3 guidelines, which describe the format and content of the CSR (completed clinical trial documentation) that complies with regulatory authorities.)
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date to have modified the artificial intelligence-enabled system and method for authoring a scientific document of Ramanujam to encode the final clinical study report or other scientific document on the computer (i.e., as a coded document) and to use this information as part of a system for design assistance for clinical trial protocols as taught by Broverman (see Abstract), with the motivation of improving the design and quality of clinical trial protocols and reducing time and cost impacts on clinical trials (see Broverman at para. 0014 and 0265).
Re. Claim 27, Broverman/Ramanujam teaches the computer-implemented method of claim 26, wherein suggesting text for inclusion comprises suggesting text based on
(i) the registration body (Ramanujam Fig. 1, [0026], [0039] teaches configuring the template based on scientific document requirements / regulatory authority guidelines / ICH E3 guidelines. Ramanujam [0006], [0072] teaches, for each template (based on a registration body), matching the sections defined in the template with target fields using section mapping… and generates the scientific document by rendering the content from the source documents (necessarily suggested for inclusion) into the predicted sections of each of the scientific document template.) or
(ii) additional documents uploaded by the user (Ramanujam Figs. 1, 6, [0046], [0074] teaches matching the sections of the template with sections extracted from the source documents… and allowing a user to upload the source documents (based on other documents) and allowing the user to fetch and display, in response to user input, additional information from the source documents for selection and rendering into one or more of the sections in the predefined CSR template.)
Re. Claim 28, Broverman/Ramanujam teaches the computer-implemented method of claim 27, wherein suggesting text for inclusion comprises suggesting text (Ramanujam [0006], [0040], [0072] teaches, for each template, generating the prefilled CSR… matching the sections defined in the template with target fields using section mapping… and generating the scientific document by rendering the content from the source documents (necessarily suggesting text based on other documents completed) into the predicted sections of each of the scientific document template) based on other fields or documents completed by the user (Broverman [0095] teaches for all of the entry methods, whenever the user changes document text or other document features that do not implicate iCP elements, the protocol design tool 110 updates the iCD instance 130 with the revisions… Whenever the user updates iCP elements (based on other fields) (by adding elements, deleting elements or changing element values), the protocol design tool 110 updates an iCP instance 122 with all the revisions (necessarily suggesting text for inclusion)… As mentioned, the iCP instance 122 can at the same time be used to update and ensure consistency across references to protocol elements within an evolving document or document collection.)
Re. Claim 29, Broverman/Ramanujam teaches the computer-implemented method of claim 26, wherein suggesting text for inclusion comprises using a natural language processing model to determine section headers for the fields of the template documents (see Broverman [0094]-[0095], iCD instance 130… fields or sections) (Ramanujam Fig. 1, [0039], [0044] teaches automatically extract and pre-process content from the source documents using natural language processing 103 prior to mapping 104… Fig. 5 illustrates a flowchart of an embodiment of the section mapping algorithm (NLP model) executed for mapping the sections configured in the predefined CSR template with content from the multiple source documents... The section extractor 202 of the automated authoring engine (see FIG. 2) receives 501 source documents uploaded by a user and obtains the table of contents (TOC) (section headers) from the uploaded source documents… extracts 502 sections from the TOC of the uploaded source documents... also extracts 503 sections from the TOC of the predefined CSR template (necessarily determines section headers to extract sections).) and providing a suggestion based on the corresponding determined section header (Ramanujam [0039]-[0040] teaches the section mapper 206 receives the ICH E3 metadata from the metadata database 204 and the extracted sections from the section repository 205 as inputs, and executes the section mapping algorithm for mapping the sections in the predefined CSR template with the content from the source documents 201 (providing the suggestions based on the corresponding determined section header) as disclosed in Fig. 5… the section mapper 206 generates a pre-filled CSR based on the section mapping predictions 207.)
Response to Arguments
Rejections under 35 U.S.C. §112(b)
Regarding the rejections of claims 1-18, the Applicant has cancelled the claims to obviate the previous issues of indefiniteness. Regarding the rejection of claim 19, the Applicant has amended the claim to overcome the previous issue(s) of indefiniteness. The amended claim set as considered does not cause any new issues.
Note: 35 U.S.C. §101
Regarding the rejection of Claims 1-20, the Applicant has cancelled claims 1-18 and 20, rendering the rejection of the claims moot.
Regarding the rejection of claim 19, the Applicant has amended the independent claim to recite “obtaining data indicating a set of clinical trial documents associated with a clinical trial; receiving data indicating a user-specified change to a data field within a first document included in the set of clinical trial documents; determining a key-value pair associated with the data field, wherein the key-value pair comprises (i) a key specifying a classification for the data field, and (ii) a value representing content of the data field as modified by the user-specified change; extracting, using a machine learning model, unstructured data elements contained within other documents included in the set of clinical trial documents; executing, using the machine learning model, a pairing algorithm to match the unstructured data elements from the other documents against the key; identifying, using the machine learning model, a subset of documents from the other documents based on matching against the key, wherein each document included in the subset of documents contains at least one unstructured data element that matches the key; and propagating the value of the key-value pair to the at least one extracted unstructured data element within each document included in the subset of documents.”
The claim as a whole provides a practical application under subject eligibility analysis Step 2A Prong 2, since it provides an improvement to another technological field, i.e., a technical solution to a technical problem of clinical trial documentation. MPEP § 2106.05(a). As indicated in the specification: “[0009] Advantageously, this enables clinical trial documentation to be prepared in an efficient and accurate manner. A user may be able to accurately enter relevant information relevant to their clinical trial, and clinical trial documentation may be prepared and output in a manner (e.g., in a structured data format) that can be easily imported by the clinical trial registration body.” See also the specification para. 0063. Therefore, the Examiner has withdrawn the previous 101 rejection. The subject matter eligibility of claim 19 also applies to dependent claims 21-29.
Rejection under 35 U.S.C. §103
Regarding the rejection of Claims 1-20, the Applicant has cancelled claims 1-18 and 20, rendering the rejection of the claims moot.
Regarding the rejection of Claim 19, the Examiner has considered the Applicant’s arguments but does not find them persuasive for at least the following reasons. Applicant argues:
B1. “the portions of the prior art cited in the Office Action do not disclose or suggest at least the feature of "executing, using [a] machine learning model, a pairing algorithm to match the unstructured data elements from the other documents against the key," "identifying, using the machine learning model, a subset of documents from the other documents based on matching against the key" and "propagating the value of the key-value pair to the at least one extracted unstructured data element within each document included in the subset of documents," as now recited in amended claim 19” (Remarks, pg. 8).
Re. argument B1: The Examiner respectfully submits the basis of rejection as necessitated by amendment including the addition of more than one limiting step. Given the BRI, Broverman in view of Ramanujam teaches or renders obvious the recited claim features.
B2. “to the extent that Braverman' s technique is understood to reflect propagation, updates are implemented only when the user "commits to a change in any iCP elements that are referenced in the iCD instance." Braverman at [0096]. This does not correspond to "propagating [a] value of the key-value pair to the at least one extracted unstructured data element within each document included in the subset of documents."” (Remarks, pg. 9).
Re. argument B2: The Examiner respectfully submits that, given the broadest reasonable interpretation, Broverman does teach the final step of the claim because an iCP element can be mapped to the recited “key-value pair” as drafted. Broverman’s iCP instance 122 is understood to include iCP elements (the recited “key-value pairs”) linked to the iCD instance (the recited “first document”) text supplied or entered into the word processor via the document viewer (see at least Fig. 9 and para. 0244). As mentioned, the iCP instance 122 (i.e., its iCP elements) can at the same time be used to update references to the same iCP element by updating the same document text within one or more documents of the document collection (i.e., propagate the value of the key-value pair to the at least one extracted unstructured data element) (see at least Broverman Fig. 1 and para. 0095).
Regarding the rejection of Claims 21-29, the Applicant has not offered any arguments with respect to these claims other than to reiterate the argument(s) present for the claim(s) from which they depend. As such, the rejection of these claims is also respectfully maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Witchey et al. (US 12,462,246 B1) for teaching token-based digital private data exchange systems, methods, and apparatus including records 114 comprising field-value pairs 116 (see Fig. 1 and col. 6, lines 58-60).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 Jessica M Webb whose telephone number is (469)295-9173. The examiner can normally be reached Mon-Fri 9:00am-1:00pm CST.
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, Robert Morgan can be reached on (571) 272-6773. 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.
/J.M.W./Examiner, Art Unit 3683
/CHRISTOPHER L GILLIGAN/Primary Examiner, Art Unit 3683