DETAILED ACTION
This office action is based on the claim(s) filed on 08/06/2026.
Claims 1-2, 7-8, 18, and 20 have been amended.
Claims 1-20 are currently pending and have been examined.
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06/24/2026 is in accordance with the provisions of 37 CFR 1.97 and are considered by the Examiner.
Claim Rejections - 35 USC § 112(a)
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim(s) 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
In order to satisfy the written description requirement, the specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. See MPEP 2161.01(1). However, generic claim language in the original disclosure does not satisfy the written description requirement if it fails to support the scope of the genus claimed, and even original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function, See MPEP 2161.01(1) citing in part Ariad, 598 F.3d at 1349 ("[A]n adequate written description of a claimed genus requires more than a generic statement of an invention's boundaries.").
Specifically, with regard to computer-implemented functional claims, the specification must provide a disclosure of the computer and the algorithm in sufficient detail to demonstrate to one of ordinary skill in the art that the inventor possessed the invention, including how to program the disclosed computer to perform the claimed function. MPEP 2161.01(1).
Claim 1 and 7, recite “in response to identifying the error while the unique identifier is presented on the display, automatically remove the unique identifier from the display and present, in place of the unique identifier, a perceivable indicator associated with the error”, for which the subject matter of the limitation was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, at the time the application was filed, had possession of the claimed invention. As best understood, it appears that there is no support for the underlined recitation in the original disclosure of the present application for this limitation. As described in applicant’s specification [0064], “The processor is further configured to replace the unique identifier with a perceivable indicator associated with a connection error in response to determining that the infusion device is not in the prepared state” which describes a programming or capability to execute when required which is different than automatic performance process. There is not explicit disclosure as filed describing the feature “automatically remove the unique identifier” as claimed.
The examiner takes the position that with respect to these limitations or features of the claims, the specification fails to provide an adequate written description of the invention to an extent that would sufficiently show that applicant was in possession of an invention that could operate as claimed. Simply disclosing a vague description, without actually explaining how to perform the function(s) claimed, results in a written description problem under 112(a). The examiner has no idea how applicant actually contemplated doing these steps because nothing is disclosed other than the broad disclosure of the specification as mentioned above.
Therefore, applicant has failed to show the actual subject matter in their possession at the time of the invention in a way sufficient to reasonably convey to one skilled in the relevant art that applicant had possession of the claimed invention at the time the application was filed. Therefore, these limitations of the claims are considered to be new matter. Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 4-11, 13-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mills et al. (US 2015/0379237 A1 – “Mills”) in view of Kelly et al. (US 2017/0061096 A1 – “Kelly”)
Regarding Claim 1 (Currently Amended), Mills teaches an infusion system comprising:
an infusion device; a network data transceiver configured to establish a data connection between the infusion device and a data network system; and a processor configured to:
present, on a display of the infusion device, a unique identifier of the infusion device Mills discloses a screen displaying an IV documentation that includes order details, status of the infusion pump, and infusion pump barcode (Mills: [0029-0030], [0043])
detect an operational parameter of the infusion device Mills discloses detecting from the infusion pump messages active alarm indicating error such as power level issue, operation issue, operation mode, and other various situations or condition etc. (Mills: [0075-0076])
determine, at the infusion device, that the infusion device is not in a prepared state to receive an automated programming request based at least in part on a correspondence between the operational parameter and an auto programming readiness criterion Mills discloses the status of an infusion pump such as if the pump is running and/or indication of connectivity state, power issue, etc. where the pump may not accept an auto-program request (Mills: [Fig. 1], [0028], [0037], [0051], [0058], [0075-0076])
identify an error associated with the infusion device not being ready to receive the automated programming request based on the correspondence between the detected operational parameter and the auto programming readiness criterion Mills discloses an error may be identified and display error code or convey a message to medical records where the error code may be associated with different issues such as an active alarm that stops or prevents delivery as such the infusion pump may not be ready for auto-programming (Mills: [Table 1], [Fig. 6], [0037], [0050-0051], [0061-0062], [0075-0076])
in response to identifying the error while the unique identifier is presented on the display, automatically remove the unique identifier from the display and present, in place of the unique identifier, a perceivable indicator associated with the error; Mills discloses the pump is programmed to output an alert error message [perceivable indicator associated with the error] substituting [remove from the display] the auto-programing screen (Mills: [Fig. 5-6], [0061-0062])
automatically adjust the infusion device to correct the error based on the auto programming readiness criterion Mills discloses based on the identified error, the infusion pump may automatically reject the auto-programming and an action is suggested for adjusting the program and clearing the error [correct the error] or the pump may allow the auto-programming order to continue after displaying an error, where different action(s) is/are associated with the different error type(s) such as the error code may be an active alarm that stops or prevents delivery or line cannot be interrupted, or does not match drug library information, checksum failure or handshake failure, etc. (Mills: [Fig. 3], [Table 1], [0037], [0041], [0050], [0052-0053], [0069], [0086])
cause the infusion device to administer a medical fluid specified in an infusion order to a patient after the infusion device has been adjusted to correct the error Mills discloses when the error is corrected, for example matching drug order, the infusion pump my start the delivery to the patient (Mills: [Fig. 3, 6], [Table 1], [0050-0052], [0088]).
Mills discloses displaying documentation to include instructions to scan infusion pump barcode label on the pump [0029-0030], [0043]. However, Mills does not expressly disclose:
present unique identifier on a display of the infusion device as underlined.
Kelly teaches
suppress presentation, on a display of the infusion device, of a unique identifier from the display of the infusion device Kelly discloses based on determine established connection, interface of the infusion pump displaying a digital barcode [unique identifier] (Kelly: [Fig. 3-4], [0006], [0015]).
Mills discloses tracking infusion pumps to identify status of the pump(s) such as presenting error messages and linking medication order(s) to adjust settings of the pump and instruct to scan the infusion pump barcode. Kelly discloses tracking infusion pump communication with hospital system and display barcode on the pump interface when connection is established. Therefore, it would be obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have of Mills to incorporate presenting a pump identifier on a screen, as taught by Kelly which may avoid errors that affect timeliness and effectiveness of patient care and frustration of clinician, patient, and family members of the patient (Kelly: [0014]).
Regarding Claim 2 (Currently Amended), the combination of Mills and Kelly teaches the infusion system of claim 1, wherein the error comprises a connection error associated with the data connection between the infusion device and the data network system Mills discloses displaying error message on infusion pump display screen when not able to perform an action due to network issue and verification of network connection on the pump (Mills: [0028], [0051], [0058], [0086]).
Regarding Claim 4 (Original), the combination of Mills and Kelly teaches the infusion system of claim 1, further comprising an infusion module in data communication with the infusion device, and wherein the processor is further configured to determine whether the infusion module is in a prepared state, wherein the unique identifier is presented if the infusion module is in the prepared state Mills discloses a MMU server comprising a drug library [infusion module] comprising drug information such as ID, strength, volume, etc., in communication with the scanned infusion pump (Mills: [0033]). Kelly discloses scanning a barcode used by a clinician to scan a medical device/infusion device via a graphical representation of a barcode on a display of the infusion device, wherein the barcode is not provided [not presenting] via the user interface if communication has not been established between the medical device and EMR [not in the prepared state] (Kelly: [0005], [0030], [0034], [0039]-[0041]).
Therefore, it would be obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have of Mills to incorporate presenting a pump identifier when connection and/or pump in prepared state, as taught by Kelly which may avoid errors that affect timeliness and effectiveness of patient care and frustration of clinician, patient, and family members of the patient (Kelly: [0014]).
Regarding Claim 5 (Original), the combination of Mills and Kelly teaches the
infusion system of claim 1, wherein the infusion device comprises one of: a volumetric infusion pump or a syringe infusion pump Mills discloses an infusion pump used to deliver intravenous fluid(s) and/or medications (e.g., Dopamine) [volumetric infusion pump] (Mills: [Fig. 4-6], [0016-0017], [0065]).
Regarding Claim 6 (Currently Amended), the combination of Mills and Kelly teaches the infusion system of claim 1, wherein the processor is further configured to, while the infusion device is in the prepared state:
present, on the display of the infusion device, the unique identifier of the infusion device; Mills discloses a screen displaying an IV documentation that includes order details, status of the infusion pump, and infusion pump barcode (Mills: [0029]-[0030]). Kelly discloses interface of the infusion pump displaying a digital barcode [unique identifier] (Kelly: [Fig. 3-4], [0006], [0015]). The motivations to combine the above-mentioned references are discussed in the rejection of claim 1, and incorporated herein.
wait for an indication that the unique identifier of the infusion device was scanned by a scanner to associate the infusion device with an infusion order Mills discloses the barcode of the infusion pump is scanned by a scanner and bundles the information containing the medical device identification information with request containing medication infusion order information details (Mills: [0030]-[0031], [0041], [0043])
receive from a data network system, at the infusion device, in response to receiving the indication, configuration information associated with the infusion order; Mills discloses infusion pump delivery parameters or settings are mapped or converted from corresponding order information details of the program pump request such as drug type, strength, duration, etc. and based on the scanned information, transmitting auto-programming for infusion pump setting based on the received order (Mills: [0032]-[0035], [0045])
automatically configure the infusion device to cause infusion of the medical fluid specified in the infusion order to the patient based on parameters of the infusion order provided by the received configuration information Mills discloses once detecting infusion pump condition information are satisfied according to program pump request, the infusion pump automatically start the requested infusion auto-program may begin delivering fluid according to the programmed settings (Mills: [0035]-[0036], [0049], [0042]).
Regarding Claim 7 (Currently Amended), Mills teaches a method of ensuring an infusion device is in a prepared state to perform steps associated with programming an infusion and executing a programmed infusion, Mills discloses availability of an infusion pump to perform programming (Mills: [0029], [0051], [0058]), the method comprising:
the claim limitations is/are analogous to the limitations in Claim 1. As such, claim 7 is/are rejected for substantially the same reasons given for claim 1, and is incorporated herein.
Regarding Claim 8 (Currently Amended), the combination of Mills and Kelly teaches the method of claim 7, wherein the prepared state comprises the infusion device is being in data communication with a coordination engine, an infusion system server, and an online drug library Mills discloses medication management system (MMS) comprising a medical management unit (MMU) server with a drug library is installed on the MMU server, where MMU server may monitor, coordinate and communicate with many infusion pumps (Mills: [Fig. 1], [0015], [0019], [0022]).
Regarding Claim 9 (Original), the combination of Mills and Kelly teaches the method of claim 7, wherein the method further includes: in response to determining that the infusion device lacks a data connection between the infusion device and a data network system, displaying, at a user interface of the infusion device, a prompt for an input to cause the infusion device to establish a data connection to the data network system Mills discloses screen of infusion pump may provide the caregiver with instructions [displaying a prompt] like to scan the infusion pump barcode or identify whether the pump is running or stopped [connection] (Mills: [0029]). Kelly discloses when the infusion device has not established communication [lacks a data connection], clinical user may need to scan a patient or medication [input] in order to establish connection with the network (Kelly: [0041]).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 7, and incorporated herein.
Regarding Claim 10 (Original), the combination of Mills and Kelly teaches the method of claim 7, further comprising: determining an operational status of the infusion device and wherein the operational status of the infusion device indicates an availability of the infusion device to perform the infusion order Mills discloses determining error indicating pump channel is in use and if not currently in user [availability of the infusion device], the pump verify and start the infusion program comprising the order (Mills: [0053], [0085]).
Regarding Claim 11 (Original), the combination of Mills and Kelly teaches the method of claim 10, wherein the unique identifier is presented when an operational status indicates that the infusion device is operational, and the infusion device is not undergoing programming or executing a bolus or secondary infusion Mills discloses an error presented when the infusion pump is not ready for accepting actions or instructions indicating the pump channel is not cleared and/or such that the line is busy/in use (Mills: [0053] [0074], [0085]).
Regarding Claim 13 (Original), the combination of Mills and Kelly teaches the method of claim 7, wherein the infusion device comprises a plurality of infusion pumps, and the unique identifier of the infusion device is associated with a selected one of the plurality of infusion pumps that is available to receive the infusion order Mills discloses scanning a barcode associated with a selected infusion pump, where the MMU server coordinate and communicate with a plurality of infusion pumps and where a pump determined free of error indicating available to receive programming/ medication order (Mills: [0022], [0030], [0043], [0051]).
Regarding Claim 14 (Original), the combination of Mills and Kelly teaches the method of claim 13, wherein: prior to presenting the unique identifier of the infusion device associated with the selected one of the plurality of infusion pumps on the display of the infusion device, displaying a barcode code icon next to a softkey adjacent the selected one of the plurality of infusion pumps; receiving a selection of the softkey; and in response to receiving the selection of the softkey, initiating an auto programming request Mills discloses displaying a medication infusion delivery channels and selecting corresponding soft key or button for starting the programming the infusion pump where each delivery channel is associated with a barcode that may be scanned by a caregiver (Mills: [Fig. 4], [0030], [0043], [0057], [0059], [0064]).
Regarding Claim 15 (Original), the combination of Mills and Kelly teaches the method of claim 7, wherein an electronic medical records storage and retrieval system receives the infusion order and transmits an auto programming request to a coordination engine in a data network system upon receiving information contained in the unique identifier of the infusion device Mills discloses infusion pump delivery parameters or settings are mapped or converted from corresponding order information details of the program pump request such as drug type, strength, duration, etc. and based on the scanned information, transmitting auto-programming for infusion pump setting based on the received order (Mills: [0032]-[0035], [0039], [0044]-[0046]).
Regarding Claim 16 (Original), the combination of Mills and Kelly teaches the method of claim 15, wherein the coordination engine, a drug library deployed to a care facility internal network and an infusion system server are in data communication Mills discloses medication management system (MMS) comprising a medical management unit (MMU) server with a drug library is installed on the MMU server, where MMU server may monitor, coordinate and communicate with many infusion pumps (Mills: [Fig. 1], [0015], [0019], [0022]).
Regarding Claim 17 (Original), the combination of Mills and Kelly teaches the method of claim 7, further comprising: in accordance with a determination that a security certificate associated with a data connection between an infusion system server in a data network system and a coordination engine in the data network system is invalid, generating an alert indicating that the unique identifier of the infusion device will not be presented on the display of the infusion device for scanning by a scanner Kelly discloses label component does not provide digital barcode on the device display but provide status of the infusion workflow on the display of the infusion device when the requirements such as communication not established (Kelly: [0041]).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 7, and incorporated herein.
Regarding Claim 18 (Currently Amended), the claim limitations is/are analogous to the limitations in Claim 2. As such, claim 18 is/are rejected for substantially the same reasons given for claim 2, and is incorporated herein.
Regarding Claim 20 (Currently Amended), the claim limitations is/are analogous to the limitations in Claim 6. As such, claim 20 is/are rejected for substantially the same reasons given for claim 6, and is incorporated herein.
Claims 3 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Mills et al. (US 2015/0379237 A1 – “Mills”) in view of Kelly et al. (US 2017/0061096 A1 – “Kelly”) in view of Kamen et al. (US 2019/0189272A1 – “Kamen”)
Regarding Claim 3 (Original), the combination of Mills and Kelly teaches the
infusion system of claim 1, wherein the prepared state includes an active connection to an infusion pump fleet management server, the infusion device is in an operational state, and a security certificate associated with the infusion device that is not expired Mills discloses detecting connectivity signal verified by a connection icon on an infusion pump [prepared state] which indicates an active connection to an MMU server and determines if the pump is engaged in delivering medication [operational state] where the MMU server my support up to one thousand infusion pumps concurrently [infusion pump fleet management server] (Mills: [Table 1], [0024], [0028], [0053], [0058], [0085]).
However, the combination of Mills and Kelly does not disclose:
security certificate associated with the infusion device.
Kamen teaches
quality manage provides status of the fleet of devices such as hardware, software updates and detect if new security certificate such that if the certificate is still valid or expired [is not expired] (Kamen: [Tale 1], [0237]).
Therefore, it would be obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have of Mills and Kelly to incorporate detect validity of security certificate, as taught by Kamen which help improving efficiency of care by collecting all infusion pump(s) relevant information (Kamen: [0119]).
Regarding Claim 19 (Original), the claims limitations is/are analogous to the limitations in Claim 3. As such, claims 19 is/are rejected for substantially the same reasons given for claim 3, and is incorporated herein.
Claims 12 is rejected under 35 U.S.C. 103 as being unpatentable over Mills et al. (US 2015/0379237 A1 – “Mills”) in view of Kelly et al. (US 2017/0061096 A1 – “Kelly”) in view of Borges et al. (US 2012/0241525 A1 – “Borges”)
Regarding Claim 12 (Original), the combination of Mills and Kelly teaches the
method of claim 7, wherein the unique identifier of the infusion device comprises a two-dimensional barcode that is displayed on a liquid crystal display (LCD) of the infusion device
However, the combination of Mills and Kelly does not expressly disclose:
a two-dimensional barcode
Borges discloses an infusion pump LCD display displaying a 2-D barcode (Borges: [0011]-[0012]).
Therefore, it would be obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have the barcode displayed on a screen of Mills and Kelly to incorporate 2D barcode, as taught by Borgos which helps correlating barcode medical administration system with infusion pump (Borgos: [0001]).
Furthermore, "a two-dimensional barcode that is displayed on a liquid crystal display (LCD) of the infusion device " can be construed as intended use without patentable weight.
Response to Arguments
Applicant's arguments filed 08/06/2026 have been fully considered by the Examiner and addressed as the following:
In the remarks, Applicant argues the substance:
Applicant's arguments with respect to the Double Patenting rejection on page 7.
In response to the Terminal Declaimer filed 08/06/2026 and approved, Examiner withdraws the double patenting rejection.
Applicant's arguments with respect to the 35 U.S.C. § 103 rejection on page 7-9.
On page 8 of the remarks, the Applicant argues “Applicant respectfully submits that the applied references, alone or in combination, are not understood to disclose or teach the features of independent Claim 1 ... Neither Mills nor Kelly teaches or suggests the features of amended Claim 1...”, Examiner respectfully disagree. Although the Applicant argument is/are directed to a newly added feature, Examiner has introduced sections in Mills and Kelly disclosing, under BRI, the argued amended feature.
Hence, Examiner remains the 103 rejections of claims which have been updated to address Applicant's amendments and remarks in the above Office Action.
Prior Art Cited but not Applied
The following document(s) were found relevant to the disclosure but not applied:
US 2020/0027548- “Xavier” discloses connectivity of plurality of infusion pumps in a clinical environment and updating software such as drug library.
The references are relevant since it discloses identification of a medical device and patient treatment information via communication with network environment.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALAAELDIN ELSHAER whose telephone number is (571)272-8284. The examiner can normally be reached M-Th 8:30-5:30.
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, MAMON OBEID can be reached at Mamon.Obeid@USPTO.GOV. 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.
/ALAAELDIN M. ELSHAER/Primary Examiner, Art Unit 3687
Prosecution Insights