DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
The examiner acknowledges the present application claims priority to PCT/US2022/053722 with Provisional Application 63/293,620, filed 12/23/2021.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 9/10/2024, 11/7/2025, 2/3/2026 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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(s) 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(s) is/are: “graphical data module” in claims 1, 6, 7, 12, 18, 19. “Processing module” in claims 1, 12. “Additional data module” in claim 3. “New data module” in claim 14. The following is an analysis of the three-prong test for each of the limitations. Thus, the claimed limitations invoke 112(f) interpretation.
“graphical data module” is a term used as a substitute for "means," and are generic placeholders for performing the claimed functions of "configured to receive a configuration parameter." “Processing module” is a term used as a substitute for "means," and are generic placeholders for performing the claimed functions of "configured to receive." “Additional data module” is a term used as a substitute for "means," and are generic placeholders for performing the claimed functions of "configured to display the received data." “New data module” is a term used as a substitute for "means," and are generic placeholders for performing the claimed functions of "configured to display the received data."
The generic placeholder "graphical data module " is modified by functional language: "configured to receive a configuration parameter." The generic placeholder "Processing module" is modified by functional language: "configured to receive." The generic placeholder "Additional data module" is modified by functional language: "configured to display the received data." The generic placeholder "New data module" is modified by functional language: "configured to display the received data."
The generic place holder " graphical data module " is not modified by sufficient structure, performing the claimed function. There is no hardware described in the claims that perform the feature of " configured to receive a configuration parameter." The generic place holder "Processing module " is not modified by sufficient structure, performing the claimed function. There is no hardware described in the claims that perform the feature of "configured to receive." The generic place holder "Additional data module " is not modified by sufficient structure, performing the claimed function. There is no hardware described in the claims that perform the feature of " configured to display the received data." The generic place holder "New data module " is not modified by sufficient structure, performing the claimed function. There is no hardware described in the claims that perform the feature of "configured to display the received data."
Because this/these claim limitation(s) is/are 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/these limitation(s) 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/them 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.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-24 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 limitation(s) “graphical data module” and “Processing module” and “Additional data module” and “New data module” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The disclosure is devoid of any structure that performs the functions in the above limitations. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claims 2-11 are dependent claims, and inherit the 35 U.S.C. §112(b) rejections from independent claim 1.
Claims 13-24 are dependent claims, and inherit the 35 U.S.C. §112(b) rejections from independent claim 12.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-24 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. “Graphical data module [0071-0072], Processing module [0050], Additional data module [0083], and New data module [0077]” are described in the disclosure for their function, but are not described in their structure. One skilled in the arts is unable to determine what these units are made of, and whether they are hardware, etc.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-20, and 22-24 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Handler, Patent Application Publication Number US 20190122764 A1 (hereinafter “Handler”).
Claim 1: Handler teaches “An infusion control device (i.e. bedside brain is configured to execute a therapeutic control rule… and control therapeutic devices [Handler 0006]… medical therapy devices includes at least one of an infusion pump [Handler 0008]), comprising:
a non-transitory machine-readable memory; and
a processor operably connected to a display and the memory (i.e. Bedside brain 100 includes a memory… includes one or more processors, capable of executing instructions in communication with the memory [Handler 0048]), the processor configured to:
provide a user interface to the display (i.e. Bedside brain 100 may include an operator interface (e.g., a touchscreen, a physical mouse/keyboard, etc.) [Handler 0057, Fig. 2-23]);
prompt, via the user interface, a user to select a therapy (i.e. FIG. 6B illustrates that a “Lactated Ringers” infusion therapy has been selected by the user [Handler 0064, Fig. 5, 6B] note: Fig. 5 shows “Hypovolemia” selected in the UI);
receive a selected therapy from the user interface (i.e. FIG. 6B illustrates that a “Lactated Ringers” infusion therapy has been selected by the user [Handler 0064, Fig. 5, 6B] note: Fig. 5 shows “Hypovolemia” selected in the UI);
based on receiving the selected therapy:
confirm that one or more sensor devices required for the selected therapy are operably connected to the infusion control device (i.e. Bedside brain 100 may further display required devices, such as patient therapy devices 106A-B and/or patient monitoring devices 108A-B. With the “Hypovolemia” protocol, bedside brain requires an infusion pump or syringe pump, with either saline or lactated ringers as the delivered therapy. Bedside brain 100 also indicates that the required therapy device is not detected (e.g., “None detected”). Bedside brain 100 will not active the “Hypovolemia” protocol, until the required device is detected and configured appropriately [Handler 0063, Fig. 5]… Patient monitoring devices 108A-B may include any patient monitor and/or physiological sensor [Handler 0054]);
confirm that one or more intravenous infusion devices are operably connected to the infusion control device (i.e. Bedside brain 100 may further display required devices, such as patient therapy devices 106A-B and/or patient monitoring devices 108A-B. With the “Hypovolemia” protocol, bedside brain requires an infusion pump or syringe pump, with either saline or lactated ringers as the delivered therapy. Bedside brain 100 also indicates that the required therapy device is not detected (e.g., “None detected”). Bedside brain 100 will not active the “Hypovolemia” protocol, until the required device is detected and configured appropriately [Handler 0063, Fig. 5]… Patient therapy devices 106A-B may include infusion pumps… or any other pump capable of delivering an intravenous therapy [Handler 0053]) and that the one or more intravenous infusion devices are controllable based on information derivable from the sensor devices (i.e. each therapeutic device 106A-B may be individually compatible with the bedside brain 100… upon connection… between a therapeutic device 106A-B and the bedside brain 100, a handshaking occurs between the bedside brain 100 and the therapeutic device 106A-B. In an embodiment, handshaking includes identification, by the therapeutic device 106A-B: (1) that it is a therapeutic device, (2) what kind of device it is, (3) what non-therapeutic actions it can take, and (4) what therapeutic actions it can take… [Handler 0099, Fig. 5, 7] note: Handler Fig. 5, 7 shows a volume sensor and a pump device. The check mark indicates a successful handshake connection to a controllable sensor and pump) (i.e. bedside brain 100 receives a monitor failure indication (e.g., ECG lead failure indication)… and modifies the therapy (if needed) to maintain patient safety [Handler 0086]);
download a first algorithm, the first algorithm configured to operate the one or more intravenous infusion devices based on real-time sensor data received from the one or more sensor devices (i.e. the protocol execution module receives the plurality of protocols from an external server [Handler 0010]… bedside brain server 102 provides information, as required by the bedside brain 100, such as specific rule protocols [Handler 0051]… bedside brain 100 receives a monitor failure indication (e.g., ECG lead failure indication)… and modifies the therapy (if needed) to maintain patient safety [Handler 0086, Fig. 12] note: Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL”);
select one or more graphical data modules particular to the selected therapy for display within the user interface based on a type of the one or more sensor devices and the selected therapy (Handler Fig. 12 shows a configuration GUI as graphical data, for Hypovolemia as a selected therapy. Fig. 7 shows that selected therapy Hypovolemia uses a sensor type “PIVA.”), wherein each selected graphical data module is associated with and configured to receive sensor data from a respective sensor device of the sensor devices and provide the sensor data to a processing module (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL”), wherein at least one of the respective graphical data modules is configured to receive a configuration parameter associated with operation of a first infusion device of the one or more intravenous infusion devices (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL” and 3. Volume of rehydration fluid (in mL) to bolus if severely hypovolemic: 250 mL.” The infusion pump will dispense these volumes of medicine); and
dynamically reconfigure the user interface to display, within the user interface, a default organization of the selected one or more graphical data modules based on the first algorithm (Handler Fig. 12 reconfigures the UI to display a left bar with “Hypovolemia” selected graphic, and a “Summary” screen template);
operably connect the infusion control device to the first infusion device, the infusion control device being physically distinct from the one or more intravenous infusion devices (i.e. upon connection (e.g., via hard-wire) between a therapeutic device 106A-B and the bedside brain 100 [Handler 0099, Fig. 1 element 100 is separate from element 106A and 108A]);
receive, via the at least one respective graphical data module, the configuration parameter (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL” and 3. Volume of rehydration fluid (in mL) to bolus if severely hypovolemic: 250 mL.” The pencil icon indicates that the volume of medicine can be input and/or edited); and
control the first infusion device based on the sensor data received by the processing module from the selected one or more graphical data modules, the first algorithm, and the received configuration parameter (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL” and 3. Volume of rehydration fluid (in mL) to bolus if severely hypovolemic: 250 mL.” The pencil icon indicates that the volume of medicine can be input and/or edited. This input (configuration parameter) also programs, or controls (algorithm) the pump (infusion device) based on when to rehydrate (based on the sensor) for hypovolemia (selected graphical data module).”
Claim 2: Handler teaches “The infusion control device of Claim 1, wherein the first algorithm is configured to operate the first infusion device in a closed-loop mode (Handler protocol in Fig. 7, 8, and 12 is/are executed in a closed-loop mode once it is configured. See "auto-execute therapy safety action" in fig. 8 and "potential safety action" in fig. 7) based on the real-time data received from the one or more sensor devices (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL”), wherein controlling the first infusion device comprises:
controlling the first infusion device in the closed-loop mode based on the real-time data received from the one or more sensor devices, the downloaded first algorithm, and the received configuration parameter (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL” and 3. Volume of rehydration fluid (in mL) to bolus if severely hypovolemic: 250 mL.” The pencil icon indicates that the volume of medicine can be input and/or edited. This input (configuration parameter) also programs, or controls (algorithm) the pump (infusion device) based on when to rehydrate (based on the sensor) for hypovolemia (selected graphical data module).”
Claim 3: Handler teaches “The infusion control device of Claim 2, wherein the processor is further configured to:
detect an additional sensor operably connected to the control device (i.e. patient monitoring devices includes at least one of a heart rate sensor, a temperature sensor, a pulse oximetry sensor, a patient weight sensor, a glucose sensor, a respiratory sensor, a blood pressure sensor, a pressure sensor, and a volume-index sensor [Handler 0009, Fig. 1] note: Handler Fig. 1 shows a plurality of Patient monitoring devices 108A-108B);
based on detecting the additional sensor:
download to the control device, from a server, a second algorithm associated with the additional sensor (i.e. Bedside brain 100 is only capable of running protocols that it is aware of (e.g., bedside brain 100 must have stored the rule syntax for the particular protocol). Furthermore, bedside brain 100 is only capable of running protocols for connected… patient monitoring devices 108A-B… If all required system parameters are fulfilled (e.g., patient monitoring device parameters, patient therapy device parameters, etc.), the protocol will be identified in a protocol list by bedside brain 100. Thus, bedside brain 100 provides a listing of only protocols that the bedside brain 100 is capable of running with a given system [Handler 0060] note: only after the devices are confirmed will the protocols [e.g. hypovolemia] appear in the list, and only after they appear in the list, can the protocol configuration be received (e.g. from external server 0010, 0051, 0086). Note2: Handler discloses both confirming devices and then listing the protocols in 0060, as well as listing the protocols and then confirming the devices in Fig. 5 and 7 with a selection of Hypovolemia and “Required Therapeutic Devices ‘InfusionPump or SyringePump…’ = None detected”);
update the user interface to display an additional data module associated with the additional sensor (i.e. Bedside brain 100 is only capable of running protocols that it is aware of (e.g., bedside brain 100 must have stored the rule syntax for the particular protocol). Furthermore, bedside brain 100 is only capable of running protocols for connected… patient monitoring devices 108A-B… If all required system parameters are fulfilled (e.g., patient monitoring device parameters, patient therapy device parameters, etc.), the protocol will be identified in a protocol list by bedside brain 100. Thus, bedside brain 100 provides a listing of only protocols that the bedside brain 100 is capable of running with a given system [Handler 0060] note: protocols that require the additional sensor are now listed in an updated list);
receive data from the additional sensor and displaying the received data via the additional data module (Handler Fig. 3-16 show a plurality of therapies other than hypovolemia that are available for selection. Claim 1 can be repeated for a second therapy that shows on the list when a second sensor is connected) (Handler Fig. 12 shows a configuration GUI as graphical data, for Hypovolemia as a selected therapy. Fig. 7 shows that selected therapy Hypovolemia uses a sensor type “PIVA.” Additional required sensor appears here in the “Required Inputs” section after it is detected and handshake is complete); and
control the first infusion device in the closed-loop mode based on real-time data received from the additional sensor and the one or more sensor devices, the downloaded first and second algorithms, and the received configuration parameter (Handler Fig. 3-16 show a plurality of therapies other than hypovolemia that are available for selection. Claim 1 can be repeated for a second therapy that shows on the list after a second sensor is connected) (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL” and 3. Volume of rehydration fluid (in mL) to bolus if severely hypovolemic: 250 mL.” The pencil icon indicates that the volume of medicine can be input and/or edited. This input (configuration parameter) also programs, or controls (algorithm) the pump (infusion device) based on when to rehydrate (based on the sensor, and for an additional sensor that is detected for a second therapy) for hypovolemia (selected graphical data module) (i.e. the three-channel IV pump has that all three channels hooked up to different medications would emulate three devices and three therapies (e.g., one medication per therapy). In this example, the three-channel IV pump would send three separate handshakes [Handler 0107] note: Handler is capable of multiple distinct therapies/algorithms, including a first and second algorithm).”
Claim 4: Handler teaches “The infusion control device of Claim 1, wherein the processor is further configured to:
receive a third algorithm associated with a first sensor of the one or more sensor devices, the third algorithm configured to operate the first infusion device based on real-time data received from the first sensor;
automatically replace the first algorithm with the third algorithm; and
control the first infusion device based on real-time data received from the one or more sensor devices, the third algorithm and the received configuration parameter (i.e. FIGS. 8 to 12 illustrate the interface of bedside brain 100, while displaying protocol settings… The user can update each of these common settings. For example, FIG. 9 illustrates the user selecting the common setting of auto-execute time. Bedside brain 100 displays a keyboard, such that the user can enter any time as desired (or may select the default time) [Handler 0066-0067, Fig. 8-12]).”
Claim 5: Handler teaches “The infusion control device of Claim 1, wherein the one or more sensor devices comprises a physiological monitor connected to a patient and configured to measure a physiological signal from the patient (i.e. Patient monitoring devices 108A-B may include any patient monitor and/or physiological sensor, such as a heart rate sensor (e.g., an EKG sensor and/or an ECG sensor), a temperature sensor, a pulse oximetry sensor, a patient weight scale, a glucose sensor, a respiratory sensor, a blood pressure sensor, a pressure sensor, or any other sensor [Handler 0054]), and wherein the real-time data includes a measurement value of the physiological signal (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL”), wherein the processor is further configured to:
provide the measurement value to the first algorithm;
receive a parameter for adjusting an operation of the first infusion device from the first algorithm based on providing the measurement value to the first algorithm; and
adjust the operation of the first infusion device based on the received parameter (i.e. FIGS. 8 to 12 illustrate the interface of bedside brain 100, while displaying protocol settings… The user can update each of these common settings [Handler 0066-0067, Fig. 8-12] note: Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL.” The 5mL parameter value is adjustable).”
Claim 6: Handler teaches “The infusion control device of Claim 1, wherein the processor is further configured to, before generating the default organization of the one or more respective graphical data modules:
select the one or more respective graphical data modules from a plurality of predetermined graphical data modules based on the selection of the selected therapy and a type of the one or more sensor devices (Handler Fig. 3-16 show the respective interfaces of the system. In Fig. 3, “hypovolemia” is a graphical data module, from a plurality of protocols in the left sidebar. Hypovolemia is the selected therapy and requires a PIVA sensor in Fig. 5. Thus the “hypovolemia” data module is based on the selected therapy, which is based on the sensor type).”
Claim 7: Handler teaches “The infusion control device of Claim 1, wherein the processor is further configured to:
operably connect the control device to a medical device (i.e. upon connection (e.g., via hard-wire) between a therapeutic device 106A-B and the bedside brain 100 [Handler 0099, Fig. 1 element 100 is separate from element 106A and 108A]);
receive a second selection of a second therapy from the user interface (Handler Fig. 3-16 show a plurality of therapies other than hypovolemia that are available for selection. Claim 1 can be repeated for a second therapy); and
based on receiving the second selection:
confirm that at least one sensor corresponding to the second therapy is operably connected to the control device (Handler Fig. 3-16 show a plurality of therapies other than hypovolemia that are available for selection. Claim 1 can be repeated for a second therapy) (i.e. Bedside brain 100 may further display required devices, such as patient therapy devices 106A-B and/or patient monitoring devices 108A-B. With the “Hypovolemia” protocol, bedside brain requires an infusion pump or syringe pump, with either saline or lactated ringers as the delivered therapy. Bedside brain 100 also indicates that the required therapy device is not detected (e.g., “None detected”). Bedside brain 100 will not active the “Hypovolemia” protocol, until the required device is detected and configured appropriately [Handler 0063, Fig. 5]… Patient monitoring devices 108A-B may include any patient monitor and/or physiological sensor [Handler 0054]);
download, from a server, a second algorithm configured to operate the medical device based on real-time data received from the at least one sensor (Handler Fig. 3-16 show a plurality of therapies other than hypovolemia that are available for selection. Claim 1 can be repeated for a second therapy) (i.e. the protocol execution module receives the plurality of protocols from an external server [Handler 0010]… bedside brain server 102 provides information, as required by the bedside brain 100, such as specific rule protocols [Handler 0051]… bedside brain 100 receives a monitor failure indication (e.g., ECG lead failure indication)… and modifies the therapy (if needed) to maintain patient safety [Handler 0086, Fig. 12] note: Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL”);
display at least one graphical data module associated with receiving data from the at least one sensor (Handler Fig. 3-16 show a plurality of therapies other than hypovolemia that are available for selection. Claim 1 can be repeated for a second therapy) (Handler Fig. 12 shows a configuration GUI as graphical data, for Hypovolemia as a selected therapy. Fig. 7 shows that selected therapy Hypovolemia uses a sensor type “PIVA.”) and with controlling the medical device (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL”); and
control the medical device based on the real-time data received from the at least one sensor and the second algorithm (Handler Fig. 3-16 show a plurality of therapies other than hypovolemia that are available for selection. Claim 1 can be repeated for a second therapy) (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL” and 3. Volume of rehydration fluid (in mL) to bolus if severely hypovolemic: 250 mL.” The pencil icon indicates that the volume of medicine can be input and/or edited. This input (configuration parameter) also programs, or controls (algorithm) the pump (infusion device) based on when to rehydrate (based on the sensor) for hypovolemia (selected graphical data module) while simultaneously controlling the first infusion device (i.e. the three-channel IV pump has that all three channels hooked up to different medications would emulate three devices and three therapies (e.g., one medication per therapy). In this example, the three-channel IV pump would send three separate handshakes [Handler 0107]).”
Claim 8: Handler teaches “The infusion control device of Claim 1, wherein the processor is further configured to:
confirm that the one or more sensor devices are associated with the selected therapy and a type of the first infusion device before downloading the first algorithm and generating the organization within the user interface (i.e. Bedside brain 100 is only capable of running protocols that it is aware of (e.g., bedside brain 100 must have stored the rule syntax for the particular protocol). Furthermore, bedside brain 100 is only capable of running protocols for connected patient therapy devices 106A-B… bedside brain 100 may require that at least one of the connected patient therapy devices 106A-B is an infusion pump, if the protocol action requires the bedside brain 100 to cease patient infusion. If all required system parameters are fulfilled (e.g., patient monitoring device parameters, patient therapy device parameters, etc.), the protocol will be identified in a protocol list by bedside brain 100. Thus, bedside brain 100 provides a listing of only protocols that the bedside brain 100 is capable of running with a given system [Handler 0060] note: only after the devices are confirmed will the protocols [e.g. hypovolemia] appear in the list, and only after they appear in the list, can the protocol configuration be received (e.g. from external server 0010, 0051, 0086). Note2: Handler discloses both confirming devices and then listing the protocols in 0060, as well as listing the protocols and then confirming the devices in Fig. 5 and 7 with a selection of Hypovolemia and “Required Therapeutic Devices ‘InfusionPump or SyringePump…’ = None detected”).”
Claim 9: Handler teaches “The infusion control device of Claim 1, wherein the processor is further configured to:
operably connect the infusion control device to a second infusion device of the one or more intravenous infusion devices, the infusion control device being physically distinct from the second infusion device (Handler Fig. 1 shows control device “Bedside Brain” connected to a plurality of infusion devices “Patent Therapy Device 106A” and “Patient Therapy Device 106B”);
download to the control device, from a server, a second algorithm (Handler Fig. 3-16 show a plurality of therapies other than hypovolemia that are available for selection. Claim 1 can be repeated for a second therapy) (i.e. the protocol execution module receives the plurality of protocols from an external server [Handler 0010]… bedside brain server 102 provides information, as required by the bedside brain 100, such as specific rule protocols [Handler 0051]… bedside brain 100 receives a monitor failure indication (e.g., ECG lead failure indication)… and modifies the therapy (if needed) to maintain patient safety [Handler 0086, Fig. 12] note: Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL”); and
control the second infusion device based on the real-time data received from the one or more sensor devices and the second algorithm (Handler Fig. 3-16 show a plurality of therapies other than hypovolemia that are available for selection. Claim 1 can be repeated for a second therapy) (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL” and 3. Volume of rehydration fluid (in mL) to bolus if severely hypovolemic: 250 mL.” The pencil icon indicates that the volume of medicine can be input and/or edited. This input (configuration parameter) also programs, or controls (algorithm) the pump (infusion device) based on when to rehydrate (based on the sensor) for hypovolemia (selected graphical data module).”
Claim 10: Handler teaches “The infusion control device of Claim 9, wherein the processor is further configured to:
adjust a parameter of the second infusion device based on an alert from the first infusion device (i.e. Therapy devices 106A-B may provide input on device state, or other inputs such as device monitored input parameters. For example, a defibrillator may provide ECG monitored input parameters [Handler 0053, Fig. 1 shows multiple infusion pumps 106A-106B can be used]… a monitor failure indication (e.g., ECG lead failure indication), alerts the clinician, and modifies the therapy (if needed) [Handler 0086] note: output devices can also provide input parameters. Input parameters can trigger alerts. Input parameters can modify a therapy on the connected therapy device. For example a defibrillator of 0035 (as a first therapy device) provides ECG input parameters to a second therapy device. The second therapy device receives an input of an ECG lead failure similar to 0086 from the first therapy device as an alert. The second infusion device modifies the therapy/adjusts a parameter on the second infusion device. It is noted that the example in Handler is an ECG device—Handler categorizes pumps and defibrillators as medical therapy devices in 0008—so an infusion device may also perform similarly).”
Claim 11: Handler teaches “The infusion control device of Claim 1, further comprising the display (Handler Fig. 3-16 show interfaces on a display of an infusion control device).”
Claim 12: Handler teaches “A method of intelligently controlling an intravenous infusion (i.e. bedside brain is configured to execute a therapeutic control rule… and control therapeutic devices [Handler 0006]… medical therapy devices includes at least one of an infusion pump [Handler 0008]), comprising:
receiving an indication that a control device is operably connected to one or more intravenous infusion devices (i.e. Bedside brain 100 may further display required devices, such as patient therapy devices 106A-B and/or patient monitoring devices 108A-B. With the “Hypovolemia” protocol, bedside brain requires an infusion pump or syringe pump, with either saline or lactated ringers as the delivered therapy. Bedside brain 100 also indicates that the required therapy device is not detected (e.g., “None detected”). Bedside brain 100 will not active the “Hypovolemia” protocol, until the required device is detected and configured appropriately [Handler 0063, Fig. 5]… Patient therapy devices 106A-B may include infusion pumps… or any other pump capable of delivering an intravenous therapy [Handler 0053]), the control device being physically distinct from the one or more intravenous infusion devices (i.e. upon connection (e.g., via hard-wire) between a therapeutic device 106A-B and the bedside brain 100 [Handler 0099, Fig. 1 element 100 is separate from element 106A and 108A]);
presenting, for the control device, a user interface configured to provide for selection one or more predetermined therapies (i.e. FIG. 6B illustrates that a “Lactated Ringers” infusion therapy has been selected by the user [Handler 0064, Fig. 5, 6B] note: Fig. 5 shows “Hypovolemia” selected in the UI) associated with the one or more intravenous infusion devices and configured to display one or more graphical data modules based on the selection (i.e. Bedside brain 100 may further display required devices, such as patient therapy devices 106A-B and/or patient monitoring devices 108A-B. With the “Hypovolemia” protocol, bedside brain requires an infusion pump or syringe pump, with either saline or lactated ringers as the delivered therapy. Bedside brain 100 also indicates that the required therapy device is not detected (e.g., “None detected”). Bedside brain 100 will not active the “Hypovolemia” protocol, until the required device is detected and configured appropriately [Handler 0063, Fig. 5]… Patient therapy devices 106A-B may include infusion pumps… or any other pump capable of delivering an intravenous therapy [Handler 0053] note: Handler Fig. 12 shows a configuration GUI as graphical data, for Hypovolemia as a selected therapy);
receiving, at the control device, a selection of a first therapy of the one or more predetermined therapies provided by the user interface (i.e. FIG. 6B illustrates that a “Lactated Ringers” infusion therapy has been selected by the user [Handler 0064, Fig. 5, 6B] note: Fig. 5 shows “Hypovolemia” selected in the UI); and
based on receiving the selection of the first therapy, at the control device:
determining that one or more sensor devices for providing data associated with the selected first therapy are operably connected to the control device (i.e. Bedside brain 100 may further display required devices, such as patient therapy devices 106A-B and/or patient monitoring devices 108A-B. With the “Hypovolemia” protocol, bedside brain requires an infusion pump or syringe pump, with either saline or lactated ringers as the delivered therapy. Bedside brain 100 also indicates that the required therapy device is not detected (e.g., “None detected”). Bedside brain 100 will not active the “Hypovolemia” protocol, until the required device is detected and configured appropriately [Handler 0063, Fig. 5]… Patient monitoring devices 108A-B may include any patient monitor and/or physiological sensor [Handler 0054]);
downloading to the control device, from a server based on determining that the one or more sensor devices are operably connected to the control device, a first algorithm configured to operate the one or more intravenous infusion devices based on real-time data received from the one or more sensor devices (i.e. the protocol execution module receives the plurality of protocols from an external server [Handler 0010]… bedside brain server 102 provides information, as required by the bedside brain 100, such as specific rule protocols [Handler 0051]… bedside brain 100 receives a monitor failure indication (e.g., ECG lead failure indication)… and modifies the therapy (if needed) to maintain patient safety [Handler 0086, Fig. 12] note: Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL”);
select one or more respective graphical data modules particular to the selected first therapy within the user interface based on a type of the one or more sensor devices and the selected therapy (Handler Fig. 12 shows a configuration GUI as graphical data, for Hypovolemia as a selected therapy. Fig. 7 shows that selected therapy Hypovolemia uses a sensor type “PIVA.”), wherein each selected graphical data module is associated with and configured to receive sensor data from a respective sensor device of the sensor devices and provide the sensor data to a processing module (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL”), and at least one of the one or more respective graphical data modules is configured to receive a user input of a configuration parameter associated with operation of the one or more intravenous infusion devices (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL” and 3. Volume of rehydration fluid (in mL) to bolus if severely hypovolemic: 250 mL.” The pencil icon indicates that the volume of medicine can be input and/or edited); and
dynamically reconfiguring the user interface to display, within the user interface, a default organization of the selected one or more graphical data modules based on the first algorithm (Handler Fig. 12 reconfigures the UI to display a left bar with “Hypovolemia” selected graphic, and a “Summary” screen template);
prompting for the configuration parameter;
receiving, via the at least one respective graphical data module, the configuration parameter (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL” and 3. Volume of rehydration fluid (in mL) to bolus if severely hypovolemic: 250 mL.” The pencil icon indicates that the volume of medicine can be input and/or edited); and
controlling the one or more intravenous infusion devices based on the real-time data received by the processing module from the one or graphical data modules, the downloaded first algorithm, and the received configuration parameter (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL” and 3. Volume of rehydration fluid (in mL) to bolus if severely hypovolemic: 250 mL.” The pencil icon indicates that the volume of medicine can be input and/or edited. This input (configuration parameter) also programs, or controls (algorithm) the pump (infusion device) based on when to rehydrate (based on the sensor) for hypovolemia (selected graphical data module).”
Claim 13: Handler teaches “The method of Claim 12, wherein the first algorithm is configured to operate a first infusion device in a closed-loop mode (Handler protocol in Fig. 7, 8, and 12 is/are executed in a closed-loop mode once it is configured. See "auto-execute therapy safety action" in fig. 8 and "potential safety action" in fig. 7) based on the real-time data received from the one or more sensor devices (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL”), wherein controlling the first infusion device comprises:
controlling the first infusion device in the closed-loop mode based on the real-time data received from the one or more sensor devices, the downloaded first algorithm, and the received configuration parameter (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL” and 3. Volume of rehydration fluid (in mL) to bolus if severely hypovolemic: 250 mL.” The pencil icon indicates that the volume of medicine can be input and/or edited. This input (configuration parameter) also programs, or controls (algorithm) the pump (infusion device) based on when to rehydrate (based on the sensor) for hypovolemia (selected graphical data module).”
Claim 14: Handler teaches “The method of Claim 13, further comprising:
detecting a new sensor operably connected to the control device (i.e. patient monitoring devices includes at least one of a heart rate sensor, a temperature sensor, a pulse oximetry sensor, a patient weight sensor, a glucose sensor, a respiratory sensor, a blood pressure sensor, a pressure sensor, and a volume-index sensor [Handler 0009, Fig. 1] note: Handler Fig. 1 shows a plurality of Patient monitoring devices 108A-108B);
based on detecting the new sensor:
downloading to the control device, from the server, a second algorithm associated with the new sensor (i.e. Bedside brain 100 is only capable of running protocols that it is aware of (e.g., bedside brain 100 must have stored the rule syntax for the particular protocol). Furthermore, bedside brain 100 is only capable of running protocols for connected… patient monitoring devices 108A-B… If all required system parameters are fulfilled (e.g., patient monitoring device parameters, patient therapy device parameters, etc.), the protocol will be identified in a protocol list by bedside brain 100. Thus, bedside brain 100 provides a listing of only protocols that the bedside brain 100 is capable of running with a given system [Handler 0060] note: only after the devices are confirmed will the protocols [e.g. hypovolemia] appear in the list, and only after they appear in the list, can the protocol configuration be received (e.g. from external server 0010, 0051, 0086). Note2: Handler discloses both confirming devices and then listing the protocols in 0060, as well as listing the protocols and then confirming the devices in Fig. 5 and 7 with a selection of Hypovolemia and “Required Therapeutic Devices ‘InfusionPump or SyringePump…’ = None detected”);
updating the user interface to display a new data module associated with the new sensor i.e. Bedside brain 100 is only capable of running protocols that it is aware of (e.g., bedside brain 100 must have stored the rule syntax for the particular protocol). Furthermore, bedside brain 100 is only capable of running protocols for connected… patient monitoring devices 108A-B… If all required system parameters are fulfilled (e.g., patient monitoring device parameters, patient therapy device parameters, etc.), the protocol will be identified in a protocol list by bedside brain 100. Thus, bedside brain 100 provides a listing of only protocols that the bedside brain 100 is capable of running with a given system [Handler 0060] note: protocols that require the additional sensor are now listed in an updated list);
receiving data from the new sensor and displaying the received data via the new data module (Handler Fig. 3-16 show a plurality of therapies other than hypovolemia that are available for selection. Claim 1 can be repeated for a second therapy that shows on the list when a second sensor is connected) (Handler Fig. 12 shows a configuration GUI as graphical data, for Hypovolemia as a selected therapy. Fig. 7 shows that selected therapy Hypovolemia uses a sensor type “PIVA.” Additional required sensor appears here in the “Required Inputs” section after it is detected and handshake is complete); and
controlling the first infusion device in the closed-loop mode based on real-time data received from the new sensor and the one or more sensor devices, the downloaded first and second algorithms, and the received configuration parameter (Handler Fig. 3-16 show a plurality of therapies other than hypovolemia that are available for selection. Claim 1 can be repeated for a second therapy that shows on the list after a second sensor is connected) (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL” and 3. Volume of rehydration fluid (in mL) to bolus if severely hypovolemic: 250 mL.” The pencil icon indicates that the volume of medicine can be input and/or edited. This input (configuration parameter) also programs, or controls (algorithm) the pump (infusion device) based on when to rehydrate (based on the sensor, and for an additional sensor that is detected for a second therapy) for hypovolemia (selected graphical data module) (i.e. the three-channel IV pump has that all three channels hooked up to different medications would emulate three devices and three therapies (e.g., one medication per therapy). In this example, the three-channel IV pump would send three separate handshakes [Handler 0107] note: Handler is capable of multiple distinct therapies/algorithms, including a first and second algorithm).”
Claim 15: Handler teaches “The method of Claim 12, further comprising:
confirming that the one or more sensor devices are associated with the first therapy and a type of a first infusion device before downloading the first algorithm and generating the default organization within the user interface (i.e. Bedside brain 100 is only capable of running protocols that it is aware of (e.g., bedside brain 100 must have stored the rule syntax for the particular protocol). Furthermore, bedside brain 100 is only capable of running protocols for connected patient therapy devices 106A-B… bedside brain 100 may require that at least one of the connected patient therapy devices 106A-B is an infusion pump, if the protocol action requires the bedside brain 100 to cease patient infusion. If all required system parameters are fulfilled (e.g., patient monitoring device parameters, patient therapy device parameters, etc.), the protocol will be identified in a protocol list by bedside brain 100. Thus, bedside brain 100 provides a listing of only protocols that the bedside brain 100 is capable of running with a given system [Handler 0060] note: only after the devices are confirmed will the protocols [e.g. hypovolemia] appear in the list, and only after they appear in the list, can the protocol configuration be received (e.g. from external server 0010, 0051, 0086). Note2: Handler discloses both confirming devices and then listing the protocols in 0060, as well as listing the protocols and then confirming the devices in Fig. 5 and 7 with a selection of Hypovolemia and “Required Therapeutic Devices ‘InfusionPump or SyringePump…’ = None detected”).”
Claim 16: Handler teaches “The method of Claim 12, further comprising:
receiving a third algorithm associated with a first sensor of the one or more sensor devices, the third algorithm configured to operate the first infusion device based on real-time data received from the first sensor;
automatically replacing the first algorithm with the third algorithm; and
controlling the first infusion device based on real-time data received from the one or more sensor devices, the third algorithm and the received configuration parameter (i.e. FIGS. 8 to 12 illustrate the interface of bedside brain 100, while displaying protocol settings… The user can update each of these common settings. For example, FIG. 9 illustrates the user selecting the common setting of auto-execute time. Bedside brain 100 displays a keyboard, such that the user can enter any time as desired (or may select the default time) [Handler 0066-0067, Fig. 8-12]).”
Claim 17: Handler teaches “The method of Claim 12, wherein the one or more sensor devices comprises a physiological monitor connected to a patient and configured to measure a physiological signal from the patient (i.e. Patient monitoring devices 108A-B may include any patient monitor and/or physiological sensor, such as a heart rate sensor (e.g., an EKG sensor and/or an ECG sensor), a temperature sensor, a pulse oximetry sensor, a patient weight scale, a glucose sensor, a respiratory sensor, a blood pressure sensor, a pressure sensor, or any other sensor [Handler 0054]), and wherein the real-time data includes a measurement value of the physiological signal (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL”), the method further comprising:
providing the measurement value to the first algorithm;
receiving a parameter for adjusting an operation of the first infusion device from the first algorithm based on providing the measurement value to the first algorithm; and
adjusting the operation of the first infusion device based on the received parameter (i.e. FIGS. 8 to 12 illustrate the interface of bedside brain 100, while displaying protocol settings… The user can update each of these common settings [Handler 0066-0067, Fig. 8-12] note: Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL.” The 5mL parameter value is adjustable).”
Claim 18: Handler teaches “The method of Claim 12, further comprising, before generating the default organization of the one or more respective graphical data modules:
selecting the one or more respective graphical data modules from a plurality of predetermined graphical data modules based on the selection of the first therapy and a type of the one or more sensor devices (Handler Fig. 3-16 show the respective interfaces of the system. In Fig. 3, “hypovolemia” is a graphical data module, from a plurality of protocols in the left sidebar. Hypovolemia is the selected therapy and requires a PIVA sensor in Fig. 5. Thus the “hypovolemia” data module is based on the selected therapy, which is based on the sensor type).”
Claim 19: Handler teaches “The method of Claim 12, further comprising:
operably connecting the control device to a medical device (i.e. upon connection (e.g., via hard-wire) between a therapeutic device 106A-B and the bedside brain 100 [Handler 0099, Fig. 1 element 100 is separate from element 106A and 108A]);
receiving, for the medical device from the user interface, a second selection of a second therapy of the one or more predetermined therapies provided by the user interface (Handler Fig. 3-16 show a plurality of therapies other than hypovolemia that are available for selection. Claim 1 can be repeated for a second therapy); and
based on receiving the second selection:
confirming that at least one sensor corresponding to the second therapy is operably connected to the control device (Handler Fig. 3-16 show a plurality of therapies other than hypovolemia that are available for selection. Claim 1 can be repeated for a second therapy) (i.e. Bedside brain 100 may further display required devices, such as patient therapy devices 106A-B and/or patient monitoring devices 108A-B. With the “Hypovolemia” protocol, bedside brain requires an infusion pump or syringe pump, with either saline or lactated ringers as the delivered therapy. Bedside brain 100 also indicates that the required therapy device is not detected (e.g., “None detected”). Bedside brain 100 will not active the “Hypovolemia” protocol, until the required device is detected and configured appropriately [Handler 0063, Fig. 5]… Patient monitoring devices 108A-B may include any patient monitor and/or physiological sensor [Handler 0054]);
downloading, from the server, a second algorithm configured to operate the medical device based on real-time data received from the at least one sensor (Handler Fig. 3-16 show a plurality of therapies other than hypovolemia that are available for selection. Claim 1 can be repeated for a second therapy) (i.e. the protocol execution module receives the plurality of protocols from an external server [Handler 0010]… bedside brain server 102 provides information, as required by the bedside brain 100, such as specific rule protocols [Handler 0051]… bedside brain 100 receives a monitor failure indication (e.g., ECG lead failure indication)… and modifies the therapy (if needed) to maintain patient safety [Handler 0086, Fig. 12] note: Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL”);
displaying at least one graphical data module associated with receiving data from the at least one sensor (Handler Fig. 3-16 show a plurality of therapies other than hypovolemia that are available for selection. Claim 1 can be repeated for a second therapy) (Handler Fig. 12 shows a configuration GUI as graphical data, for Hypovolemia as a selected therapy. Fig. 7 shows that selected therapy Hypovolemia uses a sensor type “PIVA.”) and with controlling the medical device (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL”); and
controlling the medical device based on the real-time data received from the at least one sensor and the second algorithm (Handler Fig. 3-16 show a plurality of therapies other than hypovolemia that are available for selection. Claim 1 can be repeated for a second therapy) (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL” and 3. Volume of rehydration fluid (in mL) to bolus if severely hypovolemic: 250 mL.” The pencil icon indicates that the volume of medicine can be input and/or edited. This input (configuration parameter) also programs, or controls (algorithm) the pump (infusion device) based on when to rehydrate (based on the sensor) for hypovolemia (selected graphical data module) while simultaneously controlling the first infusion device (i.e. the three-channel IV pump has that all three channels hooked up to different medications would emulate three devices and three therapies (e.g., one medication per therapy). In this example, the three-channel IV pump would send three separate handshakes [Handler 0107]).”
Claim 20: Handler teaches “The method of Claim 19, wherein the at least one sensor corresponding to the second therapy is one of the one or more sensor devices for providing data associated with the selected first therapy, the method further comprising:
controlling the first infusion device and the medical device based on same data received from the at least one sensor, the first infusion device being controlled based on input of the same data to the first algorithm and the medical device being controlled based on input of the same data to the second algorithm (i.e. In an embodiment, multiple protocols may be run on one device… simultaneously [Handler 0104] note: multiple protocols/therapies can be run on one patient monitoring device/sensor. When this is the case, the operations of the infusion device and medical device would be based on the same single sensor data).”
Claim 22: Handler teaches “The method of Claim 12, further comprising:
operably connecting the infusion control device to a second infusion device of the one or more intravenous infusion devices, the infusion control device being physically distinct from the second infusion device (Handler Fig. 1 shows Bedside Brain 100 as a control device connected to at least two distinct Patient Therapy Devices 106A-106B);
downloading to the control device, from a server, a second algorithm (Handler Fig. 3-16 show a plurality of therapies other than hypovolemia that are available for selection. Claim 1 can be repeated for a second therapy) (i.e. the protocol execution module receives the plurality of protocols from an external server [Handler 0010]… bedside brain server 102 provides information, as required by the bedside brain 100, such as specific rule protocols [Handler 0051]… bedside brain 100 receives a monitor failure indication (e.g., ECG lead failure indication)… and modifies the therapy (if needed) to maintain patient safety [Handler 0086, Fig. 12] note: Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL”); and
controlling the second infusion device based on the real-time data received from the one or more sensor devices and the second algorithm (Handler Fig. 3-16 show a plurality of therapies other than hypovolemia that are available for selection. Claim 1 can be repeated for a second therapy) (Handler Fig. 12 shows “2. Bolus rehydration IV fluid when PIVA volume index falls below this value: 5mL” and 3. Volume of rehydration fluid (in mL) to bolus if severely hypovolemic: 250 mL.” The pencil icon indicates that the volume of medicine can be input and/or edited. This input (configuration parameter) also programs, or controls (algorithm) the pump (infusion device) based on when to rehydrate (based on the sensor) for hypovolemia (selected graphical data module).”
Claim 23: Handler teaches “The method of Claim 22, further comprising:
adjusting a parameter of the second infusion device based on an alert from the first infusion device (i.e. Therapy devices 106A-B may provide input on device state, or other inputs such as device monitored input parameters. For example, a defibrillator may provide ECG monitored input parameters [Handler 0053, Fig. 1 shows multiple infusion pumps 106A-106B can be used]… a monitor failure indication (e.g., ECG lead failure indication), alerts the clinician, and modifies the therapy (if needed) [Handler 0086] note: output devices can also provide input parameters. Input parameters can trigger alerts. Input parameters can modify a therapy on the connected therapy device. For example a defibrillator of 0035 (as a first therapy device) provides ECG input parameters to a second therapy device. The second therapy device receives an input of an ECG lead failure similar to 0086 from the first therapy device as an alert. The second infusion device modifies the therapy/adjusts a parameter on the second infusion device. It is noted that the example in Handler is an ECG device—Handler categorizes pumps and defibrillators as medical therapy devices in 0008—so an infusion device may also perform similarly).”
Claim 24: Handler teaches “A non-transitory machine-readable medium storing instructions thereon that, when executed by a processor (i.e. Bedside brain 100 includes a memory… includes one or more processors, capable of executing instructions in communication with the memory [Handler 0048]), cause the processor to perform a method according to Claim 12 (See claim 1).”
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Handler, in view of Kamen Dean from Deka Products, European Patent Application number EP 3511943 A1 (hereinafter “Deka”).
Claim 21: Handler teach(es) all the limitations of claim 12, above. Handler is/are silent regarding “identifying, based on information received from the first infusion device, a patient designated to receive therapy from the first infusion device; operably connecting the control device to a cloud-based system configured to accumulate patient data; downloading patient order information pertaining to the patient from the cloud-based system; and receiving, at the control device from the first infusion device, infusion information comprising a flow rate or an amount of a medication provided by the first infusion device; determining, at the control device, limits on the infusion information based on the patient order information; and controlling, at the control device, the flow rate of the medication provided by the first infusion device based on the determined limits on the infusion information.”
Deka teaches “identifying, based on information received from the first infusion device, a patient designated to receive therapy from the first infusion device;
operably connecting the control device to a cloud-based system configured to accumulate patient data;
downloading patient order information pertaining to the patient from the cloud-based system (i.e. monitoring server may be configured to interrogate an electronic health records database to receive patient information therefrom. The monitoring server may be further configured to populate the monitoring client with a predefined set of information in accordance with the patient information… The predefined set of information may include at least one of a patient age, a height, a weight, a diagnosis, a current medication, a medication category, a medication allergies, and a sensitivity [Deka 0069-0070]) (i.e. the user information may be downloaded to any device including, but not limited to, history, preferred settings, etc., information [Deka 0327] note: size, weight, age are user information, downloadable to any device); and
receiving, at the control device from the first infusion device, infusion information comprising a flow rate or an amount of a medication provided by the first infusion device (i.e. event network 9 may also include a Drug Error Reduction System ("DERS"). The DERS system may include a first set of predetermined criteria to trigger soft alarms and/or a second set of predetermined criteria to trigger hard alarms. Soft alarms may be overridden (e.g., turned off) by a caregiver using a user interface of an infusion pump 7 and/or a monitoring client 1 (and may be only an audible and/or vibratory alarm) while hard alarms cause the treatment to cease until the source of the hard alarm is removed…. hard and soft limits define treatment limits, such as drug dosage limits based upon size, weight, age, other patient parameters, or other criteria [Deka 0199-0200] note: size, weight, age are user information, downloadable to any device, and obtained through a network. Note2: causing treatment to cease sets the flow rate to zero, based on the patient’s limits);
determining, at the control device, limits on the infusion information based on the patient order information (i.e. event network 9 may also include a Drug Error Reduction System ("DERS"). The DERS system may include a first set of predetermined criteria to trigger soft alarms and/or a second set of predetermined criteria to trigger hard alarms. Soft alarms may be overridden (e.g., turned off) by a caregiver using a user interface of an infusion pump 7 and/or a monitoring client 1 (and may be only an audible and/or vibratory alarm) while hard alarms cause the treatment to cease until the source of the hard alarm is removed…. hard and soft limits define treatment limits, such as drug dosage limits based upon size, weight, age, other patient parameters, or other criteria [Deka 0199-0200] note: size, weight, age are user information, downloadable to any device, and obtained through a network. Note2: causing treatment to cease sets the flow rate to zero, based on the patient’s limits); and
controlling, at the control device, the flow rate of the medication provided by the first infusion device based on the determined limits on the infusion information (i.e. event network 9 may also include a Drug Error Reduction System ("DERS"). The DERS system may include a first set of predetermined criteria to trigger soft alarms and/or a second set of predetermined criteria to trigger hard alarms. Soft alarms may be overridden (e.g., turned off) by a caregiver using a user interface of an infusion pump 7 and/or a monitoring client 1 (and may be only an audible and/or vibratory alarm) while hard alarms cause the treatment to cease until the source of the hard alarm is removed…. hard and soft limits define treatment limits, such as drug dosage limits based upon size, weight, age, other patient parameters, or other criteria [Deka 0199-0200] note: size, weight, age are user information, downloadable to any device, and obtained through a network. Note2: causing treatment to cease sets the flow rate to zero, based on the patient’s limits).”
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention/combination of Handler to include control a pump automatically as disclosed by Deka.
One would have been motivated to do so, before the effective filing date of the invention because it provides the benefit of reducing manual steps, and the benefit of reducing user error.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Onesti (US 20250367380 A1) listed on 892 is related to algorithms, parameters, sensors and, specifically medicinal pump application.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMUEL SHEN whose telephone number is (469)295-9169 and email address is samuel.shen@uspto.gov. The examiner can normally be reached Monday-Thursday, 7:00 am - 5:00 pm CT.
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, Fred Ehichioya can be reached on (571) 272-4034. 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.
/S.S./Examiner, Art Unit 2179
/IRETE F EHICHIOYA/Supervisory Patent Examiner, Art Unit 2179
Prosecution Insights