Methods, devices, servers, respiratory treatment systems, and apparatus

Abstract

A method and apparatus for improving the security of communications between devices is provided. In a secure networked respiratory treatment system, a more secure communication link is established using a shared secret derived using a different communication link. The communication includes transmitting treatment data from a respiratory treatment device to a server for authentication. A control device receives data and a nonce from the server, and receives from the respiratory treatment device a signing key that depends on the nonce and a secret shared by the respiratory treatment device and the server. Upon receiving the code and data, the control device generates an authentication code using the received treatment data and key for authentication of the data by the server. The server calculates a key from the nonce and a secret known to the respiratory treatment device and another authentication code from the received treatment data and key. Data authentication includes comparing the received code with the calculated code.

Description

[Technical Field]

[0001] 1 Cross-reference to related applications This application claims the benefit of U.S. Provisional Patent Application No. 62 / 416,867, filed November 3, 2016, and U.S. Provisional Patent Application No. 62 / 458,658, filed February 14, 2017, each of which is incorporated herein by reference in its entirety.

[0002] 2. Technical Background 2.1 Technology field The present technology relates to one or more of the detection, diagnosis, treatment, prevention and amelioration of respiratory-related disorders. The present technology also relates to medical devices or apparatus and their use or operation. [Background technology]

[0003] 2.2 Description of Related Art 2.2.1 The human respiratory system and its diseases The body's respiratory system facilitates gas exchange. The nose and oral cavity form the entrance to a patient's airways.

[0004] These airways contain a series of branching tubes that become narrower, shorter, and more numerous the deeper they travel into the lungs. The primary function of the lungs is gas exchange, allowing oxygen from the air to enter the venous blood and carbon dioxide to leave. The trachea divides into right and left main bronchi, which further divide into terminal bronchioles. The bronchi constitute conducting airways and do not participate in gas exchange. The airways further divide into respiratory bronchioles and ultimately into alveoli. Gas exchange occurs in the alveolar region of the lung, which is called the respiratory zone. See: "Respiratory Physiology," by John B. West, Lippincott Williams & Wilkins, ninth edition published 2012.

[0005] There is a range of respiratory diseases. Particular diseases can be characterized by particular manifestations such as apnea, hypopnea and hyperpnea.

[0006] Examples of respiratory diseases include obstructive sleep apnea (OSA), Cheyne-Stokes respiration (CSR), respiratory failure (RF), obesity hyperventilation syndrome (OHS), chronic obstructive pulmonary disease (COPD), neuromuscular diseases (NMD), and chest wall diseases.

[0007] Obstructive sleep apnea (OSA) is a form of sleep-disordered breathing (SDB) characterized by respiratory episodes such as closure or obstruction of the upper airway during sleep. It results from a combination of an abnormally small upper airway and normal loss of muscle tone in the area of the tongue, soft palate, and posterior oropharyngeal wall during sleep. This condition causes affected individuals to experience breathing pauses typically lasting 30 to 120 seconds, sometimes 200 to 300 times per night. This can result in excessive daytime sleepiness, which can contribute to cardiovascular disease and brain damage. This condition is common, particularly among middle-aged, overweight men, but patients often experience no symptoms. See U.S. Pat. No. 4,944,310 (Sullivan).

[0008] Respiratory failure is a general term for respiratory disorders that refers to the inability of the lungs to take in enough oxygen or exhale enough CO2 to meet the patient's needs. Respiratory failure can include some or all of the following conditions:

[0009] Obesity hyperventilation syndrome (OHS) is defined as the combination of severe obesity and awake chronic hypercapnia in the absence of any other clear cause of hypoventilation. Symptoms include dyspnea, morning headache, and excessive daytime sleepiness.

[0010] Chronic obstructive pulmonary disease (COPD) encompasses any of a group of lower respiratory tract diseases that share certain common characteristics, including increased resistance to air movement, prolonged expiratory phase of breathing, and a decrease in normal lung elasticity. Examples of COPD include emphysema and chronic bronchitis. Causes of COPD include chronic smoking (the primary risk factor), occupational exposure, air pollution, and genetic factors. Symptoms include dyspnea on exertion, chronic cough, and sputum production.

[0011] Neuromuscular disease (NMD) is a broad term encompassing numerous diseases and illnesses that impair muscle function directly through intrinsic muscle pathology or indirectly through neuropathology. Some NMD patients are characterized by progressive muscle impairment, resulting in the inability to walk, wheelchair confinement, difficulty swallowing, respiratory muscle weakness, and ultimately death from respiratory failure. Neuromuscular disorders can be categorized as rapidly progressive or slowly progressive: (i) rapidly progressive disorders, characterized by muscle impairment that worsens over months and leads to death within a few years (e.g., amyotrophic lateral sclerosis (ALS) and Duchenne muscular dystrophy (DMD) in teenagers); (ii) variable or slowly progressive disorders, characterized by muscle impairment that worsens over years and results in only a modest reduction in life expectancy (e.g., limb-girdle, facioscapulohumeral, and myotonic muscular dystrophy). Symptoms of respiratory failure in NMD include: increasing general weakness, difficulty swallowing, difficulty breathing on exertion and at rest, fatigue, drowsiness, morning headache, and difficulty concentrating and mood changes.

[0012] Chest wall disorders are a group of thoracic deformities that result in ineffective connections between the respiratory muscles and the rib cage. These disorders are primarily characterized by restrictive obstruction and share the potential for long-term hypercapnic respiratory failure. Scoliosis and / or kyphoscoliosis can lead to severe respiratory failure. Symptoms of respiratory failure include: dyspnea on exertion, peripheral edema, orthopnea, recurrent chest infections, morning headache, fatigue, poor sleep quality, and loss of appetite.

[0013] A range of respiratory therapies are used to treat such conditions.

[0014] 2.2.2 Respiratory therapy Various forms of respiratory therapy (e.g., continuous positive airway pressure (CPAP) therapy, noninvasive ventilation (NIV), and invasive ventilation (IV)) are used to treat or ameliorate one or more of the above-mentioned respiratory disorders. Additionally, otherwise healthy individuals can also benefit from preventative treatment of respiratory disorders.

[0015] Continuous positive airway pressure (CPAP) therapy is used in the treatment of obstructive sleep apnea (OSA). Its mechanism of action is that continuous positive airway pressure acts as a pneumatic splint, for example, by pushing the soft palate and tongue forward or backward against the posterior oropharyngeal wall, thereby preventing closure of the upper airway. Because treatment of OSA with CPAP therapy can be voluntary, patients may choose not to adhere to treatment if they perceive one or more of the following about the device used to deliver the treatment: uncomfortable, difficult to use, expensive, or aesthetically unappealing.

[0016] Noninvasive ventilation (NIV) provides ventilatory support to a patient through the upper airway to assist the patient in breathing and / or maintain adequate oxygen levels in the body by performing some or all of the respiratory functions. Ventilatory support is provided through a noninvasive patient interface. NIV is used to treat CSR and respiratory failure in forms such as OHS, COPD, MD, and chest wall disorders.

[0017] Invasive ventilation (IV) provides ventilatory support to patients who are no longer able to breathe effectively on their own and can be provided using a tracheostomy tube.

[0018] High-flow therapy is a respiratory therapy that involves adding airflow to the entrance to the airways at a rate higher than typical respiratory flow. HFT is used to treat OSA and COPD.

[0019] Oxygen therapy is a respiratory therapy that involves adding oxygen-enriched air at a controlled flow rate to the entrance to the airways. Oxygen therapy is used to treat COPD.

[0020] 2.2.3 Respiratory Treatment Systems Respiratory therapy may be provided by a respiratory flow and / or pressure therapy system or device. The respiratory therapy system may include a respiratory therapy device (RT device) (e.g., a respiratory pressure therapy (RPT) device), an air circuit, a humidifier, a patient interface, an external control device, and a remote server.

[0021] 2.2.3.1 Patient Interface A patient interface may be used to provide a wearer with an interface to a respiratory device, for example, by providing airflow to an airway entrance. Airflow may be provided via a mask to the nose and / or mouth, a tube to the mouth, or a tracheostomy tube to the patient's trachea. Depending on the therapy being applied, the patient interface may form a seal with, for example, an area of the patient's face, thereby facilitating gas delivery at a pressure sufficient to disperse with atmospheric pressure for therapy implementation (e.g., at a positive pressure of about 10 cmH2O relative to atmospheric pressure). In other forms of therapy, such as oxygen therapy, the patient interface, for example, a nasal cannula, may not include a seal sufficient to facilitate delivery of a gas supply to the airways at a positive pressure of about 10 cmH2O.

[0022] 2.2.3.2 Respiratory Therapy (RT) Devices RT devices can be used to deliver one or more of the above-mentioned therapies, for example, by generating a flow of air at positive pressure for delivery to the entrance of the airways. Examples of RT devices include CPAP devices, mechanical ventilators, and portable oxygen concentrators.

[0023] 2.2.3.3 Humidifier Airflow delivery without humidification can lead to dryness of the airway. When a humidifier is used with an RT device and patient interface, humidified gas is produced, minimizing drying of the nasal mucosa and increasing comfort in the patient's airway. Additionally, in cooler climates, the application of warm air to the facial area surrounding the patient interface generally provides more comfort than cool air.

[0024] 2.2.3.4 External Control Devices Due to cost and / or ease of manufacture, the user interface of an RT device may be quite limited, perhaps including one or two buttons and LEDs, but no display screen. However, in such situations, the sophistication of therapies deliverable via the RT device must not be compromised. One way to achieve both goals is to make the RT device controllable by an external control device. This external control device is configured with the functionality to control the RT device to provide the full range of respiratory therapies the RT device is capable of providing, for example, by transmitting control parameters (e.g., pressure and / or flow settings). The external control device may take the form of a dedicated pre-configured "remote control" or a general-purpose computing device configured by running special-purpose software applications. For convenience, the external control device may be portable. In some such cases, the external control device may be configured to download special-purpose software application(s), for example, from a remote server over a network (e.g., the Internet), to accomplish the functions described in more detail herein.

[0025] Typically, such external control arrangements require the RT device to communicate with the external control device. For convenience, especially if the external control device is portable, communication between the RT device and the external control device can be wireless. It is desirable to prevent unauthorized individuals also possessing an external control device configured to control the RT device from breaching the security of the arrangement. This is particularly difficult with wireless communications, which in principle allow easy and unauthorized access to unauthorized external control devices within range of the RT device. Protocols for short-range wireless communication between two devices (e.g., Bluetooth®) may have a certain level of built-in security, but remain vulnerable to certain types of attacks via unauthorized external control devices within range of the RT device, as determined by the particular wireless protocol being used.

[0026] 2.2.3.5 Remote Server For clinical reasons, data may be obtained to determine whether a patient prescribed respiratory therapy is "compliant" (e.g., whether the patient adheres to one or more "compliance rules" with their RT device). An example of a compliance rule for CPAP therapy requires that a patient use the RT device for at least four hours per night for at least 21 days out of 30 consecutive days to be considered compliant. To determine patient compliance, a provider of the RT device (e.g., a healthcare provider or device manufacturer) may operate a remote server configured to communicate with the RT device, e.g., periodically, over a network. The remote server may obtain data describing the patient's therapy or the results of evaluation of one or more compliance rules from the RT device. The therapy data may be used to calculate usage over a predetermined period and evaluated in conjunction with the compliance rule(s) by the remote server and / or the RT device. Once the healthcare provider determines that the patient has used their RT device in accordance with the compliance rules, the healthcare provider may notify a third party that the patient is compliant.

[0027] Additionally, the "firmware" of an RT device may require upgrades from time to time, and the RT device may obtain upgrade files for such purposes from a remote server operated over a network by the device manufacturer.

[0028] There may be other aspects of a patient's care that benefit from communication between the patient's RT device and a remote server.

[0029] Securing such communications can be important for safety, compliance, and / or privacy reasons. For example, ensuring that only appropriate upgrades are sent and applied to the receiving RT device can help prevent tampering with the operation of the RT device. Similarly, being able to reliably communicate data generated within the device without tampering can help ensure the integrity of the compliance verification process. It is also desirable to ensure that data transfers of health-related information are limited to only intended or authorized recipients. Other benefits may become apparent from the following description of some aspects of the present technology. Summary of the Invention

[0030] 3. Brief description of the technology The present technology relates to the provision of medical devices for use in the diagnosis, amelioration, treatment or prevention of respiratory disorders, which medical devices have one or more of improved comfort, cost, effectiveness, ease of use and manufacturability.

[0031] Aspects of the present technology relate to devices used in the diagnosis, amelioration, treatment or prevention of respiratory disorders.

[0032] Aspects of the present technology allow for secure connection of respiratory treatment devices to a control device associated with an authorized user.

[0033] According to one form of the present technology, a control device obtains a first shared secret (e.g., a token) known to a respiratory therapy (RT) device through physical access to the RT device. The first shared secret is then used by both devices communicating over an insecure communication link to establish a relatively stronger, more secure second shared secret (e.g., a second, more complex token), thereby establishing a secure communication link between them. In the secure communication, the second shared secret is used in a strong encryption method.

[0034] Some versions of the present technology include a method of wirelessly communicating with a respiratory treatment device. The method may include a controlling device establishing an unsecured wireless communication link with the respiratory treatment device. The method may include the controlling device obtaining a first shared secret over a communication link different from the unsecured wireless communication link. The first shared secret may be known to the respiratory treatment device. The method may include the controlling device calculating a second shared secret using the first shared secret and data communicated over the unsecured wireless communication link. The second shared secret may be known to the respiratory treatment device and is stronger than the first shared secret. The method may include the controlling device communicating wirelessly with the respiratory treatment device based on the second shared secret.

[0035] In some versions of the method, computing the second shared secret may include a Diffie-Hellman key exchange. The method may include the controlling device computing a session key with the second shared secret. The method may include the controlling device using the session key to encrypt and decrypt data communicated with the respiratory treatment device over the wireless link. In some versions, establishing an unsecured wireless communication link may include the controlling device computing a symmetric key known to the respiratory treatment device. Obtaining the first shared secret over a different communication link may depend on physical access by the controlling device to the respiratory treatment device. Obtaining the first shared secret may include the controlling device scanning the first shared secret in machine-readable form printed on a housing of the respiratory treatment device. The machine-readable form may be a barcode. The barcode may be a QR code.

[0036] In some versions, obtaining the first shared secret includes receiving, by the controlling device, the first shared secret entered via a user interface of the controlling device. The method may include verifying, by the controlling device, that the second shared secret is known to the respiratory treatment device. In some versions, verifying may include computing a first hash value using the second shared secret, receiving the second hash value from the respiratory treatment device over an unsecured wireless communication link, and comparing the first hash value with the second hash value. The method may include generating a user output via a user interface of the controlling device if the first hash value is not equal to the second hash value. The second shared secret may be used to establish a secure wireless communication link between the controlling device and the respiratory treatment device. In some versions, the method may include computing a session key from the second shared secret. The method may include transmitting, by the controlling device over the secure wireless communication link, control parameters for controlling respiratory therapy operation of the respiratory treatment device. The control parameters may include one of a pressure setting and a flow setting. The method may include receiving, by the controlling device, data related to respiratory therapy operation of the respiratory treatment device over the secure wireless communication link, the data may include any one or more of a usage time of the respiratory treatment device and a plurality of respiratory events.

[0037] Some versions of the present technology may include a computer-readable data storage medium having program instructions encoded thereon configured to cause a processor to perform any of the method(s) described herein. Some versions of the present technology may include a server having access to such a computer-readable data storage medium. The server may be configured to receive a request to download the program instructions from the computer-readable data storage medium to a control device over a network. The server may transmit the program instructions in response to the request to download the program instructions.

[0038] Some versions of the present technology may include a control device configured to wirelessly communicate with a respiratory treatment device. The control device may include a memory that stores processing instructions. The control device may include a processor. The processor may be configured to establish an unsecured wireless communication link with the respiratory treatment device. The processor may be configured to obtain a first shared secret over a communication link different from the unsecured wireless communication link, the first shared secret being known to the respiratory treatment device. The processor may be configured to calculate a second shared secret using the first shared secret and data communicated over the unsecured wireless communication link. The second shared secret may be known to the respiratory treatment device and may be stronger than the first shared secret.

[0039] In some versions, the control device may include a barcode reader. The processor may be further configured to obtain the first shared secret by scanning a barcode printed on a housing of the respiratory treatment device with the barcode reader. The barcode may encode the first shared secret. In some versions, the control device may include a user interface. The processor may be further configured to obtain the first shared secret via input entered through the user interface.

[0040] Some versions of the present technology may include a method of wirelessly communicating between a respiratory treatment device and a controlling device. The method may include establishing an unsecured wireless communication link with the controlling device by the respiratory treatment device. The method may include computing a second shared secret by the respiratory treatment device using a first shared secret and data communicated over the unsecured wireless communication link. The first shared secret and the second shared secret may be known to the controlling device. The second shared secret may be stronger than the first shared secret. The method may include the respiratory treatment device wirelessly communicating with the controlling device based on the second shared secret.

[0041] Some versions of the present technology may include a respiratory treatment device configured to wirelessly communicate with a control device. The respiratory treatment device may include a memory that stores processing instructions. The respiratory treatment device may include a controller configured to establish an unsecured wireless communication link with the control device. The controller may be configured to calculate a second shared secret using a first shared secret and data communicated over the unsecured wireless communication link. The first shared secret and the second shared secret may be known to the control device. The second shared secret may be stronger than the first shared secret. The respiratory treatment device may include a housing including a printed barcode. The printed barcode may encode the first shared secret.

[0042] Some versions of the present technology may include a respiratory treatment system. The system may include a respiratory treatment device. The system may include a control device configured to wirelessly communicate with the respiratory treatment device. The control device may include a processor configured to establish an unsecured wireless communication link with the respiratory treatment device. The processor may be configured to obtain a first shared secret over a communication link different from the unsecured wireless communication link. The first shared secret may be known to the respiratory treatment device. The processor may be configured to calculate a second shared secret using the first shared secret and data communicated over the unsecured wireless communication link. The second shared secret may be known to the respiratory treatment device and may be stronger than the first shared secret. The processor may be configured to wirelessly communicate with the respiratory treatment device based on the second shared secret. The respiratory treatment device may include a housing having a printed barcode. The printed barcode may encode the first shared secret. The control device may further include a barcode reader. The processor may be further configured to obtain the first shared secret by scanning the barcode with the barcode reader. The control device may further include a user interface. The processor may be further configured to obtain the first shared secret via input entered through the user interface.

[0043] Another aspect of the present technology allows recipients to grant authorization to therapy data when it is uploaded from a respiratory therapy device to a remote server via an untrusted control device.

[0044] Another form of this technique involves using a secret known to both the RT device and the server (but not the control device) and a "nonce" provided by the server for derivation of a key (by the RT device) that is used to derive an authentication code for authenticating the treatment data.

[0045] Some versions of the present technology may include a method of uploading therapy data generated by a respiratory treatment device to a remote server via a controlling device configured to communicate with the respiratory treatment device and with the remote server. The method may include receiving, by the controlling device, the therapy data from the respiratory treatment device. The method may include receiving, by the controlling device, a nonce from the remote server. The method may include transmitting, by the controlling device, the nonce to the respiratory treatment device. The method may include receiving, by the controlling device, a signing key from the respiratory treatment device. The signing key may depend on the nonce and a secret known to the respiratory treatment device and the remote server. The method may include generating, by the controlling device, an authentication code using the therapy data and the signing key. The authentication code may be used to authenticate the therapy data. The method may include transmitting, by the controlling device, the therapy data and the authentication code to the remote server. In some versions, the authentication code may be a hashed message authentication code. The signing key may further depend on an offset into a shared secret. The offset may be received by the controlling device from the remote server. The nonce may be a pseudorandom number. In some versions, the controlling device may securely receive the signing key from the respiratory treatment device by decrypting the signing key with a symmetric key known to the respiratory treatment device.

[0046] Some versions of the present technology may include a control device. The control device may include a memory and a processor. The memory may include program instructions. When executed by the processor, the program instructions control the control device to upload therapy data generated by the respiratory treatment device to a remote server. The program instructions may control the control device to receive therapy data from the respiratory treatment device. The program instructions may control the control device to receive a nonce from the remote server. The program instructions may control the control device to send the nonce to the respiratory treatment device. The program instructions may control the control device to receive a signing key from the respiratory treatment device. The signing key may depend on the nonce and a secret known to the respiratory treatment device and the remote server. The program instructions may control the control device to generate an authentication code using the therapy data and the signing key. The authentication code may be used to authenticate the therapy data. The program instructions may control the control device to send the therapy data and the authentication code to the remote server.

[0047] Some versions of the present technology may include a method for authenticating treatment data generated by a respiratory treatment device. The method may include receiving the treatment data and a first authentication code. The method may include computing a signing key from a nonce and a secret known to the respiratory treatment device. The method may include computing a second authentication code from the received treatment data and the signing key. The method may include authenticating the treatment data by comparing the first authentication code with the second authentication code.

[0048] In some versions, the method may include transmitting the offset to the respiratory treatment device. The signing key may depend on the offset. The authentication code may be a hashed message authentication code. The method may include transmitting a nonce to the respiratory treatment device. The nonce may be a pseudorandom number.

[0049] Some versions of the present technology may include a server. The server may include a memory and a processor. The memory may include program instructions. When executed by the processor, the program instructions control the server to authenticate therapy data generated by the respiratory treatment device. The program instructions may include controlling the server to receive the therapy data and a first authentication code. The program instructions may include computing a signing key from a nonce and a secret known to the respiratory treatment device. The program instructions may compute a second authentication code from the received therapy data and the signing key. The program instructions may authenticate the therapy data by comparing the first authentication code with the second authentication code.

[0050] Some versions of the present technology may include a networked respiratory treatment system. The system may include a respiratory treatment device configured to deliver respiratory treatment to a patient. The system may include a remote server. The system may include a control device configured to communicate with the respiratory treatment device and with the remote server. The control device may be configured to receive treatment data from the respiratory treatment device by the control device. The control device may be configured to receive a nonce from the remote server by the control device. The control device may be configured to transmit the nonce to the respiratory treatment device. The control device may be configured to receive a signing key from the respiratory treatment device. The signing key may depend on the nonce and a secret known to the respiratory treatment device and the remote server. The control device may be configured to generate an authentication code using the treatment data and the signing key. The authentication code may be used to authenticate the treatment data. The control device may be configured to transmit the treatment data and the authentication code to the remote server. In some versions, the respiratory treatment device may be a respiratory pressure treatment device. The control device may be configured to securely communicate with the respiratory treatment device using a shared symmetric key. The remote server may be configured to receive the treatment data and the first authentication code. The remote server may be configured to compute a signing key from the nonce and a secret known to the respiratory treatment device. The remote server may be configured to compute a second authentication code from the received treatment data and the signing key. The remote server may be configured to authenticate the treatment data by comparing the first authentication code with the second authentication code.

[0051] Some versions of the present technology may include a networked respiratory treatment system. The networked respiratory treatment system may include a respiratory treatment device configured to deliver respiratory treatment to a patient. The networked respiratory treatment system may include a controlling device configured to communicate with the respiratory treatment device. The networked respiratory treatment system may include a remote server configured to communicate with the controlling device. The remote server may be configured to receive treatment data and a first authentication code from the controlling device. The remote server may be configured to compute a signing key from a nonce and a secret known to the respiratory treatment device. The remote server may be configured to compute a second authentication code from the received treatment data and the signing key. The remote server may be configured to authenticate the treatment data by comparing the first authentication code with the second authentication code. The respiratory treatment device may be a respiratory pressure treatment device. The controlling device may be configured to securely communicate with the respiratory treatment device using a shared symmetric key. The controlling device may be configured to receive treatment data from the respiratory treatment device. The controlling device may be configured to receive a nonce from the remote server. The controlling device may be configured to transmit the nonce to the respiratory treatment device. The controlling device may be configured to receive a signing key from the respiratory treatment device. The signing key may depend on a nonce and a secret known to the respiratory treatment device and the remote server. The controlling device may be configured to generate an authentication code using the treatment data and the signing key. The authentication code may be used to authenticate the treatment data. The controlling device may be configured to transmit the treatment data and the authentication code to the remote server.

[0052] In some versions, the respiratory treatment device may be configured to receive a nonce from the remote server. The respiratory treatment device may be configured to compute a signing key from the nonce and a secret known to the respiratory treatment device and the remote server. The respiratory treatment device may be configured to generate an authentication code using the treatment data and the signing key. The respiratory treatment device may be configured to transmit the treatment data and the authentication code to the remote server.

[0053] Some versions of the present technology may include a method of uploading therapy data generated by a respiratory treatment device to a remote server. The method may include receiving a nonce from the remote server by the respiratory treatment device. The method may include computing, by the respiratory treatment device, a signing key from the nonce and a secret known to the remote server. The method may include generating, by the respiratory treatment device, an authentication code using the therapy data and the signing key. The authentication code is used to authenticate the therapy data. The method may include transmitting the therapy data and the authentication code from the respiratory treatment device to the remote server. The authentication code may be a hashed message authentication code. The signing key may further depend on an offset into the shared secret. The offset may be received by the respiratory treatment device from the remote server. The nonce may be a pseudorandom number. The respiratory treatment device may receive the nonce via a control device configured to communicate with the remote server. The respiratory treatment device may receive the nonce from the control device by decrypting the nonce using a symmetric key known to the control device. The respiratory treatment device may transmit the therapy data and the authentication code via a control device configured to communicate with the remote server. The controlling device may transmit the treatment data and the authentication code to the controlling device by encrypting the treatment data and the authentication code with a symmetric key known to the controlling device.

[0054] Some versions of the present technology may include a respiratory treatment device. The respiratory treatment device may include a pressure generator. The pressure generator is adapted to couple to a patient interface and provide a positive pressure airflow to the patient interface. The respiratory treatment device may include a memory and a processor. The memory may include program instructions. When executed by the processor, the program instructions control the respiratory treatment device to upload therapy data generated by the respiratory treatment device to a remote server. The program instructions may control the respiratory treatment device to receive a nonce from the respiratory treatment device remote server. The program instructions may control the respiratory treatment device to compute a signing key from the nonce and a secret known to the remote server. The program instructions may control the respiratory treatment device to generate an authentication code using the therapy data and the signing key. The authentication code may be used to authenticate the therapy data. The program instructions may control the respiratory treatment device to transmit the therapy data and the authentication code to the remote server.

[0055] Some versions of the present technology may include a networked respiratory treatment system. The networked respiratory treatment system may include a respiratory treatment device for administering respiratory treatment to a patient. The networked respiratory treatment system may include a remote server configured to communicate with the respiratory treatment device. The respiratory treatment device may be configured to receive a nonce from the remote server. The respiratory treatment device may be configured to compute a signing key from the nonce and a secret known to the remote server. The respiratory treatment device may be configured to generate an authentication code using the treatment data and the signing key. The authentication code may be used to authenticate the treatment data. The respiratory treatment device may be configured to transmit the treatment data and the authentication code to the remote server. The respiratory treatment device may be a respiratory pressure treatment device. In some versions, the networked respiratory treatment system may include a control device configured to securely communicate with the respiratory treatment device and to communicate with the remote server. The control device may be configured to securely communicate with the respiratory treatment device using a symmetric key known to the respiratory treatment device. The remote server may be configured to receive the treatment data and a first authentication code. The remote server may be configured to compute a signing key from the nonce and a secret known to the respiratory treatment device. The remote server can be configured to compute a second authentication code from the received treatment data and the signing key. The remote server can be configured to authenticate the treatment data by comparing the first authentication code with the second authentication code.

[0056] Some versions of the present technology may include an apparatus having means for receiving therapy data from a respiratory treatment device. The apparatus may include means for receiving a nonce from a remote server and means for transmitting the nonce to the respiratory treatment device. The apparatus may include means for receiving a signing key from the respiratory treatment device. The signing key depends on the nonce and a secret known to the respiratory treatment device and the remote server. The apparatus may include means for generating an authentication code using the therapy data and the signing key. The authentication code is used to authenticate the therapy data. The apparatus may include means for transmitting the therapy data and the authentication code to the remote server.

[0057] Some versions of the present technology may include an apparatus having apparatus means for receiving therapy data from a respiratory treatment device and a first authentication code. The apparatus may include means for computing a signing key from a nonce and a secret known to the respiratory treatment device. The apparatus may include means for computing a second authentication code from the received therapy data and the signing key. The apparatus may include means for authenticating the therapy data by comparing the first authentication code with the second authentication code.

[0058] Some versions of the present technology may include a device having means for delivering respiratory therapy to a patient. The device may include means for receiving a nonce from a remote server. The device may include means for computing a signing key from the nonce and a secret known to the remote server. The device may include means for generating an authentication code using the treatment data and the signing key. The authentication code is used to authenticate the treatment data. The device may include means for transmitting the treatment data and the authentication code to the remote server.

[0059] The methods, systems, devices, and apparatus described herein may enable improved functionality in processors (e.g., processors of special purpose computers, respiratory monitors, and / or respiratory treatment devices). Additionally, the described methods, systems, devices, and apparatus enable improvements in the field of automated management, monitoring, and / or treatment of respiratory disorders (e.g., obstructive sleep apnea) and related device communications.

[0060] Of course, some of the above aspects may form sub-aspects of the present technology, and various sub-aspects and / or aspects may be combined in various ways to form further aspects or sub-aspects of the present technology.

[0061] Other features of the present technology will become apparent in light of the information contained in the following detailed description, abstract, drawings, and claims. [Brief explanation of the drawings]

[0062] The present technology is illustrated by way of example and not limitation in the accompanying drawings, in which like reference numerals include like elements:

[0063] [Figure 1] 1 shows a system including a patient 1000 wearing a patient interface 3000, which takes the form of nasal pillows and receives air at positive pressure supplied by an RT device 4000. The air from the RT device 4000 is humidified by a humidifier 5000 and travels along an air circuit 4170 to the patient 1000. A bed companion 1100 is also shown. [Figure 2] 4.2 Respiratory System and Facial Anatomy Figure 2 shows an overview of the human respiratory system, including the nose and oral cavity, larynx, vocal folds, esophagus, trachea, bronchi, lungs, alveolar sacs, heart, and diaphragm. [Figure 3] 4.3 Patient Interface FIG. 3 shows a patient interface in the form of a nasal mask in accordance with one form of the present technology. [Figure 4A]4.4 RT Device FIG. 4A illustrates an RT device in accordance with one aspect of the present technology. [Figure 4B] 4B is a schematic diagram of the air pressure paths of an RT device 4000 in accordance with one form of the present technology, with upstream and downstream directions indicated. [Figure 4C] FIG. 4C is a schematic diagram of the electrical components of an RT device 4000 in accordance with one aspect of the present technology. [Figure 5A] 4.5 Humidifier FIG. 5A is an isometric view of a humidifier in accordance with one form of the present technology. [Figure 5B] FIG. 5B is an isometric view of a humidifier in accordance with one form of the present technology, showing the humidifier reservoir 5110 removed from the humidifier reservoir dock 5130. [Figure 6] 4.6 Secure Networked Respiratory Treatment System FIG. 6 is a schematic diagram of a networked respiratory treatment system in accordance with one form of the present technology. [Figure 7] FIG. 7 is a flowchart illustrating a method by which a control device and an RT device may establish a secure communication link therebetween, in accordance with one aspect of the present technology. [Figure 8] FIG. 8 is a flowchart illustrating methods that the RT device and the control device may each perform (to perform their respective roles in the method of FIG. 7 in accordance with one aspect of the present technology). [Figure 9] FIG. 9 is a schematic diagram of a method that may be performed by the networked respiratory treatment system of FIG. 6 to secure firmware upgrades to RT devices in accordance with one form of the present technology. [Figure 10] FIG. 10 is a schematic diagram of a method that may be performed by the networked respiratory treatment system of FIG. 6 to authenticate treatment data upload to a server in accordance with one form of the present technology. [Figure 11] FIG. 11 is a schematic diagram of a method that may be performed by the networked respiratory treatment system of FIG. 6 to authenticate treatment data upload to a server in accordance with another form of the present technology. DETAILED DESCRIPTION OF THE INVENTION

[0064] 5 Detailed Description of the Embodiments of the Present Technology Before describing the present technology in further detail, it is to be understood that the present technology is not limited to the specific embodiments described herein, which may vary. It is also to be understood that the terminology used in the present disclosure is for the purpose of describing the specific embodiments described herein, and is not intended to be limiting.

[0065] The following description is provided in connection with various embodiments that may share one or more common characteristics and / or features. It should be understood that one or more features of any one embodiment may be combined with one or more features of another embodiment or other embodiments. In addition, any single feature or combination of features in any of these embodiments may constitute an additional embodiment.

[0066] 5.1 Treatment In one form, the present technology includes a method of treating a respiratory disorder, the method including applying a positive pressure airflow to the entrance of the airways of a patient 1000.

[0067] 5.2 Respiratory Treatment Systems In one form, the present technology includes a respiratory treatment system for the treatment of respiratory disorders. The respiratory treatment system may include a RT device 4000 that delivers a flow of air at positive pressure to a patient 1000 via an air circuit 4170 to a patient interface 3000.

[0068] 5.3 Patient Interface A non-invasive patient interface 3000 in accordance with one aspect of the present technology includes the following functional features: a seal-forming structure 3100, a plenum chamber 3200, a positioning and stabilizing structure 3300, a vent 3400, a form of connection port 3600 for connection to an air circuit 4170, and a forehead support 3700. In some forms, the functional features may be provided by one or more physical components. In some forms, a single physical component may provide one or more functional features. In use, the seal-forming structure 3100 is positioned to surround the entrance to the patient's airways to facilitate the delivery of air at positive pressure to the airways.

[0069] 5.4 RT Devices An RT device 4000 according to one aspect of the present technology may include mechanical, pneumatic, and / or electrical components and may be configured to execute one or more algorithms (e.g., any of the methods described herein, in whole or in part). The RT device 4000 may be configured to deliver a flow of air at positive pressure to an entrance to a patient's airways for the treatment of, for example, one or more of the respiratory disorders described anywhere herein.

[0070] The RT device may have an external housing 4010. The external housing 4010 is formed by two portions: an upper portion 4012 and a lower portion 4014. Additionally, the external housing 4010 may include one or more panel(s) 4015. The RT device 4000 includes a chassis 4016 that supports one or more internal components of the RT device 4000. The RT device 4000 may include a handle 4018.

[0071] The air pressure path of the pneumatic RT device 4000 may include one or more air circuit items (e.g., an inlet air filter 4112, an inlet muffler 4122, a pressure generator 4140 (e.g., a blower 4142) capable of supplying air at positive pressure, an outlet muffler 4124) and one or more transducers 4270 (e.g., a pressure sensor 4272 and a flow sensor 4274).

[0072] One or more of the air path items may be disposed within a removable, unitary structure called a pneumatic block 4020. The pneumatic block 4020 may be disposed within the outer housing 4010. In one form, the pneumatic block 4020 is supported by or formed as part of the chassis 4016.

[0073] The RT device 4000 can have a power supply 4210, one or more input devices 4220, a central controller 4230, a therapy device controller 4240, a pressure generator 4140, one or more protection circuits 4250, a memory 4260, a transducer 4270, a data communication interface 4280, and one or more output devices 4290. The electrical components 4200 can be mounted on a single printed circuit board assembly (PCBA) 4202. In one alternative, the RT device 4000 can include more than one PCBA 4202.

[0074] 5.4.1 RT Devices Mechanical and Pneumatic Components An RT device may include one or more of the following components in an integral unit: In an alternative, one or more of the following components may be located as their own separate units.

[0075] 5.4.1.1 Air filter(s) An RT device in accordance with one form of the present technology may include an air filter 4110 or multiple air filters 4110.

[0076] In one form, the inlet air filter 4112 is located at the beginning of the air pressure path upstream of the pressure generator 4140 .

[0077] In one form, an outlet air filter 4114 (eg, an antibacterial agent) is located between the outlet of the pneumatic block 4020 and the patient interface 3000.

[0078] 5.4.1.2 Muffler(s) An RT device in accordance with one form of the present technology may include a muffler 4120 or multiple mufflers 4120.

[0079] In one form of the present technology, an inlet muffler 4122 is positioned above a pressure generator 4140 in the pneumatic path.

[0080] In one form of the present technology, the outlet muffler 4124 is positioned in the pneumatic path between the pressure generator 4140 and the patient interface 3000.

[0081] 5.4.1.3 Pressure generator In one form of the present technology, the pressure generator 4140 that generates the air flow or supply at positive pressure is a controllable blower 4142. For example, the blower 4142 may include a brushless DC motor 4144 with one or more impellers housed within a volute. The blower may deliver the air supply at a rate of, for example, up to about 120 liters / minute, at a positive pressure ranging from about 4 cmH2O to about 20 cmH2O, or in other forms up to about 30 cmH2O. The blower may be described in any one of the following patents or patent applications, which are incorporated herein by reference in their entirety: U.S. Patent No. 7,866,944; U.S. Patent No. 8,638,014; U.S. Patent No. 8,636,479; and PCT Patent Application Publication WO 2013 / 020167.

[0082] The pressure generator 4140 is under the control of the therapy device controller 4240 .

[0083] In other forms, pressure generator 4140 can be a piston-driven pump, a pressure regulator connected to a high pressure source (eg, a compressed air reservoir), or a bellows.

[0084] 5.4.1.4 Transducer(s) The transducer may be internal to the RT device or external to the RT device. An external transducer may, for example, be located on the air circuit or form part of the air circuit (e.g., a patient interface). An external transducer may take the form of a non-contact sensor (e.g., a Doppler radar motion sensor that transmits or moves data to the RT device).

[0085] In one form of the present technology, one or more transducers 4270 may be positioned upstream and / or downstream of the pressure generator 4140. The one or more transducers 4270 may be constructed and arranged to generate a signal indicative of a characteristic of the airflow (e.g., flow rate, pressure, or temperature at that point in the pneumatic path).

[0086] In one form of the present technology, one or more transducers 4270 may be positioned proximate the patient interface 3000.

[0087] In one form, the signal from the converter 4270 may be filtered (eg, by low-pass, high-pass, or band-pass filtering).

[0088] 5.4.1.4.1 Flow Sensor A flow sensor 4274 according to the present technology may be based on a differential pressure transducer (eg, SDP600 series differential pressure transducers from SENSIRION).

[0089] In one form, a signal indicative of the flow rate from the flow sensor 4274 is received by the central controller 4230.

[0090] 5.4.1.4.2 Pressure Sensor A pressure sensor 4272 according to the present technology can be placed in fluid communication with the pneumatic path. One example of a suitable pressure sensor is a transducer from the HONEYWELL ASDX series. Another suitable pressure sensor is a transducer from the NPA series from GENERAL ELECTRIC.

[0091] In one form, the signal from the pressure sensor 4272 may be received by the central controller 4230.

[0092] 5.4.1.4.3 Motor Speed Converter In one form of the present technology, a motor speed transducer 4276 may be used to determine the rotational speed of the motor 4144 and / or blower 4142. A motor speed signal from the motor speed transducer 4276 may be provided to the therapy device controller 4240. The motor speed transducer 4276 may be, for example, a speed sensor (e.g., a Hall effect sensor).

[0093] 5.4.1.5 Anti-spillback valves In one form of the present technology, an anti-spillback valve 4160 may be located between the humidifier 5000 and the pneumatic block 4020. The anti-spillback valve is constructed and positioned to reduce the risk of water flowing upstream from the humidifier 5000 (e.g., to the blower motor 4144).

[0094] 5.4.2 RT Device Electrical Components 5.4.2.1 Power supply The power supply 4210 can be located inside or outside the external housing 4010 of the RT device 4000 .

[0095] In one form of the present technology, the power supply 4210 powers only the RT device 4000. In another form of the present technology, power is provided from the power supply 4210 to both the RT device 4000 and the humidifier 5000.

[0096] 5.4.2.2 Input Devices In one form of the present technology, the RT device 4000 includes an input device 4220 to allow the patient to interact with the device. In one such form, the input device 4220 includes one or more buttons, switches, or dials.

[0097] 5.4.2.3 Central Control Unit In one form of the present technology, the central controller 4230 is one or more processors suitable for controlling the RT device 4000 .

[0098] Suitable processors may include x86 INTEL processors, processors based on the ARM® Cortex®-M processor from ARM Holdings (e.g., the S®32 series of microcontrollers from ST Micro Electronics). In certain alternative forms of the present technology, 32-bit RISC CPUs (e.g., the STR9 series microcontrollers from ST Micro Electronics) or 16-bit RISC CPUs (e.g., processors from the MSP430 family of microcontrollers manufactured by Texas Instruments) may also be suitable.

[0099] In one form of the present technology, the central controller 4230 is a dedicated electronic circuit.

[0100] In one form, the central controller 4230 is an application specific integrated circuit. In another form, the central controller 4230 includes discrete electronic components.

[0101] The central controller 4230 may be configured to receive input signals from one or more transducers 4270, one or more input devices 4220 and the humidifier 5000.

[0102] The central controller 4230 may be configured to provide output signal(s) to one or more of the output device 4290, the therapy device controller 4240, the data communication interface 4280, and the humidifier 5000.

[0103] In some forms of the present technology, the central controller 4230 is configured to implement one or more methods described herein (e.g., one or more algorithms expressed as a computer program or "firmware" stored in a non-transitory computer-readable recording medium (e.g., memory 4260)). For example, one algorithm may detect a patient's respiratory events during respiratory therapy.

[0104] 5.4.2.4 Clock The RT device 4000 may include a clock 4232 connected to the central controller 4230 .

[0105] 5.4.2.5 Therapy Device Controller In one form of the present technology, the therapy device controller 4240 is a therapy control module and forms part of the algorithm executed by the central controller 4230.

[0106] In one form of the present technology, the therapy device controller 4240 is a dedicated motor control integrated circuit. For example, in one form, the MC33035 brushless DC motor controller manufactured by ONSEMI is used.

[0107] 5.4.2.6 Protection circuit The one or more protection circuits 4250 according to the present technology may include electrical protection circuits, temperature and / or pressure safety circuits.

[0108] 5.4.2.7 Memory In accordance with one form of the present technology, the RT device 4000 includes memory 4260 (e.g., non-volatile memory). In some forms, the memory 4260 may include battery-powered static RAM. In some forms, the memory 4260 may include volatile RAM.

[0109] Memory 4260 may be located on PCBA 4202. Memory 4260 may take the form of EEPROM or NAND flash.

[0110] Additionally or alternatively, the RT device 4000 includes removable memory 4260 (eg, a memory card made according to the Secure Digital (SD) standard).

[0111] In one form of the present technology, memory 4260 functions as a non-transitory computer-readable storage medium on which computer program instructions embodying one or more of the methods described herein (e.g., one or more algorithms described above) are recorded.

[0112] 5.4.2.8 Communications In one form of the present technology, a data communications interface 4280 is provided and connected to the central controller 4230. The data communications interface 4280 may be connectable to a remote external communications network 4282 and / or a local external communications network 4284. The remote external communications network 4282 may be connectable to a remote external device 4286. The local external communications network 4284 may be connectable to a local external device 4288. The local external communications network 4284 may be wired or wireless.

[0113] In one form, the data communication interface 4280 is part of the central controller 4230. In another form, the data communication interface 4280 is separate from the central controller 4230 and may include an integrated circuit or processor.

[0114] 5.4.2.9 Output Device An output device 4290 in accordance with the present technology may take the form of one or more of a visual, audio, and tactile unit. In one form, the output device 4290 may include an LED or the like.

[0115] The output device 4290 and the input device 4220 may collectively be referred to as the user interface of the RT device 4000.

[0116] 5.5 Air Circuit An air circuit 4170, in accordance with one aspect of the present technology, is a conduit or tube constructed and arranged such that, in use, air flow travels between two components (eg, the RT device 4000 and the patient interface 3000).

[0117] 5.6 Humidifier In one form of the present technology, a humidifier 5000 is provided (for example as shown in FIG. 5A) for changing the absolute humidity of air or gas to be delivered to a patient relative to ambient air. Typically, the humidifier 5000 is used to increase the absolute humidity (relative to ambient air) and increase the temperature of the air stream before delivery to the patient's airways.

[0118] The humidifier 5000 may include a humidifier reservoir 5110, a humidifier inlet 5002 for receiving an airflow, and a humidifier outlet 5004 for delivering a humidified airflow. In some forms, such as shown in Figures 5A and 5B, the inlet and outlet of the humidifier reservoir 5110 may be the humidifier inlet 5002 and the humidifier outlet 5004, respectively. The humidifier 5000 may further include a humidifier base 5006. The humidifier base 5006 may be adapted to receive the humidifier reservoir 5110 and may include a heating element 5240.

[0119] 5.7 Secure Networked Respiratory Care 6 is a schematic diagram of a networked respiratory treatment system 6000 shown with several external entities, in accordance with one form of the present technology. The system includes an RT device 4000. The RT device 4000 is configured to deliver a flow of air at positive pressure to a patient 1000 via an air circuit 4170 to a patient interface 3000 as shown in FIG.

[0120] The RT device 4000 communicates with a control device 6010 via a wireless connection 6015. The control device 6010 is associated with the patient 1000. The control device 6010 may correspond to the local external device 4288 in FIG. 4C , and the wireless connection 6015 may correspond to the local external communication network 4284. The control device 6010 is a control device for the RT device 4000 (e.g., a dedicated “remote control” or a general-purpose computing device configured by running a special-purpose software application or “app”). Such a software application may be downloaded by the control device 6010 from a server (e.g., a web server) over a network (e.g., an intranet or the Internet). The control device 6010 may be portable. In some forms, the wireless connection 6015 uses one or more wireless communication protocols (e.g., Bluetooth or Bluetooth LE, NFC, or consumer infrared protocol). Thus, the wireless connection 6015 may use short-range or low-energy networking (which may be a direct link between the control device and the RT device).

[0121] 6 also shows a second control device 6020 communicating with the RT device 4000 via a wireless connection 6025. However, the second control device 6020 does not form part of the respiratory treatment system 6000. If the wireless connection 6025 uses the same protocol as the wireless connection 6015, a criminal 6030 in possession of the second control device 6020 could compromise the security of the wireless connection 6015 between the control device 6010 and the RT device 4000 via the second control device 6020. For this reason, the second control device 6020 may be referred to as an unauthorized control device 6020. Arrangements for securing the wireless connection 6015 against various threats posed by the unauthorized control device 6020 are described in more detail below.

[0122] The networked respiratory treatment system 6000 also includes a remote server 6040 that communicates with the controlling device 6010 via a wireless connection 6050. The remote server 6040 may be accessible to the controlling device (e.g., the controlling device 6010) through one or more networks (e.g., the Internet or the Internet) via the wireless connection 6050. Thus, the wireless connection 6050 may serve as an indirect networking link to the remote server. Examples of such wireless networking include a Wi-Fi network, a Bluetooth network, and a wireless cellular network (e.g., a Global System for Mobile Communication (GSM) network). Thus, the wireless connection 6050 may use longer-range wireless communication than the wireless connection 6015. The controlling device 6010 may be configured to act as an intermediary between the RT device 4000 and the remote server 6040. The networked respiratory treatment system 6000 may include other RT devices (not shown). Each of these other RT devices (not shown) is controlled by a corresponding control device (not shown) and communicates with the server 6040 via a corresponding wireless connection (not shown), such that the server 6040 is configured to function as multiple RT devices 4000 without confusion between these devices.

[0123] The RT device 4000 may be configured to transmit data related to respiratory therapy (e.g., usage time, number of respiratory events, or compliance rule evaluation results) to the controlling device 6010 via connection 6015. Such therapy data may then be uploaded from the controlling device 6010 to the server 6040 via connection 6050. The controlling device 6010 may be configured to transmit control parameters related to respiratory therapy (e.g., compliance rules) to the RT device 4000 via connection 6015. Such control parameters may be downloaded by the controlling device 6010 from the server 6040 via connection 6050. The controlling device 6010 may also be configured to transmit upgrades to the RT device 4000 firmware via connection 6015. Such upgrades may be downloaded by the controlling device 6010 from the server 6040 via connection 6050.

[0124] FIG. 6 also shows that computing device 6060 communicates with server 6040 via wireless connection 6070. However, computing device 6060 does not form part of networked respiratory treatment system 6000. Additionally, computing device 6060 is referred to as an unassociated (control) device because it does not communicate with an RT device. If wireless connection 6070 utilizes the same protocol as wireless connection 6050 and unassociated device 6060 runs a “spoofed” version of the app running on control device 6010 (to make server 6040 appear to be the legitimate control device 6010), a criminal 6065 in possession of unassociated device 6060 could potentially compromise the operation of networked respiratory treatment system 6000 (particularly server 6040) via unassociated device 6060. Arrangements for securing server 6040 against various threats posed by unassociated devices 6060 are described in more detail below.

[0125] A third category of threat to the networked respiratory treatment system 6000 occurs when a controlling device 6010 communicating with an RT device 4000 is under the control of a criminal (not shown). The criminal installs a “spoofed” version of an app on the controlling device 6010 that is running on an authorized controlling device. This spoofed version attempts to appear to the server 6040 and / or the RT device 4000 as the authorized controlling device for illicit purposes. Such a controlling device 6010 is therefore referred to as a “spoofed” controlling device. In other words, the server 6040 cannot be sure that any controlling device 6010 communicating with it has not been “spoofed” and must therefore treat any controlling device 6010 in the networked respiratory treatment system 6000 as untrustworthy. Arrangements for securing the server 6040 against the various threats posed by such spoofed controlling devices 6010 are described in more detail below.

[0126] 5.7.1 RT Device and Control Device As described above, it is desirable to prevent a security breach of the wireless communication 6015 between the RT device 4000 and the control device 6010 by an unauthorized control device 6020. It is also desirable to minimize the complexity of establishing a secure communication link between the control device 6010 and the RT device 4000. Furthermore, it is necessary to enable a secure communication link to be established on the RT device 4000 using what may be considered a very limited user interface. The input device 4220 of the RT device 4000 may consist of a single button, and the output device 4290 of the RT device 4000 may consist of a single LED. However, this method of establishing a communication link should also be available on RT devices with more sophisticated user interfaces.

[0127] A communication link between two devices can be secured by using a symmetric key, known to both devices but unknown to the other, to encrypt and decrypt communications between the two devices. The security of the communication link is directly related to the "strength" of the symmetric key cryptography. Strength is roughly equal to the number of possible key values and the entropy, or randomness, of the values chosen. Generally, for a key where the probability of any value occurring is the same for all possible values, the greater the number of possible values, the greater the entropy and strength of the key. One difficulty in establishing such a secure communication link is creating a symmetric key known to both devices and keeping it secret from unauthorized control devices (e.g., 6020) that may be able to eavesdrop on unencrypted communications between the two devices.

[0128] 7 is a flowchart illustrating a method 7000 that may be used by a control device 6010 and an RT device 4000 to establish a secure communication link between them in accordance with one form of the present technology. That is, the controller or processor of the control device 6010 and / or the RT device 4000 may be configured (e.g., programmed) to perform the method as described herein, for example, in connection with FIGS. 7 and 8.

[0129] Method 7000 begins at step 7010. In step 7010, the control device 6010 and the RT device 4000 establish a communication link between them. This step may be initiated by some input activation on the user interface of the RT device 4000 (e.g., pressing a button 4220 forming part of the user interface of the RT device 4000). The RT device 4000 may be configured to limit or allow the availability of such activation input to any one or more of the patient, clinician, or authorized technician (e.g., a technician from a medical equipment provider). The LED 4290 also forms part of the user interface of the RT device 4000 and may force light on or off to indicate that the RT device 4000 is ready to connect to a control device. Such an initiating action results in disconnection of any control device currently connected to the RT device 4000. Thus, any existing control-related communication link with the RT device 4000 is terminated by the RT device 4000.

[0130] In an implementation of method 7000 in which the wireless protocol used is a standard communication protocol (e.g., Bluetooth), in response to a user initiation action, the RT device 4000 enters a “discoverable” mode. That is, devices that support the protocol (e.g., Bluetooth) can pair with the RT device as part of step 7010. In one such implementation, the devices are configured to establish a symmetric key-encrypted communication link between them (e.g., by using the Just Works association model of the Simple Pairing feature of the Lisbon release of the Bluetooth Core Specification [1]). Each device can then encrypt and decrypt communications using the shared symmetric key. Simple pairing provides protection against passive eavesdropping attacks equivalent to that of legacy Bluetooth 2.0+EDR (and earlier) pairing, except that the latter uses a 16-character, case-sensitive alphanumeric PIN (approximately 95 bits of entropy). This provides the advantage of being significantly easier to use. Under the Simple Pairing Just Works association model, the user need only accept the pairing by selecting "Yes" for a "Yes / No" control on the controlling device's user interface 6010. Just Works is particularly suited to RT devices with the simplest user interfaces, consisting of a single button 4220 and LED 4290, because such devices may not be able to display arbitrary alphanumeric codes as required for the Simple Pairing Numeric Comparison association model. In other implementations of step 7010 (including those in which the wireless protocol used is Bluetooth), the communication link established by step 7010 is unencrypted (i.e., a "clear" communication link).

[0131] As a result of step 7010, both devices have access to the communication line for two-way communication between them. LED 4290 may indicate the completion of step 7010 by continuously illuminating. If the communication line is unencrypted, it is considered insecure due to the risk of passive eavesdropping.

[0132] An active unauthorized control device (e.g., 6020) may discover the RT device 4000 when in discoverable mode and pair with the RT device 4000 via the Just Works association model, thereby denying service to the control device 6010.

[0133] To reduce this possibility, in some implementations, the effect of the user action initiating step 7010 may be time-limited (e.g., within a "discoverability window"). In such implementations, the RT device 4000 may only be discoverable within the discoverability window (e.g., 62 seconds long). Outside the discoverability window, the RT device 4000 becomes undiscoverable to all devices communicating with it via standard protocols (e.g., Bluetooth devices). This may be indicated by the extinguishing of the LED 4290. As a result, the period during which an unauthorized control device (e.g., 6020) may attempt to deny service to the RT device 4000 is limited to the short interval during which the control device 6010 is also actively attempting to pair with the RT device 4000.

[0134] If an unauthorized control device 6020 does succeed in pairing with the RT device 4000, the control device 6010 can detect this situation by failing to complete its own pairing within a certain predetermined time limit. The control device 6010 can communicate this failure to the user and prompt the user to repeat the initiating action (e.g., pressing the button 4220 on the RT device 4000). This initiating action results in all control devices paired with the RT device 4000 being disconnected, as described above. In one implementation, the discoverability window can last longer for second and subsequent pairing attempts than for the first pairing attempt.

[0135] A more serious threat than denial of service is the situation in which an unauthorized control device 6020 could become a "MITM" (undetected by either device 6010 or 4000) during the discoverability window. A umpire attack occurs when the unauthorized control device 6020 poses as the other device to each device in a Bluetooth pairing operation. The unauthorized control device 6020 then relays information between these two devices, giving each device the illusion that the two devices are directly paired, and computes a symmetric key. Thus, after learning the symmetric key, the unauthorized control device 6020 may be able to eavesdrop on the communication line between these two devices and insert and modify information on the communication line (this is known as "active eavesdropping"). Thus, even if a symmetric key is exchanged or shared between the RT device 4000 and the control device 6010, the communication link established by step 7010 is considered insecure, at least with respect to active eavesdropping (even when using the Just Works Simple Pairing and / or "discoverable window" options described above).

[0136] Referring to method 7000, after the control device 6010 successfully establishes an unsecured communication link with the RT device 4000 in step 7010, the RT device 4000 may be unable to be discovered by other devices communicating via standard protocols. Next, steps 7020 and 7030 may be performed to reduce the risk of passive and active eavesdropping. In steps 7020 and 7030, a first shared secret (e.g., a token) is established and converted to a second shared secret (e.g., a second, more complex token that is stronger than the first shared secret) via communication over the unsecured communication link. Because the first shared secret may be known to an unauthorized control device (e.g., 6020), it cannot be the symmetric key established in step 7010 or be derived from step 7010. Thus, the purpose of step 7020 is to establish the first shared secret using a communication link different from the unsecured communication link established in step 7010.

[0137] A significant common difference between the control device 6010 and the unauthorized control device 6020 is that the former has physical access to the RT device 4000, while the latter does not. In step 7020, this difference is utilized to establish a first shared secret between the control device 6010 and the RT device 4000. Such a first secret may be predetermined, for example, by a manufacturer, allowing the RT device 4000 to distribute the first secret to, for example, a user. Thus, a controller within the RT device 4000 may be preprogrammed (e.g., with the first secret) to distribute based on the first secret. Once such a first secret is obtained for / by the control device 6010, it becomes shared. The first secret may be obtained by the control device 6010 via a communication line or medium (e.g., communication line 6013 in FIG. 6 ) different from the insecure communication line established between the control device 6010 and the RT device 4000 in step 7010. For example, in step 7020, the control device 6010 obtains a token or a master key known to the RT device 4000 via the different communication channel 6013. The token or master key may be considered a first shared secret. The master key may be different and randomized for each RT device 4000 originating from a single manufacturer. The different communication channel 6013 may be referred to as an "out-of-band" mechanism. Some implementations of step 7020 may utilize physical access from the control device 6010 to the RT device 4000. Other such "different communication channel" transfers may also be used in step 7020 (e.g., via telephone, mail, user / instruction manual, access to manufacturer website, or other distributed material specific to the particular RT device 4000 (e.g., from the manufacturer)).

[0138] Next, in step 7030, the control device 6010 and the RT device 4000 establish a second shared secret using the token or secret key and an exchange of information (e.g., key exchange) over an unsecured communication line. Thus, one or both devices may independently generate a second shared secret from (1) the first shared secret that was not communicated over the unsecured communication line and (2) the exchanged information that was not communicated over the unsecured communication line. This second shared secret may be a more complex token (e.g., more bits, digits, and / or characters) than the preceding token and may be considered an “authentication key.” The second shared secret may then be used to derive and generate a symmetric key known as a “session key.” Neither the second shared secret nor the session key need be exchanged through communication over the unsecured communication line. The control device 6010 and the RT device 4000, both of which possess the session key, then establish a more secure communication line than the unsecured communication line established in step 7010 by using the session key for communication (e.g., encryption and decryption). Without knowing the master key, an unauthorized MITM-controlled device cannot compute or derive the second shared secret or session key, and therefore cannot eavesdrop on the communication link established in step 7030, even if it knew all of the data exchanged within the insecure communication link at step 7030. That is, without knowing the session key, an unauthorized MITM-controlled device cannot decrypt information encrypted using the session key or insert intelligible information into the communication link. Therefore, the communication link established in step 7030 can be considered more secure than the insecure communication link established in step 7010.

[0139] In one “physical access” implementation of step 7020, the duplicate key is a token printed on a physical part of the RT device 4000 (e.g., the housing 4010) or its user manual / instruction manual or other documentation that may be distributed by the RT device 4000. The duplicate key may be printed in human-readable form, machine-readable form, or both. In one machine-readable implementation, the token may be obfuscated so that it cannot be easily understood by humans. For example, in one such implementation, the token may be encoded as a barcode 6017 (e.g., a QR code), printed on the housing 4010, or other encoded graphic symbol / indication. In such an implementation, the control device 6010 is configured with a barcode reader (e.g., a camera and associated barcode decoding image processing capabilities), and in step 7020, the control device 6010 uses the barcode reader to scan the barcode and thereby obtain the duplicate key. In one implementation of the human-readable form, the master key is printed in alphanumeric format on the housing 4010. In such an implementation of step 7020, the control device 6010 obtains the master key through manual user input into a user interface of the control device 6010. In one such implementation, the human-readable form of the master key is a five-decimal digit numeric code (100,000 possibilities). Such a master key is "weak" because it only has approximately 16 bits of entropy. In another implementation, the human-readable form of the master key is a four-decimal digit numeric code (e.g., "7409"), which may also be considered weak.

[0140] As noted above, the master key may be printed on the housing 4010 in both machine-readable and human-readable form. In such an implementation, in step 7020, the control device 6010 first attempts to scan the master key in machine-readable form into the control device 6010. If this fails, the control device 6010 prompts the user to manually enter the master key in human-readable form through the user interface of the control device 6010.

[0141] In another "physical access" implementation of step 7020, the control device 6010 obtains the token from the RT device 4000 via a short-range wireless protocol (e.g., Near Field Communication (NFC)). In another "physical access" implementation of step 7020, the control device 6010 obtains the token from the RT device 4000 by scanning an RFID tag embedded in the RT device 4000. The RFID tag encodes the token.

[0142] In step 7030, both devices execute a key exchange protocol together by communicating over an insecure communication channel to compute a shared (symmetric) authentication key. The master key (first shared secret) obtained in step 7020 is used to authenticate the key exchange in step 7030. In some implementations of step 7030, a Diffie-Hellman-based key exchange protocol may be used (e.g., the Secure Remote Password (SRP) protocol). In one implementation of step 7030, a type of Diffie-Hellman-based protocol known as SRP6a [2] is used. SRP6a has the following properties: · Secure against eavesdropping. The master key is not transmitted over insecure communication lines, whether clear or encrypted. Immunity to replay attacks, preventing captured information from being reused to gain access. Resistance to offline dictionary attacks. Traffic capture does not provide any information for offline computational attacks. Forward security: Traffic captured in previous sessions is safe from decryption if the master key is known. No back-end connection is required to pass the certificate and authentication.

[0143] As described above, SRP6a achieves security through Diffie-Hellman-based iteration. Under SRP6a, one device (the RT device 4000 in this technology) is designated as the server, and the other (the control device 6010) is designated as the client. The server (authenticator) converts a shared secret key to the verifier. The verifier then generates a public key that is combined with Diffie-Hellman exponentiation. The result is security when used with low-entropy secret keys (e.g., 5-digit secret keys). The client (peer) also generates a Diffie-Hellman public key. The public keys are exchanged over an insecure communication channel, and from this information, both the client and server compute a shared secret (authentication key) that is stronger than the secret key. Optionally, the two devices may then perform a complete message verification sequence to prove to themselves that their calculated authentication keys are identical. This is accomplished through a sequence of hashes, the results of which are exchanged and compared between the devices. If any comparison fails, step 7030 is aborted because this failure is evidence that the MITM-controlled device is attempting to participate in a key exchange using an incorrectly guessed passkey. For increased security, in a preferred implementation of step 7030, if step 7030 is repeated with the same passkey, the likelihood that the authentication keys will be identical is statistically low.

[0144] Both devices store the hash of the authentication key in secure persistent storage (e.g., memory 4260 for the RT device 4000). As described above, in the final substep of step 7030, each device computes a session key from the hash of the authentication key for encryption / decryption in the current session. The session key computation may be based on a single-use random number called a "nonce." The "nonce" is generated and transmitted from one device to the other. In one implementation, the "nonce" is a random number generated by the server, transmitted to the client over an insecure communication channel (used by both devices in the session key computation), and then discarded. By repeating this substep with a different nonce on each subsequent re-pairing of the devices, a different session key is computed for each communication session, thereby establishing the "forward security" described above.

[0145] The passkey itself does not need to be stored in memory 4260 of the RT device 4000. Instead, a hash of the passkey can be stored in memory 4260, since this is all that is required on the server side to perform step 7030 according to SRP6a. The passkey hash is not externally accessible from the RT device 4000, so access to the location in memory 4260 (where the hash is stored) cannot be provided via interface 4280 to an external computing device, local or remote. After step 7030 is complete, the passkey does not need to be stored in the control device 6010 because it will not be used in subsequent re-pairing operations.

[0146] 8 includes two flowcharts illustrating methods 8000 and 8050. Methods 8000 and 8050 may be performed by a server (RT device 4000) and a client (control device 6010), respectively, to perform their respective roles in method 7000 in accordance with one aspect of the present technology.

[0147] Method 8000 begins at step 8010, and method 8050 begins at step 8055, where the server and client each take the necessary actions to establish an unsecured communication link with each other (e.g., Just Works Simple Pairing (step 7010) of the Bluetooth protocol). These steps require unsecured bidirectional communication between the two devices, as indicated by the two-way dotted arrow 8001. The remaining communication between the two devices (except for the communication in step 8060), as indicated by the dashed arrow between method 8000 and method 8050, occurs over the unsecured communication link.

[0148] Step 8060 of method 8050 follows next. Here, the client obtains the passkey (P) or first shared secret from the server, as described above in connection with step 7020, e.g., using physical access to the server. The remaining steps of methods 8000 and 8050 involve step 7030 of method 7000. In step 8015 of method 8000, the server computes a server public key (B) using a salt (s). The salt (s) is a random number generated by the server. The Diffie-Hellman key exchange is based on a multiplicative group (known as a prime group) modulo a large prime number (N). To compute the server public key (B), the server uses a group generator (g), which is a small integer (e.g., 2), and the prime group (N). First, the server computes an exponent (x) as the hash of the salt (s) concatenated with the hash of the passkey (P):

number

number

[0149] The server then computes the multiplier (k) by hashing the prime group (N) and the group generator (g):

number

[0150] The server then computes the server public key (B) as follows:

number

[0151] The client receives the server public key (B) and salt(s) in step 8065 of method 8050. Because the client knows the group generator (g) and the prime group (N), in step 8070 it can compute the client public key (A) by raising the group generator (g) to the client random exponent (a) modulo the prime group (N):

number

[0152] Also in step 8070, the client sends the client public key (A) to the server, which the server received in step 8020 of method 8000. Note that because the client public key (A) is independent of the server public key (B) or the salt(s), steps 8065 and 8070 can be performed in any order. Step 8020 can precede step 8015 if step 8070 precedes step 8065.

[0153] Note also that step 8060 may follow steps 8065 and 8070, since the client does not need a passkey (P) in computing the client public key (A). However, in some cases, step 8060 may precede step 8055.

[0154] In step 8025, the server computes a hash (u) of the client and server public keys (A and B):

number

number

[0155] In step 8075 of method 8050, the client computes the hash (u), multiplier (k), and exponent (x) using the above formulas (note that computing the exponent (x) requires the passkey (P) obtained in step 8060). The client then computes the authentication key (S) as follows:

number

[0156] Using modulo N arithmetic, it can be seen that the client and server compute the same authentication key (S) in steps 8025 and 8075, respectively. However, to protect against error or corruption, subsequent steps in methods 8000 and 8050 confirm that the server and client each share a common authentication key (S). In step 8080 of method 8050, the client calculates a client hash value (Mclient) as follows:

number

number

[0157] Assuming the server and client hash values (Mserver and Mclient) are equal, method 8000 proceeds to step 8040, where the server calculates a second server hash value (HAMKserver) as follows:

number

[0158] Also in step 8040, the server sends a second server hash value (HAMKserver) and a nonce (randomly selected by the server) to the client. Meanwhile, in step 8085 of method 8050, the client computes a second client hash value (HAMKclient) as follows:

number

[0159] In step 8090, the client receives the second server hash value (HAMKserver) and the nonce and compares the second server hash value and the client hash value (HAMKserver and HAMKclient). If they are not equal, the method 8050 aborts and notifies the user of the failure of the secure communication link establishment step 7030 (e.g., by generating a user output via the user interface of the control device 6010 and / or the output device 4290 of the RT device 4000).

[0160] Assuming the second server hash value and the client hash value (HAMKserver and HAMKclient) are equal, method 8050 proceeds to step 8095, where the client computes a session key (Ks) by hashing the authentication key (S) and the nonce received in step 8090:

number

[0161] Meanwhile, in step 8045 of method 8000, the server similarly computes a session key (Ks).

[0162] The above arrangement significantly reduces the likelihood of an unauthorized control device 6020 actively or passively eavesdropping on the connection 6015, thereby making it possible for the connection between the control device 6010 and the RT device 4000 to be considered secure.

[0163] However, even if the connection 6015 between the control device 6010 and the RT device 4000 is thus secure, and the connection 6050 between the control device 6010 and the server 6040 is also nominally "secure" (e.g., adhering to the SSL connection protocol), threats to the networked respiratory treatment system 6000 remain due to unassociated control devices 6060 and spoofed control devices 6010 as described above.

[0164] 5.7.2 Control Devices and Servers Each RT device (e.g., 4000) in the networked respiratory treatment system 6000 can be identified by a unique identifier that is known to the RT device itself and the server 6040. In addition, each RT device 4000 knows a unique block of data that is unknown to all other devices except the server 6040, and this data block is securely stored in the server 6040 in a manner associated with the RT device 4000 by its unique identifier. This data block is called the RT device's secret. This secret enables a secure arrangement between the RT device 4000 and the server 6040, because it is unknown to the controlling device 6010, which mediates between the RT device and the server 6040, even if the controlling device 6010 is a spoofed controlling device.

[0165] 5.7.2.1 Firmware Upgrade As mentioned above, it may sometimes be necessary to upgrade the firmware of the RT device 4000. If a spoofed controlling device 6010 could tamper with the upgrade (without being detected by the RT device 4000), the controlling device 6010 could alter the operation of the RT device 4000, rendering it ineffective in respiratory therapy. Therefore, it is useful for the RT device 4000 to be able to verify that the firmware upgrade originated from the server 6040, that the firmware upgrade was intended for the RT device 4000, and that it has not been tampered with by the controlling device 6010.

[0166] 9 is a schematic diagram of a method 9000 that may be used by a networked respiratory treatment system 6000 to authorize a firmware upgrade for an RT device 4000. The three entities involved in method 9000 (the RT device 4000, the control device 6010, and the server 6040) are depicted as vertical lines from left to right, with communications and other actions between them depicted as arrows from top to bottom in chronological order.

[0167] Method 9000 may begin at step 9005. In step 9005, the control device 6010 optionally sends a query to the RT device 4000 for its current firmware version number. In step 9010, the device 4000 responds to the control device 6010 with its firmware version number. In step 9020, the control device 6010 requests a firmware upgrade from the server 6040 and sends the current firmware version number. In step 9030, if this is necessary, the server 6040 responds by sending a firmware upgrade file to the control device 6010 based on the firmware version number (if an upgrade is unavailable, the server responds with the message "none," causing the control device 6010 to exit method 9000 after step 9030).

[0168] In some versions, the method may begin at step 9020. In one type of method 9000, steps 9005-9020 are omitted, and the method 9000 begins at step 9030. In step 9030, the server 6040 transmits a firmware upgrade file to the control device 6010 based on its own record of the upgrade history of the RT device 4000.

[0169] In a further variation of method 9000, step 9005 requests a unique identifier for the RT device rather than the RT device's firmware version number. In step 9010, the RT device 4000 responds to the controlling device 6010 with its unique identifier. In step 9020, the controlling device 6010 requests a firmware upgrade from the server 6040 and sends the unique identifier. In step 9030, if one is needed, the server 6040 applies the firmware upgrade by sending it to the controlling device 6010 based on the unique identifier. This variation allows the server 6040 to target specific devices (rather than all devices with a particular firmware version number) for the firmware upgrade.

[0170] In a next step 9035, the control device 6010 sends the upgrade file to the RT device 4000. In step 9040, the RT device 4000 sends its unique identifier to the control device 6010. (In the further variant described above, the unique identifier of the RT device 4000 is already known to the control device 6010, so step 9040 is not necessary.) Next, in step 9045, the control device 6010 requests an authentication code for the upgrade from the server 6040 and sends the unique identifier of the RT device 4000. Next, in step 9050, the server 6040 derives a key from the secret associated with the unique identifier received from the control device 6010 (i.e., the secret shared with the RT device 4000). In one implementation, the key is a subset of data from the secret. The server 6040 then uses the key to derive the authentication code from the upgrade file sent to the control device 6010 in step 9030. In one implementation of step 9050, the authentication code is a hashed message authentication code (HMAC) derived from a hash of the upgrade file. In another implementation, the authentication code is a hash of the upgrade file encrypted with a key. Using a hash of the upgrade file rather than the upgrade file itself is advantageous for the server 6040 because it may need to perform the same operation multiple times, more or less simultaneously, on different RT devices in the networked respiratory treatment system 6000.

[0171] Next, in step 9055, the server 6040 sends the authentication code to the control device 6010. In step 9060, the control device 6010 sends the authentication code to the RT device 4000. In step 9065, the RT device 4000 derives a key from its secret in the same manner as the server 6040 in step 9050. The RT device 4000 then calculates (also in step 9065) an authentication code from the upgrade file received from the control device 6010 in step 9035, using the key derived in the same manner as the server 6040 in step 9050. Thus, the calculation of the authentication code by the RT device 4000 in step 9065 mimics the calculation performed by the server 6040 in step 9050. The RT device 4000 then compares the calculated authentication code with the authentication code received in step 9060. If these two codes match, the RT device 4000 authenticates the upgrade file. The RT device 4000 then securely applies the upgrade file to its own native firmware.

[0172] The authentication code is computed in a manner that ensures that neither the secret nor the key can be derived from the upgrade file and authentication code (even if it is known how to compute the authentication code from the upgrade file). Furthermore, if the upgrade file is tampered with by a spoofed control device 6010, the authentication code computed by the RT device 4000 in step 9065 will be different from the one received by the server 6040 in step 9055. Therefore, because neither the key nor the secret was sent to the control device 6010 and the control device 6010 cannot compute the expected authentication code without the key, it is impossible to derive the key or secret from the control device 6010, and it is impossible for the spoofed control device 6010 to provide a fake or fraudulent upgrade to the firmware of the RT device 4000.

[0173] 5.7.2.2 Uploading Treatment Data As noted above, RT devices (e.g., 4000) in the networked respiratory treatment system 6000 may be configured to upload therapy data to the server 6040 via their own controlling device 6010. A spoofed controlling device 6010 or an unassociated controlling device 6060 under the control of a criminal 6065 may attempt to upload fake or fraudulent therapy data to the server 6040. This may be considered an acceptable risk, as an isolated source of fake therapy data poses only minimal harm to the entire networked therapy system 6000, which includes many RT devices. However, it is unacceptable for a spoofed controlling device 6010 or an unassociated controlling device 6060 to pose as the controlling device for other RT devices in the system 6000 and upload fake therapy data falsely claiming to come from those RT devices. This is because such fake therapy data could overwhelm the authentic therapy data uploaded to the server 6040 from the authorized controlling device 6010. Therefore, at the time of upload, it is desirable that the controlling device 6010 is communicating with the RT device 4000 from which it claims to be uploading therapy data. This precondition prevents an unassociated controlling device 6060 that has managed to connect with the RT device 4000 at least once in the past from later connecting with an authorized controlling device 6010 and performing spoofing and large-scale uploads of fake therapy data.

[0174] Figure 10 is a schematic diagram of a method 10000 that may be used by the networked respiratory treatment system 6000 of Figure 6 to authenticate treatment data uploads to a server in accordance with one form of the present technology.

[0175] Method 10000 begins at step 10005. In step 10005, the RT device 4000 sends therapy data to the control device 6010. This step can occur at other times relative to method 10000, but must occur before the transfer of therapy data to the server. In step 10010, the control device 6010 requests a "nonce" and offset from the server 6040 and sends an identifier for the RT device 4000. The nonce is a (pseudo)random number with a limited duration, governed by time and / or a number of uses. In this regard, the nonce "expires" after a predetermined period and / or a predetermined number of uses. Once the nonce expires, it is no longer used by the server 6040. For example, the duration of the nonce can be exactly one use. In step 10015, the server 6040 provides the control device 6010 with the nonce and offset. The server 6040 tracks the number of uses or the time since the nonce was first sent in step 10015 and the identifier of the RT device 4000 so that the server 6040 can later determine if the nonce has expired. The offset is a pointer that can be used to derive a key from the secret associated with the identifier received in step 10010 (i.e., a secret known to the RT device 4000). For example, the pointer can be an identifier that is used to select a subset of data from the secret to use as a key or to perform a hash to generate a key from the subset of data.

[0176] Next, in step 10020, the control device 6010 requests a signing key from the RT device 4000 and sends the offset and the nonce received from the server in step 10015. In step 10025, the RT device 4000 derives a signing key using the offset, the nonce, and its secret. In the next step 10030, the RT device 4000 sends the signing key to the control device 6010. In step 10035, the control device 6010 uses the signing key to obtain an authentication code for the therapy data. In one implementation, the authentication code is an HMAC. For example, the authentication code can be a hash computed with the therapy data and the signing key using a cryptographic hash function. In step 10040, the control device 6010 sends the therapy data, the authentication code, and the RT device 4000 identifier to the server 6040. Finally, in step 10045, the server 6040 checks whether the nonce associated with the received identifier sent in step 10015 has expired. If the nonce associated with the received identifier sent in step 10015 has expired, authentication fails. If the nonce associated with the received identifier sent in step 10015 has not expired, the server 6040 derives a signing key using the offset, the nonce sent in step 10015, and a secret associated with the identifier (i.e., a secret known to the RT device 4000). The server 6040 uses the signing key to calculate an authentication code for the therapy data. The method for calculating the authentication code from which the signing key is derived is the same as the method used by the RT device 4000 and the control device 6010 in steps 10025 and 10035. If there is a match between the calculated authentication code and the authentication code received in step 10040, the therapy data is authenticated.

[0177] 10, based on such authentication, the server 6040 may then optionally perform an action with the treatment data. For example, the server 6040 may store the treatment data in a treatment-related database for later use. In some cases, the server 6040 may perform a compliance process (e.g., including the application of compliance rules and / or evaluation of the treatment data via compliance reporting, as described above).

[0178] In subsequent uploads of new therapy data received from the RT device 4000, the control device 6010 may skip step 10010 and reuse the signing key received in step 10030 of a previous execution of method 10000. However, if the nonce has expired and the control device 6010 later loses upload authorization, the control device 6010 will have to restart method 1000 from step 10010 onwards in order to upload the therapy data. In such cases, the server 6040 may optionally send an error message to prompt such restart.

[0179] Because the connection between the control device 6010 and the server 6040 is not secure, an unassociated control device 6060 could eavesdrop on step 10015 and obtain the offset and nonce. However, because the connection between the RT device 4000 and the control device 6010 is secure, an unassociated control device 6060 cannot eavesdrop on this connection to obtain the signing key or authorize the control device 6060 to upload false therapy data to the server 6040. In addition, a control device 6010 that has connected to the RT device 4000 and thus obtained a signing key once cannot continue to use this same signing key indefinitely because the nonce used by the server 6040 to derive the signing key eventually expires. Furthermore, a spoofed control device 6010 cannot deduce future signing keys by itself, no matter how frequently it participates in method 10000, because it cannot deduce the secret from any number of signing keys, nonce, and offsets. Therefore, the control device 6010 may need to be connected to the RT device 4000 to allow continuous authorization of therapy data uploads. A shorter nonce duration increases security by requiring therapy data uploads to occur closer to the connection between the control device 6010 and the RT device 4000. However, this increases the computational burden on the system 6000 and reduces the convenience of independent operation of the control device 6010 and the RT device 4000. This also increases the dependency on the connection between the RT device 4000 and the control device 6010, making it desirable to increase their independence. Therefore, the expiration duration of the nonce expiration can be selected to balance these concerns.

[0180] In one type of method 10000, no offset is used. In such a case, the RT device 4000 and server 6040 derive the signing key from the secret and nonce only.

[0181] It should be noted that method 10000 cannot prevent a spoofed control device 6010 connected to the RT device 4000 from cheating or falsifying the treatment data (prior to signing (i.e., computing the authentication code)). Therefore, the server 6040 cannot detect such cheating or falsification when using method 10000.

[0182] Figure 11 is a schematic diagram of a further method 11000 that may be used by networked respiratory treatment system 6000 of Figure 6 to authorize therapy data upload to a server in accordance with one form of the present technology. Steps 11005-11020 of method 11000 are the same as correspondingly numbered steps 10005-10020 of method 10000.

[0183] In step 11025, the RT device 4000 uses the offset, nonce, and its secret to obtain a signing key. Next, the RT device 4000 uses the signing key to calculate an authentication code (e.g., HMAC) from the therapy data sent in step 11005. In step 11030, the RT device 4000 sends the authentication code to the control device 6010. Next, in step 11040, the control device 6010 sends the therapy data, authentication code, and RT device identifier to the server 6040. Finally, in step 11045, the server 6040 checks whether the nonce sent in step 11015 has expired. If the nonce sent in step 11015 has expired, authentication fails. If the nonce sent in step 11015 has not expired, the server 6040 derives a signing key using the offset and nonce sent in step 11015 and a secret associated with the RT device identifier (i.e., a secret known to the RT device 4000). The server 6040 then uses the signing key to compute an authentication code for the therapy data. The derivation of the signing key and computation of the authentication code are the same as those used by the RT device 4000 in step 11025. If the computed authentication code matches the authentication code received in step 11040, the therapy data is authenticated.

[0184] When method 11000 is used, neither the secret nor the signing key is sent to the control device 6010. Furthermore, the method of deriving the signing key and authentication code is such that it is not possible to derive the signing key from the offset, nonce, authentication code, and therapy data (even if the method of deriving the signing key and authentication code is known to the control device 6010). Therefore, a spoofed control device 6010 cannot tamper with or forge therapy data (without being detected by the server 6040) because it does not have the key to generate an authentication code for the tampered or forged data.

[0185] Disadvantages of method 11000 include the additional computational load and / or storage capacity required on the RT device 4000 to sign and transmit many small chunks of therapy data or to accumulate large amounts of therapy data in memory and then sign and transmit this data to the controlling device 6010. Additionally, there is an administrative burden on the controlling device 6010, which may not be simultaneously connected to the server 6040 and the RT device 4000. Therefore, the controlling device 6010 must keep track of each chunk of therapy data and its associated authentication code received from the RT device 4000 while disconnected from the server 6040, in order to later forward the therapy data to the server 6040 in association with the correct authentication code (when the controlling device 6010 is connected to the server 6040).

[0186] In one version of method 11000, neither an offset nor a nonce is used. In such a case, a signing key that can be derived from the secret without the need for information exchange is used by both the RT device 4000 and the server 6040. In one such version, the signing key is the secret itself. In this version, steps 11005-11020 are omitted, and the method begins with step 11025. In step 11025, the RT device 4000 derives a signing key from the secret and uses the signing key to compute an authentication code from the treatment data. In step 11030, the RT device sends both the treatment data and the authentication code to the control device 6010. Then, in step 11040, the control device 6010 sends the treatment data and the authentication code to the server 6040. Finally, in step 11045, the server 6040 derives a signing key using a secret associated with the identifier (i.e., a secret known to the RT device 4000) and uses this signing key to compute an authentication code for the therapy data. The method for deriving the signing key from the secret and computing the authentication code is the same as that used by the RT device 4000 in step 11025. If there is a match between the computed authentication code and the authentication code received in step 11040, the therapy data is authenticated. In this type of case, the authentication code is essentially derived from a fixed key, making it less desirable (i.e., less secure) than method 10000 using a random nonce.

[0187] This variant of the method 11000 may be less secure than the original method 11000 because a single breach of the RT device 4000 by a spoofed control device 6010 or an unassociated control device 6060 could result in any amount of counterfeit therapy data being uploaded to the server 6040 by such a device claiming to come from the RT device 4000.

[0188] 5.8 Glossary For purposes of this disclosure, in certain aspects of the technology, one or more of the following definitions may apply. In other aspects of the technology, other definitions may apply.

[0189] Air: In certain forms of the present technology, air may refer to atmospheric air, while in other forms of the present technology, air may refer to a combination of other breathable gases (e.g., oxygen-rich atmospheric air).

[0190] Automatic Positive Airway Pressure (APAP) Therapy: A CPAP therapy that is capable of automatically adjusting therapeutic pressure between minimum and maximum limits, for example, between breaths, depending on the presence or absence of signs of an SDB episode.

[0191] Continuous Positive Airway Pressure (CPAP) Therapy: Respiratory pressure therapy in which the therapeutic pressure is approximately constant throughout the patient's respiratory cycle. In some forms, the pressure at the entrance to the airways increases slightly during exhalation and decreases slightly during inhalation. In some forms, the pressure varies during different respiratory cycles of the patient (e.g., increased in response to the detection of an indication of partial upper airway obstruction and decreased in the absence of notification of partial upper airway obstruction).

[0192] Flow Rate: The instantaneous amount (or mass) of air delivered per unit time. Flow rate can refer to an instantaneous quantity. Sometimes, when referring to flow rate, it refers to a scalar quantity (i.e., a quantity that has only magnitude). In other cases, when referring to flow rate, it refers to a vector quantity (i.e., a quantity that has both magnitude and direction). Flow rate may be given the symbol Q. "Flow rate" may also be called "flow" or "airflow" for shorthand.

[0193] Humidifier: The word "humidifier" is construed to mean a humidifying device constructed, arranged, or configured with a physical structure capable of providing a therapeutically beneficial amount of water (H2O) vapor to an air stream to ameliorate a medical respiratory disorder in a patient.

[0194] Patient: A person with or without a respiratory disease.

[0195] Respiratory Therapy (RT): Therapeutic addition of an air supply to the airway entrance at a therapeutic pressure, typically positive relative to atmosphere (pressure therapy) and / or at an elevated flow rate relative to typical respiratory flow (flow therapy).

[0196] Ventilator: A mechanical device that provides pressure support to a patient while they perform some or all of the work of breathing.

[0197] 5.9 Other Notes A portion of the disclosure of this patent document contains material that is entitled to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of this patent document or this patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but reserves all copyright rights therefor for all other purposes.

[0198] Unless otherwise clearly indicated from the context and unless a range of values is provided, it is understood that each intervening value, to the tenth of the unit of the lower limit, between the upper and lower limits of the range, and for any other stated or intervening value in the stated range, is encompassed by the technology. The upper and lower limits of these intervening ranges, independently included in the intervening range, are also encompassed by the technology if they specifically exceed the limits in the stated range. If the stated range includes one or both of these limits, then ranges exceeding either or both of these stated limits are also encompassed by the technology.

[0199] Furthermore, when a value or values are embodied herein as part of the present technology, unless otherwise specified, it is understood that such values may be approximated and may be used to any appropriate significant figures to the extent practical technical practice permits or requires.

[0200] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this technology belongs. Although any methods and materials similar or equivalent to those described herein can be used in the practice or testing of this technology, a limited number of exemplary methods and materials are described herein.

[0201] Although particular materials are described as being suitable for use in the construction of components, obvious alternative materials having similar properties may be substituted. Furthermore, unless stated to the contrary, any and all components described herein are understood to be manufacturable and therefore may be manufactured collectively or separately.

[0202] Please note that as used herein and in the appended claims, the singular forms "a," "an," and "the" include their plural equivalents unless the context clearly dictates otherwise.

[0203] All publications mentioned herein are incorporated by reference to disclose and describe the methods and / or materials that are the subject of these publications. The publications mentioned herein are provided solely for their disclosure prior to the filing date of this application. Nothing herein should be construed as an admission that the present technology does not antedate such publications by virtue of prior patents. Furthermore, the dates of publications mentioned may differ from the actual publication dates, which may require independent confirmation.

[0204] The terms "comprises" and "comprising" should be construed as referring to elements, components, or steps in a non-exclusive sense, indicating that a described element, component, or step may be present in, utilized with, or combined with other elements, components, or steps not specifically described.

[0205] The headings used in the detailed description are for the convenience of the reader and should not be used to limit the content found in the disclosure or claims as a whole. These headings should not be used in interpreting the scope of the claims or the claim limitations.

[0206] Although the technology herein has been described with reference to specific embodiments, it should be understood that these embodiments are merely illustrative of the principles and applications of the technology. In some cases, terms and symbols may indicate specific details unnecessary for the practice of the technology. For example, although the terms "first" and "second" (etc.) are used, unless otherwise specified, these terms are not intended to indicate any order but are used to distinguish between separate elements. Furthermore, although the process steps in the method may be described or illustrated in an ordered manner, such an order is not required. Those skilled in the art will recognize that such an order can be changed and / or aspects can be performed simultaneously or even synchronously.

[0207] Thus, it should be understood that numerous modifications are possible in the exemplary embodiments and that other arrangements may be devised without departing from the spirit and scope of the present technology. Various versions of such arrangements may be considered in connection with the individual examples in the numbered paragraphs below.

[0208] 5.10 Example of a Patient Interface for the Technology 1. A method of wirelessly communicating with a respiratory treatment device, comprising: establishing, by a controlling device, an unsecured wireless communication link with a respiratory treatment device; the controlling device obtaining a first shared secret over a communication link different from the insecure wireless communication link, the first shared secret being known to the respiratory treatment device; computing by the control device a second shared secret using the first shared secret and the data communicated over the insecure wireless communication link, the second shared secret being known to the respiratory treatment device and being stronger than the first shared secret; the controlling device wirelessly communicating with the respiratory treatment device based on a second shared secret; A method comprising:

[0209] Example 2. The method of example 1, wherein computing the second shared secret includes a Diffie-Hellman key exchange.

[0210] Example 3. The method of example 1, further comprising the control device computing a session key using the second shared secret.

[0211] Example 4. The method of example 3, further comprising the controlling device encrypting and decrypting data communicated with the respiratory treatment device over the wireless link using the session key.

[0212] Example 5. The method of example 1, wherein establishing the unsecured wireless communication link includes the controlling device computing a symmetric key known to the respiratory treatment device.

[0213] Example 6. The method of example 1, wherein obtaining the first shared secret over the different communication lines relies on physical access to the respiratory treatment device by the controlling device.

[0214] Example 7. The method of Example 6, wherein obtaining the first shared secret includes scanning, by the control device, the first shared secret in machine-readable form printed on a housing of the respiratory treatment device.

[0215] Example 8. The method of Example 7, wherein the machine-readable form is a bar code.

[0216] Example 9. The method of example 8, wherein the barcode is a QR code.

[0217] Example 10. The method of example 6, wherein obtaining the first shared secret includes receiving, by the control device, the first shared secret entered via a user interface of the control device.

[0218] Example 11. The method of example 1, further comprising verifying by the control device that the second shared secret is known to the respiratory treatment device.

[0219] Example 12. To confirm: computing a first hash value using a second shared secret; receiving a second hash value from the respiratory treatment device over an unsecured wireless communication link; Including, comparing the first hash value to the second hash value; The method of Example 11, comprising:

[0220] Example 13. The method of example 12, further comprising generating a user output via a user interface of the control device if the first hash value is not equal to the second hash value.

[0221] Example 14. The method of any one of Examples 1 to 13, wherein a second shared secret establishes a secure wireless communication link between the control device and the respiratory treatment device.

[0222] Example 15. The method of example 14, further comprising computing the session key from the second shared secret.

[0223] Example 16. The method of Example 14, further comprising the controlling device transmitting, via the secure wireless communication link, control parameters for controlling respiratory therapy operation of the respiratory treatment device.

[0224] Example 17. The method of example 16, wherein the control parameters include one of a pressure setting and a flow setting.

[0225] Example 18. The method of any one of Examples 14 to 17, further comprising the controlling device receiving data related to respiratory therapy operation of the respiratory treatment device via said secure wireless communication link.

[0226] Example 19. The method of Example 18, wherein the data includes any one or more of: a duration of use of the respiratory treatment device and a plurality of respiratory events.

[0227] Example 20. A computer-readable data storage medium having encoded program instructions thereon, the program instructions configured to cause a processor to perform a method including the method of any one of Examples 1-19.

[0228] Example 21. A server having access to the computer-readable data storage medium of Example 20, the server being configured to receive instructions to download the program instructions of the computer-readable data storage medium to a control device over a network.

[0229] Example 22. A control device configured to wirelessly communicate with a respiratory treatment device, comprising: a memory for storing processing instructions; And, establishing an unsecured wireless communication link with a respiratory treatment device; obtaining a first shared secret over a communication link different from the insecure wireless communication link, the first shared secret being known to the respiratory treatment device; computing a second shared secret using the first shared secret and data communicated over the insecure wireless communication link, the second shared secret being known to the respiratory treatment device and being stronger than the first shared secret; a processor configured to: a control device.

[0230] Example 23. The control device of Example 22, further including a barcode reader, wherein the processor is further configured to obtain the first shared secret by scanning a barcode printed on a housing of the respiratory treatment device with the barcode reader, the barcode encoding the first shared secret.

[0231] Example 24. The control device of Example 22, further including a user interface, wherein the processor is further configured to obtain the first shared secret via input entered through the user interface.

[0232] Example 25. A method for wireless communication between a respiratory treatment device and a control device, comprising: establishing, by the respiratory treatment device, an unsecured wireless communication link with the control device; computing, by the respiratory treatment device, a second shared secret using the first shared secret and data communicated over the insecure wireless communication link, the first shared secret and the second shared secret being known to the control device, and the second shared secret being stronger than the first shared secret; wirelessly communicating with the control device by the respiratory treatment device based on a second shared secret; A method comprising:

[0233] Example 26. A respiratory treatment device configured to wirelessly communicate with a control device, the respiratory treatment device comprising: a memory for storing processing instructions; a controller, establishing an insecure wireless communication link with a control device; a controller configured to compute a second shared secret using the first shared secret and data communicated over the insecure wireless communication link, the first shared secret and the second shared secret being known to the control device, and the second shared secret being stronger than the first shared secret; 1. A respiratory treatment device comprising:

[0234] Example 27. A device comprising: a housing including a printed barcode, the printed barcode encoding a first shared secret;

[0235] Example 28. A respiratory treatment system, comprising: Respiratory therapy devices; and a control device configured to wirelessly communicate with the respiratory treatment device; The control device establishing an unsecured wireless communication link with a respiratory treatment device; obtaining a first shared secret over a communication link different from the insecure wireless communication link, the first shared secret being known to the respiratory treatment device; computing a second shared secret using the first shared secret and data communicated over the insecure wireless communication link, the second shared secret being known to the respiratory treatment device and being stronger than the first shared secret; and conducting wireless communication with the respiratory treatment device based on the second shared secret. Respiratory treatment device of Example 26.

[0236] Example 29. The respiratory treatment system of Example 28, wherein the respiratory treatment device includes a housing including a printed barcode, the printed barcode encoding the first shared secret.

[0237] Example 30. The respiratory treatment system of Example 29, wherein the control device further includes a barcode reader, and the processor is further configured to obtain the first shared secret by the barcode reader by scanning the barcode.

[0238] Example 31. The respiratory treatment system of Example 29, wherein the control device further includes a user interface, and the processor is further configured to obtain the first shared secret via input entered through the user interface.

[0239] Example 32. A method of uploading therapy data generated by a respiratory therapy device to a remote server via a control device configured to communicate with the respiratory therapy device and to communicate with the remote server, comprising: receiving, by a controlling device, treatment data from a respiratory treatment device; receiving by the control device a nonce from a remote server; the controlling device transmitting the nonce to the respiratory treatment device; receiving by the controlling device a signing key from the respiratory treatment device, the signing key being dependent on a nonce and a secret known to the respiratory treatment device and the remote server; generating an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data; the controlling device transmitting the treatment data and the authentication code to a remote server; A method comprising:

[0240] Example 33. The method of example 32, wherein the authentication code is a hashed message authentication code.

[0241] Example 34. The method of any one of Examples 32-33, wherein the signing key further depends on an offset into the shared secret, the offset being received by the control device from a remote server.

[0242] Example 35. The method of any one of Examples 32-34, wherein the nonce is a pseudorandom number.

[0243] Example 36. The method of any one of Examples 32-35, wherein the control device securely receives the signing key from the respiratory treatment device by decrypting the signing key using a symmetric key known to the respiratory treatment device.

[0244] Example 37. A control device, comprising: Memory and a processor; Including, The memory includes program instructions that, when executed by the processor, control the control device to upload therapy data generated by the respiratory therapy device to a remote server, the program instructions comprising: receiving treatment data from a respiratory treatment device; receiving a nonce from a remote server; sending a nonce to a respiratory treatment device; receiving a signing key from the respiratory treatment device, the signing key depending on a nonce and a secret known to the respiratory treatment device and the remote server; generating an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data; sending the treatment data and the authentication code to a remote server; Controlling the control device to perform Control device.

[0245] Example 38. A method for authenticating treatment data generated by a respiratory treatment device, comprising: receiving treatment data and a first authentication code; computing a signing key from the nonce and a secret known to the respiratory treatment device; computing a second authentication code from the received treatment data and the signing key; authenticating the treatment data by comparing the first authentication code with the second authentication code; A method comprising:

[0246] Example 39. The method of example 38, further comprising transmitting an offset to the respiratory treatment device, wherein the signing key depends on the offset.

[0247] Example 40. The method of any one of Examples 38-39, wherein the authentication code is a hashed message authentication code.

[0248] Example 41. The method of any one of Examples 38-40, further comprising transmitting the nonce to the respiratory treatment device.

[0249] Example 42. The method of any one of Examples 38-41, wherein the nonce is a pseudorandom number.

[0250] Example 43. A server, Memory and a processor; Including, The memory includes program instructions that, when executed by the processor, control the server to authenticate therapy data generated by the respiratory therapy device, the program instructions comprising: receiving treatment data and a first authentication code; computing a signing key from the nonce and a secret known to the respiratory treatment device; computing a second authentication code from the received treatment data and the signing key; authenticating the treatment data by comparing the first authentication code with the second authentication code; Controlling the server to do server.

[0251] Example 44. A networked respiratory treatment system, comprising: a respiratory treatment device configured to deliver respiratory treatment to a patient; A remote server; a control device configured to communicate with the respiratory treatment device and with a remote server, the control device comprising: receiving, by a control device, therapy data from the respiratory therapy device; receiving, by the control device, a nonce from a remote server; sending a nonce to the respiratory treatment device by the control device; receiving, by the controlling device, a signing key from the respiratory treatment device, the signing key being dependent on a nonce and a secret known to the respiratory treatment device and the remote server; The controlling device generates an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data; the controlling device sending the treatment data and the authentication code to a remote server; a control device configured to:

[0252] Example 45. The system of Example 44, wherein the respiratory treatment device is a respiratory pressure treatment device.

[0253] Example 46. The system of any one of Examples 44-45, wherein the control device is configured to communicate securely with the respiratory treatment device using a shared symmetric key.

[0254] Example 47. The remote server: receiving treatment data and a first authentication code; computing a signing key from the nonce and a secret known to the respiratory treatment device; computing a second authentication code from the received treatment data and the signing key; authenticating the treatment data by comparing the first authentication code with the second authentication code; The system of any one of Examples 44 to 46, configured to perform the following.

[0255] Example 48. A networked respiratory treatment system, comprising: a respiratory treatment device configured to deliver respiratory treatment to a patient; a control device configured to communicate with the respiratory treatment device; a remote server configured to communicate with the control device, receiving treatment data and a first authentication code from the controlling device; computing a signing key from the nonce and a secret known to the respiratory treatment device; computing a second authentication code from the received treatment data and the signing key; authenticating the treatment data by comparing the first authentication code with the second authentication code; a remote server configured to:

[0256] Example 49. The system of Example 48, wherein the respiratory treatment device is a respiratory pressure treatment device.

[0257] Example 50. The system of any one of Examples 48-49, wherein the control device is configured to communicate securely with the respiratory treatment device using a shared symmetric key.

[0258] Example 51. The control device comprises: receiving treatment data from a respiratory treatment device; receiving a nonce from a remote server; sending a nonce to a respiratory treatment device; receiving a signing key from the respiratory treatment device, the signing key depending on a nonce and a secret known to the respiratory treatment device and the remote server; generating an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data; sending the treatment data and the authentication code to a remote server; The system of any one of Examples 48 to 50, configured to perform the following.

[0259] Example 52. A respiratory treatment device comprises: receiving a nonce from a remote server; Computing a signing key from the nonce and a secret known to the respiratory treatment device and the remote server; generating an authentication code using the treatment data and a signing key; sending the treatment data and the authentication code to a remote server; The system of any one of Examples 48 to 50, configured to perform the following.

[0260] Example 53. A method of uploading therapy data generated by a respiratory therapy device to a remote server, comprising: receiving, by the respiratory treatment device, a nonce from the remote server; Computing by the respiratory treatment device a signing key from the nonce and a secret known to the remote server; generating an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data; transmitting the treatment data and the authentication code from the respiratory treatment device to a remote server; A method comprising:

[0261] Example 54. The method of example 53, wherein the authentication code is a hashed message authentication code.

[0262] Example 55. The method of any one of Examples 53-54, wherein the signing key further depends on an offset into the shared secret, the offset being received by the respiratory treatment device from a remote server.

[0263] Example 56. The method of any one of Examples 53-55, wherein the nonce is a pseudorandom number.

[0264] Example 57. The method of any one of Examples 53-56, wherein the respiratory treatment device receives the nonce via a control device configured to communicate with a remote server.

[0265] Example 58. The method of Example 57, wherein the respiratory treatment device receives the nonce from the controlling device by decrypting the nonce using a symmetric key known to the controlling device.

[0266] Example 59. The method of any one of Examples 53-58, wherein the respiratory treatment device sends the treatment data and the authentication code via a control device configured to communicate with a remote server.

[0267] Example 60. The method of Example 59, wherein the controlling device sends the treatment data and the authentication code to the controlling device by encrypting the treatment data and the authentication code using a symmetric key known to the controlling device.

[0268] Example 61. A respiratory treatment device, comprising: a pressure generator adapted to couple to a patient interface and to provide a positive pressure air flow to the patient interface; Memory and a processor; Including, The memory includes program instructions that, when executed by the processor, control the respiratory treatment device to upload therapy data generated by the respiratory treatment device to a remote server, the program instructions comprising: receiving a nonce from a remote server; Computing a signing key from the nonce and a secret known to the remote server; generating an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data; sending the treatment data and the authentication code to a remote server; controlling a respiratory therapy device to perform Respiratory therapy devices.

[0269] Example 62. A networked respiratory treatment system, comprising: a respiratory treatment device for administering respiratory treatment to a patient; a remote server configured to communicate with the respiratory treatment device; Including, Respiratory therapy devices include: receiving a nonce from a remote server; Computing a signing key from the nonce and a secret known to the remote server; generating an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data; sending the treatment data and the authentication code to a remote server; configured to: Networked respiratory treatment systems.

[0270] Example 63. The system of Example 62, wherein the respiratory treatment device is a respiratory pressure treatment device.

[0271] Example 64. The system of any one of Examples 62-63, further including a control device configured to securely communicate with the respiratory treatment device and to communicate with a remote server.

[0272] Example 65. The system of Example 64, wherein the control device is configured to communicate securely with the respiratory treatment device using a symmetric key known to the respiratory treatment device.

[0273] Example 66. The remote server: receiving treatment data and a first authentication code; computing a signing key from the nonce and a secret known to the respiratory treatment device; computing a second authentication code from the received treatment data and the signing key; authenticating the treatment data by comparing the first authentication code with the second authentication code; The system of any one of Examples 62 to 65, configured to perform the following.

[0274] Example 67. An apparatus comprising: means for receiving treatment data from a respiratory treatment device; means for receiving a nonce from a remote server; means for transmitting the nonce to the respiratory treatment device; means for receiving a signing key from the respiratory treatment device, the signing key being dependent on a nonce and a secret known to the respiratory treatment device and the remote server; means for generating an authentication code using the treatment data and a signing key, the authentication code being used to authenticate the treatment data; means for transmitting the treatment data and the authentication code to a remote server; 1. An apparatus comprising:

[0275] Example 68. A device comprising: means for receiving treatment data from the respiratory treatment device and a first authentication code; means for computing a signing key from the nonce and a secret known to the respiratory treatment device; means for computing a second authentication code from the received treatment data and the signing key; means for authenticating the treatment data by comparing the first authentication code with the second authentication code; 1. An apparatus comprising:

[0276] Example 69. An apparatus comprising: a means for delivering respiratory therapy to the patient; means for receiving a nonce from a remote server; means for computing a signing key from the nonce and a secret known to the remote server; means for generating an authentication code using the treatment data and a signing key, the authentication code being used to authenticate the treatment data; means for transmitting the treatment data and the authentication code to a remote server; 1. An apparatus comprising: The claims of the original application as originally filed are as follows: Claim 1: 1. A method for wireless communication with a respiratory treatment device, comprising: establishing, by a controlling device, an unsecured wireless communication link with said respiratory treatment device; the controlling device obtaining a first shared secret over a communication link different from the insecure wireless communication link, the first shared secret being known to the respiratory treatment device; the control device computing a second shared secret using the first shared secret and data communicated over the insecure wireless communication link, the second shared secret being known to the respiratory treatment device and being stronger than the first shared secret; the control device wirelessly communicating with the respiratory treatment device based on the second shared secret; A method comprising: Claim 2: 10. The method of claim 1, wherein computing the second shared secret comprises a Diffie-Hellman key exchange. Claim 3: The method of claim 1 , further comprising the control device computing a session key with the second shared secret. Claim 4: 4. The method of claim 3, further comprising the controlling device encrypting and decrypting data communicated with the respiratory treatment device over the wireless link using the session key. Claim 5: The method of claim 1 , wherein establishing an unsecured wireless communication link includes the controlling device computing a symmetric key known to the respiratory treatment device. Claim 6: 10. The method of claim 1, wherein obtaining the first shared secret over a different line depends on physical access to the respiratory treatment device by the control device. Claim 7: 7. The method of claim 6, wherein obtaining the first shared secret includes scanning the first shared secret in machine-readable form printed on a housing of the respiratory treatment device by the control device. Claim 8: The method of claim 7 , wherein the machine-readable form is a bar code. Claim 9: The method of claim 8 , wherein the barcode is a QR code. Claim 10: The method of claim 6 , wherein obtaining the first shared secret includes receiving, by the control device, the first shared secret entered via a user interface of the control device. Claim 11: The method of claim 1 , further comprising verifying by the control device that the second shared secret is known to the respiratory treatment device. Claim 12: The confirmation is computing a first hash value using the second shared secret; receiving a second hash value from the respiratory treatment device over the unsecured wireless communication link; comparing the first hash value to the second hash value; 12. The method of claim 11, comprising: Claim 13: 13. The method of claim 12, further comprising generating a user output via a user interface of the control device if the first hash value is not equal to the second hash value. Claim 14: The method of claim 1 , wherein the second shared secret establishes a secure wireless communication link between the control device and the respiratory treatment device. Claim 15: 15. The method of claim 14, further comprising computing a session key from the second shared secret. Claim 16: 15. The method of claim 14, further comprising the controlling device transmitting, via the secure wireless communication link, control parameters for controlling respiratory therapy operation of the respiratory treatment device. Claim 17: The method of claim 16 , wherein the control parameters include one of a pressure setting and a flow setting. Claim 18: 15. The method of claim 14, further comprising the controlling device receiving data related to respiratory therapy operation of the respiratory treatment device via the secure wireless communication link. Claim 19: 20. The method of claim 18, wherein the data includes any one or more of a duration of use of the respiratory treatment device and a plurality of respiratory events. Claim 20: 10. A computer-readable data storage medium having encoded thereon program instructions configured to cause a processor to perform a method including the method of claim 1. Claim 21: 21. A server having access to the computer-readable data storage medium of claim 20, the server configured to receive a request to download the program instructions of the computer-readable data storage medium to the control device over a network. Claim 22: a control device configured to wirelessly communicate with a respiratory treatment device, a memory for storing processing instructions; 1. A processor, comprising: establishing an unsecured wireless communication link with the respiratory treatment device; obtaining a first shared secret over a link different from the insecure wireless communication link, the first shared secret being known to the respiratory treatment device; computing a second shared secret using the first shared secret and data communicated over the insecure wireless communication link, the second shared secret being known to the respiratory treatment device and being stronger than the first shared secret; a processor configured to: a control device. Claim 23: 23. The control device of claim 22, further comprising a barcode reader, wherein the processor is further configured to obtain the first shared secret by scanning a barcode printed on a housing of the respiratory treatment device with the barcode reader, the barcode encoding the first shared secret. Claim 24: 23. The control device of claim 22, further comprising a user interface, wherein the processor is further configured to obtain the first shared secret via input entered through the user interface. Claim 25: 1. A method for wireless communication between a respiratory treatment device and a control device, comprising: establishing, by the respiratory treatment device, an unsecured wireless communication link with the control device; computing, by the respiratory treatment device, a second shared secret using a first shared secret and data communicated over the insecure wireless communication link, the first shared secret and the second shared secret being known to the control device, and the second shared secret being stronger than the first shared secret; the respiratory treatment device wirelessly communicating with the control device based on the second shared secret; A method comprising: Claim 26: 1. A respiratory treatment device configured to wirelessly communicate with a control device, comprising: a memory for storing processing instructions; a controller, establishing an unsecured wireless communication link with the control device; computing a second shared secret using a first shared secret and data communicated over the insecure wireless communication link, the first shared secret and the second shared secret being known to the control device, and the second shared secret being stronger than the first shared secret; a controller configured to: 1. A respiratory treatment device comprising: Claim 27: 27. The respiratory treatment device of claim 26, further comprising a housing including a printed barcode, said printed barcode encoding said first shared secret. Claim 28: 1. A respiratory treatment system comprising: a respiratory treatment device; a control device configured to wirelessly communicate with the respiratory treatment device; Including, The control device includes a processor, the processor comprising: establishing an unsecured wireless communication link with the respiratory treatment device; obtaining a first shared secret over a link different from the insecure wireless communication link, the first shared secret being known to the respiratory treatment device; computing a second shared secret using the first shared secret and data communicated over the insecure wireless communication link, the second shared secret being known to the respiratory treatment device and being stronger than the first shared secret; wirelessly communicating with the respiratory treatment device based on the second shared secret; configured to: Respiratory treatment systems. Claim 29: 30. The respiratory treatment system of claim 28, wherein the respiratory treatment device includes a housing including a printed barcode, the printed barcode encoding the first shared secret. Claim 30: 30. The respiratory treatment system of claim 29, wherein the control device further includes a barcode reader, and the processor is further configured to obtain the first shared secret with the barcode reader by scanning the barcode. Claim 31: 30. The respiratory treatment system of claim 29, wherein the control device further includes a user interface, and the processor is further configured to obtain input entered through the user interface via the first shared secret. Claim 32: 1. A method for uploading therapy data generated by a respiratory therapy device to a remote server via a control device configured to communicate with the respiratory therapy device and with the remote server, comprising: receiving the treatment data from the respiratory treatment device by the control device; receiving by the control device a nonce from the remote server; the control device transmitting the nonce to the respiratory treatment device; receiving by the controlling device a signing key from the respiratory treatment device, the signing key being dependent on the nonce and a secret known to the respiratory treatment device and the remote server; the controlling device generating an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data; the controlling device transmitting the treatment data and the authentication code to the remote server; A method comprising: Claim 33: 33. The method of claim 32, wherein the authentication code is a hashed message authentication code. Claim 34: 33. The method of claim 32, wherein the signing key further depends on an offset into the shared secret, the offset received by the control device from the remote server. Claim 35: 33. The method of claim 32, wherein the nonce is a pseudorandom number. Claim 36: 33. The method of claim 32, wherein the control device securely receives the signing key from the respiratory treatment device by decrypting the signing key using a symmetric key known to the respiratory treatment device. Claim 37: A control device comprising: Memory and a processor; Including, The memory includes program instructions that, when executed by the processor, control the control device to upload therapy data generated by a respiratory treatment device to a remote server, the program instructions comprising: receiving the treatment data from the respiratory treatment device; receiving a nonce from the remote server; sending the nonce to the respiratory treatment device; receiving a signing key from the respiratory treatment device, the signing key depending on the nonce and a secret known to the respiratory treatment device and the remote server; generating an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data; sending the treatment data and the authentication code to the remote server; and controlling the control device to perform Control device. Claim 38: 1. A method for authenticating treatment data generated by a respiratory treatment device, comprising: receiving the treatment data and a first authentication code; computing a signing key from a nonce and a secret known to the respiratory treatment device; computing a second authentication code from the received treatment data and the signing key; authenticating the treatment data by comparing the first authentication code with the second authentication code; A method comprising: Claim 39: 40. The method of claim 38, further comprising transmitting an offset to the respiratory treatment device, wherein the signing key depends on the offset. Claim 40: 39. The method of claim 38, wherein the authentication code is a hashed message authentication code. Claim 41: 39. The method of claim 38, further comprising transmitting the nonce to the respiratory treatment device. Claim 42: 39. The method of claim 38, wherein the nonce is a pseudorandom number. Claim 43: a server, Memory and a processor; Including, The memory includes program instructions that, when executed by the processor, control the server to authenticate therapy data generated by a respiratory therapy device, the program instructions comprising: receiving the treatment data and a first authentication code; computing a signing key from a nonce and a secret known to the respiratory treatment device; computing a second authentication code from the received treatment data and the signing key; authenticating the treatment data by comparing the first authentication code with the second authentication code; controlling the server to perform server. Claim 44: 1. A networked respiratory treatment system comprising: a respiratory treatment device configured to deliver respiratory treatment to a patient; A remote server; a control device configured to communicate with the respiratory treatment device and to communicate with the remote server, the control device comprising: receiving, by the control device, treatment data from the respiratory treatment device; receiving by the control device a nonce from the remote server; sending the nonce to the respiratory treatment device by the control device; receiving, by the controlling device, a signing key from the respiratory treatment device; the signing key depends on the nonce and a secret known to the respiratory treatment device and the remote server; the controlling device generating an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data; the controlling device sending the treatment data and the authentication code to the remote server; a control device configured to: Including, system. Claim 45: 45. The system of claim 44, wherein the respiratory treatment device is a respiratory pressure treatment device. Claim 46: 45. The system of claim 44, wherein the control device is configured to communicate securely with the respiratory treatment device using a shared symmetric key. Claim 47: The remote server receiving the treatment data and a first authentication code; computing a signing key from a nonce and a secret known to the respiratory treatment device; computing a second authentication code from the received treatment data and the signing key; authenticating the treatment data by comparing the first authentication code with the second authentication code; configured to: 45. The system of claim 44. Claim 48: 1. A networked respiratory treatment system comprising: a respiratory treatment device configured to deliver respiratory treatment to a patient; a control device configured to communicate with the respiratory treatment device; a remote server configured to communicate with the control device, the remote server comprising: receiving treatment data and a first authentication code from the controlling device; computing a signing key from a nonce and a secret known to the respiratory treatment device; computing a second authentication code from the received treatment data and the signing key; authenticating the treatment data by comparing the first authentication code with the second authentication code; a remote server configured to: Including, the system. Claim 49: 49. The system of claim 48, wherein the respiratory treatment device is a respiratory pressure treatment device. Claim 50: 49. The system of claim 48, wherein the control device is configured to communicate securely with the respiratory treatment device using a shared symmetric key. Claim 51: The control device receiving the treatment data from the respiratory treatment device; receiving a nonce from the remote server; sending the nonce to the respiratory treatment device; receiving a signing key from the respiratory treatment device, the signing key depending on the nonce and a secret known to the respiratory treatment device and the remote server; generating an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data; sending the treatment data and the authentication code to the remote server; configured to: 49. The system of claim 48. Claim 52: The respiratory treatment device comprises: receiving a nonce from the remote server; Computing a signing key from the nonce and a secret known to the respiratory treatment device and the remote server; generating an authentication code using the treatment data and the signing key; sending the treatment data and the authentication code to the remote server; configured to: 49. The system of claim 48. Claim 53: 1. A method for uploading therapy data generated by a respiratory therapy device to a remote server, comprising: receiving by the respiratory treatment device a nonce from the remote server; Computing by the respiratory treatment device a signing key from the nonce and a secret known to the remote server; the respiratory treatment device generating an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data; and transmitting the treatment data and the authentication code from the respiratory treatment device to the remote server; A method comprising: Claim 54: 54. The method of claim 53, wherein the authentication code is a hashed message authentication code. Claim 55: 54. The method of claim 53, wherein the signing key further depends on an offset into the shared secret, the offset received by the respiratory treatment device from the remote server. Claim 56: The method of any one of claims 53 to 55, wherein the nonce is a pseudorandom number. Claim 57: 54. The method of claim 53, wherein the respiratory treatment device receives the nonce via a control device configured to communicate with the remote server. Claim 58: 58. The method of claim 57, wherein the respiratory treatment device receives the nonce from the controlling device by decrypting the nonce with a symmetric key known to the controlling device. Claim 59: 54. The method of claim 53, wherein the respiratory treatment device transmits the treatment data and the authentication code via a control device configured to communicate with the remote server. Claim 60: 60. The method of claim 59, wherein the control device transmits the treatment data and the authentication code to the control device by encrypting the treatment data and the authentication code with a symmetric key known to the control device. Claim 61: Respiratory therapy devices include: a pressure generator adapted to couple to a patient interface and to provide a positive pressure air flow to the patient interface; Memory and a processor; Including, The memory includes program instructions that, when executed by the processor, control the respiratory treatment device to upload therapy data generated by the respiratory treatment device to a remote server, the program instructions comprising: receiving a nonce from the remote server; Computing a signing key from the nonce and a secret known to the remote server; generating an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data; A respiratory treatment device that controls the respiratory treatment device to send the treatment data and the authentication code to the remote server. Claim 62: 1. A networked respiratory treatment system comprising: a respiratory treatment device for administering respiratory treatment to a patient; a remote server configured to communicate with the respiratory treatment device; Including, The respiratory treatment device comprises: receiving a nonce from the remote server; Computing a signing key from the nonce and a secret known to the remote server; generating an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data; sending the treatment data and the authentication code to the remote server; configured to: system. Claim 63: 63. The system of claim 62, wherein the respiratory treatment device is a respiratory pressure treatment device. Claim 64: 63. The system of claim 62, further comprising a control device configured to securely communicate with the respiratory treatment device and to communicate with the remote server. Claim 65: 65. The system of claim 64, wherein the control device is configured to communicate securely with the respiratory treatment device using a symmetric key known to the respiratory treatment device. Claim 66: The remote server receiving the treatment data and a first authentication code; computing a signing key from a nonce and a secret known to the respiratory treatment device; computing a second authentication code from the received treatment data and the signing key; authenticating the treatment data by comparing the first authentication code with the second authentication code; configured to: 63. The system of claim 62. Claim 67: 1. An apparatus comprising: means for receiving treatment data from a respiratory treatment device; means for receiving a nonce from a remote server; means for transmitting the nonce to the respiratory treatment device; means for receiving a signing key from the respiratory treatment device, the signing key being dependent on the nonce and a secret known to the respiratory treatment device and the remote server; means for generating an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data; means for transmitting the treatment data and the authentication code to the remote server; 1. An apparatus comprising: Claim 68: 1. An apparatus comprising: means for receiving treatment data from the respiratory treatment device and a first authentication code; means for computing a signing key from a nonce and a secret known to the respiratory treatment device; means for computing a second authentication code from the received treatment data and the signing key; means for authenticating the treatment data by comparing the first authentication code with the second authentication code; 1. An apparatus comprising: Claim 69: 1. An apparatus comprising: a means for delivering respiratory therapy to the patient; means for receiving a nonce from a remote server; means for computing a signing key from the nonce and a secret known to the remote server; means for generating an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data; means for transmitting the treatment data and the authentication code to the remote server; 1. An apparatus comprising: [Explanation of symbols]

[0277] 5.11 List of Reference Symbols patient 1000 Bedmate: 1100 Patient Interface 3000 Seal forming structure 3100 Plenum Chamber 3200 Structure 3300 Ventilation 3400 Connection port 3600 Forehead support part 3700 RT Device 4000 Outer Housing 4010 Internal part 4012 Part 4014 Panel 4015 Chassis 4016 Handle 4018 Pneumatic Block 4020 Air Filter 4110 Inlet Air Filter 4112 Outlet Air Filter 4114 Muffler 4120 Inlet muffler 4122 Outlet muffler 4124 Pressure Generator 4140 Blower 4142 Motor 4144 Anti-spillback valve 4160 Air Circuit 4170 Electrical Components 4200 PCBA 4202 Electrical Power Supply 4210 Button 4220 Central control unit 4230 Clock 4232 Therapy Device Controller 4240 Protection circuit 4250 Memory 4260 Converter 4270 Pressure Sensor 4272 Flow Sensor 4274 Motor Speed Converter 4276 Interface 4280 Remote External Communications Network 4282 Local external communication network 4284 Remote External Device 4286 Local Foreign Device 4288 Output device 4290 Humidifier 5000 Humidifier inlet 5002 Humidifier outlet 5004 Humidifier Base 5006 Humidifier Reservoir 5110 Humidifier Reservoir Dock 5130 heating element 5240 Networked respiratory therapy system 6000 Control Device 6010 Channel 6013 Wireless connection 6015 Barcode 6017 Second Control Device 6020 Wireless connection 6025 criminal 6030 Server 6040 Wireless connection 6050 Unassociated Control Device 6060 criminal 6065 Wireless connection 6070 method 7000 Step 7010 Step 7020 Step 7030 method 8000 Arrow 8001 Step 8010 Step 8015 Step 8020 Step 8025 Step 8030 Step 8035 Step 8040 Step 8045 Method 8050 Step 8055 Step 8060 Step 8065 Step 8070 Step 8075 Step 8080 Step 8085 Step 8090 Step 8095 method 9000 Step 9005 Step 9010 Step 9020 Step 9030 Step 9035 Step 9040 Step 9045 Step 9050 Step 9055 Step 9060 Step 9065 method 10000 Step 10005 Step 10010 Step 10015 Step 10020 Step 10025 Step 10030 Step 10035 Step 10040 Step 10045 Method 11000 Step 11005 Step 11010 Step 11015 Step 11020 Step 11025 Step 11030 Step 11040 Step 10045

[0278] 6 References 1.Simple Pairing Whitepaper, version 10r00.Bluetooth Core Specification Working Group, August 2006. 2.Using the Secure Remote Password (SRP) Protocol for TLS Authentication (RFC-5054), Taylor et al., November 2007.

Claims

1. 1. A method for uploading therapy data generated by a respiratory therapy device to a remote server via a control device configured to communicate with the respiratory therapy device and with the remote server, comprising: receiving the treatment data from the respiratory treatment device by the control device; receiving by the control device a nonce from the remote server; the control device transmitting the nonce to the respiratory treatment device; receiving by the controlling device a signing key from the respiratory treatment device, the signing key being dependent on the nonce and a secret known to the respiratory treatment device and the remote server; generating, by the controlling device, an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data; the controlling device transmitting the treatment data and the authentication code to the remote server; A method comprising:

2. The method of claim 1 , wherein the authentication code is a hashed message authentication code.

3. The method of claim 1 , wherein the signing key further depends on an offset into the secret, the offset being received by the control device from the remote server.

4. The method of claim 1 , wherein the nonce is a pseudorandom number.

5. The method of claim 1 , wherein the control device securely receives the signing key from the respiratory treatment device by decrypting the signing key using a symmetric key known to the respiratory treatment device.

6. A computer program causing one or more processors of a control device to perform the method of any one of claims 1 to 5.

7. Memory and a processor; A control device comprising: the memory includes program instructions that, when executed by the processor, control the controlling device to upload therapy data generated by a respiratory treatment device to a remote server, the program instructions controlling the controlling device to receive the therapy data from the respiratory treatment device, receive a nonce from the remote server, send the nonce to the respiratory treatment device, receive a signing key from the respiratory treatment device, the signing key being dependent on the nonce and a secret known to the respiratory treatment device and the remote server, generate an authentication code using the therapy data and the signing key, the authentication code being used to authenticate the therapy data, and send the therapy data and the authentication code to the remote server. Control device.

8. a respiratory treatment device configured to deliver respiratory treatment to a patient; A remote server; a controlling device configured to communicate with the respiratory treatment device and with the remote server, the controlling device configured to: receive by the controlling device treatment data from the respiratory treatment device; receive by the controlling device a nonce from the remote server; send by the controlling device the nonce to the respiratory treatment device; receive by the controlling device a signing key from the respiratory treatment device, the signing key being dependent on the nonce and a secret known to the respiratory treatment device and the remote server; generate by the controlling device an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data; and send by the controlling device the treatment data and the authentication code to the remote server; Including, Networked respiratory treatment systems.

9. The system of claim 8 , wherein the respiratory treatment device is a respiratory pressure treatment device.

10. The system of claim 8 , wherein the control device is configured to communicate securely with the respiratory treatment device using a shared symmetric key.

11. The remote server receiving the treatment data and a first authentication code; computing a signing key from a nonce and a secret known to the respiratory treatment device; computing a second authentication code from the received treatment data and the signing key; authenticating the treatment data by comparing the first authentication code with the second authentication code; configured to: The system of claim 8.

12. The control device receiving the treatment data from the respiratory treatment device; receiving a nonce from the remote server; sending the nonce to the respiratory treatment device; receiving a signing key from the respiratory treatment device, the signing key being dependent on the nonce and a secret known to the respiratory treatment device and the remote server; generating an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data; sending the treatment data and the authentication code to the remote server; configured to: The system of claim 8.

13. means for receiving treatment data from a respiratory treatment device; means for receiving a nonce from a remote server; means for transmitting the nonce to the respiratory treatment device; means for receiving a signing key from the respiratory treatment device, the signing key being dependent on the nonce and a secret known to the respiratory treatment device and the remote server; a generating means for generating an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data; means for transmitting the treatment data and the authentication code to the remote server; An apparatus comprising:

14. a memory configured to store instructions for controlling a control device to upload therapy data generated by the respiratory therapy device to a remote server via the control device; one or more processors coupled to the memory, the one or more processors configured to execute the instructions to receive the treatment data from the respiratory treatment device, receive a signing key from the respiratory treatment device, the signing key being based on a secret known to the respiratory treatment device and the remote server, generate an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data, and transmit the treatment data and the authentication code to the remote server; A control device including:

15. the one or more processors are configured to execute the instructions to receive a nonce from the remote server and transmit the nonce to the respiratory treatment device; The control device of claim 14 , wherein the signing key is based on both the nonce and the secret.

16. the signing key is based on an offset applied to the secret; the one or more processors are configured to execute the instructions to receive the offset along with the nonce from the remote server and transmit the offset along with the nonce to the respiratory treatment device.

16. The control device of claim 15.

17. The control device of claim 15 , wherein the nonce is a pseudorandom number.

18. The control device of claim 14 , wherein the authentication code is a hashed message authentication code.

19. 15. The control device of claim 14, wherein to generate the authentication code, the one or more processors are configured to execute the instructions to compute a hash of the treatment data and the signing key using a cryptographic hash function.

20. The control device of claim 14 , wherein the one or more processors are configured to execute the instructions to decrypt the signing key using a symmetric key known to the respiratory treatment device.

21. The control device of claim 14 , wherein the one or more processors are configured to execute the instructions to send an identifier associated with the respiratory treatment device along with the treatment data and the authentication code to the remote server.

22. A control device according to any one of claims 14 to 21, wherein the control device is configured to communicate with the respiratory treatment device over a first wireless connection and with the remote server over a second wireless connection.

23. 23. The control device of claim 22, wherein the first wireless connection uses a short-range communication protocol and the second wireless connection uses a long-range communication protocol.

24. One or more computer-readable storage media that, when executed by one or more processors, cause a control device to operate to upload therapy data generated by a respiratory therapy device to a remote server, the control instructions of the processors comprising: instructions to receive the treatment data from the respiratory treatment device; instructions to receive a signing key from the respiratory treatment device, the signing key being based on a secret known to the respiratory treatment device and the remote server; instructions to generate an authentication code using the treatment data and the signing key, the authentication code being used to authenticate the treatment data; instructions for transmitting the treatment data and the authentication code to the remote server; one or more computer-readable storage media,

25. the processor control instructions further include instructions for receiving a nonce from the remote server and instructions for transmitting the nonce to the respiratory treatment device; 25. The one or more computer-readable storage media of claim 24, wherein the signing key is based on both the nonce and the secret.

26. the signing key is based on an offset applied to the secret; the processor control instructions further include instructions for receiving the offset along with the nonce from the remote server and instructions for transmitting the offset along with the nonce to the respiratory treatment device.

26. One or more computer-readable storage media according to claim 25.

27. 26. The one or more computer-readable storage media of claim 25, wherein the nonce is a pseudo-random number.

28. 25. The one or more computer-readable storage media of claim 24, wherein the authentication code is a hashed message authentication code.

29. 25. The one or more computer-readable storage media of claim 24, wherein the instructions for generating the authentication code further comprise instructions for computing a hash of the therapy data and the signing key using a cryptographic hash function.

30. 25. The one or more computer-readable storage media of claim 24, wherein the processor control instructions further include instructions for decrypting the signing key using a symmetric key known to the respiratory treatment device.

31. 25. The one or more computer-readable storage media of claim 24, wherein the processor control instructions further include instructions for sending an identifier associated with the respiratory treatment device along with the treatment data and the authentication code to the remote server.

32. 32. The one or more computer-readable storage media of any one of claims 24-31, wherein the processor control instructions operate the control device to communicate with the respiratory treatment device over a first wireless connection and with the remote server over a second wireless connection.

33. 33. The one or more computer-readable storage media of claim 32, wherein the first wireless connection uses a short-range communication protocol and the second wireless connection uses a long-range communication protocol.

Images