DETAILED CORRESPONDANCE
The present application is being examined under the pre-AIA first to invent provisions. This final office action on merits is in response to the communication received on 11/05/2025.
Status of claims
Claims 18-20 are cancelled. Claims 21-23 are new. Amendments to claims 1-17 are acknowledged and have been carefully considered. Claims 1-17 and 21-23 are pending and considered below. This application is a continuation of Application 16989627 filed on 08/10/2020, which is a continuation of Application 14128511 filed on 03/19/2014, which is a 371 of PCT/NZ2012/000106 filed on 06/26/2012, which claims the benefit of Provisional Application 61501641 filed on 06/27/2011.
Claim Rejections - 35 USC § 112
The § 112 (b) rejection of claim 1 is withdrawn because the Applicant’s amendments have clarified the previously identified ambiguities, and the claim now particularly points out and distinctly claims the subject matter regarded as the invention.
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-17 and 21-23 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1
Under step 1, the analysis is based on MPEP 2106.03, and claims 1-17 and 21-23 are drawn to a computer system. Thus, each claim, on its face, is directed to one of the statutory categories (i.e., useful process, machine, manufacture, or composition of matter) of 35 U.S.C. §101.
Step 2A Prong One
Claim 1 recites the limitations of identifying an appropriate recipient computer of a plurality of recipient computers for the data, each recipient computer comprising different data and encoding requirements; and encoding information into an appropriate recipient computer format. These limitations, as drafted, are processes that, under their broadest reasonable interpretation, cover performance of the limitations in the mind or by using a pen and paper. But for the “the routing engine” and “the output engine” language, the claim encompasses a user simply determining which recipient should receive the data and converting the data into a format appropriate for the recipient in their mind or by using a pen and paper. The mere nominal recitation of the routing engine and the output engine do not take the claim limitations out of the mental processes grouping. Thus, these claims recite a mental process which is an abstract idea.
Claim 21 recites the limitations of identifying an appropriate recipient computer of a plurality of recipient computers for the data, each recipient computer comprising different data and encoding requirements; and formatting the data based on routing rules into a format required by the recipient computer identified based on the routing rules and encodes the data for transmission to the recipient computer according to the requirements of the recipient computer. These limitations, as drafted, are processes that, under their broadest reasonable interpretation, cover performance of the limitations in the mind or by using a pen and paper. But for the “the routing engine” and “the output engine” language, the claim encompasses a user simply determining which recipient should receive data and converting the data into a format required by the computer in their mind or by using a pen and paper. The mere nominal recitation of the routing engine and the output engine do not take the claim limitations out of the mental processes grouping. Thus, these claims recite a mental process which is an abstract idea.
Under Step 2A Prong Two
The claimed limitations, as per claim 1, include:
a processor which receives data from a plurality of breathing apparatus devices, each breathing apparatus device of the plurality of breathing apparatus devices including a controller, a user interface, a blower, and one or more sensors communicative with the controller, wherein the one or more sensors include a flow sensor;
wherein the breathing apparatus devices are configured to generate therapy data, the therapy data being one or more of: usage data, compliance data, efficacy data, patient data, or other data from the breathing apparatus, each of the plurality of the breathing apparatus devices are further comprising or being associated with a transmission interface, wherein each of the plurality of the breathing apparatus devices configured to automatically, upon periodic occurrence of a trigger, transmit data using the transmission interface:
wherein the processor further comprises a data integration engine, a routing engine, and an output engine;
the data integration engine formats data received from the plurality of breathing apparatus devices;
the routing engine identifies an appropriate recipient computer of a plurality of recipient computers for the data, each recipient computer comprising different data and encoding requirements;
the output engine encodes information into an appropriate recipient computer format;
the processor further configured to transmit the encoded data to an appropriate recipient computer;
wherein receiving and/or transmitting of the data is via a WAN network, the breathing apparatus devices being directly or indirectly in communication with the WAN network via a wired or wireless connection.
The claimed limitations, as per claim 21, include:
a processor which receives data from a plurality of breathing apparatus devices, each breathing apparatus device of the plurality of breathing apparatus devices including a controller, a user interface, a blower, and one or more sensors communicative with the controller, wherein the one or more sensors include a flow sensor;
wherein the breathing apparatus devices are configured to generate therapy data, the therapy data being one or more of: usage data, compliance data, efficacy data, patient data, or other data from the breathing apparatus, each of the plurality of the breathing apparatus devices further comprising or being associated with a transmission interface, wherein each of the plurality of the breathing apparatus devices are configured to automatically, upon periodic occurrence of a trigger, transmit data using the transmission interface:
wherein the processor further comprises a data integration engine, a routing engine, and an output engine;
the data integration engine formats data received from the plurality of breathing apparatus devices;
the routing engine identifies an appropriate recipient computer of a plurality of recipient computers for the data, each recipient computer comprising different data and encoding requirements,
wherein the routing engine:
receives a user identification or a device identification associated with the breathing apparatus device from which data was received;
retrieves stored routing rules based on the user identification or the device identification;
the output engine formats the data into a format required by the recipient computer identified based on the routing rules and encodes the data for transmission to the recipient computer according to the requirements of the recipient computer;
the processor further configured to transmit the encoded data to an appropriate recipient computer;
wherein receiving and/or transmitting of the data is via a WAN network, the breathing apparatus devices being directly or indirectly in communication with the WAN network via a wired or wireless connection.
Examiner Note: underlined elements indicate additional elements of the claimed invention identified as performing the steps of the claimed invention.
The judicial exception expressed in claims 1 and 21 are not integrated into a practical application. The claims as a whole merely describes how to generally “apply” the concept of identifying an appropriate recipient for data and formatting and routing the data to that recipient based on recipient specific requirements in a computer environment. The claimed computer components (i.e., a processor; wherein the processor further comprises a data integration engine, a routing engine, and an output engine; and the data integration engine formats data received from the plurality of breathing apparatus devices) are recited at a high level of generality and are merely invoked as tools to perform an existing process of identifying an appropriate recipient for data and formatting and routing the data to that recipient. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Accordingly, alone and in combination, these additional elements do not integrate the abstract idea into a practical application.
The judicial exception expressed in claims 1 and 21 are not integrated into a practical application. The abstract idea is merely carried out in a technical environment or field (i.e., breathing therapy devices and networked computer systems), however fails to contain meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment (see MPEP 2106.05(h)). The additional elements that are carried out in a technical environment includes receiving data from a plurality of breathing apparatus devices, each breathing apparatus device of the plurality of breathing apparatus devices including a controller, a user interface, a blower, and one or more sensors communicative with the controller, wherein the one or more sensors include a flow sensor; and wherein receiving and/or transmitting of the data is via a WAN network, the breathing apparatus devices being directly or indirectly in communication with the WAN network via a wired or wireless connection. Accordingly, alone and in combination, these additional elements do not integrate the abstract idea into a practical application.
The judicial exception expressed in claims 1 and 21 are not integrated into a practical application. The claims recite the additional elements of wherein the breathing apparatus devices are configured to generate therapy data, the therapy data being one or more of: usage data, compliance data, efficacy data, patient data, or other data from the breathing apparatus (claims 1 and 21); each of the plurality of the breathing apparatus devices are further comprising or being associated with a transmission interface, wherein each of the plurality of the breathing apparatus devices configured to automatically, upon periodic occurrence of a trigger, transmit data using the transmission interface (claims 1 and 21); further configured to transmit the encoded data to an appropriate recipient computer (claims 1 and 21); receives a user identification or a device identification associated with the breathing apparatus device from which data was received (claim 21); and retrieves stored routing rules based on the user identification or the device identification (claim 21). These limitations are recited at a high level of generality (i.e., as a general means of gathering therapy data and transmitting the data to a recipient system), and amounts to merely data gathering and insignificant application, which is a form of insignificant extra-solution activity. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application. The claims are directed to an abstract idea.
Therefore, under step 2A, the claims are directed to the abstract idea, and require further analysis under Step 2B.
Under step 2B
Claim 1 and 21 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed with respect to Step 2A, the claim as a whole merely describes how to generally “apply” the concept of identifying an appropriate recipient for data and formatting and routing the data to that recipient based on recipient specific requirements in a computer environment. Thus, even when viewed as a whole, nothing in the claims add significantly more (i.e., an inventive concept) to the abstract idea.
Claims 1 and 21 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed with respect to Step 2A, the abstract idea is merely carried out in a technical environment or field, however fails to contain meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment. Thus, even when viewed as a whole, nothing in the claims add significantly more (i.e., an inventive concept) to the abstract idea.
For claim 1 and claim 21, under step 2B, the additional elements of wherein the breathing apparatus devices are configured to generate therapy data, the therapy data being one or more of: usage data, compliance data, efficacy data, patient data, or other data from the breathing apparatus (claims 1 and 21); each of the plurality of the breathing apparatus devices are further comprising or being associated with a transmission interface, wherein each of the plurality of the breathing apparatus devices configured to automatically, upon periodic occurrence of a trigger, transmit data using the transmission interface (claims 1 and 21); further configured to transmit the encoded data to an appropriate recipient computer (claims 1 and 21); receives a user identification or a device identification associated with the breathing apparatus device from which data was received (claim 21); and retrieves stored routing rules based on the user identification or the device identification (claim 21) have been evaluated. The system performs a general function of receiving patient data for subsequent processing, which represents a well-understood, routine, and conventional activity in the field of monitoring systems for breathing therapy devices. The specification discloses that the system is used in its ordinary capacity as a data input device and does not describe any improvement to the system itself or to the functioning of the overall computer system (see [0078]). Also noted in Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016), merely collecting information for analysis without a technological improvement does not add significantly more to an abstract idea. The use of the system is no more than collecting information before analyzing, formatting, and routing the information and does not integrate the abstract idea into a practical application. Additionally, as noted in In re Brown, 645 Fed. App'x 1014, 1016-1017 (Fed. Cir. 2016), merely transmitting information represents an insignificant application of the underlying mental process, as the transmission simply moves data from one location to another and does not impose any meaningful limitation or add any technological improvement. Therefore, the claims do not recite an inventive concept and is not patent eligible.
Claims 3, 5, 13, 15-17, and 23 recite no further additional elements, and only further narrow the abstract idea. The previously identified additional elements, individually and as a combination, do not integrate the narrowed abstract idea into a practical application for reasons similar to those explained above, and do not amount to significantly more than the narrowed abstract idea for reasons similar to those explained above.
Claims 2, 4, 6-12, 14, and 22 recite the additional element of a user interface (claim 2), one or more sensors (claim 4), a pressure sensor, a humidity sensor, a mass flow sensor, or a temperature sensor (claim 4), an intermediate computer (claim 6), a remote computer (claim 7), the removal memory device (claim 8), the PC (claim 8, 9, 10), analog or digital telephone modem (claim 11), a mobile, landline, or VOIP telephone (claim 11), a speaker (claim 11), the user computer (claim 12 and 14), the transmission interface (claim 14), and a recipient computer (claim 22). However, this additional element amounts to implementing an abstract idea on a generic computing device (claims 2, 6-12, 14, and 22) or mere linking to a particular environment (claims 4 and 11). As such, this additional element, when considered individually or in combination with the prior devices, does not integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
Thus, as the dependent claims remain directed to a judicial exception, and as the additional elements of the claims do not amount to significantly more, the dependent claims are not patent eligible.
Therefore, the claims here fail to contain any additional element(s) or combination of additional elements that can be considered as significantly more and the claim is rejected under 35 U.S.C. 101 for lacking eligible subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-17 and 21-23 are rejected under 35 U.S.C. 103 as being unpatentable over by Martin et al. (U.S. Patent Publication US 2010/0132708 A1), referred to hereinafter as Martin, in view of Larondo et al. (JP Publication No. JP 2011502369 A), referred to hereinafter as Larondo.
Regarding claim 1, Martin teaches breathing data from a plurality of remote breathing apparatus devices (Martin [0002] “The present invention relates to positive airway pressure devices for respiratory therapy for treating, for example, Sleep Disordered Breathing (SDB). The present invention also relates to components for positive pressure airway devices.”);
a plurality of breathing apparatus devices, each breathing apparatus device of the plurality of breathing apparatus devices including a controller, a user interface, a blower, and one or more sensors communicative with the controller, wherein the one or more sensors include a flow sensor (Martin [0002] “The present invention relates to positive airway pressure devices for respiratory therapy for treating, for example, Sleep Disordered Breathing (SDB). The present invention also relates to components for positive pressure airway devices.”, and Martin [0077] “Referring again to FIG. 9, a controller 130 may be provided to control the supply of power to and operation of the blower assembly 98. The controller 130 may be, for example, a printed circuit board comprising a control circuit that receives signals from the flow sensor 134 and controls the blower assembly 98 and heater plate 102 to provide a humidified air flow 164 at predetermined humidity and/or temperature.”); and
wherein the breathing apparatus devices are configured to generate therapy data, the therapy data being one or more of: usage data, compliance data, efficacy data, patient data, or other data from the breathing apparatus, each of the plurality of the breathing apparatus devices are further comprising (Martin [0002] “The present invention relates to positive airway pressure devices for respiratory therapy for treating, for example, Sleep Disordered Breathing (SDB). The present invention also relates to components for positive pressure airway devices.”, Martin [0040] “The term "air" will be taken to include breathable gases, for example air with supplemental oxygen.”, Martin [0077] “Referring again to FIG. 9, a controller 130 may be provided to control the supply of power to and operation of the blower assembly 98. The controller 130 may be, for example, a printed circuit board comprising a control circuit that receives signals from the flow sensor 134 and controls the blower assembly 98 and heater plate 102 to provide a humidified air flow 164 at predetermined humidity and/or temperature. Such a control circuit is disclosed in U.S. Patent Application Publication 2009/0223514 A1, the entire contents of which is incorporated herein by reference.”, Martin [0057] “As shown in FIG. 5, a tube, or hose, 80 may be connected to the outlet 26, for example by a connector 84, to deliver the air flow to a patient interface 82, for example a mask.”).
Martin fails to explicitly teach a computer system which receives data and determines an appropriate target recipient system of a plurality of target recipient systems, the target recipient systems having different formatting requirements, formats and routes breathing apparatus usage data to the appropriate target recipient system of the plurality of target recipient systems, the computer system comprising;
a processor which receives data and a user interface;
to generate therapy data, patient data, a transmission interface, and to automatically, upon periodic occurrence of a trigger, transmit data using the transmission interface;
wherein the processor further comprises a data integration engine, a routing engine, and an output engine;
the data integration engine formats data received;
the routing engine identifies an appropriate recipient computer of a plurality of recipient computers for the data, each recipient computer comprising different data and encoding requirements;
the output engine encodes information into an appropriate recipient computer format;
the processor further configured to transmit the encoded data to an appropriate recipient computer; and
wherein receiving and/or transmitting of the data is via a WAN network, the breathing apparatus devices being directly or indirectly in communication with the WAN network via a wired or wireless connection.
Larondo teaches a computer system which receives data and determines an appropriate target recipient system of a plurality of target recipient systems, the target recipient systems having different formatting requirements, formats and routes breathing apparatus usage data to the appropriate target recipient system of the plurality of target recipient systems, the computer system comprising (Larondo, page 6-7, “Each patient medical device 13 can generate one or more types of patient data, and can incorporate one or more components for the delivery of therapy, sensing physiological data, and measuring environmental parameters. Typical medical devices include, for example, patient implantable medical devices (PIMD) such as pacemakers, implantable defibrillators, drug pumps, and nerve stimulation devices. For example, an extracorporeal medical device such as an automatic external defibrillator (AED) may also be paired with a patient portable communicator. Medical devices can include implantable or external sensors. Examples of the implantable sensor include a heart or respiratory monitor, an implantable diagnostic multi-sensor non-therapeutic device, and the like. External sensors include Holter monitors, scales, sphygmomanometer cuffs, temperature sensors (eg digital thermometers and skin temperature sensors), ECG and / or heart rate sensors, respiratory masks such as CPAP masks with oxygen and carbon dioxide concentrations There may also be mentioned gas sensors”, Larondo, page 7, “Patient communicator 14 communicates with cellular-based components. For example, the PPC 14 can communicate with the base station 24 via a wireless interface.” And Larondo, page 9, “For example, a particular block of medical device data of interest may be selectively transferred from the medical device 13 to the patient mobile communicator 14 in response to a command signal generated by the remote server, the patient mobile communicator 14, or the medical device 13. Good. The generation of these command signals may be derived from programmed instructions residing in the PPC 14 or medical device memory that are triggered to be executed by the PPC 14, medical device, or remote server. The programmed instructions may be changed, typically by a physician via a remote server, or by an interface to the PPC 14 or medical device. For example, a physician may wish to receive data related to an arrhythmia (eg, atrial or ventricular tachyarrhythmia) whenever such an event occurs. This selected portion of the data is tagged for transfer to the PPC 14 according to the physician's request. Depending on the severity of the event type, the physician may require that event data be automatically transferred to the remote server via the PPC 14 as soon as the event occurs, or more severe For infrequent events, the PPC 14 may request that data be transferred the next time it connects to the remote server.”, Larondo, page 4, “As shown in the embodiment of FIG. 1A, life critical network 200 employs central authority 16 to manage access to the network infrastructure. This includes cryptographically verifying and authenticating content from potential nodes and allowing other control over network-based monitoring aspects before allowing access. The life critical network 200 preferably supports the concept of classifying nodes on the network 200 into a specific hierarchy of access entitlements. Various components seeking access to the life critical network 200 are given different access rights based on their classification. For example, if the sensor devices 17A to 17B with low urgency are classified into a hierarchy with low urgency or priority, access to a high-speed connection may not be given. The patient implantable medical device programmer system 23 may be given preferential access to high speed connectivity functions due to the more stringent requirements for timely interconnection to the infrastructure. This classification and priority determination is preferably managed dynamically via the central authority 16.” Larondo, page 26, “FIG. 3D illustrates an embodiment of a source medical device that communicates with each target component via a life-critical network that supports dynamic communication link mapping methods, according to an embodiment of the present invention. The portable source device 14 is shown communicatively connected to a network 200 that includes a number of nodes N and a target node.sub.NT corresponding to a target component 16 such as, for example, a central authority or patient management server system. Portable source device 14 is preferably connected to mapping agent 235and profile library 237 and also incorporates mapping agent 235 and profile library 237. The mapping agent 235 preferably employs a processor configured to execute program instructions for discovering available communication links in the network 200 and obtain connection information such as connection options and connection attributes from the discovery operation.”, and Larondo, page 67 “The hub 1000 can also incorporate speech synthesis circuitry or speech file playback circuitry that converts speech / acoustic files into human language. Voice messages can be unidirectional or bidirectional, such as between the hub 1000 and the automated patient management server 850. For example, a message forwarded to the hub 1000 via the automated patient management system 850from a physician, clinician, or technician (eg, an employee of an automated patient management service) is transmitted in human language by the acoustic and electrical circuit / component of the hub1000. It may be reproduced in the form. The sound file may be converted into, for example, WAV orMP3 format. The hub 1000 may also allow a patient or caregiver to record a message and send this message to the recipient via the automated patient management server 850. A “live” audio session between the patient / caregiver and the physician, clinician, or technician is performed using a wired connection established using the hub 1000, a wireless connection, or a connection to the voice over internet.”):;
a processor which receives data and a user interface (Larondo, page 26, “FIG. 3D illustrates an embodiment of a source medical device that communicates with each target component via a life-critical network that supports dynamic communication link mapping methods, according to an embodiment of the present invention. The portable source device 14 is shown communicatively connected to a network 200 that includes a number of nodes N and a target node.sub.NT corresponding to a target component 16 such as, for example, a central authority or patient management server system. Portable source device 14 is preferably connected to mapping agent 235and profile library 237 and also incorporates mapping agent 235 and profile library 237. The mapping agent 235 preferably employs a processor configured to execute program instructions for discovering available communication links in the network 200 and obtain connection information such as connection options and connection attributes from the discovery operation.”, Larondo, page 29, “Although the PPC 800 can also incorporate a display that includes some or all of the indicators provided on the dashboard 842, various embodiments of the PPC 800 can be implemented with a reduced feature set, for example. A limited user interface may also be provided, such as in the case of a patient mobile communicator 800.”);
to generate therapy data, patient data, a transmission interface, and to automatically, upon periodic occurrence of a trigger, transmit data using the transmission interface (Larondo, page 6-7, “Each patient medical device 13 can generate one or more types of patient data, and can incorporate one or more components for the delivery of therapy, sensing physiological data, and measuring environmental parameters. Typical medical devices include, for example, patient implantable medical devices (PIMD) such as pacemakers, implantable defibrillators, drug pumps, and nerve stimulation devices. For example, an extracorporeal medical device such as an automatic external defibrillator (AED) may also be paired with a patient portable communicator. Medical devices can include implantable or external sensors. Examples of the implantable sensor include a heart or respiratory monitor, an implantable diagnostic multi-sensor non-therapeutic device, and the like. External sensors include Holter monitors, scales, sphygmomanometer cuffs, temperature sensors (eg digital thermometers and skin temperature sensors), ECG and / or heart rate sensors, respiratory masks such as CPAP masks with oxygen and carbon dioxide concentrations There may also be mentioned gas sensors”, Larondo, page 7, “Patient communicator 14 communicates with cellular-based components. For example, the PPC 14 can communicate with the base station 24 via a wireless interface.” And Larondo, page 9, “For example, a particular block of medical device data of interest may be selectively transferred from the medical device 13 to the patient mobile communicator 14 in response to a command signal generated by the remote server, the patient mobile communicator 14, or the medical device 13. Good. The generation of these command signals may be derived from programmed instructions residing in the PPC 14 or medical device memory that are triggered to be executed by the PPC 14, medical device, or remote server. The programmed instructions may be changed, typically by a physician via a remote server, or by an interface to the PPC 14 or medical device. For example, a physician may wish to receive data related to an arrhythmia (eg, atrial or ventricular tachyarrhythmia) whenever such an event occurs. This selected portion of the data is tagged for transfer to the PPC 14 according to the physician's request. Depending on the severity of the event type, the physician may require that event data be automatically transferred to the remote server via the PPC 14 as soon as the event occurs, or more severe For infrequent events, the PPC 14 may request that data be transferred the next time it connects to the remote server.”);
wherein the processor further comprises a data integration engine, a routing engine, and an output engine (Larondo, page 26, “FIG. 3D illustrates an embodiment of a source medical device that communicates with each target component via a life-critical network that supports dynamic communication link mapping methods, according to an embodiment of the present invention. The portable source device 14 is shown communicatively connected to a network 200 that includes a number of nodes N and a target node.sub.NT corresponding to a target component 16 such as, for example, a central authority or patient management server system. Portable source device 14 is preferably connected to mapping agent 235and profile library 237 and also incorporates mapping agent 235 and profile library 237. The mapping agent 235 preferably employs a processor configured to execute program instructions for discovering available communication links in the network 200 and obtain connection information such as connection options and connection attributes from the discovery operation.”, Larondo, page 49, “First, the caregiver conducts a remote program session through the data input mechanism (operation731). The programming instructions and parameters selected by the caregiver are converted by the managed server into a patient implantable medical device type command that is checked for accuracy and digitally signed (operation 732). Also, the patient-implanted medical device formalized command is inversely converted and provided in a format that can be displayed to the caregiver for approval or rejection (operation 733). If the converted programming is rejected by the caregiver, control returns to the caregiver's program session (operation 731). Otherwise, the patient-implanted medical device formatted command is marked for delivery to the server and, after receipt by the server, authentication and integrity are verified (operation 734)”, Larondo, page 4, “As shown in the embodiment of FIG. 1A, life critical network 200 employs central authority 16 to manage access to the network infrastructure. This includes cryptographically verifying and authenticating content from potential nodes and allowing other control over network-based monitoring aspects before allowing access. The life critical network 200 preferably supports the concept of classifying nodes on the network 200 into a specific hierarchy of access entitlements. Various components seeking access to the life critical network 200 are given different access rights based on their classification. For example, if the sensor devices 17A to 17B with low urgency are classified into a hierarchy with low urgency or priority, access to a high-speed connection may not be given. The patient implantable medical device programmer system 23 may be given preferential access to high speed connectivity functions due to the more stringent requirements for timely interconnection to the infrastructure. This classification and priority determination is preferably managed dynamically via the central authority 16.”);
the data integration engine formats data received (arondo, page 6-7 “Each PPC 14 is preferably uniquely assigned to a particular patient 12A through a process according to various embodiments generally referred to herein as “pairing”. As used herein, pairing generally refers to the inherent association that occurs between a patient's PPC 14 and the medical device (s) 13 associated with that patient. When information is transmitted between the medical device 13 and the automatic patient management server 16A, the patient portable communicator 14 paired with the individual medical device (s) 13 can receive information through one or more networks.” and Larondo, page 49, “First, the caregiver conducts a remote program session through the data input mechanism (operation731). The programming instructions and parameters selected by the caregiver are converted by the managed server into a patient implantable medical device type command that is checked for accuracy and digitally signed (operation 732). Also, the patient-implanted medical device formalized command is inversely converted and provided in a format that can be displayed to the caregiver for approval or rejection (operation 733). If the converted programming is rejected by the caregiver, control returns to the caregiver's program session (operation 731). Otherwise, the patient-implanted medical device formatted command is marked for delivery to the server and, after receipt by the server, authentication and integrity are verified (operation 734)”.);
the routing engine identifies an appropriate recipient computer of a plurality of recipient computers for the data, each recipient computer comprising different data and encoding requirements (Larondo, page 4, “As shown in the embodiment of FIG. 1A, life critical network 200 employs central authority 16 to manage access to the network infrastructure. This includes cryptographically verifying and authenticating content from potential nodes and allowing other control over network-based monitoring aspects before allowing access. The life critical network 200 preferably supports the concept of classifying nodes on the network 200 into a specific hierarchy of access entitlements. Various components seeking access to the life critical network 200 are given different access rights based on their classification. For example, if the sensor devices 17A to 17B with low urgency are classified into a hierarchy with low urgency or priority, access to a high-speed connection may not be given. The patient implantable medical device programmer system 23 may be given preferential access to high speed connectivity functions due to the more stringent requirements for timely interconnection to the infrastructure. This classification and priority determination is preferably managed dynamically via the central authority 16.”);
the output engine encodes information into an appropriate recipient computer format (Larondo, page 67 “The hub 1000 can also incorporate speech synthesis circuitry or speech file playback circuitry that converts speech / acoustic files into human language. Voice messages can be unidirectional or bidirectional, such as between the hub 1000 and the automated patient management server 850. For example, a message forwarded to the hub 1000 via the automated patient management system 850from a physician, clinician, or technician (eg, an employee of an automated patient management service) is transmitted in human language by the acoustic and electrical circuit / component of the hub1000. It may be reproduced in the form. The sound file may be converted into, for example, WAV orMP3 format. The hub 1000 may also allow a patient or caregiver to record a message and send this message to the recipient via the automated patient management server 850. A “live” audio session between the patient / caregiver and the physician, clinician, or technician is performed using a wired connection established using the hub 1000, a wireless connection, or a connection to the voice over internet.”);
the processor further configured to transmit the encoded data to an appropriate recipient computer(Larondo, page 26, “FIG. 3D illustrates an embodiment of a source medical device that communicates with each target component via a life-critical network that supports dynamic communication link mapping methods, according to an embodiment of the present invention. The portable source device 14 is shown communicatively connected to a network 200 that includes a number of nodes N and a target node.sub.NT corresponding to a target component 16 such as, for example, a central authority or patient management server system. Portable source device 14 is preferably connected to mapping agent 235and profile library 237 and also incorporates mapping agent 235 and profile library 237. The mapping agent 235 preferably employs a processor configured to execute program instructions for discovering available communication links in the network 200 and obtain connection information such as connection options and connection attributes from the discovery operation.”, and Larondo, page 67 “The hub 1000 can also incorporate speech synthesis circuitry or speech file playback circuitry that converts speech / acoustic files into human language. Voice messages can be unidirectional or bidirectional, such as between the hub 1000 and the automated patient management server 850. For example, a message forwarded to the hub 1000 via the automated patient management system 850from a physician, clinician, or technician (eg, an employee of an automated patient management service) is transmitted in human language by the acoustic and electrical circuit / component of the hub1000. It may be reproduced in the form. The sound file may be converted into, for example, WAV orMP3 format. The hub 1000 may also allow a patient or caregiver to record a message and send this message to the recipient via the automated patient management server 850. A “live” audio session between the patient / caregiver and the physician, clinician, or technician is performed using a wired connection established using the hub 1000, a wireless connection, or a connection to the voice over internet.”);
wherein receiving and/or transmitting of the data is via a WAN network, the breathing apparatus devices being directly or indirectly in communication with the WAN network via a wired or wireless connection (Larondo, page 12, “The life critical network 200 basically corresponds to a private network supported by a public network infrastructure. The life critical network 200 is configured to operate on the conventional mobile network 20 and data network 22.” and LARONDO, page 4, “The process of mapping the environment at the source end of the network 200 begins with a source agent making a series of queries and / or connection attempts through various methods of building temporal and spatial profiles. In various embodiments, the device that performs the mapping can also employ many forms of both wired and wireless communications. Communication mechanisms include but are not limited to RF radio transceivers (such as WiFiMax, IEEE 802.11a / b / g / n); cellular network transceivers (such as GSM, EDGE, GPRS, CDMA); Bluetooth (high power or low power) Method); Zigbee (IEEE 802.15.4); Wired Ethernet (IEEE 802.3); Legacy Telephone System (POTS) / Public Switched Telephone Network (PSTN); Emergency System (eg, 911, Radio Priority) Service); TDD, SMS, MMS, EMS, and VOIP may be included.”).
It would have been obvious to a person having ordinary skill in the art (PHOSITA), at the time of the invention, to combine the breathing apparatus system of Martin with the medical device data transmission, routing, and formatting system of Larondo to arrive at the claimed computer system of claim 1. Martin teaches positive airway pressure (PAP) breathing apparatus devices including a controller, blower, and flow sensor that generate therapy-related operational data during respiratory treatment. Larondo teaches medical devices that generate patient and therapy data and automatically transmit such data, upon triggering events, via wired or wireless communication interfaces to remote systems over a WAN. Larondo further teaches centralized processing entities that manage communication links, classify destination components, and control delivery of medical data to appropriate target systems. A PHOSITA would have been motivated to incorporate Larondo’s known automated data transmission and network management techniques into Martin’s breathing therapy system in order to enable remote monitoring, compliance tracking, and efficient delivery of therapy data to external systems, which were well recognized needs in the field of respiratory therapy and healthcare monitoring.
Additionally, Larondo teaches formatting, conversion, and adaptation of medical data for delivery to different target components within a network, including converting data into formats suitable for different recipients and managing delivery based on recipient classification and network requirements. Once Larondo’s system routes medical data to a plurality of recipient systems with different roles and access entitlements, it would have been predictable that such recipient systems impose different data and encoding requirements. Accordingly, a PHOSITA would have been motivated to format and encode breathing apparatus usage data for the appropriate target recipient system prior to transmission, as recited in claim 1, using known and routine data handling techniques. The combination of Martin and Larondo applies known medical device networking, routing, and formatting mechanisms to a known breathing apparatus system to achieve predictable results.
Regarding claim 2, Martin and Larondo teach the invention in claim 1, as discussed above, and further teach wherein the user interface comprises one or more of: a knob, a plurality of buttons, or a screen (Martin [0046] “Referring again to FIG. 1A, the flow generator housing 14 of the PAP device 10 may comprise controls 20 and a display 22, for example an LCD. The controls 20 may comprise buttons, although it should be appreciated that other controls, such as knobs or dials, may be provided.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to configure the breathing apparatus system to include a user interface comprising one or more of a knob, buttons, or a screen, as taught by Martin, because such interface components were well known, interchangeable options for controlling and displaying information in PAP devices, and their inclusion would have yielded predictable results.
Regarding claim 3, Martin and Larondo teach the invention in claim 1, as discussed above, and further teach wherein the breathing apparatus further comprises a source of pressurized gas, the breathing apparatus configured to regulate a flow of the pressurized gas (Martin [0050] “The inlet air flow 38 is pressurized by the blower motor assembly 32. The amount of pressurization is dependent on, for example, the rotation speed of the impeller(s) of the blower motor assembly 32. The pressurized air flow 58 exits the blower motor assembly 32 into an airway connector 44 provided in the flow generator housing 14 and is then directed by the airway connector 44 into a channel inlet 46. As shown in FIG. 1B, the channel inlet 46 directs the flow into a spiral channel 49 defined by a channel wall 52 provided in the flow generator housing 14. The channel 49 forms the flow into a spiral air flow that is directed to a channel outlet 50 that is provided in fluid communication with the outlet 62 provided on the humidifier 16.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to include a source of pressurized gas and to regulate the flow of the pressurized gas in the breathing apparatus, as taught by Martin, because pressurization and controlled gas flow are fundamental and conventional aspects of PAP respiratory therapy devices.
Regarding claim 4, Martin and Larondo teach the invention in claim 1, as discussed above, and further teach wherein the one or more sensors further comprise one or more of: a pressure sensor, a humidity sensor, a mass flow sensor, or a temperature sensor (Martin [0077] “Referring again to FIG. 9, a controller 130 may be provided to control the supply of power to and operation of the blower assembly 98. The controller 130 may be, for example, a printed circuit board comprising a control circuit that receives signals from the flow sensor 134 and controls the blower assembly 98 and heater plate 102 to provide a humidified air flow 164 at predetermined humidity and/or temperature. Such a control circuit is disclosed in U.S. Patent Application Publication 2009/0223514 A1, the entire contents of which is incorporated herein by reference.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to include additional sensors such as pressure, humidity, mass flow, or temperature sensors in the breathing apparatus, as taught by Martin, because such sensors were routinely used to monitor therapy conditions and device operation in PAP systems and would have predictably improved monitoring and control.
Regarding claim 5, Martin and Larondo teach the invention in claim 1, as discussed above, and further teach wherein transmission of the data is via one or more of: WIFI transmission; Bluetooth transmission; Ethernet transmission; mobile/landline telephone transmission; or transfer via a removable memory device using a PC (Larondo, page 7, “Patient communicator 14 communicates with cellular-based components. For example, the PPC 14 can communicate with the base station 24 via a wireless interface.” and LARONDO, page 4, “In various embodiments, the device that performs the mapping can also employ many forms of both wired and wireless communications. Communication mechanisms include but are not limited to RF radio transceivers (such as WiFiMax, IEEE 802.11a / b / g / n); cellular network transceivers (such as GSM, EDGE, GPRS, CDMA); Bluetooth (high power or low power) Method); Zigbee (IEEE 802.15.4); Wired Ethernet (IEEE 802.3); Legacy Telephone System (POTS) / Public Switched Telephone Network (PSTN); Emergency System (eg, 911, Radio Priority) Service); TDD, SMS, MMS, EMS, and VOIP may be included”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to transmit data from the breathing apparatus using one or more of Wi-Fi, Bluetooth, Ethernet, telephone transmission, or removable memory devices, as taught by Larondo, because these were known and commonly used communication mechanisms for medical device data transfer, and selecting among them would have been a routine choice based on implementation needs.
Regarding claim 6, Martin and Larondo teach the invention in claim 5, as discussed above, and further teach wherein the breathing apparatus devices are in communication with the computer system via an intermediate computer (Martin [0002] “The present invention relates to positive airway pressure devices for respiratory therapy for treating, for example, Sleep Disordered Breathing (SDB). The present invention also relates to components for positive pressure airway devices.” and Larondo, page 9, “ For example, a particular block of medical device data of interest may be selectively transferred from the medical device 13 to the patient mobile communicator 14 in response to a command signal generated by the remote server, the patient mobile communicator 14, or the medical device 13. Good. The generation of these command signals may be derived from programmed instructions residing in the PPC 14 or medical device memory that are triggered to be executed by the PPC 14, medical device, or remote server. The programmed instructions may be changed, typically by a physician via a remote server, or by an interface to the PPC 14 or medical device.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to communicate between the breathing apparatus devices and the computer system via an intermediate computer, as taught by Martin and Larondo, because intermediary computing devices (patient communicators or PCs) were conventionally used to collect, relay, and manage medical device data prior to transmission to remote systems, yielding predictable results.
Regarding claim 7, Martin and Larondo teach the invention in claim 6, as discussed above, and further teach wherein the intermediate computer is a remote computer (Larondo, page 47, “The physician remotely accesses the patient implantable medical device via the patient portable communicator to determine if the conditions are appropriate for performing the capture threshold test (step S705). If appropriate, the physician sends an SMS message command to the PPC to initiate a capture threshold test (step S710). The PPC receives the SMS message command (step S715) and relays the command to the patient implantable medical device. The patient implantable medical device starts a capture threshold test (step S720). During the threshold test, the patient implantable medical device-patient mobile communicator pair streams the real-time electrogram waveform to the automatic patient management server (step S725), and the doctor observes the electrogram waveform from a remote site.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to implement the intermediate computer as a remote computer, as taught by Larondo, because remote access to medical device data via intermediary communicators and servers was well known and routinely used to enable offsite monitoring, control, and data review with predictable results.
Regarding claim 8, Martin and Larondo teach the invention in claim 5, as discussed above, and further teach wherein the transmission is via the removable memory device using the PC, wherein an upload applet is downloaded to the PC, the upload applet configured to automatically transmit the data (Larondo, page 54-55, “Expansion of the ability to interface between the PPC 800 and external device (s) can be done with or without the involvement of the automatic patient management server 850. For example, a local interface connection device (e.g., a laptop) can communicate with and obtain data from the patient implantable medical device 802 wirelessly or via a hard wire connection (e.g., USB or FireWire). The local device can display various types of data obtained from the patient implantable medical device 802, such as ECG waveforms, sensor data, event counters, histograms, and other information of interest. In general, browsing-only access to the patient implantable medical device is preferably granted to the local device, as shown in FIG. A suitable local device, such as a laptop, can be configured to emulate a patient implantable medical device programmer, and an authorized clinician can use such a local device to Note that 800 can be called or programmed locally. Data related to local patient implantable medical device programming and / or calls may be uploaded to the automated patient management server 850 via a wireless or hardwire connection.” and Larondo, page 27, “A physician or other authorized person can also interact with the automated patient management server to access various information regarding the specific patient, the patient's medical device, and / or the patient portable communicator. FIGS. 9A and 9B illustrate a user access device, such as a laptop or patient portable communicator 835, that provides authorized access to the automatic patient management server 850 via a network 830 (eg, a life critical network), for example. The laptop 835 may be in a doctor's office, home, or other location (eg, a resort hotel room). Dashboard diagnostics typically run on a laptop 835 that shows information about the status of the PPC 800 and the patient's medical device (eg, an implantable cardiac rhythm management device or other patient-implanted medical device). May be. Similar to automotive dashboards with various gauges and indicators, dashboard diagnostics can be a communication medium (eg, a cellular network) and other medical devices or sensors that communicate to the patient implantable medical device 802 or the PPC 800.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to transmit data via a removable memory device using a PC with an upload applet, as taught by Larondo, because using a local computing device to retrieve stored medical device data and automatically upload it to a remote server was a known and predictable alternative communication pathway.
Regarding claim 9, Martin and Larondo teach the invention in claim 8, as discussed above, and further teach wherein the upload applet is configured to activate automatic upload of the data from the removable memory device onto the PC (Larondo, page 54-55, “Expansion of the ability to interface between the PPC 800 and external device (s) can be done with or without the involvement of the automatic patient management server 850. For example, a local interface connection device (e.g., a laptop) can communicate with and obtain data from the patient implantable medical device 802 wirelessly or via a hard wire connection (e.g., USB or FireWire). The local device can display various types of data obtained from the patient implantable medical device 802, such as ECG waveforms, sensor data, event counters, histograms, and other information of interest. In general, browsing-only access to the patient implantable medical device is preferably granted to the local device, as shown in FIG. A suitable local device, such as a laptop, can be configured to emulate a patient implantable medical device programmer, and an authorized clinician can use such a local device to Note that 800 can be called or programmed locally. Data related to local patient implantable medical device programming and / or calls may be uploaded to the automated patient management server 850 via a wireless or hardwire connection.” and Larondo, page 27, “A physician or other authorized person can also interact with the automated patient management server to access various information regarding the specific patient, the patient's medical device, and / or the patient portable communicator. FIGS. 9A and 9B illustrate a user access device, such as a laptop or patient portable communicator 835, that provides authorized access to the automatic patient management server 850 via a network 830 (eg, a life critical network), for example. The laptop 835 may be in a doctor's office, home, or other location (eg, a resort hotel room). Dashboard diagnostics typically run on a laptop 835 that shows information about the status of the PPC 800 and the patient's medical device (eg, an implantable cardiac rhythm management device or other patient-implanted medical device). May be. Similar to automotive dashboards with various gauges and indicators, dashboard diagnostics can be a communication medium (eg, a cellular network) and other medical devices or sensors that communicate to the patient implantable medical device 802 or the PPC 800.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to configure the upload applet to automatically upload data from the removable memory device onto the PC, as taught by Larondo, because automation of data transfer from connected storage devices was a routine software function that reduced user intervention and yielded predictable improvements in efficiency.
Regarding claim 10, Martin and Larondo teach the invention in claim 9, as discussed above, and further teach wherein the upload applet is further configured to activate transmission of the data from the PC (Larondo, page 27, “A physician or other authorized person can also interact with the automated patient management server to access various information regarding the specific patient, the patient's medical device, and / or the patient portable communicator. FIGS. 9A and 9B illustrate a user access device, such as a laptop or patient portable communicator 835, that provides authorized access to the automatic patient management server 850 via a network 830 (eg, a life critical network), for example. The laptop 835 may be in a doctor's office, home, or other location (eg, a resort hotel room). Dashboard diagnostics typically run on a laptop 835 that shows information about the status of the PPC 800 and the patient's medical device (eg, an implantable cardiac rhythm management device or other patient-implanted medical device). May be. Similar to automotive dashboards with various gauges and indicators, dashboard diagnostics can be a communication medium (eg, a cellular network) and other medical devices or sensors that communicate to the patient implantable medical device 802 or the PPC 800.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to further configure the upload applet to activate transmission of the data from the PC to a remote system, as taught by Larondo, because once data is uploaded to a local computing device, automated forwarding over a network is a conventional and predictable extension of known data management workflows.
Regarding claim 11, Martin and Larondo teach the invention in claim 1, as discussed above, and further teach wherein transmission of the data is via one or more of: GSM transmission; VOIP transmission; analog or digital telephone modem; manual input of data displayed on the breathing apparatus to a website; manual or voice input of data displayed on the breathing apparatus into a mobile, landline, or VOIP telephone; or data in an audible form from a speaker of the breathing apparatus over the mobile, landline, or VOIP telephone (Larondo, page 10, “It should be appreciated that the present invention can utilize the mobile network 20 rather than a GSM based system. For example, Universal Mobile Telecommunication System (UMTS) is a 3G mobile technology that may replace the GSM / GPRS network infrastructure in the future and possibly in the present. UMTS has a radio interface that can connect to different backbone networks, such as the Internet, ISDN, GSM, or other UMTS networks, unlike GSM. The PPC 14 can also be configured to communicate over a UMTS network or any other conventional or future network.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to transmit data using alternative modalities such as GSM, VOIP, telephone modems, manual data entry, voice input, or audible transmission, as taught by Larondo, because multiple redundant communication mechanisms for medical data transmission were well known and commonly used depending on infrastructure availability and user constraints.
Regarding claim 12, Martin and Larondo teach the invention in claim 1, as discussed above, and further teach wherein a recipient computer of the plurality of recipient computers belongs to one or more of: an insurance company; a medical equipment dealer; a healthcare professional, or a patient (Larondo, page 6, “Each PPC 14 is preferably uniquely assigned to a particular patient 12A through a process according to various embodiments generally referred to herein as “pairing”. As used herein, pairing generally refers to the inherent association that occurs between a patient's PPC 14 and the medical device (s) 13 associated with that patient.”, and Larondo, page 67 “The hub 1000 can also incorporate speech synthesis circuitry or speech file playback circuitry that converts speech / acoustic files into human language. Voice messages can be unidirectional or bidirectional, such as between the hub 1000 and the automated patient management server 850. For example, a message forwarded to the hub 1000 via the automated patient management system 850from a physician, clinician, or technician (eg, an employee of an automated patient management service) is transmitted in human language by the acoustic and electrical circuit / component of the hub1000. It may be reproduced in the form. The sound file may be converted into, for example, WAV orMP3 format. The hub 1000 may also allow a patient or caregiver to record a message and send this message to the recipient via the automated patient management server 850. A “live” audio session between the patient / caregiver and the physician, clinician, or technician is performed using a wired connection established using the hub 1000, a wireless connection, or a connection to the voice over internet.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to route therapy data to recipient computers belonging to insurance companies, medical equipment dealers, healthcare professionals, or patients, as taught by Larondo, because distributing medical device data to different stakeholders for monitoring, compliance, billing, or care management was a known and predictable use of such systems.
Regarding claim 13, Martin and Larondo teach the invention in claim 1, as discussed above, and further teach wherein the therapy data comprise one or more of: flow data; or data relating to flow limitation events (Martin [0077] “Referring again to FIG. 9, a controller 130 may be provided to control the supply of power to and operation of the blower assembly 98. The controller 130 may be, for example, a printed circuit board comprising a control circuit that receives signals from the flow sensor 134 and controls the blower assembly 98 and heater plate 102 to provide a humidified air flow 164 at predetermined humidity and/or temperature. Such a control circuit is disclosed in U.S. Patent Application Publication 2009/0223514 A1, the entire contents of which is incorporated herein by reference.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to include flow data and data relating to flow limitation events as part of the therapy data, as taught by Martin, because flow sensing and analysis are fundamental aspects of PAP therapy systems and routinely used to monitor treatment efficacy and device operation.
Regarding claim 14, Martin and Larondo teach the invention in claim 1, as discussed above, and further teach wherein the trigger comprises the breathing apparatus automatically signaling the transmission interface to: retrieve the therapy data from the breathing apparatus; and one or both of receive the data from or transmit the data including the therapy data to the user computer (Martin [0002] “The present invention relates to positive airway pressure devices for respiratory therapy for treating, for example, Sleep Disordered Breathing (SDB). The present invention also relates to components for positive pressure airway devices.” and
Larondo, page 9, “For example, a particular block of medical device data of interest may be selectively transferred from the medical device 13 to the patient mobile communicator 14 in response to a command signal generated by the remote server, the patient mobile communicator 14, or the medical device 13. Good. The generation of these command signals may be derived from programmed instructions residing in the PPC 14 or medical device memory that are triggered to be executed by the PPC 14, medical device, or remote server. The programmed instructions may be changed, typically by a physician via a remote server, or by an interface to the PPC 14 or medical device. For example, a physician may wish to receive data related to an arrhythmia (eg, atrial or ventricular tachyarrhythmia) whenever such an event occurs. This selected portion of the data is tagged for transfer to the PPC 14 according to the physician's request. Depending on the severity of the event type, the physician may require that event data be automatically transferred to the remote server via the PPC 14 as soon as the event occurs, or more severe For infrequent events, the PPC 14 may request that data be transferred the next time it connects to the remote server.” Larondo, page 6-7, “Each PPC 14 is preferably uniquely assigned to a particular patient 12A through a process according to various embodiments generally referred to herein as “pairing”. As used herein, pairing generally refers to the inherent association that occurs between a patient's PPC 14 and the medical device (s) 13 associated with that patient. When information is transmitted between the medical device 13 and the automatic patient management server 16A, the patient portable communicator 14 paired with the individual medical device (s) 13 can receive information through one or more networks.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to configure the breathing apparatus to automatically trigger retrieval and transmission of therapy data, as taught by Larondo, because automated command based data transfer from a medical device to an intermediary or remote system in response to programmed triggers was well known and yielded predictable results in remote patient monitoring systems.
Regarding claim 15, Martin and Larondo teach the invention in claim 1, as discussed above, and further teach wherein the trigger comprises a user action (Larondo, page 9, “For example, a particular block of medical device data of interest may be selectively transferred from the medical device 13 to the patient mobile communicator 14 in response to a command signal generated by the remote server, the patient mobile communicator 14, or the medical device 13. Good. The generation of these command signals may be derived from programmed instructions residing in the PPC 14 or medical device memory that are triggered to be executed by the PPC 14, medical device, or remote server. The programmed instructions may be changed, typically by a physician via a remote server, or by an interface to the PPC 14 or medical device. For example, a physician may wish to receive data related to an arrhythmia (eg, atrial or ventricular tachyarrhythmia) whenever such an event occurs. This selected portion of the data is tagged for transfer to the PPC 14 according to the physician's request. Depending on the severity of the event type, the physician may require that event data be automatically transferred to the remote server via the PPC 14 as soon as the event occurs, or more severe For infrequent events, the PPC 14 may request that data be transferred the next time it connects to the remote server.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to invention to initiate data retrieval and transmission in response to a user action, as taught by Larondo, because user initiated commands for selectively transmitting medical device data were a conventional control mechanism that provided predictable and expected functionality.
Regarding claim 16, Martin and Larondo teach the invention in claim 1, as discussed above, and further teach wherein the trigger comprises an end of a treatment session (Larondo, page 49-50, “First, the caregiver conducts a remote program session through the data input mechanism (operation 731). The programming instructions and parameters selected by the caregiver are converted by the managed server into a patient implantable medical device type command that is checked for accuracy and digitally signed (operation 732). Also, the patient-implanted medical device formalized command is inversely converted and provided in a format that can be displayed to the caregiver for approval or rejection (operation 733). If the converted programming is rejected by the caregiver, control returns to the caregiver's program session (operation 731). Otherwise, the patient-implanted medical device formatted command is marked for delivery to the server and, after receipt by the server, authentication and integrity are verified (operation 734). In a further embodiment, the patient implantable medical device itself performs command confirmation in addition to or in place of the server. Assuming that the command has been confirmed, the patient's consent is verified before the command is applied (operation 735). However, if the patient does not give consent, control returns to the program session again (operation 731). With consent, the server performs a program session (operation 736). If the session is interrupted and does not resume or is terminated abnormally, the original patient implantable device programming is restored and control returns to the program session (operation 731). With successful programming, the server calls the patient implantable medical device after the program session is complete to report the programmed results for overview and evaluation to the caregiver (operation 737). Additional implementations for remote programming that the embodiments may be used in conjunction with the various embodiments discussed herein are co-owned patents incorporated herein by reference.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the to trigger data transmission at the end of a treatment session, as taught by Larondo, because post session reporting and transmission of medical device data was a routine practice in remote medical systems to summarize completed therapy and enable review, with predictable results.
Regarding claim 17, Martin and Larondo teach the invention in claim 1, as discussed above, and further teach wherein the trigger comprises a scheduled time (Larondo, page 22, “PPC data is collected at a scheduled time, for example at night, and many activities can be performed if the patient is out of coverage while sleeping.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to trigger retrieval and transmission of therapy data at a scheduled time, as taught by Larondo, because scheduled data collection and transmission were well known techniques used to accommodate network availability and patient usage patterns, and selecting a scheduled trigger represents a predictable and routine implementation choice.
Regarding claim 21, Martin teaches breathing data from a plurality of remote breathing apparatus devices (Martin [0002] “The present invention relates to positive airway pressure devices for respiratory therapy for treating, for example, Sleep Disordered Breathing (SDB). The present invention also relates to components for positive pressure airway devices.”);
a plurality of breathing apparatus devices, each breathing apparatus device of the plurality of breathing apparatus devices including a controller, a user interface, a blower, and one or more sensors communicative with the controller, wherein the one or more sensors include a flow sensor (Martin [0002] “The present invention relates to positive airway pressure devices for respiratory therapy for treating, for example, Sleep Disordered Breathing (SDB). The present invention also relates to components for positive pressure airway devices.”, and Martin [0077] “Referring again to FIG. 9, a controller 130 may be provided to control the supply of power to and operation of the blower assembly 98. The controller 130 may be, for example, a printed circuit board comprising a control circuit that receives signals from the flow sensor 134 and controls the blower assembly 98 and heater plate 102 to provide a humidified air flow 164 at predetermined humidity and/or temperature.”); and
wherein the breathing apparatus devices are configured to generate therapy data, the therapy data being one or more of: usage data, compliance data, efficacy data, patient data, or other data from the breathing apparatus, each of the plurality of the breathing apparatus devices are further comprising (Martin [0002] “The present invention relates to positive airway pressure devices for respiratory therapy for treating, for example, Sleep Disordered Breathing (SDB). The present invention also relates to components for positive pressure airway devices.”, Martin [0040] “The term "air" will be taken to include breathable gases, for example air with supplemental oxygen.”, Martin [0077] “Referring again to FIG. 9, a controller 130 may be provided to control the supply of power to and operation of the blower assembly 98. The controller 130 may be, for example, a printed circuit board comprising a control circuit that receives signals from the flow sensor 134 and controls the blower assembly 98 and heater plate 102 to provide a humidified air flow 164 at predetermined humidity and/or temperature. Such a control circuit is disclosed in U.S. Patent Application Publication 2009/0223514 A1, the entire contents of which is incorporated herein by reference.”, Martin [0057] “As shown in FIG. 5, a tube, or hose, 80 may be connected to the outlet 26, for example by a connector 84, to deliver the air flow to a patient interface 82, for example a mask.”).
Martin fails to explicitly teach a computer system which receives data and determines an appropriate target recipient system of a plurality of target recipient systems, the target recipient systems having different formatting requirements, formats and routes breathing apparatus usage data to the appropriate target recipient system of the plurality of target recipient systems, the computer system comprising;
a processor which receives data and a user interface;
to generate therapy data, patient data, a transmission interface, and to automatically, upon periodic occurrence of a trigger, transmit data using the transmission interface;
wherein the processor further comprises a data integration engine, a routing engine, and an output engine;
the routing engine identifies an appropriate recipient computer of a plurality of recipient computers for the data, each recipient computer comprising different data and encoding requirements;
the data integration engine formats data received;
the routing engine identifies an appropriate recipient computer of a plurality of recipient computers for the data, each recipient computer comprising different data and encoding requirements;
wherein the routing engine: receives a user identification or a device identification associated with the device from which data was received;
retrieves stored routing rules based on the user identification or the device identification;
the output engine formats the data into a format required by the recipient computer identified based on the routing rules and encodes the data for transmission to the recipient computer according to the requirements of the recipient computer;
the processor further configured to transmit the encoded data to an appropriate recipient computer; and
wherein receiving and/or transmitting of the data is via a WAN network, the breathing apparatus devices being directly or indirectly in communication with the WAN network via a wired or wireless connection.
Larondo teaches a computer system which receives data and determines an appropriate target recipient system of a plurality of target recipient systems, the target recipient systems having different formatting requirements, formats and routes breathing apparatus usage data to the appropriate target recipient system of the plurality of target recipient systems, the computer system comprising (Larondo, page 6-7, “Each patient medical device 13 can generate one or more types of patient data, and can incorporate one or more components for the delivery of therapy, sensing physiological data, and measuring environmental parameters. Typical medical devices include, for example, patient implantable medical devices (PIMD) such as pacemakers, implantable defibrillators, drug pumps, and nerve stimulation devices. For example, an extracorporeal medical device such as an automatic external defibrillator (AED) may also be paired with a patient portable communicator. Medical devices can include implantable or external sensors. Examples of the implantable sensor include a heart or respiratory monitor, an implantable diagnostic multi-sensor non-therapeutic device, and the like. External sensors include Holter monitors, scales, sphygmomanometer cuffs, temperature sensors (eg digital thermometers and skin temperature sensors), ECG and / or heart rate sensors, respiratory masks such as CPAP masks with oxygen and carbon dioxide concentrations There may also be mentioned gas sensors”, Larondo, page 7, “Patient communicator 14 communicates with cellular-based components. For example, the PPC 14 can communicate with the base station 24 via a wireless interface.” And Larondo, page 9, “For example, a particular block of medical device data of interest may be selectively transferred from the medical device 13 to the patient mobile communicator 14 in response to a command signal generated by the remote server, the patient mobile communicator 14, or the medical device 13. Good. The generation of these command signals may be derived from programmed instructions residing in the PPC 14 or medical device memory that are triggered to be executed by the PPC 14, medical device, or remote server. The programmed instructions may be changed, typically by a physician via a remote server, or by an interface to the PPC 14 or medical device. For example, a physician may wish to receive data related to an arrhythmia (eg, atrial or ventricular tachyarrhythmia) whenever such an event occurs. This selected portion of the data is tagged for transfer to the PPC 14 according to the physician's request. Depending on the severity of the event type, the physician may require that event data be automatically transferred to the remote server via the PPC 14 as soon as the event occurs, or more severe For infrequent events, the PPC 14 may request that data be transferred the next time it connects to the remote server.”, Larondo, page 4, “As shown in the embodiment of FIG. 1A, life critical network 200 employs central authority 16 to manage access to the network infrastructure. This includes cryptographically verifying and authenticating content from potential nodes and allowing other control over network-based monitoring aspects before allowing access. The life critical network 200 preferably supports the concept of classifying nodes on the network 200 into a specific hierarchy of access entitlements. Various components seeking access to the life critical network 200 are given different access rights based on their classification. For example, if the sensor devices 17A to 17B with low urgency are classified into a hierarchy with low urgency or priority, access to a high-speed connection may not be given. The patient implantable medical device programmer system 23 may be given preferential access to high speed connectivity functions due to the more stringent requirements for timely interconnection to the infrastructure. This classification and priority determination is preferably managed dynamically via the central authority 16.” Larondo, page 26, “FIG. 3D illustrates an embodiment of a source medical device that communicates with each target component via a life-critical network that supports dynamic communication link mapping methods, according to an embodiment of the present invention. The portable source device 14 is shown communicatively connected to a network 200 that includes a number of nodes N and a target node.sub.NT corresponding to a target component 16 such as, for example, a central authority or patient management server system. Portable source device 14 is preferably connected to mapping agent 235and profile library 237 and also incorporates mapping agent 235 and profile library 237. The mapping agent 235 preferably employs a processor configured to execute program instructions for discovering available communication links in the network 200 and obtain connection information such as connection options and connection attributes from the discovery operation.”, and Larondo, page 67 “The hub 1000 can also incorporate speech synthesis circuitry or speech file playback circuitry that converts speech / acoustic files into human language. Voice messages can be unidirectional or bidirectional, such as between the hub 1000 and the automated patient management server 850. For example, a message forwarded to the hub 1000 via the automated patient management system 850from a physician, clinician, or technician (eg, an employee of an automated patient management service) is transmitted in human language by the acoustic and electrical circuit / component of the hub1000. It may be reproduced in the form. The sound file may be converted into, for example, WAV orMP3 format. The hub 1000 may also allow a patient or caregiver to record a message and send this message to the recipient via the automated patient management server 850. A “live” audio session between the patient / caregiver and the physician, clinician, or technician is performed using a wired connection established using the hub 1000, a wireless connection, or a connection to the voice over internet.”):;
a processor which receives data and a user interface (Larondo, page 26, “FIG. 3D illustrates an embodiment of a source medical device that communicates with each target component via a life-critical network that supports dynamic communication link mapping methods, according to an embodiment of the present invention. The portable source device 14 is shown communicatively connected to a network 200 that includes a number of nodes N and a target node.sub.NT corresponding to a target component 16 such as, for example, a central authority or patient management server system. Portable source device 14 is preferably connected to mapping agent 235and profile library 237 and also incorporates mapping agent 235 and profile library 237. The mapping agent 235 preferably employs a processor configured to execute program instructions for discovering available communication links in the network 200 and obtain connection information such as connection options and connection attributes from the discovery operation.”, Larondo, page 29, “Although the PPC 800 can also incorporate a display that includes some or all of the indicators provided on the dashboard 842, various embodiments of the PPC 800 can be implemented with a reduced feature set, for example. A limited user interface may also be provided, such as in the case of a patient mobile communicator 800.”);
to generate therapy data, patient data, a transmission interface, and to automatically, upon periodic occurrence of a trigger, transmit data using the transmission interface (Larondo, page 6-7, “Each patient medical device 13 can generate one or more types of patient data, and can incorporate one or more components for the delivery of therapy, sensing physiological data, and measuring environmental parameters. Typical medical devices include, for example, patient implantable medical devices (PIMD) such as pacemakers, implantable defibrillators, drug pumps, and nerve stimulation devices. For example, an extracorporeal medical device such as an automatic external defibrillator (AED) may also be paired with a patient portable communicator. Medical devices can include implantable or external sensors. Examples of the implantable sensor include a heart or respiratory monitor, an implantable diagnostic multi-sensor non-therapeutic device, and the like. External sensors include Holter monitors, scales, sphygmomanometer cuffs, temperature sensors (eg digital thermometers and skin temperature sensors), ECG and / or heart rate sensors, respiratory masks such as CPAP masks with oxygen and carbon dioxide concentrations There may also be mentioned gas sensors”, Larondo, page 7, “Patient communicator 14 communicates with cellular-based components. For example, the PPC 14 can communicate with the base station 24 via a wireless interface.” And Larondo, page 9, “For example, a particular block of medical device data of interest may be selectively transferred from the medical device 13 to the patient mobile communicator 14 in response to a command signal generated by the remote server, the patient mobile communicator 14, or the medical device 13. Good. The generation of these command signals may be derived from programmed instructions residing in the PPC 14 or medical device memory that are triggered to be executed by the PPC 14, medical device, or remote server. The programmed instructions may be changed, typically by a physician via a remote server, or by an interface to the PPC 14 or medical device. For example, a physician may wish to receive data related to an arrhythmia (eg, atrial or ventricular tachyarrhythmia) whenever such an event occurs. This selected portion of the data is tagged for transfer to the PPC 14 according to the physician's request. Depending on the severity of the event type, the physician may require that event data be automatically transferred to the remote server via the PPC 14 as soon as the event occurs, or more severe For infrequent events, the PPC 14 may request that data be transferred the next time it connects to the remote server.”);
wherein the processor further comprises a data integration engine, a routing engine, and an output engine (Larondo, page 26, “FIG. 3D illustrates an embodiment of a source medical device that communicates with each target component via a life-critical network that supports dynamic communication link mapping methods, according to an embodiment of the present invention. The portable source device 14 is shown communicatively connected to a network 200 that includes a number of nodes N and a target node.sub.NT corresponding to a target component 16 such as, for example, a central authority or patient management server system. Portable source device 14 is preferably connected to mapping agent 235and profile library 237 and also incorporates mapping agent 235 and profile library 237. The mapping agent 235 preferably employs a processor configured to execute program instructions for discovering available communication links in the network 200 and obtain connection information such as connection options and connection attributes from the discovery operation.”, Larondo, page 49, “First, the caregiver conducts a remote program session through the data input mechanism (operation731). The programming instructions and parameters selected by the caregiver are converted by the managed server into a patient implantable medical device type command that is checked for accuracy and digitally signed (operation 732). Also, the patient-implanted medical device formalized command is inversely converted and provided in a format that can be displayed to the caregiver for approval or rejection (operation 733). If the converted programming is rejected by the caregiver, control returns to the caregiver's program session (operation 731). Otherwise, the patient-implanted medical device formatted command is marked for delivery to the server and, after receipt by the server, authentication and integrity are verified (operation 734)”, Larondo, page 4, “As shown in the embodiment of FIG. 1A, life critical network 200 employs central authority 16 to manage access to the network infrastructure. This includes cryptographically verifying and authenticating content from potential nodes and allowing other control over network-based monitoring aspects before allowing access. The life critical network 200 preferably supports the concept of classifying nodes on the network 200 into a specific hierarchy of access entitlements. Various components seeking access to the life critical network 200 are given different access rights based on their classification. For example, if the sensor devices 17A to 17B with low urgency are classified into a hierarchy with low urgency or priority, access to a high-speed connection may not be given. The patient implantable medical device programmer system 23 may be given preferential access to high speed connectivity functions due to the more stringent requirements for timely interconnection to the infrastructure. This classification and priority determination is preferably managed dynamically via the central authority 16.”);
the data integration engine formats data received (arondo, page 6-7 “Each PPC 14 is preferably uniquely assigned to a particular patient 12A through a process according to various embodiments generally referred to herein as “pairing”. As used herein, pairing generally refers to the inherent association that occurs between a patient's PPC 14 and the medical device (s) 13 associated with that patient. When information is transmitted between the medical device 13 and the automatic patient management server 16A, the patient portable communicator 14 paired with the individual medical device (s) 13 can receive information through one or more networks.” and Larondo, page 49, “First, the caregiver conducts a remote program session through the data input mechanism (operation731). The programming instructions and parameters selected by the caregiver are converted by the managed server into a patient implantable medical device type command that is checked for accuracy and digitally signed (operation 732). Also, the patient-implanted medical device formalized command is inversely converted and provided in a format that can be displayed to the caregiver for approval or rejection (operation 733). If the converted programming is rejected by the caregiver, control returns to the caregiver's program session (operation 731). Otherwise, the patient-implanted medical device formatted command is marked for delivery to the server and, after receipt by the server, authentication and integrity are verified (operation 734)”.);
the routing engine identifies an appropriate recipient computer of a plurality of recipient computers for the data, each recipient computer comprising different data and encoding requirements (Larondo, page 4, “As shown in the embodiment of FIG. 1A, life critical network 200 employs central authority 16 to manage access to the network infrastructure. This includes cryptographically verifying and authenticating content from potential nodes and allowing other control over network-based monitoring aspects before allowing access. The life critical network 200 preferably supports the concept of classifying nodes on the network 200 into a specific hierarchy of access entitlements. Various components seeking access to the life critical network 200 are given different access rights based on their classification. For example, if the sensor devices 17A to 17B with low urgency are classified into a hierarchy with low urgency or priority, access to a high-speed connection may not be given. The patient implantable medical device programmer system 23 may be given preferential access to high speed connectivity functions due to the more stringent requirements for timely interconnection to the infrastructure. This classification and priority determination is preferably managed dynamically via the central authority 16.”);
wherein the routing engine: receives a user identification or a device identification associated with the device from which data was received (Larondo, page 35, “Pairing involves exchanging or providing pairing information that is used to link devices in communication in a unique patient implantable medical device-patient mobile communicator pair with one or both devices. Pairing information establishes and maintains device identification information, patient identification information, encryption keys, and / or a secure and reliable communication link between the patient implantable medical device and the patient portable communicator paired with it It can also contain information that can be used to Pairing information is generally maintained in the PPC and / or the patient implantable medical device and provided and exchanged before or during the pairing between the patient implantable medical device and the PPC. And / or deployed.”, Larondo, page 6-7 “Each PPC 14 is preferably uniquely assigned to a particular patient 12A through a process according to various embodiments generally referred to herein as “pairing”. As used herein, pairing generally refers to the inherent association that occurs between a patient's PPC 14 and the medical device (s) 13 associated with that patient. When information is transmitted between the medical device 13 and the automatic patient management server 16A, the patient portable communicator 14 paired with the individual medical device (s) 13 can receive information through one or more networks.” and Larondo, page 49, “First, the caregiver conducts a remote program session through the data input mechanism (operation731). The programming instructions and parameters selected by the caregiver are converted by the managed server into a patient implantable medical device type command that is checked for accuracy and digitally signed (operation 732). Also, the patient-implanted medical device formalized command is inversely converted and provided in a format that can be displayed to the caregiver for approval or rejection (operation 733). If the converted programming is rejected by the caregiver, control returns to the caregiver's program session (operation 731). Otherwise, the patient-implanted medical device formatted command is marked for delivery to the server and, after receipt by the server, authentication and integrity are verified (operation 734)”.);
retrieves stored routing rules based on the user identification or the device identification (Larondo, page 35, “Pairing involves exchanging or providing pairing information that is used to link devices in communication in a unique patient implantable medical device-patient mobile communicator pair with one or both devices. Pairing information establishes and maintains device identification information, patient identification information, encryption keys, and / or a secure and reliable communication link between the patient implantable medical device and the patient portable communicator paired with it It can also contain information that can be used to Pairing information is generally maintained in the PPC and / or the patient implantable medical device and provided and exchanged before or during the pairing between the patient implantable medical device and the PPC. And / or deployed.”, Larondo, page 6-7 “Each PPC 14 is preferably uniquely assigned to a particular patient 12A through a process according to various embodiments generally referred to herein as “pairing”. As used herein, pairing generally refers to the inherent association that occurs between a patient's PPC 14 and the medical device (s) 13 associated with that patient. When information is transmitted between the medical device 13 and the automatic patient management server 16A, the patient portable communicator 14 paired with the individual medical device (s) 13 can receive information through one or more networks.” and Larondo, page 49, “First, the caregiver conducts a remote program session through the data input mechanism (operation731). The programming instructions and parameters selected by the caregiver are converted by the managed server into a patient implantable medical device type command that is checked for accuracy and digitally signed (operation 732). Also, the patient-implanted medical device formalized command is inversely converted and provided in a format that can be displayed to the caregiver for approval or rejection (operation 733). If the converted programming is rejected by the caregiver, control returns to the caregiver's program session (operation 731). Otherwise, the patient-implanted medical device formatted command is marked for delivery to the server and, after receipt by the server, authentication and integrity are verified (operation 734)”.);
the output engine formats the data into a format required by the recipient computer identified based on the routing rules and encodes the data for transmission to the recipient computer according to the requirements of the recipient computer (Larondo, page 67 “The hub 1000 can also incorporate speech synthesis circuitry or speech file playback circuitry that converts speech / acoustic files into human language. Voice messages can be unidirectional or bidirectional, such as between the hub 1000 and the automated patient management server 850. For example, a message forwarded to the hub 1000 via the automated patient management system 850from a physician, clinician, or technician (eg, an employee of an automated patient management service) is transmitted in human language by the acoustic and electrical circuit / component of the hub1000. It may be reproduced in the form. The sound file may be converted into, for example, WAV orMP3 format. The hub 1000 may also allow a patient or caregiver to record a message and send this message to the recipient via the automated patient management server 850. A “live” audio session between the patient / caregiver and the physician, clinician, or technician is performed using a wired connection established using the hub 1000, a wireless connection, or a connection to the voice over internet.”, and Larondo, page 4, “As shown in the embodiment of FIG. 1A, life critical network 200 employs central authority 16 to manage access to the network infrastructure. This includes cryptographically verifying and authenticating content from potential nodes and allowing other control over network-based monitoring aspects before allowing access. The life critical network 200 preferably supports the concept of classifying nodes on the network 200 into a specific hierarchy of access entitlements. Various components seeking access to the life critical network 200 are given different access rights based on their classification. For example, if the sensor devices 17A to 17B with low urgency are classified into a hierarchy with low urgency or priority, access to a high-speed connection may not be given. The patient implantable medical device programmer system 23 may be given preferential access to high speed connectivity functions due to the more stringent requirements for timely interconnection to the infrastructure. This classification and priority determination is preferably managed dynamically via the central authority 16.”);
the processor further configured to transmit the encoded data to an appropriate recipient computer (Larondo, page 26, “FIG. 3D illustrates an embodiment of a source medical device that communicates with each target component via a life-critical network that supports dynamic communication link mapping methods, according to an embodiment of the present invention. The portable source device 14 is shown communicatively connected to a network 200 that includes a number of nodes N and a target node.sub.NT corresponding to a target component 16 such as, for example, a central authority or patient management server system. Portable source device 14 is preferably connected to mapping agent 235and profile library 237 and also incorporates mapping agent 235 and profile library 237. The mapping agent 235 preferably employs a processor configured to execute program instructions for discovering available communication links in the network 200 and obtain connection information such as connection options and connection attributes from the discovery operation.”, and Larondo, page 67 “The hub 1000 can also incorporate speech synthesis circuitry or speech file playback circuitry that converts speech / acoustic files into human language. Voice messages can be unidirectional or bidirectional, such as between the hub 1000 and the automated patient management server 850. For example, a message forwarded to the hub 1000 via the automated patient management system 850from a physician, clinician, or technician (eg, an employee of an automated patient management service) is transmitted in human language by the acoustic and electrical circuit / component of the hub1000. It may be reproduced in the form. The sound file may be converted into, for example, WAV orMP3 format. The hub 1000 may also allow a patient or caregiver to record a message and send this message to the recipient via the automated patient management server 850. A “live” audio session between the patient / caregiver and the physician, clinician, or technician is performed using a wired connection established using the hub 1000, a wireless connection, or a connection to the voice over internet.”); and
wherein receiving and/or transmitting of the data is via a WAN network, the breathing apparatus devices being directly or indirectly in communication with the WAN network via a wired or wireless connection (Larondo, page 12, “The life critical network 200 basically corresponds to a private network supported by a public network infrastructure. The life critical network 200 is configured to operate on the conventional mobile network 20 and data network 22.” and LARONDO, page 4, “The process of mapping the environment at the source end of the network 200 begins with a source agent making a series of queries and / or connection attempts through various methods of building temporal and spatial profiles. In various embodiments, the device that performs the mapping can also employ many forms of both wired and wireless communications. Communication mechanisms include but are not limited to RF radio transceivers (such as WiFiMax, IEEE 802.11a / b / g / n); cellular network transceivers (such as GSM, EDGE, GPRS, CDMA); Bluetooth (high power or low power) Method); Zigbee (IEEE 802.15.4); Wired Ethernet (IEEE 802.3); Legacy Telephone System (POTS) / Public Switched Telephone Network (PSTN); Emergency System (eg, 911, Radio Priority) Service); TDD, SMS, MMS, EMS, and VOIP may be included.”).
It would have been obvious to a person having ordinary skill in the art (PHOSITA), at the time of the invention, to combine the breathing apparatus system of Martin with the networked medical device data communication and management system of Larondo to arrive at the computer system. Martin teaches breathing apparatus devices for respiratory therapy that include a controller, blower, and flow sensor, thereby generating breathing and therapy data during use. Larondo teaches medical devices that generate patient and therapy data and automatically transmit such data via a transmission interface over a WAN to remote management systems. Larondo further teaches that data from distributed medical devices is communicated through a managed network to appropriate target components (central authority and patient management server systems) and that communication links and delivery are managed based on device and patient association (“pairing”) and device identification information. A PHOSITA would have been motivated to incorporate Larondo’s known remote data communication architecture into Martin’s breathing therapy environment to enable automated, remote collection and delivery of therapy and compliance data for monitoring and management purposes, which is a recognized objective of network patient management systems.
Further, claim 21 recites that the routing engine receives a user identification or device identification, retrieves stored routing rules based on that identification, and causes the output engine to format and encode the data according to the requirements of the identified recipient computer. Larondo teaches maintaining and using device identification and patient identification information through pairing, and using that maintained association information to control secure, reliable communications and delivery of medical device information to remote systems. In view of Larondo’s disclosure of managing delivery of medical data to network components based on device and patient association and managed network rules, it would have been obvious for a PHOSITA to implement routing logic that receives identification associated with the originating device (or associated user), consults stored routing information (routing rules and association data) to determine the proper target components, and formats and encodes transmitted information to satisfy recipient specific requirements as part of sending data through heterogeneous network components. Such identification routing and recipient specific formatting are predictable, routine features in networked medical device communications, and their use in the combined Martin and Larondo system would have yielded the predictable result of reliably directing breathing apparatus data to the correct recipient systems in an acceptable format over a WAN.
Claim 22 is analogous to claim 12, thus claim 22 is similarly analyzed and rejected in a manner consistent with the rejection of claim 12.
Regarding claim 23, Martin and Larondo teach the invention in claim 21, as discussed above, and further teach wherein the routing rules comprise a table correlating the user identification or device identification with one of the plurality of recipient computers (Larondo, page 26, “ The profile may be set automatically by the source medical device or the central authority 16.According to one approach, the source medical device employs a timer that measures how long the patient has stayed within a relatively narrow geographic location (eg, community center 221 or coffeeshop 225). The patient's residence time can be measured, and if the repeated residence time exceeds a threshold (eg> 1 hour), this location can then be automatically designated as a “daily destination”. The geographic location and the profile generated for this location that is automatically determined /created is stored in the source medical device. Table 1 below shows a number of communication link profiles associated with several different geographical locations (specifically, home location L .sub.A and work location L .sub.B ) represented inFIG. 3C. Including the profile library. This library is preferably stored in the non-volatile memory of the source medical device. Each location has an associated profile identified by a profile number. Each profile, (shown as C.sub.1 -C .sub.N) number of associated with the connection option. Typical connections include RFwireless transceivers (such as WiFiMax, IEEE 802.11a / b / g / n); cellular network transceivers (suchas GSM, EDGE, GPRS, CDMA); Bluetooth (high power or low power methods) Zigbee (IEEE802.15.4); Wired Ethernet (IEEE 802.3); Legacy Telephone System (POTS) / Public SwitchedTelephone Network (PSTN); Emergency System (eg, 911, Radio Priority Service); ; TDD, SMS, MMS,EMS, VOIP and the like..).”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to implement the routing rules as a table correlating a user identification or device identification with one of a plurality of recipient computers, as taught by Larondo, because Larondo discloses storing and using profile data that associates device or user related identifiers with specific communication profiles and destinations, and representing routing logic in a table is a well known and predictable data structure for implementing such correlations.
Response to Arguments
Applicant’s arguments and amendments, see Remarks/Amendments submitted on 11/05/2025 with respect to the rejection of the claims have been carefully considered and is addressed below.
Claim Rejections - 35 USC § 112
The § 112 (b) rejection of claim 1 is withdrawn because the Applicant’s amendments have clarified the previously identified ambiguities, and the claim now particularly points out and distinctly claims the subject matter regarded as the invention.
Claim Rejections - 35 USC § 101
Applicant’s arguments have been fully considered but are not persuasive. The claims remain directed to an abstract idea under Step 2A, Prong One. Claims 1 and 21 recite identifying an appropriate recipient for data and formatting and encoding data for that recipient based on recipient specific requirements. Under the broadest reasonable interpretation, these limitations recite decision making and information organization, which fall within the mental processes grouping of abstract ideas. The recitation of a “routing engine” and an “output engine” does not meaningfully limit the claims, as these components are described in functional terms and merely perform the abstract steps of selection and formatting.
Applicant’s argument that the claims cannot be performed in the human mind is unpersuasive. The eligibility analysis includes whether the claim recites concepts that can be performed mentally in principle, such as determining recipients and deciding how information should be organized. The claims do not recite any specific technical mechanism, algorithm, or improvement that would remove them from the mental processes grouping. Applicant’s reliance on SRI and USPTO Example 38 are misplaced, because those cases involved specific technical improvements to computer or signal processing technology, which are not present in the claims.
Under Step 2A, Prong Two, the abstract idea is not integrated into a practical application. The additional elements, the breathing therapy devices and networked computer systems, merely limit the abstract idea to a particular technological environment and constitute field-of-use limitations. The claimed computer components are generic and invoked only as tools to perform the abstract idea, and the remaining steps amount to routine data gathering, and transmission of data, which amounts to merely data gathering and insignificant application, and is a form of insignificant extra-solution activity. These additional elements do not improve the functioning of a computer, network, or breathing apparatus, nor do they meaningfully limit the abstract idea.
Under Step 2B, the claims do not recite significantly more than the abstract idea. The additional elements, individually and in combination, represent well-understood, routine, and conventional activities in the field of monitoring and information systems. The claims do not recite a technical solution to a computer problem or any unconventional use of technology, and thus are distinguishable from DDR Holdings. Accordingly, claims 1-17 and 21-23 remain not patent eligible under 35 U.S.C. § 101, and the rejection is maintained.
Claim Rejections - 35 USC § 103
Applicant’s arguments have been considered but are not persuasive. Applicant states that the amended claims are not taught by the cited art because the prior art allegedly fails to recognize the need to format data for a plurality of different recipient devices. However, Martin teaches generating and collecting breathing therapy data from respiratory devices, while Larondo teaches transmitting medical device data to multiple different recipient systems, classifying recipients, and formatting and routing data according to recipient specific profiles and communication requirements. Larondo further discloses storing routing logic and communication profiles that determine how data is delivered to different destination systems. A person of ordinary skill in the art would have been motivated to combine Martin’s respiratory therapy data generation with Larondo’s known data routing and formatting techniques to enable predictable transmission of therapy data to different recipient systems. The claimed amendments reflect the predictable application of Larondo’s routing and formatting mechanisms to the therapy data of Martin. Accordingly, the rejection under 35 U.S.C. § 103 is maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Dicks et al. (U.S. Patent Publication 2008/0097793A1) teaches a method of analyzing received patient information to identify a patient condition and generate selectively transmittable, customizable reports, enabling remote monitoring of medical devices from virtually any location without restricting patient mobility or requiring frequent healthcare facility visits.
Jain et al. (U.S. Patent Publication 2011/0167133 A1) teaches a system including an application hosting device that collects and modifies data from a medical device, transmits the data to a processing server for association with a user or device, and relays user generated instructions from the server back to the medical device, with the hosting device also storing data from multiple users and devices.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KYRA R LAGOY whose telephone number is (703)756-1773. The examiner can normally be reached Monday - Friday, 8:00 am - 5:00 pm 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, Kambiz Abdi can be reached at (571)272-6702. 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.
/K.R.L./Examiner, Art Unit 3685
/KAMBIZ ABDI/Supervisory Patent Examiner, Art Unit 3685