computDETAILED 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 .
Receipt of Applicant’s Amendment filed February 2, 2026, is acknowledged.
Response to Amendment
Claims 1, 9, and 16 have been amended. Claim 8 has been canceled. Claims 17-20 are new. Claims 1-7 and 9-20 are pending and are provided to be examined upon their merits.
Response to Arguments
Applicant’s arguments with respect to claims 1-7 and 9-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. A response is provided below in bold where appropriate.
Applicant argues 35 USC §101, starting pg. 8 of Remarks:
Claim 1-16 are rejected under 35 U.S.C. 101 as allegedly patent ineligible. Of course, the claims recite statutory subject matter, claims 1-15 (and 17-20) being directed to a device and claim 16 directed to a method. The allegation is made, however, that the claims recite an abstract idea without significantly more.
As the Federal Circuit has pointed out on numerous occasions, it is necessary to look both at the claim as a whole and at the individual elements. MCRO, Inc. v. Bandai Namco Games America, Inc., 837 F.3d 1299, 1312 (Fed. Cir. 2016). In fact, as recognized in Bascom Global Internet Services Inc. v. AT&T Mobility LLC, 827 F.3d 1341, 1350 (Fed. Cir. 2016), patent eligibility can be found in the non-conventional and non-generic arrangement of known, conventional pieces. Viewed as a whole with the language read properly in context, claim 1 provides a device (and claim 16 provides a method) that reduces noise pollution. The device addresses the problem of alarms that compete with the operational setup of the medical device, and addresses this problem in an unconventional manner, one not previously known in the art.
In MCRO and Bascom, there were technical improvements to technology itself (3D animation, computer Internet filtering).
Regarding reduces noise pollution, there may or may not be a benefit (an effect or result). For example, there are no sequence of steps that guarantee noise pollution is reduced.
From MPEP 2106.05(f) (2)
“(3) The particularity or generality of the application of the judicial exception.
A claim having broad applicability across many fields of endeavor may not provide meaningful limitations that integrate a judicial exception into a practical application or amount to significantly more. For instance, a claim that generically recites an effect of the judicial exception or claims every mode of accomplishing that effect, amounts to a claim that is merely adding the words “apply it” to the judicial exception. See Internet Patents Corporation v. Active Network, Inc., 790 F.3d 1343, 1348, 115 USPQ2d 1414, 1418 (Fed. Cir. 2015) (The recitation of maintaining the state of data in an online form without restriction on how the state is maintained and with no description of the mechanism for maintaining the state describes “the effect or result dissociated from any method by which maintaining the state is accomplished” and does not provide a meaningful limitation because it merely states that the abstract idea should be applied to achieve a desired result). See also O’Reilly v. Morse, 56 U.S. 62 (1854) (finding ineligible a claim for “the use of electromagnetism for transmitting signals at a distance”); The Telephone Cases, 126 U.S. 1, 209 (1888) (finding a method of “transmitting vocal or other sound telegraphically ... by causing electrical undulations, similar in form to the vibrations of the air accompanying the said vocal or other sounds,” to be ineligible, because it “monopolize[d] a natural force” and “the right to avail of that law by any means whatever.”).
Respectfully, there are no claimed steps of how a state of reduced noise is accomplished and mechanism for maintaining the state. For example, programming a device to not send an alarm to reduce noise is similar to programming a computer to send smaller messages in order to improve bandwidth. Even if noise or bandwidth was improved, this is an effect or result, not an improvement to technology itself.
As stated in MCRO (cited above), a patent may issue "for the means or method of producing a certain result, or effect, and not for the result or effect produced." To be sure, claim 1 recites a device that produces a certain result or effect, but importantly claim 1 does not recite merely the result or effect produced (a reduction in noise pollution). As such, claim 1 should be considered patentable.
From McRO…
“By incorporating the specific features of the rules as claim limitations, claim 1 is limited to a specific process for automatically animating characters using particular information and techniques and does not preempt approaches that use rules of a different structure or different techniques. See Morse, 56 U.S. at 113. When looked at as a whole, claim 1 is directed to a patentable, technological improvement over the existing, manual 3-D animation techniques. The claim uses the limited rules in a process specifically designed to achieve an improved technological result in conventional industry practice. Alice, 134 S. Ct. at 2358 (citing Diehr, 450 U.S. at 177). Claim 1 of the ’576 patent, therefore, is not directed to an abstract idea.” (pg. 27)
Therefore, McRO improved 3-D animation technology itself.
Bascom Global Internet Services, Inc. v. AT&T Mobility LLC, 827 F.3d 1341 (Fed. Cir. 2016) (cited above) may be instructive here as well. In Bascom, the Federal Circuit found that it was error to merely recognize that each claim element may be, by itself, known in the art, and fail to appreciate the "non-conventional and non-generic arrangement of known, conventional pieces."Id. at 1350. Despite the fact that the specification described the claimed hardware as "well-known generic computer components" and that "[f]iltering content on the Internet was already a known concept", the Federal Circuit found that "the patent describes how its particular arrangement of elements is a technical improvement over prior art ways of filtering such content."Id. On this basis, the Federal Circuit concluded that even though the claims may have been directed to the abstract idea of filtering content, the ordered combination of claim limitations transform the abstract idea into a particular, practical application.
In accord with Bascom, even if the Office were to take the position that the structure of the system and the medical device was conventional, the unconventional operation of the medical device in combination with the recited structure of the controller to provide a modified operation should be sufficient to transform the medical device into a particular, practical application.
From Bascom…
“Similarly, although the invention in the ’606 patent is engineered in the context of filtering content, the invention is not claiming the idea of filtering content simply applied to the Internet. The ’606 patent is instead claiming a technology-based solution (not an abstract-idea-based solution implemented with generic technical components in a conventional way) to filter content on the Internet that overcomes existing problems with other Internet filtering systems. By taking a prior art filter solution (one-size-fits-all filter at the ISP server) and making it more dynamic and efficient (providing individualized filtering at the ISP server), the claimed invention represents a “software-based invention[] that improve[s] the performance of the computer system itself.” See Brief for United States as Amicus Curiae in Support of Respondents at 30–31, Alice Corp. Pty. Ltd. v. CLS Bank Int’l, 134 S. Ct. 2347 (2014) (No. 13-298), 2014 WL 828034.“ (pg. 18)
Therefore, Bascom improved performance of the computer system itself with their Internet filtering.
Both McRO and Bascom, with their claimed steps assured a technical improvement. Select and operate a medical device using predetermined alarm modes does not provided assurance that noise is reduced.
Specifically, the claimed device determines in which operational setup of a plurality of predetermined operational setups the medical device is operating, determines a quality of service of a communication with the another device via the communication interface, selects one of the plurality of predetermined alarm modes based on the determined operational setup and the determined quality of service, and operates the medical device in the selected one of the plurality of predetermined alarm modes. Further, the plurality of predetermined alarm modes include a suppression mode, in which alarm messages received and processed by the controller do not produce an alarm, and a perception mode, in which the alarm messages received and processed by the controller produce an alarm.
While it has been suggested that this could be carried out on pen and paper, or within the mind of an individual, this is not correct. One could not determine the operational setup of a medical device in their mind, nor could they determine a quality of service of a communication in their mind. Further, one could not cause a medical device to suppress an alarm or produce an alarm with mere mental power. These steps of the operation of the device require the operation of the structured controller recited therein in combination with the medical device, and cannot be characterized as mere mental processes.
Respectfully, Applicant’s specification and claims show the process to be mental. For example, the “predetermined alarm modes” were thought out or created in someone’s mind before the modes were even implemented. The select one of the predetermined alarm modes step required someone to mentally select before actually selecting or programming a device.
As stated in the August 4 Subject Matter Eligibility Memorandum, "a claim does not recite a mental process when it contains limitation(s) that cannot practically be performed in the human mind, for instance when the human mind is not equipped to perform the claim limitation(s)." See August 4 Memorandum, page 2. The fact that the claim language may embrace more than one narrowly defined technology to accomplish actions that cannot be performed in the human mind does not make the claims patent ineligible, where the human mind is not equipped to perform the claim limitation(s).
The step in claim 16 of “operating the medical device in the selected one of the plurality of predetermined alarm modes,” is recited at a high level of generality. The medical device is a generic device and could amount to operating a computer based on a selected mode. Special purpose computers have been shown not to be enough (see MPEP 2106 I and Alappat)
For these reasons, the claims recite patent eligible subject matter.
Based on the above response, the rejection is respectfully maintained but modified for the claim amendments.
Applicant argues 35 USC §103, starting pg. 11 of Remarks:
Claims 1-16 are rejected under 35 U.S.C. 103 as allegedly unpatentable over US Pub. No. 2007/0251835 to Mehta et al. The applicant has amended claims 1 and 16, and disagrees with the rejection as follows.
Amended claim 1 recites a medical device including a communication interface communicatively couplable or coupled with another device, and a controller configured to be selectively operated in one of a plurality of predetermined alarm modes.
The controller is configured to determine in which operational setup of a plurality of predetermined operational setups the medical device is operating, determine a quality of service of a communication with the another device via the communication interface, select one of the plurality of predetermined alarm modes based on the determined operational setup and the determined quality of service, and operate the medical device in the selected one of the plurality of predetermined alarm modes
Further, the plurality of predetermined alarm modes includes a suppression mode, in which alarm messages received and processed by the controller do not produce an alarm, and a perception mode, in which the alarm messages received and processed by the controller produce an alarm.
From Mehta…
“Network communication process 1000 may be performed by a transmitting device that is within a local medical device system, e.g., an infusion system having an infusion pump that controls the infusion of fluid into the body of a user. For example, the transmitting device may be any local device within the local infusion system, such as a bedside monitor device, a hospital monitor device, a physiological characteristic meter, a physiological characteristic sensor transmitter, a remote controller, a handheld monitor/controller, the infusion pump itself, or the like. Process 1000 may begin when the transmitting device obtains (either internally, from another device, or from a user) or generates a notification (task 1002) related to the operation of the infusion pump and/or related to the operation of another local device. As used here, a notification may be any signal, alert, alarm, content, data, or information that is intended to be forwarded to another device, or is utilized as a prompt or a trigger to invoke a response by the transmitting device.” [0131]
Therefore, an infusion pump can receive notification such as an alert or alarm.
Pump controller that controls the operation of the pump…
“FIG. 5 is a schematic representation of a medical device system monitor 500 configured in accordance with an example embodiment of the invention. Monitor 500 represents a generalized embodiment that may be realized as a bedside monitor, a hospital monitor, or a handheld monitor/controller, depending upon its specific configuration. In this example, monitor 500 generally includes a local device interface 502, a local communication module 504, a display element 506, one or more user interface features 508, a network communication module 510, a network interface 512, a processing architecture 514, and a suitable amount of memory 516. If monitor 500 is implemented as a hospital monitor, then it may also include an infusion pump 518 and a pump controller 520 that controls the operation of infusion pump 518 (these elements are depicted in dashed lines to indicate their optional nature). The elements of monitor 500 may be coupled together via a bus 522 or any suitable interconnection architecture.” [0082]
Alert or alarm enable or disable instruction (therefore, operation) for the local device…
“Processing architecture 514 may also be configured to interpret and process incoming information, data, and content that is conveyed in network communications generated by an originating device that is external to the local infusion system. Referring to FIG. 1, the originating device may be any network device 104, including a networked monitor device. Such incoming network information may include, without limitation: programming data for a local device within the infusion system; an activation instruction for an infusion pump or another local device within the infusion system; a status request for a local device within the infusion system; a request for physiologic data of the user; an alert or alarm enable or disable instruction for a local device within the infusion system (which may be processed by monitor 500 and/or routed by monitor 500 to the appropriate local device); advisory information for the patient (e.g., a notification to place an order for supplies, a reminder to schedule a doctor's appointment, a reminder to schedule or automatically execute a data download for analysis by a caregiver, a notification to perform routine diagnostics, either manually or remotely via a network connection); or the like.” [0087]
As such, amended claim 1 relates operating a medical device in one of a plurality of predetermined alarm modes. Based on the criteria of an operational setup and a determined quality of service of a communication with another device, a respective alarm mode is selected, and alarms are suppressed or perceivable. All these steps are performed at the pump level and affect the generation or suppression of alarms at the pump level.
From Mehta…
“Network communication process 1000 may be performed by a transmitting device that is within a local medical device system, e.g., an infusion system having an infusion pump that controls the infusion of fluid into the body of a user. For example, the transmitting device may be any local device within the local infusion system, such as a bedside monitor device, a hospital monitor device, a physiological characteristic meter, a physiological characteristic sensor transmitter, a remote controller, a handheld monitor/controller, the infusion pump itself, or the like. Process 1000 may begin when the transmitting device obtains (either internally, from another device, or from a user) or generates a notification (task 1002) related to the operation of the infusion pump and/or related to the operation of another local device. As used here, a notification may be any signal, alert, alarm, content, data, or information that is intended to be forwarded to another device, or is utilized as a prompt or a trigger to invoke a response by the transmitting device.” [0131]
The above notification (alert or alarm) can be at the infusion pump itself for operation of the infusion pump.
Thus, the claimed subject matter has the advantage of reducing noise pollution in the context of the application of medical devices. This is achieved by recognizing that certain operational setups require stricter alarm reporting and acknowledgement than other operational setups. While a further limiting factor of an automatic alarm reduction at the bedside is the reliability of communication between the first medical device and the other (second) device, both criteria are considered.
The claimed subject matter is neither disclosed nor taught by Mehta et al.
Mehta et al. discloses a medical device system where system data is transmitted and received over wireless links. In particular, Mehta et al. classifies the links into reliable links and intermittent or unreliable links. See, e.g., Mehta et al., paras. [0168], [0262]. Mehta et al. then describes a system that differs in its operation depending on whether the system expects to be using a reliable link or an unreliable link.
Mehta et al. states that the allegedly corresponding medical device that "can be configured to support both reliable wireless links (where missing or unacknowledged packets result in the generation of alarms) and unreliable wireless links (where missing or unacknowledged packets do not result in the generation of alarms) in a dynamically switching manner and in response to various criteria." Mehta et al., para. [0263]. Thus, depending on whether the links are expected to be reliable or unreliable, alarm signals may or may not be generated for missing packets.
As such, Mehta et al. does not disclose or teach the recited alarm modes selected based on determined operational setup and quality of service. That is, Mehta et al. does not consider both operational setup and quality of services to select an alarm mode that then determines if alarm messages received and processed by the controller produce an alarm (perception mode) or do not (suppression mode). Rather, Mehta et al. accommodates unreliable links by not generating alarms if packets are missing.
Applicant above is arguing that Mehta et al. does not teach select an alarm mode based on determined operational setup and determined quality of service.
First, Applicant’s specification teaches various operational setup examples (pp. 10-12), in Figures 3-7.
The operational setup can be:
An operating room (Setup A);
A wired connection at a ward level (Setup B);
A wireless system in a private network (Setup C);
A wireless setup with an HL7 network (Setup D);
Two devices connected to a server via a bridging network (Setup E).
Therefore, operational setup can be many things that includes location/situation of a device or type of network.
From Applicant’s specification…
“Fig. 5 shows another exemplary operational setup C. The operational setup C is that of a wireless virtual switching system in a private network, but with low criticality. Several first medical devices 1A at the patient's bedside are connected wirelessly to the monitoring network 6. A second device 2 in the form of a standard PC with monitor. Due to the wireless connection, the QoS may be low. However, since also the criticality of the operational setup C is low, an alarm mode with no or attenuated alarm levels at the first medical devices 1A and alarm forwarding to the second device 2 with a DIS alarm reporting system are selected. HTTPS may be used as protocol for the alarm reporting. The communications may be controlled by a server 7.” (pg. 11, lines 16-24(
The above operational setup is a wireless network, and due to the wireless connection, QoS may be low. An alarm mode is set with no or attenuated alarm levels.
Mehta teaches:
Wireless medical device configured to support (operational setup) wireless links where the links may be reliable or unreliable (QoS). Missing packets in the reliable network (QoS) can result in generation of an alarm (therefore, alarm mode) or if the wireless network is unreliable (QoS) no alarm…
“An embodiment of a wireless medical device as described herein can be configured to support both reliable wireless links (where missing or unacknowledged packets result in the generation of alarms) and unreliable wireless links (where missing or unacknowledged packets do not result in the generation of alarms) in a dynamically switching manner and in response to various criteria. In practice, unreliable links may be associated with a "best effort" quality of service. One example of a dynamically switchable wireless link is the wireless link between an infusion pump and a bedside monitor for the pump. Although this link may be a reliable link while the patient is asleep and in close proximity to the bedside monitor, during the day the link could switch to a best effort link to accommodate periods of time when the patient might be outside of the reliable range of the bedside monitor. When the patient (and the infusion pump) returns within range of the bedside monitor, the link can switch back to a reliable link and accumulated patient data can be transferred in a batch mode.” [0262]
Therefore, if the network is wireless (operational setup) and reliable (QoS), but there is a problem, the alarm mode is to send an alarm. The above is teaching Applicant’s claim.
From Mehta…
“A device in the network may also be configured to not sound an alarm. This can be performed on a pre-programmed time schedule, such as night versus day, or as required at any time. In the latter scenario, to prevent accidentally silencing a device permanently, the device may be designed to switch to the pre-programmed mode at the prescribed time.” [0255]
Therefore, the device is programmed with alarm modes.
As such, Mehta et al. does not disclose or teach the subject matter of the amended claim 1.
While claim 16 does not recite exactly the same subject matter as claim 1, claim 16 recites language similar to that cited above. Consequently, applicant submits that the arguments made above relative to claim 1 apply with equal force to claim 16. Therefore, the rejection of claim 16 should be withdrawn.
For the above reasons, the Examiner maintains the rejection but provides additional prior art to further teach the amended and new claims.
Claims 2-7, 9-15, and 17-20 depend from claim 1. Because claim 1 is allowable, the dependent claims are also allowable for at least this reason. Claims 2-7, 9-15, and 17-20 recite additional language that may further distinguish the cited references.
For the above reasons, the Examiner maintains the rejection. Art is cited for the new claims.
For example, claims 17-20 set out additional details of the operational setups used in claim 1 to select the alarm modes. These details may include how the setups include characteristics of a clinical situation, or a criticality of a care setup (from the standpoint of caregiver attention). The details may also include how the determination of the operational setup of the medical device is made. These additional details may further distinguish Mehta et al.
Prior art is cited for the new claims.
Claim Rejections - 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-7 and 9-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1-16 are directed to a system or method, which are statutory categories of invention. (Step 1: YES).
The Examiner has identified method Claim 16 as the claim that represents the claimed invention for analysis and is similar to system Claim 1.
Claim 16 recites the limitations of:
A method for operating a medical device, the medical device comprising a communication interface communicatively couplable or coupled with another device and a controller configured to be selectively operated in one of a plurality of predetermined alarm modes, the method comprising:
determining in which operational setup of a plurality of predetermined operational setups the medical device is operating;
determining a quality of service of a communication with the another device via the communication interface;
selecting one of the plurality of predetermined alarm modes based on the determined operational setup and the determined quality of service; and
operating the medical device in the selected one of the plurality of predetermined alarm modes,
wherein the plurality of predetermined alarm modes comprises a suppression mode, in which alarm messages processed by the controller do not produce an alarm, and a perception mode, in which the alarm messages processed by the controller produce an alarm.
These above limitations, under their broadest reasonable interpretation, cover performance of the limitation as mental processes. The claim recites elements, highlighted in bold above, which covers performance of the limitation that can be concepts performed in the mind of a person or with pen and paper. A person can determine an operational setup of medical devices by knowing where the device is operating (e.g. critical care unit), a person can determine by viewing physical connections between devices a quality of service (e.g., is there a cable between the devices, do the devices show a wireless connection), a person can select an alarm mode (e.g., select with pen and paper an alarm mode). A person can mentally and with pen and paper predetermine alarm modes that will not (suppression mode) and will (perception mode) produce an alarm. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation as a mental process, then it falls within the “Mental Processes” grouping of abstract ideas. See also MPEP 2106.04(a)(2) III C where using a generic computer was not enough to make abstract claims statutory. Accordingly, the claim recites an abstract idea. Claim 1 is also abstract for similar reasons. (Step 2A-Prong 1: YES. The claims are abstract)
This judicial exception is not integrated into a practical application. In particular, the claims only recite: medical device, communication interface, another device, controller (Claim 1); medical device, communication interface, another device (Claim 16). The computer hardware is recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts no more than mere instructions to apply the exception using a generic computer component. The medical device is a generic device recited at a high level of generality (see pg. 7, lines 22-29 where medical device comprises a controller, communication interface, and sound emitting device). Another device could be a computer (pg. 6, lines 25-30) and Fig’s 2-4, ref. 2 in care giver room, or an undefined mobile caregiver device (pg. 5, lines 24-27). Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore claims 1 and 16 are directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additional claimed elements are not integrated into a practical application)
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a computer hardware amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Thus claims 1 and 16 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent claims 2-15 and 17-20 further define the abstract idea that is present in their respective independent claim 1 and thus correspond to Mental Processes and hence are abstract for the reasons presented above. The dependent claims do not include any additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. The claims themselves are either abstract or further limit abstract elements. Claim 2 recites an infusion device, which is recited and applied at a high level of generality. Claims 3, 4, 11-15 recite the “another device” which is a generic device applied at a high level of generality. Claim 6 recites display and claim 7 recites sound emitting device which are generic devices applied at a high level of generality. Claim 10 recites “predetermined device” which is a generic device applied at a high level of generality. Claim 15 recites “caregiver device” and “mobile device” which are generic devices applied at a high level of generality. Claims 19 and 20 recite medical device or devices which are generic devices recited at a high level of generalty. Therefore, the claims 2-15 and 17-20 are directed to an abstract idea. Thus, the claims 1-7 and 9-20 are not patent-eligible.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 U.S.C. §112(a) or §112 1st paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-7 and 9-16 are rejected under 35 U.S.C. 103 as being unpatentable over Pub. No. US 2007/0251835 to Mehta et al. in view of Pub. No. US 2020/0306443 to Day et al.
Regarding claims 1 and 16
(claim 1) A medical device comprising a communication interface communicatively couplable or coupled with another device, and a controller configured to be selectively operated in one of a plurality of predetermined alarm modes, wherein the controller is further configured to:
determine in which operational setup of a plurality of predetermined operational setups the medical device is operating;
Mehta et al. teaches:
Control of infusion pump (medical device) via configured user interface…
“In practice, operation of infusion pump 128 may be remotely controlled by command display controller 138 (which may be realized as a handheld monitor/controller for infusion pump 128), by remote control device 134, and/or by or monitor 140. In one example embodiment, BG meter 136 may include the functionality of a controller device such that both components share a single housing. One such BG meter is described in U.S. patent application Ser. No. 11/204,667, titled "Controller Device for an Infusion Pump," the content of which is incorporated by reference herein. Control of infusion pump 128 may also be possible via a suitably configured user interface located at infusion pump 128 itself.” [0062]
Example of infusion device with calibrate and activate mechanism (plurality of predetermined operational setups and operation of the device)….
Local devices can process the received sensor data in an appropriate manner. For example, portable display device 132, remote control device 134, BG meter 136, command display controller 138, monitor 140, or infusion pump 128 may display the current BG level derived from the received sensor data and/or generate an alert or otherwise indicate low or high BG levels. As another example, BG meter 136 or infusion pump 128 may process the received sensor data for purposes of calibration. As yet another example, infusion pump 128 may be configured to activate its infusion mechanism in response to the received sensor data. Moreover, sensor data could be processed in one or more of the local devices and/or in one or more of network devices 104. In this regard, system 100 may utilize distributed processing techniques for the handling of sensor data.” [0064]
Communication interface…
“In one embodiment, devices within local infusion system 102 can communicate with network devices 104 via a suitably configured translation device, system, or application 113. For example, such a translation device 113 may be configured to communicate with devices within local infusion system 102 using a suitable RF data communication protocol (which may be published or proprietary), while coupling to one or more network devices 104 via a standardized data communication interface such as USB, IEEE 1394, or the like. The translation device 113 may also be provisioned with flash memory capability such that patients or caregivers can save data received from a device in a portable storage device and physically transport the storage device to any compatible computing device, e.g., a personal computer at a doctor's office. One example translation device is described in more detail below in connection with FIGS. 18-20.” [0056]
Deployment of operating conditions (setup) and activation instruction (operational setup)…
“… Depending upon the particular system deployment and the specific operating conditions, an example control communication may include, without limitation: an alert disable instruction; an activation instruction for the infusion pump or any local device; a programming parameter for the infusion pump or any local device; or the upload of software programs (main application code or auxiliary function code such as motor control, RF telemetry code, or the like). Eventually, the network device can transmit (task 912) the control communication in an appropriate format and in compliance with the particular data communication protocol utilized for the communication session with the local device. Upon receipt, the receiving local device can process the control communication in an appropriate manner.” [0128]
determine a quality of service of a communication with the another device via the communication interface;
Quality of service and example of switchable (determine) unreliable links (QoS) of best effort and reliable link (Qos)…
“An embodiment of a wireless medical device as described herein can be configured to support both reliable wireless links (where missing or unacknowledged packets result in the generation of alarms) and unreliable wireless links (where missing or unacknowledged packets do not result in the generation of alarms) in a dynamically switching manner and in response to various criteria. In practice, unreliable links may be associated with a "best effort" quality of service. One example of a dynamically switchable wireless link is the wireless link between an infusion pump and a bedside monitor for the pump. Although this link may be a reliable link while the patient is asleep and in close proximity to the bedside monitor, during the day the link could switch to a best effort link to accommodate periods of time when the patient might be outside of the reliable range of the bedside monitor. When the patient (and the infusion pump) returns within range of the bedside monitor, the link can switch back to a reliable link and accumulated patient data can be transferred in a batch mode.” [0262]
select one of the plurality of predetermined alarm modes based on the determined operational setup and the determined quality of service; and
{
From Applicant’s specification on alarm modes, operational setup, and quality of service…
“Fig. 5 shows another exemplary operational setup C. The operational setup C is that of a wireless virtual switching system in a private network, but with low criticality. Several first medical devices 1A at the patient's bedside are connected wirelessly to the monitoring network 6. A second device 2 in the form of a standard PC with monitor. Due to the wireless connection, the QoS may be low. However, since also the criticality of the operational setup C is low, an alarm mode with no or attenuated alarm levels at the first medical devices 1A and alarm forwarding to the second device 2 with a DIS alarm reporting system are selected. HTTPS may be used as protocol for the alarm reporting. The communications may be controlled by a server 7.” (pg. 11, lines 16-24(
The above operational setup is a wireless network, and due to the wireless connection, QoS may be low. An alarm mode is set with no or attenuated alarm levels.
}
Wireless medical device configured to support (operational setup) wireless links where the links may be reliable or unreliable (QoS). Missing packets in the reliable network (QoS) can result in generation of an alarm (therefore, alarm mode) or if the wireless network is unreliable (QoS) no alarm…
“An embodiment of a wireless medical device as described herein can be configured to support both reliable wireless links (where missing or unacknowledged packets result in the generation of alarms) and unreliable wireless links (where missing or unacknowledged packets do not result in the generation of alarms) in a dynamically switching manner and in response to various criteria. In practice, unreliable links may be associated with a "best effort" quality of service. One example of a dynamically switchable wireless link is the wireless link between an infusion pump and a bedside monitor for the pump. Although this link may be a reliable link while the patient is asleep and in close proximity to the bedside monitor, during the day the link could switch to a best effort link to accommodate periods of time when the patient might be outside of the reliable range of the bedside monitor. When the patient (and the infusion pump) returns within range of the bedside monitor, the link can switch back to a reliable link and accumulated patient data can be transferred in a batch mode.” [0262]
Medical device configured (operational setup) to support reliable and unreliable wireless links (QoS)…
“An embodiment of a wireless medical device as described herein can be configured to support both reliable wireless links (where missing or unacknowledged packets result in the generation of alarms) and unreliable wireless links (where missing or unacknowledged packets do not result in the generation of alarms) in a dynamically switching manner and in response to various criteria. In practice, unreliable links may be associated with a "best effort" quality of service. One example of a dynamically switchable wireless link is the wireless link between an infusion pump and a bedside monitor for the pump. Although this link may be a reliable link while the patient is asleep and in close proximity to the bedside monitor, during the day the link could switch to a best effort link to accommodate periods of time when the patient might be outside of the reliable range of the bedside monitor. When the patient (and the infusion pump) returns within range of the bedside monitor, the link can switch back to a reliable link and accumulated patient data can be transferred in a batch mode.” [0262]
Reliable link for high priority data and unreliable link for low priority data…
“…For example, the particular wireless data communication mode may be selected in response to: (1) a priority associated with data to be transferred between the devices; (2) a data type category associated with data to be transferred between the devices; (3) a predetermined schedule; (4) transmit power criteria; and/or (5) a quality of service measurement for a wireless data communication session between the devices. Regarding item (1), the reliable link mode can be selected for data marked with a relatively high priority, while the unreliable link mode can be selected for data marked with a relatively low priority…” [0263]
Prevent (select) QoS alarm when determines unacknowledged packets (determined QoS) in unreliable link mode (determined operational setup) and alarms are for low priority data items (predetermined alarm mode)…
“If query task 2512 determines that the unreliable link mode is currently active, then the devices will continue providing a best effort quality of service (task 2516) regardless of the wireless data packet acknowledgement status. In other words, the unreliable link mode tolerates unacknowledged packets and the devices need not take any special action in response to unacknowledged packets. Indeed, the devices might be suitably configured to prevent the generation of quality of service alarms (task 2518) while operating in the unreliable link mode. This feature ensures that alarms are not generated for low priority data items.” [0266]
operate the medical device in the selected one of the plurality of predetermined alarm modes,
Activation (operate) for infusion pump and enable and disable alert or alarm instruction (predetermined modes)…
“Processing architecture 514 may also be configured to interpret and process incoming information, data, and content that is conveyed in network communications generated by an originating device that is external to the local infusion system. Referring to FIG. 1, the originating device may be any network device 104, including a networked monitor device. Such incoming network information may include, without limitation: programming data for a local device within the infusion system; an activation instruction for an infusion pump or another local device within the infusion system; a status request for a local device within the infusion system; a request for physiologic data of the user; an alert or alarm enable or disable instruction for a local device within the infusion system (which may be processed by monitor 500 and/or routed by monitor 500 to the appropriate local device); advisory information for the patient (e.g., a notification to place an order for supplies, a reminder to schedule a doctor's appointment, a reminder to schedule or automatically execute a data download for analysis by a caregiver, a notification to perform routine diagnostics, either manually or remotely via a network connection); or the like.” [0087] Inherent with enable and disable instruction for alert/alarm being provided is predetermined modes.
wherein the plurality of predetermined alarm modes comprises a suppression mode, in which alarm messages received and processed by the controller do not produce an alarm, and a perception mode, in which the alarm messages received and processed by the controller produce an alarm.
Alert or alarm enable (perception) and disable (suppression) instruction (mode)…
“Processing architecture 514 may also be configured to interpret and process incoming information, data, and content that is conveyed in network communications generated by an originating device that is external to the local infusion system. Referring to FIG. 1, the originating device may be any network device 104, including a networked monitor device. Such incoming network information may include, without limitation: programming data for a local device within the infusion system; an activation instruction for an infusion pump or another local device within the infusion system; a status request for a local device within the infusion system; a request for physiologic data of the user; an alert or alarm enable or disable instruction for a local device within the infusion system (which may be processed by monitor 500 and/or routed by monitor 500 to the appropriate local device); advisory information for the patient (e.g., a notification to place an order for supplies, a reminder to schedule a doctor's appointment, a reminder to schedule or automatically execute a data download for analysis by a caregiver, a notification to perform routine diagnostics, either manually or remotely via a network connection); or the like.” [0087]
Obtains or generates (internally or from another device) a notification (alarm) related to the operation of an infusion pump…
“Network communication process 1000 may be performed by a transmitting device that is within a local medical device system, e.g., an infusion system having an infusion pump that controls the infusion of fluid into the body of a user. For example, the transmitting device may be any local device within the local infusion system, such as a bedside monitor device, a hospital monitor device, a physiological characteristic meter, a physiological characteristic sensor transmitter, a remote controller, a handheld monitor/controller, the infusion pump itself, or the like. Process 1000 may begin when the transmitting device obtains (either internally, from another device, or from a user) or generates a notification (task 1002) related to the operation of the infusion pump and/or related to the operation of another local device. As used here, a notification may be any signal, alert, alarm, content, data, or information that is intended to be forwarded to another device, or is utilized as a prompt or a trigger to invoke a response by the transmitting device.” [0131]
Where monitor 500 includes an infusion pump and controller (receive and process to produce alarm)…
“FIG. 5 is a schematic representation of a medical device system monitor 500 configured in accordance with an example embodiment of the invention. Monitor 500 represents a generalized embodiment that may be realized as a bedside monitor, a hospital monitor, or a handheld monitor/controller, depending upon its specific configuration. In this example, monitor 500 generally includes a local device interface 502, a local communication module 504, a display element 506, one or more user interface features 508, a network communication module 510, a network interface 512, a processing architecture 514, and a suitable amount of memory 516. If monitor 500 is implemented as a hospital monitor, then it may also include an infusion pump 518 and a pump controller 520 that controls the operation of infusion pump 518 (these elements are depicted in dashed lines to indicate their optional nature). The elements of monitor 500 may be coupled together via a bus 522 or any suitable interconnection architecture.” [0082]
Suppression and Perception
Mehta et al. teaches alarm. They also teach enable and disable instruction. They do not literally teach suppression.
Day et al. also in the business of alarm teaches:
Typically alarms get produced (perception mode)…
“In hospitals that use infusion pumps and other medical devices, alarms are used to indicate device malfunction, therapy interruptions, end of therapy and other events that need to be handled by the clinical staff. Typically, alarms get displayed on device screens and produce audible sound. In some cases, there are too many devices that alarm in close proximity to each other. As a result, it is very hard to tell which device is actually alarming. The sound of alarms can also disturb or wake up sleeping patients. Hospital nurses usually manage multiple infusions running on multiple patients in one or more given clinical care areas. It is difficult for a nurse to be in the same vicinity of the infusion device at all times during an infusion, thus making it difficult to respond immediately to infusion-related or infusion device alarms. Further, clinical staff is not always in the close proximity to the alarming device to hear the alarm. In such situations it would be desirable for the staff to be notified of device alarms as soon as possible regardless of their proximity to the device so that they can better attend to their patients' needs.” [0005]
Example of rules that determine whether an alarm is generated (perception) or not generated (suppression)…
“Interface 22 likewise allows appropriate personnel to administer the rules used to control alarm forwarding in the system via a rule editor available on monitor/control device 18 or clinical system 24. The administration interface would allow the hospital personnel to determine rules for what contents from a data message from pump 12 would cause an alarm message to be generated. For example, an administrator could determine that an alarm would be generated whenever a certain kind of medication was interrupted, even if only temporarily, while the interruption of a different kind of medication did not generate an alarm unless the interruption was of a sufficient duration. The administration interface could also allow the hospital personnel to determine rules for what contents from a data message from pump 12 would control how and if certain alarm messages would be suppressed. For example, an administrator could determine that an alarm message generated based on a data message regarding a life critical or otherwise high risk drug, such as analgesics, sedatives or anticoagulants like Heparin for example, would not be suppressed at all, an alarm message generated based on a data message regarding a less critical drug could be locally suppressed at the device but could not be cleared remotely, and an alarm message generated based on a data message regarding a noncritical drug could be both locally suppressed at the device and cleared remotely.” [0033]
Various suppression protocols (modes) can be created…
“Each combination of alarm forwarding, acknowledgment, and particular kinds of suppression can be referred to as a suppression protocol. For example, the combination of suppressing a local auditory alarm until either a set time has elapsed or an alarm forwarding confirmation or acknowledgment was received is a first suppression protocol, while the combination of suppressing a remote alarm to a supervisor until either a set time has elapsed or a primary care giver cleared an alarm locally at the medical device is a second suppression protocol. Various suppression protocols can be created by hospital personnel via use of the rules editor mentioned previously, which can in one embodiment be incorporated into the Hospira MedNet™ software. The various suppression protocols can further be selectively applied by the care system based on the content of medical device data messages, alarm messages, and other information available to the system. As such, particularly stringent suppression protocols can be applied to low priority alarms automatically while more lax suppression protocols are applied to higher priority alarms.” [0039]
Where alarm is suppressed based on rules, algorithms, or instructions (therefore, alarm is processed but suppressed)…
“If, at step 66, it is determined, according to rules, algorithms or instructions, that the pump 12 is configured to suppress the local audio alarm, the program advances to step 68 where it is evaluated whether to delay or suppress the local audio alarm based on its rules, algorithms or instructions including, but not limited to, reference to the current stage of the local delay timer 50. If, at step 68, it is determined that the local audio alarm should be suppressed, the program passes to step 70. Step 70 determines whether the local delay timer 50 has exhausted its predetermined delay time and the alarm condition still persists. If the local delay timer 50 has exhausted its local delay time and the alarm condition still persists, the program passes to step 72 where pump 12 provides a local audio alarm even though the alarm had previously been determined to be suppressed. The reason the alarm suppression is overridden in this embodiment is that the failure to receive an acknowledgment of receipt of an alarm notice, as evidenced by the local delay time 50 timing out, has been determined, according to rules, algorithms or instructions, to require an alarm to be generated. Also, according to rules, algorithms or instructions, the alarm can be generated immediately or can be generated after taking further action (e.g., resending the alarm message to see if an acknowledgment or receipt of the alarm message returns). If at step 66 it is determined that pump 12 is not configured to suppress a local audio alarm indication, the program passes to step 72 where pump 12 provides a local audio alarm. Either or both a local audio or visual alarm can be produced at 46 and 72.” [0053]
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the method and system of Mehta et al. the ability to suppress an alarm as taught by Day et al. since the claimed invention is merely a combination of old elements and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Further motivation is provided by Day who teaches the problem of noise and benefit of using protocols to suppress alarms.
Regarding claim 2
The medical device according to claim 1, wherein the medical device is an infusion device or an infusion station for administering at least a fluid to a patient.
Mehta et al. teaches:
Infusion systems…
“Embodiments of the present invention relate generally to medical devices and medical device networks, such as infusion systems that deliver fluids into a patient's body. More particularly, embodiments of the present invention relate to systems and techniques related to wireless data communication protocols, and wireless data communication features suitable for use in a medical device network environment.” [0002]
Regarding claim 3
The medical device according to claim 1, wherein the controller is further configured to delegate or disseminate an alarm message to the another device depending on the determined operational setup and the determined quality of service.
Mehta et al. teaches:
Example of notification (alarm) forwarded (disseminate) to another device…
“Network communication process 1000 may be performed by a transmitting device that is within a local medical device system, e.g., an infusion system having an infusion pump that controls the infusion of fluid into the body of a user. For example, the transmitting device may be any local device within the local infusion system, such as a bedside monitor device, a hospital monitor device, a physiological characteristic meter, a physiological characteristic sensor transmitter, a remote controller, a handheld monitor/controller, the infusion pump itself, or the like. Process 1000 may begin when the transmitting device obtains (either internally, from another device, or from a user) or generates a notification (task 1002) related to the operation of the infusion pump and/or related to the operation of another local device. As used here, a notification may be any signal, alert, alarm, content, data, or information that is intended to be forwarded to another device, or is utilized as a prompt or a trigger to invoke a response by the transmitting device.” [0131]
Links based on quality of service…
“An embodiment of a wireless medical device as described herein can be configured to support both reliable wireless links (where missing or unacknowledged packets result in the generation of alarms) and unreliable wireless links (where missing or unacknowledged packets do not result in the generation of alarms) in a dynamically switching manner and in response to various criteria. In practice, unreliable links may be associated with a "best effort" quality of service. One example of a dynamically switchable wireless link is the wireless link between an infusion pump and a bedside monitor for the pump. Although this link may be a reliable link while the patient is asleep and in close proximity to the bedside monitor, during the day the link could switch to a best effort link to accommodate periods of time when the patient might be outside of the reliable range of the bedside monitor. When the patient (and the infusion pump) returns within range of the bedside monitor, the link can switch back to a reliable link and accumulated patient data can be transferred in a batch mode.” [0262]
Regarding claim 4
The medical device according to claim 3, wherein the controller is further configured, in case of a delegated alarm message, to receive a response to the communicated delegated alarm message from the another device.
Mehta et al. teaches:
Example of control signals with notifications/alarms and response…
“Control signal generation logic 720 may include or be realized as hardware, software, and/or firmware that is suitably configured to generate network communications as control signals for the receiving network device. For example, control signal generation logic 720 may generate automatic or user-created control signals that initiate the generation of notifications, alerts, alarms, displays, or otherwise control the operation of any compatible destination network device. Upon receipt of such a control signal, a destination network device will respond in a suitable manner--activating a display, activating a vibrating element, activating an illumination element, generating an audio or video response, or the like. In embodiments, control signal generation logic 720 may cooperate with one or more of the other logical components of network communication module 700, for example, alert/alarm generation logic 712, to facilitate the formatting and network transmission of control signals.” [0119]
Regarding claim 5
The medical device according to claim 3, wherein the controller is further configured to produce a visible and/or audible alarm based on a delay of a response to the communicated delegated alarm message and based on the selected one of the plurality of predetermined alarm modes.
Mehta et al. teaches:
Example of activating a display, generating an audio or video (predetermined alarm modes) response…
“Control signal generation logic 720 may include or be realized as hardware, software, and/or firmware that is suitably configured to generate network communications as control signals for the receiving network device. For example, control signal generation logic 720 may generate automatic or user-created control signals that initiate the generation of notifications, alerts, alarms, displays, or otherwise control the operation of any compatible destination network device. Upon receipt of such a control signal, a destination network device will respond in a suitable manner--activating a display, activating a vibrating element, activating an illumination element, generating an audio or video response, or the like. In embodiments, control signal generation logic 720 may cooperate with one or more of the other logical components of network communication module 700, for example, alert/alarm generation logic 712, to facilitate the formatting and network transmission of control signals.” [0119]
Example of alarm delayed…
“Once the wireless medical devices are operating in the selected link reliability mode, a transmitting device can generate and transmit a wireless data packet to a receiving device (task 2508). If the transmitting device receives an acknowledgement (ACK) of the transmitted data packet (query task 2510), then task 2508 may be re-entered to enable the continued transmission of additional wireless data packets using the selected mode. If the transmitting device does not receive an ACK message for the transmitted data packet, then it may check to determine whether the reliable link mode is currently active (query task 2512). If the devices are currently operating in the reliable link mode, then an appropriate alarm is generated (task 2514) to notify the user that a wireless data packet may have been missed or that the wireless link has become unreliable. In practice, task 2514 may be delayed until a specified number of data packets have been transmitted without acknowledgment.” [0265
Regarding claim 6
The medical device according to claim claim 1, characterized by further comprising a display adapted to produce a visible alarm.
Mehta et al. teaches:
Display alarm/alert status…
“Any of the devices within local infusion system 102 may include a display and related processing logic that facilitates the display of physiologic patient data, device status information, time and date information, alarm/alert status, and other information related to the operation, status, or condition of the patient, related to any of the devices within local infusion system 102, or related to local infusion system 102 itself. Portable display device 132 may be realized as a small device having limited functionality. In this regard, portable display device 132 may be incorporated into a key fob, a carabiner, a pendant, an insulin pen, a credit card display, or the like. Other local devices may have expanded display capabilities related to the specific functionality of such devices. For example, BG meter 136 may include display features that are specific to its metering functionality.” [0065]
Regarding claim 7
The medical device according to claim1, characterized by further comprising a sound emitting device adapted to produce an audible alarm.
Mehta et al. teaches:
Speakers for alarm or alert…
“… Housing 202 may also be configured to accommodate integral speakers 212, which can be activated to generate alarm or alert notifications. Housing 202 may also be designed to accommodate user interface features 208 as shown in FIG. 2. Stand 204 is suitably configured to support housing 202 and to provide a stable mounting location for bedside monitor 200. In the example embodiment shown in FIG. 2, stand 204 is also configured to accommodate one or more user interface features 208. User interface features 208 may include a keypad, keys, buttons, switches, knobs, a touchpad, a joystick, a pointing device, a virtual writing tablet, or any device, component, or function that enables the user to select options, input information, or otherwise control the operation of bedside monitor 200.” [0072]
Regarding claim 9
The medical device according to claim 8, wherein the plurality of predetermined alarm modes further comprises an attenuation mode, in which alarms are attenuated.
Mehta et al. teaches:
Silence or volume control element (therefore, attenuate) for an alarm…
“A device for a medical device network may be suitably configured in a manner that combines the functionality of a wireless repeater/annunciator and a data communication translation device (see FIGS. 18-20 and related description). Such a device may be powered by a USB connection when coupled to a computer, by a conventional household AC supply, or by an AC or DC adapter having a USB connector. This device may be configured as a full-featured component (e.g., a bedside or hospital monitor as described above), or as a reduced-featured component having a minimal or no user interface. For example, a minimal user interface may include an alarm silence/termination button and perhaps a volume control element for audio alarms. In practice, such a combined device could be programmable via a personal computer or other suitable computing device (using, for example, a USB connection).” [0261]
Regarding claim 10
The medical device according to claim 1, wherein the controller is configured to determine in which operational setup of the plurality of predetermined operational setups the medical device is operating by at least one of:
receiving a user input at the medical device:
Mehta et al. teaches:
One example of user input…
“Command display controller 138 is preferably realized as a handheld monitor/controller device that, although physically separate from infusion pump 128, enables the user to monitor and control the operation of infusion pump 128. This allows the user to operate infusion pump 128 without physically handling the device. As described in more detail below, command display controller 138 includes a communication module for transmitting local communications or commands to infusion pump 128. In further embodiments, command display controller 138 may receive local communications sent from infusion pump 128 or other components within local infusion system 102. In example embodiments, command display controller 138 also includes a network communication module for handling network communications to and from network devices that are external to local infusion system 102. Further, command display controller 138 may include one or more user input elements on its housing, such as keys, buttons, or the like, which accommodate user inputs. In embodiments, command display controller 138 includes a display on its housing, which may be configured to concurrently reproduce at least a portion of the information displayed on infusion pump 128.” [0067]
receiving a message indicating an operational setup via the communication interface; and
Display (receiving a message) of operation information…
“Any of the devices within local infusion system 102 may include a display and related processing logic that facilitates the display of physiologic patient data, device status information, time and date information, alarm/alert status, and other information related to the operation, status, or condition of the patient, related to any of the devices within local infusion system 102, or related to local infusion system 102 itself. Portable display device 132 may be realized as a small device having limited functionality. In this regard, portable display device 132 may be incorporated into a key fob, a carabiner, a pendant, an insulin pen, a credit card display, or the like. Other local devices may have expanded display capabilities related to the specific functionality of such devices. For example, BG meter 136 may include display features that are specific to its metering functionality.” [0065]
detecting a predetermined device or a predetermined plurality of devices via the communication interface.
Communication interface…
“In one embodiment, devices within local infusion system 102 can communicate with network devices 104 via a suitably configured translation device, system, or application 113. For example, such a translation device 113 may be configured to communicate with devices within local infusion system 102 using a suitable RF data communication protocol (which may be published or proprietary), while coupling to one or more network devices 104 via a standardized data communication interface such as USB, IEEE 1394, or the like. The translation device 113 may also be provisioned with flash memory capability such that patients or caregivers can save data received from a device in a portable storage device and physically transport the storage device to any compatible computing device, e.g., a personal computer at a doctor's office. One example translation device is described in more detail below in connection with FIGS. 18-20.” [0056]
Establish link to a local (therefore, predetermined) device…
“…The local communication module and local device interface may be configured to support wireless and/or wired data communication protocols. In an embodiment, local device interface 214 may represent a physical interface (such as a plug, a jack, a connector, a USB port, etc.) that facilitates connection to a data communication cable or any suitably configured physical component that establishes a communication link to a local device. As another example, a network communication module may cooperate with a network interface to receive network communications from network devices and/or to transmit network communications to network devices. The network communication module and network interface may be configured to support wireless and/or wired data communication protocols. In an embodiment, network interface 216 may represent a physical interface (such as a plug, a jack, a connector, a USB port, etc.) that accommodates a data communication cable or any suitably configured physical component that establishes a communication link to a network device. Bedside monitor 200 may also utilize one or more wireless local device interfaces and one or more wireless network interfaces, however, such wireless interfaces may not be visible from points outside housing 202.” [0074]
Regarding claim 11
The medical device according to claim 1, wherein the controller is configured to determine the quality of service of a communication with the another device by at least one of:
receiving a response from the another device;
Mehta et al. teaches:
Reliable links where unacknowledged packets (response from other device) cause alarms, therefore, acknowledged packets (response from another device)…
“An embodiment of a wireless medical device as described herein can be configured to support both reliable wireless links (where missing or unacknowledged packets result in the generation of alarms) and unreliable wireless links (where missing or unacknowledged packets do not result in the generation of alarms) in a dynamically switching manner and in response to various criteria. In practice, unreliable links may be associated with a "best effort" quality of service. One example of a dynamically switchable wireless link is the wireless link between an infusion pump and a bedside monitor for the pump. Although this link may be a reliable link while the patient is asleep and in close proximity to the bedside monitor, during the day the link could switch to a best effort link to accommodate periods of time when the patient might be outside of the reliable range of the bedside monitor. When the patient (and the infusion pump) returns within range of the bedside monitor, the link can switch back to a reliable link and accumulated patient data can be transferred in a batch mode.” [0262] Inherent with packet response is from another device.
determining that a latency of a communication with the another device is above or below a predetermined latency threshold; and
determining that a network bandwidth of a communication with the another device is above or below a predetermined network bandwidth threshold.
Example of quality of service threshold…
“Eventually, both devices are setup to support the designated retry timing scheme. Accordingly, the transmitting device can retransmit at least one wireless data packet using the designated retry periodicity setting (task 3018). In this example, if one or both devices detect an operating condition that satisfies a quality of service threshold (query task 3020), then retry periodicity selection process 3000 may be re-entered at task 3002 such that the normal timing scheme and the baseline retry timing scheme are again utilized for subsequently transmitted data packets. In other words, the system switches back to the first timing scheme and switches back to its nominal retry periodicity setting. If the threshold quality of service is not satisfied (query task 3020), then process 3000 may exit or otherwise proceed in an appropriate manner. For example, query task 3004 may be re-entered to enable dynamic adjustment of the retry timing scheme. Alternatively, the current retry timing scheme may be maintained for a period of time or until the quality of service improves or degrades by a specified amount.” [0287]
Regarding claim 12
The medical device according to claim 1, wherein the plurality of predetermined operational setups comprises at least one wireless setup, in which the communication interface communicates via a wireless connection with the another device and at least one wired setup, in which the communication interface communicates via a wired connection with the another device.
Mehta et al. teaches:
Wired or wireless communication…
“Insulin pumps and continuous glucose monitoring devices may also be configured to communicate with remote control devices, monitoring or display devices, BG meters, and other devices associated with such an infusion system. Individual devices within conventional infusion systems may be configured to support a limited amount of wired or wireless data communication to support the operation of the infusion system. For example, a continuous glucose monitoring sensor may include a wireless radio frequency ("RF") transmitter that communicates with a BG monitor device within the infusion system. As another example, the infusion system may include a handheld remote control that communicates with the infusion pump device using wireless techniques. Conventional infusion systems, however, operate in a somewhat isolated and local manner in that the routing of control signals, monitoring signals, patient status information, physiologic data, alerts, activation instructions, programming signals, and other data communication generally occurs within the limited short range and local operating environment of the infusion system itself. Moreover, many conventional infusion systems do not take advantage of certain protocols that facilitate efficient and effective wireless data communication between devices arranged in a network.” [0005]
Regarding claim 13
A system, comprising:
at least one medical device in accordance with claim 1 and
Mehta et al. teaches:
Fig. 1, ref. 128 and infusion pump……
PNG
media_image1.png
332
216
media_image1.png
Greyscale
another device communicatively coupled with the at least one medical device.
Fig. 1, ref. 140 and monitor.
Regarding claim 14
The system according to claim 13, further comprising a plurality of medical devices communicatively coupled with the another device via a same network.
Mehta et al. teaches:
Fig. 1 as network and the two devices on the same network…
“FIG. 1 is a schematic representation of a network-based medical device system 100 configured in accordance with an example embodiment of the invention. In this example, system 100 is an insulin infusion system that controls the infusion of insulin into the body of a user. Aspects of the invention, however, may also be utilized in the context of other medical device systems. Briefly, system 100 includes a local infusion system 102 having one or more local devices that communicate (unidirectional or bidirectional) with one or more network devices 104. As used here, network devices 104 are "external" to local infusion system 102 because they need not utilize the local data communication protocols and techniques employed within local infusion system 102, and because they need not be in close physical proximity to the local devices within local infusion system 102. The manner in which a given local device within local infusion system 102 communicates with a given network device 104 may vary depending upon the particular configuration of system 100, the characteristics of that local device, and the characteristics of that network device 104. For example, network communications may be routed using one data communication network 106, using a plurality of data communication networks 108/110, using a direct wireless or wired connection 112, or the like. In one example embodiment, data from wireless devices within local infusion system 102 (and/or data from wireless devices associated with different local infusion systems) may be collected by a wireless telemetry router device that serves as an interface to one or more network devices 104. One example wireless telemetry router device is described in more detail below in connection with FIG. 21.” [0054]
Regarding claim 15
The system according to claim 13 wherein the another device is a caregiver device adapted to visibly display and/or audibly emit alarms, and/or to send alarms to a mobile device.
Mehta et al. teaches:
“Infusion pump 128 is configured to deliver fluid, such as insulin, into the body of a user via, for example, an infusion set. In accordance with one example embodiment, infusion pump 128 serves as a central hub, and most of the processing logic and intelligence for local infusion system resides at infusion pump 128. In some embodiments, the local medical device system need not include infusion pump 128, for example, monitoring systems utilized in conjunction with traditional insulin injection therapy. Moreover, infusion pump 128 need not include a display. In an embodiment that lacks a display, portable display device 132, remote control device 134, command display controller 138, or any other device within local infusion system 102 may serve as a remote display for infusion pump 128. Other options for a remote display include, but are not limited to, any of the network devices 104 described above, e.g., wireless phone 124, monitor device 114, portable computer 116, or personal digital assistant 120.” [0061]
“Any of the devices within local infusion system 102 may include a display and related processing logic that facilitates the display of physiologic patient data, device status information, time and date information, alarm/alert status, and other information related to the operation, status, or condition of the patient, related to any of the devices within local infusion system 102, or related to local infusion system 102 itself. Portable display device 132 may be realized as a small device having limited functionality. In this regard, portable display device 132 may be incorporated into a key fob, a carabiner, a pendant, an insulin pen, a credit card display, or the like. Other local devices may have expanded display capabilities related to the specific functionality of such devices. For example, BG meter 136 may include display features that are specific to its metering functionality.” [0065]
Example of caregiver and audio signals…
“Audio signal/file generation logic 716 may include or be realized as hardware, software, and/or firmware that is suitably configured to generate network communications as audio signals and/or audio files. The audio signals or files may be pre-programmed into the monitor device (or into the device that creates the audio signals or files). Alternatively, the audio signals or files may be created by a user of the monitor device (or by a user of the device in communication with the monitor device). For example, audio signal/file generation logic 716 may generate automatic or user-created audio signals or audio files that convey notifications, alerts, alarms, status reports, physiologic data, or other information that is intended for any compatible destination network device. Audio-based alerts/alarms may be automatically initiated by the monitor device or by a device in communication with the monitor device. Alternatively, audio-based alerts/alarms may be initiated by a user, patient, or caregiver at the monitor device or at a device in communication with the monitor device. Upon receipt, the destination network device can play the audio signals or audio files using an appropriate playback mechanism, multimedia application, or the like.” [0115]
Alarm/alert forwarded to caregiver…
“Here, annunciator/repeater 2484 forwards (repeats) the message to the next device in the link, and so on. Each annunciator/repeater device can sound the appropriate alarm/alert as the location of the caregiver is unknown. The receiving annunciator/repeater device may respond with an ACK or NAK to the transmitting annunciator/repeater device…” [0257]
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over the combined references in section (6) above in further view of Pub. No. US 2005/0137653 to Friedman.
Regarding claim 17
The system according to claim 1, wherein the plurality of predetermined operational setups further comprises clinical situations including an intensive-care setup, an operating room setup, a ward level setup, a patient room setup, and a caregiver room setup.
Mehta et al. teaches operational setups and alarms. They do not teach specific clinical situations.
Friedman et al. also in the business of alarms teaches:
Operating parameters (setups with alarm levels for intensive care unit, surgical (operating) unit (room), patient wards, patient bedsides, nurse station (caregiver room)…
“FIG. 4 shows a layout view of one type of hospital ward showing patient rooms, nurse station, storage facility, hallways, medical devices at patients' bedsides including infusion pumps and vital signs monitors, and a mobile server (mobile systems manager) 302. The clinical setting where such a system may be employed may consist of various types of patient wards, such as an ICU (intensive care unit), labor and delivery, and medical/surgical unit. In the case of FIG. 4, the medical instruments are configured according to the specific clinical setting, that is, the medical instruments are configured as appropriate for a specific ward or unit type, and are programmed with specific ward-related operating parameters such as alarm levels, maximum rates, dose limits and the like. These ward-related operating parameters are referred to herein as "profiles." The profiles may be given names similar or identical to the relevant patient ward names such as ICU, labor and delivery, and so forth. The term "PCU" is meant to indicate "patient care unit" and may comprise various medical devices such as an infusion pump, a vital signs monitor, or other devices.” [0064]
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the method and system of Mehta et al. the ability to have a setup for clinical situations as taught by Friedman et al. since the claimed invention is merely a combination of old elements and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Further motivation is provided by Friedman et al. who teaches the advantages of programming for various clinical situations.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over the combined references in section (6) above in view of Pub. No. US 2017/0068790 to Fuerst.
Regarding claim 18
The system according to claim 1, wherein the plurality of predetermined operational setups further comprises a high criticality care setup, wherein required attention from a caregiver is high, and a low criticality care setup, wherein the required attention from the caregiver is low.
Mehta et al. teaches alarms. They do not teach specific clinical situations.
Fuerst also in the business of alerts (alarms) teaches:
Physiological value higher than threshold value (high criticality care setup), transmit alert to medical practitioner (attention required), and smaller value, continue measuring (required attention is low)…
“In some embodiments, the instant invention provides for a computer system, including: a) at least one server having software stored on a non-transient computer readable medium; where, upon execution of the software, the at least one server is at least configured to: i) receiving, an input from a user, where the input includes user data consisting of: food intake of the user, glucose readings of the user, medication intake by the user, stress related events in the preceding day, insulin dose taken by the user, or any combination thereof; ii) receiving, in real-time, physiological data representative of at least one physiological measurement of at least one physiological characteristic of the user, where the at least one physiological characteristic is selected from the group consisting of: heart rate, heart rate variability, oxygen saturation, temperature, galvanic skin response, or any combination thereof; iii) comparing, in real-time, the at least one physiological measurement of the user to at least one pre-determined physiological value associated with the at least one physiological characteristic retrieved from at least one database; iv) based on the comparing, determining, in real-time, that a difference between the at least one physiological measurement of the user and the at least one pre-determined physiological value is: a) higher than a predetermined threshold value, or b) smaller than the predetermined threshold value, and then: v) generating, in real-time, at least one alert when the at least one pre-determined physiological value is higher than the predetermined threshold value; vi) transmitting, in real-time, the at least one alert to at least one of: the user, at least one family member, at least one medical practitioner, or any combination thereof; and vii) when the at least one pre-determined physiological value is smaller than the predetermined threshold value, causing to continue measuring, in real-time, the at least one physiological characteristic of the user.” [0004]
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the method and system of Mehta et al. the ability to have a setup based on physiological value for transmitting alert to medical practitioner as taught by Fuerst since the claimed invention is merely a combination of old elements and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Further motivation is provided by Fuerst who teaches that advantages of alerting medical practitioners when physiological value is above a threshold (critically high).
Claims 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over the combined references in section (6) above in view of Pub. No. US 2021/0077712 to Dave et al.
Regarding claim 19
The system according to claim 1, wherein the controller is further configured to determine in which operational setup the medical device is operating based on criticality of care, flow of information, and communicative connections.
{
From Applicant’s Specification on determine…
“The controller 11 of the first medical device 1A (optionally, also the controller 21 of the second device 2) is further configured to determine in which operational setup of a plurality of predetermined operational setups the first medical device 1A is currently operating. Various different operating setups A-E will be described in more detail below with reference to Figs. 3-7. In general, the predefined operational setups may comprise setups with different levels of requirements (e.g., low and high, or low, intermediate and high), e.g., setups with a different criticality of care, with a different flow of information and/or with different setups of 15 communicative connections, for example.” (pg. 8, lines 8-15)
Therefore, operational setup can be based on criticality of care, different flow of information and different setups of communicative connection. So, information in a critical care unit, with variable amounts of (flow/bandwidth) information, and wireless connections could be an operational setup.
}
Mehta et al. teaches operational setups. They do not teach based on criticality of care, flow information and communicative connections.
Dave et al. also in the business of operational setups teaches:
Network connectivity (communicative connections) and identified as critical care areas….
“In some implementations, the medical device 12 may utilize one or more geofence sensors to detect a location setting in which the device is located. One or more location measurements may be obtained using the geofence sensor(s) and used to determine whether to adjust a power allotment to the various systems of the medical device 12, including to any connected functional modules. Certain parameters may tend to shorten a battery's capacity and life, such as environmental parameters (e.g., controlled temperature of a clinical setting versus ambient temperature on a patio outside a patient's home) and/or the availability of charging outlets. A medical device may obtain data regarding its battery's expected capacity or life based on various factors including current operating temperature, depth of discharge, rate of discharge, and previously known capacities under similar conditions. If the medical device 12 determines that the battery's expected capacity is lower than a predetermined threshold for maintaining current operations for a predetermined time period, the medical device may enter a power saving mode and begin to shut down or reduce operation of non-essential systems. Functional units and or medical device features may be determined to be essential or non-essential depending on various factors, including care area, status of the patient, time to next charge, etc. In some examples, network connectivity may be identified as a non-essential system. In other examples, network connectivity may be identified as an essential system. Audible alarms may be identified as essential in high traffic noisy critical care areas such as an intensive care unit, but not when the device is identified as being in transit from one area to another (e.g., vehicle ride from hospital to home).” [0054]
Mode with network bandwidth (flow information) and clinical mode vs patient mode for use at home (criticality of care)…
“Responsive to the determined location mode, an operation mode of the medical device is automatically switched from a first mode currently programmed for the care of the patient to a second mode, the second mode using different parameters than the first mode to control the medical device, in step 306. For example, a clinician mode may be geared towards use in a care facility with specific resources available to the device (e.g., network bandwidth, power, network security) and trained clinicians to operate the medical device, while a patient mode may be geared towards use in a patient's home with different resources and/or by the patient or a family member. In some implementations, the switching of operation mode may include identifying the operation mode to switch based on the geofence parameter. For example, if a geofence parameter may be associated with a specific care setting where certain modes are appropriate. The association may be stored as a static or dynamic configuration of the medical device within a memory accessible by the medical device.” [0061]
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the method and system of Mehta et al. the ability to have a setup based on criticality of care, flow information, and communicative connections as taught by Dave et al. since the claimed invention is merely a combination of old elements and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Further motivation is provided by Dave et al. who teaches mode and various parameters considered for setting up a medical device.
Regarding claim 20
The system according to claim 19, wherein the controller is further configured to disseminate an alarm message to multiple devices depending on the determined operational setup and determined quality of service.
Mehta et al. teaches:
Medical device network with plurality of devices with wireless links that convey alerts and/or alarms….
“An embodiment of a medical device system as described here includes wireless devices that are configured to support a number of RF data communication protocols, techniques, and technologies that enable efficient routing of system data over wireless links. The medical device system includes a plurality of devices arranged in a wireless network topology (and/or in a wired network topology). Moreover, a wireless medical device in the "local" or "body" area network can be suitably configured to communicate with one or more external network devices, such as networked computers, cellular telephones, personal digital assistants, hospital monitoring equipment, pager devices, or the like. Wireless network communications within the medical device network may convey device status information, physiologic patient data, alerts, and/or alarms. Moreover, wireless network communications within the medical device network may convey data that originates from external devices outside the local system environment, such as device programming instructions, device actuation instructions, calibration parameters, alert/alarm enable or disable signals, and/or other control parameters to the local system devices.” [0006]
Wireless medical device configured to support (operational setup) wireless links where the links may be reliable or unreliable (QoS). Missing packets in the reliable network (QoS) can result in generation of an alarm (therefore, alarm mode) or if the wireless network is unreliable (QoS) no alarm…
“An embodiment of a wireless medical device as described herein can be configured to support both reliable wireless links (where missing or unacknowledged packets result in the generation of alarms) and unreliable wireless links (where missing or unacknowledged packets do not result in the generation of alarms) in a dynamically switching manner and in response to various criteria. In practice, unreliable links may be associated with a "best effort" quality of service. One example of a dynamically switchable wireless link is the wireless link between an infusion pump and a bedside monitor for the pump. Although this link may be a reliable link while the patient is asleep and in close proximity to the bedside monitor, during the day the link could switch to a best effort link to accommodate periods of time when the patient might be outside of the reliable range of the bedside monitor. When the patient (and the infusion pump) returns within range of the bedside monitor, the link can switch back to a reliable link and accumulated patient data can be transferred in a batch mode.” [0262]
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KENNETH BARTLEY whose telephone number is (571)272-5230. The examiner can normally be reached Mon-Fri: 7:30 - 4:00 EST.
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, SHAHID MERCHANT can be reached at (571) 270-1360. 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.
/KENNETH BARTLEY/Primary Examiner, Art Unit 3684
Prosecution Insights