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 .
DETAILED ACTION
Response to Amendment
The present Office Action is in response to the Request for Continued Examination dated 03/18/2026.
In the amendment dated 03/18/2026, the following occurred: Claims 1, 6 and 15 was amended. Claim 12 was canceled.
Claims 1-11 and 13-20 are currently pending.
Request for Continued Examination
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 03/18/2026 has been entered.
Claim Objections
Claim 1 is objected to for the following informality: “receive medical data in the first data format from a medical device via the input interface” should read “receive medical data in the first data format from the medical device via the input interface”
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-11 and 13-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1
The claim recites an apparatus for communication and transmission of medical data, which is within a statutory category.
Step 2A1
The limitations of store at least one configuration file, the at least one configuration file specifying; ports for communicatively coupling, a first data format comprising a Health-Level 7 ("HL7") protocol, a Fast Healthcare Interoperability Resources ("FHIR") protocol, or a binary protocol, and a second data format comprising JavaScript Object Notation ("JSON") or Hypertext Transfer Protocol ("HTTP"); read the at least one configuration file to determine the first data format is specified for transmission of medical data, and determine the second data format is specified for transmission of medical data, receive medical data in the first data format, select a first subset of the medical data for transmission in the first data format, convert a second subset of the medical data to the second data format, and transmit the second subset of the medical data in the second data format, as drafted, is a process that, under the broadest reasonable interpretation, covers certain methods of organizing human activity (i.e., managing personal behavior including following rules or instructions) but for recitation of generic computer components. The claims encompass a series of rules or instructions for a person or persons to follow, with or without the aid of a computer, to store configuration file, determine the first and second data format, receive medical data in the first data format, select a first subset of the medical data for transmission in the first data format, convert a second subset of the medical data to the second data format, and transmit the second subset of the medical data in the second data format in the manner described in the identified abstract idea, supra. The rules or instructions are the claimed steps of “store… determine…determine…receive…select… convert and transmit date” as indicated supra.
Other than reciting generic computer components (discussed infra), i.e., a digital communication apparatus comprising an input interface including a serial input port, an Ethernet input port, and a wireless input port, an output interface including a serial output port, an Ethernet output port, and a wireless output port, a memory device and a processor (all part of a generic computer), the claimed invention amounts to managing personal behavior or interaction between people. If a claim limitation, under its broadest reasonable interpretation, covers managing personal behavior or interactions between people but for the recitation of generic computer components, then it falls within the “certain methods of organizing human activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application. In particular, claim 1 recites the additional elements of a digital communication apparatus comprising an input interface including a serial input port, an Ethernet input port, and a wireless input port, an output interface including a serial output port, an Ethernet output port, and a wireless output port, a memory device and a processor. These additional elements are not exclusively defined by the applicant and are recited at a high-level of generality (i.e., a generic computer components for enabling access to medical information or for performing generic computer functions) such that they amounts to no more than mere instructions to apply the exception using a generic computer component. As set forth in MPEP 2106.04(d) “merely including instructions to implement an abstract idea on a computer” is an example of when an abstract idea has not been integrated into a practical application. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Claim 1 further recite the additional elements of a medical device, remote server and medical network. These additional element are recited at a high level of generality (i.e. a general means to receive/transmit data) and amount to a location of where data is received and transmitted, which is a form of extra solution activity. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of a digital communication apparatus comprising an input interface including a serial input port, an Ethernet input port, and a wireless input port, an output interface including a serial output port, an Ethernet output port, and a wireless output port, a memory device and a processor to perform the noted steps amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept (“significantly more”). Moreover, using generic computer components to perform abstract ideas does not provide a necessary inventive concept. See Alice, 573 U.S. at 223 (“mere recitation of a generic computer cannot transform a patent-ineligible abstract idea into a patent-eligible invention”). Therefore, whether considered alone or in combination, the additional elements do not amount to significantly more than the abstract idea.
Also as discussed with respect to integration of the abstract idea into a practical application, the additional elements of a medical device, remote server and medical network were considered extra-solution activity. This has been re-evaluated under the “significantly more” analysis and determined to be well-understood, routine, conventional activity in the field. MPEP 2016.05(d)(II) indicates that receiving and/or transmitting data over a network has been held by the courts to be well-understood, routine, conventional activity (citing Symantec, TLI Communications, OIP Techs., and buySAFE). Well-understood, routine, conventional activity cannot provide an inventive concept (“significantly more”). As such the claim is not patent eligible.
Claims 2-11 and 13-20 are similarly rejected because they either further define/narrow the abstract idea and/or do not further limit the claim to a practical application or provide as inventive concept such that the claims are subject matter eligible even when considered individually or as an ordered combination. Claim(s) 2 further merely describe(s) the first subset of the medical data is the same as the second subset of the medical data. Claim(s) 3 further merely describes(s) provides for communicative coupling to at least one of an electronic medical record ("EMR") server, a middleware server, or an integration engine. Claim(s) 3 also include the additional element of “an electronic medical record ("EMR") server, a middleware server, or an integration engine” which are analyzed the same as the medical network and the remote server and do not provide practical application or significantly more for the same reasons. Claim(s) 4 further merely describes(s) a first connectivity agent and using a messaging protocol for transmission of the second subset of the medical data in the second data format. Claim(s) 5 further merely describes(s) the messaging protocol includes a Message Queuing Telemetry Transport ("MQTT") publish- subscribe network protocol. Claim(s) 6 further merely describes(s) wherein the at least one configuration file specifies a first destination network address and a second destination network address, and wherein the first destination network address is associated with a network domain that includes the medical network and the second destination network address is associated with a network domain that is external to the medical network. Claim(s) 7 further merely describes(s) generating log data and health data; and including the log data and the health data with the first subset of the medical data for transmission in the first data format. Claim(s) 8 further merely describes(s) the log data includes at least one of an identification of a medical device type, an identification of a medical device serial number, a time stamp from which the received medical data was generated by the medical device or received by the processor from the medical device, an identifier of the digital communication apparatus, a timestamp for the first subset of the medical data, or a monotonic time stamp. Claim(s) 9 further merely describes(s) the health data includes information related to the memory device, CPU usage information, network connectivity information, process/thread information, or information related to software operated by the processor. Claim(s) 10 further merely describes(s) generating log data and health data; converting the log data to the second data format; and including the log data with the second subset of the medical data for transmission. Claim(s) 11 further merely describes(s) anonymizing patient information included within the second subset of the medical data before transmission, or encrypt the second subset of the medical data before transmission. Claim(s) 13 further merely describes(s) wherein the wireless input port includes at least one of a Wi-Fi input port and a Bluetooth® input port and the wireless output port includes at least one of a Wi-Fi output port or a cellular output port. Claim(s) 13 also include the additional element of “Wi-Fi input port and a Bluetooth® input port” which are analyzed the same as the wireless input and output ports and do not provide practical application or significantly more for the same reasons. Claim(s) 14 further merely describes(s) the medical data includes at least one of: event information comprising transitions between fill, dwell, and drain phase of a dialysis cycle; alarm information; treatment programming information; or treatment information comprising an estimated fill rate, a drain rate, and an amount of ultrafiltration removed. Claim(s) 15 further merely describes(s) receiving a stream of the medical data; creating a snapshot of the medical data at periodic intervals; and providing the snapshot of the medical data as at least one of the first subset of the medical data or the second subset of the medical data. Claim(s) 16 further merely describes(s) the periodic intervals have a period between five seconds and sixty seconds. Claim(s) 17 further merely describes(s) using event tracking to identify changes to the medical data between snapshots; and including only the changed medical data from a previous snapshot as at least one of the first subset of the medical data or the second subset of the medical data. Claim(s) 18 further merely describes(s) the remote server includes one or more application programming interfaces ("API") for receiving the second subset of the medical data for storage within at least one of a Structured Query Language ("SQL") database, a NoSQL database, or an Amazon® Relational Database Service ("RDS"). Claim(s) 18 also include the additional element of “one or more application programming interfaces ("API"), a Structured Query Language ("SQL") database, a NoSQL database, or an Amazon® Relational Database Service ("RDS")” which are analyzed the same as the remote server and do not provide practical application or significantly more for the same reasons. Claim(s) 19 further merely describes(s) the remote server is an analytics server that is configured to periodically analyze the second subset of the medical data for key performance indicators ("KPIs") related to operation of the medical device, and wherein the KPIs include treatment trends, component usage trends, or alert/alarm trends. Claim(s) 20 further merely describes(s) wherein the remote server is an analytics server that is configured to determine recommendations or guidelines to improve operation of the medical device. Claim(s) 19 and 20 also include the additional element of “an analytics server” which is analyzed the same as the remote server and does not provide practical application or significantly more for the same reasons.
Claims 2-11 and 13-20 further define the abstract idea and are rejected for the same reason presented above with respect to claim 1.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 2, 4, 7-10 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Espina (US 2010/0049005), in view of Jarman (US 2018/0032573) and in further view of Chan (US 2011/0219091).
REGARDING CLAIM 1
Espina discloses a digital communication apparatus comprising: an input interface configured for communicative coupling to a medical device, the input interface including a serial input port, an Ethernet input port, and a wireless input port; an output interface configured for communicative coupling to a medical network and a remote server that is external to the medical network, the output interface including a serial output port, an Ethernet output port, and a wireless output port (Espina at [0021] teaches a medical equipment interface may be a receptacle for a cable connecting the wireless device to the item of medical equipment (interpreted by Examiner as the input interface configured for communicative coupling to a medical device, the input interface including a serial input port, an Ethernet input port, and a wireless input port). In the alternative, the wireless device may be configured as a stick (similar to a USB stick) that connects to a jack at the item of medical equipment which obviates the need for a cable and facilitates the handling and use of medical equipment. [0022] teaches the wireless interface (interpreted by Examiner as the output interface configured for communicative coupling to a medical network and a remote server that is external to the medical network, the output interface including a serial output port, an Ethernet output port, and a wireless output port) may support a communication standard such as ZigBee, Bluetooth, or IEEE 802.11b. Fig. 5 and [0093] teach a medical equipment interface MEI that provides connection to an item of medical equipment. The medical equipment interface as presented in FIG. 5 provides a jack for connecting a cable that leads to the item of medical equipment. Inside the wireless device WD the medical equipment interface is connected to a processor (processing unit) PU via a connection 51. It is connected to a working memory WM and a parameter memory PM. Data that was received at one interface, i.e. medical equipment interface or wireless interface can be temporarily stored in the working memory WM. The processor is also connected to a wireless interface WI via a connection 52. The wireless interface is further connected to an antenna for sending and/or receiving wireless data); a memory device configured to store at least one configuration file for the input interface and output interface (Espina at [0025] teaches storing the content configuration file in various registers and memories. [0030] teaches the processor is further arranged to read the configuration file from the medical device interface or from the wireless interface so that no additional configuration interface is needed. [0053] teaches the configuration file may contain information for each interface (interpreted by Examiner as a memory device configured to store at least one configuration file for the input interface and output interface)), the at least one configuration file specifying; one of the input ports for communicatively coupling with the medical device, one of the Ethernet output port or the wireless output port provide for communicatively coupling with the remote server, one of the serial output port or an Ethernet output port for communicatively coupling with the medical network, a first data format, and a second data format (Espina at [0031] teaches receiving configuration file from a configuration file tool (interpreted by Examiner as a configuration file). A configuration file tool may present the different options of protocol adaptation to a user in an organized fashion. [0017] teaches a configuration file contains an adaptation specification that pertains to the protocol adaptation, and to perform the protocol adaptation in compliance with the adaptation specification. [0028] teaches the configuration file may describe the protocol adaptation by defining at least one mapping between a data pattern at the medical equipment interface and a data pattern at the wireless interface. The mapping may comprise a transformation rule defining a transformation from the data pattern at the medical equipment interface to the data at the wireless interface or vice versa (interpreted by Examiner as the configuration file specifying one of the input ports, one of the Ethernet output port or the wireless output port, one of the serial output port or an Ethernet output port, a first data format, and a second data format)); and a processor communicatively coupled to the input interface, the output interface, and the memory device, the processor configured to: receive medical data in the first data format from a medical device via the input interface, select a first subset of the medical data for transmission in the first data format to the medical network via the serial output port or the Ethernet output port (Espina at [abstract] teaches that the protocol adaptation takes place from a protocol of incoming data received at the medical equipment interface (interpreted by Examiner as the input interface) to a protocol of data to be transmitted through the wireless interface (interpreted by Examiner as serial output port or the Ethernet output port), or vice versa. [0024] teaches the protocol adaptation is performed on data that is received at either the medical equipment interface or the wireless interface (interpreted by Examiner as receive medical data in the first data format from a medical device via the input interface). [0025] teaches that the configuration file used for specifying the protocol adaptation may contain filtering patterns, storing patterns, assembly patterns and prioritizing patterns. [0028] teaches the configuration file may describe the protocol adaptation by defining at least one mapping between a data pattern at the medical equipment interface and a data pattern at the wireless interface. The mapping may comprise a transformation rule defining a transformation from the data pattern at the medical equipment interface to the data at the wireless interface or vice versa. [0029] teaches the configuration file may describe the protocol adaptation by defining minimum requirements for processing payload data pertaining to the item of medical equipment. The properties of the wireless link include maximal data rate, maximal packet size, currently available bandwidth, or current consumption. The sending wireless device receives the payload data at its medical equipment interface and is able to analyze the payload data. The receiving wireless device does not have this opportunity. Therefore it is contemplated to first cause the sending wireless device to establish a protocol adaptation based on the minimum requirements contained in the configuration file, the properties of the wireless link, and an analysis of the payload data (received at the medical equipment interface of the wireless device). As soon as the sending wireless device has established a set of rules by which protocol adaptation will be performed, the sending wireless device sends the set of rules to the receiving wireless device. The receiving wireless device processes the received set of rules in order to determine how to perform the backward protocol adaptation that allows retrieving a faithful reproduction of the payload data. [0052] teaches that in the case the wireless device WD1, WD2 is arranged for bi-directional transmission, it is able to accept input data at both of its interfaces and pass it on to the respective other interface after suitable data processing in accordance with the configuration file. [0094] and Fig. 6 teach a frame of data 61 (interpreted by Examiner as select a first subset of the medical data for transmission in the first data format to the medical network via the serial output port or the Ethernet output port). Moreover, the analyzer ANLZ determines sections within the data frame 61 that indicate a possible data reduction. Depending on the data the analyzer ANLZ finds in data frame 61, it determines which action should be taken in order to perform the desired protocol adaptation. If the analyzer ANLZ has decided which action should be taken on the current data, it directs the concerned portion of data frame 61 to one of several processing modules),
Espina does not explicitly disclose a first data format comprising a Health-Level 7 ("HL7") protocol, a Fast Healthcare Interoperability Resources ("FHIR") protocol, or a binary protocol and a second data format comprising JavaScript Object Notation ("JSON") or Hypertext Transfer Protocol ("HTTP"), however Jarman further discloses:
a first data format comprising a Health-Level 7 ("HL7") protocol, a Fast Healthcare Interoperability Resources ("FHIR") protocol, or a binary protocol and a second data format comprising JavaScript Object Notation ("JSON") or Hypertext Transfer Protocol ("HTTP"); (Jarman at [0075] teaches formats of the received data include HL7 (interpreted by Examiner as the first data format) and that data may be sent over HTTP messages and/or may be sent in the JSON data format (interpreted by Examiner as the second data format)),
It would have been prima facie obvious to one of ordinary skill in the art at the time of the invention was made to combine the noted features of Espina with teaching of Jarman since known work in one field of endeavor may prompt variations in design in either the same field or a different field based on design incentives or other market forces if the variations would have been predictable to one of ordinary skill in the art. One of ordinary skill in the art of healthcare would have found it obvious to update the first and second data format of the primary reference using the first data format comprising a Health-Level 7 ("HL7") protocol, a Fast Healthcare Interoperability Resources ("FHIR") protocol, or a binary protocol and the second data format comprising JavaScript Object Notation ("JSON") or Hypertext Transfer Protocol ("HTTP") as found in the second reference, in order to gain the commonly understood benefits of such adaptation, such as improve the accuracy, security, and efficiency of data processing and/or computing systems. This update would be accomplished with no unpredictable results.
Espina and Jarman do not explicitly disclose read the at least one configuration file to determine the first data format is specified for transmission of medical data to the medical network via the serial output port or the Ethernet output port, and determine the second data format is specified for transmission of medical data to the remote server via the Ethernet output port or the wireless output port; convert a second subset of the medical data to the second data format, and transmit the second subset of the medical data in the second data format to the remote server via the Ethernet output port or the wireless output port, however Chan further discloses:
read the at least one configuration file to determine the first data format is specified for transmission of medical data to the medical network via the serial output port or the Ethernet output port, and determine the second data format is specified for transmission of medical data to the remote server via the Ethernet output port or the wireless output port (Chan at [0047] teaches data server of network bridge can be adapted to format the received medical data (interpreted by Examiner as the medical data of Espina above) in a specified format for transfer and network bridge can be reconfigured to format the medical data in a different format as may be needed. [0048] teaches that a skilled artisan will also appreciate that the standard format can be any format desired. [0050] also teaches the network bridge can translate the received response into a specified format for transmission (interpreted by Examiner as means to determine first/second data format specified for transmission)), convert a second subset of the medical data to the second data format, and transmit the second subset of the medical data in the second data format to the remote server via the Ethernet output port or the wireless output port (Chan at [0026] teaches obtaining medical data from a medical device [0041] teaches an output port for transmitting the medical data and [0043] teaches translating data to various formats by a variety of protocol translation (interpreted by Examiner as the wireless output port of Espina above that transmits the second subset of the medical data in the second data format to the remote server). [0050] teaches translating to a standard format or into a specified format for transmission, [0066] teaches the collected medical data may be formatted according to the defined protocol and [0089] teaches transmission protocols and data formats such as hypertext transfer protocol (HTTP)),
It would have been prima facie obvious to one of ordinary skill in the art at the time of the invention was made to combine the noted features of Espina and Jarman with teaching of Chan since known work in one field of endeavor may prompt variations in design in either the same field or a different field based on design incentives or other market forces if the variations would have been predictable to one of ordinary skill in the art. One of ordinary skill in the art of healthcare would have found it obvious to update the data configuration files and transmission methods of the primary and secondary reference using reading the at least one configuration file to determine the first and second data format specified for transmission and converting a second subset of the medical data to the second data format, and transmit the second subset in the second data format as found in the third reference, in order to gain the commonly understood benefits of such adaptation, such as enabling communication of medical data over a variety of networks using a variety of different protocols without re-configuration. This update would be accomplished with no unpredictable results.
REGARDING CLAIM 2
Espina, Jarman and Chan disclose the limitation of claim 1.
Espina further discloses:
The digital communication apparatus of Claim 1, wherein the first subset of the medical data is the same as the second subset of the medical data (Espina at [0094] teaches the analyzer ANLZ could also look out for data that is identical to preceding data (interpreted by Examiner as means the first subset of the medical data is the same as the second subset of the medical data)).
REGARDING CLAIM 4
Espina, Jarman and Chan disclose the limitation of claim 1.
Espina further discloses:
The digital communication apparatus of Claim 1, wherein the processor includes a first connectivity agent and uses a messaging protocol for transmission of the second subset of the medical data in the second data format (Espina at [0017] teaches the processor is arranged to communicate (interpreted by Examiner as means to include a first connectivity agent) with the medical equipment interface and the wireless interface, and is also arranged to perform a protocol adaptation. The protocol adaptation takes place from a protocol of incoming data received at the medical equipment interface to a protocol of data to be transmitted through the wireless interface, or vice versa (interpreted by Examiner as means to use a messaging protocol for transmission of data)).
REGARDING CLAIM 7
Espina, Jarman and Chan disclose the limitation of claim 1.
Espina further discloses:
The digital communication apparatus of Claim 1, wherein the processor is further configured to: generate log data and health data; and include the log data and the health data with the first subset of the medical data for transmission in the first data format via the output interface to the medical network (Espina at [0034] teaches data received from the item of medical equipment and data to be transmitted to the second wireless device (interpreted by Examiner as health data) and [0106] teaches sending a schedule defining the times (interpreted by Examiner as data can be log data) or conditions of the refilling action).
REGARDING CLAIM 8
Espina, Jarman and Chan disclose the limitation of claim 7.
Espina further discloses:
The digital communication apparatus of Claim 7, wherein the log data includes at least one of an identification of a medical device type, an identification of a medical device serial number, a time stamp from which the received medical data was generated by the medical device or received by the processor from the medical device, an identifier of the digital communication apparatus, a timestamp for the first subset of the medical data, or a monotonic time stamp (Espina at [0094] teaches an identification number of the item of medical equipment (interpreted by Examiner as log data includes an identification of a medical device type).
REGARDING CLAIM 9
Espina, Jarman and Chan disclose the limitation of claim 7.
Espina further discloses:
The digital communication apparatus of Claim 7, wherein the health data includes information related to the memory device, CPU usage information, network connectivity information, process/thread information, or information related to software operated by the processor (Espina at [0093] teaches memory is populated during the set up (configuration) of the wireless device with parameter values that are read from one or several configuration files (interpreted by Examiner as health information includes information related to)).
REGARDING CLAIM 10
Espina, Jarman and Chan disclose the limitation of claim 1.
Espina further discloses:
The digital communication apparatus of Claim 1, wherein the processor is further configured to: generate log data and health data; convert the log data to the second data format; and include the log data with the second subset of the medical data for transmission via the output interface to the remote server (Espina at [0034] teaches data received from the item of medical equipment and data to be transmitted to the second wireless device (interpreted by Examiner as health data) and [0106] teaches sending a schedule defining the times (interpreted by Examiner as data can be log data) or conditions of the refilling action. [0094] teaches the analyzer ANLZ determines sections within the data frame 61 that indicate a possible data reduction. Depending on the data the analyzer ANLZ finds in data frame 61, it determines which action should be taken in order to perform the desired protocol adaptation. If the analyzer ANLZ has decided which action should be taken on the current data, it directs the concerned portion of data frame 61 to one of several processing modules (interpreted by Examiner as convert the log data to the second data format; and include the log data with the second subset of the medical data for transmission via the output interface to the remote server)).
REGARDING CLAIM 14
Espina, Jarman and Chan disclose the limitation of claim 1.
Espina further discloses:
The digital communication apparatus of Claim 1, wherein the medical data includes at least one of: event information comprising transitions between fill, dwell, and drain phase of a dialysis cycle; alarm information; treatment programming information; or treatment information comprising an estimated fill rate, a drain rate, and an amount of ultrafiltration removed (Espina at [0105] teaches data that is highly prioritized could be an alarm such as overstepping of threshold values for the measured variable, or a low battery alarm at one of the items of medical equipment or the wireless devices (interpreted by Examiner as the medical data includes event information comprising alarm information)).
Claims 3 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Espina (US 2010/0049005), in view of Jarman (US 2018/0032573), in view of Chan (US 2011/0219091) and in further view of Dicks (US 2008/0218376).
REGARDING CLAIM 3
Espina, Jarman and Chan disclose the limitation of claim 1.
Espina, Jarman and Chan do not explicitly disclose the output interface provides for communicative coupling to at least one of an electronic medical record (“EMR”) server, however Dicks further discloses:
The digital communication apparatus of Claim 1, wherein the output interface provides for communicative coupling to at least one of an electronic medical record (“EMR”) server, a middleware server, or an integration engine via the medical network (Dicks at [0028] teaches a message is formatted and transmitted to a medical data server (interpreted by Examiner as the electronic medical record ("EMR") server). Optionally, a command can be received from the medical data server (155) and optionally relayed from the intermediary device. [0043] teaches receiving the medical device data using a wireless network protocol (interpreted by Examiner as the medical network)).
It would have been obvious for one of the ordinary skill in the art before the effective filling date of the claimed invention to have modified the systems and methods of Espina, Jarman and Chan to incorporate communicative coupling to at least one of an electronic medical record (“EMR”) server as taught by Dicks with the motivation of increasing the efficiency and effectiveness of providing care to patients while reducing costs (Dicks at [0011]).
REGARDING CLAIM 11
Espina, Jarman and Chan disclose the limitation of claim 1.
Espina, Jarman and Chan do not explicitly disclose encrypting data before transmission, however Dicks further discloses:
The digital communication apparatus of Claim 1, wherein the processor is further configured to at least one of: anonymize patient information included within the second subset of the medical data before transmission, or encrypt the second subset of the medical data before transmission (Dicks at [0047] teaches the medical device data can be encrypted prior to transmission).
It would have been obvious for one of the ordinary skill in the art before the effective filling date of the claimed invention to have modified the data transmission methods of Espina, Jarman and Chan to incorporate encrypting data before transmission as taught by Dicks with the motivation of increasing the efficiency and effectiveness of providing care to patients while reducing costs (Dicks at [0011]).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Espina (US 2010/0049005), in view of Jarman (US 2018/0032573), in view of Chan (US 2011/0219091) and in further view of Laval (US 2015/0097697).
REGARDING CLAIM 5
Espina, Jarman and Chan disclose the limitation of claim 4.
Espina, Jarman and Chan do not explicitly disclose the messaging protocol to include a Message Queuing Telemetry Transport (“MQTT”) publish-subscribe network protocol, however Laval further discloses:
The digital communication apparatus of Claim 4, wherein the messaging protocol includes a Message Queuing Telemetry Transport (“MQTT”) publish-subscribe network protocol (Laval at [0065] teaches using messaging protocols such as Message Queuing Telemetry Transport (MQTT)).
It would have been prima facie obvious to one of ordinary skill in the art at the time of the invention was made to combine the noted features of Espina, Jarman and Chan with teaching of Laval since known work in one field of endeavor may prompt variations in design in either the same field or a different field based on design incentives or other market forces if the variations would have been predictable to one of ordinary skill in the art. One of ordinary skill in the art of healthcare would have found it obvious to update the protocols of the primary, secondary and third reference using a messaging protocol that includes a Message Queuing Telemetry Transport ("MQTT") publish-subscribe network protocol as found in the fourth reference, in order to gain the commonly understood benefits of such adaptation, such as improved the simplicity, integrity, and security of information exchanges, filter a significant amount of unused data overhead, and reduce/eliminate the need to backhaul all raw data to a central data center. This update would be accomplished with no unpredictable results.
Claims 6, 15, 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Espina (US 2010/0049005), in view of Jarman (US 2018/0032573), in view of Chan (US 2011/0219091) and in further view of Tukol (US 2012/0197973).
REGARDING CLAIM 6
Espina, Jarman and Chan disclose the limitation of claim 1.
Espina, Jarman and Chan do not explicitly disclose wherein the configuration file specifies a first destination network address for the medical network and a second destination network address for the remote server, and wherein the first destination network address is associated with a network domain that includes the medical network and the second destination network address is associated with a network domain that is external to the medical network, however Tukol further discloses:
The digital communication apparatus of Claim 1, wherein the configuration file specifies a first destination network address for the medical network and a second destination network address for the remote server, and wherein the first destination network address is associated with a network domain that includes the medical network and the second destination network address is associated with a network domain that is external to the medical network (Tukol at [0068] teaches addressing by a corresponding network address such as, but not limited to, an Internet protocol (IP) address (interpreted by Examiner as means to specifies a first and second destination network address)).
It would have been prima facie obvious to one of ordinary skill in the art at the time of the invention was made to combine the noted features of Espina, Jarman and Chan with teaching of Tukol since known work in one field of endeavor may prompt variations in design in either the same field or a different field based on design incentives or other market forces if the variations would have been predictable to one of ordinary skill in the art. One of ordinary skill in the art of healthcare would have found it obvious to update the configuration file of the primary reference and the transmission methods of the secondary and third reference using configuration files specifying destinations as found in the fourth reference, in order to gain the commonly understood benefits of such adaptation, such as reducing the usage of high bandwidth and time. This update would be accomplished with no unpredictable results.
REGARDING CLAIM 15
Espina, Jarman and Chan disclose the limitation of claim 1.
Espina, Jarman and Chan do not explicitly disclose wherein the processor is configured to: receive a stream of the medial data; create a snapshot of the medical data at periodic intervals; and provide the snapshot of the medical data as at least one of the first subset of the medical data or the second subset of the medical data, however Tukol further discloses:
The digital communication apparatus of Claim 1, wherein the processor is configured to: receive a stream of the medial data; create a snapshot of the medical data at periodic intervals; and provide the snapshot of the medical data as at least one of the first subset of the medical data or the second subset of the medical data (Tukol at [0143] teaches receiving data (interpreted by Examiner as receive a stream of the medial data) [0153] and [0154] teaches creating and providing snapshots).
It would have been prima facie obvious to one of ordinary skill in the art at the time of the invention was made to combine the noted features of Espina, Jarman and Chan with teaching of Tukol since known work in one field of endeavor may prompt variations in design in either the same field or a different field based on design incentives or other market forces if the variations would have been predictable to one of ordinary skill in the art. One of ordinary skill in the art of healthcare would have found it obvious to update the system and methods of the primary, secondary and third reference using the functions of the processor of the fourth reference to receive a stream of the medial data, create a snapshot of the medical data at periodic intervals and provide the snapshot of the medical data as at least one of the first subset of the medical data or the second subset of the medical data, in order to gain the commonly understood benefits of such adaptation, such as reducing the usage of high bandwidth and time. This update would be accomplished with no unpredictable results.
REGARDING CLAIM 17
Espina, Jarman, Chan and Tukol disclose the limitation of claim 15.
Espina, Jarman and Chan do not explicitly disclose wherein the processor is further configured to: use event tracking to identify changes to the medical data between snapshots; and include only the changed medical data from a previous snapshot as at least one of the first subset of the medical data or the second subset of the medical data, however Tukol further discloses:
The digital communication apparatus of Claim 15, wherein the processor is further configured to: use event tracking to identify changes to the medical data between snapshots; and include only the changed medical data from a previous snapshot as at least one of the first subset of the medical data or the second subset of the medical data (Tukol at [0284] teaches keeping track of any configuration changes made on a particular device (interpreted by Examiner as use event tracking to identify changes between snapshots). [0295] teaches when pushing updated configurations, only those settings that are part of the update may change without changing the overall state of the device (interpreted by Examiner as means to include only the changed medical data from a previous snapshot)).
It would have been prima facie obvious to one of ordinary skill in the art at the time of the invention was made to combine the noted features of Espina, Jarman and Chan with teaching of Tukol since known work in one field of endeavor may prompt variations in design in either the same field or a different field based on design incentives or other market forces if the variations would have been predictable to one of ordinary skill in the art. One of ordinary skill in the art of healthcare would have found it obvious to update the system and methods of the primary, secondary and third reference using the functions of the processor of the fourth reference to use event tracking to identify changes to the medical data between snapshots; and include only the changed medical data from a previous snapshot as at least one of the first subset of the medical data or the second subset of the medical data, in order to gain the commonly understood benefits of such adaptation, such as reducing the usage of high bandwidth and time. This update would be accomplished with no unpredictable results.
REGARDING CLAIM 18
Espina, Jarman and Chan disclose the limitation of claim 1.
Espina, Jarman and Chan do not explicitly disclose wherein the remote server includes one or more application programming interfaces (“API”) for receiving the second subset of the medical data for storage within at least one of a Structured Query Language (“SQL”) database, a NoSQL database, or an Amazon® Relational Database Service (“RDS”), however Tukol further discloses:
The digital communication apparatus of Claim 1, wherein the remote server includes one or more application programming interfaces (“API”) for receiving the second subset of the medical data for storage within at least one of a Structured Query Language (“SQL”) database, a NoSQL database, or an Amazon® Relational Database Service (“RDS”) (Tukol at [0092] teaches tags from the configuration file may be read and the appropriate application programming interfaces (APIs) may be used to apply most of the settings contained in the configuration file.).
It would have been prima facie obvious to one of ordinary skill in the art at the time of the invention was made to combine the noted features of Espina, Jarman and Chan with teaching of Tukol since known work in one field of endeavor may prompt variations in design in either the same field or a different field based on design incentives or other market forces if the variations would have been predictable to one of ordinary skill in the art. One of ordinary skill in the art of healthcare would have found it obvious to update the system and methods of the primary, secondary and third reference using the one or more application programming interfaces (“API”) of the fourth reference, in order to gain the commonly understood benefits of such adaptation, such as reducing the usage of high bandwidth and time. This update would be accomplished with no unpredictable results.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Espina (US 2010/0049005), in view of Jarman (US 2018/0032573), in view of Chan (US 2011/0219091) and in further view of Conway (US 2017/0220972).
REGARDING CLAIM 13
Espina, Jarman and Chan disclose the limitation of claim 1.
Espina, Jarman and Chan do not explicitly disclose wherein the wireless input port includes at least one of a Wi-Fi input port and a Bluetooth® input port and the wireless output port includes at least one of a Wi-Fi output port or a cellular output port, however Conway further discloses:
The digital communication apparatus of Claim 1, wherein the wireless input port includes at least one of a Wi-Fi input port and a Bluetooth® input port and the wireless output port includes at least one of a Wi-Fi output port or a cellular output port (Conway at [0245] teaches using WIFI adapter as an output port and an input port, such as a WIFI or Bluetooth adapter).
It would have been prima facie obvious to one of ordinary skill in the art at the time of the invention was made to combine the noted features of Espina, Jarman and Chan with teaching of Conway since known work in one field of endeavor may prompt variations in design in either the same field or a different field based on design incentives or other market forces if the variations would have been predictable to one of ordinary skill in the art. One of ordinary skill in the art of healthcare would have found it obvious to update the system and methods of the primary, secondary and third reference using the wireless input and output ports as found in the fourth reference, in order to gain the commonly understood benefits of such adaptation, such as improved software programs. This update would be accomplished with no unpredictable results.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Espina (US 2010/0049005), in view of Jarman (US 2018/0032573), in view of Chan (US 2011/0219091) and in further view of McCall (US 2003/0102836).
REGARDING CLAIM 16
Espina, Jarman and Chan disclose the limitation of claim 1.
Espina, Jarman and Chan do not explicitly disclose wherein the periodic intervals have a period between five seconds and sixty seconds, however McCall further discloses:
The digital communication apparatus of Claim 15, wherein the periodic intervals have a period between five seconds and sixty seconds (McCall at [0039] teaches a pre-determined time of typically between five to sixty second intervals).
It would have been prima facie obvious to one of ordinary skill in the art at the time of the invention was made to combine the noted features of Espina, Jarman and Chan with teaching of McCall since known work in one field of endeavor may prompt variations in design in either the same field or a different field based on design incentives or other market forces if the variations would have been predictable to one of ordinary skill in the art. One of ordinary skill in the art of healthcare would have found it obvious to update the system and methods of the primary, secondary and third reference using a messaging protocol that includes periodic intervals between five seconds and sixty seconds as found in the fourth reference, in order to gain the commonly understood benefits of such adaptation, such as increased reliability. This update would be accomplished with no unpredictable results.
Claims 19 is rejected under 35 U.S.C. 103 as being unpatentable over Espina (US 2010/0049005), in view of Jarman (US 2018/0032573), in view of Chan (US 2011/0219091) and in further view of Aftab (US 2019/0325353).
REGARDING CLAIM 19
Espina, Jarman and Chan disclose the limitation of claim 1.
Espina, Jarman and Chan do not explicitly disclose wherein the remote server is an analytics server that is configured to periodically analyze the second subset of the medical data for key performance indicators (“KPIs”) related to operation of the medical device, and wherein the KPIs include treatment trends, component usage trends, or alert/alarm trends, however Aftab further discloses:
The digital communication apparatus of Claim 1, wherein the remote server is an analytics server that is configured to periodically analyze the second subset of the medical data for key performance indicators (“KPIs”) related to operation of the medical device, and wherein the KPIs include treatment trends, component usage trends, or alert/alarm trends (Aftab at [0002] teaches big data applications and services may employ machine learning models that analyze large volumes of data to deliver various insights and key performance indicators [0015] teaches usage monitoring and [0042] teaches the network-based platform may store measures of performance metrics such as runtime, consistency of performance, usage, class of service (uptime, updates), accuracy, availability off-line, and reputation of developer (interpreted by Examiner as means to periodically analyze the second subset of the medical data for key performance indicators (“KPIs”) related to operation of the medical device and wherein the KPIs include treatment trends, component usage trends, or alert/alarm trends)).
It would have been prima facie obvious to one of ordinary skill in the art at the time of the invention was made to combine the noted features of Espina, Jarman and Chan with teaching of Aftab since known work in one field of endeavor may prompt variations in design in either the same field or a different field based on design incentives or other market forces if the variations would have been predictable to one of ordinary skill in the art. One of ordinary skill in the art of healthcare would have found it obvious to update the system and methods of the primary, secondary and third reference using the method for periodically analyzing the second subset of the medical data for key performance indicators (“KPIs”) related to operation of the medical device and wherein the KPIs include treatment trends, component usage trends, or alert/alarm trends as found in the fourth reference, in order to gain the commonly understood benefits of such adaptation, such as improved performance. This update would be accomplished with no unpredictable results.
Claims 20 is rejected under 35 U.S.C. 103 as being unpatentable over Espina (US 2010/0049005), in view of Jarman (US 2018/0032573), in view of Chan (US 2011/0219091) and in further view of Pindado (US 2016/0228640).
REGARDING CLAIM 20
Espina, Jarman and Chan disclose the limitation of claim 1.
Espina, Jarman and Chan do not explicitly disclose wherein the remote server is an analytics server that is configured to determine recommendations or guidelines to improve operation of the medical device, however Pindado further discloses:
The digital communication apparatus of Claim 1, wherein the remote server is an analytics server that is configured to determine recommendations or guidelines to improve operation of the medical device (Pindado at [0044] teaches the analytics system can be, for example, a big data server (e.g., based on Hadoop, or another analytics engine) that can receive, store and analyze the sensor data according to a predefined analytical method or process (interpreted by Examiner as wherein the remote server is an analytics server) and [0080] teaches improving operation and performance of prosthetic device (interpreted by Examiner as the medical device)).
It would have been prima facie obvious to one of ordinary skill in the art at the time of the invention was made to combine the noted features of Espina, Jarman and Chan with teaching of Pindado since known work in one field of endeavor may prompt variations in design in either the same field or a different field based on design incentives or other market forces if the variations would have been predictable to one of ordinary skill in the art (KSR rationale F). One of ordinary skill in the art of healthcare would have found it obvious to update the system and methods of the primary, secondary and third reference using wherein the remote server as found in the fourth reference that is an analytics server that is configured to determine recommendations or guidelines to improve operation of the medical device, in order to gain the commonly understood benefits of such adaptation, such as improved operation and performance. This update would be accomplished with no unpredictable results.
Response to Arguments
Rejection under 35 U.S.C. § 103
Regarding the rejection of claims 1-11 and 13-20, the Examiner has considered the Applicant’s arguments, but does not find them persuasive. Applicant argues:
Chan is silent about how the network bridge (102) determines which protocol formats are used for translation based on an output port or a destination for the data. At most, Chan discloses the network bridge (102) has a mapping table "that associates medical data in the standard format to the related variables, fields for the formats for transmission to network 230". (See Chan, par. [0048]). In other words, Chan's mapping table specifies how the data itself is translated between different formats. However, Chan does not specify how a certain protocol or data format is selected based on a destination or an output port through which the data is to be transmitted… For at least these reasons, Chan accordingly fails to disclose reading a configuration file to determine a first data format is specified for transmission of medical data to a medical network via a serial output port or an Ethernet output port and determine a second data format is specified for transmission of medical data to a remote server via an Ethernet output port or a wireless output port. Applicants accordingly respectfully submit that Chan in any combination with Perez and Jarman fails to disclose independent Claim 1 and dependent Claims 2, 4, 7 to 10, and 14.
Regarding 1, the Examiner respectfully disagrees. Combination of Espina, Jarman and Chan is relied upon to disclose the features of claim 1. Chan teaches reading a configuration file to determine the specified data format for transmission of medical data as Chan at [0047] teaches data server of network bridge can be adapted to format the received medical data in a specified format for transfer and network bridge can be reconfigured to format the medical data in a different format as may be needed and [0050] also teaches the network bridge can translate the received response into a specified format for transmission (interpreted by Examiner as means to determine first/second data format specified for transmission). Chan at [0048] teaches that a skilled artisan will also appreciate that the standard format can be any format desired. Moreover, Chan teaches converting and transmitting medical data in the second format (HTTP/JSON). Given the broadest reasonable interpretation, the cited references in combination teach the claimed features.
Conclusion
The prior art made of record though not relied upon in the present basis of rejection are noted in the attached PTO 892 and include:
Tran (US 2008/0004904) teaches systems and methods for providing interoperability among healthcare devices.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to LIZA TONY KANAAN whose telephone number is (571)272-4664. The Examiner can normally be reached on Mon-Thu 9:00am-6:00pm ET.
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, Robert Morgan can be reached on 571-272-6773. 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 the 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/docs 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.
/LIZA TONY KANAAN/Examiner, Art Unit 3683
Prosecution Insights