DETAILED ACTION
Notices to Applicant
This communication is a First Action Non-Final on the merits. Claims 1-20 as filed 02/10/2024, are currently pending and have been considered below.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
The present application claims the benefit of U.S. Provisional Patent Application No. 63/444,875, filed February 10, 2023, and U.S. Provisional Patent Application No. 63/444,869, filed February 10, 2023, each of which is incorporated by reference herein in its entirety.
The present application is also a continuation-in-part application of U.S. Patent Application No. 17/502,005, filed October 14, 2021, which is a continuation-in-part of U.S. Patent Application No. 17/402,256, filed August 13, 2021, both naming Dimitar V. Baronov, Robert Hammond-Oakley, and Evan J. Butler as inventors, which claims priority to U.S. Provisional Patent Application No. 63/091,493, filed October 14, 2020, U.S. Provisional Patent Application No. 63/091,427, filed October 14, 2020, U.S. Provisional Patent Application No. 63/180,881, filed April 28, 2021, U.S. Provisional Patent Application No. 63/183,979, filed May 4, 2021, and U.S. Provisional Patent Application No. 63/190,070, filed May 18, 2021.
Claim Objections
Claim 15 is objected to because of the following informalities: Line 2 recites the claim element “an application simulator,” however, lines 3, 7, and 9 recite “the simulator,” – these elements should read “the application simulator.” Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation is: “an application simulator” in claim 15.
Because this claim limitation is being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it is being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this limitation interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
The present Application Specification states “Those skilled in the art should understand that each of these components can be implemented in a variety of conventional manners, such as by using hardware, software, or a combination of hardware and software, across one or more other functional components. For example, the simulator 142 (discussed in detail below) may be implemented using a plurality of microprocessors executing firmware.” See Application Specification at [0136]. Therefore, the claim limitations will be interpreted to be a hardware AND software computer program product stored on a memory (see MPEP § 2181(II)(B) wherein when the supporting disclosure for a computer-implemented invention discusses the implementation of the functionality of the invention through hardware, software, or a combination of both, a question can arise as to which mode of implementation supports the means-plus-function limitation. The language of 35 U.S.C. 112(f) requires that the recited "means" for performing the specified function shall be construed to cover the corresponding "structure or material" described in the specification and equivalents thereof. Therefore, by choosing to use a means-plus-function limitation and invoke 35 U.S.C. 112(f) applicant limits that claim limitation to the disclosed structure, i.e., implementation by hardware or the combination of hardware and software, and equivalents thereof. Therefore, the examiner should not construe the limitation as covering pure software implementation).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2-4, 6-7, 12-14, and 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 6 recites the limitation "the graphic compiler" in line 2. There is insufficient antecedent basis for this limitation in the claim. Claims 12 and 20 recite the same “the graphic compiler” limitation with insufficient antecedent basis.
Claims 2, 3, 7, 9, 10, and 13 recite the limitations “high compliance” and/or “low compliance.” The terms “high” and “low” are relative terms which renders the claim indefinite. The terms “high” and “low” are not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Accordingly, claims 2, 3, 7, 9, 10, and 13, as well as claim 4, which dependents upon claim 3, are rejected as being indefinite.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without significantly more.
Claims 1-7 are drawn to a method for back testing a medical protocol, which is within the four statutory categories (i.e. method).
Independent Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 1 recites:
1. A method of back testing a medical protocol comprising: receiving an eligibility rule and compliance rule for a medical protocol, each of the rules having one or more conditions;
receiving collected patient data from a plurality of patients, the collected patient data including longitudinal patient data relating to a specific parameter collected over a period of time from one or more sensors and/or medical devices;
determining that a patient was eligible for the protocol as a function of the eligibility rule and the collected patient data; and
determining a historic dynamic concordance rate for the protocol, the historic dynamic concordance rate for the protocol indicating the rate at which the patient data was consistent with the compliance rule for the protocol over the period of time.
The above claim limitations, as drafted, is a method that, under its broadest reasonable interpretation, covers managing personal behavior or interactions between people through following rules or instructions but for the recitation of generic computer components. That is, other than reciting “one or more sensors and/or medical devices,” nothing in the claim precludes the limitations from being rules or instructions for managing personal behavior or interactions between people. For example, but for the “one or more sensors and/or medical devices,” language, receiving an eligibility rule and compliance rule for a medical protocol, each of the rules having one or more conditions; receiving collected patient data from a plurality of patients, the collected patient data including longitudinal patient data relating to a specific parameter collected over a period of time; determining that a patient was eligible for the protocol as a function of the eligibility rule and the collected patient data; and determining a historic dynamic concordance rate for the protocol, the historic dynamic concordance rate for the protocol indicating the rate at which the patient data was consistent with the compliance rule for the protocol over the period of time in the context of this claim encompasses the managing of personal behaviors for back testing a medical protocol. If a claim limitation, under its broadest reasonable interpretation, covers performance of managing personal behavior or interactions between people through following rules or instructions but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Further, the limitations of “determining that a patient was eligible for the protocol as a function of the eligibility rule and the collected patient data; and determining a historic dynamic concordance rate for the protocol, the historic dynamic concordance rate for the protocol indicating the rate at which the patient data was consistent with the compliance rule for the protocol over the period of time” falls within the “Mental Processes” 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 only recites the above bolded additional elements of using “one or more sensors and/or medical devices,” to perform the claim limitations. The additional elements are recited at a high-level of generality utilizing the claimed machinery of one or more sensors and/or medical devices in its ordinary capacity (i.e., the sensors may include, but are not limited to, a blood oximeter, a blood pressure measurement device, a pulse measurement device, a glucose measuring device, one or more analyte measuring devices, an electrocardiogram recording device, amongst others (Application Specification [0063], [0064])). As such, the limitations amount to no more than mere instructions to implement an abstract idea invoking machinery as a tool to perform an abstract idea. See MPEP 2106.05(f)(2). Further, this additional element of using “one or more sensors and/or medical devices,” amounts to are mere data gathering and output recited at a high level of generality, and thus are insignificant extra-solution activity. See MPEP 2106.05(g) (“whether the limitation is significant”). Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. 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 using “one or more sensors and/or medical devices,” to perform the claim limitations amounts to no more than mere instructions to apply the exception using machinery in its ordinary capacity (i.e., the sensors may include, but are not limited to, a blood oximeter, a blood pressure measurement device, a pulse measurement device, a glucose measuring device, one or more analyte measuring devices, an electrocardiogram recording device, amongst others (Application Specification [0063], [0064])). Mere instructions to apply an exception using machinery in its ordinary capacity cannot provide an inventive concept. See MPEP 2106.05(f)(2). Further, the this additional element of using “one or more sensors and/or medical devices,” amounts to are mere data gathering and output receiving or transmitting data over a network and are well-understood, routine, conventional activity. See MPEP 2106.05(d), subsection II. The claim is not patent eligible.
Dependent claims 2-7 include limitations of the independent claim and are directed to the same abstract idea as discussed above and incorporated herein. The dependent claims are rejected under 35 U.S.C. § 101 because they are directed to non-statutory subject matter. These additional claims recite what the data is and how it is analyzed. These information characteristics do not integrate the judicial exception into a practical application, and, when viewed individually or as a whole, they do not add anything substantial beyond the managing of personal behaviors for back testing a medical protocol. Claim 4 recites “a newly deployed medical device” and claims 6-7 recite a “graphic compiler,” however, both of these limitations are recited at a high level of generality as a tool for performing the abstract idea. See Application Specification at [0058], [0063], [0064], [0127], [0136]; MPEP 2106.05(f). Furthermore, the combination of elements does not indicate a significant improvement to the functioning of a computer or any other technology. Therefore the dependent claims are rejected under 35 U.S.C. § 101.
Claims 8-14 are drawn to a computer program product for use on a computer system for enrolling a patient in a medical protocol, which is within the four statutory categories (i.e. manufacture).
Independent Claim 8 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 8 recites:
8. A computer program product for use on a computer system for enrolling a patient in a medical protocol, the computer program product comprising a tangible, non-transient computer usable medium having computer readable program code thereon, the computer readable program code comprising:
program code for receiving eligibility rule and compliance rule for a medical protocol;
program code for receiving collected patient data from a plurality of patients, the collected patient data including longitudinal patient data relating to a specific parameter collected over a period of time from one or more sensors and/or medical devices;
program code for receiving determining when a patient was eligible for the protocol as a function of the eligibility rule and the collected patient data; and
program code for receiving determining a historic dynamic concordance rate for the protocol, the historic dynamic concordance rate for the protocol indicating the rate at which the patient data was consistent with the compliance rule for the protocol over the period of time.
The above claim limitations, as drafted, is a manufacture that, under its broadest reasonable interpretation, covers managing personal behavior or interactions between people through following rules or instructions but for the recitation of generic computer components. That is, other than reciting “a tangible, non-transient computer usable medium having computer readable program code thereon,” and “one or more sensors and/or medical devices,” nothing in the claim precludes the limitations from being rules or instructions for managing personal behavior or interactions between people. For example, but for the “a tangible, non-transient computer usable medium having computer readable program code thereon,” and “one or more sensors and/or medical devices,” language, receiving an eligibility rule and compliance rule for a medical protocol, each of the rules having one or more conditions; receiving collected patient data from a plurality of patients, the collected patient data including longitudinal patient data relating to a specific parameter collected over a period of time; determining that a patient was eligible for the protocol as a function of the eligibility rule and the collected patient data; and determining a historic dynamic concordance rate for the protocol, the historic dynamic concordance rate for the protocol indicating the rate at which the patient data was consistent with the compliance rule for the protocol over the period of time in the context of this claim encompasses the managing of personal behaviors for back testing a medical protocol. If a claim limitation, under its broadest reasonable interpretation, covers performance of managing personal behavior or interactions between people through following rules or instructions but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Further, the limitations of “determining that a patient was eligible for the protocol as a function of the eligibility rule and the collected patient data; and determining a historic dynamic concordance rate for the protocol, the historic dynamic concordance rate for the protocol indicating the rate at which the patient data was consistent with the compliance rule for the protocol over the period of time” falls within the “Mental Processes” 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 only recites the above bolded additional elements of using “a tangible, non-transient computer usable medium having computer readable program code thereon,” and “one or more sensors and/or medical devices,” to perform the claim limitations. The additional elements are recited at a high-level of generality (i.e., a computer program product for use with a computer system that may include a series of computer instructions fixed either on a tangible, non-transitory medium, such as a computer readable medium (e.g., a diskette, CD-ROM, ROM, or fixed disk); and the sensors may include, but are not limited to, a blood oximeter, a blood pressure measurement device, a pulse measurement device, a glucose measuring device, one or more analyte measuring devices, an electrocardiogram recording device, amongst others (Application Specification [0063], [0064], [0248])). As such, the limitations amount to no more than mere instructions to implement an abstract idea on a computer or machinery in its ordinary capacity, or merely uses a computer/machinery as a tool to perform an abstract idea. See MPEP 2106.05(f). Further, this additional element of using “one or more sensors and/or medical devices,” amounts to are mere data gathering and output recited at a high level of generality, and thus are insignificant extra-solution activity. See MPEP 2106.05(g) (“whether the limitation is significant”). Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. 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 using “a tangible, non-transient computer usable medium having computer readable program code thereon,” and “one or more sensors and/or medical devices,” to perform the claim limitations amounts to no more than mere instructions to apply the exception using generic computing components and machinery used its ordinary capcaity (i.e., a computer program product for use with a computer system that may include a series of computer instructions fixed either on a tangible, non-transitory medium, such as a computer readable medium (e.g., a diskette, CD-ROM, ROM, or fixed disk); and the sensors may include, but are not limited to, a blood oximeter, a blood pressure measurement device, a pulse measurement device, a glucose measuring device, one or more analyte measuring devices, an electrocardiogram recording device, amongst others (Application Specification [0063], [0064], [0248])). Mere instructions to apply an exception using a generic computer component or machinery used in its ordinary capacity cannot provide an inventive concept. See MPEP 2106.05(f). Further, the this additional element of using “one or more sensors and/or medical devices,” amounts to are mere data gathering and output receiving or transmitting data over a network and are well-understood, routine, conventional activity. See MPEP 2106.05(d), subsection II. The claim is not patent eligible.
Dependent claims 9-14 include limitations of the independent claim and are directed to the same abstract idea as discussed above and incorporated herein. The dependent claims are rejected under 35 U.S.C. § 101 because they are directed to non-statutory subject matter. These additional claims recite what the data is and how it is analyzed. These information characteristics do not integrate the judicial exception into a practical application, and, when viewed individually or as a whole, they do not add anything substantial beyond the managing of personal behaviors for back testing a medical protocol. Claims 12-14 recite a “graphic compiler,” however, both of these limitations are recited at a high level of generality as a tool for performing the abstract idea. See Application Specification at [0058], [0063], [0064], [0127], [0136]; MPEP 2106.05(f). Furthermore, the combination of elements does not indicate a significant improvement to the functioning of a computer or any other technology. Therefore the dependent claims are rejected under 35 U.S.C. § 101.
Claims 15-20 are drawn to a system for simulating a medical protocol, which is within the four statutory categories (i.e. machine).
Independent Claim 15 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 15 recites:
15. A system for simulating a medical protocol, the system comprising: an application simulator configured to receive eligibility rule and compliance rule for a medical protocol,
the simulator further configured to receive collected patient data from a plurality of patients, the collected patient data including longitudinal patient data relating to a specific parameter collected over a period of time from one or more sensors and/or medical devices,
the simulator further configured to compare the patient data with the eligibility rule to determine when a patient was eligible for the protocol, and
the simulator further configured to compare the patient data with the compliance rule to determine a historic dynamic concordance rate for the protocol, the historic dynamic concordance rate for the protocol indicating the rate at which the patient data was consistent with the compliance rule for the protocol over the period of time.
The above claim limitations, as drafted, is a machine that, under its broadest reasonable interpretation, covers managing personal behavior or interactions between people through following rules or instructions but for the recitation of generic computer components. That is, other than reciting “an application simulator configured to,” and “one or more sensors and/or medical devices,” nothing in the claim precludes the limitations from being rules or instructions for managing personal behavior or interactions between people. For example, but for the “an application simulator configured to,” and “one or more sensors and/or medical devices,” language, receiving an eligibility rule and compliance rule for a medical protocol, each of the rules having one or more conditions; receiving collected patient data from a plurality of patients, the collected patient data including longitudinal patient data relating to a specific parameter collected over a period of time; determining that a patient was eligible for the protocol as a function of the eligibility rule and the collected patient data; and determining a historic dynamic concordance rate for the protocol, the historic dynamic concordance rate for the protocol indicating the rate at which the patient data was consistent with the compliance rule for the protocol over the period of time in the context of this claim encompasses the managing of personal behaviors for back testing a medical protocol. If a claim limitation, under its broadest reasonable interpretation, covers performance of managing personal behavior or interactions between people through following rules or instructions but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Further, the limitations of “determining that a patient was eligible for the protocol as a function of the eligibility rule and the collected patient data; and determining a historic dynamic concordance rate for the protocol, the historic dynamic concordance rate for the protocol indicating the rate at which the patient data was consistent with the compliance rule for the protocol over the period of time” falls within the “Mental Processes” 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 only recites the above bolded additional elements of using “an application simulator configured to,” and “one or more sensors and/or medical devices,” to perform the claim limitations. The additional elements are recited at a high-level of generality (i.e., a computer program product for use with a computer system that may include a series of computer instructions fixed either on a tangible, non-transitory medium, such as a computer readable medium (e.g., a diskette, CD-ROM, ROM, or fixed disk); and the sensors may include, but are not limited to, a blood oximeter, a blood pressure measurement device, a pulse measurement device, a glucose measuring device, one or more analyte measuring devices, an electrocardiogram recording device, amongst others (Application Specification [0063], [0064], [0136])). As such, the limitations amount to no more than mere instructions to implement an abstract idea on a computer or machinery in its ordinary capacity, or merely uses a computer/machinery as a tool to perform an abstract idea. See MPEP 2106.05(f). Further, this additional element of using “one or more sensors and/or medical devices,” amounts to are mere data gathering and output recited at a high level of generality, and thus are insignificant extra-solution activity. See MPEP 2106.05(g) (“whether the limitation is significant”). Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. 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 using “an application simulator configured to,” and “one or more sensors and/or medical devices,” to perform the claim limitations amounts to no more than mere instructions to apply the exception using generic computing components and machinery used in its ordinary capacity (i.e., a computer program product for use with a computer system that may include a series of computer instructions fixed either on a tangible, non-transitory medium, such as a computer readable medium (e.g., a diskette, CD-ROM, ROM, or fixed disk); and the sensors may include, but are not limited to, a blood oximeter, a blood pressure measurement device, a pulse measurement device, a glucose measuring device, one or more analyte measuring devices, an electrocardiogram recording device, amongst others (Application Specification [0063], [0064], [0248])). Mere instructions to apply an exception using a generic computer component or machinery used in its ordinary capacity cannot provide an inventive concept. See MPEP 2106.05(f). Further, the this additional element of using “one or more sensors and/or medical devices,” amounts to are mere data gathering and output receiving or transmitting data over a network and are well-understood, routine, conventional activity. See MPEP 2106.05(d), subsection II. The claim is not patent eligible.
Dependent claims 16-20 include limitations of the independent claim and are directed to the same abstract idea as discussed above and incorporated herein. The dependent claims are rejected under 35 U.S.C. § 101 because they are directed to non-statutory subject matter. These additional claims recite what the data is and how it is analyzed. These information characteristics do not integrate the judicial exception into a practical application, and, when viewed individually or as a whole, they do not add anything substantial beyond the managing of personal behaviors for back testing a medical protocol. Claims 19-20 recite a “graphic compiler,” however, both of these limitations are recited at a high level of generality as a tool for performing the abstract idea. See Application Specification at [0058], [0063], [0064], [0127], [0136]; MPEP 2106.05(f). Furthermore, the combination of elements does not indicate a significant improvement to the functioning of a computer or any other technology. Therefore the dependent claims are rejected under 35 U.S.C. § 101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4, 6-10, 12-13, 15-16, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. 2009/0313048 A1 (hereinafter “Kahn et al.”) in view of U.S. 2019/0328338 A1 (hereinafter “Hu et al.”).
RE: Claim 1 Kahn et al. teaches the claimed:
1. A method of back testing a medical protocol comprising: receiving an eligibility rule and compliance rule for a medical protocol, each of the rules having one or more conditions ((Kahn et al., [0127], [0149], Fig 18) (establish initial patient eligibility criteria, this could involve selecting values for the attributes in the previously selected patient eligibility attribute list, or establishing further eligibility criteria, or both; The fact of enrollment is recorded in the patient information database; the workflow management tool, governed by the iCP database, directs all of the workflow task required at each patient visit in order to ensure compliance with the protocol; Example protocol consists of treatment administered intravenously every three weeks as long as the patient has stable or responding disease i.e. compliance rule e.g. granucolocyte count must be >= 1500/ul and platelet count must be >= 10000/ul on day 1 of each cycle));
receiving collected patient data from a plurality of patients, the collected patient data including longitudinal patient data relating to a specific parameter collected over a period of time from one or more sensors and/or medical devices ((Kahn et al., [0063], [0082], [0148]) (Once a patient is enrolled into a study, the protocol database indicates to the clinician exactly what tasks are to be performed at each patient visit. These tasks can include both patient management tasks, such as administering a drug or taking a measurement, and also data management tasks, such as completing and submitting a particular CRF; patient measurement data e.g. blood pressure i.e. requiring use of a sensor and/or medical device; The iCP may direct certain patient assessment tasks which are relevant to the further eligibility criteria of the particular study. It also directs the data management tasks which are appropriate so that clinical site personnel enter the patient assessment results into the system for comparison against the further eligibility criteria));
determining that a patient was eligible for the protocol as a function of the eligibility rule and the collected patient data ((Kahn et al., [0149]) (if the patient is still eligible for one or more clinical trials, the then workflow management tool directs and manages the process of enrolling the patient in one of the trials)).
Kahn et al. fails to explicitly teach, but Hu et al. teaches the claimed:
determining a historic dynamic concordance rate for the protocol, the historic dynamic concordance rate for the protocol indicating the rate at which the patient data was consistent with the compliance rule for the protocol over the period of time ((Hu et al., Tables1-3, [0006], [0031], [0037], [0041], [0043], [0047]-[0050]) (tables showing the rate over an interval of time when patient data e/g/ oxygen saturation, hear rate satisfies a threshold rule for whether or not a treatment e.g. blood transfusion is required)).
One of ordinary skill in the art at the time of the effective filing date would have found it obvious to combine the rate over a period of time a patient measurement satisfied a threshold condition for a treatment as taught by Hu et al. within the method and system for intelligent clinical protocol management and evaluation as taught by Kahn et al. with the motivation of determining whether a patient requires intervention at an earlier stage of the treatment process (Hu et al. at [0003]).
RE: Claim 2 Kahn et al. and Hu et al. teach the claimed:
2. The method as defined by claim 1, further comprising: determining patient outcomes as a function of high compliance with the protocol relative to low compliance with the protocol ((Kahn et al., [0115]) (The process continues at a "Cycle 1; Day 1" object 622 followed by a choice_object 624 for "Assess for treatment." The clinician may make one of several choices during step 624 including a step of delaying ( choice object 626); a step of calling the study chairman (choice object 628); a step of aborting the current patient (choice object 630))).
RE: Claim 3 Kahn et al. and Hu et al. teach the claimed:
3. The method as defined by claim 1, further comprising: adjusting the eligibility rule or compliance rule for the protocol to define an adjusted protocol; determining patient outcomes as a function of high compliance with the protocol relative to low compliance with the adjusted protocol ((Kahn et al., [0115], [0129]) (After accrual is simulated with the patient eligibility criteria established initially in step 1010, then in step 1014, the protocol author decides whether accrual under those conditions will be adequate for the purposes of the study. If not, then in step 1016, the protocol author revises the patient eligibility criteria, again either the values in the preliminary patient eligibility criteria list or in the further eligibility criteria or both, and loops back to try the accrual simulation step 1012 again; The process continues at a "Cycle 1; Day 1" object 622 followed by a choice_object 624 for "Assess for treatment." The clinician may make one of several choices during step 624 including a step of delaying ( choice object 626); a step of calling the study chairman (choice object 628); a step of aborting the current patient (choice object 630))).
RE: Claim 4 Kahn et al. and Hu et al. teach the claimed:
4. The method of claim 3, wherein the collected patient data includes patient data from a newly deployed medical device, wherein adjusting the protocol is a function of the patient data from the newly deployed medical device ((Hu et al., [0023]) (When a patient suffers trauma, the first responders attend to the patient and begin treatment, often in the field or in an emergency response vehicle. This treatment often includes attaching vital signs monitors, such as a blood pressure sensor to measure blood pressure and a PPG sensor to measure oxygen saturation of the blood. According to various embodiments the data from one or more of these sensors are used to determine blood loss, even due to hidden internal bleeding, and thus the probability of the need for a transfusion, including need for a massive transfusion)).
One of ordinary skill in the art at the time of the effective filing date would have found it obvious to combine the use of a newly deployed medical device for collecting data to determine adjusting a protocol i.e. whether or not a transfusion is needed based on the newly collected data as taught by Hu et al. within the method and system for intelligent clinical protocol management and evaluation as taught by Kahn et al. with the motivation of determining whether a patient requires intervention at an earlier stage of the treatment process (Hu et al. at [0003]).
RE: Claim 6 Kahn et al. and Hu et al. teach the claimed:
6. The method as defined by claim 1, wherein the protocol eligibility rule and compliance rule are generated using the graphic compiler ((Kahn et al., [0102]) (In addition to being kept in the form of Visit objects, management task objects and VisitTo VisitTransition objects, the protocol meta-model also allows an iCP to keep the protocol schema in a graphical or diagrammatic form as well. In fact, it is the graphical form that protocol authors typically use, with intuitive drag-and-drop and drill-down behaviors, to encode clinical trial protocols using Protege 2000)).
RE: Claim 7 Kahn et al. and Hu et al. teach the claimed:
7. The method as defined by claim 6, further comprising: adjusting the protocol eligibility rule and/or compliance rule using the graphical compiler after receiving feedback regarding patient outcomes as a function of high compliance with the protocol, and/or adjusting the protocol eligibility rule and/or compliance rule using the graphical compiler after receiving feedback regarding a number of notifications generated by the protocol ((Kahn et al., [0102], [0115], [0129]) (After accrual is simulated with the patient eligibility criteria established initially in step 1010, then in step 1014, the protocol author decides whether accrual under those conditions will be adequate for the purposes of the study. If not, then in step 1016, the protocol author revises the patient eligibility criteria, again either the values in the preliminary patient eligibility criteria list or in the further eligibility criteria or both, and loops back to try the accrual simulation step 1012 again; The process continues at a "Cycle 1; Day 1" object 622 followed by a choice_object 624 for "Assess for treatment." The clinician may make one of several choices during step 624 including a step of delaying ( choice object 626); a step of calling the study chairman (choice object 628); a step of aborting the current patient (choice object 630; In addition to being kept in the form of Visit objects, management task objects and VisitTo VisitTransition objects, the protocol meta-model also allows an iCP to keep the protocol schema in a graphical or diagrammatic form as well. In fact, it is the graphical form that protocol authors typically use, with intuitive drag-and-drop and drill-down behaviors, to encode clinical trial protocols using Protege 2000)).
RE: Claim 8 Kahn et al. teaches the claimed:
8. A computer program product for use on a computer system for enrolling a patient in a medical protocol, the computer program product comprising a tangible, non-transient computer usable medium having computer readable program code thereon, the computer readable program code comprising: program code for receiving eligibility rule and compliance rule for a medical protocol ((Kahn et al., [0127], [0149], Fig 18, claim 19) (a computer readable medium for storing the intelligent clinical protocol; establish initial patient eligibility criteria, this could involve selecting values for the attributes in the previously selected patient eligibility attribute list, or establishing further eligibility criteria, or both; The fact of enrollment is recorded in the patient information database; the workflow management tool, governed by the iCP database, directs all of the workflow task required at each patient visit in order to ensure compliance with the protocol; Example protocol consists of treatment administered intravenously every three weeks as long as the patient has stable or responding disease i.e. compliance rule e.g. granucolocyte count must be >= 1500/ul and platelet count must be >= 10000/ul on day 1 of each cycle));
program code for receiving collected patient data from a plurality of patients, the collected patient data including longitudinal patient data relating to a specific parameter collected over a period of time from one or more sensors and/or medical devices ((Kahn et al., [0063], [0082], [0148]) (Once a patient is enrolled into a study, the protocol database indicates to the clinician exactly what tasks are to be performed at each patient visit. These tasks can include both patient management tasks, such as administering a drug or taking a measurement, and also data management tasks, such as completing and submitting a particular CRF; patient measurement data e.g. blood pressure i.e. requiring use of a sensor and/or medical device; The iCP may direct certain patient assessment tasks which are relevant to the further eligibility criteria of the particular study. It also directs the data management tasks which are appropriate so that clinical site personnel enter the patient assessment results into the system for comparison against the further eligibility criteria));
program code for receiving determining when a patient was eligible for the protocol as a function of the eligibility rule and the collected patient data ((Kahn et al., [0149]) (if the patient is still eligible for one or more clinical trials, the then workflow management tool directs and manages the process of enrolling the patient in one of the trials)).
Kahn et al. fails to explicitly teach, but Hu et al. teaches the claimed:
program code for receiving determining a historic dynamic concordance rate for the protocol, the historic dynamic concordance rate for the protocol indicating the rate at which the patient data was consistent with the compliance rule for the protocol over the period of time ((Hu et al., Tables1-3, [0006], [0031], [0037], [0041], [0043], [0047]-[0050]) (tables showing the rate over an interval of time when patient data e/g/ oxygen saturation, hear rate satisfies a threshold rule for whether or not a treatment e.g. blood transfusion is required)).
One of ordinary skill in the art at the time of the effective filing date would have found it obvious to combine the rate over a period of time a patient measurement satisfied a threshold condition for a treatment as taught by Hu et al. within the method and system for intelligent clinical protocol management and evaluation as taught by Kahn et al. with the motivation of determining whether a patient requires intervention at an earlier stage of the treatment process (Hu et al. at [0003]).
RE: Claim 9 Kahn et al. and Hu et al. teach the claimed:
9. The computer program product of claim 8, further comprising: program code for determining patient outcomes as a function of high compliance with the protocol relative to low compliance with the protocol ((Kahn et al., [0115]) (The process continues at a "Cycle 1; Day 1" object 622 followed by a choice_object 624 for "Assess for treatment." The clinician may make one of several choices during step 624 including a step of delaying ( choice object 626); a step of calling the study chairman (choice object 628); a step of aborting the current patient (choice object 630))).
RE: Claim 10 Kahn et al. and Hu et al. teach the claimed:
10. The computer program product of claim 8, further comprising: program code for adjusting the eligibility rule or compliance rule for the protocol to define an adjusted protocol; program code for determining patient outcomes as a function of high compliance with the protocol relative to low compliance with the adjusted protocol ((Kahn et al., [0115], [0129]) (After accrual is simulated with the patient eligibility criteria established initially in step 1010, then in step 1014, the protocol author decides whether accrual under those conditions will be adequate for the purposes of the study. If not, then in step 1016, the protocol author revises the patient eligibility criteria, again either the values in the preliminary patient eligibility criteria list or in the further eligibility criteria or both, and loops back to try the accrual simulation step 1012 again; The process continues at a "Cycle 1; Day 1" object 622 followed by a choice_object 624 for "Assess for treatment." The clinician may make one of several choices during step 624 including a step of delaying ( choice object 626); a step of calling the study chairman (choice object 628); a step of aborting the current patient (choice object 630))).
RE: Claim 12 Kahn et al. and Hu et al. teach the claimed:
12. The computer program product of claim 8, wherein the protocol eligibility rule and compliance rule are generated using the graphic compiler ((Kahn et al., [0102]) (In addition to being kept in the form of Visit objects, management task objects and VisitTo VisitTransition objects, the protocol meta-model also allows an iCP to keep the protocol schema in a graphical or diagrammatic form as well. In fact, it is the graphical form that protocol authors typically use, with intuitive drag-and-drop and drill-down behaviors, to encode clinical trial protocols using Protege 2000)).
RE: Claim 13 Kahn et al. and Hu et al. teach the claimed:
13. The computer program product of claim 12, further comprising: program code for adjusting the protocol eligibility rule and/or compliance rule using the graphical compiler after receiving feedback regarding patient outcomes as a function of high compliance with the protocol ((Kahn et al., [0102], [0115], [0129]) (After accrual is simulated with the patient eligibility criteria established initially in step 1010, then in step 1014, the protocol author decides whether accrual under those conditions will be adequate for the purposes of the study. If not, then in step 1016, the protocol author revises the patient eligibility criteria, again either the values in the preliminary patient eligibility criteria list or in the further eligibility criteria or both, and loops back to try the accrual simulation step 1012 again; The process continues at a "Cycle 1; Day 1" object 622 followed by a choice_object 624 for "Assess for treatment." The clinician may make one of several choices during step 624 including a step of delaying ( choice object 626); a step of calling the study chairman (choice object 628); a step of aborting the current patient (choice object 630; In addition to being kept in the form of Visit objects, management task objects and VisitTo VisitTransition objects, the protocol meta-model also allows an iCP to keep the protocol schema in a graphical or diagrammatic form as well. In fact, it is the graphical form that protocol authors typically use, with intuitive drag-and-drop and drill-down behaviors, to encode clinical trial protocols using Protege 2000)).
RE: Claim 15 Kahn et al. teaches the claimed:
15. A system for simulating a medical protocol, the system comprising: an application simulator configured to receive eligibility rule and compliance rule for a medical protocol ((Kahn et al., [0086], [0126], [0127], [0149], Fig 18) (The iCP database is used by most software modules in the overall system to ensure that all protocol parameters, treatment decisions, and testing procedures are followed; an accrual simulation method for establishing patient eligibility criteria, substantially solves the problem mentioned above in which after finalizing a clinical trial protocol, engaging study sites and beginning the enrollment process, it is finally found that the eligibility criteria for the study are too restrictive and that with such criteria it is not possible to enroll sufficient patients in the trial; establish initial patient eligibility criteria, this could involve selecting values for the attributes in the previously selected patient eligibility attribute list, or establishing further eligibility criteria, or both; The fact of enrollment is recorded in the patient information database; the workflow management tool, governed by the iCP database, directs all of the workflow task required at each patient visit in order to ensure compliance with the protocol; Example protocol consists of treatment administered intravenously every three weeks as long as the patient has stable or responding disease i.e. compliance rule e.g. granucolocyte count must be >= 1500/ul and platelet count must be >= 10000/ul on day 1 of each cycle));
the simulator further configured to receive collected patient data from a plurality of patients, the collected patient data including longitudinal patient data relating to a specific parameter collected over a period of time from one or more sensors and/or medical devices ((Kahn et al., [0063], [0082], [0148]) (Once a patient is enrolled into a study, the protocol database indicates to the clinician exactly what tasks are to be performed at each patient visit. These tasks can include both patient management tasks, such as administering a drug or taking a measurement, and also data management tasks, such as completing and submitting a particular CRF; patient measurement data e.g. blood pressure i.e. requiring use of a sensor and/or medical device; The iCP may direct certain patient assessment tasks which are relevant to the further eligibility criteria of the particular study. It also directs the data management tasks which are appropriate so that clinical site personnel enter the patient assessment results into the system for comparison against the further eligibility criteria));
the simulator further configured to compare the patient data with the eligibility rule to determine when a patient was eligible for the protocol ((Kahn et al., [0149]) (if the patient is still eligible for one or more clinical trials, the then workflow management tool directs and manages the process of enrolling the patient in one of the trials)).
Kahn et al. fails to explicitly teach, but Hu et al. teaches the claimed:
the simulator further configured to compare the patient data with the compliance rule to determine a historic dynamic concordance rate for the protocol, the historic dynamic concordance rate for the protocol indicating the rate at which the patient data was consistent with the compliance rule for the protocol over the period of time ((Hu et al., Tables1-3, [0006], [0031], [0037], [0041], [0043], [0047]-[0050]) (tables showing the rate over an interval of time when patient data e/g/ oxygen saturation, hear rate satisfies a threshold rule for whether or not a treatment e.g. blood transfusion is required)).
One of ordinary skill in the art at the time of the effective filing date would have found it obvious to combine the rate over a period of time a patient measurement satisfied a threshold condition for a treatment as taught by Hu et al. within the method and system for intelligent clinical protocol management and evaluation as taught by Kahn et al. with the motivation of determining whether a patient requires intervention at an earlier stage of the treatment process (Hu et al. at [0003]).
RE: Claim 16 Kahn et al. and Hu et al. teach the claimed:
16. The system as defined by claim 15, further comprising a database including the eligibility rule and the compliance rule ((Kahn et al., [0062]) (The protocol designer chooses the meta-model and preliminary eligibility list appropriate for the relevant disease category, and encodes the clinical trial protocol, including eligibility and patient workflow, within the selected meta-model. The resulting protocol database is stored together with databases of other protocols in the same and different disease categories)).
RE: Claim 18 Kahn et al. and Hu et al. teach the claimed:
18. The system as defined by claim 16, further comprising a reporting module configured to provide a report about the protocol, wherein the report includes clicks by medical staff in the interface, interactions with the interface by medical staff, average patient compliance, time from eligibility to protocol start, ICU length of stay, ventilation time, extubation failure rate, readmission rate, and/or patient outcomes relative to dynamic concordance of the patient ((Kahn et al., [0064], [0147]) (The system keeps track of the progress of the patient and the clinician through the workflow graph of a particular protocol. The system reports this information to study sponsors, who can then monitor the progress of an overall clinical trial in near-real-time, and to the central authority which can then generate performance metrics; involves manual entry of newly obtained patient data, then preferably such data is added to the patient information database i.e. interactions with the interface by the medical staff)).
RE: Claim 19 Kahn et al. and Hu et al. teach the claimed:
19. The system as defined by claim 18, further comprising a graphic compiler configured to graphically generate the eligibility rule and/or the compliance rule ((Kahn et al., [0102]) (In addition to being kept in the form of Visit objects, management task objects and VisitTo VisitTransition objects, the protocol meta-model also allows an iCP to keep the protocol schema in a graphical or diagrammatic form as well. In fact, it is the graphical form that protocol authors typically use, with intuitive drag-and-drop and drill-down behaviors, to encode clinical trial protocols using Protege 2000)).
Claims 5, 11, 14, 17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. 2009/0313048 A1 (hereinafter “Kahn et al.”) in view of U.S. 2019/0328338 A1 (hereinafter “Hu et al.”), and further in view of U.S. 2017/0132383 A1
RE: Claim 5 Kahn et al. and Hu et al. teach the claimed:
5. The method as defined by claim 1, further comprising:
Kahn et al. and Hu et al. fails to explicitly teach, but Myers et al. teaches the claimed:
receiving notification rule associated with the protocol; determining a historic number of notifications over the period of time as a function of the notification rule; adjusting the notification rule to reduce the historic number of notifications ((Myers et al., [0031], [0043]) (The system can be configured to allow for customizable alarms or notifications to be set that are triggered when significant health state changes or measurement data drifts are observed. Triggering of an alarm, event or notification will solicit a response, which in tum will either ignore the detected change or drift and continue to look for further change or drift, modify some of the algorithm or detection parameters, or reset the baseline, i.e. the historical rate, with a subset of the data or begin acquiring new data to form a new baseline i.e. the adjusted notification rule. The notification can result in a custom labelling of patient state, such as the reporting of a graded risk category. Multiple tests can be performed and an alert triggered if one or more tests agree to a drift or trend detection)).
One of ordinary skill in the art at the time of the effective filing date would have found it obvious to combine the setting and adjusting of patient state detection notification rules as taught by Myers et al. within the method and system for intelligent clinical protocol management and evaluation as taught by Kahn et al. and the method and system for determining the rate over a period of time a patient measurement satisfied a threshold condition for a treatment as taught by Hu et al. with the motivation improving patient state detection and alarm accuracy considering feedback of target events or health-state changes (Myers et al. at [0004]).
RE: Claim 11 Kahn et al. and Hu et al. teach the claimed:
11. The computer program product of claim 8,
Kahn et al. and Hu et al. fails to explicitly teach, but Myers et al. teaches the claimed:
further comprising: program code for receiving notification rule associated with the protocol; program code for determining a historic number of notifications over the period of time as a function of the notification rule; program code for adjusting the notification rule to reduce the historic number of notifications ((Myers et al., [0031], [0043]) (The system can be configured to allow for customizable alarms or notifications to be set that are triggered when significant health state changes or measurement data drifts are observed. Triggering of an alarm, event or notification will solicit a response, which in tum will either ignore the detected change or drift and continue to look for further change or drift, modify some of the algorithm or detection parameters, or reset the baseline, i.e. the historical rate, with a subset of the data or begin acquiring new data to form a new baseline i.e. the adjusted notification rule. The notification can result in a custom labelling of patient state, such as the reporting of a graded risk category. Multiple tests can be performed and an alert triggered if one or more tests agree to a drift or trend detection)).
One of ordinary skill in the art at the time of the effective filing date would have found it obvious to combine the setting and adjusting of patient state detection notification rules as taught by Myers et al. within the method and system for intelligent clinical protocol management and evaluation as taught by Kahn et al. and the method and system for determining the rate over a period of time a patient measurement satisfied a threshold condition for a treatment as taught by Hu et al. with the motivation improving patient state detection and alarm accuracy considering feedback of target events or health-state changes (Myers et al. at [0004]).
RE: Claim 14 Kahn et al. and Hu et al. teach the claimed:
14. The computer program product of claim 12, further comprising: program code for adjusting the protocol eligibility rule and/or compliance rule using the graphical compiler ((Kahn et al., [0102]) (In addition to being kept in the form of Visit objects, management task objects and VisitTo VisitTransition objects, the protocol meta-model also allows an iCP to keep the protocol schema in a graphical or diagrammatic form as well. In fact, it is the graphical form that protocol authors typically use, with intuitive drag-and-drop and drill-down behaviors, to encode clinical trial protocols using Protege 2000)).
Kahn et al. and Hu et al. fails to explicitly teach, but Myers et al. teaches the claimed:
after receiving feedback regarding a number of notifications generated by the protocol ((Myers et al., [0031], [0043]) (The system can be configured to allow for customizable alarms or notifications to be set that are triggered when significant health state changes or measurement data drifts are observed. Triggering of an alarm, event or notification will solicit a response, which in tum will either ignore the detected change or drift and continue to look for further change or drift, modify some of the algorithm or detection parameters, or reset the baseline, i.e. the historical rate, with a subset of the data or begin acquiring new data to form a new baseline i.e. the adjusted notification rule. The notification can result in a custom labelling of patient state, such as the reporting of a graded risk category. Multiple tests can be performed and an alert triggered if one or more tests agree to a drift or trend detection)).
One of ordinary skill in the art at the time of the effective filing date would have found it obvious to combine the setting and adjusting of patient state detection notification rules as taught by Myers et al. within the method and system for intelligent clinical protocol management and evaluation as taught by Kahn et al. and the method and system for determining the rate over a period of time a patient measurement satisfied a threshold condition for a treatment as taught by Hu et al. with the motivation improving patient state detection and alarm accuracy considering feedback of target events or health-state changes (Myers et al. at [0004]).
RE: Claim 17 Kahn et al. and Hu et al. teach the claimed:
17. The system as defined by claim 16,
Kahn et al. and Hu et al. fails to explicitly teach, but Myers et al. teaches the claimed:
wherein the application simulator is configured to receive notification rule associated with the protocol, and to determine the number of notifications as a function of the protocol and the patient data ((Myers et al., [0031], [0043]) (The system can be configured to allow for customizable alarms or notifications to be set that are triggered when significant health state changes or measurement data drifts are observed. Triggering of an alarm, event or notification will solicit a response, which in tum will either ignore the detected change or drift and continue to look for further change or drift, modify some of the algorithm or detection parameters, or reset the baseline, i.e. the historical rate, with a subset of the data or begin acquiring new data to form a new baseline i.e. the adjusted notification rule. The notification can result in a custom labelling of patient state, such as the reporting of a graded risk category. Multiple tests can be performed and an alert triggered if one or more tests agree to a drift or trend detection)).
One of ordinary skill in the art at the time of the effective filing date would have found it obvious to combine the setting and adjusting of patient state detection notification rules as taught by Myers et al. within the method and system for intelligent clinical protocol management and evaluation as taught by Kahn et al. and the method and system for determining the rate over a period of time a patient measurement satisfied a threshold condition for a treatment as taught by Hu et al. with the motivation improving patient state detection and alarm accuracy considering feedback of target events or health-state changes (Myers et al. at [0004]).
RE: Claim 20 Kahn et al., Hu et al., and Myers et al. teach the claimed:
20. The system as defined by claim 17, wherein a rule of the protocol is modified using the graphical compiler after generating the report ((Kahn et al., [0102]) (In addition to being kept in the form of Visit objects, management task objects and VisitTo VisitTransition objects, the protocol meta-model also allows an iCP to keep the protocol schema in a graphical or diagrammatic form as well. In fact, it is the graphical form that protocol authors typically use, with intuitive drag-and-drop and drill-down behaviors, to encode clinical trial protocols using Protege 2000)).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. 2019/0224434 A1 teaches a medical system for intubation procedure for a patient comprising airflow sensors (abstract);
U.S. 2015/0213221 A1 teaches a decision support system for management of extubation in tensive care unit patients (abstract);
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANTHONY BALAJ whose telephone number is (571)272-8181. The examiner can normally be reached 8:00 - 4:00 M-F.
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, Fonya Long can be reached at (571) 270-5096. 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.M.B./Examiner, Art Unit 3682
/FONYA M LONG/Supervisory Patent Examiner, Art Unit 3682