DETAILED ACTION
Notices to Applicant
This communication is a First Action Non-Final on the merits. Claims 1-25 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 patent 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, and 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, both of which in turn claim 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
Claims 10 and 22 are objected to because of the following informalities:
Claim 10, Line 9 recites the element “the selected object,” – the limitation should read “the selected protocol condition objection,” as initially presented in line 3.
Claim 22, Line 1 recites “wherein the reports the reports,” – the limitation should read “wherein the reports.”
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.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
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 limitations is: “a reporting module” in claim 21.
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/they is/are 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 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 recites sufficient structure to perform the claimed function so as to avoid it being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
The present Application Specification provides “Those skilled in the art should understand that such a device has other physical and/or functional components, such as central processing units, other packet processing modules, and short-term memory” (Application Specification at [0139]). 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-8, 21-23, and 25 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.
Claims 2 recites the limitation "the plurality of eligibility condition objects". There is insufficient antecedent basis for this limitation in the claim. Independent claim 1 recites “one or more eligible condition objections,” such that only at least one of the element is claimed, such that a plurality claimed in dependent claim 2 lacks antecedent basis.
Claims 3 recites the limitation "the plurality of compliance condition objects". There is insufficient antecedent basis for this limitation in the claim. Independent claim 1 recites “one or more compliance condition objections,” such that only at least one of the element is claimed, such that a plurality claimed in dependent claim 3 lacks antecedent basis.
Claims 4 and 8 each recite the limitation “the protocol sequence window,” however, there is insufficient antecedent basis for this limitation in each of these claims.
Claim 6 recites the limitation “the condition,” however, there is insufficient antecedent basis for this limitation in the claim.
Claims 7 and 8 each recite the limitation "the plurality protocol condition objects". There is insufficient antecedent basis for this limitation in the claim. Independent claim 1 recites “one or more protocol condition objections,” such that only at least one of the element is claimed, such that a plurality claimed in dependent claims 7 and 8 lack antecedent basis.
Claim 22 recites the limitation “the reports,” however, there is insufficient antecedent basis for this limitation in the claim.
Claim 23 recites the limitation “the graphical reporting objects,” however, there is insufficient antecedent basis for this limitation in the claim.
Claim 25 recites the limitation “the detected patient event,” however, there is insufficient antecedent basis for this limitation in the claim.
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-9 are directed to a computer-implemented method for creating a clinical decision support application, which falls under the statutory category of a method. Independent claim 1 does not recite a judicial exception (e.g. an abstract idea), and as a result, is directed to patent eligible subject matter.
Claims 20-25 are directed to a computer-implemented system for creating a medical protocol, which falls under the statutory category of a machine. Independent claim 20 does not recite a judicial exception (e.g. an abstract idea), and as a result, is directed to patent eligible subject matter.
Claims 10-19 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 10-19 are drawn to a computer-implemented method for creating a medical protocol, which is within the four statutory categories (i.e. method).
Independent Claim 10 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 10 recites
10. A computer-implemented method for creating a medical protocol, the method comprising:
selecting a protocol condition object from a graphical user interface displaying a plurality of different protocol condition objects, each object associated with at least one corresponding parameter requirement;
displaying the selected protocol condition object in a protocol sequence window of the graphical user interface;
displaying a specific parameter window related to the corresponding parameter requirement for the selected object;
receiving a specific parameter related to the corresponding parameter requirement within the specific parameter window;
generating a clinical protocol having a condition as a function of the received specific parameter for the selected protocol condition type.
The claim, as drafted, is a method that, under its broadest reasonable interpretation, covers managing personal behavior or relationships between people through rules or instructions but for the recitation of generic computer components. That is, other than reciting the above bolded elements, for example, “selecting a protocol condition object from a graphical user interface… ,” “displaying the selected protocol condition object in a protocol sequence window of the graphical user interface,” and “displaying a specific parameter window related to the corresponding parameter requirement for the selected object,” nothing in the claim precludes the limitations from managing personal behavior or interactions between people through rules or instructions. For example, but for the above bolded language, receiving a specific parameter related to the corresponding parameter requirement within the specific parameter window and generating a clinical protocol having a condition as a function of the received specific parameter for the selected protocol condition type in the context of this claim encompasses rules or instructions for managing personal behavior or interactions between people for creating a medical protocol. If a claim limitation, under its broadest reasonable interpretation, covers rules or instructions for managing personal behavior or interactions between people but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. See MPEP § 2106.04(a)(2)(II)(C)(iii. a mental process that a neurologist should follow when testing a patient for nervous system malfunctions, In re Meyer, 688 F.2d 789, 791-93, 215 USPQ 193, 194-96 (CCPA 1982)). 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, for example, “selecting a protocol condition object from a graphical user interface… ,” “displaying the selected protocol condition object in a protocol sequence window of the graphical user interface,” and “displaying a specific parameter window related to the corresponding parameter requirement for the selected object,” to perform the claim limitations. The elements in each of these steps are recited at a high-level of generality (i.e., a graphical user interface it may be provided on, among other things, a touch-screen display (e.g. a hospital monitory, mobile device, smartphone, etc.) as it relates to a general purpose computer component (Application Specification [0153])). As such, the limitations amount to no more than mere instructions to implement an abstract idea on a computer or other machinery, or merely uses a computer or other machinery as a tool under its ordinary capacity to perform an abstract idea. See MPEP 2106.05(f)(2). 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 above bolded additional elements, for example, “selecting a protocol condition object from a graphical user interface… ,” “displaying the selected protocol condition object in a protocol sequence window of the graphical user interface,” and “displaying a specific parameter window related to the corresponding parameter requirement for the selected object,” to perform the claim limitations amounts to no more than mere instructions to apply the exception using a generic computer component. (i.e., a graphical user interface it may be provided on, among other things, a touch-screen display (e.g. a hospital monitory, mobile device, smartphone, etc.) as it relates to a general purpose computer component (Application Specification [0153])). Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. See MPEP 2106.05(f)(2). The claim is not patent eligible.
Dependent claims 11-19 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 medical protocol 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 rules or instructions for managing personal behavior or interactions between people for creating a medical protocol. 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 § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 10-19 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by W.O. 00/42487 (hereinafter “Buchanan et al.”).
RE: Claim 10 Buchanan et al. teaches the claimed:
10. A computer-implemented method for creating a medical protocol, the method comprising: selecting a protocol condition object from a graphical user interface displaying a plurality of different protocol condition objects, each object associated with at least one corresponding parameter requirement ((Buchanan et al., Pg. 28, Lines 8-10; Pg. 29, lines 27-28; Pg. 30, lines 7-11) (The user then chooses whether to enter a new rule (STEP 1112) or to select an existing rule from a list, 10 preferably presented on a pull down menu (STEP 1114); If a new problem rule is being built or if an existing problem rule is being modified, the user may build the rule in any order by sequentially selecting one of each of the following components: available indicators (STEP 131 0); an associated urgency and likelihood (STEP 10 1312); an operator (e.g., a Boolean operator or proximity operator) (STEP 1314); and a value (STEP 1316); FIG. 13C is a depiction of a graphical user interface that may be used with the intervention rule building process i.e. rules arranged in order of likelihood status)),
displaying the selected protocol condition object in a protocol sequence window of the graphical user interface ((Buchanan et al., Fig 13B) ( Protocol conditions of if Heart Rate <50, or if Heart Rate >= 6-, or if History of Neurological Fainting/Syncopal Episode – True AND History Cardiovascular Orthostatic Hypertension = False AND Medications Anti-arrhythmic = True i.e. multiple protocol conditions selected and displayed in a sequence on a user interface));
displaying a specific parameter window related to the corresponding parameter requirement for the selected object ((Buchanan et al., Pg. 24, lines 16-18) (The Determine Problems submodule 812 accesses the knowledge base and engages an inference engine in the rule server 402 to display a set of possible problems based on the entered data for the patient));
receiving a specific parameter related to the corresponding parameter requirement within the specific parameter window ((Buchanan et al., Pg. 18, Lines 1-7; pg. 19, lines 1-24) (The preferred embodiment implements an electronic record charting capability which is accessible and updated during the individual contact. Data is preferably recorded using point and click mechanisms (e.g., by means of a mouse) or touch screen technology, and data is presented in graphical menus that are site-configurable));
generating a clinical protocol having a condition as a function of the received specific parameter for the selected protocol condition type ((Buchanan et al., Pg. 18, Lines 1-7; pg. 19, lines 1-24) (The software facilitates real-time decision support by utilizing the expert knowledge base 408 to identify individual problems, desired outcomes, and recommended interventions. The user is automatically alerted when critical conditions exist)).
RE: Claim 11 Buchanan et al. teaches the claimed:
11. The method as defined by claim 10, wherein the plurality of different protocol condition objects include a rate based object, a measurement based object, and an event based object ((Buchanan et al., Fig 3C, 13B) (Patient Problem Rules e.g. (Labs WNL (MB > 4% or CtNt >= 0.19 ng/mL) i.e. rate based object; Problem rules build includes heart rate above or below a value i.e. measurement based object; Problem rules build includes Fainting/Syncopal Episode/Anti-arrhythmic medication i.e. an event based object)).
RE: Claim 12 Buchanan et al. teaches the claimed:
12. The method as defined by claim 10, further comprising selecting a second protocol condition object from the graphical user interface, the second protocol condition object being different from the first protocol condition object; displaying the second selected protocol condition object with the first selected protocol condition object in the protocol sequence window of the graphical user interface ((Buchanan et al., Fig 13B) ( Protocol conditions of if Heart Rate <50, or if Heart Rate >= 6-, or if History of Neurological Fainting/Syncopal Episode – True AND History Cardiovascular Orthostatic Hypertension = False AND Medications Anti-arrhythmic = True i.e. multiple protocol conditions selected and displayed in a sequence on a user interface)).
RE: Claim 13 Buchanan et al. teaches the claimed:
13. The method as defined by claim 12, further comprising: displaying a second specific parameter window related to the corresponding parameter requirement for the second selected object; receiving a specific parameter related to the corresponding parameter requirement within the second specific parameter window; generating a clinical protocol having conditions as a function of the received specific parameters for the first and the second selected protocol condition types ((Buchanan et al., Pg. 18, Lines 1-7; pg. 19, lines 1-24; Pg. 24, lines 16-18) (The Determine Problems submodule 812 accesses the knowledge base and engages an inference engine in the rule server 402 to display a set of possible problems based on the entered data for the patient; The preferred embodiment implements an electronic record charting capability which is accessible and updated during the individual contact. Data is preferably recorded using point and click mechanisms (e.g., by means of a mouse) or touch screen technology, and data is presented in graphical menus that are site-configurable; The software facilitates real-time decision support by utilizing the expert knowledge base 408 to identify individual problems, desired outcomes, and recommended interventions. The user is automatically alerted when critical conditions exist)).
RE: Claim 14 Buchanan et al. teaches the claimed:
14. The method as defined by claim 10, wherein the condition is an eligibility condition or a compliance condition for the protocol ((Buchanan et al., Fig 3C, 13B) (Patient Problem Rules e.g. (Labs WNL (MB > 4% or CtNt >= 0.19 ng/mL) i.e. rate based object; Problem rules build includes heart rate above or below a value i.e. measurement based object; Problem rules build includes Fainting/Syncopal Episode/Anti-arrhythmic medication i.e. an event based object)).
RE: Claim 15 Buchanan et al. teaches the claimed:
15. The method as defined by claim 10, further comprising selecting a plurality protocol condition objects from the graphical user interface ((Buchanan et al., Pg. 28, Lines 8-10; Pg. 29, lines 27-28; Pg. 30, lines 7-11) (The user then chooses whether to enter a new rule (STEP 1112) or to select an existing rule from a list, 10 preferably presented on a pull down menu (STEP 1114); If a new problem rule is being built or if an existing problem rule is being modified, the user may build the rule in any order by sequentially selecting one of each of the following components: available indicators (STEP 131 0); an associated urgency and likelihood (STEP 10 1312); an operator (e.g., a Boolean operator or proximity operator) (STEP 1314); and a value (STEP 1316); FIG. 13C is a depiction of a graphical user interface that may be used with the intervention rule building process i.e. rules arranged in order of likelihood status)).
RE: Claim 16 Buchanan et al. teaches the claimed:
16. The method as defined by claim 15, wherein the plurality of protocol condition objects are rearrangeable in the protocol sequence window, and the plurality of protocol condition objects are logically linkable using and/or statements ((Buchanan et al., Pg. 30, Lines 18-28) (In the preferred embodiment, an indicator is selected by dragging and dropping the indicator on a rule building block 1350 (FIG. 13B). The urgency status may be selected from a spin control, list box, or a pull down menu which includes, for example, "non-urgent", "immediate", and "stat". The likelihood status may be selected from a spin control, list box, or a pull down menu which includes, for example, "potential", "possible", "probable", "confirmed", and "ruled out". In the preferred embodiment, a button tool bar 1352 which is used for boolean logic operations is presented on the screen. Clicking on one of the operators moves that operator to the rule building block 1350. A value may also be entered in the rule building block directly through keyboard operation. FIGS. 13C and 13D show a similar graphical user interface tailored for the inputs required to build intervention rules and outcome rules, respectively)).
RE: Claim 17 Buchanan et al. teaches the claimed:
17. The method as defined by claim 10, further comprising displaying the generated protocol in a patient display ((Buchanan et al., Pg. 16, Lines 27-29; pg. 20, lines 14-20) (In general, when a patient's chart is opened, the preferred embodiment of the invention invokes an initialization process which provides access to the knowledge base and patient database; the system retrieves the individual patient information from the patient database 406 and the chart is opened. In the preferred embodiment, the user is then presented with a new graphical interface. FIG. 7C is a depiction of a graphical user interface that may be used to display a patient's chart information in accordance with one embodiment of the invention. In particular, information about the patient may be shown in windows that allow for the charting of vital sign measurements, medical history, Patient Problems, Physical Exam, and Labs/Diagnostic Tests)).
RE: Claim 18 Buchanan et al. teaches the claimed:
18. The method as defined by claim 17, further comprising collecting data from a patient relating to the generated protocol and displaying data relevant to the generated protocol in the patient display ((Buchanan et al., Pg. 16, Lines 27-29; pg. 20, lines 14-20; ; Pg. 18, Lines 1-7; pg. 19, lines 1-24) (In general, when a patient's chart is opened, the preferred embodiment of the invention invokes an initialization process which provides access to the knowledge base and patient database; the system retrieves the individual patient information from the patient database 406 and the chart is opened. In the preferred embodiment, the user is then presented with a new graphical interface. FIG. 7C is a depiction of a graphical user interface that may be used to display a patient's chart information in accordance with one embodiment of the invention. In particular, information about the patient may be shown in windows that allow for the charting of vital sign measurements, medical history, Patient Problems, Physical Exam, and Labs/Diagnostic Tests; The preferred embodiment implements an electronic record charting capability which is accessible and updated during the individual contact. Data is preferably recorded using point and click mechanisms (e.g., by means of a mouse) or touch screen technology, and data is presented in graphical menus that are site-configurable)).
RE: Claim 19 Buchanan et al. teaches the claimed:
19. The method as defined by claim 10, wherein the eligibility condition is a parent base condition ((Buchanan et al., Pg. 28, Lines 1-5) (FIG. 11B is a depiction of a graphical user interface that may be used to begin the rule making process. If a problem is selected (STEP 1102), the user enters the name of the problem the user wishes to create, and an identification for a parent module which includes the broad medical discipline pertaining to the problem (STEP 1104) i.e. selected from a list of condition types such as cardiology, ontology, or all)).
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-9 are rejected under 35 U.S.C. 103 as being unpatentable over W.O. 00/42487 (hereinafter “Buchanan et al.”) in view of U.S. 2020/0327996 A1 (hereinafter “Barkol et al.”).
RE: Claim 1 Buchanan et al. teaches the claimed:
1. A computer-implemented method for creating a clinical decision support application, the method comprising: providing an interface configured to receive ((Buchanan et al., Pg. 9, lines 7-12) (The preferred embodiment of the invention includes an object oriented software tool which greatly improves the speed with which protocols can be encapsulated and maintained. The tool provides a graphical user interface and "point-and-click" capabilities to allow a non-programmer to define, modify, add, store and utilize new protocols, thereby adapting the system to a changing medical infrastructure as new practice guidelines are invoked)):
a protocol eligibility condition by selecting one or more eligibility condition objects from an available list within a configuration graphical user interface, each eligibility condition object associated with at least one corresponding condition type, and each type configurable with specific parameters ((Buchanan et al., Pg. 28, Lines 1-5) (FIG. 11B is a depiction of a graphical user interface that may be used to begin the rule making process. If a problem is selected (STEP 1102), the user enters the name of the problem the user wishes to create, and an identification for a parent module which includes the broad medical discipline pertaining to the problem (STEP 1104) i.e. selected from a list of condition types such as cardiology, ontology, or all));
a protocol compliance condition by selecting one or more compliance condition objects from an available list within the configuration graphical user interface, each compliance condition object related to a patient parameter, selecting the thresholds within which compliance is achieved for each patient related parameter, and arranging the patient related parameters by an order in which to display them in an active graphical user interface ((Buchanan et al., Pg. 28, Lines 8-10; Pg. 29, lines 27-28; Pg. 30, lines 7-11) (The user then chooses whether to enter a new rule (STEP 1112) or to select an existing rule from a list, 10 preferably presented on a pull down menu (STEP 1114); If a new problem rule is being built or if an existing problem rule is being modified, the user may build the rule in any order by sequentially selecting one of each of the following components: available indicators (STEP 131 0); an associated urgency and likelihood (STEP 10 1312); an operator (e.g., a Boolean operator or proximity operator) (STEP 1314); and a value (STEP 1316); FIG. 13C is a depiction of a graphical user interface that may be used with
the intervention rule building process i.e. rules arranged in order of likelihood status)), and
generating an executable clinical decision support application code as a function of the eligibility condition, compliance condition, and notification condition ((Buchanan et al., Pg. 14, Lines 18-20) (The preferred protocol building tool 308 allows a user to interactively add rules to the knowledge database without requiring a software engineer to write, debug, and integrate new code into a new system)).
Buchanan et al. fails to explicitly teach, but Barkol et al. teaches the claimed:
a list of notification conditions by selecting from a list of specific notification types under which a user of the clinical decision support application will be notified and associating each notification type with a plurality of user roles ((Barkol et al., [0110]-[0112], [0114]) (a notification settings page presents various information relating to notifications to a user of a display device including a button that may present information relating to the different notification levels (e.g. none, low, medium, high) with a notification preference (display, color, haptic and/or audio, etc.); some or all notification settings based on the healthcare role provided by the user))
One of ordinary skill in the art at the time of the effective filing date would have found it obvious to combine the notification settings and preferences set for different healthcare users based on their healthcare role, notification type, and notification importance level as taught by Barkol et al. within the expert system for real-time decision support with an interactive tool which enables users to incorporate or modify decision rules within the system without writing computer code as taught by Buchanan et al. with the motivation of ensuring a rapid response should a patient's condition deteriorate, near-continuous monitoring of the output from the multiple monitoring devices may be necessary (Barkol et al., [0002]).
RE: Claim 2 Buchanan et al and Barkol et al. teach the claimed:
2. The method as defined by claim 1, wherein the plurality of eligibility condition objects includes a rate based object, a measurement based object, and an event based object ((Buchanan et al., Fig 3C, 13B) (Patient Problem Rules e.g. (Labs WNL (MB > 4% or CtNt >= 0.19 ng/mL) i.e. rate based object; Problem rules build includes heart rate above or below a value i.e. measurement based object; Problem rules build includes Fainting/Syncopal Episode/Anti-arrhythmic medication i.e. an event based object)).
RE: Claim 3 Buchanan et al and Barkol et al. teach the claimed:
3. The method as defined by claim 1, wherein the plurality of compliance condition objects includes a rate based object, a measurement based object, and an event based object ((Buchanan et al., Fig 3C, 13B; Pg. 28, Lines 8-10; Pg. 29, lines 27-28; Pg. 30, lines 7-11) (Patient Problem Rules e.g. (Labs WNL (MB > 4% or CtNt >= 0.19 ng/mL) i.e. rate based object; Problem rules build includes heart rate above or below a value i.e. measurement based object; Problem rules build includes Fainting/Syncopal Episode/Anti-arrhythmic medication i.e. an event based object; The user then chooses whether to enter a new rule (STEP 1112) or to select an existing rule from a list, 10 preferably presented on a pull down menu (STEP 1114); If a new problem rule is being built or if an existing problem rule is being modified, the user may build the rule in any order by sequentially selecting one of each of the following components: available indicators (STEP 131 0); an associated urgency and likelihood (STEP 10 1312); an operator (e.g., a Boolean operator or proximity operator) (STEP 1314); and a value (STEP 1316); FIG. 13C is a depiction of a graphical user interface that may be used with the intervention rule building process i.e. rules arranged in order of likelihood status)).
RE: Claim 4 Buchanan et al and Barkol et al. teach the claimed:
4. The method as defined by claim 1, further comprising: selecting a second protocol condition object from the configuration graphical user interface, the second protocol condition object being different from the first protocol condition object; displaying the second selected protocol condition object with the first selected protocol condition object in the protocol sequence window of the graphical user interface ((Buchanan et al., Fig 13B) ( Protocol conditions of if Heart Rate <50, or if Heart Rate >= 6-, or if History of Neurological Fainting/Syncopal Episode – True AND History Cardiovascular Orthostatic Hypertension = False AND Medications Anti-arrhythmic = True i.e. multiple protocol conditions selected and displayed in a sequence on a user interface)).
RE: Claim 5 Buchanan et al and Barkol et al. teach the claimed:
5. The method as defined by claim 4, further comprising: displaying a second specific parameter window related to the corresponding parameter requirement for the second selected object; receiving a specific parameter related to the corresponding parameter requirement within the second specific parameter window; generating a clinical protocol having conditions as a function of the received specific parameters for the first and the second selected protocol condition types ((Buchanan et al., Pg. 18, Lines 1-7; pg. 19, lines 1-24; Pg. 24, lines 16-18) (The Determine Problems submodule 812 accesses the knowledge base and engages an inference engine in the rule server 402 to display a set of possible problems based on the entered data for the patient; The preferred embodiment implements an electronic record charting capability which is accessible and updated during the individual contact. Data is preferably recorded using point and click mechanisms (e.g., by means of a mouse) or touch screen technology, and data is presented in graphical menus that are site-configurable; The software facilitates real-time decision support by utilizing the expert knowledge base 408 to identify individual problems, desired outcomes, and recommended interventions. The user is automatically alerted when critical conditions exist)).
RE: Claim 6 Buchanan et al and Barkol et al. teach the claimed:
6. The method as defined by claim 1, wherein the condition is an eligibility condition or a compliance condition for the protocol ((Buchanan et al., Fig 3C, 13B) (Patient Problem Rules e.g. (Labs WNL (MB > 4% or CtNt >= 0.19 ng/mL) i.e. rate based object; Problem rules build includes heart rate above or below a value i.e. measurement based object; Problem rules build includes Fainting/Syncopal Episode/Anti-arrhythmic medication i.e. an event based object)).
RE: Claim 7 Buchanan et al and Barkol et al. teach the claimed:
7. The method as defined by claim 1, further comprising selecting a plurality protocol condition objects from the graphical user interface ((Buchanan et al., Pg. 28, Lines 8-10; Pg. 29, lines 27-28; Pg. 30, lines 7-11) (The user then chooses whether to enter a new rule (STEP 1112) or to select an existing rule from a list, 10 preferably presented on a pull down menu (STEP 1114); If a new problem rule is being built or if an existing problem rule is being modified, the user may build the rule in any order by sequentially selecting one of each of the following components: available indicators (STEP 131 0); an associated urgency and likelihood (STEP 10 1312); an operator (e.g., a Boolean operator or proximity operator) (STEP 1314); and a value (STEP 1316); FIG. 13C is a depiction of a graphical user interface that may be used with the intervention rule building process i.e. rules arranged in order of likelihood status)).
RE: Claim 8 Buchanan et al and Barkol et al. teach the claimed:
8. The method as defined by claim 7, wherein the plurality of protocol condition objects are rearrangeable in the protocol sequence window, and the plurality of protocol condition objects are logically linkable using and/or statements ((Buchanan et al., Pg. 30, Lines 18-28) (In the preferred embodiment, an indicator is selected by dragging and dropping the indicator on a rule building block 1350 (FIG. 13B). The urgency status may be selected from a spin control, list box, or a pull down menu which includes, for example, "non-urgent", "immediate", and "stat". The likelihood status may be selected from a spin control, list box, or a pull down menu which includes, for example, "potential", "possible", "probable", "confirmed", and "ruled out". In the preferred embodiment, a button tool bar 1352 which is used for boolean logic operations is presented on the screen. Clicking on one of the operators moves that operator to the rule building block 1350. A value may also be entered in the rule building block directly through keyboard operation. FIGS. 13C and 13D show a similar graphical user interface tailored for the inputs required to build intervention rules and outcome rules, respectively)).
RE: Claim 9 Buchanan et al and Barkol et al. teach the claimed:
9. The method as defined by claim 1, further comprising displaying the generated protocol in an active user interface ((Buchanan et al., Pg. 18, Lines 1-7; pg. 19, lines 1-24; Pg. 24, Lines 16-18) (The software facilitates real-time decision support by utilizing the expert knowledge base 408 to identify individual problems, desired outcomes, and recommended interventions. The user is automatically alerted when critical conditions exist; The Determine Problems submodule 812 accesses the knowledge base 408 and engages an inference engine in the rule server 402 to display a set of possible problems based on the entered data for the patient)).
Claims 20-24 are rejected under 35 U.S.C. 103 as being unpatentable over W.O. 00/42487 (hereinafter “Buchanan et al.”) in view of U.S. 2011/0055720 A1 (hereinafter “Potter et al.”).
RE: Claim 20 Buchanan et al. teaches the claimed:
20. A computer-implemented system for creating a medical protocol, the system comprising: a conditions library containing graphically selectable eligibility objects and graphically selectable compliance objects relating to a medical protocol ((Buchanan et al., Pg. 9, lines 7-12; Pg. 18, Lines 1-7; pg. 19, lines 1-24; Pg. 24, lines 16-18) (The Determine Problems submodule 812 accesses the knowledge base and engages an inference engine in the rule server 402 to display a set of possible problems based on the entered data for the patient; The preferred embodiment implements an electronic record charting capability which is accessible and updated during the individual contact. Data is preferably recorded using point and click mechanisms (e.g., by means of a mouse) or touch screen technology, and data is presented in graphical menus that are site-configurable; The preferred embodiment of the invention includes an object oriented software tool which greatly improves the speed with which protocols can be encapsulated and maintained. The tool provides a graphical user interface and "point-and-click" capabilities to allow a non-programmer to define, modify, add, store and utilize new protocols, thereby adapting the system to a changing medical infrastructure as new practice guidelines are invoked)):
[…], the user interface configured to display the graphically selectable eligibility objects and graphically selectable compliance objects, the user interface further configured to display a sequence window in which the graphically selectable eligibility objects may be moved to define an eligibility rule for the protocol, and in which the graphically selectable compliance objects may be moved to define a compliance rule for the protocol ((Buchanan et al., Pg. 30, Lines 18-28) (In the preferred embodiment, an indicator is selected by dragging and dropping the indicator on a rule building block 1350 (FIG. 13B). The urgency status may be selected from a spin control, list box, or a pull down menu which includes, for example, "non-urgent", "immediate", and "stat". The likelihood status may be selected from a spin control, list box, or a pull down menu which includes, for example, "potential", "possible", "probable", "confirmed", and "ruled out". In the preferred embodiment, a button tool bar 1352 which is used for boolean logic operations is presented on the screen. Clicking on one of the operators moves that operator to the rule building block 1350. A value may also be entered in the rule building block directly through keyboard operation. FIGS. 13C and 13D show a similar graphical user interface tailored for the inputs required to build intervention rules and outcome rules, respectively)).
Buchanan et al. fails to explicitly teach, but Potter et al. teaches the claimed:
a graphic compiler generating a user interface ((Potter et al., [0071]) (Such composition may alternatively be or additionally be composed using a graphical compiler in which models, maps, or graphical depictions of the therapeutic wellness device may be manipulated to assemble the desired therapy program or sequence. Such therapy programs or sequences may also be defined by a user commanding the therapeutic wellness device to assume the various configurations and activities in a time sequence and simultaneously "recording" or "capturing" such sequence for retention and sharing or later use)).
One of ordinary skill in the art at the time of the effective filing date would have found it obvious to combine the graphic compiler for manipulable for assembling a desired therapy program or sequence of a therapeutic wellness device as taught by Potter et al. within the expert system for real-time decision support with an interactive tool which enables users to incorporate or modify decision rules within the system without writing computer code as taught by Buchanan et al. with the motivation of graphically interacting with a user to allow greater flexibility and portability in managing and administering therapeutic operations (Potter et al., [0002], [0003]).
RE: Claim 21 Buchanan et al. and Potter et al. teach the claimed:
21. The method as defined by claim 20, further comprising a reporting module configured to provide reports to medical practitioners ((Buchanan et al., Pg. 8, Lines 20-27) (The preferred embodiment of the invention prompts the physician to order these treatments and tests, then records the results of these tests and changes in clinical condition brought about by treatment, and then refines the diagnosis as a result of this additional information. Finally, the invention makes a tentative final recommended diagnosis and suggests the appropriate treatment, including patient disposition, medications, schedules, and follow-up care, and creates detailed patient specific aftercare instructions. All these items can be verified by the health care provider)).
RE: Claim 22 Buchanan et al. and Potter et al. teach the claimed:
22. The method as defined by claim 20, wherein the reports the reports are configured using the graphical compiler and graphical reporting objects ((Buchanan et al., Pg. 8, Lines 20-27; Pg. 18, Lines 1-7; pg. 19, lines 1-24) (The preferred embodiment of the invention prompts the physician to order these treatments and tests, then records the results of these tests and changes in clinical condition brought about by treatment, and then refines the diagnosis as a result of this additional information. Finally, the invention makes a tentative final recommended diagnosis and suggests the appropriate treatment, including patient disposition, medications, schedules, and follow-up care, and creates detailed patient specific aftercare instructions. All these items can be verified by the health care provider; The preferred embodiment implements an electronic record charting capability which is accessible and updated during the individual contact. Data is preferably recorded using point and click mechanisms (e.g., by means of a mouse) or touch screen technology, and data is presented in graphical menus that are site-configurable)).
RE: Claim 23 Buchanan et al. and Potter et al. teach the claimed:
23. The method as defined by claim 20, wherein the graphical reporting objects include graphical objects for counting clicks by medical staff in the interface, counting 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 ((Buchanan et al., Pg. 8, Lines 8-11; pg. 10, lines 21-25) (The invention is a comprehensive decision support system providing support for individual assessment, identifying individual problems and desired outcomes, recommending interventions and appropriate diagnostic tests and treatment, and reassessing to determine actual outcomes; Finally, the system measures the actual outcome by guiding a practitioner through the process during recurring visits to the practitioner, with the actual outcome data possibly affecting the other steps in the process as the patient's condition changes. In the preferred embodiment, an actual outcome module 122 provides a GUI that guides the practitioner through a desired set of questions drawn from an evaluation knowledge base 124)).
RE: Claim 24 Buchanan et al. and Potter et al. teach the claimed:
24. The method as defined by claim 20, further comprising an event detector configured to parse the patient data to automatically detect a patient event ((Buchanan et al., Pg. 18, Lines 1-7; pg. 19, lines 1-24) (The software facilitates real-time decision support by utilizing the expert knowledge base 408 to identify individual problems, desired outcomes, and recommended interventions. The user is automatically alerted when critical conditions exist)).
Claim 25 is rejected under 35 U.S.C. 103 as being unpatentable over W.O. 00/42487 (hereinafter “Buchanan et al.”) in view of U.S. 2011/0055720 A1 (hereinafter “Potter et al.”), and further in view of U.S. 2017/0354382 A1 (hereinafter “Fauss et al.”).
RE: Claim 25 Buchanan et al. and Potter et al. teach the claimed:
25. The method as defined by claim 20,
Buchanan et al. fails to explicitly teach, but Potter et al. teaches the claimed:
wherein the detected patient event may include extubation, reintubation, length of extubation, extubation failure detection, cardiac arrest detection, vasoactive weaning detection, acute kidney injury detection, and/or time at which any of the aforementioned events occurred (([0021]) (The system described herein allows clinicians to monitor and alert a care provider in real-time to the patient's risk of a critical deterioration (i.e. heart attack) in patients with parallel circulation physiology)).
One of ordinary skill in the art at the time of the effective filing date would have found it obvious to combine the system for monitoring and alerting in real-time a patient’s risk of a heart attack as taught by Fauss et al. within the expert system for real-time decision support with an interactive tool which enables users to incorporate or modify decision rules within the system without writing computer code as taught by Buchanan et al. and the graphic compiler for manipulable for assembling a desired therapy program or sequence of a therapeutic wellness device as taught by Potter et al. with the motivation of measuring of risk to detect deterioration of patients in clinical practice with rare congenital heart defect (Fauss et al., [0002]=[0003]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20200185092 A1 teaches real-time data derived from a plurality of data sources for supporting user-definable rules and providing user notifications for providing user notifications and smart alarms (Abstract);
US 20180181720 A1 teaches methods and systems for assigning clinical goals, care plans, and/or care pathways (Abstract);
US 20170177819 A1 teaches a real-time medical communication system for sending notifications of medical alerts (Abstract); and
US 20090132580 A1 teaches utilizing a user interface to design a workflow for a clinical protocol ([0028], [0033]).
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