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 .
Status Of Claims
This action is in reply to the application filed on 03/15/2024.
Claims 1-21 are currently pending and have been examined.
Claim Rejections – 35 § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-21 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1, recites in part, “determine whether the deviation has been resolved”. It is how determination is made as to whether the deviation has been resolved. Is there an algorithm or formula that is used to determine whether or not the deviation has been resolved? Claim 1 is therefore found to be indefinite, because the resulting claim does not clearly set forth the metes and bounds of the patent protection desired. All dependent claims, namely claims 2-10, are rejected for at least the same reason.
Claim 11, recites in part, “determining whether the deviation has been resolved”. It is how determination is made as to whether the deviation has been resolved. Is there an algorithm or formula that is used to determine whether or not the deviation has been resolved? Claim 11 is therefore found to be indefinite, because the resulting claim does not clearly set forth the metes and bounds of the patent protection desired. All dependent claims, namely claims 12-20, are rejected for at least the same reason. Claim 21 recites similar limitations, and is rejected for at least the same reason.
Statement regarding 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-21 recite patent eligible subject matter. The Examiner’s reasons are described below.
The claimed invention recites an abstract idea in Step 2A Prong One because it recites various mental processes such as identifying a deviation in the received automated programming data with respect to the stored programming data, determining whether the deviation is resolved, then activating the infusion if the deviation is resolved or sending an indication to the server if the deviation is not resolved.
However, in Step 2A Prong Two, the claimed invention as a whole integrates the idea into a practical application by including many additional elements that go beyond insignificant extra-solution activity, generally linking to a technical field, or merely applying the abstract ideas such as an infusion device comprising a display device and pump controller (comprising a processor) receiving from a remote server automated programming data instructing the infusion device regarding infusion of medication, when a deviation is identified, sending an acknowledgement of the automated programming data and the deviation, and displaying a user interface workflow for the user to correct the deviation, providing prompts to the user on the user interface for the user to solve the deviation, and if the deviation is resolved, the infusion by the infusion device is activated by the pump controller, otherwise, an indication is sent to the server regarding the deviation. These limitations integrate the abstract idea into a practical application by providing an improvement in technology. In particular, the techniques improve upon automated infusion pump programming by accepting misaligned automated programming request (APR) in real time and continuing processing the resolution with a clinician using the device’s local user interface (see at least Paragraph [0005]).
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(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim 1-21 are rejected under 35 U.S.C. 103(a) as being unpatentable over Jacobson et al., U.S. Patent Application Publication US 2016/0350513 A1 in view of Eggers et al., U.S. Patent Application Publication US 2002/169636 A1.
Claim 1:
Jacobson discloses the following limitations as shown below:
An infusion device, comprising (see at least Paragraph 24, An infusion pump system with multiple drug library editor source capability is described herein. The infusion pump can receive an operational drug library from either one of a dedicated drug library editor or an enterprise drug library editor):
a display device (see at least Paragraph 54, In one embodiment of the method 600 the step 608 of selecting a source drug library editor is performed at the infusion pump by a user making a selection from a plurality of possible selections on a user interface of the pump. In one embodiment, a download drug library function could be facilitated by a pump user interface display screen with a drop-down menu of drug library editor sources); and
a pump controller comprising a processor (see at least Paragraph 15, The infusion pump includes a memory operable to store an operational drug library; a flow controller operably connected to the memory; and a fluid driver operably connected to the flow controller);
wherein the pump controller is configured to: receive, from a server remote from the infusion device, automated programming data configured to instruct the infusion device regarding an infusion of a medication (see at least Paragraph 15, the infusion device accesses and generates a first drug library, … and the flow controller is operable to control the fluid driver in accordance with the received operational drug library);
identify a deviation in the received automated programming data with respect to stored programming data (see at least Paragraph 25, the infusion pump system includes a dedicated drug library editor and an enterprise drug library editor. The infusion pump provides a therapeutic fluid from a fluid reservoir to a patient in accordance with operating parameters and/or limits established in an operational drug library; Paragraph 27, bi-directional communications between the pump and server, as well as sophisticated logging and reporting on pump programming, user input, and operation (including but not limited to alarms, alerts, messages, overrides, program modifications, etc.));
send, without rejecting the received automated programming data, an acknowledgement of the automated programming data and the deviation (see at least Paragraph 27, bi-directional communications between the pump and server, as well as sophisticated logging and reporting on pump programming, user input, and operation (including but not limited to alarms, alerts, messages, overrides, program modifications, etc.; programming at the point of care is logged and reported));
display a user interface workflow for correcting the deviation (see at least Paragraph 35, A programmer (not shown), such as a licensed pharmacist, doctor, or the like, can work with the drug library editor on a user interface to create and/or modify the drug library 224 as desired for a particular application);
determine whether the deviation has been resolved; if the deviation is resolved then activate the infusion; and if the deviation is not resolved then send an indication to the server regarding the deviation (see at least Paragraph 27, bi-directional communications between the pump and server, as well as sophisticated logging and reporting on pump programming, user input, and operation (including but not limited to alarms, alerts, messages, overrides, program modifications, etc.; programming at the point of care is logged and reported)).
Jacobson may not specifically disclose the following limitations, but Eggers as shown does:
provide, via a user interface displayed on the display device, one or more user prompts according to the determined user interface workflow to resolved the deviation (Eggers, see at least Paragraph 39, system then notifies the user when perfusion pressure falls outside of a defined range and recommends adjusting infusion rate of a therapeutic agent to increase blood pressure or to decrease intracranial pressure);
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the teachings of the infusion pump system and method of Jacobson with the interactivity of Eggers with the motivation of providing the benefit that “… facilitates efficient and accurate programming of a medical treatment device while ensuring that the prescribed treatment conforms with institutional and departmental guidelines with respect to a patient in a particular location and/or with particular characteristics” (Eggers, see at least Paragraph 9).
Claims 11 and 21 recite substantially similar method and apparatus limitations to those of apparatus claim 1 and, as such, are rejected for similar reasons as given above.
Claim 2:
The combination of Jacobson/Eggers discloses the limitations shown in the rejection above. Jacobson further discloses the following limitations:
wherein receiving the automated programming data comprises receiving a drug identifier and a request to load parameters for a drug corresponding to the drug identifier (see at least Paragraph 27, bi-directional communications between the pump and server, as well as sophisticated logging and reporting on pump programming, user input, and operation; Paragraph 30, The first drug library 112 and the second drug library 122 can each be part of a customizable drug library database available to the first drug library editor 110 and second drug library editors 120, respectively. The drug library includes drug and infusion pump related information, which may include but is not limited to drug name, drug class, drug concentration, drug amount, drug units, diluent amount, diluent units, dosing units, delivery dose or rate, medication parameters or limits (hard or soft), device/infuser settings and/or modes, clinical care area (CCA) designations and constraints, library version, and the like); and
wherein identifying the deviation comprises determining that the drug is not identified in a currently active first drug library stored in a memory of the infusion device (see at least Paragraph 36, The medication management unit 220 can perform other functions in addition to being the drug library editor. In one embodiment, the medication management unit 220 can further maintain patient safety by reviewing medication orders, drug-drug compatibility, and medication delivery time sequences. In another embodiment, the medication management unit 220 can modulate performance of a medication order based on laboratory data or other newly received patient information. In another embodiment, the medication management unit 220 can monitor the status of the infusion pumps and infusion status progress (including alarms, event logs, and pump user interface inputs), generate reports, and control software or operating code updates to the infusion pumps).
Claim 12 recites substantially similar method limitations to those of apparatus claim 2 and, as such, is rejected for similar reasons as given above.
Claim 3:
The combination of Jacobson/Eggers discloses the limitations shown in the rejection above. Jacobson further discloses the following limitations:
determine, by the infusion device, that the parameters to be loaded for drug are stored in a deactivated second drug library stored in the memory of the infusion device (see at least Paragraph 46, The infusion pump 400 is for selective use with either one of a first drug library editor or a second drug library editor as described above. The first drug library editor is operable to generate a first drug library and the second drug library editor is operable to generate a second drug library; Paragraph 47, The memory 410 is operable to receive one of the first drug library from the first drug library editor and the second drug library from the second drug library editor as the operational drug library 412);
prompt via the one or more prompts, a user to confirm use of the second drug library (see at least Paragraph 36, In another embodiment, the medication management unit 220 can monitor the status of the infusion pumps and infusion status progress (including alarms, event logs, and pump user interface inputs), generate reports, and control software or operating code updates to the infusion pumps); and
based on receiving a confirmation to use the second drug library, deactivate the currently active first drug library, activate the second drug library, and load the parameters for the drug from the activated second drug library (see at least Paragraph 12, preparing a second drug library on a second drug library editor; loading the second drug library into the infusion pump from the second drug library editor as the operational drug library; and delivering an infusion from the infusion pump in accordance with the second drug library).
Claim 13 recites substantially similar method limitations to those of apparatus claim 3 and, as such, is rejected for similar reasons as given above.
Claim 4:
The combination of Jacobson/Eggers discloses the limitations shown in the rejection above. Jacobson further discloses the following limitations:
identify the first pump channel for receiving the automated programming data (see at least Paragraph 54, A drug library editor user interface display screen can provide a drop-down menu or other means of selection for the drug library editor source. Then the selected drug library editor source can download the respective drug library to the target pump or pumps. In another embodiment, a special handshake between the drug library editor and the pump could identify the drug library editor source selected at the drug library editor. The download message or drug library itself could contain a code, configuration setting or direction as to where to accept the next drug library from);
determine that the parameters to be loaded are more aligned with the second pump channel than with the first pump channel (see at least Paragraph 54, A drug library editor user interface display screen can provide a drop-down menu or other means of selection for the drug library editor source. Then the selected drug library editor source can download the respective drug library to the target pump or pumps. In another embodiment, a special handshake between the drug library editor and the pump could identify the drug library editor source selected at the drug library editor. The download message or drug library itself could contain a code, configuration setting or direction as to where to accept the next drug library from); and
prompt via the one or more prompts, a user to confirm use of the second pump channel for receiving the automated programming data (see at least Paragraph 36, In another embodiment, the medication management unit 220 can monitor the status of the infusion pumps and infusion status progress (including alarms, event logs, and pump user interface inputs), generate reports, and control software or operating code updates to the infusion pumps).
Claim 14 recites substantially similar method limitations to those of apparatus claim 4 and, as such, is rejected for similar reasons as given above.
Claim 5:
The combination of Jacobson/Eggers discloses the limitations shown in the rejection above. Jacobson further discloses the following limitations:
determine that the second drug library is for a different care area than a care area currently activated for the infusion device (see at least Paragraph 11, The first drug library editor is one of a dedicated drug library editor and an enterprise drug library editor, and the second drug library editor is the other of the one of the dedicated drug library editor and the enterprise drug library editor).
Claim 15 recites substantially similar method limitations to those of apparatus claim 5 and, as such, is rejected for similar reasons as given above.
Claim 6:
The combination of Jacobson/Eggers discloses the limitations shown in the rejection above. Jacobson further discloses the following limitations:
wherein receiving the automated programming data comprises receiving a drug identifier and a concentration of a drug corresponding to the drug identifier (see at least Paragraph 27, bi-directional communications between the pump and server, as well as sophisticated logging and reporting on pump programming, user input, and operation; Paragraph 30, The first drug library 112 and the second drug library 122 can each be part of a customizable drug library database available to the first drug library editor 110 and second drug library editors 120, respectively. The drug library includes drug and infusion pump related information, which may include but is not limited to drug name, drug class, drug concentration, drug amount, drug units, diluent amount, diluent units, dosing units, delivery dose or rate, medication parameters or limits (hard or soft), device/infuser settings and/or modes, clinical care area (CCA) designations and constraints, library version, and the like), and
wherein identifying the deviation comprises: determining that the drug is identified in a drug library stored in a memory of the infusion device (see at least Paragraph 36, The medication management unit 220 can perform other functions in addition to being the drug library editor. In one embodiment, the medication management unit 220 can further maintain patient safety by reviewing medication orders, drug-drug compatibility, and medication delivery time sequences. In another embodiment, the medication management unit 220 can modulate performance of a medication order based on laboratory data or other newly received patient information. In another embodiment, the medication management unit 220 can monitor the status of the infusion pumps and infusion status progress (including alarms, event logs, and pump user interface inputs), generate reports, and control software or operating code updates to the infusion pumps); and
determining that the received concentration of the drug is outside an allowable range for the concentration stored in the drug library (see at least Paragraph 36, The medication management unit 220 can perform other functions in addition to being the drug library editor. In one embodiment, the medication management unit 220 can further maintain patient safety by reviewing medication orders, drug-drug compatibility, and medication delivery time sequences. In another embodiment, the medication management unit 220 can modulate performance of a medication order based on laboratory data or other newly received patient information. In another embodiment, the medication management unit 220 can monitor the status of the infusion pumps and infusion status progress (including alarms, event logs, and pump user interface inputs), generate reports, and control software or operating code updates to the infusion pumps; Paragraph 39, Using such a drug library editor, hospital pharmacists work in collaboration with a cross-functional medical team to develop customized drug libraries and dose recommendations, which are then programmed into a database and transferred to the infusion pump. The drug libraries can incorporate both hard and soft dose limits, and can customize clinical decision rules for multiple clinical care areas (CCAs). In various applications, the Hospira MedNet™ safety software and Hospira MedNet™ Meds™ drug library editor software can be used with the Hospira Plum A+ ™ general infusion system,).
Claim 16 recites substantially similar method limitations to those of apparatus claim 6 and, as such, is rejected for similar reasons as given above.
Claim 7:
The combination of Jacobson/Eggers discloses the limitations shown in the rejection above. Jacobson further discloses the following limitations:
prompt via the one or more prompts, a user to confirm use of the automated programming data received from the server in place of the at least some parameters already received (see at least Paragraph 27, The enterprise drug library editor is typically a part of a larger suite of software applications run on or connected through a client computer to a server that has more functions such as bi-directional communications between the pump and server, as well as sophisticated logging and reporting on pump programming, user input, and operation (including but not limited to alarms, alerts, messages, overrides, program modifications, etc.). The application of the dedicated drug library editor and the enterprise drug library editor are described below in association with FIGS. 2 & 3, respectively).
Jacobson may not specifically disclose the following limitations, but Eggers as shown does:
receive scanned information from a medication container that was scanned by a scanner associated with the infusion device (see at least Paragraph 48, As with all other protocols stored in a configuration database, a stored Multi Dose 408 protocol may be selected or activated from the configuration database simply by scanning a coded drug label containing the protocol identifier (with or without instructions for deviating from the default protocol values);
send the scanned information to the server with a request to obtain the automated programming data, wherein the automated programming data is received after the scanned information is sent to the server (see at least Paragraph 35, Each protocol includes a plurality of fields of default operating parameters. In some cases an infusion protocol may include a complete detailed infusion instruction with all of the default parameter values defined. Other infusion protocols may have partially defined parameters with additional data entry required by the user at the point of care. For example, protocol A 232 of FIG. 3 includes fields of default operating parameter values and other data for controlling a medication infusion pump. The fields of this example include drug name 300, concentration 304, container size(s) 308, nominal dose rate 312, initial bolus 316, maximum dose rate 320, minimum dose rate 324, maximum cumulative dose 328, drug incompatibility 332 and an ID field, record pointer 336, for identifying or "calling" the protocol record. Each field typically includes stored default parameter values that collectively define a specific infusion protocol. Some fields, such as Drug Incompatibility 332, include a reference or link to another database or drug library containing relevant information. Such references to commonly used data libraries allow data to be shared between protocols and/or configuration databases to avoid duplicate storage and entry and to allow efficient updating of database information. Similarly, all protocols need not be stored within each configuration database. Rather, protocols from different configuration databases may be saved in a master database or library, with each individual configuration database containing reference links to particular protocols stored in the library; Paragraph 48);
determine that the infusion device already received at least some parameters for the medication via the user interface when the automated programming data is received (see at least Paragraph 36, Consequently, if the user selects a drug name, then certain parameters in the record are applied. Such parameters would typically include the drug name, delivery rate limits, units of delivery, possibly concentration and container size. The user would enter or scan in missing data such as patient weight, drug amount, diluent volume, dosage rate, total dosage and confirm the automatically selected parameters as prompted; Paragraph 48, As with all other protocols stored in a configuration database, a stored Multi Dose 408 protocol may be selected or activated from the configuration database simply by scanning a coded drug label containing the protocol identifier (with or without instructions for deviating from the default protocol values). Any missing or different values may then be entered by the user);
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the teachings of the infusion pump system and method of Jacobson with the feature of Eggers for at least the same reasons given for claim 1 above.
Claim 17 recites substantially similar method limitations to those of apparatus claim 7 and, as such, is rejected for similar reasons as given above.
Claim 8:
The combination of Jacobson/Eggers discloses the limitations shown in the rejection above. Jacobson further discloses the following limitations:
determine that the automated programming data is for changing a parameter of the infusion of the medication while the infusion is being administered to a patient, wherein identifying the deviation comprises determining, when the automated programming data is received, that the infusion is not being administered to the patient (see at least Paragraph 27, The enterprise drug library editor is typically a part of a larger suite of software applications run on or connected through a client computer to a server that has more functions such as bi-directional communications between the pump and server, as well as sophisticated logging and reporting on pump programming, user input, and operation (including but not limited to alarms, alerts, messages, overrides, program modifications, etc.). The application of the dedicated drug library editor and the enterprise drug library editor are described below in association with FIGS. 2 & 3, respectively); and
after determining that the infusion is not being administered, prompt via the one or more user prompts, a user to start or continue administering the infusion to the patient (see at least Paragraph 36, In another embodiment, the medication management unit 220 can monitor the status of the infusion pumps and infusion status progress (including alarms, event logs, and pump user interface inputs), generate reports, and control software or operating code updates to the infusion pumps).
Claim 18 recites substantially similar method limitations to those of apparatus claim 8 and, as such, is rejected for similar reasons as given above.
Claim 9:
The combination of Jacobson/Eggers discloses the limitations shown in the rejection above. Jacobson further discloses the following limitations:
resolve a plurality of deviations for a plurality of automated programming data received from the server; identify a common resolution to a common deviation of the plurality of deviations based on a plurality of user responses to user prompts for resolving the deviations (see at least Paragraph 27, bi-directional communications between the pump and server, as well as sophisticated logging and reporting on pump programming, user input, and operation (including but not limited to alarms, alerts, messages, overrides, program modifications, etc.));
receive, by the infusion device, new automated programming data for a new infusion to be administered by the infusion device; identify the common deviation in the new automated programming data; and automatically resolve the common deviation in the new automated programming data based on the identified common resolution.
Claim 19 recites substantially similar method limitations to those of apparatus claim 9 and, as such, is rejected for similar reasons as given above.
Claim 10:
The combination of Jacobson/Eggers discloses the limitations shown in the rejection above. Jacobson further discloses the following limitations:
determine that the automated programming data is for a drug to be administered to a patient after a first drug is administered to the patient (see at least Paragraph 32, Each of the infusion pumps 240 includes an operational drug library 242, with each of the operational drug libraries 242 for each individual infusion pump 240 being tailored for the patient using each individual infusion pump 240, i.e., the operational drug libraries 242 can be different from each other as required to meet the therapy needs of a particular patient, the intended use of the infusion pump, or the location of the pump or patient. The medication management system 200 can include one or more computers/servers with associated software as required for a particular application);
prompt via the one or more prompts, a user to program the infusion device to administer the first drug (see at least Paragraph 36, medication management unit 220 can modulate performance of a medication order based on laboratory data or other newly received patient information. In another embodiment, the medication management unit 220 can monitor the status of the infusion pumps and infusion status progress (including alarms, event logs, and pump user interface inputs), generate reports, and control software or operating code updates to the infusion pumps; Paragraph 54, A drug library editor user interface display screen can provide a drop-down menu or other means of selection for the drug library editor source. Then the selected drug library editor source can download the respective drug library to the target pump or pumps. In another embodiment, a special handshake between the drug library editor and the pump could identify the drug library editor source selected at the drug library editor. The download message or drug library itself could contain a code, configuration setting or direction as to where to accept the next drug library from); and
after the infusion device is programmed to administer the first drug, automatically load parameters corresponding to the automated programming data from the stored programming data (see at least Paragraph 30, The drug library includes drug and infusion pump related information, which may include but is not limited to drug name, drug class, drug concentration, drug amount, drug units, diluent amount, diluent units, dosing units, delivery dose or rate, medication parameters or limits (hard or soft), device/infuser settings and/or modes, clinical care area (CCA) designations and constraints, library version, and the like. The drug library can also include operating parameters for reporting from each of the infusion pumps back to the medication management system; Paragraph 50, the delivering an infusion 508 from the infusion pump in accordance with the first drug library further includes delivering the infusion from the infusion pump at a location such as a hospice, a nursing home, a home care environment, or other small treatment location).
Claim 20 recites substantially similar method limitations to those of apparatus claim 10 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 Joy Chng whose telephone number is 571.270.7897. The examiner can normally be reached on Monday-Friday, 9:00am-5:00pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, JASON 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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866.217.9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Joy Chng/
Primary Examiner, Art Unit 3686
Prosecution Insights