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
In the response filed on 20 January 2026, the following has occurred: claims 1-3, 5-6, 8-12, 15, 17 and 19-20 have been amended; claim 22 is newly added.
Now claims 1-6, 8-17 and 19-22 are pending.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 20 January 2026 has been entered.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-6, 8-17 and 19-22 are rejected for lack of adequate written description.
Claims 1, 19-20 and their dependent claims are rejected for lack of adequate written description. The claim recites functional steps for which the Applicant has not adequately described the steps in sufficient detail for one of ordinary skill in the art to conclude that the Applicant had possession of the invention.
MPEP 2161.01(I): When examining computer-implemented functional claims, examiners should determine whether the specification discloses the computer and the algorithm (e.g., the necessary steps and/or flowcharts) that perform the claimed function in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor invented the claimed subject matter. [...] If the specification does not provide a disclosure of the computer and algorithm in sufficient detail to demonstrate to one of ordinary skill in the art that the inventor possessed the invention including how to program the disclosed computer to perform the claimed function, a rejection under 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph, for lack of written description must be made. For more information regarding the written description requirement, see MPEP § 2161.01- § 2163.07(b).
Specifically, the claim recites “calculating, by the one or more processors, a quantitative data integrity score” The Applicant has provided no disclosure of how this “quantitative data integrity score” is specifically calculated. Any calculation could potentially read on the as-claimed invention.
The Specification states at:
paragraphs [0059]-[0060], “the test suite for genetic testing referenced above may be run programmatically to evaluate the integrity… the system will evaluate two instances of a patient's abstracted clinical data and compose a score at both the case and field-levels to determine a level of agreement between a plurality of abstractors (or "raters") in order to determine whether to automatically begin the evaluation process… a scoring scheme is used to calculate the proficiency and accuracy of each submission”
paragraph [0145], “Reporting data may include rankings and scores at both the patient record and clinical data attribute / field grain, indicative of data source / stream quality, completeness and integrity”
This is inadequate for a person of ordinary skill in the art at the time of the invention (or filing) to conclude that the Applicant had possession of the claimed “quantitative data integrity score”. No algorithm/formula is present to determine a “quantitative data integrity score”, no recitations of “quantitative data integrity score” are present in the specification, no algorithm/formula for determination of a “quantitative data integrity score” is presented.
The Examiner prospectively notes that this written description rejection is not based on whether one skilled in the art would know how to program a computer to perform any form of a “quantitative data integrity score” (i.e., an enablement rejection), but rather is directed to the Applicant’s lack of specificity as to how the “quantitative data integrity score” is specifically performed with respect to the Applicant’s claimed invention, i.e., would a potential infringer know the metes and bounds of the Applicant’s invention such that they could avoid infringing the Applicant’s claimed invention. In this case, they would not because the Applicant's description of “quantitative data integrity score” claims any and all types of scoring evidencing that the Applicant did not have possession of their invention at the time of filing.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-6, 8-17 and 19-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1 and 19-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite computer-implemented method, system and CRM for performing automated quality assurance testing on data. The limitations of:
Claim 1, which is representative of claims 19 and 20
during creation of clinical information by a user, in real time: [… obtaining …], via one or more electronic data streams, unstructured subject data comprising the clinical information; integrating, […], the unstructured data to generate corresponding structured patient data, by performing [… organization of data …]; wherein performing the [… organization of data …] includes determining a mapping between a plurality of data elements and a plurality of data values within [… rules …] and the unstructured subject data; wherein the plurality of data elements includes one or more clinical or phenotypic data attributes; wherein the plurality of data values includes values extracted from the unstructured subject data corresponding to respective ones of the plurality of data elements; and wherein the [… rules …] includes semantic relationship information describing correspondence of respective ones of the plurality of data elements to respective ones of the plurality of the data values; testing the structured patient data by executing one or more rules to identify one or more errors and to identify one or more instances of incomplete information in the structured subject data, wherein the one or more rules include fully-automated rules, semi-automated rules or user-initiated rules; causing, in real time, […], an indication of the one or more errors or one or more instances of incomplete information to be [… provided to …] a user; [… obtaining …], a revision to the unstructured subject data from the user [….]; generating, […], a definitive clinical record for one or more subjects based on the structured subject data and the revision; calculating, […], a quantitative data integrity score for the definitive clinical record, wherein the quantitative data integrity score is based on a number and a severity of the one or more errors and the revision; and associating the quantitative data integrity score with the definitive clinical record in a data store.
, as drafted, is a method, which under the broadest reasonable interpretation, covers a method of organizing human activity (i.e., managing personal behavior including following rules or instructions) via the recitation of generic computer components. That is, by a human user interacting with one or more processors, a display device, a computing device (Claim 1), one or more processors, one or more memories, a display device, a computing device (Claims 19 and 20), the claimed invention amounts to managing personal behavior or interaction between people, the Examiner notes as stated in 2106.04(a)(2), “certain activity between a person and a computer… may fall within the “certain methods of organizing human activity” grouping”. For example, via at least one or more processors, a display device, a computing device (Claim 1), one or more processors, one or more memories, a display device, a computing device (Claims 19 and 20), the claim encompasses collection of data, analysis of the collected data, formatting of data, testing the format, allowing a human user to interact with and revise any formatting and providing a human user a result of the organized data for the human user to use (i.e., organization of the collected data) for creation of a report for output of a organized result to a human user via human user interaction. If a claim limitation, under its broadest reasonable interpretation, covers managing personal behavior or interactions between people but for the recitation of generic computer components, then it falls within the “method of organizing human activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements of one or more processors, a display device, a computing device (Claim 1), one or more processors, one or more memories, a display device, a computing device (Claims 19 and 20), which implements the abstract idea. The one or more processors, a display device, a computing device (Claim 1), one or more processors, one or more memories, a display device, a computing device (Claims 19 and 20) are recited at a high-level of generality (i.e., a general-purpose computers/ computer component implementing generic computer functions; see Applicant’s specification Figure 2, paragraphs [0009]-[0011]) such that it amounts no more than mere instructions to apply the exception using generic computer components. Accordingly, these additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim recites the additional elements of “receiving…”, “schema mapping and a concept mapping”, “displayed on a display device”. The “receiving…” steps are recited at a high-level of generality (i.e., as a general means of receiving/transmitting data) and amounts to the mere transmission and/or receipt of data, which is a form of extra-solution activity. The “schema mapping and a concept mapping” is recited at a high-level of generality (i.e., as a general means of use of natural language processing) and amounts to merely linking of the abstract idea to particular technological environment. The “displayed on a display device” is recited at a high-level of generality (i.e., as a general displaying data) and amounts to merely linking of the abstract idea to particular technological environment. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of one or more processors, a display device, a computing device (Claim 1), one or more processors, one or more memories, a display device, a computing device (Claims 19 and 20), to perform the noted steps amounts to no more than mere instructions to apply the exception using generic hardware components. Mere instructions to apply an exception using a generic hardware component cannot provide an inventive concept (“significantly more”).
Also as discussed above with respect to integration of the abstract idea into a practical application, the additional elements of “receiving…”, “schema mapping and a concept mapping”, “displayed on a display device” were considered extra-solution activity and/or generally linking to a particular technological environment. The “receiving…” has been re-evaluated under the "significantly more" analysis and determined to amount to be well-understood, routine, and conventional elements/functions. As described in MPEP 2106.0S(d)(II)(i) "Receiving or transmitting data over a network" is well-understood, routine, and conventional. The “schema mapping and a concept mapping” has been re-evaluated under the “significantly more” analysis and determined to amount to be well-understood, routine, and conventional elements/functions. As described in Sadeghi (2014/0278448): see below but at least paragraphs [0016], [0159]; Caffarel (20210118556): paragraphs [0011], [0025]; Reiner (20100145720): paragraph [0095]; mapping data using NLP is well-understood, routine and conventional. The “displayed on a display device” has been re-evaluated under the “significantly more” analysis and determined to amount to be well-understood, routine, and conventional elements/functions. As described in Sadeghi (2014/0278448): see below but at least paragraphs [0022]-[0024], [0074]; Caffarel (20210118556): paragraphs [0052], [0073]; Reiner (20100145720): paragraph [0015], [0065]; a user interface displaying data is well-understood, routine, and conventional. Well-understood, routine, and conventional elements/functions cannot provide “significantly more.” As such the claim is not patent eligible.
Claims 2-6, 9-17 and 21-22 are similarly rejected because either further define the abstract idea and/or do not further limit the claim to a practical application or provide as inventive concept such that the claims are subject matter eligible.
Claims 2-3 further describe use of an accuracy threshold to generate and abstraction, however do not recite any additional elements sufficient to provide a practical application/significantly more.
Claim 4 further describes to format of the data stream, however does not recite any additional elements sufficient to provide a practical application/significantly more.
Claim 5 further describes the unstructured data, however does not recite any additional elements sufficient to provide a practical application/significantly more.
Claims 6-8 further define the schema and concept mapping, however this was already considered above and is incorporated herein
Claims 9 and 10 further describe making determinations for a clinical trial, however do not recite any additional elements sufficient to provide a practical application/significantly more.
Claims 11 and 12 describes use of an algorithm or procedure, however do not recite any additional elements sufficient to provide a practical application/significantly more.
Claim 13 further describes the data quality test, however do not recite any additional elements sufficient to provide a practical application/significantly more.
Claims 14-16 further describe a triggering event to begin the method, however do not recite any additional elements sufficient to provide a practical application/significantly more.
Claims 17 and 21 recite the additional element of “training… one or more machine learning models” and “a learning process”, however the “training… one or more machine learning models” is recited at a high-level of generality (i.e., as a general means of building a model) and amounts to generally linking the abstract idea to a particular technological environment. The “a learning process” is recited at a high-level of generality (i.e., as a general means of building a model) and amounts to generally linking the abstract idea to a particular technological environment. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application. The claim is directed to an abstract idea.
Also, as discussed above with respect to integration of the abstract idea into a practical application, the additional elements of “training… one or more machine learning models” and “a learning process” were considered generally linking of the abstract idea to a particular technological environment. The “training… one or more machine learning models” has been re-evaluated under the “significantly more” analysis and determined to amount to be well-understood, routine, and conventional elements/functions. As described in Sadeghi (2014/0278448): see below but at least paragraph [0048], [0197]; Ghosh (20190287675): paragraph [0039]; Rankin (2014/0223284): paragraph [0004]; training algorithms using machine learning is well-understood, routine and conventional. The “a learning process” has been re-evaluated under the “significantly more” analysis and determined to amount to be well-understood, routine, and conventional elements/functions. As described in Sadeghi (2014/0278448): see below but at least paragraph [0048], [0197]; Ghosh (20190287675): paragraph [0039]; Rankin (2014/0223284): paragraph [0004]; using machine learning to learn data is well-understood, routine and conventional. Well-understood, routine, and conventional elements/functions cannot provide “significantly more.” As such the claim is not patent eligible.
Claim 22 recites the additional elements of “maintaining… recording…”, however this is recited at a high-level of generality (i.e., as a general means of storing data) and amounts to the mere storage of data, which is a form of extra-solution activity. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application. The claim is directed to an abstract idea.
Also, as discussed above with respect to integration of the abstract idea into a practical application, the additional elements of “maintaining… recording…” were considered generally linking the abstract idea to particular technological environment. This has been re-evaluated under the “significantly more” analysis and determined to amount to be well-understood, routine, and conventional elements/functions. As described in MPEP 2106.05(d)(II)(iv) “Storing and retrieving information in memory” is well-understood, routine, and conventional. Well-understood, routine, and conventional elements/functions cannot provide “significantly more.” As such the claim is not patent eligible.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-2, 5-6, 8-17 and 19-21 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Pub. No. 2014/0278448 (hereafter “Sadeghi”; already of record in the IDS), in view of U.S. Patent Pub. No. 2015/0051922 (hereafter “Rentas”), in view of U.S. Patent Pub. No. 2017/0185720 (hereafter “Downs”; already of record in the IDS), in further view of U.S. Patent Pub. No. 2005/0182657 (hereafter “Abraham-Fuchs”).
Regarding (Currently Amended) claim 1, Sadeghi teaches a computer-implemented method of real-time structuring and validation of unstructured clinical data during electronic medical record (EMR) generation (Sadeghi: paragraph [0010], “method is provided, comprising using at least one processor to analyze a medical report to determine whether the medical report includes at least one instance of at least one category selected from a group consisting of: gender error, laterality error, and critical finding”, paragraphs [0127]-[0128], “an EHR is maintained as a structured data representation”, paragraph [0131], “enhancing the creation and use of structured electronic medical records”. Also see, paragraphs [0065]-[0066] and [0080]), the method comprising:
during creation of clinical information by a user, in real time (Sadeghi: paragraph [0002], “directed generally to the field of medical documentation, and more particularly to techniques for creating and processing patient records in medical settings”, paragraphs [0065]-[0066], “the QA tool A105 may operate in real time. For example, in some embodiments, the QA tool A105 may check a medical report as soon as the report text becomes available and/or before the author "signs" the report”, paragraph [0080], “the radiologist may still have the relevant images on his screen and be able to review one or more images when correcting an error in the report. These are merely examples, as the user may edit the report in any suitable way. In these examples, the alerts are generated in real time, which facilitates efficient correction by the user”):
receiving, via one or more electronic data streams, unstructured subject data comprising the clinical information (Sadeghi: Figure 6, paragraphs [0031]-[0033], “medical professionals may prefer to enter medical data by providing a free-form note”, paragraph [0056], “the system A100 includes multiple computers configured to communicate with each other via one or more networks”, paragraph [0131], “enable a clinician to provide input and observations via a free-form narrative clinician's note”, paragraph [0164], “provide a free-form narration of the patient encounter”. Also see, paragraph [0165]);
integrating, via, one or more processors, the unstructured data to generate corresponding structured subject data, by performing a schema mapping and a concept mapping (Sadeghi: Figure 6, paragraphs [0062]-[0064], “the QA tool A105 may invoke a NLU engine to process the medical reports to be quality assured… a lexicon of medical terms, an ontology linked to medical terms, a medical knowledge representation model, a statistical entity detection model trained using hand-annotated medical documents, and/or a statistical relation model similarly trained. Such an NLU engine is sometimes referred to herein as a clinical language understanding (CLU) engine”, paragraph [0068], “the controller A165 may extract certain data from the report, such as the text to be checked and/or any desired combination of metadata that may be used to inform the CLU engine's analysis”, paragraph [0100], “an ontology may indicate that the two terms "total hip antroplasty" and "THA" refer to the same concept in the ontology”, paragraph [0115], “the CLU engine output is a structured document (e.g., in a CDA format)”, paragraphs [0131]-[0133], “extraction of discrete medical facts (e.g., clinical facts), such as could be stored as discrete structured data items in an electronic medical record, from a clinician's free-form narration of a patient encounter… the words and/or concepts represented in the clinician's free-form narration may be represented and/or stored as data… one or more medical facts (e.g., clinical facts) may be automatically extracted from the free-form narration”, paragraph [0237], “one or more of the facts in the set collected (either by fact extraction from a text narrative or by direct entry as one or more discrete structured data items) from the patent encounter may correspond to one or more standard codes used for billing, ordering, evaluating quality of care, or the like… Examples of such standard coding systems include, but are not limited to, ICD codes”);
wherein performing the schema mapping includes determining a mapping between a plurality of data elements and a plurality of data values within a data schema and the unstructured subject data (Sadeghi: paragraph [0127], “Each piece of information stored in such an EHR is typically represented as a discrete (e.g., separate) data item occupying a field of the EHR database… Data items or fields in such an EHR are structured in the sense that only a certain limited set of valid inputs is allowed for each field”, paragraph [0175], “concepts in a formal ontology used by a fact extraction component may be linked to a lexicon of medical terms and/or codes, such that each medical term and each code is linked to at least one concept in the formal ontology”, paragraph [0186], “a fact extraction component may make use of one or more statistical models to extract semantic entities from natural language input… apply hard-coded deterministic rules to map from inputs having particular characteristics to particular outputs”. Also see, paragraph [0217]-[0226]);
wherein the plurality of data elements includes one or more clinical or […] data attributes (Sadeghi: paragraphs [0174]-[0175], “a fact extraction component may make use of a formal ontology linked to a lexicon of clinical terms… a formal ontology used by a fact extraction component may be linked to a lexicon of medical terms and/or codes, such that each medical term and each code is linked to at least one concept in the formal ontology. In some embodiments, the lexicon may include the standard medical terms and/or codes used by the institution in which the fact extraction component is applied. For example, the standard medical terms and/or codes used by an EHR maintained by the institution may be included in the lexicon linked to the fact extraction component's formal ontology”);
wherein the plurality of data values includes values extracted from the unstructured subject data corresponding to respective ones of the plurality of data elements (Sadeghi: paragraph [0127], “Each piece of information stored in such an EHR is typically represented as a discrete (e.g., separate) data item occupying a field of the EHR database. For example, a 55-year old male patient named John Doe may have an EHR database record with "John Doe" stored in the patient_name field, "55" stored in the patient_age field, and "Male" stored in the patient_gender field. Data items or fields in such an EHR are structured in the sense that only a certain limited set of valid inputs is allowed for each field”, paragraph [0186], “a fact extraction component may make use of one or more statistical models to extract semantic entities from natural language input… apply hard-coded deterministic rules to map from inputs having particular characteristics to particular outputs”. Also see, paragraph [0217]-[0226]); and
wherein the data schema includes semantic relationship information describing correspondence of respective ones of the plurality of data elements to respective ones of the plurality of the data values (Sadeghi: paragraphs [0136], “a linkage may be maintained between each extracted clinical fact and the portion of the free-form narration from which that fact was extracted”, paragraph [0176], “any other type(s) of relationship useful to the process of medical documentation may also be represented in the formal ontology… Other types of relationships may include complication relationships, comorbidity relationships, interaction relationships (e.g., among medications), and many others. Any number and type(s) of concept relationships may be included in such a formal ontology”. Also see, paragraph [0217]-[0226]);
testing the structured subject data by executing one or more rules to identify one or more errors [… or …] to identify one or more instances of incomplete information in the structured subject data (Sadeghi: paragraph [0056], “a quality assurance (QA) tool for use in processing medical reports”, paragraph [0064], “the QA tool A105 uses a CLU engine A145 to identify errors and/or critical results in medical reports”, paragraphs [0084]-[0085], “quality assurance checks may be automatically performed as part of a medical report generation workflow”, paragraph [0069], “the resolver A170 may apply one or more rules to the CLU engine output to determine whether the CLU engine output includes any errors and/or critical results of interest. For example, a rule may search the CLU engine output for an extracted fact of "laterality mismatch" type, "gender mismatch" type, "critical result" type, etc. The rules may take any form and may depend on the format of the CLU engine output”, paragraph [0112], “one or more medical reports (or one or more portions thereof) to be quality assured may be submitted to a CLU engine for processing. The CLU engine may be built and/or adapted to identify errors (e.g., laterality and/or gender errors) and/or critical results”, paragraph [0123], “the CLU engine may output any identified errors and/or critical results”),
wherein the one or more rules include fully-automated rules, semi-automated rules or user-initiated rules (Sadeghi: paragraph [0069], “the resolver A170 may apply one or more rules to the CLU engine output to determine whether the CLU engine output includes any errors and/or critical results of interest. For example, a rule may search the CLU engine output for an extracted fact of "laterality mismatch" type, "gender mismatch" type, "critical result" type, etc. The rules may take any form and may depend on the format of the CLU engine output.”, paragraph [0114], “analyzing the output of the CLU engine may include applying one or more rules that perform functions in addition to parsing the CLU engine output. For example, there may be a set of one or more rules for each type of alert (e.g., laterality error, gender error, or critical result) that the system is capable of generating. The rule sets may be selectively enabled or disabled, so that a user may configure the system to detect different types of errors and/or critical results”, paragraph [0236], “fact review component may be programmed with a set of deterministic rules to decide when such a potential opportunity exists”. The Examiner notes these read on at least user-initiated);
causing, in real time, via one or more processors, an indication of the one or more errors or the one or more instances of incomplete information to be displayed on a display device accessible by the user (Sadeghi: Figures 6-7, paragraph [0049], “provide alerts to medical professionals when errors and/or critical results are identified in medical reports… a user reviewing a medical report (e.g., a radiologist reviewing a report that he just dictated or is in the process of dictating) may be presented with one or more alerts. In some embodiments, the alerts may be organized according to their types (e.g., laterality errors, gender errors”, paragraph [0076], “display of the QA pane A205 and the Report pane A210 may allow a user to determine efficiently whether the system has correctly identified an error or critical result”, paragraph [0080], “In these examples, the alerts are generated in real time, which facilitates efficient correction by the user”, paragraph [0117], “Returning to FIG. 6, one or more alerts triggered at act A615 may be provided to a user interface component (e.g., the illustrative QA user interface A125 shown in FIG. 1) at act A620 to be displayed to the user”);
receiving, via one or more processors, a revision to the unstructured subject data from the user via a computing device accessible to the user (Sadeghi: Figures 16, paragraph [0054], “in an embodiment in which a statistical model is used to generate alerts, a user's feedback (e.g., acceptance or rejection of an alert) may be used as additional training data to adapt the statistical model”, paragraph [0146], “when the user makes a selection of a fact presented through a structured choice provided by the fact review system, the set of facts extracted by the fact extraction component may be updated accordingly… in other cases, a textual representation of the clinician's freeform narration may automatically be updated ( e.g., changed) to explicitly identify the user's selected fact as having been ascertained from the patient encounter”);
generating, via one or more processors, a definitive clinical record for one or more subjects based on the structured subject data and the revision (Sadeghi: Figure 16, paragraph [0008], “Electronic medical records can also be shared, accessed, and updated by multiple different persons locally and from remote locations through suitable user interfaces and network connections”, paragraph [0053], “the user may in some instances be required to resolve certain ones or all of the alerts. For example, a radiologist creating a report may be required to resolve, or at least acknowledge, every alert before he is able to "sign off" on the report”, paragraph [0065], “As used herein, "signing" is an act performed by an author of a report (e.g., a clinician or lab technician) to indicate the report is ready to be made part of a patient's medical record… may or may not include the author attaching an electronic signature to the report”, paragraph [0146], “when the user makes a selection of a fact presented through a structured choice provided by the fact review system, the set of facts extracted by the fact extraction component may be updated accordingly… in other cases, a textual representation of the clinician's freeform narration may automatically be updated ( e.g., changed) to explicitly identify the user's selected fact as having been ascertained from the patient encounter”. Also see, paragraph [0231]. The Examiner notes signing a note reads on preparing a definitive record under the broadest reasonable interpretation);
calculating, by the one or more processors, a […] score for the definitive clinical record, wherein the […] score is based on a number […] of the one or more errors and the revision; and associating the […] score with the definitive clinical record in a data store (Sadeghi: paragraph [0054], “in an embodiment in which a statistical model is used to generate alerts, a user's feedback (e.g., acceptance or rejection of an alert) may be used as additional training data to adapt the statistical model”, paragraph [0061], “reports ready to be included in patient medical records”, paragraph [0075], “the total number of critical results identified… the total number of gender errors identified”, paragraph [0085], “identifies the types of alerts generated and the number of alerts for each such type”, paragraph [0145], “the statistical model may be used to score the alternative hypotheses based on probability, confidence, or any other suitable measure of an estimated likelihood”).
Sadeghi may not explicitly teach (underlined below for clarity):
testing the structured patient data by executing one or more rules to identify one or more errors and to identify one or more instances of incomplete information in the structured patient data,
Rentas teaches testing the structured patient data by executing one or more rules to identify one or more errors and to identify one or more instances of incomplete information in the structured patient data (Rentas: paragraph [0029], “to identify additional required data missing from the patient test data according to electronic health record provider requirements”, paragraph [0105], “application server 62 then identifies fields in the patient test data that are missing for the test type (step S54)”);
One of ordinary skill in the art before the effective filing date would have found it obvious to include using a quality test to identify one or more instances of missing data as taught by Rentas within the determination of errors using quality tests as taught by Sadeghi with the motivation of “increases the likelihood that the patient, physician, and care team will receive the results quicker, which allows for immediate clinical management decisions to be made” (Rentas: paragraphs [0002]-[0005]).
Sadeghi and Rentas may not explicitly teach (underlined below for clarity):
wherein the plurality of data elements includes one or more clinical or phenotypic data attributes;
calculating, by the one or more processors, a quantitative data integrity score for the definitive clinical record, wherein the quantitative data integrity score is based on a number […] of the one or more errors and the revision; and associating the quantitative data integrity score with the definitive clinical record in a data store.
Downs teaches wherein the plurality of data elements includes one or more clinical or phenotypic data attributes (Downs: Figure 9, paragraph [0165], “a system for curation and analysis of genetic variants. A requestor 701 submits a curation request through a curation request application portal 706 to a variant curation interpreter 711, as illustrated by arrow 723. As part of the request, the requestor 701 provides access to a sample's genetic information and phenotype”);
calculating, by the one or more processors, a quantitative data integrity score for the definitive clinical record, wherein the quantitative data integrity score is based on a number […] of the one or more errors and the revision; and associating the quantitative data integrity score with the definitive clinical record in a data store (Downs: paragraph [0018], “a data quality score… a credibility score”, paragraph [0060], “A “data quality score” is a quantitative value based on an objective level of confidence in information submitted”, paragraph [0102], “The scores can be based on data such as the number”. Also see, paragraph [0134]).
One of ordinary skill in the art before the effective filing date would have found it obvious to include using a sufficiency score to test unstructured data comprising phenotype data as taught by Downs within the quality assurance testing of structured data as taught by Sadeghi and Rentas with the motivation of “providing an increase in the data available to clinical laboratories and genetic test developers” (Downs: paragraphs [0002]-[0005]).
Sadeghi, Rentas and Downs may not explicitly teach (underlined below for clarity):
calculating, by the one or more processors, a quantitative data integrity score for the definitive clinical record, wherein the quantitative data integrity score is based on a number and a severity of the one or more errors and the revision; and associating the quantitative data integrity score with the definitive clinical record in a data store.
Abraham-Fuchs teaches calculating, by the one or more processors, a quantitative data integrity score for the definitive clinical record, wherein the quantitative data integrity score is based on a number and a severity of the one or more errors and the revision; and associating the quantitative data integrity score with the definitive clinical record in a data store (Abraham-Fuchs: paragraph [0085], “a quality and/or compliance score may be calculated”, paragraph [0116], “Number and severity of deviations from these rules may then automatically calculated from the entries… For each rule, a compliance measure may then be calculated from the sum of all deviations from this rule for example. Alternatively, or optionally, for all rules together a combined measure is calculated to quantify the overall quality”).
One of ordinary skill in the art before the effective filing date would have found it obvious to include using a severity and number of deviations for determining a quality score as taught by Abraham-Fuchs within the quality control of structured data using an integrity score as taught by Sadeghi, Rentas and Downs with the motivation of “improve the clinical study or clinical study process” (Abraham-Fuchs: paragraph [0009]).
Regarding (Currently Amended) claim 2, Sadeghi, Rentas, Downs and Abraham-Fuchs teaches the limitations of claim 1, and further teaches repeating steps the testing, the causing, and the receiving the revision until one or more of the structured subject data satisfies a threshold for accuracy (Sadeghi: paragraph [0048], “capture the likelihoods of various patterns… determine the likelihood that one or more given portions of text in a particular medical report represents an error or critical result”, paragraph [0053], “the user may in some instances be required to resolve certain ones or all of the alerts”, paragraph [0080], “the Database 1 (database 111) can continuously be updated to accurately reflect or indicate which structured quality indicators have previously been approved or accepted by users”, paragraph [0096], “If that observed likelihood is sufficiently high (e.g., above a selected threshold)”, paragraph [0122], “A threshold confidence level may be set so that a candidate is flagged as an error or critical result if it is associated with a confidence value above the threshold level”. The process is repeated for all determined errors that satisfy a threshold accuracy and teaches what is required of the claim under the broadest reasonable interpretation).
The motivation to combine is the same as in claim 1, incorporated herein.
Regarding (Currently Amended) claim 5, Sadeghi, Rentas, Downs and Abraham-Fuchs teaches the limitations of claim 1, and further teaches wherein the unstructured subject data includes at least one of: (i) subject demographics data, (ii) diagnosis data, (iii) treatments data, (iv) outcomes data, (v) genetic testing data, (vi) labs data, or (vii) other subject data (Sadeghi: paragraphs [0005]-[0006], “a note could include, for example, a description of the reason(s) for the patient encounter, an account of any vital signs, test results, and/or other clinical data collected during the encounter, one or more diagnoses determined by the clinician from the encounter, and/or a description of a plan for further treatment… impressions may include, for example, the radiologist's interpretations of one or more medical images (e.g., one or more diagnoses) and/or notes for possible follow-up tests, procedures, and/or treatments”).
The motivation to combine is the same as in claim 1, incorporated herein.
Regarding (Currently Amended) claim 6, Sadeghi, Rentas, Downs and Abraham-Fuchs teaches the limitations of claim 1, and further teaches processing the unstructured subject data using natural language processing to identify medical ontological terms within the unstructured patient data (Sadeghi: paragraphs [0062], “the QA tool A105 may invoke a NLU engine to process the medical reports to be quality assured. The NLU engine may be built and/or tuned using information specific to the medical field. Non-limiting examples of such information include a lexicon of medical terms, an ontology linked to medical terms, a medical knowledge representation model… Such an NLU engine is sometimes referred to herein as a clinical language understanding (CLU) engine”, paragraph [0100], “an ontology linked to medical terms may be used by a CLU engine in some embodiments and may facilitate identifying errors and/or critical results in a medical report. For instance, with respect to the example shown in FIG. 5, an ontology may indicate that the two terms "total hip antroplasty" and "THA" refer to the same concept in the ontology”).
The motivation to combine is the same as in claim 1, incorporated herein.
Regarding (Currently Amended) claim 8, Sadeghi, Rentas, Downs and Abraham-Fuchs teaches the limitations of claim 1, and further teaches wherein performing the concept mapping includes determining a mapping between a data model and one or more medical concepts included in the unstructured subject data, by identifying and processing one or more source data fields and attributes in the unstructured subject data (Sadeghi: paragraph [0127], “Each piece of information stored in such an EHR is typically represented as a discrete (e.g., separate) data item occupying a field of the EHR database… Data items or fields in such an EHR are structured in the sense that only a certain limited set of valid inputs is allowed for each field”, paragraph [0175], “concepts in a formal ontology used by a fact extraction component may be linked to a lexicon of medical terms and/or codes, such that each medical term and each code is linked to at least one concept in the formal ontology”, paragraph [0186], “a fact extraction component may make use of one or more statistical models to extract semantic entities from natural language input… apply hard-coded deterministic rules to map from inputs having particular characteristics to particular outputs”. Also see, paragraph [0217]-[0226]).
The motivation to combine is the same as in claim 1, incorporated herein.
Regarding (Currently Amended) claim 9, Sadeghi, Rentas, Downs and Abraham-Fuchs teaches the limitations of claim 1, and further teaches processing, via one or more processors, at least a portion of the structured subject data to identify one or more clinical attributes (Sadeghi: paragraph [0011], “determine whether the one or more portions of text comprise at least one instance of at least one category selected from the group”, paragraph [0241], “alert the user when it is determined that an unspecified diagnosis may possibly be ascertained from the patient encounter”, paragraph [0252], “a method 1200 for identifying unspecified diagnoses in clinical documentation”); and
determining, based on the one or more clinical attributes, whether to include at least one subject corresponding to at least the portion of the structured subject data in a clinical trial (Abraham-Fuchs: paragraph [0006], “assist in recruiting patients for the study, as well as selecting an appropriate investigator/investigators and appropriate clinical trial site(s)”, paragraph [0009], “automated, supervision of compliance with quality criteria and/or a need for a systematic and preferably automated way to check quality compliance of a clinical study”, paragraphs [0039]-[0040], “Patient inclusion criteria ... Patient exclusion criteria”, paragraph [0065], “measures of quality and/or compliance with various protocol rules of the clinical study criteria”).
The motivation to combine is the same as in claim 1, incorporated herein.
Regarding (Currently Amended) claim 10, Sadeghi, Rentas, Downs and Abraham-Fuchs teaches the limitations of claim 9, and further teaches determining whether to include the at least the one subject corresponding to at least the portion of the structured subject data in the clinical trial further based on at least one data quality test (Abraham-Fuchs: paragraph [0006], “assist in recruiting patients for the study, as well as selecting an appropriate investigator/investigators and appropriate clinical trial site(s)”, paragraph [0009], “automated, supervision of compliance with quality criteria and/or a need for a systematic and preferably automated way to check quality compliance of a clinical study”, paragraphs [0039]-[0040], “Patient inclusion criteria ... Patient exclusion criteria”, paragraph [0065], “measures of quality and/or compliance with various protocol rules of the clinical study criteria”).
The motivation to combine is the same as in claim 1, incorporated herein.
Regarding (Currently Amended) claim 11, Sadeghi, Rentas, Downs and Abraham-Fuchs teaches the limitations of claim 1, and further teaches wherein testing the structured subject data includes processing the structured subject data using (i) a recursive algorithm (ii) an iterative algorithm or (iii) a conflict resolution procedure (Sadeghi: paragraph [0069], “the CLU client A155 may forward output received from the CLU engine A145 to a resolver component A170 of the QA Tool A105 for further processing. The resolver A170 may be programmed to parse the output of the CLU engine A145, which may be in any suitable format (e.g., an XML format such as a Clinical Document Architecture (CDA) format), and identify any errors and/or critical results of interest to the resolver A170. In one embodiment, the resolver A170 may apply one or more rules to the CLU engine output to determine whether the CLU engine output includes any errors and/or critical results of interest”, paragraph [0141], “an alert to a conflict may be triggered by a combination of facts”, paragraph [0162], “Each of these processing components of system 100 may be implemented in software”).
The motivation to combine is the same as in claim 1, incorporated herein.
Regarding (Currently Amended) claim 12, Sadeghi, Rentas, Downs and Abraham-Fuchs teaches the limitations of claim 11, and further teaches generating an indication of support of at least one data quality test based on processing the structured subject data using the recursive algorithm (Sadeghi: paragraphs [0122]-[0124], “a confidence value may be computed for a candidate of an error or critical result and may be indicative of how similar this particular candidate is to one or more patterns in the training data that were hand-annotated as errors and/or critical results… confidence information may be provided with an identified error or critical result, such as a confidence score”); or
generating a modification of the at least one data quality test based on processing the structured subject data using the recursive algorithm (Sadeghi: paragraph [0054], “a user's feedback (e.g., acceptance or rejection of an alert) may be used as additional training data to adapt the statistical model. Thus, adaptation may be performed continually as the system is being used” paragraphs [0146]-[0148], “a fact review system may allow a clinician or other user to directly add a clinical fact… when such a fact is added, the fact extraction component may be updated for that user… to re-train a statistical fact extraction model to associate the selected word(s) with the added fact… fact review system may allow a user to add, delete and/or modify (collectively referred to as "change") a medical fact extracted”).
The motivation to combine is the same as in claim 1, incorporated herein.
Regarding (Previously Presented) claim 13, Sadeghi, Rentas, Downs and Abraham-Fuchs teaches the limitations of claim 10, and further teach wherein the at least one data quality test is a genetic testing test including molecular variant criteria, and wherein the computer implemented method further comprises: identifying a gene and a type of molecular variant of the gene (Downs: paragraph [0017], “calculate a variant score for information in the genetic information database”, paragraph [0048], “Biomarkers expressly include genomic information as indicated by a sequence or presence of certain nucleotide bases in a DNA molecule”, paragraph [0134], “a variant score can be based on factors such as data quality… The data quality score can be based on an objective level of confidence… The ClinVar database utilizes a metric to assess a level of confidence in information submitted… the criteria required to assign a variant to each category”. The Examiner notes this includes molecular variant criteria for identifying a confidence of a gene and variant of the gene, which teaches what is required of the claim limitation under the broadest reasonable interpretation).
The motivation to combine is the same as in claim 1, incorporated herein.
Regarding (Previously Presented) claim 14, Sadeghi, Rentas, Downs and Abraham-Fuchs teaches the limitations of claim 1, and further teaches wherein the computer implemented method is performed in response to detecting at least one trigger event (Sadeghi: Figures 1, 6, paragraphs [0110]-[0111 ], “an indication may be received from a user… an explicit request to initiate quality assurance checking on one or more medical reports… any other type of indication that may trigger a quality assurance check”. Also see, paragraphs [0056]-[0060], [0127]-[0131], [0138]).
The motivation to combine is the same as in claim 1, incorporated herein.
Regarding (Currently Amended) claim 15, Sadeghi, Rentas, Downs and Abraham-Fuchs teaches the limitations of claim 14, and further teaches wherein detecting the at least the one trigger event includes: (i) detecting, via one or more processors, an on-demand request; (ii) detecting, via one or more processors, a new software code commit; (iii) detecting, via one or more processors, an application build phase; (iv) detecting, via one or more processors, receipt of new data; (vi) detecting, via one or more processors, ingesting of data across a source or a stream; (vii) detecting, via one or more processors, a sufficient inter-rater or intra-rater reliability scoring system; (viii) detecting, via one or more processors, a completion of a case abstraction and/or a quality assurance activity; (ix) detecting, via one or more processors, a bulk initiation of evaluation of multiple structured subject records once all have been completed; or (x) detecting, via one or more processors, a real-time analysis during creation of a subject note or other subject data (Sadeghi: Figures 1, 6, paragraphs [0065]-[0066], “the QA tool Al OS may operate in real time… the QA tool Al OS may process medical reports offline (e.g., in batches).”, paragraphs [0110]-[0111 ], “an indication may be received from a user… an explicit request to initiate quality assurance checking on one or more medical reports… any other type of indication that may trigger a quality assurance check”, paragraphs [0146]-[0148], “a fact review system may allow a clinician or other user to directly add a clinical fact… when such a fact is added, the fact extraction component may be updated for that user… to re-train a statistical fact extraction model to associate the selected word(s) with the added fact… fact review system may allow a user to add, delete and/or modify (collectively referred to as "change") a medical fact extracted”. Also see, paragraphs [0056]-[0060], [0127]-[0131], [0138]).
The motivation to combine is the same as in claim 1, incorporated herein.
Regarding (Original) claim 16, Sadeghi, Rentas, Downs and Abraham-Fuchs teaches the limitations of claim 14, and further teaches appending the at least the one trigger event to a continuously growing set of stream-specific validations, warnings and errors monitored by administrators (Sadeghi: paragraph [0142], “an alert may be provided when a set of one or more clinical facts is collected from a patient encounter, and it is determined that there is an opportunity to add to the clinical documentation of the patient encounter for quality review purposes”, paragraphs [0146]-[0148], “a fact review system may allow a clinician or other user to directly add a clinical fact… when such a fact is added, the fact extraction component may be updated for that user… to re-train a statistical fact extraction model to associate the selected word(s) with the added fact… fact review system may allow a user to add, delete and/or modify (collectively referred to as "change") a medical fact extracted”, paragraph [0156], “append a note to the freeform narration, indicating and optionally explaining the inconsistency”. The Examiner notes the alerts (i.e., validation warning/errors) are appended and teaches what is required under the broadest reasonable interpretation).
The motivation to combine is the same as in claim 1, incorporated herein.
Regarding (Currently Amended) claim 17, Sadeghi, Rentas, Downs and Abraham-Fuchs teaches the limitations of claim 1, and further teaches training, via one or more processors, one or more machine learning models based on the structured subject data (Sadeghi: paragraph [0048], “one or more statistical models may be trained using a corpus of medical reports”, paragraph [0197], “the statistical model may learn probabilistic relationships between the features and the entity labels. When later presented with an input text without manual entity labels, the statistical model may then apply the same feature extraction techniques to extract features from the input text, and may apply the learned probabilistic relationships to automatically determine the most likely entity labels for word sequences in the input text. Any suitable statistical modeling technique may be used to learn such probabilistic relationships, as aspects of the present disclosure are not limited in this respect. Non-limiting examples of suitable known statistical modeling techniques include machine learning techniques such as maximum entropy modeling, support vector machines, and conditional random fields, among others”).
The motivation to combine is the same as in claim 1, incorporated herein.
REGARDING CLAIM(S) 19 AND 20
Claim(s) 19 and 20 is/are analogous to Claim(s) 1, thus Claim(s) 19 and 20 is/are similarly analyzed and rejected in a manner consistent with the rejection of Claim(s) 1.
Regarding (Previously Presented) claim 21, Sadeghi, Rentas, Downs and Abraham-Fuchs teaches the limitations of claim 1, and further teaches adjusting the schema mapping and the concept mapping based on a learning process that incorporates user feedback and revisions to improve accuracy over time (Sadeghi: paragraph [0054], “a statistical model is used to generate alerts, a user's feedback (e.g., acceptance or rejection of an alert) may be used as additional training data to adapt the statistical model. Thus, adaptation may be performed continually as the system is being used”, paragraph [0062], “The NLU engine may be built and/or tuned”, paragraphs [0143]-[0147], “link the selected word(s) from the free-form narration to one or more concepts in a formal ontology corresponding to the added fact, or to re-train a statistical fact extraction model to associate the selected word(s) with the added fact”, paragraph [0155], “fact extraction models used by the fact extraction component may be re-trained such that the correction applied to the first text may be reflected in the manner of processing later texts”, paragraph [0172], “models in some embodiments may be trained through feedback from clinician 120 or another user”).
The motivation to combine is the same as in claim 1, incorporated herein.
Response to Arguments
Applicant's arguments filed 20 January 2026 have been fully considered but they are not persuasive. Applicants’ arguments will be addressed herein below in the order in which they appear in the response filed on 20 January 2026.
Rejections under 35 U.S.C. § 101
Regarding the rejection of claims 1-6, 8-17, and 19-21, the Examiner has considered the Applicant’s arguments but does not find them persuasive. Any arguments inadvertently not addressed are unpersuasive for at least the following reasons:
Applicant argues:
The claims are not directed to a judicial exception under Prong Two of Step 2A because they integrate the asserted abstract idea into a practical application The claims integrate the asserted abstract idea into a practical application by providing an improvement to electronic medical record (EMR) data processing technologies, and specifically the ability of EMR systems to automatically evaluate, score, and store clinical records with quantified integrity metrics that enable downstream automated processing. The specification identifies specific technical deficiencies in EMR systems… These are not merely "human activity" problems as characterized by the FOA; rather, they are technical deficiencies in how EMR computer systems store, structure, and process clinical data across disparate data sources and schemas. The specification describes how the claimed system provides technical improvements to address these deficiencies… The specification describes how the claimed system provides technical improvements to address these deficiencies… Amended claim 1 recites specific technical elements that correspond to these improvements… The quantitative data integrity score associated with the definitive clinical record in a data store is not merely an abstract metric; rather, it creates a more trustworthy "single source of truth"… Thus, the claimed "calculating ... a quantitative data integrity score" and "associating the quantitative data integrity score with the definitive clinical record in a data store" as recited by representative claim 1 creates a technical artifact that improves how computer systems prioritize data for machine learning training, clinical review, and automated operational analytics, which are functions that could not be performed without the scored record stored in the data store.
The Examiner respectfully disagrees.
It is respectfully submitted, that the claimed additional elements do not recite a technical solution to a technical problem recited in Applicant’s specification, as required by 2106.04(d)(1) to provide a technical solution to a technical problem, and further no claimed additional elements provide any alleged technical solutions to any alleged technical problems in Applicant’s specification. Looking at the argued paragraphs [0004]-[0007], the paragraphs do not recite technical problems rooted in computer hardware technology, instead the paragraphs at best describe manual human activity problems of time and efficiency in handling patient EMR data, which may improve upon the abstract idea of organizing data for a human user, nevertheless an improved abstract idea is still an abstract idea. Furthermore paragraphs [0034], [0044] and [0133] do not actually describe any details about EMR inoperability and instead frames the problem as a human activity problem of determination of gaps and managing patient medical data, which are not technical problems rooted in computer hardware technology, at best this is merely application of the abstract idea on generic computer components which are not particular, they are generic off-the shelf hardware (see Applicant’s Specification Figure 2, paragraphs [0009]-[0011]), and which as stated in 2106.05(f)(2) “claiming the improved speed or efficiency inherent with applying the abstract idea on a computer” does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA). The other argued paragraphs are directed at determination of a “quantitative data integrity score”, however the argued “quantitative data integrity score” is organization of data (i.e., math) and is not an additional element capable of providing a practical application. None of the claimed additional elements alleviate any alleged technical problems recited in Applicant’s specification, the claims collect data, organize the data and provide output for a human user using a generic off-the-shelf schema and concept mapping to generally link the abstract idea to a particular technological environment with extra-solution activity of traditional well-known computer functions (i.e., receiving and displaying) and provides no details on how these additional elements improve the performance of the computer nor how they recite a technical solution to a technical problem recited in Applicant’s specification, the argument is not persuasive.
Rejections under 35 U.S.C. § 103
Regarding the rejection of claims 1-6, 8-17 and 19-21, the Examiner has considered the Applicant’s arguments; however, the arguments are not persuasive as addressed herein. The Examiner has attempted to address all of the arguments presented by the Applicant; however, any arguments inadvertently not addressed are not persuasive for at least the following reasons:
Applicant argues:
Applicant respectfully traverses the rejection because the proposed combination of Sadeghi, Rentas, and Downs fails to teach or suggest each and every element of these claims… The proposed combination of Sadeghi, Rentas, and Downs does not teach or suggest this combination of limitations… Furthermore, there is no motivation to combine these references to arrive at the claimed invention… Each of Rankin and Abraham-Fuchs fails to remedy the deficiencies of Sadeghi, Rentas, and Downs, as each of Rankin and Abraham-Fuchs is silent on calculating a quantitative data integrity score for a definitive clinical record based on a number and a severity of one or more errors and a revision, and associating the quantitative data integrity score with a definitive clinical record in a data store. Therefore, each proposed combination fails to teach or suggest each and every element of these claims.
The Examiner respectfully disagrees.
It is respectfully submitted, the amended limitation is taught by the combination of Abraham-Fuchs within the teachings of Sadeghi, Rentas and Downs, in particular Sadeghi teaches scoring using the determined number of errors and the revision (see above but at least paragraphs [0054], [0061], [0075] and [0145]), however Sadeghi may not explicitly recite the that the score is a integrity score, Downs teaches determination of quality (i.e., integrity) scores (see above but at least paragraph [0060]), although they may not explicitly use a severity to determine an integrity score, Abraham-Fuchs teaches a quality score that uses a severity for determination, which in combination with the teachings of Sadeghi and Downs would be prima facie obvious with the motivation of “improve the clinical study or clinical study process” (Abraham-Fuchs: paragraph [0009]). Finally, a person of ordinary skill in the art would find it prima facie obvious to combine Downs within the teachings of Sadeghi with the motivation of “providing an increase in the data available to clinical laboratories and genetic test developers” (Downs: paragraphs [0002]-[0005]). Therefore, in view of the newly added Abram-Fuchs to the intendent claim as necessitated by amendment the argument is not persuasive.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Andrew E Lee whose telephone number is (571)272-8323. The examiner can normally be reached M-Th 9-5:00 PM.
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, Shahid Merchant can be reached on 571-270-1360. 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.
/A.E.L./Examiner, Art Unit 3684
/Shahid Merchant/Supervisory Patent Examiner, Art Unit 3684
Prosecution Insights