DETAILED ACTION
Acknowledgements
This office action is in response to the claims filed February 27, 2026.
Claims 1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 20, 22, 23, and 24 are pending
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 .
Request for Continued Examination
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/27/2026 has been entered.
Information Disclosure Statement(s)
The information disclosure statements (IDS) submitted on 01/12/2026, 04/13/2026, and 07/08/2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Claim Rejection - 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, 2, 3, 4, 5, 6, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 20, 22, 23, and 24 are rejected to under 35 U.S.C 101 as not being directed to eligible subject matter the grounds set out in detail below:
Independent Claims 1 and 16:
Eligibility Step 1 (does the subject matter fall within a statutory category?): Independent Claim 1 falls within the statutory category of machine. Independent claim 16 falls within the statutory category of method
Eligibility Step 2A-1 (does the claim recite an abstract idea, law of nature, or natural phenomenon?): Independent claims 1 and 16 claimed invention are directed to a judicial exception.
The claim elements in the independent claims (claim 1 being representative) which set forth the abstract idea are:
monitoring the fluid balance of a patient, comprising: …[…]…
configured to collect and measure a UO expelled from the patient,
performs operations that include: in accordance with a first infusion order;
automatically recording fluid infusion data over a period of time;
automatically recording UO data over the period of time;
determining fluid I/O data based on the fluid infusion data and the UO data;
rendering the fluid I/O data.
calculating a fluid balance for the patient, the fluid balance defined by a difference between a fluid infusion volume from the fluid infusion data and a UO volume from the UO data
rendering a graph continuously indicating the fluid balance over the period of time
comparing the fluid balance with one or more fluid balance limits;
generating an alert when the fluid balance exceeds any one of the one or more fluid balance limits, the one or more fluid balance limits, including at least one of a high fluid balance limit associated with fluid overload of the patient, or a low fluid balance limit associated with a dehydration of the patient;
and generating a revised infusion order based on the I/O data, wherein the alert includes the revised infusion order
which falls within “certain methods of organizing human activity” as following rules or instructions to analyze fluid infusion data and input and output data to determine an instituted revised infusion order. See MPEP § 2106.04(a)(2).
Eligibility Step 2A-2 (does the claim recite additional elements that integrate the judicial exception into a practical application?): For Independent Claims 1 and 16 this judicial exception is not integrated into a practical application.
In Claim 1 and 16 the additional elements are:
a fluid infusion system including one or more pumps coupled with the patient via
a urine output (UO) system including a collection container coupled with the patient via a drainage tube
one or more processors with a non-transitory computer-readable storage medium (CRM) including fluid input/output (I/O) logic
display of the system
Examiner takes the applicable considerations stated in MPEP 2106.04 (d) and analyzes them below in light of the instant applications disclosure and claim elements as a whole.
The additional element, one or more processors with a non-transitory computer-readable storage medium (CRM) including fluid input/output (I/O) logic, is performing the abstract idea and stated as general purpose computer tools or equivalent to apply the abstract idea as “apply-it”
The additional element, a fluid infusion system including one or more pumps coupled with the patient via
The additional element, a urine output (UO) system including a collection container coupled with the patient via a drainage tube, is applied as “apply-it” as a tool or equivalent to gather data
The additional element, display of the system, is applied as “apply-it” as a tool or equivalent to output data
Accordingly, claims 1 and 16 do not integrate the abstract idea into a practical application.
Eligibility Step 2B (Does the claim amount to significantly more?): The independent claims 1 and 16 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as analyzed above in step 2A prong 2 above, these additional elements, whether viewed individually or as an ordered combination, amount to no more than applying the abstract idea to gather, manipulate, and output data and thus insufficient to provide “significantly more”. Therefore, the claims do not amount to significantly more and the claims are ineligible.
Dependent Claims 2, 3, 4, 5, 6, 7, 8, 9, 11, 13, 14, 15, 17, 18, 20, 22, 23, and 24 :
Eligibility Step 1 (does the subject matter fall within a statutory category?):The dependent claims 2, 3, 4, 5, 6, 7, 8, 9, 11, 13, 14, and 15 fall within the statutory category of machine and dependent claims 17, 18, 20, 22, 23, and 24 fall within the statutory category of method.
Eligibility Step 2A-1 (does the claim recite an abstract idea, law of nature, or natural phenomenon?): Dependent claims 2, 3, 4, 5, 6, 7, 8, 9, 11, 13, 14, 15, 17, 18, 20, 22, 23, and 24 claimed invention are directed to a judicial exception.
Dependent claims 2, 3, 4, 5, 6, 7, 8, 9, 11, 13, 14, 15, 17, 18, 20, 22, 23, and 24 continue to limit the abstract idea in the independent claims by (1) limiting the determination of fluid data, (2) outputting fluid data, and (3) revising an infusion order thus, inheriting the same abstract idea which falls within “certain methods of organizing human activity” as following rules or instructions to analyze fluid infusion data and input and output data to determine an instituted revised infusion order. See MPEP § 2106.04(a)(2)
Eligibility Step 2A-2 (does the claim recite additional elements that integrate the judicial exception into a practical application?): In Claims 2, 3, 4, 5, 6, 7, 8, 9, 11, 13, 14, 15, 17, 18, 20, 22, 23, and 24 this judicial exception is not integrated into a practical application.
In Claims 2, 3, 4, 5, 6, 7, 8, 9, 11, 13, 14, 15, 17, 18, 20, 22, 23, and 24 the additional elements not already recited in the independent claims are:
a network
an electronic medical record
a wired connection
a common support structure
a housing
Examiner takes the applicable considerations stated in MPEP 2106.04 (d) and analyzes them below in light of the instant applications disclosure and claim elements as a whole.
The additional element, a network, is claimed as a general computer tool or equivalent to apply the abstract idea as “apply-it” to share data
The additional element, an electronic medical record, is generally linking the abstract idea to computer implementation
The additional element, a wired connection, is claimed as a general computer tool or equivalent to apply the abstract idea as “apply-it” to share data
The additional element, a common support structure, is generally linking the abstract idea to fluid infusion mechanical medical device implementation
The additional element, a housing , generally linking the abstract idea to fluid infusion mechanical medical device implementation
Accordingly the dependent claims do not integrate the abstract idea into a practical application.
Eligibility Step 2B (Does the claim amount to significantly more?): Dependent claims 2, 3, 4, 5, 6, 7, 8, 9, 11, 13, 14, 15, 17, 18, 20, 22, 23, and 24 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as analyzed above in step 2A prong 2 above, these additional elements, whether viewed individually or as an ordered combination, amount to no more than applying the abstract idea and/or generally linking and thus insufficient to provide “significantly more”. Therefore, the claims do not amount to significantly more and the claims are ineligible.
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.
Independent Claims 1 and 16 as well as dependent claims 2, 4, 5, 6, 7, 8, 9, 11, 13, 14, 15, 17, 20, 22, 23, and 24 are rejected to under 35 U.S.C. 103 as being unpatentable over Rudko et. al (hereinafter Rudko) (US20080027409A1) in view of HALPERT et. al (hereinafter HALPERT) (US20200254178A1) and in further view of Darrah et. al (hereinafter Darrah) (US20140228755A1)
As per claim 1, Rudko teaches:
A system for monitoring the fluid balance of a patient, comprising: a fluid infusion system including one or more pumps coupled with the patient via one or more infusion lines; ([0033] discloses, “In one example, the first infusion subsystem includes a pump controlled by the controller for infusing the patient with fluid from the first source.” And see [0056] discloses, “Also shown in FIG. 1 is fluid infusion measure ment device 10. This device is a component of another infusion Subsystem for infusing fluid from bag 12 (a drug, saline, or Sodium bicarbonate, for example) into the patient via W needle 13 connected to bag 12 by tubing 14. Fluid infusion measurement device 10 measures the amount of fluid from bag 12 infused into the patient. In one example, device 10 is connected to unit 34 via line 15 and unit 34 displays the output of device 10 (the amount of fluid infused from source 12, and/or the infusion rate, or the weight of Source 12 at any given time).” And see [0032] discloses, “The subject invention features a patient hydration/ fluid administration system. A first infusion Subsystem is for infusing a patient with fluid from a first source. A second infusion subsystem is for infusing a patient with fluid from a second source.” And see [0031] discloses, “The subject invention results from the realization that patient dehydration and over hydration in general can be prevented by automatically measuring the urine output of the patient and adjusting the rate of delivery of a hydration fluid from more than one source to the patient to achieve, as necessary, a Zero, positive, or negative net fluid balance in the patient.” And see [0051]”)
a urine output (UO) system including a collection container coupled with the patient via a drainage tube, wherein: the UO system configured to collect and measure a UO expelled from the patient, and the UO system is communicatively coupled with the fluid infusion system; (abstract and see Fig. 1 and see [0033] discloses, “In one example, the first infusion subsystem includes a pump controlled by the controller for infusing the patient with fluid from the first source. The first infusion Subsystem may include a first weighing device for weighing the first Source and outputting the weight of the first source to the controller. The urine output measurement Subsystem may also include a weighing device for weighing a urine collection chamber connected to the patient and outputting the weight of the urine collection chamber to the controller. Typically, the controller is programmed to control the pump based on the weight of the urine collection chamber.” And see [0053] discloses, “The urine collection set typically includes urine collection bag 52, Foley catheter connector 26 for connection to a Foley catheter, and tubing extending between the urine collection bag and connector 26. The infusion set and the urine collection set are preferably placed together as a kit for the hydration unit in sealed bag for storage in a sterile fashion until ready for use. The integrated infusion set includes an IV bag spike, a Luer-to-Foley connector for priming, and a urine collection set includes an integrated urine bag.” and see [0055] discloses, “The disposable urine collection set collects the patient’s urine to allow it to be measured accurately.”)
and a non-transitory computer-readable storage medium (CRM) including fluid input/output (I/O) logic, that when executed by one or more processors of the system, performs operations that include: ([0060] discloses, “Processor 27 is preferably programmed to calculate the amount of fluid in the source of fluid and to track that amount to derive the amount of fluid which has been infused into the patient.” And see [0065] And see Fig. 4)
delivering the infusion fluid to the patient by the fluid infusion system in accordance with a first infusion order programmed into the fluid infusion system; ([0056] discloses, “Also shown in FIG. 1 is fluid infusion measurement device 10. This device is a component of another infusion Subsystem for infusing fluid from bag 12 (a drug, saline, or Sodium bicarbonate, for example) into the patient via W needle 13 connected to bag 12 by tubing 14. Fluid infusion measurement device 10 measures the amount of fluid from bag 12 infused into the patient.” And [0064] discloses, “Controller 100, FIG. 3 is programmed to determine the rate of change of the urine weight, steps 110 and 112, FIG. 4 to calculate a desired infusion rate based on the rate of change of the urine weight, step 114, and to adjust the infusion rate of the infusion pump 22, FIG. 1 based on the calculated desired infusion rate, step 116, FIG. 4.”)
automatically recording fluid infusion data from the fluid infusion system over a period of time([0060] discloses, “ FIG. 2 shows an example of fluid infusion measurement device 10. Load cell 25 is operable to weigh a source of fluid placed on attachment hook 18. The output of load cell 25 is provided to processor 27 typically after conditioning by signal conditioning circuitry 29. Processor 27 is preferably programmed to calculate the amount of fluid in the source of fluid and to track that amount to derive the amount of fluid which has been infused into the patient.” And [0061] discloses, “FIG. 1 controls hydration pump 22, FIG.3 to infuse the patient with hydration fluid based on the patient’s urine output and keeps track of the hydration fluid injected in two ways to provide safety and redundancy. The preferred hydration fluid measurement subsystem includes, first, as discussed above, the weight of hydration fluid source 24, FIG. 1 which is monitored as shown at 102 in FIG. 3. Urine output is also monitored as shown at 104. In addition, the operation history of infusion pump 22 may be monitored by controller 100. Controller 100 may store values representing both of these measurements in a memory such as PROM 106 and controller 100 is programmed as shown in FIG. 4 to store the hydration fluid amounts administered via the hydration fluid measurement strain gauge, and controller 100 is also programmed to store the hydration fluid amount administered by monitoring of the hydration pump operation history.”)
automatically recording UO data from the UO system over the period of time; ([0059] discloses, “Also, if fluid balancing is desired, the controlling electronics of unit 34 can be configured to adjust the operation of pump 22 based on the amount of fluid received by the patient from source 12, the amount of fluid received by the patient from source 24, and the amount of fluid (urine) output by the patient.” And see And [0061] discloses, “FIG. 1 controls hydration pump 22, FIG.3 to infuse the patient with hydration fluid based on the patient’s urine output and keeps track of the hydration fluid injected in two ways to provide safety and redundancy. The preferred hydration fluid measurement subsystem includes, first, as discussed above, the weight of hydration fluid source 24, FIG. 1 which is monitored as shown at 102 in FIG. 3. Urine output is also monitored as shown at 104. In addition, the operation history of infusion pump 22 may be monitored by controller 100. Controller 100 may store values representing both of these measurements in a memory such as PROM 106 and controller 100 is programmed as shown in FIG. 4 to store the hydration fluid amounts administered via the hydration fluid measurement strain gauge, and controller 100 is also programmed to store the hydration fluid amount administered by monitoring of the hydration pump operation history.” And see [0064] discloses, “FIG. 4 illustrates an algorithm that can be used by the controller software of controller 100, FIG. 3 to execute a desired therapy. The algorithm is executed periodically based on a controller internal timer clock. It is appreciated that the algorithm can be made more complex to improve the performance and safety of the device. Controller 100, FIG. 3 is programmed to determine the rate of change of the urine weight, steps 110 and 112, FIG. 4 to calculate a desired infusion rate based on the rate of change of the urine weight, step 114, and to adjust the infusion rate of the infusion pump 22, FIG. 1 based on the calculated desired infusion rate, step 116, FIG. 4.” And see [0061] discloses, “In the subject invention, controller 100, FIG. 3 (a microprocessor or microcontroller or other circuitry (e.g., a comparator) in console 34, FIG. 1 controls hydration pump 22, FIG.3 to infuse the patient with hydration fluid based on the patient’s urine output and keeps track of the hydration fluid injected in two ways to provide safety and redundancy. The preferred hydration fluid measurement subsystem includes, first, as discussed above, the weight of hydration fluid source 24, FIG. 1 which is monitored as shown at 102 in FIG. 3. Urine output is also monitored as shown at 104. In addition, the operation history of infusion pump 22 may be monitored by controller 100. Controller 100 may store values representing both of these measurements in a memory such as PROM 106 and controller 100 is programmed as shown in FIG. 4 to store the hydration fluid amounts administered via the hydration fluid measurement strain gauge, and controller 100 is also programmed to store the hydration fluid amount administered by monitoring of the hydration pump operation history.”)
determining fluid I/O data based on the fluid infusion data and the UO data; and rendering the fluid I/O data on a display of the system;…[…]… ([0049] discloses, “Unit 34 is also typically equipped with the user interface. The interface allows the user to set (dial in) the two or more parameters of therapy Such as the duration of hydration and the desired net fluid balance at the end. The amount of urine which must be output by the patient before balancing begins can also be set. The net fluid balance can be zero if no fluid gain or loss is desired. Display indicators on the console show the current status of therapy: the elapsed time, the net fluid gain or loss, the amount of fluid infused, the amount of fluid loss, the loss rate, and/or the infusion rate.”)
However, Rudko does not explicitly teach:
calculating a fluid balance for the patient, the fluid balance defined by a difference between a fluid infusion volume from the fluid infusion data and a UO volume from the UO data
rendering on the display a graph continuously indicating the fluid balance over the period of time
comparing the fluid balance with one or more fluid balance limits stored in the CRM;
generating an alert when the fluid balance exceeds any one of the one or more fluid balance limits, the one or more fluid balance limits, including at least one of a high fluid balance limit associated with fluid overload of the patient, or a low fluid balance limit associated with a dehydration of the patient;
and generating a revised infusion order based on the I/O data, wherein the alert includes the revised infusion order
However, HALPERT does explicitly teach:
calculating a fluid balance for the patient, the fluid balance defined by a difference between a fluid infusion volume from the fluid infusion data and a UO volume from the UO data …[…]…comparing the fluid balance with one or more fluid balance limits stored in the CRM; ([0050] discloses, “The system also includes a urine output measuring subsystem , a fluid administration subsystem , and a controller responsive to the urine output measuring subsystem and configured to monitor the urine output of a patient . The controller is programmed to control the fluid administration subsystem to automatically administer fluid to the patient at a rate equal to or approximately to the monitored urine output rate until the urine output rate reaches the set desired threshold , step 202. The controller monitors the urine output rate and is programmed to respond when the set urine output rate is reached . The controller is programmed , in response to the set urine output rate is reached to automatically thereafter administer fluid to the patient at the set desired negative net gain rate until the set total fluid loss goal is reached , steps 204 , 206. The controller monitors the total fluid loss and when the goal is reached the controller is programmed to respond . The controller is programmed in response to the desired total fluid loss goal being reached to thereafter , until the end of therapy , automatically administer fluid to the patient at a rate equal to or approximately equal to the monitored urine output rate , step 208. The urine output measuring subsystem may include means for weighing a urine collection bag . The fluid administration subsystem may include a fluid pump and means for weighing a fluid bag connected to the fluid pump.”)
generating an alert when the fluid balance exceeds any one of the one or more fluid balance limits, the one or more fluid balance limits, including at least one of a high fluid balance limit associated with fluid overload of the patient, or a low fluid balance limit associated with a dehydration of the patient; ([0034] discloses, “If the measured urine rate drops below the current set negative match rate or below another urine rate alert setting , the user is alerted . Alerts of low urine rate can occur directly via the fluid management system's screen remotely through the hospital's network . Negative match profile continues until the clinician stops therapy . If the clinician set a total fluid loss target , the fluid management system stops the negative match profile when the patient reaches the total fluid loss target and resumes balanced hydration. An alert can be provided to the clinician to inform them that the fluid loss target has been met.” And see [0084] pseudo code which discloses, “LastUrineOutputAlertTime = Now ( ) // reset time // until urine output exceeds threshold , balance” and see Fig. 2 and see [ 0051 ] Featured is a method of treating a patient with excess fluid . A urine output rate desired threshold , and / or a negative net fluid gain rate , a desired total fluid loss goal are set in unit 34 , FIG . 1. A diuretic is administered ( manually or automatically ) to the patient to induce urine output at hour O of therapy , FIG . 3. For a first therapy period after admin istration of the diuretic , the urine output rate of the patient is driven to a higher level matching or exceeding the set urine output rate ( e.g. , over 400 ml / hr ) desired threshold by automatically infusing fluid into the patient at rates which match or closely match the patient's urine output rates resulting in little or no total fluid loss as shown in hours 0-2 of therapy in FIG . 3. For a second therapy period after the set urine output rate desired threshold is reached , fluid loss is induced at the set negative net fluid gain rate by auto matically decreasing the amount of fluid infused and infus ing fluid at rates which are less than but a function of the patient's urine output rates until the set desired total fluid loss goal is reached as shown in hours 2-13 of therapy in FIG . 3. Optionally , a diuretic may again be administered ( manually or automatically ) during this second therapy period as shown at hour 10. In the third therapy period , fluid is automatically infused at rates equal to or approximately equal to the patient's urine output rates after the desired total fluid loss goal is reached and until the end of therapy resulting in little or no total fluid loss during the third therapy period to prevent patient dehydration” )
and generating a revised infusion order based on the I/O data, wherein the alert includes the revised infusion order (e.g. [0070] discloses, “Typically , the controller is programmed to deter mine the rate of change of the urine weight , the rate of change of the urine sodium concentration , to calculate a desired infusion rate based on the rate of change of the urine weight , and to adjust the infusion rate of the infusion pump based on the calculated desired infusion rate to replace sodium lost in urine in a more concentrated solution than urine sodium concentration . As a result net loss of free water is achieved and blood serum sodium concentration is increased , which is the desired goal of the therapy.” And see [0071] discloses, “It is preferred that the controller subsystem includes a user interface which is configured to allow the user to set a desired serum concentration level achieved in a predetermined time period . The user interface may also include a display indicating the net water and sodium gain or loss , and a display indicating the elapsed time . The user interface can be configured to allow the user to set duration of replacement and to allow the user to set a desired net fluid balance in hourly steps or continuous ramp rate . The control subsystem may also include an alarm subsystem including an air detector . The control subsystem is responsive to the air detector and configured to stop the infusion pump if air exceeding a specified amount is detected . The alarm sub system may be responsive to the urine collection system and configured to provide an indication when the urine collec tion system has reached its capacity . The alarm subsystem may also be responsive to the infusion system and config ured to provide an indication when the infusion subsystem is low on infusion fluid.” And see [0072] discloses, “The system may further include a diuretic admin istration system and / or a blood chemistry sensor responsive to changes of blood sodium concentration . The system may further include a biosensor directly responding to intracra nial pressure or the interstitial fluid pressure in a body compartment where edema is present . [ 0073 ] Amethod of removing excess interstitial fluid from the patient with fluid overload and edema in accordance with this invention includes the steps of :” and see [0074] discloses, “ A. Monitoring a biological sensor responsive to a physiologic variable ;” and see [0075] discloses, “B. Controlling the infusion pump based on the said parameter ; and [ 0076 ] C. Infusing osmotic agent into the patient's blood.” And see [0077] discloses, “The step of monitoring may comprise measuring the urine output volume and composition . The step of measuring the urine output may further include weighing the urine output by the patient . Typically , the step of adjusting the infusion rate includes determining the rate of excretion of sodium in the urine of the urine output by the patient , calculating a desired infusion rate based on the rate of change of the urine sodium , and adjusting the infusion rate based on the calculated desired infusion rate.” / Examiner notes the revised infusion is interpreted as defined in instant application paragraph [00012] which discloses, “The revised infusion order may include at least one of an increased or decreased a rate of infusion. The revised infusion order may also include an altered medical dose of the infusion fluid to chemically cause a change in the fluid balance. The revised infusion order may also include a different drug to be administered. “)
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Rudko’s teachings of adjusting therapy to balance fluid (see e.g. [0049]) with HALPERT’s explicit teachings as previously cited, the motivation being, Rudko’s teaches the infusion being of a drug (see e.g. [0030] and [0056]) and adjustment of the infusion (see e.g. [0059]), therefore it would be obvious to one of ordinary skill that the Rudko’s has the predictable computer elements to change the drug being infused as needed as explicitly taught in HALPERT to decrease utilization of resources and improve individualized treatment and care.
However, HALPERT also does not explicitly teach:
rendering on the display a graph continuously indicating the fluid balance over the period of time
However, Darrah does explicitly teach:
rendering on the display a graph continuously indicating the fluid balance over the period of time (see Fig. 14 and see [0062] discloses, “FIG. 14 depicts another embodiment of a display of the present invention, which may be associated with any of the apparatus of this invention.”)
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Rudko’s teachings of adjusting therapy to balance fluid (see e.g. [0049]) and HALPERT’s explicit teachings as previously cited with Darrah’s teachings of a specific graph on the screen indicating the balance and input and output of fluid as Rudko broadly teaches displaying means of indicating infusion (e.g. [0056]) and Halpert teaches graphing means of display for fluid balancing (see e.g. fig. 3-5), the motivation being one of ordinary skill would understand that Rudko’s has the predictable computer elements to display and the data involved gathered as well as in HALPERT of balancing information to choose the type of display of the information in graphical form as in Darrah and it would decrease utilization of resources and improve UX to improve patient care transparency.
As per claim 2, Rudko teaches:
The system of claim 1, wherein the operations further include transmitting I/O data across a network to an external entity. ([0056] discloses, “Also shown in FIG. 1 is fluid infusion measurement device 10. This device is a component of another infusion Subsystem for infusing fluid from bag 12 (a drug, saline, or Sodium bicarbonate, for example) into the patient via W needle 13 connected to bag 12 by tubing 14. Fluid infusion measurement device 10 measures the amount of fluid from bag 12 infused into the patient. In one example, device 10 is connected to unit 34 via line 15 and unit 34 displays the output of device 10 (the amount of fluid infused from source 12, and/or the infusion rate, or the weight of Source 12 at any given time). Wireless communications between device 10 and unit 34 are also possible. Device 10 could also be integrated into unit 34. Now the nurse will be able to determine, on the display, the amount of Saline infused from bag 24, the amount of fluid infused from bag 12, and the amount of urine output by the patient, among other possible readings. Additional sources of infused fluids can be monitored in the same manner.”)
As per claim 4, Rudko teaches:
The system of claim 1, wherein the fluid infusion system is coupled with the UO system via a wired connection. ([0056] discloses, “Also shown in FIG. 1 is fluid infusion measurement device 10. This device is a component of another infusion Subsystem for infusing fluid from bag 12 (a drug, saline, or Sodium bicarbonate, for example) into the patient via W needle 13 connected to bag 12 by tubing 14. Fluid infusion measurement device 10 measures the amount of fluid from bag 12 infused into the patient. In one example, device 10 is connected to unit 34 via line 15 and unit 34 displays the output of device 10 (the amount of fluid infused from source 12, and/or the infusion rate, or the weight of Source 12 at any given time). Wireless communications between device 10 and unit 34 are also possible. Device 10 could also be integrated into unit 34. Now the nurse will be able to determine, on the display, the amount of Saline infused from bag 24, the amount of fluid infused from bag 12, and the amount of urine output by the patient, among other possible readings.” And see Fig. 1)
As per claim 5, Rudko teaches:
The system of claim 1, wherein the fluid infusion system and the UO system are attached together. (see abstract and Fig. 1 and see [0047])
As per claim 6, Rudko teaches:
The system of claim 1, wherein the fluid infusion system and the UO system are anchored to a common support structure. (See Fig. 1, 34, 22, and 52 and see [0047]-[0048])
As per claim 7, Rudko teaches:
The system of claim 1 , wherein the UO system includes the display. ([0049] discloses, “Unit 34 is also typically equipped with the user interface. The interface allows the user to set (dial in) the two or more parameters of therapy Such as the duration of hydration and the desired net fluid balance at the end. The amount of urine which must be output by the patient before balancing begins can also be set. The net fluid balance can be zero if no fluid gain or loss is desired. Display indicators on the console show the current status of therapy: the elapsed time, the net fluid gain or loss, the amount of fluid infused, the amount of fluid loss, the loss rate, and/or the infusion rate.”)
As per claim 8, Rudko teaches:
The system of claim 1, wherein the UO system includes the I/O logic. ([0060] discloses, “Processor 27 is preferably programmed to calculate the amount of fluid in the source of fluid and to track that amount to derive the amount of fluid which has been infused into the patient.” And see [0065] And see Fig. 4 and Fig. 1 / examiner notes UO system is a subsystem of the processing system which includes the programmable logic for processor)
As per claim 9, Rudko teaches:
The system of claim 1, further comprising a housing, wherein the fluid infusion system and the UO system are disposed within the housing. (see [0057] and see Fig. 1 10 and 12 and see [0056] discloses, “Device 10 could also be integrated into unit 34. Now the nurse will be able to determine, on the display, the amount of Saline infused from bag 24, the amount of fluid infused from bag 12, and the amount of urine output by the patient, among other possible readings.”)
As per claim 11, Rudko teaches:
The system of claim 1, wherein the operations further include transmitting the alert to the external entity. ([0056] discloses, “Now the nurse will be able to determine, on the display, the amount of Saline infused from bag 24, the amount of fluid infused from bag 12, and the amount of urine output by the patient, among other possible readings. Additional sources of infused fluids can be monitored in the same manner.” And see [0050] discloses, “The user interface may also include alarms. The alarms notify the user of therapy events such as an empty fluid bag or a full collection bag as detected by the weight scale. In one proposed embodiment, the urine is collected by gravity. If urine collection unexpectedly stops for any rea son, the system will reduce and, if necessary, stop the IV infusion of fluid and alarm the user. Alternatively, the console can include the second (urine) pump similar to infusion pump 22.”)
As per claim 13, Rudko teaches:
The system of claim 1, wherein the revised infusion order includes at least one of an increased or decreased rate of infusion. ([0056] discloses, “Also shown in FIG. 1 is fluid infusion measurement device 10. This device is a component of another infusion Subsystem for infusing fluid from bag 12 (a drug, saline, or Sodium bicarbonate, for example) into the patient via W needle 13 connected to bag 12 by tubing 14. Fluid infusion measurement device 10 measures the amount of fluid from bag 12 infused into the patient.” And see [0064] discloses, “FIG. 4 illustrates an algorithm that can be used by the controller software of controller 100, FIG. 3 to execute a desired therapy. The algorithm is executed periodically based on a controller internal timer clock. It is appreciated that the algorithm can be made more complex to improve the performance and safety of the device. Controller 100, FIG. 3 is programmed to determine the rate of change of the urine weight, steps 110 and 112, FIG. 4 to calculate a desired infusion rate based on the rate of change of the urine weight, step 114, and to adjust the infusion rate of the infusion pump 22, FIG. 1 based on the calculated desired infusion rate, step 116, FIG. 4.” And see [0065] discloses, “The programming of controller 100 and/or processor 27, FIG. 2 (if present) calculates the amount of fluid infused into the patient from source 12, FIG. 1 by measuring the weight of source 12, step 130, FIG. 5. At different times, the weight of the source is compared, step 132 and based on weight differences, the amount infused is calculated, step 134. The amount infused and/or the infusion rate is then output for display and/or as an input to other programming configured as discussed above when the amount of fluid infused from Source 12 is taken into account to control pump 22, to control regulator 21 (if present), and the like.” And see [0050] discloses, “The user interface may also include alarms. The alarms notify the user of therapy events such as an empty fluid bag or a full collection bag as detected by the weight scale. In one proposed embodiment, the urine is collected by gravity. If urine collection unexpectedly stops for any reason, the system will reduce and, if necessary, stop the IV infusion of fluid and alarm the user.” And see ([0056] discloses, “Now the nurse will be able to determine, on the display, the amount of Saline infused from bag 24, the amount of fluid infused from bag 12, and the amount of urine output by the patient, among other possible readings. Additional sources of infused fluids can be monitored in the same manner.” / reduce or stopping is interpreted by examiner as decreasing)
As per claim 14, Rudko does not explicitly teach:
The system of claim 1, wherein the revised infusion order includes an altered medical dose of the infusion fluid to chemically cause a change in the fluid balance.
However, HALPERT does explicitly teach:
The system of claim 1, wherein the revised infusion order includes an altered medical dose of the infusion fluid to chemically cause a change in the fluid balance. (e.g. [0070] discloses, “Typically , the controller is programmed to deter mine the rate of change of the urine weight , the rate of change of the urine sodium concentration , to calculate a desired infusion rate based on the rate of change of the urine weight , and to adjust the infusion rate of the infusion pump based on the calculated desired infusion rate to replace sodium lost in urine in a more concentrated solution than urine sodium concentration . As a result net loss of free water is achieved and blood serum sodium concentration is increased , which is the desired goal of the therapy.” And see [0071] discloses, “It is preferred that the controller subsystem includes a user interface which is configured to allow the user to set a desired serum concentration level achieved in a predetermined time period . The user interface may also include a display indicating the net water and sodium gain or loss , and a display indicating the elapsed time . The user interface can be configured to allow the user to set duration of replacement and to allow the user to set a desired net fluid balance in hourly steps or continuous ramp rate . The control subsystem may also include an alarm subsystem including an air detector . The control subsystem is responsive to the air detector and configured to stop the infusion pump if air exceeding a specified amount is detected . The alarm sub system may be responsive to the urine collection system and configured to provide an indication when the urine collec tion system has reached its capacity . The alarm subsystem may also be responsive to the infusion system and config ured to provide an indication when the infusion subsystem is low on infusion fluid.” And see [0072] discloses, “The system may further include a diuretic admin istration system and / or a blood chemistry sensor responsive to changes of blood sodium concentration . The system may further include a biosensor directly responding to intracra nial pressure or the interstitial fluid pressure in a body compartment where edema is present . [ 0073 ] Amethod of removing excess interstitial fluid from the patient with fluid overload and edema in accordance with this invention includes the steps of :” and see [0074] discloses, “ A. Monitoring a biological sensor responsive to a physiologic variable ;” and see [0075] discloses, “B. Controlling the infusion pump based on the said parameter ; and [ 0076 ] C. Infusing osmotic agent into the patient's blood.” And see [0077] discloses, “The step of monitoring may comprise measuring the urine output volume and composition . The step of measuring the urine output may further include weighing the urine output by the patient . Typically , the step of adjusting the infusion rate includes determining the rate of excretion of sodium in the urine of the urine output by the patient , calculating a desired infusion rate based on the rate of change of the urine sodium , and adjusting the infusion rate based on the calculated desired infusion rate.” / Examiner notes the revised infusion is interpreted as defined in instant application paragraph [00012] which discloses, “The revised infusion order may include at least one of an increased or decreased a rate of infusion. The revised infusion order may also include an altered medical dose of the infusion fluid to chemically cause a change in the fluid balance. The revised infusion order may also include a different drug to be administered. “)
As per claim 15, Rudko does not explicitly teach:
The system of claim 1, wherein the revised infusion order includes a different drug to be administered.
However, HALPERT does explicitly teach:
The system of claim 1, wherein the revised infusion order includes a different drug to be administered. (e.g. [0035] discloses, “The hydration fluid could be any number of fluids , including but not limits to isotonic saline ( “ normal ” ) , hyper tonic saline , Ringer's Lactate , etc. “ and see [0061] discloses, “A system and a method have been developed to reduce fluid overload and edema and force diuresis in patients with heart failure and other conditions leading to fluid retention, that do not respond to conventional drug therapy . The system and method provides controlled infusion of an osmotic agent ( i.e. hypertonic saline ) into the patient's I.V. that is safe and easy to use.” And see [0062] discloses, “A novel patient infusion , monitoring and control system has been developed that , in one embodiment , comprises:” and see [0063] discloses, “A. A source of a solution of a blood compatible osmotic I.V. infusible agent such as hypertonic saline ,” and see [0064] discloses, “B. An infusion pump and an I.V. set for controlled delivery of the agent to the patient ,” and see [0065] discloses, “ C. A biofeedback sensors connected to the patient that allow monitoring and guiding of the therapy , “ and see [0066] discloses, “ D. A microprocessor based controller responsive to the biofeedback signals and is configured to adjust the infusion rate of the pump based on the output of the biofeedback sensors controlling the infusion of the osmotic agent.” And see [0067] discloses, “In an embodiment that targets therapy of CHF patients , the biofeedback component is comprised of a urine volume monitoring device and a sensor monitoring sodium concentration in urine . The infusion pump is designed for accurate volume delivery . The concentration of sodium in the infusion fluid is known . This allows the controller to calculate the amount of sodium and water delivered to the patient ( the “ ins ” ) . Urine monitoring measures the amount of water and sodium excreted by the patient ( the “ outs ” ) . The system balances ( the “ ins ” and “ outs ” ) the total sodium amount in the patient's body water and achieves the desired sodium concentration in plasma . Optionally gradual controlled increase of sodium concentration in serum can be achieved by : a ) removal of excess free water in urine , and b ) net positive ( “ ins ” over “ outs ” ) addition of small amounts of sodium gradually over hours and days of therapy . As a result , free water excretion is increased , while sodium concentration in blood is maintained within the desired and safe range or increased gradually and safely as desired.” And see [0072]-[0079])
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Rudko’s teachings of adjusting therapy to balance fluid (see e.g. [0049]) with HALPERT’s explicit teachings as previously cited, the motivation being, Rudko’s teaches the infusion being of a drug (see e.g. [0030] and [0056]) and adjustment of the infusion (see e.g. [0059]), therefore it would be obvious to one of ordinary skill that the Rudko’s has the predictable computer elements to change the drug being infused as needed as explicitly taught in HALPERT to decrease utilization of resources and improve individualized treatment and care.
As per claim 16, Rudko teaches:
A method for monitoring a fluid balance of a patient, comprising: ([0032] discloses, “The subject invention features a patient hydration/ fluid administration system. A first infusion Subsystem is for infusing a patient with fluid from a first source. A second infusion subsystem is for infusing a patient with fluid from a second source.” And see [0031] discloses, “The subject invention results from the realization that patient dehydration and over hydration in general can be prevented by automatically measuring the urine output of the patient and adjusting the rate of delivery of a hydration fluid from more than one source to the patient to achieve, as necessary, a Zero, positive, or negative net fluid balance in the patient.” And see [0051]”)
receiving fluid infusion data from a fluid infusion system, the fluid infusion system delivering infusion fluid to the patient; ([0032] discloses, “The subject invention features a patient hydration/ fluid administration system. A first infusion Subsystem is for infusing a patient with fluid from a first source.” And see [0060] discloses, “ FIG. 2 shows an example of fluid infusion measurement device 10. Load cell 25 is operable to weigh a source of fluid placed on attachment hook 18. The output of load cell 25 is provided to processor 27 typically after conditioning by signal conditioning circuitry 29. Processor 27 is preferably programmed to calculate the amount of fluid in the source of fluid and to track that amount to derive the amount of fluid which has been infused into the patient.”)
receiving urine output (UO) data from a UO system, the UO system collecting and measuring UO from the patient; ([0064] discloses, “FIG. 4 illustrates an algorithm that can be used by the controller software of controller 100, FIG. 3 to execute a desired therapy. The algorithm is executed periodically based on a controller internal timer clock. It is appreciated that the algorithm can be made more complex to improve the performance and safety of the device. Controller 100, FIG. 3 is programmed to determine the rate of change of the urine weight, steps 110 and 112, FIG. 4 to calculate a desired infusion rate based on the rate of change of the urine weight, step 114, and to adjust the infusion rate of the infusion pump 22, FIG. 1 based on the calculated desired infusion rate, step 116, FIG. 4.” And see [0061] discloses, “In the subject invention, controller 100, FIG. 3 (a microprocessor or microcontroller or other circuitry (e.g., a comparator) in console 34, FIG. 1 controls hydration pump 22, FIG.3 to infuse the patient with hydration fluid based on the patient’s urine output and keeps track of the hydration fluid injected in two ways to provide safety and redundancy. The preferred hydration fluid measurement subsystem includes, first, as discussed above, the weight of hydration fluid source 24, FIG. 1 which is monitored as shown at 102 in FIG. 3. Urine output is also monitored as shown at 104. In addition, the operation history of infusion pump 22 may be monitored by controller 100. Controller 100 may store values representing both of these measurements in a memory such as PROM 106 and controller 100 is programmed as shown in FIG. 4 to store the hydration fluid amounts administered via the hydration fluid measurement strain gauge, and controller 100 is also programmed to store the hydration fluid amount administered by monitoring of the hydration pump operation history.”)
determining fluid input/output (I/O) data from the fluid infusion data and the UO data; and rendering the I/O data on a display, ([0064] discloses, “Controller 100, FIG. 3 is programmed to determine the rate of change of the urine weight, steps 110 and 112, FIG. 4 to calculate a desired infusion rate based on the rate of change of the urine weight, step 114, and to adjust the infusion rate of the infusion pump 22, FIG. 1 based on the calculated desired infusion rate, step 116, FIG. 4.” And see ([0049] discloses, “Unit 34 is also typically equipped with the user interface. The interface allows the user to set (dial in) the two or more parameters of therapy Such as the duration of hydration and the desired net fluid balance at the end. The amount of urine which must be output by the patient before balancing begins can also be set. The net fluid balance can be zero if no fluid gain or loss is desired. Display indicators on the console show the current status of therapy: the elapsed time, the net fluid gain or loss, the amount of fluid infused, the amount of fluid loss, the loss rate, and/or the infusion rate.”)
wherein: the UO system is coupled with the fluid infusion system to define an I/O system, (abstract and see Fig. 1 and see [0033] discloses, “In one example, the first infusion subsystem includes a pump controlled by the controller for infusing the patient with fluid from the first source. The first infusion Subsystem may include a first weighing device for weighing the first Source and outputting the weight of the first source to the controller. The urine output measurement Subsystem may also include a weighing device for weighing a urine collection chamber connected to the patient and outputting the weight of the urine collection chamber to the controller. Typically, the controller is programmed to control the pump based on the weight of the urine collection chamber.” And see [0053] and see [0055] discloses, “The disposable urine collection set collects the patient’s urine to allow it to be measured accurately.”)
and the display is coupled with the IO system. ([0049] discloses, “Unit 34 is also typically equipped with the user interface. The interface allows the user to set (dial in) the two or more parameters of therapy Such as the duration of hydration and the desired net fluid balance at the end. The amount of urine which must be output by the patient before balancing begins can also be set. The net fluid balance can be zero if no fluid gain or loss is desired. Display indicators on the console show the current status of therapy: the elapsed time, the net fluid gain or loss, the amount of fluid infused, the amount of fluid loss, the loss rate, and/or the infusion rate.”)
As per claims 16, 17, 20, 22-24 they are method claims which repeats the same limitations of claims 1, 2, 11, 13, 14-15 the corresponding system claim, as a series of process steps as opposed to a collection of elements. Since the collective teaching of Rudko and HALPERT as well as the motivations to combine disclose the structural elements that constitute the system of claims 1, 2, 11, 13, 14-15 it is respectfully submitted that they perform the underlying process steps, as well. As such, the limitations of claims 16, 17, 20, 22-24 are rejected for the same reasons given above for claim 1, 2, 11, 13, 14-15.
Dependent claims 3 and 18 are rejected to under 35 U.S.C. 103 as being unpatentable over Rudko et. al (hereinafter Rudko) (US20080027409A1) in view of HALPERT et. al (hereinafter HALPERT) (US20200254178A1), in further view of Darrah et. al (hereinafter Darrah) (US20140228755A1) and in even further view of Handler (US20230089041Al)
As per claim 3 and similarly claim 18, Rudko, HALPERT, and Darrah do not explicitly teach:
The system of claim 2, wherein the external entity includes an electronic medical record.
However, Handler does explicitly teach:
a. The system of claim 2, wherein the external entity includes an electronic medical record. ([0043] discloses, “The gateway 112 may also be configured to integrate with the HIS 120 or other hospital system to facilitate the transmission of the infusion therapy progress data 130 from the pump 102 to, for example, a hospital electronic medical record ("EMR").”)
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Rudko’s teachings of communicating with a user at a display such as a nurse (see e.g. [0056]) and Darrah and HALPERTs teachings as previously cited with Handler’s explicit teachings of transmitting infusion data to an EMR, the motivation being, Rudko’s teaches sending infusion data outputs to a nurse (see e.g. [0056]) by displaying on an interface and may interface with a computer (see e.g. [0066]), therefore it would be obvious to one of ordinary skill that the Rudko’s has the predictable computer elements to implement the transmission to an external entity such as the explicitly taught EMR in Handler to decrease utilization of resources and improve real time communication with decrease in manual dictation errors.
Response to Arguments Regarding 35 U.S.C § 101 Rejection
Applicant’s arguments on remarks pages 1-2 are as follows: Claims 1-9, 11, 13-18, 20, and 22-24 are rejected to under 35 U.S.C § 101 as allegedly being directed to ineligible subject matter. The Office Action alleges on page 3 and 4 of the Office Action that the claims 1 and 16 are directed to a judicial exception. The Examiner alleges that "The claim elements in the independent claims (claim 1 being representative) which set forth the abstract idea are:
a) monitoring the fluid balance of a patient, comprising: ... [... ]... configured to deliver an infusion fluid through one or more infusions to the patient;
b) configured to collect and measure a UO expelled from the patient,
c) performs operations that include: instituting delivery of a first infusion to the patient, wherein the first infusion is delivered to the patient
d) receiving fluid infusion data following the delivery of the first infusion to the patient
e) receiving UO data following the delivery of the first infusion to the patient;
f) determining fluid 1/0 data based on the fluid infusion data and the UO data;
g) rendering the fluid 1/0 data.
h) calculating afluid balance for the patient, the fluid balance defined by a difference between afluid infusion volume from the fluid infusion data and a UO volume from the UO data comparing the fluid balance with one or more fluid balance limits;
i) generating an alert when the fluid balance exceeds any one of the one or more fluid balance limits, the one or more fluid balance limits, including at least one of a high fluid balance limit associated with fluid overload of the patient, or a low fluid balance limit associated with a dehydration of the patient;
j) generating a revised infusion order based on the 1/0 data, wherein the alert includes the revised infusion order, and instituting a second infusion or altering a rate of infusion of the first infusion based on the revised infusion order. The Examiner specifically alleges that claim elements set forth above constitute "certain methods of organizing human activity" as following rules or instructions to analyze fluid infusion data and input and output data to determine an instituted revised infusion order. See MPEP § 2106.04(a)(2). Without conceding the forgoing allegations, Applicant has amended claims 1 and 16 to recite inter alia the following elements. delivering the infusion fluid to the patient via pumps of the fluid infusion system in accordance with a first infusion order programmed into the fluid infusion system; automatically recording fluid infusion data from the fluid infusion over a period of time; and automatically recording UO data from the UO system over the period of time. Applicant submits that actually delivering the infusion fluid to the patient by the fluid infusion system in accordance with a first infusion order that is programmed into the fluid infusion system cannot be interpreted as human activity. Similarly, automatic recording of fluid infusion data and UO data also cannot be interpreted as human activity. Therefore, claims 1 and 16 do not constitute an abstract idea, and therefore, claims 1 and 16 are not directed to a judicial exception. Pursuant to the amendments to independent claims 1 and 16 and the arguments set forth above, Applicant submits that claims 1 and 16 are eligible under 35 U.S.C. § 101. Accordingly, Applicant respectfully requests withdrawal of the rejections of independent claims 1 and 16, and claims 2-9, 11, 13-15, 17, 18, 20, and 22-24 depending therefrom under 35 U.S.C. § 101.
Examiner appreciates applicant’s arguments but does not find them persuasive. MPEP 2106.04(a)(2) (II) states, “Finally, the sub-groupings encompass both activity of a single person (for example, a person following a set of instructions or a person signing a contract online) and activity that involves multiple people (such as a commercial interaction), and thus, certain activity between a person and a computer (for example a method of anonymous loan shopping that a person conducts using a mobile phone) may fall within the “certain methods of organizing human activity” grouping. It is noted that the number of people involved in the activity is not dispositive as to whether a claim limitation falls within this grouping.”
In response to applicants first argument, examiner notes the claim is approached under broadest reasonable interpretation and examiner must take the substance of the positive recitation of the claim without reading the specification into the claims but in light of the specification. The examiner identifies the elements within the claims which are abstract and identifies the additional elements of the claim. The elements identified as abstract are reasonably interpreted to be a certain method of organizing human activity or, more particularly as following rules or instructions to analyze fluid infusion data and input and output data to determine an instituted revised infusion order. See MPEP § 2106.04(a)(2). The independent claims for example claim 1 does recite the amended additional elements as aforementioned in this office action such as for example a fluid infusion system delivering the infusion fluid to the patient. Under broadest reasonable interpretation examiner notes that while the fluid infusion system is delivering fluid to the patient confined to the pump itself by a processor, within the claim construction, it is an “apply-it” step as it is a mere data gathering step prior to executing the integral claim abstract analysis for generating a revised fluid infusion order. The additional element is not producing the tangible result from the abstract analysis when reviewing the claim as a whole. The remainder of the claim is abstract as the recitation of the claim is directed to data collection and analysis to determine information within an infusion environment for alerting and making additional infusion decisions where automatic recording of fluid infusion data and UO data also can be interpreted as human activity as it is not confined to a fluid infusion pump delivering fluid but rather utilizing a processor system to gather data more efficiently, thus examiner maintains it is “certain methods of organizing human activity” as humans can review infusion data and information to record automatically as it is happening in real time and make decisions and change care today and the use of a processor based system does not make the claim dispositive of being directed to an abstract idea.
Thus Examiner maintains the 35 U.S.C § 101 Rejection.
Response to Arguments Regarding 35 U.S.C § 102/103 Rejections
Applicant’s arguments on remarks pages 3-5 with respect to claims 1 and 16 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Prior Art Cited But Not Relied Upon
Salinas et. al (hereinafter Salinas) (US20110230824A1)
A method and system for operating a semi-closed loop and/or a closed loop resuscitation of a burn patient in view of patient information and other physiological data gathered as part of the method and/or by the system. The method in at least one embodiment includes receiving patient information, calculating an infusion rate based at least on part on a portion of the received patient information, outputting the infusion rate to an infusion pump, obtaining a urinary output, calculating a new infusion rate using infusion rate model based constants, and outputting the new infusion rate to an infusion pump. In Some embodiments, the method includes notifying medical staff when problems arise, displaying information regarding the resuscitation, and setting limits regarding the infusion rates.
Handler et. al (US10071202B2)
Methods , systems , and apparatuses integrating medical device data are disclosed . In an example embodiment , a vital sign monitor apparatus includes a renal failure therapy interface configured to receive a renal failure therapy param eter from a renal failure therapy machine performing a renal therapy treatment on a patient and an infusion pump inter face configured to receive an infusion parameter from an infusion pump performing an infusion treatment for the same patient . The apparatus also includes a vital sign monitor engine configured to display , within a combination user interface of a vital sign monitor , the renal failure therapy parameter within a renal failure therapy timeline , and the infusion parameter within an infusion timeline that is aligned with the renal failure therapy timeline .
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ashley Elizabeth Evans whose telephone number is (571) 270-0110. The examiner can normally be reached Monday – Friday 8:00 AM – 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Mamon Obeid can be reached on (571) 270-1813. The fax phone number for the organization where this application or proceeding is assigned 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. Should you have questions on access to the Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/ASHLEY ELIZABETH EVANS/Examiner, Art Unit 3687
/MAMON OBEID/Supervisory Patent Examiner, Art Unit 3687
Prosecution Insights