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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 01/30/2026 has been entered.
Response to Arguments
Rejection Under 103
Applicant's arguments filed 01/30/2026 have been fully considered.
Applicant argues that the amended claims recite a location of the pump device with a programming limitation, which White does not teach. This programming permits the pump device to be disposed in the homecare environment without the presence of the healthcare professional contrary to White. White conflicts with the suggested combination by teaching a system that works because of authorized users confirming the programming prior to infusion. White emphasized the need for a professional to be present at the IV pump to validate the programming prior to infusion.
In response to Applicant’s argument, the argument are moot in light of the new grounds of rejection. See the updated rejection for further clarification.
Applicant argues that the same arguments apply to the other independent claim and that the dependent claims are novel since they depend from patentable claims 1 and 8 and further distinguish the cited references.
In response to Applicant’s argument, the arguments are moot in light of the new grounds of rejection and since the independent claims are still rejected, the dependent claims are also rejected due to inheriting the issue of the independent claims. See their rejections below.
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 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.
Claims 1, 3-9, 11-12, 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Holowko et al. (US 6039251) in view of Walsh (US 2002/0195488), Zdeblick (US 2009/0118594), and Rose et al. (US 2017/0230907).
Regarding claim 1, Holowko discloses a system for providing homecare to a patient, the system comprising:
a medical pump device disposed in a homecare environment with the patient remote from a healthcare professional and programmable to carry out an administration operation for administering a medical fluid to the patient without the presence of the healthcare professional at the homecare environment to confirm the programming, (col. 3 Ln. 43-46 a system for secure operation of a medical device is provided, comprising a medical device for use in medical treatment at a remote location and which is controllable by control instructions; col. 4 Ln. 33-34 a pump located in a patient's home from a remote medical care facility; col. 4 Ln. 40-43 securely operating a portable medical device, such that only authorized patients can use the device; col. 4 Ln. 54-61 a secure remote control system 10 which allows a medicament dispensing patient pump or other medical device 26, located in a patient's home 11, to be controlled and monitored from a remote location, such as a medical care facility 12. The pump 26 delivers prescription medicine and/or other substances to the patient in a controlled manner in accordance with the medical treatment prescribed for the patient)
the medical pump device comprising a pumping mechanism for administering the medical fluid, a local storage device for storing programming information, a processor device for controlling operation of the pumping mechanism according to the programming information in said storage device, and (col. 4 Ln. 62-67, col. 5 ln. 1-5 A modem 20 is located in the patient's home or other remote care area 11, for communicating with the modem 14 and computer 13 at the base medical care facility 12. A central processing unit (CPU) 18 controls the modem 20, as well as the smartcard reader/writer 22, and the pump 26. The CPU can be a standard microprocessor or microcontroller or other control unit which allows for communication as well as the execution of instructions. Software (and/or firmware) 19 is also provided in a memory unit for instructing the CPU with respect to the functions of communication, pump control, and security; col. 5 Ln. 36-46 Control software is provided with the software 19 for allowing the CPU 18 to control the pump 26 in the desired manner, and thereby enable the pump to deliver medicine or other substances to the patient in a controlled manner and in accordance with a medical treatment plan. For example, with a device for delivering fluid medicaments, the program would preferably comprise a number of algorithms and routines which control the rate at which the fluid is delivered to the patient, the frequency of administration of the fluid, the number of doses to be delivered, and other variables associated with drug delivery)
wherein the remote communication device is configured to transmit prescription data sets each prescription data set comprising programming information associated with a particular medical fluid to the medical pump device in a push message, without prior communication about transmission from the medical pump device, and (Fig. 1 and corresponding text; col. 9 ln. 18-20 the patients prescription is entered, such as by using a user interface with computer 13 of FIG. 1; col. 4 Ln. 62-67, col. 5 ln. 1-5 A modem 20 is located in the patient's home or other remote care area 11, for communicating with the modem 14 and computer 13 at the base medical care facility 12; col. 9 ln. 54-67 If the smartcard has been entered into the reader… the previously saved equipment number of the pump is obtained from memory located with the device or CPU. These two obtained numbers are then compared, at step 56, to determine if they match. If they do not match, an unauthorized patient card has been entered into the reader and the pump should not be permitted to operate. Accordingly, steps 62 and 64 are executed wherein an error message is displayed and the pump is disabled or not enabled)
the medical pump device is configured to receive said prescription data sets and store the programming information contained in the prescription data sets in said storage device, (col. 9 ln. 18-23 the patients prescription is entered, such as by using a user interface with computer 13 of FIG. 1. This prescription information can include a variety of data, such as, for example, the type of drug to administer, the rate at which the drug should be administered, and the frequency of administration col. 5 Ln. 36-46 Control software is provided with the software 19 for allowing the CPU 18 to control the pump 26 in the desired manner, and thereby enable the pump to deliver medicine or other substances to the patient in a controlled manner and in accordance with a medical treatment plan. For example, with a device for delivering fluid medicaments, the program would preferably comprise a number of algorithms and routines which control the rate at which the fluid is delivered to the patient, the frequency of administration of the fluid, the number of doses to be delivered, and other variables associated with drug delivery; col. 6 ln. 50 – co. 7 ln. 1 patient smartcard can also be used to store data regarding the pump operation. For example, the CPU 18 can keep track of the data associated with the delivery of medicine to the patient, such as how much medicine was delivered, the times at which the medicine was delivered, the type of medicine which was delivered, any errors or warnings which occurred during delivery, and similar data. This data can be saved to the patient smartcard in the reader/writer 22, for ease of transportation by the patient and for paperless record keeping of the pump data)
Holowko does not appear to teach the following, however, Walsh teaches it is old and well known in the art of healthcare data processing to have:
a reader device for reading identification information of an identification mark of a fluid container containing medical fluid, and (Walsh [0146] In accordance with a further embodiment of the invention, the invention is used to assist verification of medications to be taken by a patient on an outpatient basis. In this embodiment, which is illustrated schematically in FIG. 6, a laser barcode scanner and speaker unit 180 similar to those described above (or an equivalent unit,) are located in the patient's home… recognize the barcodes on the patient's medication bottle, packet, pill box or like container or carrier; [0147] the program in computer 184 records and verifies that the medication container was scanned by the patient and records the medication and the time of day for later reporting {where the medication being the medical fluid is taught above})
Therefore, it would have been obvious to one of ordinary skill in the art of healthcare data processing, before the effective filing date of the claimed invention, to modify Holowko to incorporate a reader device for reading identification information of an identification mark of a fluid container containing medical fluid, as taught by Walsh, in order to assist with verifying the medications being taken by the patient when they are at home. See Walsh [0146].
Holowko-Walsh does not appear to teach the following, however, Zdeblick teaches it is old and well known in the art of healthcare data processing wherein:
transmit a plurality of prescription data sets (Zdeblick [0041] A given fluid delivery device may include a single component or two or more disparate components (such as syringes and vials, fluid containment bags and IV pumps, etc.) which are operatively connected to one another during use and collectively comprise the ability to transfer a fluid transfer signal between the device and a patient associated identifier, as reviewed above. [0042] Embodiments of the fluid delivery devices may include what is viewed as pharma-informatics enabled components, such as pharma-informatics enabled fluid containers. By pharma-informatics enabled fluid container is meant a fluid container, e.g., bag, vial, etc., that includes a volume of fluid that is to be transferred to a patient, e.g., via the fluid delivery device, where the container also has associated with it some identifier that provides identifying information about the contents of the container. The nature of the identifying information may vary greatly, from the simple, e.g., the name of the fluid, the name of the pharmaceutical agent present therein, to the more complex, e.g., the dosage present in the container, the history of the fluid in the container, the quality of the fluid in the container (e.g., whether it is compromised or spoiled), etc. The nature of the identifier may also vary, e.g., from being a passive interrogatable element, such as a barcode or other machine readable identifier, to a more active component, such as a component that can broadcast information and includes a power source. Sensors, as described below, may also be associated with the medical containers)
wherein the processor device of the medical pump device is configured to load the stored programming information associated with the particular medical fluid from the plurality of prescription data sets stored in the storage device to carry out an administration operation with no user input including no entering of additional data into the medical pump device if identification information read by the reader device relates to the particular medical fluid. (Zdeblick [0011] an intelligent fluid delivery system which includes a patient associated identifier and a parenteral fluid delivery device (such as a syringe, intravenous administration device, inhaler, or dialysis device, as reviewed in greater detail below). The delivery device and identifier are configured so that a fluid transfer signal can be transmitted between them using the patient's body as a communication medium…. Since the knowledge is automatically obtained, no human intervention is required to obtain the knowledge. Instead, without any human intervention, the system obtains the knowledge and provides it to a user for use, e.g., by outputting data comprising the knowledge to a user and/or recording the data to a suitable recording medium, such as a computer readable medium. Furthermore, the knowledge about the fluid delivery event is definitive, such that one can know for sure that the knowledge is about the specific patient and the specific fluid delivery device of interest, again without the requirements of any human intervention or verification)
Therefore, it would have been obvious to one of ordinary skill in the art of healthcare data processing, before the effective filing date of the claimed invention, to modify Holowko-Walsh, as modified above, to incorporate transmitting a plurality of prescription data sets; wherein the processor device of the medical pump device is configured to load the stored programming information associated with the particular medical fluid from the plurality of prescription data sets stored in the storage device to carry out an administration operation with no user input including no entering of additional data into the medical pump device if identification information read by the reader device relates to the particular medical fluid, as taught by Zdeblick, in order to automate the system for dispensing and administering a plurality of treatments to ensure there is a reduce potential for error during the process. See Zdeblick [0006].
Holowko-Walsh-Zdeblick does not appear to teach the following, however, Rose teaches it is old and well known in the art of data communications to have:
a remote communication device being in communication connection with the medical pump device via a communication network, the communication network comprising one of (i) a low power wide area network, (ii) a public mobile communication network, and (iii) a public communication network, (Rose [0056] The gateway devices(s) 202 can include a communication module 220 to communicate with other gateway devices or end devices (e.g., in mesh network) and/or to communicate via the network(s) 210. For example, the communication module 220 can include antennas to communicate with the end device(s) 204 via any low power, long range wide area network. [0058] the end device 204 can operate remotely from gateway device 202… In some embodiments, the communication module 230 can communicate with the gateway device 202 via one or more antennas, communicating at within one or more industrial, scientific, and medical (ISM) bands, such as 915 MHz in the United States, 868 MHz/433 MHz in Europe… the end device 204 can transmit and receive data via a long range, wide area network, for example, in accordance with a LoRa modulation protocol provided by SEMTECH, or in accordance with the LoRaWAN specification provided by the LoRa Alliance)
Therefore, it would have been obvious to one of ordinary skill in the art of data communications, before the effective filing date of the claimed invention, to modify Holowko-Walsh-Zdeblick, as modified above, to incorporate the communication network comprising one of (i) a low power wide area network, (ii) a public mobile communication network, and (iii) a public communication network, as taught by Rose, in order to provide communications over longer distances than short-range wireless communication technologies. See Rose [0030].
Regarding claim 3, Holowko-Walsh-Zdeblick-Rose teaches the system according to claim 1, and Holowko further discloses wherein the programming information comprises at least one of information relating to a delivery mode, a dose rate, an administration volume, and a maximum dose. (Holowko col. 9 ln. 18-23 the patients prescription is entered, such as by using a user interface with computer 13 of FIG. 1. This prescription information can include a variety of data, such as, for example, the type of drug to administer, the rate at which the drug should be administered, and the frequency of administration).
Regarding claim 4, Holowko-Walsh-Zdeblick-Rose teaches the system according to claim 1, and Walsh further teaches wherein the identification mark is a barcode or an RFID tag. (Walsh [0146] In accordance with a further embodiment of the invention, the invention is used to assist verification of medications to be taken by a patient on an outpatient basis. In this embodiment, which is illustrated schematically in FIG. 6, a laser barcode scanner and speaker unit 180 similar to those described above (or an equivalent unit,) are located in the patient's home… recognize the barcodes on the patient's medication bottle, packet, pill box or like container or carrier; [0147] the program in computer 184 records and verifies that the medication container was scanned by the patient and records the medication and the time of day for later reporting).
Regarding claim 5, Holowko-Walsh-Zdeblick-Rose teaches the system according to claim 1, and Zdeblick further teaches wherein the processor device is configured to start an administration operation according to the loaded programming information upon confirmation by a user. (Zdeblick [0098] The IV pump only permits delivery after two confirmations occur. First, the pump confirms with the patient associated identifier that the correct medication is going to be administered to the patient, as determined by the bar code and the patient associate identifier. After transmitting through the conductive link to the patient that this is the correct fluid, the system continues to allow a full delivery of fluid).
Regarding claim 6, Holowko-Walsh-Zdeblick-Rose teaches the system according to claim 1, and Zdeblick further teaches wherein the reader device is embedded in a housing of the medical pump device. (Zdeblick [0108] In yet another variation, shown in FIG. 7D, the transmitter 52A is off of the IV bag and the transmitter becomes an external module and it can either be wired and attached to the pump, or wireless (as shown by dashed line). In this embodiment, identification of the contents of the bag may be by a number of different ways, such as by bar code, text, RFID, etc. A reader reads either the bar code).
Regarding claim 7, Holowko-Walsh-Zdeblick-Rose teaches the system according to claim 1, and Holowko further discloses wherein the medical pump device is located at a remote location from the remote communication device. (Holowko Fig. 1 and corresponding text; col. 4 Ln. 62-67, col. 5 ln. 1-5 A modem 20 is located in the patient's home or other remote care area 11, for communicating with the modem 14 and computer 13 at the base medical care facility 12).
Regarding claim 8, recites substantially similar limitations as those already addressed in the rejection of claim 1, and, as such, is rejected for similar reasons as given above.
Regarding claim 9, Holowko-Walsh-Zdeblick-Rose teaches the system according to claim 1, and further discloses:
wherein the reader device of the medical pump device is configured to read, from an identification mark of another fluid container, information relating to a prescription data set comprising programming information associated with a medical fluid contained in the another fluid container, (Walsh [0146] In accordance with a further embodiment of the invention, the invention is used to assist verification of medications to be taken by a patient on an outpatient basis. In this embodiment, which is illustrated schematically in FIG. 6, a laser barcode scanner and speaker unit 180 similar to those described above (or an equivalent unit,) are located in the patient's home… recognize the barcodes on the patient's medication bottle, packet, pill box or like container or carrier; [0147] the program in computer 184 records and verifies that the medication container was scanned by the patient and records the medication and the time of day for later reporting {where the medication being the medical fluid is taught above})
wherein the processor device of the medical pump device is configured to load the programming information associated with the medical fluid in the another fluid container to carry out an administration operation (Zdeblick [0098] The IV pump only permits delivery after two confirmations occur. First, the pump confirms with the patient associated identifier that the correct medication is going to be administered to the patient, as determined by the bar code and the patient associate identifier. After transmitting through the conductive link to the patient that this is the correct fluid, the system continues to allow a full delivery of fluid).
Regarding claim 11, Holowko-Walsh-Zdeblick-Rose teaches the system according to claim 1, and Rose further teaches wherein the low power wide area network operates around 868 MHz or around 915 MHz. (Rose [0058] the end device 204 can operate remotely from gateway device 202… In some embodiments, the communication module 230 can communicate with the gateway device 202 via one or more antennas, communicating at within one or more industrial, scientific, and medical (ISM) bands, such as 915 MHz in the United States, 868 MHz/433 MHz in Europe… the end device 204 can transmit and receive data via a long range, wide area network, for example, in accordance with a LoRa modulation protocol provided by SEMTECH, or in accordance with the LoRaWAN specification provided by the LoRa Alliance). The motivations to combine the references mentioned above was discussed in the rejection of claim 1, and is incorporated herein.
Regarding claim 12, Holowko-Walsh-Zdeblick-Rose teaches the system according to claim 11, and Rose further teaches wherein the communication network is a long-range wide area network (LoRaWAN). (Rose [0058] the end device 204 can transmit and receive data via a long range, wide area network, for example, in accordance with a LoRa modulation protocol provided by SEMTECH, or in accordance with the LoRaWAN specification provided by the LoRa Alliance). The motivations to combine the references mentioned above was discussed in the rejection of claim 1, and is incorporated herein.
Regarding claim 14, the claim recites substantially similar limitations as those already addressed in the rejection of claim 11, and as such is rejected for similar reasons as given above.
Regarding claim 15, the claim recites substantially similar limitations as those already addressed in the rejection of claim 12, and as such is rejected for similar reasons as given above.
Claims 10, 13 are rejected under 35 U.S.C. 103 as being unpatentable over Holowko-Walsh-Zdeblick-Rose in view of Usman Raza et al., ("Low Power Wide Area Networks: An Overview", January 16, 2017, IEEE Communications Surveys & Tutorials, Vol. 19), and Sands et al. (CA 2804758C).
Regarding claim 10, Holowko-Walsh-Zdeblick-Rose teaches the system according to claim 1, but does not appear to teach the following, however, Raza teaches it is old and well-known in the art of low energy communications wherein the communication network is a low power wide area network with a range of up to 40 km. (Raza Table 1 and corresponding text; pg. 861 col. 2 teaches ranges for LoRaWAN in one study were observed to be 15km to 30km).
Therefore, it would have been obvious to one of ordinary skill in the art of low energy communications, before the effective filing date of the claimed invention, to modify Holowko-Walsh-Zdeblick-Rose, as modified above, to incorporate transmitting prescription data without prior communication about transmission from the medical pump device as taught by Raza in order to save power when transmitting data. See Raza pg. 858 col. 1.
Regarding claim 13, the claim recites substantially similar limitations as those already addressed in the rejection of claim 10, and as such is rejected for similar reasons as given above.
Claims 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Holowko-Walsh-Zdeblick-Rose in view of Szamosfalvi et al. (US 2008/0015487).
Regarding claim 16, Holowko-Walsh-Zdeblick-Rose teaches the system according to claim 1, and Holowko-Walsh-Zdeblick-Rose does not appear to teach wherein the plurality of prescription data sets relate to a plurality of medical fluids to be administered over an extended course of therapy following a plurality of medication protocols. However, Szamosfalvi teaches it is old and well-known in the art of healthcare data processing wherein the plurality of prescription data sets relate to a plurality of medical fluids to be administered over an extended course of therapy following a plurality of medication protocols. (Szamosfalvi [0326] teaches a plurality of operational modes that include administering the treatment in extended therapy sessions [0668] teaches extended therapy sessions can be uses where the medication administration protocol does not require high blood flow).
Therefore, it would have been obvious to one of ordinary skill in the art of healthcare data processing, before the effective filing date of the claimed invention, to modify Holowko-Walsh-Zdeblick-Rose, as modified above, to incorporate wherein the plurality of prescription data sets relate to a plurality of medical fluids to be administered over an extended course of therapy following a plurality of medication protocols as taught by Szamosfalvi in order to eliminate bleeding risks. See Szamosfalvi [0668].
Regarding claim 17, the claim recites substantially similar limitations as those already addressed in the rejection of claim 16, and, as such, is rejected for similar reasons as given above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANDA R COVINGTON whose telephone number is (303)297-4604. The examiner can normally be reached Monday - Friday, 10 - 5 MT.
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, Jason B. Dunham can be reached on (571) 272-8109. 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.
/AMANDA R. COVINGTON/Examiner, Art Unit 3686
/RACHELLE L REICHERT/Primary Examiner, Art Unit 3686
Prosecution Insights