DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on January 6, 2026, has been entered.
Response to Amendment
Claims 1 and 21 have been amended. Claims 11-20, 24, and 27 have been canceled. Claims 31 and 32 are new. Claims 1-10, 21-23, 25, 26, and 28-32 are pending and are provided to be examined upon their merits.
Response to Arguments
Applicant’s arguments with respect to claims -10, 21-23, 25, 26, and 28-32 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 claims are not obvious, starting pg. 8 of Remarks:
A. Independent Claims 1 and 21 Are Not Obvious
Claims 1 and 21 were rejected under 35 U.S.C. § 103 as being unpatentable over Xavier in view of Verma and McAllen. Although Applicant respectfully disagrees, Applicant has amended the claims to expedite allowance.
Claim 1 as amended recites in part:
A system for managing communications for medical devices, the system
comprising:
a medical device comprising a communication engine and a user interface controller;
a medical device server comprising one or more processors and configured to require, for communication with the medical device server, registration by the medical device based on a current state and event history of the medical device; and
the medical device is configured to:
establish a first secure connection with the connectivity adapter based at least partly on a signed certificate uniquely associated with the medical device;
send, to the connectivity adapter via the first secure connection, a request for registration of the medical device with the medical device server;
receive, from the connectivity adapter via the first secure connection, a response representing an approval of the registration; and
subsequent to approval of the registration:
determine that the first secure connection has been disconnected;
establish a second secure connection with the connectivity adapter based at least partly on the signed certificate;
determine that a time period, after which a second request for registration of the medical device is to be sent, has not expired; and
exchange, based on the time period not being expired, a second plurality of network communications with the medical device server via the second secure connection without performing an additional registration, wherein the second plurality of network communications consume less network bandwidth than the request for registration and the response representing approval of the registration.
Claim 21 as amended recites in part:
A computer-implemented method for managing medical device communications, comprising:
under control of a medical device comprising one or more processors and a communication engine,
establishing a first secure connection with a connectivity adapter based at least partly on a signed certificate uniquely associated with the medical device;
sending, to the connectivity adapter via the first secure connection, a request for registration of the medical device with a medical device server;
receiving, from the connectivity adapter via the first secure connection, a response representing an approval of the registration; and subsequent to approval of the registration:
determining that the first secure connection has been disconnected;
establishing a second secure connection with the connectivity adapter based at least partly on the signed certificate;
determining that a time period, after which a second request for registration of the medical device is to be sent, has not expired; and
exchanging, based on the time period not being expired, a second plurality of network communications with the medical device server via the second secure connection without performing an additional registration, wherein the second plurality of network communications consume less network bandwidth than the request for registration and the response representing approval of the registration.
As an initial matter, the above-quoted combinations of elements clearly define which devices are performing which operations. More specifically, the claims state that it is the medical device that "establish[es] a first secure connection with a connectivity adapter based at least partly on a signed certificate uniquely associated with the medical device." In contrast, the portions of Xavier cited in the Office Action instead deal with a connectivity adapter that sends an authentication request to an authentication proxy. (See Office Action, p. 13.)
Respectfully, the device has to present itself to the system.
From Applicant’s specification on secure connection with signed certificate:
“To reestablish communications without the overhead of sending all registration related data after every interruption, a delayed registration process may be performed in which a secure connection may be established using a process by which the medical device proves its identity, such as by using the secure sockets layer (“SSL”) protocol or transport layer security (“TLS”) protocol with signed certificates. The medical device may then resume normal network communication using the secure connection, without performing a full registration process. The delayed registration is “lazy” in the sense that full registration may be delayed until a period of time has expired (e.g., the medical device's registration may expire every 24 hours). In some embodiments, full registration may be delayed regardless of how many times the medical device re-establishes communication with the server. In some embodiments, the medical device may be permitted to establish communication a limited number of times during a particular time period before a full registration is performed. In some embodiments, the full registration may be permitted or required before the next scheduled time (e.g., before 24 hours) if some critical information of the medical device has changed, such as metadata or device name.” [0014]
From Applicant’s specification…
“As shown in FIG. 3, at [1] the CE 120 may create a secure connection with the connectivity adapter 104. Illustratively, the CE 120 may open a web socket to the connectivity adapter 104 and may provide information, such as an address (e.g., an IP address), identity data (e.g., a secure certificate uniquely associated with the medical device 102), and the like. At [2] the connectivity adapter 104 may accept the connection request, and the connection may be established. In some embodiments, the connectivity adapter 104 may notify other systems of the secure connection with the medical device 102. For example, the connectivity adapter 104 may notify the medical device server 106 at [3] that the medical device 102 now has a connection with the connectivity adapter 104.” [0034]
Therefore, the communication engine of the medical device establishes communication.
From Xavier et al…
A first network with communication between connectivity adapter and infusion pumps, and where the connectivity adapter is configured to receive infusion pump message, including new information over a first network…
“Clause 1. A system configured to facilitate messaging during a network outage, the system comprising: a plurality of infusion pumps configured to deliver medication to patients, each infusion pump of the plurality of infusion pumps comprising a memory configured to store operational software and a processor configured to generate pump messages; a connectivity adapter comprising computer hardware and in communication with the plurality of infusion pumps over a first network; and a server comprising computer hardware and in communication with the connectivity adapter over a second network different from the first network, wherein the connectivity adapter is configured to: receive a first pump message from a first infusion pump of the plurality of infusion pumps, the first pump message including information that is new to the connectivity adapter; generate a first standardized dataset message based on the information in the first pump message; store the first standardized dataset message in an outbound queue for transmission to the server; subsequent to storing the first standardized dataset message in the outbound queue, receive a second pump message from the first infusion pump, the second pump message including additional information that is new to the connectivity adapter; generate a second standardized dataset message based on the additional information in the second pump message; store the second standardized dataset message in the outbound queue for transmission to the server; remove the first standardized dataset message from the outbound queue without transmitting the first standardized dataset message to the server; and transmit the second standardized dataset message in the outbound queue to the server.” [0097]
Identifying login credentials of infusion pumps (medical devices) via a first network connection (therefore, the infusion pump through the communication engine and through the connectivity adapter)…
“Clause 135. A method for authenticating a network device residing in a clinical environment using a token, the method comprising: processing an authentication request from the network device residing in the clinical environment via a first network connection, wherein the authentication request includes identifying information associated with the clinical environment, and wherein the clinical environment includes one or more infusion pumps in communication with the network device; identifying login credentials to be used to authenticate the network device residing in the clinical environment; transmitting the login credentials to an authentication system configured to authenticate requests from the network device residing in the clinical environment via a second network connection different from the first network connection; receiving a security token from the authentication system, the security token being usable by the network device to transmit requests to the authentication system via the second network connection; and transmitting the security token to the network device residing in the clinical environment via the first network connection.” [0231]
Fig. 3, infusion pump 204 and 206…
PNG
media_image1.png
358
692
media_image1.png
Greyscale
The method of Clause 135 (first network) and sending a signed request to the authentication system…
“Clause 138. The method of Clause 135, further comprising causing the network device residing in the clinical environment to transmit a signed request to the authentication system.” [0234]
Therefore, the above teaches sending a signed request to the authentication system from the infusion pump via the first network, where the first network is between the infusion pump and connectivity adapter.
In addition, the claims as amended recite exchanging, "based on the time period not being expired, a second plurality of network communications with the medical device server via the second secure connection without performing an additional registration." This feature is patentably distinct from the cited references. There is simply no disclosure of exchanging a "second plurality of network communications with the medical device server via the second secure connection without performing an additional registration," where the second secure connection has been established "with the connectivity adapter based at least partly on the signed certificate," as recited in amended Claims 1 and 21. Thus, the cited art cannot disclose doing so "based on the time period not being expired," where the time period is "a time period, after which a second request for registration of the medical device is to be sent," as further recited in the claims. Thus, Applicant respectfully requests that the rejection of Claims 1 and 21 under 35 U.S.C. § 103 be withdrawn and the claim allowed.
From Applicant’s argument above…
>>”There is simply no disclosure of exchanging a "second plurality of network communications with the medical device server via the second secure connection without performing an additional registration," where the second secure connection has been established "with the connectivity adapter based at least partly on the signed certificate," as recited in amended Claims 1 and 21. Thus, the cited art cannot disclose doing so "based on the time period not being expired," where the time period is "a time period, after which a second request for registration of the medical device is to be sent," as further recited in the claims.
From Claim 21…
establishing a second secure connection with the connectivity adapter based at least partly on the signed certificate;
“determining that a time period, after which a second request for registration of the medical device is to be sent, has not expired; and
exchanging, based on the time period not being expired, a second plurality of network communications with the medical device server via the second secure connection without performing an additional registration, wherein the second plurality of network communications consume less network bandwidth than the request for registration and the response representing approval of the registration.”
Applicant has amended their claim, which is claiming a time period for re-registration has not yet expired, therefore a second registration is not yet required, and establishing a second secure connection based on the signed certificate and sending a second secure connection without performing additional registration. This is essentially sending a signed certificate for a secure connection when a registration has not yet expired.
The primary art of Xavier et al. as indicated above teaches establish with the connectivity adapter a secure connection with a signed certificate, as the infusion device does this via the first network.
From Applicant’s argument above…
>>”There is simply no disclosure of exchanging a "second plurality of network communications with the medical device server via the second secure connection without performing an additional registration," where the second secure connection has been established "with the connectivity adapter based at least partly on the signed certificate," as recited in amended Claims 1 and 21.”<<
The primary art of Xavier teaches dealing with outages. Secondary art was used to teach registration. New art is cited that teaches using a signed certificate when registration has not yet expired.
B. Claims 2-10, 22, 23, 25, 26, and 28-32 Are Patentable
Claims 2-10, 22, 23, 25, 26, and 28-32 each depend from one of independent Claims 1 or 21, and include all of the elements of their respective independent claims. Therefore, Claims 2- 10, 22, 23, 25, 26, and 28-32 are submitted to be allowable for at least the same reasons as Claims 1 and 21. In addition, Claims 2-10, 22, 23, 25, 26, and 28-32 are allowable over the applied art for the unique combinations of features recited in those claims.
For at least the foregoing reasons, Applicant respectfully requests withdrawal of the rejection of Claims 2-10, 22, 23, 25, 26, and 28-30 under 35 U.S.C. § 103, and allowance of these claims and new Claims 31 and 32.
The rejection is respectfully maintained but modified for the claim amendments.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 9, 21, and 28 are rejected under 35 U.S.C. 103 as being unpatentable over Pub. No. US 2021/0358603 to Xavier et al. in view of Pub. No. US 2020/0177589 to Mangalvedkar et al.
Regarding claims 1 and 21
(claim 21) A computer-implemented method for managing medical device communications, comprising:
Xavier et al. teaches:
Fig. 10, ref. 206 teaches example of connectivity adapter…
PNG
media_image2.png
436
670
media_image2.png
Greyscale
Infusion pump (medical device) with communication engine…
“FIG. 3 illustrates the messages received, stored, and transmitted by the connectivity adapter 206 in the clinical environment 102. As shown in FIG. 3, the infusion pump 204 may include motor controller unit (MCU) 204A and communications engine (CE) 204B. Although not shown in FIG. 3, the infusion pump 204 may include one or more memories and storage media configured to store various instructions, parameters, and/or messages. The connectivity adapter 206 may include transformation worker 206A, device status manager 206B, cache 206C, and outbound queue 206D. The MCU 204A may generate and send messages to the CE 204B for storage and transmission to the connectivity adapter 206. In some cases, the messages are each associated with a message identifier (ID). In some embodiments, the MCU 204A is a very small processor (e.g., 12 Mhz) and the CE 204B is a more powerful processor (e.g., 400 Mhz)…” [0022]
Example of infusion pumps with techniques that can be applied to medical devices to display blood pressure (therefore, interface)….
“Various techniques for facilitating communication with and across a clinical environment and a cloud environment are described herein. These techniques may include converting pump messages into standardized dataset messages (also referred to herein simply as “messages”), merging the messages into a cache, transmitting the messages to a cloud server, detecting network outages, clearing an outbound queue, detecting missing messages, authenticating a connectivity adapter for cloud access, providing a segmented data structure, among others. These and other embodiments are described in greater detail below with reference to FIGS. 1-13. Although many of the examples are described in the context of a hospital environment including infusion pumps, the techniques described herein can be applied to any network environment including other medical devices (e.g., patient care monitors configured to display blood pressure, heart rate, blood oxygenation, and the like), or non-medical devices, or any combination thereof.” [0004]
Example of device manager (cloud/server) and live message (current state) and historical message…
“The cache 206C may store the current state of the individual infusion pumps 204 configured to communicate with the connectivity adapter 206. As additional messages are received from the infusion pumps 204, the device status manager 206B updates the current state stored in the cache 206C to reflect the changes made by the messages from the infusion pumps 204. In some embodiments, the device status manager 206B determines whether the message received from the transformation worker 206A is a live message or an historical message. A live message includes messages that are transmitted to the connectivity adapter 206 based on a new event at the infusion pump 204. An historical message includes messages that are transmitted to the connectivity adapter 206 based on a prior event at the infusion pump 204. Historical messages may be transmitted at the request of the connectivity adapter 206. The device status manager 206B is configured to merge the message into the cache 206C upon determining that the message is a live message (and alternatively, refrain from merging the message into the cache 206C upon determining that the message is an historical message). The cache 206C may be implemented using an in-memory cache (e.g., Redis) or other storage devices.” [0042]
under control of a medical device comprising one or more processors and a communication engine,
Xavier et al. teaches:
Fig. 3, ref. 204 teaches “INFUSION PUMP” (medical device) and CE (communication engine)…
PNG
media_image3.png
200
574
media_image3.png
Greyscale
Example of processors…
“FIG. 3 illustrates the messages received, stored, and transmitted by the connectivity adapter 206 in the clinical environment 102. As shown in FIG. 3, the infusion pump 204 may include motor controller unit (MCU) 204A and communications engine (CE) 204B. Although not shown in FIG. 3, the infusion pump 204 may include one or more memories and storage media configured to store various instructions, parameters, and/or messages. The connectivity adapter 206 may include transformation worker 206A, device status manager 206B, cache 206C, and outbound queue 206D. The MCU 204A may generate and send messages to the CE 204B for storage and transmission to the connectivity adapter 206. In some cases, the messages are each associated with a message identifier (ID). In some embodiments, the MCU 204A is a very small processor (e.g., 12 Mhz) and the CE 204B is a more powerful processor (e.g., 400 Mhz)…” [0022]
establishing a first secure connection with a connectivity adapter based at least partly on a signed certificate uniquely associated with the medical device;
Login credentials on behalf of connectivity adapter (associated with medical device), and security token to generate a signed request (signed certificate)…
“In some cases, the connectivity adapter 206 may be a network appliance and may lack the capability of managing and maintaining its own user account. In such cases, the connectivity adapter 206 may send an authentication request to the authentication proxy 1006 (e.g., via a connection such as a secured and authenticated WebSocket connection or another other TCP connection), and the authentication proxy 1006 may provide login credentials to the authentication system 1004 on behalf of the connectivity adapter 206 and receive a security token that can be used by the connectivity adapter 206 to generate a signed request. The connectivity adapter 206 may send the signed request to the authentication system 1004 (e.g., using HTTP), just as the authenticated user devices 1002 do in FIG. 10. In some cases, the connection between the connectivity adapter 206 and the authentication proxy 1006 utilize a different communications protocol (e.g., WebSocket) than the connection between the connectivity adapter 206 and the authentication system 1004 (e.g., HTTP). By using the authentication proxy 1006, the connectivity adapter can utilize the cloud services provided by the cloud environment 106 without having to manage user accounts or login credentials. The authentication proxy 1006 may maintain one or more user accounts per clinical environment account.” [0079]
See Certificate below.
sending, to the connectivity adapter via the first secure connection, a request for registration of the medical device with a medical device server;
{
From Applicant’s Specification on registration…
“Some existing methods of communication between medical devices and servers or other computing systems in a clinical environment involve a full registration process whereby a medical device is required to register with a server in order to communicate with the server (e.g., to exchange clinical data, receive programming instructions, etc.). For example, a medical device may be required to provide logging data regarding events occurring on the medical device, manifest data regarding the current software and/or hardware configuration of the medical device, and the like. In this way, a server can ensure that the medical device has the proper components, is communicating using the proper protocols, etc…” [0012]
Therefore, registration may include providing logging data regarding events, current software and hardware configuration data, etc.
}
A first network with communication between connectivity adapter and infusion pumps, and where the connectivity adapter is configured to receive infusion pump message, including new information over a first network…
“Clause 1. A system configured to facilitate messaging during a network outage, the system comprising: a plurality of infusion pumps configured to deliver medication to patients, each infusion pump of the plurality of infusion pumps comprising a memory configured to store operational software and a processor configured to generate pump messages; a connectivity adapter comprising computer hardware and in communication with the plurality of infusion pumps over a first network; and a server comprising computer hardware and in communication with the connectivity adapter over a second network different from the first network, wherein the connectivity adapter is configured to: receive a first pump message from a first infusion pump of the plurality of infusion pumps, the first pump message including information that is new to the connectivity adapter; generate a first standardized dataset message based on the information in the first pump message; store the first standardized dataset message in an outbound queue for transmission to the server; subsequent to storing the first standardized dataset message in the outbound queue, receive a second pump message from the first infusion pump, the second pump message including additional information that is new to the connectivity adapter; generate a second standardized dataset message based on the additional information in the second pump message; store the second standardized dataset message in the outbound queue for transmission to the server; remove the first standardized dataset message from the outbound queue without transmitting the first standardized dataset message to the server; and transmit the second standardized dataset message in the outbound queue to the server.” [0097]
Identifying login credentials of infusion pumps (medical devices) via a first network connection (therefore, the infusion pump through the communication engine and through the connectivity adapter)…
“Clause 135. A method for authenticating a network device residing in a clinical environment using a token, the method comprising: processing an authentication request from the network device residing in the clinical environment via a first network connection, wherein the authentication request includes identifying information associated with the clinical environment, and wherein the clinical environment includes one or more infusion pumps in communication with the network device; identifying login credentials to be used to authenticate the network device residing in the clinical environment; transmitting the login credentials to an authentication system configured to authenticate requests from the network device residing in the clinical environment via a second network connection different from the first network connection; receiving a security token from the authentication system, the security token being usable by the network device to transmit requests to the authentication system via the second network connection; and transmitting the security token to the network device residing in the clinical environment via the first network connection.” [0231]
Fig. 3, infusion pump 204 and 206…
PNG
media_image1.png
358
692
media_image1.png
Greyscale
The method of Clause 135 (first network) and sending a signed request to the authentication system…
“Clause 138. The method of Clause 135, further comprising causing the network device residing in the clinical environment to transmit a signed request to the authentication system.” [0234]
Therefore, the above teaches sending a signed request to the authentication system from the infusion pump via the first network, where the first network is between the infusion pump and connectivity adapter.
See Registration and Expire below.
receiving, from the connectivity adapter via the first secure connection, a response representing an approval of the registration; and
Example of adapter sending (receiving from the adapter) information, but unable to transmit relevant messages, therefore, sending (when able) registration information…
“FIG. 5 illustrates the messages received, stored, and transmitted by the cloud environment 106. As shown in FIG. 5, the DFM 408 may include cache 408A and outbound queue 408B. The cache 408A may store the current state of the infusion pump 204. For example, the cache 408A may include all of the current parameter values (or to the extent available to the DFM 408) at the infusion pump 204 (e.g., power status, infusion status, battery status, network status, infusion start time, volume to be infused, volume infused, dose, and the like). In some cases, the current state stored in the cache 408A is identical to the current state stored in the cache 206C. In other cases, the current state stored in the cache 408A includes additional information not stored in the cache 206C, or vice versa. For example, the DFM 408 may have access to data sources not accessible (or readily accessible) by the connectivity adapter 206, and the DFM 408 may have obtained additional data prior to merging the message and the additional data into the cache 408A. In another example, due to a network outage, the connectivity adapter 206 may have been able to update its own cache 206C but unable to transmit the relevant messages to the DFM 408. In such a case, the cloud cache 408A may include less information than the connectivity adapter cache 206C. The outbound queue 408B may include messages to be transmitted to the clinical environment 102. For example, the outbound queue 408B can include command messages (e.g., instructions to update the security settings on the connectivity adapter 206), request messages (e.g., requests for missing messages for logging purposes), etc. In other examples, the outbound queue 408B may include log requests, drug library updates, software updates, security updates, and the like. In some embodiments, the items in the outbound queue 408B are less time-sensitive than the items in the outbound queue 206D. The process of detecting and requesting missing messages from the clinical environment 102 is described in greater detail below with reference to FIG. 7. In some cases, the data stored in the cache 408A may be copied or moved to the database 414.” [0033] Inherent with sending relevant messages is not sending the registration information.
Authenticating (receiving and approving) connectivity adapter for cloud (server) access…
“Various techniques for facilitating communication with and across a clinical environment and a cloud environment are described herein. These techniques may include converting pump messages into standardized dataset messages (also referred to herein simply as “messages”), merging the messages into a cache, transmitting the messages to a cloud server, detecting network outages, clearing an outbound queue, detecting missing messages, authenticating a connectivity adapter for cloud access, providing a segmented data structure, among others. These and other embodiments are described in greater detail below with reference to FIGS. 1-13. Although many of the examples are described in the context of a hospital environment including infusion pumps, the techniques described herein can be applied to any network environment including other medical devices (e.g., patient care monitors configured to display blood pressure, heart rate, blood oxygenation, and the like), or non-medical devices, or any combination thereof.” [0004]
See Registration and Expire below.
subsequent to approval of the registration:
exchanging, via the first secure connection, a first plurality of network communications with the medical device server;
Example of secured connection for communications with cloud (server)…
“In some cases, the connectivity adapter 206 may be a network appliance and may lack the capability of managing and maintaining its own user account. In such cases, the connectivity adapter 206 may send an authentication request to the authentication proxy 1006 (e.g., via a connection such as a secured and authenticated WebSocket connection or another other TCP connection), and the authentication proxy 1006 may provide login credentials to the authentication system 1004 on behalf of the connectivity adapter 206 and receive a security token that can be used by the connectivity adapter 206 to generate a signed request. The connectivity adapter 206 may send the signed request to the authentication system 1004 (e.g., using HTTP), just as the authenticated user devices 1002 do in FIG. 10. In some cases, the connection between the connectivity adapter 206 and the authentication proxy 1006 utilize a different communications protocol (e.g., WebSocket) than the connection between the connectivity adapter 206 and the authentication system 1004 (e.g., HTTP). By using the authentication proxy 1006, the connectivity adapter can utilize the cloud services provided by the cloud environment 106 without having to manage user accounts or login credentials. The authentication proxy 1006 may maintain one or more user accounts per clinical environment account.” [0079]
determining that the first secure connection has been disconnected;
Example of determining an interruption (connection disconnected)…
“Clause 55. A method for providing messaging in a clinical environment, the method comprising: storing a plurality of messages in a message queue, wherein the plurality of messages contain information about one or more infusion pumps residing in the clinical environment, the plurality of messages stored in the message queue including at least a first message; transmitting at least some of the plurality of messages to a remote server configured to receive messages generated in the clinical environment; subsequent to the transmission, detecting a temporary interruption in a network connection to the remote server, wherein the temporary interruption prevents transmission of messages to the remote server; determining that the first message in the message queue does not satisfy a condition for being removed from the message queue without being successfully transmitted to the remote server; determining that the temporary interruption has been resolved; and transmitting the first message to the remote server such that the first message is received by the remote server.” [0151]
establishing a second secure connection with the connectivity adapter based at least partly on the signed certificate;
Determining interruption has been resolved (establishing a second connection)…
“Clause 55. A method for providing messaging in a clinical environment, the method comprising: storing a plurality of messages in a message queue, wherein the plurality of messages contain information about one or more infusion pumps residing in the clinical environment, the plurality of messages stored in the message queue including at least a first message; transmitting at least some of the plurality of messages to a remote server configured to receive messages generated in the clinical environment; subsequent to the transmission, detecting a temporary interruption in a network connection to the remote server, wherein the temporary interruption prevents transmission of messages to the remote server; determining that the first message in the message queue does not satisfy a condition for being removed from the message queue without being successfully transmitted to the remote server; determining that the temporary interruption has been resolved; and transmitting the first message to the remote server such that the first message is received by the remote server.” [0151]
Example of second secure network (connection) and token (based on signed certificate)…
“Clause 142. A system configured to authenticate a network device residing in a clinical environment using a token, the system comprising: one or more processors; and one or more memories in communication with the one or more processors and storing computer-executable instructions that, when executed by the one or more processors, configure the one or more processors to: process an authentication request from the network device residing in the clinical environment via a first network connection, wherein the authentication request includes identifying information associated with the clinical environment, and wherein the clinical environment includes one or more infusion pumps in communication with the network device; identify login credentials to be used to authenticate the network device residing in the clinical environment; cause the login credentials to be transmitted to an authentication system configured to authenticate requests from the network device residing in the clinical environment via a second network connection different from the first network connection; receive a security token from the authentication system, the security token being usable by the network device to transmit requests to the authentication system via the second network connection; and cause the security token to be transmitted to the network device residing in the clinical environment via the first network connection.” [0238]
determining that a time period, after which a second request for registration of the medical device is to be sent, has not expired; and
Schedule (determining a time period) for re-sending messages (after which second request for message is to be sent)…
“In some embodiments, when the infusion pump 204 is turned on after being off for a period of time, or upon the connection between the infusion pump 204 and the connectivity adapter 206 being re-established, the infusion pump 204 sends all of the available, unsent messages or data to the connectivity adapter 206. In some cases, such an approach may overload the internal network of the clinical environment 102 (e.g., if 500 infusion pumps 204 came back online after being offline for weeks). Thus, in some cases, the connectivity adapter 206 may deliberately reject such pump messages to reduce the network load, and have the infusion pumps 204 re-send the pump messages at a later time. The infusion pumps 204 may adopt a schedule for re-sending rejected pump messages that further reduces the network load (e.g., exponential back-offs where each retry is performed after a longer wait period, randomization where the back-offs are not strictly exponential and include random temporal variations, a combination of exponential back-offs and randomization, etc.).” [0037]
See Registration and Expire below.
exchanging, based on the time period not being expired, a second plurality of network communications with the medical device server via the second secure connection without performing an additional registration, wherein the second plurality of network communications consume less network bandwidth than the request for registration and the response representing approval of the registration.
{
“Various techniques are described herein for managing the registration of medical devices with servers and/or other computing systems in an efficient manner that reduces the load on networks and servers processing registration requests. These techniques may include use of partial or delayed registration. When a medical device (e.g., an infusion pump) initially connects to a server (e.g., a medical device server or intermediary thereto), the medical device may register with the server. For a period of time after completion of the registration, the medical device may not be required to re-register when a network connection is interrupted and reestablished. To reestablish communications, a secure connection may be established using a process by which the medical device proves its identity. The medical device may then resume normal network communication using the secure connection, without performing a full registration process. Full registration may be delayed until a later time, so long as it is performed before a period of time has expired (e.g., the medical device's registration may expire every 24 hours). Thus, the registration load on networks and servers after network interruptions may be delayed or reduced altogether, which mitigates the risk that registration after an interruption will cause further interruptions. These and other embodiments are described in greater detail below with reference to FIGS. 1-5. Although many of the examples are described in the context of particular medical devices, functions, and hospital or clinical environments, the techniques described herein can be applied to other medical devices, functions, and hospital or clinical environments.” [0004]
Connectivity adapter throttle log (delay registration) requests based on network load (bandwidth), therefore, consume less bandwidth by throttling…
“Upon determining that the DFM 408 is missing one or more events or messages, the DFM 408 may generate a request for such messages and store the request in the outbound queue 408B for transmission to the connectivity adapter 206. In some embodiments, the request is in the standardized dataset format and includes a flag having a value indicating that the request is a log retrieval request and not live data. A single log retrieval request may identify multiple messages to be requested from the infusion pump 204. Upon receiving the log retrieval requests from the cloud environment 106, the connectivity adapter 206 may transform the requests to one or more messages in the pump protocol and send to the infusion pump 204. Alternatively, the connectivity adapter 206 may throttle the requests based on the network load or condition of the clinical environment 102.” [0056]
From Applicant’s specification on bandwidth…
“Some existing methods of communication between medical devices and servers or other computing systems in a clinical environment involve a full registration process whereby a medical device is required to register with a server in order to communicate with the server (e.g., to exchange clinical data, receive programming instructions, etc.). For example, a medical device may be required to provide logging data regarding events occurring on the medical device, manifest data regarding the current software and/or hardware configuration of the medical device, and the like. In this way, a server can ensure that the medical device has the proper components, is communicating using the proper protocols, etc. However, by requiring the exchange of a relatively large amount of data and performing processing of that data by a server to complete the registration, various networking issues may arise. If too many medical devices attempt to register with the server at the same time (e.g., after a network outage or server outage), the full registration processes can overwhelm the network and/or the server and, in extreme cases, can cause a condition similar to a distributed denial of service attack. If network signal availability is inconsistent in a wireless network environment, the repeated registration processes that occur on every reconnection to the network can consume bandwidth and further affect the network, potentially causing additional interruptions.” [0012]
The above teaches network interruptions and load or inconsistent network signal and repeated registration processes can consume bandwidth.
}
Send messages (exchanging communication)…
“In some embodiments, when the infusion pump 204 is turned on after being off for a period of time, or upon the connection between the infusion pump 204 and the connectivity adapter 206 being re-established, the infusion pump 204 sends all of the available, unsent messages or data to the connectivity adapter 206. In some cases, such an approach may overload the internal network of the clinical environment 102 (e.g., if 500 infusion pumps 204 came back online after being offline for weeks). Thus, in some cases, the connectivity adapter 206 may deliberately reject such pump messages to reduce the network load, and have the infusion pumps 204 re-send the pump messages at a later time. The infusion pumps 204 may adopt a schedule for re-sending rejected pump messages that further reduces the network load (e.g., exponential back-offs where each retry is performed after a longer wait period, randomization where the back-offs are not strictly exponential and include random temporal variations, a combination of exponential back-offs and randomization, etc.).” [0037]
Reduce network load (consume less bandwidth) by reject pump messages…
“In some embodiments, when the infusion pump 204 is turned on after being off for a period of time, or upon the connection between the infusion pump 204 and the connectivity adapter 206 being re-established, the infusion pump 204 sends all of the available, unsent messages or data to the connectivity adapter 206. In some cases, such an approach may overload the internal network of the clinical environment 102 (e.g., if 500 infusion pumps 204 came back online after being offline for weeks). Thus, in some cases, the connectivity adapter 206 may deliberately reject such pump messages to reduce the network load, and have the infusion pumps 204 re-send the pump messages at a later time. The infusion pumps 204 may adopt a schedule for re-sending rejected pump messages that further reduces the network load (e.g., exponential back-offs where each retry is performed after a longer wait period, randomization where the back-offs are not strictly exponential and include random temporal variations, a combination of exponential back-offs and randomization, etc.).” [0037]
Remove messages from the queue to not overload (consume less) the network (bandwidth)…“For example, upon determining that the connection to the cloud environment 106 has been terminated or otherwise become unavailable, the connectivity adapter 206 may determine whether the outbound queue 206D includes any messages to be transmitted to the cloud environment 106 and discard one or more of the messages from the outbound queue 206D. For example, in the event of a prolonged outage, there may be a large number of messages in the outbound queue 206D, which may overload the network. For example, the large number of messages in the outbound queue 206D may delay transmission of time-sensitive alerts and may even include messages that are no longer relevant due to the length of the network outage. To prevent such issues, some of the messages in the outbound queue 206D may be removed without transmitting them to the cloud environment 106. In such cases, the cloud environment 106 will request those “missing” messages at a later time. In some embodiments, the messages in the outbound queue are discarded based on time (e.g., after being in the outbound queue for a specific amount of time). Alternatively, the determination of whether to discard one or more messages may be based on the size of the outbound queue. For example, the outbound queue may be fixed in size, and the oldest message is discarded upon a new message being added to the outbound queue that is full. For example, the messages may be discarded based on a first-in first-out (FIFO) manner. In some cases, the connectivity adapter 206 starts removing messages from the outbound queue 206D only after the outbound queue 206D reaches a threshold message size.” [0047]
Certificate
Xavier et al. teaches signed. They also teach connectivity adapter. They do not literally teach certificate.
Mangalvedkar et al. also in the business of signed teaches:
Connection credentials…
“Embodiments of IoT devices 101 may be able to store network connection information and authenticating documentation within a memory 105 or persistent storage 106 device, onboard the IoT device 101 or accessible via a network accessible storage device. Embodiments of the connection information stored by the IoT device 101 may be described as connection credentials 150a, 150b, 150c . . . 150n (referred herein to generally as “credentials 150”). Embodiments of the credentials 150 may store authentication information that may be used for accessing the IoT platform 153. Examples of credentials can include user/password combinations, a security token or a digital certificate. One or more combinations of credentials may be implemented for added security.” [0063] Inherent with not registering and using connection credential is using less bandwidth.
Example of registered information that includes device ID, connection credentials, custom rules, therefore, connection credentials is less information than registration information…
“Embodiments of the provisioning service 109 may dynamically provision and re-provision each IoT device 101 based on whether there are changes to the provisioning rules stored by the rules registry 119. An IoT administrative system 110 may connect to the provisioning service 109, access the rules registry and add, delete or modify provisioning rules maintained by the rules registry 119. As provisioning rules are added, deleted or modified, the provisioning service 109 may re-provision IoT devices 101 currently registered to one or more IoT platforms 153, in accordance with the added, deleted or modified rules. Changes to the device ID, connection credentials, custom rules, etc. which were previously provisioned to the IoT devices 101 may be automatically updated to reflect the current set of provisioning rules stored by the rules registry 119.” [0027]
Credentials as digital certificates, signed objects comprising digital signature or security tokens, etc…
“In step 505 of method 500, the provisioning service 109 may verify the credentials 150 received from the un-provisioned IoT device 101 submitting the registration request. The credentials 150, which may be in the form of digital certificates, signed objects comprising a digital signature or security tokens in some embodiments, may be verified by authenticating the public or private keys, digital signatures or security tokens. The provisioning service 109 may securely validate the credentials by matching the keys, signatures and tokens of the credentials 150 with the authenticated values issued by the issuing authority responsible for issuing the credentials 150 used by the IoT device 101. If the credentials 150 match the values issued by the credentials issued by the issuing authority, then the credentials may be considered verified.” [0101]
Communication unit with adapter (communication adapter)…
“Communication unit 111 provides for communications with other computer systems or devices via a network (e.g., network 160). In the exemplary embodiment, communication unit 111 may include network adapters or interfaces such as a TCP/IP adapter cards, wireless Wi-Fi interface cards, 3G, 4G, or 5G wireless interface cards or other wired or wireless communication links. The network 160 can comprise, for example, copper wires, optical fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. Software and data used to practice embodiments of the present invention can be downloaded to each of the computer systems operating in computing environment 100, 180, 190, 200, 350 or computer system 700 through communication unit 111 (e.g., via the Internet, a local area network or other wide area network). From communication unit 111, the software and data can be loaded onto persistent storage 106.” [0117]
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 Xavier et al. the ability to connect using signed certificate as taught by Mangalvedkar 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 Mangalvedkar et al. who teaches the advantages of signing with credentials instead
Registration and Expire
The combined references teach communicating with a server. They do not teach registration with expire.
Mangalvedkar et al. also in the business of communicating with a server teaches:
“Private cloud: the cloud infrastructure is operated solely for an organization. It may be managed by the organization or a third party and may exist on-premises or off-premises.” [0049]
Cloud (server) computing environment for medical device…
“Referring to the drawings, FIG. 3 is an illustrative example of a cloud computing environment 350. As shown, cloud computing environment 350 includes one or more cloud computing nodes 310 with which IoT devices 101 can be used by cloud consumers, for example, a lighting system 101a, a camera system 101b, a medical monitoring device 101c, an automobile system 101n and/or any physical object equipped with a computing system or computerized components, may communicate. Nodes 310 may communicate with one another and may be grouped (not shown) physically or virtually, in one or more networks, such as Private, Community, Public, or Hybrid clouds as described hereinabove, or a combination thereof. This allows cloud computing environment 350 to offer infrastructure, platforms and/or software as services for which a cloud consumer does not need to maintain resources on a local computing device. It is understood that the types of client devices, including IoT devices 101 connected cloud computing environment, are intended to be illustrative only and that computing nodes 310 and cloud computing environment 350 can communicate with any type of computerized device over any type of network 160 and/or network addressable connection (e.g., using a web browser).” [0054]
Connection credentials…
“Embodiments of IoT devices 101 may be able to store network connection information and authenticating documentation within a memory 105 or persistent storage 106 device, onboard the IoT device 101 or accessible via a network accessible storage device. Embodiments of the connection information stored by the IoT device 101 may be described as connection credentials 150a, 150b, 150c . . . 150n (referred herein to generally as “credentials 150”). Embodiments of the credentials 150 may store authentication information that may be used for accessing the IoT platform 153. Examples of credentials can include user/password combinations, a security token or a digital certificate. One or more combinations of credentials may be implemented for added security.” [0063]
Credentials as signed objects, etc…
“In step 505 of method 500, the provisioning service 109 may verify the credentials 150 received from the un-provisioned IoT device 101 submitting the registration request. The credentials 150, which may be in the form of digital certificates, signed objects comprising a digital signature or security tokens in some embodiments, may be verified by authenticating the public or private keys, digital signatures or security tokens. The provisioning service 109 may securely validate the credentials by matching the keys, signatures and tokens of the credentials 150 with the authenticated values issued by the issuing authority responsible for issuing the credentials 150 used by the IoT device 101. If the credentials 150 match the values issued by the credentials issued by the issuing authority, then the credentials may be considered verified.” [0101]
Time-dependent rules for registration and device registration with expired rule, where inherent with not registering is using less bandwidth…
“FIG. 5a represents a flowchart illustrating a first portion of a method 500 for registering an IoT device 101 to a computer network 160, in accordance with the embodiments of the present disclosure. The embodiment of the method 500 may begin at step 501. In step 501, a provisioning service 109 may receive a request from an un-provisioned IoT device 101 to register the IoT device 101 with one or more IoT platforms 153. The request from the IoT device 101 may be performed because the IoT device 101 is connecting to the provisioning service 109 for the first time or the request may be submitted to the provisioning service 109 because the IoT device's 101 previous registration has expired (i.e., in accordance with a time-dependent rule of the rules registry 119). The IoT device 101 may be connect to the provisioning service 109 via a URL that may be embedded on the IoT device 101 by the manufacturer and/or made available to the IoT device 101 by the IoT platform 153. As shown in FIG. 2, the registration request may be accompanied by a set of credentials 150 and metadata 152 that may be received by provisioning service 109 as part of the registration request.” [0099] Inherent with not registering for connection is using less bandwidth.
Registration with various data…
“In step 503 of method 500, the incoming registration request from one or more IoT devices 101 may be logged with the provisioning log 121 of the provisioning service 109. The provisioning log 121 may record information associated with the registration request including the date and time of the registration request, and whether metadata 152 accompanied the request. The provisioning log 121 may further record one or more elements describing the IoT device 101 that may be have been present in the metadata 152, including the IP address, MAC address, geolocation, preregistration_ID, typeID, and classID of the IoT device 101. Embodiments of the provisioning log 121 may be capable of tracking, organizing, formatting and/or cross referencing logged events associated with reoccurring IoT device 101 registration requests.” [0100]
Registration limited by time period, and credentials set to expire within the time period…
“In step 523 of method 500, the provisioning service 109 may receive the rules statement generated in step 521 from the rules engine 117. The provisioning service 109 may proceed to apply the instructions of the rules statement, thus expressing the rules of the rules registry to provision the IoT device 101. Embodiments of step 523 may include generating credentials 150, a deviceID, user ID/passwords and/or security tokens, that may allow the IoT device 101 to access the IoT platform 153, consistent with the instructions of the rules statement. For example, one instruction of the rules statement generated in step 521 may set a limited time period for IoT device 101 to remain registered with IoT platform 153. The provisioning service in step 523 may apply the limited time period instruction of the rules statement by issuing a set of credentials 150 to the IoT device 101 that expire within the time period specified in the rule. In another example, a rules statement may instruct the provisioning service 109 to delay registration of the IoT device 101 for a set period of time. In accordance with the rules statement, the provisioning service 109 may delay the generation of the credentials 150 being sent to the IoT device 101 until such a time period has been met, or in some embodiments, the provisioning service 109 may issue credentials that become valid as of a particular time in the future that is consistent with the rule instructing the provisioning service 109 to delay access of the IoT device 101 to the IoT platform 153.” [0110]
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 the combined references the ability to connect using credentials and not registration as taught by Mangalvedkar 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 Mangalvedkar et al. who teaches the advantages of setting a registration expiry time but using credentials for communication before expiration.
Regarding claims 9 and 28
(claim 28) The computer-implemented method of claim 21, wherein the medical device comprises an infusion pump.
Xavier et al. teaches:
Infusion pump…
“Modern medical care often involves the use of medical infusion pumps to deliver fluids and/or fluid medicine to patients. Infusion pumps permit the controlled delivery of fluids to a patient and provide flexible yet controlled delivery schedules. Infusion pumps can communicate with a server configured to manage the infusion statuses of the individual infusion pumps.” [0003]
Claims 2-4, 6,7, 10, 22, 23, 25, 26, 29, and 30 are rejected under 35 U.S.C. 103 as being unpatentable over the combined references in section (5) above in further view of Pub. No. US 2005/0138428 to McAllen et al.
Regarding claims 2 and 30
(claim 30) The computer-implemented method of claim 21, further comprising, under control of the connectivity adapter:
forwarding the request for registration to the medical device server;
See Forwarding and Receiving below.
receiving the response from the medical device server; and
See Forwarding and Receiving below.
forwarding the response to the medical device.
See Forwarding and Receiving below.
Forwarding and Receiving below.
The combined references teach registration. They do not teach forwarding and receiving.
McAllen et al. also in the business of registration teaches:
Registering the client with the server and communications between server and client…
“The present invention is generally embodied in a system having one or more servers and one or more clients that are connected to a network. The present invention generally provides a method for discovering what clients are connected to the network, for registering the client with the server, and for providing secure communications between the server and the client. A communication session established between a server and client in accordance with the methods of the present invention is particularly robust in that it inherently provides for re-establishing connections that are dropped for whatever reason, and rejects attempts by rogue or third party servers to connect to the network.” [0010]
Creates TCP/IP connections by the RDS (receiving a response from server) to each endpoint NIM (forwarding to medical devices)…
“Once the NIMs connected to the network have registered with the RDS, the RDS creates TCP/IP connections to each endpoint on every NIM. This provides a reliable means of delivering large application-level messages between the RDS and the endpoints. This is also advantageous in that only the RDS can create a connection to the NIM, and the NIM is programmed to ignore any messages not originating with an RDS. Moreover, the NIM will respond to messages only from the RDS to which it is registered, and will ignore messages from other servers, including rogue servers attempting to impersonate a valid RDS server.” [0143]
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 the combined references the ability to forward and receive data as taught by McAllen 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 McAllen et al. who teaches the advantages of forwarding and receiving data and this allows registration communication with their server and medical devices.
Regarding claims 3 and 22
(claim 22) The computer-implemented method of claim 21, further comprising:
determining, subsequent to exchanging the second plurality of network communications, that the registration is invalid;
See Invalid below.
establish a third secure connection with the connectivity adapter based at least partly on the signed certificate; and
Determining interruption has been resolved (establishing a third connection)…
“Clause 55. A method for providing messaging in a clinical environment, the method comprising: storing a plurality of messages in a message queue, wherein the plurality of messages contain information about one or more infusion pumps residing in the clinical environment, the plurality of messages stored in the message queue including at least a first message; transmitting at least some of the plurality of messages to a remote server configured to receive messages generated in the clinical environment; subsequent to the transmission, detecting a temporary interruption in a network connection to the remote server, wherein the temporary interruption prevents transmission of messages to the remote server; determining that the first message in the message queue does not satisfy a condition for being removed from the message queue without being successfully transmitted to the remote server; determining that the temporary interruption has been resolved; and transmitting the first message to the remote server such that the first message is received by the remote server.” [0151]
Example of second secure network (connection) and token (based on signed certificate)…
“Clause 142. A system configured to authenticate a network device residing in a clinical environment using a token, the system comprising: one or more processors; and one or more memories in communication with the one or more processors and storing computer-executable instructions that, when executed by the one or more processors, configure the one or more processors to: process an authentication request from the network device residing in the clinical environment via a first network connection, wherein the authentication request includes identifying information associated with the clinical environment, and wherein the clinical environment includes one or more infusion pumps in communication with the network device; identify login credentials to be used to authenticate the network device residing in the clinical environment; cause the login credentials to be transmitted to an authentication system configured to authenticate requests from the network device residing in the clinical environment via a second network connection different from the first network connection; receive a security token from the authentication system, the security token being usable by the network device to transmit requests to the authentication system via the second network connection; and cause the security token to be transmitted to the network device residing in the clinical environment via the first network connection.” [0238]
send, to the connectivity adapter via the third secure connection, a third request for registration of the medical device with the medical device server.
Send messages (exchanging communication)…
“In some embodiments, when the infusion pump 204 is turned on after being off for a period of time, or upon the connection between the infusion pump 204 and the connectivity adapter 206 being re-established, the infusion pump 204 sends all of the available, unsent messages or data to the connectivity adapter 206. In some cases, such an approach may overload the internal network of the clinical environment 102 (e.g., if 500 infusion pumps 204 came back online after being offline for weeks). Thus, in some cases, the connectivity adapter 206 may deliberately reject such pump messages to reduce the network load, and have the infusion pumps 204 re-send the pump messages at a later time. The infusion pumps 204 may adopt a schedule for re-sending rejected pump messages that further reduces the network load (e.g., exponential back-offs where each retry is performed after a longer wait period, randomization where the back-offs are not strictly exponential and include random temporal variations, a combination of exponential back-offs and randomization, etc.).” [0037]
Invalid
The combined references teach registration requests. They do not teach registration is invalid.
McAllen et al. also in the business of registration teaches:
NIMs (network interface modules that allows medical devices to connect) registered to RDS (remote data server)…
“Once the NIMs connected to the network have registered with the RDS, the RDS creates TCP/IP connections to each endpoint on every NIM. This provides a reliable means of delivering large application-level messages between the RDS and the endpoints. This is also advantageous in that only the RDS can create a connection to the NIM, and the NIM is programmed to ignore any messages not originating with an RDS. Moreover, the NIM will respond to messages only from the RDS to which it is registered, and will ignore messages from other servers, including rogue servers attempting to impersonate a valid RDS server.” [0143]
Example of values invalid (determining subsequent registration is invalid)…
“When decrypting a message received over a TCP connection using the methods of the illustrated embodiment of the present invention, the first 16 bytes are decrypted using the AES block cipher, unsalted using the transaction key, and examined to see if they contain a valid security header. If the source IP addresses match, and the data size is within a predetermined limit, the system continues to wait for additional bytes to be received until a message of the size specified in the security header has been received. If either of the values are invalid, however, the connection is dropped.” [0162]
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 the combined references the ability to determine an invalid registration as taught by McAllen 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 McAllen et al. who teaches the importance of validating connections for security purposes and the combined references benefit for healthcare privacy and safety as critical data is transmitted.
Regarding claims 4 and 23
(claim 23) The computer-implemented method of claim 21, further comprising:
determining, subsequent to exchanging the second plurality of network communications, that the registration is invalid; and
See Invalid below.
sending, to the connectivity adapter via the second secure connection, a third request for registration of the medical device with the medical device server.
Xavier et al. teaches:
Send messages (exchanging communication)…
“In some embodiments, when the infusion pump 204 is turned on after being off for a period of time, or upon the connection between the infusion pump 204 and the connectivity adapter 206 being re-established, the infusion pump 204 sends all of the available, unsent messages or data to the connectivity adapter 206. In some cases, such an approach may overload the internal network of the clinical environment 102 (e.g., if 500 infusion pumps 204 came back online after being offline for weeks). Thus, in some cases, the connectivity adapter 206 may deliberately reject such pump messages to reduce the network load, and have the infusion pumps 204 re-send the pump messages at a later time. The infusion pumps 204 may adopt a schedule for re-sending rejected pump messages that further reduces the network load (e.g., exponential back-offs where each retry is performed after a longer wait period, randomization where the back-offs are not strictly exponential and include random temporal variations, a combination of exponential back-offs and randomization, etc.).” [0037]
Invalid
The combined references teach registration requests. They do not teach registration is invalid.
McAllen et al. also in the business of registration teaches:
NIMs (network interface modules that allows medical devices to connect) registered to RDS (remote data server)…
“Once the NIMs connected to the network have registered with the RDS, the RDS creates TCP/IP connections to each endpoint on every NIM. This provides a reliable means of delivering large application-level messages between the RDS and the endpoints. This is also advantageous in that only the RDS can create a connection to the NIM, and the NIM is programmed to ignore any messages not originating with an RDS. Moreover, the NIM will respond to messages only from the RDS to which it is registered, and will ignore messages from other servers, including rogue servers attempting to impersonate a valid RDS server.” [0143]
Example of values invalid (determining subsequent registration is invalid)…
“When decrypting a message received over a TCP connection using the methods of the illustrated embodiment of the present invention, the first 16 bytes are decrypted using the AES block cipher, unsalted using the transaction key, and examined to see if they contain a valid security header. If the source IP addresses match, and the data size is within a predetermined limit, the system continues to wait for additional bytes to be received until a message of the size specified in the security header has been received. If either of the values are invalid, however, the connection is dropped.” [0162]
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 the combined references the ability to determine an invalid registration as taught by McAllen 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 McAllen et al. who teaches the importance of validating connections for security purposes and the combined references benefit for healthcare privacy and safety as critical data is transmitted.
Regarding claims 6 and 25
(claim 25) The computer-implemented method of claim 23, wherein determining the registration is invalid comprises determining the medical device server has invalidated the registration.
The combined references teach registration. They do not teach invalidated by server.
Xavier et al. teaches:
Example of authenticate (therefore invalidate) by cloud (server)…
“FIG. 10 illustrates a computing environment 1000 including user device 1002, the clinical environment 102 including the connectivity adapter 206, and the cloud environment 106 including authentication system 1004 and authentication proxy 1006. As shown in FIG. 10, the authentication system 1004 may be configured to authenticate users based on login requests from the user devices 1002, and provide cloud services to user devices 1002 that are successfully authenticated. In such cases, the user device 1002 may own user accounts created by the authentication system 1004 and provide the login credentials for the user accounts each time accessing the cloud services provided by the cloud environment 106.” [0078] Inherent with authenticate is not authenticate.
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 the combined references the ability to invalidate registration by a server as taught by Xavier 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 Xavier et al. who teaches the advantages of authenticating user devices and the it would be obvious this could be done as part of a registration process.
Regarding claims 7 and 26
(claim 26) The computer-implemented method of claim 23, further comprising: receiving, from the connectivity adapter via the second secure connection, a second response representing a registration rejection; and
Xavier et al. teaches:
Authenticating a connectivity adapter (therefore, also rejection registration)…
“Various techniques for facilitating communication with and across a clinical environment and a cloud environment are described herein. These techniques may include converting pump messages into standardized dataset messages (also referred to herein simply as “messages”), merging the messages into a cache, transmitting the messages to a cloud server, detecting network outages, clearing an outbound queue, detecting missing messages, authenticating a connectivity adapter for cloud access, providing a segmented data structure, among others. These and other embodiments are described in greater detail below with reference to FIGS. 1-13. Although many of the examples are described in the context of a hospital environment including infusion pumps, the techniques described herein can be applied to any network environment including other medical devices (e.g., patient care monitors configured to display blood pressure, heart rate, blood oxygenation, and the like), or non-medical devices, or any combination thereof.” [0004] Inherent with authenticating is not authenticating.
determining, in response to the registration rejection, to wait for a predetermined time period before sending a third request for registration.
Schedule (predetermined time) for re-sending rejected pump messages…
“In some embodiments, when the infusion pump 204 is turned on after being off for a period of time, or upon the connection between the infusion pump 204 and the connectivity adapter 206 being re-established, the infusion pump 204 sends all of the available, unsent messages or data to the connectivity adapter 206. In some cases, such an approach may overload the internal network of the clinical environment 102 (e.g., if 500 infusion pumps 204 came back online after being offline for weeks). Thus, in some cases, the connectivity adapter 206 may deliberately reject such pump messages to reduce the network load, and have the infusion pumps 204 re-send the pump messages at a later time. The infusion pumps 204 may adopt a schedule for re-sending rejected pump messages that further reduces the network load (e.g., exponential back-offs where each retry is performed after a longer wait period, randomization where the back-offs are not strictly exponential and include random temporal variations, a combination of exponential back-offs and randomization, etc.).” [0037]
Regarding claims 10 and 29
(claim 29) The computer-implemented method of claim 21, further comprising, under control of the medical device server:
evaluating the request with respect to one or more registration criteria;
See Evaluating and Determining below.
determining, based on results of evaluating the request, to approve the registration; and
See Evaluating and Determining below.
generating the response.
See Evaluating and Determining below.
Evaluating and Determining
The combined references teach registration. They do not teach evaluating and determining.
McAllen et al. also in the business of registration teaches:
Examine to see if valid security header and wait for additional bytes (evaluating request with respect to registration criteria)…
“When decrypting a message received over a TCP connection using the methods of the illustrated embodiment of the present invention, the first 16 bytes are decrypted using the AES block cipher, unsalted using the transaction key, and examined to see if they contain a valid security header. If the source IP addresses match, and the data size is within a predetermined limit, the system continues to wait for additional bytes to be received until a message of the size specified in the security header has been received. If either of the values are invalid, however, the connection is dropped.” [0162]
Valid (determining to approve) based on message decrypted….
“Once the required number of bytes have been received for a message of the specified size, the rest of the message is decrypted and unsalted, and the MD5 hash is verified. If the verification is successful, the data is considered to be valid; if the hash verification fails, the connection is dropped.” [0163]
Sending a reply message…
“In accordance with the principles of the present invention, the only data sent over UDP connections is the RDS beacon message and the NIM status reply message. Furthermore, the status reply message is only sent as a reply to the beacon message, and only one status reply message is sent per beacon message. Likewise, TCP connections only send messages, and ACK responses to those messages. In no case, however, are multiple replies sent (e.g. multiple beacon replies or multiple ACKs). Because of this, all message exchanges utilizing the principles of the present invention may be generalized to say that there is a 1:1 request/reply message ratio.” [0165]
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 the combined references the ability to evaluate and determine as taught by McAllen 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 McAllen et al. who teaches the advantages of evaluating registration criteria and determining to approve as this would be useful steps when registering a medical device with a server.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over the combined references in section (6) above in further view of WO 2022/051230 to Vivek et al.
Regarding claim 5
The system of claim 4, wherein to determine that the registration is invalid, the medical device is configured to determine that a registration time period has expired.
The combined references teach secure registration. They do not teach registration time period has expired.
Vivek et al. also in the business of encrypted nonce (secure registration) teaches:
Example of nonce (registration token) and required to respond within predetermined time period (therefore, determining whether time period has expired)
“At [G], the verification system 104 can verify whether the response from the secure medical device 106 satisfies one or more identification verification criteria. An identification verification criterion may be a requirement that the response include a decrypted version of the encrypted verification data that was sent to the secure medical device 106 at [C]. For example, the verification system 104 may maintain a record of the unencrypted nonce generated at [A], The record may associate the nonce with the specific secure medical device 106 (e.g., the record may reference the DID 220A of the secure medical device 106). Upon receipt of the decrypted nonce 302 from the secure medical device 106, the verification system 104 may access the record of the unencrypted nonce associated with the DID 220A of the secure medical device 106 from which the response was received, and compare the stored nonce to the decrypted nonce 302. If the decrypted nonce 302 matches the stored nonce, then the secure medical device 106 has proven that it has the DISK that corresponds the DID 220A. The medical device 106 may be considered to have proven its identity by virtue of proving that it has the DISK that corresponds to the DID 220A. In some embodiments, alternative or additional identification verification criteria may be required to be satisfied in order to complete the identification protocol successfully. For example, a timestamp may be stored in connection with the nonce 300, indicating when it was provided to the secure medical device 106. The medical device 106 may be required to respond within predetermined or dynamically determined threshold period of time after the time represented by the timestamp.” [0051]
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 the combined references the ability to determine a time registration period has expired as taught by Vivek 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 Vivek et al. who teaches the advantages of security with time limitations and the combined references benefit as they are also concerned about security.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over the combined references in section (5) above in further view of Pub. No. US 2019/0244707 to Becker et al.
Regarding claim 8
The system of claim 1, wherein the medical device is further configured to:
generate a log signal comprising data representing a log of events associated with the medical device;
Xavier et al. teaches:
Example of a log signal that represents messages (events) of infusion pump (medical device)……
“Upon determining that the DFM 408 is missing one or more events or messages, the DFM 408 may generate a request for such messages and store the request in the outbound queue 408B for transmission to the connectivity adapter 206. In some embodiments, the request is in the standardized dataset format and includes a flag having a value indicating that the request is a log retrieval request and not live data. A single log retrieval request may identify multiple messages to be requested from the infusion pump 204. Upon receiving the log retrieval requests from the cloud environment 106, the connectivity adapter 206 may transform the requests to one or more messages in the pump protocol and send to the infusion pump 204. Alternatively, the
connectivity adapter 206 may throttle the requests based on the network load or condition of the clinical environment 102.” [0056]
generate a manifest signal comprising data representing a manifest of hardware and software components of the medical device; and
See Hardware, Software, and Log below.
generate the request for registration comprising the log signal and the manifest signal.
See Hardware, Software, and Log below.
Hardware, Software, and Log
The combined references teach medical devices. They also teach registration with information. They do not teach hardware, software and log.
Becker et al. also in the business of medical devices teaches:
Medical devices with hardware and software and log information…
“The device manufacturing records 52 include one or more of the following sets of records: when and where the medical devices 32 were manufactured; an identification of which options, if any, were installed or built into each medical device 32; the unique identifiers (if any) of the components or subcomponents of each medical device 32 (e.g. a particular type of siderail of a bed 32 may have a unique ID, or a particular electronic circuit board may have a unique ID); the current software and/or hardware version that is installed on the medical devices 32; and a log of the software and/or hardware updates to the medical devices 32. In addition to the foregoing data, the vendor's enterprise system 24 may also include any one or more of the following: a recommended service schedule for each of the medical devices 32, including an identification of the recommended times of service and the recommended types of service; information regarding FDA compliance and/or certification; material safety data sheets, if applicable; and software, hardware, and/or firmware updates for the medical devices 32. Still other device data may also be sent from the vendor's enterprise system 24 to the management service 22 for entry into the individual digital replicas 46 of devices 32.” [0062]
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 the combined references the ability to determine hardware, software, and log information as by Becker 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 Becker et al. who teaches the availability and usefulness of various information and the combined references benefit by using such information for managing their medical devices.
Claims 31 and 32 are rejected under 35 U.S.C. 103 as being unpatentable over the combined references in section (5) above in further view of Pub. No. US 2018/0013571 to Aarnio et al.
Regarding claim 31
The computer-implemented method of claim 21, further comprising:
generating a first message signal for registration of the medical device, wherein generating the first message signal comprises:
generating a registration request signal according to a registration signal definition;
{
From Applicant’s specification on registration signal…
“Additional aspects of the disclosure relate to types of messaging signals used during registration of a medical device, and the data represented by the messaging signals. Messages passed between medical devices, servers, and other computing devices in a clinical environment may be structured using signal definitions specifying the data required and/or permitted to be included in a message. In some embodiments, a top-level message signal definition may specify that certain fields are permitted to be included in a definition. Some of the fields may be relevant to registration of a medical device, such as a field for manifest data, a field for log data (e.g., log history), and a field for requesting registration and responding to the request. Some fields may take a single data item (e.g., one value from a range of possible values), while other fields may be more complex and take their own data structure. For example, the registration field may be defined using a separate registration signal definition that specifies the data required and/or permitted to be included, and the registration signal definition may include additional signal definitions in a nested manner, such as signal definition for registration request-specific data and a signal for registration response-specific data. By including both registration request-specific data and a registration response-specific data in a registration message, the entire registration process can be encapsulated in a single message that is ultimately received by the medical device and able to be processed in a stateless manner.” [0017]
Therefore, registration signal data is data that may be required.
}
See Registration Request below.
generating a log signal comprising data representing a log of events associated with the medical device; and
Xavier et al. teaches:
Example of generate a log retrieval request related to infusion pump…
“Upon determining that the DFM 408 is missing one or more events or messages, the DFM 408 may generate a request for such messages and store the request in the outbound queue 408B for transmission to the connectivity adapter 206. In some embodiments, the request is in the standardized dataset format and includes a flag having a value indicating that the request is a log retrieval request and not live data. A single log retrieval request may identify multiple messages to be requested from the infusion pump 204. Upon receiving the log retrieval requests from the cloud environment 106, the connectivity adapter 206 may transform the requests to one or more messages in the pump protocol and send to the infusion pump 204. Alternatively, the connectivity adapter 206 may throttle the requests based on the network load or condition of the clinical environment 102.” [0056]
See Registration Request below.
generating a manifest signal comprising data representing a manifest of hardware and software components of the medical device; and
See Registration Request below.
sending the first message signal to the medical device server via the connectivity adapter; and
Fig. 3 and send/receive messages via connectivity adapter…
PNG
media_image4.png
178
570
media_image4.png
Greyscale
receiving, from the medical device server via connectivity adapter, a second message signal, wherein the second message signal comprises a registration response signal.
Fig. 3 and send/receive messages via connectivity adapter.
See Registration Request below.
Registration Request
The combined references teach registration. They do not teach details of registration.
Aarnio et al. also in the business of registration teaches:
Example of track equipment registered (therefore, generating registration request signals) and registering computing devices (manifest of hardware), hardware and software version (components), equipment…
“The registration service 134 is configured to register new equipment that is implemented at local medical networks. For example, the registration server 134 will register each new LMN computing device 102, each LME node 106, and each component endpoint 108, among other things. The registration service 134 maintains a registration log 146 in memory 140 that tracks each piece of equipment registered in connection with a local medical network. For example, the registration service 134 maintains records (within the registration log 146) concerning the equipment connected to a local medical network. The records may contain general information regarding an overall medical network. Additionally or alternatively, the records may be specific to subsystems within the local medical network, such as servers, workstations, departments within a medical facility, and the like. Additionally or alternatively, the records may be device specific records regarding computing devices, component endpoints 108, and other medical equipment installed at one or more local medical facilities or networks. By way of example, a separate record may be maintained for each local medical network, each local medical equipment node, each component endpoint 108, and the like. A record may include a unique identifier (ID), hardware and software version information, configuration information, technical specifications, MAC address, and the like for the associated equipment. The registration service 134 may generate a new device specific record (or update a local network record) when a piece of equipment is added (e.g., registered) to the local medical network.” [0044]
Data logs…
“By authenticating component endpoints, embodiments herein avoid operation of the system with “counterfeit,” “fake,” or otherwise un-authorized component endpoints. Preventing use of un-authorized component endpoints affords various benefits, such as improving patient safety and maintaining a reliable customer-supplier business relationship. In addition, in the event of an accident or other problem, patient measurement data and system operation may be checked through data logs and patient records, even when a component endpoint is not validated when activated.” [0033]
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 the combined references the ability to generate various data as taught by Aarnio 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 Aarnio et al. who teaches registration data includes various types of data and it would be useful to have such data.
Regarding claim 32
The computer-implemented method of claim 31, wherein the second message signal received from the connectivity adapter further comprises the registration request signal.
Xavier et al. teaches:
Fig. 3 and send/receive messages via connectivity adapter…
PNG
media_image4.png
178
570
media_image4.png
Greyscale
See Registration Request below.
Registration Request
The combined references teach registration. They do not teach details of registration.
Aarnio et al. also in the business of registration teaches:
Example of track equipment registered (therefore, generating registration request signals) and registering computing devices (manifest of hardware), hardware and software version (components), equipment…
“The registration service 134 is configured to register new equipment that is implemented at local medical networks. For example, the registration server 134 will register each new LMN computing device 102, each LME node 106, and each component endpoint 108, among other things. The registration service 134 maintains a registration log 146 in memory 140 that tracks each piece of equipment registered in connection with a local medical network. For example, the registration service 134 maintains records (within the registration log 146) concerning the equipment connected to a local medical network. The records may contain general information regarding an overall medical network. Additionally or alternatively, the records may be specific to subsystems within the local medical network, such as servers, workstations, departments within a medical facility, and the like. Additionally or alternatively, the records may be device specific records regarding computing devices, component endpoints 108, and other medical equipment installed at one or more local medical facilities or networks. By way of example, a separate record may be maintained for each local medical network, each local medical equipment node, each component endpoint 108, and the like. A record may include a unique identifier (ID), hardware and software version information, configuration information, technical specifications, MAC address, and the like for the associated equipment. The registration service 134 may generate a new device specific record (or update a local network record) when a piece of equipment is added (e.g., registered) to the local medical network.” [0044]
Data logs…
“By authenticating component endpoints, embodiments herein avoid operation of the system with “counterfeit,” “fake,” or otherwise un-authorized component endpoints. Preventing use of un-authorized component endpoints affords various benefits, such as improving patient safety and maintaining a reliable customer-supplier business relationship. In addition, in the event of an accident or other problem, patient measurement data and system operation may be checked through data logs and patient records, even when a component endpoint is not validated when activated.” [0033]
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 the combined references the ability to generate various data as taught by Aarnio 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 Aarnio et al. who teaches registration data includes various types of data and it would be useful to have such data.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
The following prior art teaches registration and expire with credential…
US-20090103455-A1; US-20090116447-A1
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