JP2020508012A - セキュアなネットワーク化された呼吸治療システム - Google Patents

Abstract

方法および装置により、呼吸治療デバイス（「ＴＤ」）と、サーバーと、仲介者（例えば、前記治療デバイスのための制御デバイス（「ＣＴＬＤ」））との間の通信がセキュリティ向上のために提供される。よりセキュアな通信回線（単数または複数）が、異なる通信回線を用いて導出された共有秘密を用いて確立され得る。これらの通信は、治療データを認証のためにＴＤからサーバーへ送信することを含み得る。ＣＴＬＤは、前記データおよびナンスをサーバーから受信し得る。ＣＴＬＤは、前記ナンスに依存する署名鍵と、ＴＤおよびサーバーによって共有される秘密とを前記ＴＤから受信する。前記サーバーによる前記データの認証のために、ＣＴＬＤは、前記コードおよびデータを受信すると、受信された治療データおよび前記鍵を用いて認証コードを生成する。サーバーは、（１）前記ナンスおよびＴＤにとって既知の前記秘密からの鍵と、（２）受信された治療データおよび前記鍵からの別の認証コードとを演算する。データ認証は、受信されたコードと、演算されたコードとの比較を含み得る。【選択図】図６

Description

１ 関連出願の相互参照
本出願は、米国仮特許出願第６２／４１６８６７号（出願日：２０１６年１１月３日）および米国仮特許出願第６２／４５８６５８号（出願日：２０１７年２月１４日）の利益を主張する。本明細書中、同文献全体をれぞれを参考により援用する。

２ 技術の背景
２．１ 技術の分野
本技術は、呼吸関連疾患の検出、診断、治療、予防および改善のうち１つ以上に関する。本技術はまた、医療デバイスまたは装置と、その使用または操作とに関する。

２．２ 関連技術の説明
２．２．１ ヒトの呼吸器系およびその疾患
身体の呼吸器系は、ガス交換を促進させる。鼻および口腔は、患者の気道への入口を形成する。

これらの気道は、一連の分岐する管を含み、これらの管は、肺の奥深くに進むほど狭く、短くかつ多数になる。肺の主要な機能はガス交換であり、空気から酸素を静脈血中へ取り入れさせ、二酸化炭素を退出させる。気管は、右および左の主気管支に分かれ、これらの主気管支はさらに分かれて、最終的に終末細気管支となる。気管支は、伝導のための気道を構成するものであり、ガス交換には関与しない。気道がさらに分割されると呼吸細気管支となり、最終的には肺胞となる。肺の肺胞領域においてガス交換が行われ、この領域を呼吸ゾーンと呼ぶ。以下を参照されたい：「Ｒｅｓｐｉｒａｔｏｒｙ Ｐｈｙｓｉｏｌｏｇｙ」， ｂｙ Ｊｏｈｎ Ｂ． Ｗｅｓｔ， Ｌｉｐｐｉｎｃｏｔｔ Ｗｉｌｌｉａｍｓ＆Ｗｉｌｋｉｎｓ， ｎｉｎｔｈ ｅｄｉｔｉｏｎ ｐｕｂｌｉｓｈｅｄ ２０１２。

一定範囲の呼吸器疾患が存在している。特定の疾患は、特定の発症（例えば、無呼吸、呼吸低下および過呼吸）によって特徴付けられ得る。

呼吸器疾患の例には、閉塞性睡眠時無呼吸（ＯＳＡ）、チェーン・ストークス呼吸（ＣＳＲ）、呼吸不全（ＲＦ）、肥満過換気症候群（ＯＨＳ）、慢性閉塞性肺疾患（ＣＯＰＤ）、神経筋疾患（ＮＭＤ）および胸壁疾患が含まれる。

閉塞性睡眠時無呼吸（ＯＳＡ）は、睡眠呼吸障害（ＳＤＢ）の１つの形態であり、睡眠時の上通気道の閉鎖または閉塞などの呼吸発症によって特徴付けられる。これは睡眠時の異常に小さな上気道および舌領域における筋緊張の正常欠損、軟口蓋および後口咽頭壁の組み合わせに起因する。このような状態に起因して、罹患患者の呼吸停止が典型的には３０〜１２０秒にわたり、ときには一晩に２００〜３００回も呼吸が停止する。その結果、日中の眠気が過度になり、心血管疾患および脳損傷の原因になり得る。この症候は一般的な疾患であり、特に中年の過体重の男性に多いが、患者に自覚症状は無い。米国特許第４，９４４，３１０号（Ｓｕｌｌｉｖａｎ）を参照されたい。

呼吸不全とは、呼吸器障害の総称であり、患者の需要を満たすための充分な酸素吸気または充分なＣＯ２呼気を肺が行うことができていないことを指す。呼吸不全は、以下の疾患のうちいくつかまたは全てを包含し得る。

肥満過換気症候群（ＯＨＳ）は、低呼吸の原因が他に明確に無い状態における、深刻な肥満および覚醒慢性高炭酸ガス血症の組み合わせとして定義される。症状には、呼吸困難、起床時の頭痛と過剰な日中の眠気が含まれる。

慢性閉塞性肺疾患（ＣＯＰＤ）は、特定の共通する特性を有する下気道疾患のグループのうちのいずれも包含する。これには空気の動きに対する抵抗の増加、呼吸の呼気相の延長および肺における正常な弾性の減少が含まれる。ＣＯＰＤの例として、気腫および慢性気管支炎がある。ＣＯＰＤの原因としては、慢性喫煙（第一危険因子）、職業被ばく、空気汚染および遺伝因子がある。症状を挙げると、労作時の呼吸困難、慢性咳および痰生成がある。

神経筋疾患（ＮＭＤ）は、内在筋病理を直接介してまたは神経病理を間接的に介して筋肉機能を損なう多数の疾病および病気を包含する広範な用語である。ＮＭＤ患者の中には、進行性の筋肉障害によって特徴付けられる者もあり、結果的に歩行不可能、車椅子への束縛、嚥下困難、呼吸筋力低下に繋がり、最終的には呼吸不全による死亡に繋がる。神経筋肉障害は、以下の急速進行性と緩徐進行性とに区分され得る：（ｉ）急速進行性障害：数ヶ月かけて悪化する筋肉障害によって特徴付けられ、数年内に死亡に繋がる（例えば、ティーンエージャーにおける筋萎縮性側索硬化症（ＡＬＳ）およびデュシェンヌ筋ジストロフィー（ＤＭＤ））；（ｉｉ）可変性または緩徐進行性障害：数年かけて悪化する筋肉障害によって特徴付けられ、平均余命が若干低減するだけである（例えば、肢帯、顔面肩甲上腕型および筋強直性筋ジストロフィー）。ＮＭＤにおける呼吸不全症状を以下に挙げる：全身衰弱の増加、嚥下障害、労作および安静時の呼吸困難、疲労、眠気、起床時の頭痛、および集中および気分の変化の困難。

胸壁障害は、胸郭変形の１つのグループであり、呼吸筋肉と胸郭との間の連結の無効性の原因となる。これらの障害は、拘束性障害によって主に特徴付けられ、長期の炭酸過剰性呼吸不全の可能性を共有する。脊柱側弯症および／または脊柱後側弯症は、重篤な呼吸不全を発症することがある。呼吸不全の症状を以下に挙げる：労作時の呼吸困難、末梢浮腫、起座呼吸、反復性胸部感染症、起床時の頭痛、疲労、睡眠の質の低下、および食欲不振。

このような疾患を治療するために、一定範囲の呼吸治療が用いられている。

２．２．２ 呼吸療法
多様な形態の呼吸療法（例えば、持続的気道陽圧（ＣＰＡＰ）治療法、非侵襲的換気（ＮＩＶ）および侵襲的換気（ＩＶ）が上記の呼吸器疾患の１つ以上の治療または改善のために用いられている。さらに、その他の点では健常人も、呼吸器疾患の予防治療を有利に利用することができる。

持続的気道陽圧（ＣＰＡＰ）療法が、閉塞性睡眠時無呼吸（ＯＳＡ）の治療において用いられている。その作用機構としては、例えば軟口蓋および舌を押して後口咽頭壁へ前進または後退させることにより、持続陽圧呼吸療法が空気スプリントとして機能し、これにより上気道の閉鎖を防止し得る。ＣＰＡＰ治療によるＯＳＡの治療は自発的なものであり得るため、このような患者が治療の提供に用いられるデバイスについて以下のうち１つ以上に気づいた場合、患者が治療を遵守しないことを選択する可能性がある：不快、使用困難、高価、美観的な魅力の無さ。

非侵襲的換気（ＮＩＶ）は、換気補助を上気道を通じて患者へ提供して、呼吸機能の一部または全体を行うことにより患者の呼吸の補助および／または身体中の適切な酸素レベルの維持を提供する。換気補助が、非侵襲的患者インターフェースを介して提供される。ＮＩＶは、ＯＨＳ、ＣＯＰＤ、ＭＤ、および胸壁障害などの形態のＣＳＲおよび呼吸不全の治療に用いられている。

侵襲的換気（ＩＶ）は、自身で有効に呼吸することができなくなった患者に対して換気補助を提供し、気管切開管を用いて提供され得る。

高流量治療は、１つの呼吸療法であり、空気流れを典型的な呼吸流量に対して高い流量で気道への入口へ付加することが含まれる。ＨＦＴは、ＯＳＡ、およびＣＯＰＤの治療のために用いられている。

酸素治療は、１つの呼吸療法であり、酸素を豊富に含む空気を規定の流量で気道への入口へ付加することが含まれる。酸素治療は、ＣＯＰＤの治療に用いられている。

２．２．３ 呼吸治療システム
呼吸治療は、呼吸流れおよび／または圧力治療システムまたはデバイスによって提供され得る。呼吸治療システムは、呼吸治療デバイス（ＲＴデバイス）（例えば、呼吸圧力治療（ＲＰＴ）デバイス）、空気回路、加湿器、患者インターフェース、外部制御デバイス、および遠隔サーバーを含み得る。

２．２．３．１ 患者インターフェース
患者インターフェースは、例えば気道入口への空気流れを提供することにより呼吸デバイスへのインターフェースを装着者へ提供するために、用いられ得る。空気流れは、鼻および／または口腔へのマスク、口腔への管、または患者気管への気管切開管を介して提供され得る。適用される療法に応じて、患者インターフェースは、例えば患者の顔の領域との密閉部を形成し得、これにより、療法実行のための雰囲気圧力と共に充分な分散の圧力において（例えば、例えば雰囲気圧力に対して約１０ｃｍＨ_２Ｏの陽圧において）ガス送達を促進する。酸素療法などの他の治療形態において、患者インターフェース、例えば鼻カニューレは、約１０ｃｍＨ_２Ｏの陽圧において気道へのガス供給の送達を促進するのに充分な密閉を含まない場合がある。

２．２．３．２ 呼吸治療（ＲＴ）デバイス
ＲＴデバイスは、例えば気道入口への送達のための陽圧における空気流れを生成することにより、上記した複数の治療のうち１つ以上の送達に用いられ得る。ＲＴデバイスの例を挙げると、ＣＰＡＰデバイス、人工呼吸器および携帯可能な酸素濃縮器がある。

２．２．３．３ 加湿器
空気流れの送達を加湿無しで行った場合、気道の乾燥に繋がり得る。加湿器をＲＴデバイスおよび患者インターフェースと共に用いた場合、加湿ガスが生成されるため、鼻粘膜の乾燥が最小化され、患者気道の快適性が増加する。加えて、より冷涼な気候においては、概して患者インターフェースの周囲の顔領域へ温風を付加すると、冷風の場合よりも快適性が高まる。

２．２．３．４ 外部制御デバイス
コストおよび／または製造の簡単さに起因して、ＲＴデバイスのユーザインターフェースは極めて制限があり得、恐らく含まれるのは１個または２個のボタンおよびＬＥＤであり、表示画面は含まれない。しかし、このような状況において、ＲＴデバイスを介して送達可能な治療の高度化が損なわれないようにする必要がある。双方の目的を達成するための１つの方法として、外部制御デバイスによってＲＴデバイスを制御可能にすることがある。この外部制御デバイスは、例えば制御パラメータ（例えば、圧力および／または流量設定）の送信により、ＲＴデバイスが提供することが可能な呼吸療法の種類を全て行うためにＲＴデバイスを制御する機能と共に構成される。外部制御デバイスは、専用の事前構成された「遠隔制御」または特殊目的用ソフトウェアアプリケーションの実行によって構成された汎用演算デバイスの形態をとり得る。利便性のため、外部制御デバイスは、携帯用であり得る。いくつかのこのような場合、外部制御デバイスは、本明細書中により詳細に記載の機能の達成のために、特殊目的用ソフトウェアアプリケーション（単数または複数）を例えば遠隔サーバーからネットワーク（例えば、インターネット）を介してダウンロードするように構成され得る。

一般的に、このような外部制御配置構成の場合、ＲＴデバイスを外部制御デバイスと通信させる必要がある。利便性のため、特に外部制御デバイスが携帯用である場合、ＲＴデバイスと、外部制御デバイスとの間の通信は、無線であり得る。同様にＲＴデバイスを制御するように構成されている外部制御デバイスを同様に所有している権限の無い人間がこの配置構成のセキュリティ違反を起こす事態を回避することが、望まれている。これは、ＲＴデバイスの範囲内の権限の無い外部制御デバイスへの容易かつ不正のアクセスが原則的に可能である無線通信においては、特に困難である。２つのデバイス間の短距離無線通信のためのプロトコル（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標））は、一定のレベルの内蔵セキュリティを有し得るものの、使用されている特定の無線プロトコルによって決定されるようなＲＴデバイスの範囲内の権限の無い外部制御デバイスを通じた特定の種類の攻撃に対しては脆弱なままである。

２．２．３．５ 遠隔サーバー
臨床的理由により、呼吸治療が処方された患者が「コンプライアンスを遵守している」（例えば、患者が自身のＲＴデバイスを１つ以上の「コンプライアンスルール」に則っているか）を決定するためのデータを入手する場合がある。ＣＰＡＰ治療についてのコンプライアンスルールの一例として、患者がコンプライアンスを遵守しているとみなすためには、患者が連続３０日間のうち少なくとも２１日間にわたってＲＴデバイスを一晩あたり少なくとも４時間にわたって使用する必要がある。患者のコンプライアンスの決定のために、ＲＴデバイスのプロバイダ（例えば、ヘルスケアプロバイダまたはデバイス製造業者）は、ＲＴデバイスとネットワークを介して例えば定期的に通信するように構成された遠隔サーバーを動作させ得る。遠隔サーバーは、患者の治療またはＲＴデバイスからの１つ以上のコンプライアンス規則の評価結果を記述するデータを入手し得る。治療データは、所定の期間にわたる利用量を計算するために用いられ得、遠隔サーバーおよび／またはＲＴデバイスによるコンプライアンス規則（単数または複数）と共に評価される。ヘルスケアプロバイダが患者が自身のＲＴデバイスをコンプライアンスルールに則って使用したと決定すると、当該ヘルスケアプロバイダは、患者がコンプライアンスを遵守している旨を第三者に通知し得る。

加えて、ＲＴデバイスの「ファームウエア」の場合、アップグレードが時々必要になる。ＲＴデバイスは、このような目的のためのアップグレードファイルを、デバイス製造業者によってネットワークを介して操作される遠隔サーバーから入手し得る。

患者の治療において、患者のＲＴデバイスと遠隔サーバーとの通信から恩恵を受ける他の態様があり得る。

このような通信をセキュアにすることは、安全性、コンプライアンスおよび／またはプライバシーの理由において重要であり得る。例えば、適切なアップグレードのみを受信側のＲＴデバイスへ確実に送信および適用すれば、ＲＴデバイスの動作に対する不正の回避を支援することが可能になる。同様に、デバイス中において生成されたデータを不正無しに確実に通信することができれば、コンプライアンス確認プロセスの完全性の確保を支援することができる。健康関連情報のデータ転送を意図されるかまたは許可された受取人のみに確実に限定することも望まれる。他の恩恵は、本技術のいくつかの形態の以下の記載から明らかになり得る。

３ 技術の簡単な説明
本技術は、呼吸器疾患の診断、改善、治療または予防において用いられる医療機器の提供に関連し、これらの医療機器は、向上した快適性、コスト、有効性、使い易さおよび製造可能性のうち１つ以上を有する。

本技術の態様は、呼吸器疾患の診断、改善、治療または予防に用いられる装置に関連する。

本技術のいくつかの態様により、呼吸治療デバイスを、権限を持つユーザと関連付けられた制御デバイスへセキュアに接続することができる。

本技術の一形態に含まれる方法によれば、制御デバイスは、呼吸治療（ＲＴ）デバイスへの物理的アクセスを介して、ＲＴデバイスにとって既知の第１の共有秘密（例えば、トークン）を入手する。次に、第１の共有秘密がセキュアではない通信回線を介して通信している両方のデバイスによって用いられることにより、比較的強力なよりセキュアな第２の共有秘密（例えば、第２のより複雑なトークン）が確立され、よってセキュアな通信回線が両者間に確立される。セキュアな通信において、第２の共有秘密が強力な暗号化方法において用いられる。

本技術のいくつかのバージョンは、呼吸治療デバイスと無線通信を行う方法を含む。本方法は、呼吸治療デバイスとのセキュアではない無線通信回線を制御デバイスが確立することを含み得る。本方法は、制御デバイスがセキュアではない無線通信回線と異なる通信回線を第１の共有秘密を介して入手することを含み得る。第１の共有秘密は、呼吸治療デバイスにとって既知であり得る。本方法は、制御デバイスが第２の共有秘密を第１の共有秘密およびセキュアではない無線通信回線を介して通信されたデータを用いて演算することを含み得る。第２の共有秘密は、呼吸治療デバイスにとって既知であり得、記第１の共有秘密よりも強力である。本方法は、制御デバイスが呼吸治療デバイスとの無線通信を第２の共有秘密に基づいて行うことを含み得る。

本方法のいくつかのバージョンにおいて、第２の共有秘密を演算することは、ディフィー−ヘルマン鍵交換を含み得る。本方法は、制御デバイスがセッション鍵を第２の共有秘密と用いて演算することを含み得る。本方法は、無線回線を介して呼吸治療デバイスと通信されるデータを制御デバイスがセッション鍵を用いて暗号化および復号化することを含み得る。いくつかのバージョンにおいて、セキュアではない無線通信回線を確立することは、呼吸治療デバイスにとって既知の対称鍵を制御デバイスが演算することを含み得る。第１の共有秘密を異なる通信回線を介して入手することは、制御デバイスによる呼吸治療デバイスへの物理的アクセスに依存し得る。第１の共有秘密を入手することは、呼吸治療デバイスのハウジング上に印刷された機械可読フォームの第１の共有秘密を制御デバイスによってスキャンすることを含み得る。機械可読フォームは、バーコードであり得る。バーコードは、ＱＲコード（登録商標）であり得る。

いくつかのバージョンにおいて、第１の共有秘密を入手することは、制御デバイスのユーザインターフェースを介して入力された第１の共有秘密を制御デバイスにより受信することを含む。本方法は、第２の共有秘密が呼吸治療デバイスにとって既知であることを制御デバイスにより確認することを含み得る。いくつかのバージョンにおいて、確認することは、第１のハッシュ値を第２の共有秘密を用いて演算することと、呼吸治療デバイスからセキュアではない無線通信回線を介して第２のハッシュ値を受信することと、第１のハッシュ値を第２のハッシュ値と比較することとを含み得る。本方法は、第１のハッシュ値が第２のハッシュ値と等しくない場合、制御デバイスのユーザインターフェースを介してユーザ出力を生成することを含み得る。第２の共有秘密は、制御デバイスと呼吸治療デバイスとの間にセキュアな無線通信回線を確立するために用いられ得る。いくつかのバージョンにおいて、方法は、第２の共有秘密からセッション鍵を演算することを含み得る。本方法は、呼吸治療デバイスの呼吸療法動作を制御するための制御パラメータ制御デバイスがセキュアな無線通信回線を介して送信することを含み得る。この制御パラメータは、圧力設定および流量設定のうち１つを含み得る。本方法は、呼吸治療デバイスの呼吸療法動作に関連するデータを制御デバイスが前記セキュアな無線通信回線を介して受信することを含み得る。データは、呼吸治療デバイスの利用時間および複数の呼吸イベントのうち任意の１つ以上を含み得る。

本技術のいくつかのバージョンは、コンピュータにより読出可能なデータ記憶媒体を含み得、データ記憶媒体には、プログラム命令が符号化され、これらのプログラム命令は、本明細書中に記載の方法（単数または複数）のうちいずれかをプロセッサに行わせるように構成される。本技術のいくつかのバージョンは、かかるコンピュータにより読出可能なデータ記憶媒体へのアクセスを有するサーバーを含み得る。サーバーは、コンピュータにより読出可能なデータ記憶媒体のプログラム命令をネットワークを介して制御デバイスへダウンロードせよとのリクエストを受信するように、構成され得る。サーバーは、プログラム命令をダウンロードせよとのリクエストに応答して、プログラム命令を送信し得る。

本技術のいくつかのバージョンは、呼吸治療デバイスと無線通信するように構成された制御デバイスを含み得る。制御デバイスは、処理命令を保存するメモリを含み得る。制御デバイスは、プロセッサを含み得る。プロセッサは、呼吸治療デバイスとのセキュアではない無線通信回線を確立するように構成され得る。プロセッサは、セキュアではない無線通信回線と異なる通信回線を介して第１の共有秘密を入手するように構成され得、第１の共有秘密は、呼吸治療デバイスにとって既知である。プロセッサは、第１の共有秘密と、セキュアではない無線通信回線を介して通信されたデータとを用いて第２の共有秘密を演算するように構成され得る。第２の共有秘密は、呼吸治療デバイスにとって既知であり得、第１の共有秘密よりも強力であり得る。

いくつかのバージョンにおいて、制御デバイスは、バーコードリーダを含み得る。プロセッサは、バーコードリーダを用いて呼吸治療デバイスのハウジング上に印刷されたバーコードをスキャンすることにより第１の共有秘密を入手するように、さらに構成され得る。バーコードは、第１の共有秘密を符号化し得る。いくつかのバージョンにおいて、制御デバイスは、ユーザ・インターフェースを含み得る。プロセッサは、ユーザインターフェースを通じて入力された入力を介して第１の共有秘密を入手するように、さらに構成され得る。

本技術のいくつかのバージョンは、呼吸治療デバイスと制御デバイスとの無線通信を行う方法を含み得る。本方法は、制御デバイスとのセキュアではない無線通信回線を呼吸治療デバイスにより確立することを含み得る。本方法は、第１の共有秘密と、セキュアではない無線通信回線を介して通信されたデータとを用いて第２の共有秘密を呼吸治療デバイスにより演算することを含み得る。第１の共有秘密および第２の共有秘密は、制御デバイスにとって既知であり得る。第２の共有秘密は、第１の共有秘密よりも強力であり得る。本方法は、制御デバイスとの無線通信を呼吸治療デバイスが第２の共有秘密に基づいて行うことを含み得る。

本技術のいくつかのバージョンは、制御デバイスと無線通信するように構成された呼吸治療デバイスを含み得る。呼吸治療デバイスは、処理命令を保存するメモリを含み得る。呼吸治療デバイスは、制御デバイスとのセキュアではない無線通信回線を確立するように構成されたコントローラを含み得る。コントローラは、第１の共有秘密と、セキュアではない無線通信回線を介して通信されたデータとを用いて第２の共有秘密を演算するように構成されたコントローラであり得る。第１の共有秘密および第２の共有秘密は、制御デバイスにとって既知であり得る。第２の共有秘密は、第１の共有秘密よりも強力であり得る。呼吸治療デバイスは、印刷バーコードを含むハウジングを含み得る。印刷されたバーコードは、第１の共有秘密を符号化し得る。

本技術のいくつかのバージョンは、呼吸治療システムを含み得る。本システムは、呼吸治療デバイスを含み得る。システムは、呼吸治療デバイスと無線通信するように構成された制御デバイスを含み得る。制御デバイスは、呼吸治療デバイスとのセキュアではない無線通信回線を確立するように構成されたプロセッサを含み得る。プロセッサは、セキュアではない無線通信回線と異なる通信回線を介して第１の共有秘密を入手するように構成され得る。第１の共有秘密は、呼吸治療デバイスにとって既知であり得る。プロセッサは、第１の共有秘密と、セキュアではない無線通信回線を介して通信されたデータとを用いて第２の共有秘密を演算するように構成され得る。第２の共有秘密は、呼吸治療デバイスにとって既知であり得、第１の共有秘密よりも強力であり得る。プロセッサは、呼吸治療デバイスとの無線通信を第２の共有秘密に基づいて行うように構成され得る。呼吸治療デバイスは、印刷バーコードを有するハウジングを含み得る。印刷されたバーコードは、第１の共有秘密を符号化し得る。制御デバイスは、バーコードリーダをさらに含み得る。プロセッサは、バーコードリーダを用いてバーコードをスキャンすることにより第１の共有秘密を入手するように、さらに構成され得る。制御デバイスは、ユーザインターフェースをさらに含み得る。プロセッサは、ユーザインターフェースを通じて入力された入力を介して第１の共有秘密を入手するように、さらに構成され得る。

本技術の他の態様により、信用されていない制御デバイスを介して治療データが呼吸治療デバイスから遠隔サーバーへアップロードされた場合、このデータに対し、受取人が権限を付与することができる。

本技術の別の形態は、ＲＴデバイスおよび（制御デバイスではなく）サーバー双方にとって既知の秘密と、（ＲＴデバイスによる）鍵の導出のためにサーバーから供給される「ナンス」とを用いることを含む。この鍵は、治療データを認証するための認証コードを導出するために用いられる。

本技術のいくつかのバージョンは、呼吸治療デバイスとの通信および遠隔サーバーとの通信を行うように構成された制御デバイスを介して呼吸治療デバイスによって生成される治療データを遠隔サーバーへアップロードする方法を含み得る。本方法は、治療データを呼吸治療デバイスから制御デバイスが受信することを含み得る。本方法は、遠隔サーバーからナンスを制御デバイスが受信することを含み得る。本方法は、制御デバイスがナンスを呼吸治療デバイスへ送信することを含み得る。本方法は、制御デバイスが呼吸治療デバイスから署名鍵を受信することを含み得る。署名鍵は、ナンスと、呼吸治療デバイスおよび遠隔サーバーにとって既知の秘密とに依存し得る。本方法は、制御デバイスが治療データおよび署名鍵を用いて認証コードを生成することを含み得る。認証コードは、治療データの認証のために用いられ得る。本方法は、制御デバイスが治療データおよび認証コードを遠隔サーバーへ送信することを含み得る。いくつかのバージョンにおいて、認証コードは、ハッシュ化メッセージ認証コードであり得る。署名鍵は、共有秘密中へのオフセットにさらに依存し得る。オフセットは、遠隔サーバーから制御デバイスへ受信され得る。ナンスは、擬似乱数であり得る。いくつかのバージョンにおいて、制御デバイスは、呼吸治療デバイスにとって既知の対称鍵を用いて署名鍵を復号化することにより、署名鍵を呼吸治療デバイスからセキュアに受信し得る。

本技術のいくつかのバージョンは、制御デバイスを含み得る。制御デバイスは、メモリおよびプロセッサを含み得る。メモリは、プログラム命令を含み得る。プログラム命令は、プロセッサによって実行されると、呼吸治療デバイスによって生成された治療データを遠隔サーバーへアップロードすることするように制御デバイスを制御する。プログラム命令は、治療データを呼吸治療デバイスから受信するように制御デバイスを制御し得る。プログラム命令は、遠隔サーバーからナンスを受信するように制御デバイスを制御し得る。プログラム命令は、ナンスを呼吸治療デバイスへ送信するように、制御デバイスを制御し得る。プログラム命令は、呼吸治療デバイスから署名鍵を受信するように制御デバイスを制御し得る。署名鍵は、ナンスと、呼吸治療デバイスおよび遠隔サーバーにとって既知の秘密とに依存し得る。プログラム命令は、治療データおよび署名鍵を用いて認証コードを生成するように制御デバイスを制御し得る。認証コードは、治療データの認証に用いられ得る。プログラム命令は、治療データおよび認証コードを遠隔サーバーへ送信するように制御デバイスを制御し得る。

本技術のいくつかのバージョンは、呼吸治療デバイスによって生成された治療データの認証方法を含み得る。本方法は、治療データおよび第１の認証コードを受信することを含み得る。本方法は、ナンスと、呼吸治療デバイスにとって既知の秘密とから、署名鍵を演算することを含み得る。本方法は、受信された治療データおよび署名鍵から第２の認証コードを演算することを含み得る。本方法は、第１の認証コードを第２の認証コードと比較することにより、治療データを認証することを含み得る。

いくつかのバージョンにおいて、方法は、オフセットを呼吸治療デバイスへ送信することを含み得る。署名鍵は、オフセットに依存し得る。認証コードは、ハッシュ化メッセージ認証コードであり得る。本方法は、ナンスを呼吸治療デバイスへ送信することを含み得る。ナンスは、擬似乱数であり得る。

本技術のいくつかのバージョンは、サーバーを含み得る。サーバーは、メモリおよびプロセッサを含み得る。メモリは、プログラム命令を含み得る。プログラム命令は、プロセッサによって実行されると、呼吸治療デバイスによって生成された治療データを認証するようにサーバーを制御する。プログラム命令は、治療データおよび第１の認証コードを受信するようにサーバーを制御することを含み得る。プログラム命令は、ナンスと、呼吸治療デバイスにとって既知の秘密とから署名鍵を演算することを含み得る。プログラム命令は、受信された治療データおよび署名鍵から第２の認証コードを演算し得る。プログラム命令は、第１の認証コードを第２の認証コードと比較することにより、治療データを認証し得る。

本技術のいくつかのバージョンは、ネットワーク化された呼吸治療システムを含み得る。システムは、呼吸治療を患者に行うように構成された呼吸治療デバイスを含み得る。本システムは、遠隔サーバーを含み得る。システムは、呼吸治療デバイスとの通信および遠隔サーバーとの通信を行うように構成された制御デバイスを含み得る。制御デバイスは、呼吸治療デバイスからの治療データを制御デバイスにより受信するように、構成され得る。制御デバイスは、遠隔サーバーからのナンスを制御デバイスにより受信するように構成され得る。制御デバイスは、制御デバイスがナンスを呼吸治療デバイスへ送信するように構成され得る。制御デバイスは、呼吸治療デバイスから署名鍵を受信するように構成され得る。署名鍵は、ナンスと、呼吸治療デバイスおよび遠隔サーバーにとって既知の秘密とに依存し得る。制御デバイスは、治療データおよび署名鍵を用いて認証コードを生成するように構成され得る。認証コードは、治療データの認証のために用いられ得る。制御デバイスは、治療データおよび認証コードを遠隔サーバーへ送信するように構成され得る。いくつかのバージョンにおいて、呼吸治療デバイスは、呼吸圧力治療デバイスであってよい。制御デバイスは、呼吸治療デバイスとの通信を共有対称鍵を用いてセキュアに行うように構成され得る。遠隔サーバーは、治療データおよび第１の認証コードを受信するように構成され得る。遠隔サーバーは、ナンスと、呼吸治療デバイスにとって既知の秘密とから署名鍵を演算するように構成され得る。遠隔サーバーは、受信された治療データおよび署名鍵から第２の認証コードを演算するように構成され得る。遠隔サーバーは、第１の認証コードを第２の認証コードと比較することにより、治療データを認証するように構成され得る。

本技術のいくつかのバージョンは、ネットワーク化された呼吸治療システムを含み得る。ネットワーク化された呼吸治療システムは、呼吸治療を患者に行うように構成された呼吸治療デバイスを含み得る。ネットワーク化された呼吸治療システムは、呼吸治療デバイスと通信するように構成された制御デバイスを含み得る。ネットワーク化された呼吸治療システムは、制御デバイスと通信するように構成された遠隔サーバーを含み得る。遠隔サーバーは、制御デバイスから治療データおよび第１の認証コードを受信するように構成され得る。遠隔サーバーは、ナンスと、呼吸治療デバイスにとって既知の秘密とから署名鍵を演算するように構成され得る。遠隔サーバーは、受信された治療データおよび署名鍵から第２の認証コードを演算するように構成され得る。遠隔サーバーは、第１の認証コードを第２の認証コードと比較することにより、治療データを認証するように構成され得る。呼吸治療デバイスは、呼吸圧力治療デバイスであってよい。制御デバイスは、呼吸治療デバイスとの通信を共有対称鍵を用いてセキュアに行うように構成され得る。制御デバイスは、治療データを呼吸治療デバイスから受信するように構成され得る。制御デバイスは、遠隔サーバーからナンスを受信するように構成され得る。制御デバイスは、ナンスを呼吸治療デバイスへ送信するように構成され得る。制御デバイスは、呼吸治療デバイスから署名鍵を受信するように構成され得る。署名鍵は、ナンスと、呼吸治療デバイスおよび遠隔サーバーにとって既知の秘密とに依存し得る。制御デバイスは、治療データおよび署名鍵を用いて認証コードを生成するように構成され得る。認証コードは、治療データの認証のために用いられ得る。制御デバイスは、治療データおよび認証コードを遠隔サーバーへ送信するように構成され得る。

いくつかのバージョンにおいて、呼吸治療デバイスは、遠隔サーバーからナンスを受信するように構成され得る。呼吸治療デバイスは、ナンスと、呼吸治療デバイスおよび遠隔サーバーにとって既知の秘密とから、署名鍵を演算するように構成され得る。呼吸治療デバイスは、治療データおよび署名鍵を用いて認証コードを生成するように構成され得る。呼吸治療デバイスは、治療データおよび認証コードを遠隔サーバーへ送信するように構成され得る。

本技術のいくつかのバージョンは、呼吸治療デバイスによって生成された治療データを遠隔サーバーへアップロードする方法を含み得る。本方法は、遠隔サーバーからナンスを呼吸治療デバイスが受信することを含み得る。本方法は、ナンスからの署名鍵と、遠隔サーバーにとって既知の秘密とを呼吸治療デバイスによって演算することを含み得る。本方法は、呼吸治療デバイスが治療データおよび署名鍵を用いて認証コードを生成することを含み得る。認証コードは、治療データの認証に用いられる。本方法は、治療データおよび認証コードを呼吸治療デバイスから遠隔サーバーへ送信することを含み得る。認証コードは、ハッシュ化メッセージ認証コードであり得る。署名鍵は、共有秘密中へのオフセットにさらに依存し得る。オフセットは、遠隔サーバーから呼吸治療デバイスによって受信され得る。ナンスは、擬似乱数であり得る。呼吸治療デバイスは、遠隔サーバーと通信するように構成された制御デバイスを介してナンスを受信し得る。呼吸治療デバイスは、制御デバイスにとって既知の対称鍵を用いてナンスを復号化することにより、制御デバイスからナンスを受信し得る。呼吸治療デバイスは、遠隔サーバーと通信するように構成された制御デバイスを介して治療データおよび認証コードを送信し得る。制御デバイスは、制御デバイスにとって既知の対称鍵を用いて治療データおよび認証コードを暗号化することにより、治療データおよび認証コードを制御デバイスへ送信し得る。

本技術のいくつかのバージョンは、呼吸治療デバイスを含み得る。呼吸治療デバイスは、圧力生成器を含み得る。圧力生成器は、患者インターフェースへ連結することおよび陽圧の空気流れを患者インターフェースへ供給することを行うように、適合される。呼吸治療デバイスは、メモリおよびプロセッサを含み得る。メモリは、プログラム命令を含み得る。プログラム命令は、プロセッサによって実行されると、呼吸治療デバイスによって生成された治療データを遠隔サーバーへアップロードするように、呼吸治療デバイスを制御する。プログラム命令は、呼吸治療デバイス遠隔サーバーからナンスを受信するように、呼吸治療デバイスを制御し得る。プログラム命令は、ナンスからの署名鍵と、遠隔サーバーにとって既知の秘密とを演算するように、呼吸治療デバイスを制御し得る。プログラム命令は、治療データおよび署名鍵を用いて認証コードを生成するように、呼吸治療デバイスを制御し得る。認証コードは、治療データの認証に用いられ得る。プログラム命令は、治療データおよび認証コードを遠隔サーバーへ送信するように、呼吸治療デバイスを制御し得る。

本技術のいくつかのバージョンは、ネットワーク化された呼吸治療システムを含み得る。ネットワーク化された呼吸治療システムは、患者への呼吸治療の施行のための呼吸治療デバイスを含み得る。ネットワーク化された呼吸治療システムは、呼吸治療デバイスと通信するように構成された遠隔サーバーを含み得る。呼吸治療デバイスは、遠隔サーバーからナンスを受信するように構成され得る。呼吸治療デバイスは、ナンスからの署名鍵と、遠隔サーバーにとって既知の秘密とを演算するように構成され得る。呼吸治療デバイスは、治療データおよび署名鍵を用いて認証コードを生成するように構成され得る。認証コードは、治療データの認証に用いられ得る。呼吸治療デバイスは、治療データおよび認証コードを遠隔サーバーへ送信するように構成され得る。呼吸治療デバイスは、呼吸圧力治療デバイスであってよい。いくつかのバージョンにおいて、ネットワーク化された呼吸治療システムは、呼吸治療デバイスとセキュアに通信することおよび遠隔サーバーと通信することを行うように構成された制御デバイスを含み得る。制御デバイスは、呼吸治療デバイスにとって既知の対称鍵を用いて呼吸治療デバイスとセキュアに通信するように構成され得る。遠隔サーバーは、治療データおよび第１の認証コードを受信するように構成され得る。遠隔サーバーは、ナンスと、呼吸治療デバイスにとって既知の秘密とから署名鍵を演算するように構成され得る。遠隔サーバーは、受信された治療データおよび署名鍵から第２の認証コードを演算するように構成され得る。遠隔サーバーは、第１の認証コードを第２の認証コードと比較することにより、治療データを認証するように構成され得る。

本技術のいくつかのバージョンは、呼吸治療デバイスから治療データを受信するための手段を有する装置を含み得る。装置は、遠隔サーバーからナンスを受信する手段と、ナンスを呼吸治療デバイスへ送信する手段とを含み得る。この装置は、呼吸治療デバイスから署名鍵を受信する手段を含み得る。署名鍵は、ナンスと、呼吸治療デバイスおよび遠隔サーバーにとって既知の秘密とに依存する。この装置は、治療データおよび署名鍵を用いて認証コードを生成する手段を含み得る。認証コードは、治療データの認証に用いられる。この装置は、治療データおよび認証コードを遠隔サーバーへ送信する手段を含み得る。

本技術のいくつかのバージョンは、呼吸治療デバイスおよび第１の認証コードから治療データを受信する装置手段を有する装置を含み得る。この装置は、ナンスと、呼吸治療デバイスにとって既知の秘密とから、署名鍵を演算する手段を含み得る。この装置は、受信された治療データおよび署名鍵から第２の認証コードを演算する手段を含み得る。この装置は、第１の認証コードを第２の認証コードと比較することにより、治療データを認証する手段を含み得る。

本技術のいくつかのバージョンは、呼吸治療を患者へ送達するための手段を有する装置を含み得る。この装置は、遠隔サーバーからナンスを受信する手段を含み得る。この装置は、ナンスからの署名鍵と、遠隔サーバーにとって既知の秘密とを演算する手段を含み得る。この装置は、治療データおよび署名鍵を用いて認証コードを生成する手段を含み得る。認証コードは、治療データの認証に用いられる。この装置は、治療データおよび認証コードを遠隔サーバーへ送信する手段を含み得る。

本明細書中に記載される方法、システム、デバイスおよび装置により、プロセッサにおける機能（例えば、特定目的用コンピュータのプロセッサ、呼吸モニターおよび／または呼吸治療デバイスの機能）の向上が可能になり得る。さらに、記載の方法、システム、デバイスおよび装置により、呼吸疾患（例えば、閉塞性睡眠時無呼吸）の自動管理、監視および／または治療の技術分野、そしてデバイスとの通信に関わるにおける向上が可能になる。

もちろん、上記態様の一部は、本技術の下位態様を形成し得る。また、下位態様および／または態様のうち多様な１つを多様に組み合わせることができ、本技術のさらなる態様または下位態様も構成し得る。

本技術の他の特徴は、以下の詳細な説明、要約、図面および特許請求の範囲中に含まれる情報に鑑みれば明らかになる。

本技術を、添付図面中に非限定的に一実施例として例示する。図面中、類似の参照符号は、以下の類似の要素を含む：

［４．１ 治療システム］図１は、患者インターフェース３０００を装着している患者１０００を含むシステムを示す。このシステムは、鼻枕の形態をとり、ＲＴデバイス４０００から供給される陽圧の空気を受容する。ＲＴデバイス４０００からの空気は、加湿器５０００によって加湿され、空気回路４１７０に沿って患者１０００へと移動する。同床者１１００も図示される。 ［４．２ 呼吸システムおよび顔の解剖学的構造］図２は、鼻および口腔、喉頭、声帯ひだ、食道、気管、気管支、肺、肺胞嚢、心臓および横隔膜を含むヒト呼吸器系の概要を示す。 ［４．３ 患者インターフェース］図３は、本技術の１つの形態による鼻マスクの形態の患者インターフェースを示す。 ［４．４ ＲＴデバイス］図４Ａは、本技術の一形態に従ったＲＴデバイスを示す。 図４Ｂは、本技術の一形態に従ったＲＴデバイス４０００の空気圧経路の概略図である。上流と下流の方向が示されている。 図４Ｃは、本技術の一態様に従ったＲＴデバイス４０００の電気部品の概略図である。 ［４．５ 加湿器］図５Ａは、本技術の一形態による加湿器の等角図である。 図５Ｂは、本技術の一形態による加湿器の等角図であり、加湿器リザーバ５１１０を加湿器リザーバドック５１３０から除去した様子を示す。 ［４．６ セキュアなネットワーク化された呼吸治療システム］図６は、本技術の一形態による、ネットワーク化された呼吸治療システムの概略図である。 図７は、本技術の一形態による、制御デバイスおよびＲＴデバイスがその間にセキュアな通信回線を確立する際に用いられ得る方法を示すフローチャートである。 図８は、ＲＴデバイスおよび制御デバイスそれぞれが（本技術の１つの形態に従って図７の方法におけるそれぞれの役割を実行するために）実行し得る方法を示すフローチャートである。 図９は、本技術の１つの形態に従ってＲＴデバイスに対するファームウエアアップグレードをセキュアにするために図６のネットワーク化された呼吸治療システムによって実行され得る方法の模式図である。 図１０は、本技術の１つの形態に従ってサーバーへの治療データアップロードを認証するために図６のネットワーク化された呼吸治療システムによって実行され得る方法の模式図である。 図１１は、本技術の別の形態に従ってサーバーへの治療データアップロードを認証するために図６のネットワーク化された呼吸治療システムによって実行され得る方法の模式図である。

５ 本技術の実施例の詳細な説明
本技術についてさらに詳細に説明する前に、本技術は、本明細書中に記載される異なり得る特定の実施例に限定されるのではないことが理解されるべきである。本開示中に用いられる用語は、本明細書中に記載される特定の実施例を説明する目的のためのものであり、限定的なものではないことも理解されるべきである。

以下の記載は、１つ以上の共通の特性および／または特徴を共有し得る多様な実施例に関連して提供される。任意の１つの実施例の１つ以上の特徴は、別の実施例または他の実施例の１つ以上の特徴と組み合わせることが可能であることが理解されるべきである。加えて、これらの実施例のうちのいずれかにおける任意の単一の特徴または特徴の組み合わせは、さらなる実施例を構成し得る。

５．１ 治療法
一形態において、本技術は、呼吸器疾患の治療方法を含む。本方法は、患者１０００の気道の入口へ陽圧の空気流れを付加することを含む。

５．２ 呼吸治療システム
一形態において、本技術は、呼吸器疾患の治療のための呼吸治療システムを含む。呼吸治療システムは、陽圧における空気流れを患者インターフェース３０００への空気回路４１７０を介して患者１０００へ供給するＲＴデバイス４０００を含み得る。

５．３ 患者インターフェース
本技術の一態様による非侵襲的患者インターフェース３０００は、以下の機能様態を含む：シール形成構造３１００、プレナムチャンバ３２００、位置決めおよび安定化構造３３００、通気孔３４００、空気回路４１７０への接続のための一形態の接続ポート３６００、および前額支持部３７００。いくつかの形態において、機能様態が、１つ以上の物理的コンポーネントによって提供され得る。いくつかの形態において、１つの物理的コンポーネントは、１つ以上の機能様態を提供し得る。使用時において、シール形成構造３１００は、気道への陽圧での空気供給を促進するように、患者の気道の入口を包囲するように配置される。

５．４ ＲＴデバイス
本技術の一態様によるＲＴデバイス４０００は、機械、空気圧式、および／または電気部品を含み、１つ以上のアルゴリズム（例えば全体的にせよ部分的にせよ本明細書に記載の方法のうちいずれか）を実行するように構成され得る。ＲＴデバイス４０００は、例えば本文書中のいずれかに記載の呼吸疾患のうち１つ以上の治療のために患者の気道への入口へ陽圧における空気流れを供給するように構成され得る。

ＲＴデバイスは、外部ハウジング４０１０を持ち得る。外部ハウジング４０１０は、上部４０１２および下部４０１４の２つの部分によって形成される。さらに、外部ハウジング４０１０は、１つ以上のパネル（単数または複数）４０１５を含み得る。ＲＴデバイス４０００は、ＲＴデバイス４０００の１つ以上の内部コンポーネントを支持するシャーシ４０１６を含む。ＲＴデバイス４０００は、ハンドル４０１８を含み得る。

空気圧ＲＴデバイス４０００の空気圧経路は、１つ以上の空気回路アイテム（例えば、入口空気フィルタ４１１２、入口マフラー４１２２、空気を陽圧で供給することが可能な圧力生成器４１４０（例えば、送風機４１４２）、出口マフラー４１２４）ならびに１つ以上の変換器４２７０（例えば、圧力センサ４２７２および流量センサ４２７４）を含み得る。

空気経路アイテムのうち１つ以上は、空気圧式ブロック４０２０と呼ばれる取り外し可能な一体構造内に配置され得る。空気圧式ブロック４０２０は、外部ハウジング４０１０内に配置され得る。一形態において、空気圧式ブロック４０２０は、シャーシ４０１６によって支持されるかまたはシャーシ４０１６の一部として形成される。

ＲＴデバイス４０００は、電源４２１０、１つ以上の入力デバイス４２２０、中央コントローラ４２３０、治療デバイスコントローラ４２４０、圧力生成器４１４０、１つ以上の保護回路４２５０、メモリ４２６０、変換器４２７０、データ通信インターフェース４２８０、および１つ以上の出力デバイス４２９０を有することができる。電気コンポーネント４２００は、シングルプリント回路基板アセンブリ（ＰＣＢＡ）４２０２上に取り付けられ得る。一代替形態において、ＲＴデバイス４０００は、１つよりも多くのＰＣＢＡ４２０２を含み得る。

５．４．１ ＲＴデバイス機械および空気圧式コンポーネント
ＲＴデバイスは、以下のコンポーネントのうち１つ以上を一体ユニット中に含み得る。一代替形態において、以下のコンポーネントのうち１つ以上が、それぞれの別個のユニットとして配置され得る。

５．４．１．１ 空気フィルタ（単数または複数）
本技術の一形態によるＲＴデバイスは、空気フィルタ４１１０または複数の空気フィルタ４１１０を含み得る。

一形態において、入口空気フィルタ４１１２は、圧力生成器４１４０の空気圧経路上流の始まり部に配置される。

一形態において、出口空気フィルタ４１１４（例えば抗菌ファクタ）は、空気圧ブロック４０２０の出口と、患者インターフェース３０００との間に配置される。

５．４．１．２ マフラー（単数または複数）
本技術の一形態によるＲＴデバイスは、マフラー４１２０または複数のマフラー４１２０を含み得る。

本技術の一形態において、入口マフラー４１２２は、空気圧経路内において圧力生成器４１４０の上方に配置される。

本技術の一形態において、出口マフラー４１２４は、空気圧経路内において圧力生成器４１４０と患者インターフェース３０００との間に配置される。

５．４．１．３ 圧力生成器
本技術の一形態において、空気の流れまたは供給を陽圧において生成する圧力生成器４１４０は、制御可能な送風機４１４２である。例えば、送風機４１４２は、ボリュート内に収容された１つ以上のインペラを備えたブラシレスＤＣモータ４１４４を含み得る。送風機は、空気供給の送達を例えば約１２０リットル／分までの速度で、約４ｃｍＨ_２Ｏ〜約２０ｃｍＨ_２Ｏの範囲の陽圧で、または他の形態において約３０ｃｍＨ_２Ｏまで行うことができる。送風機については、以下の特許または特許出願のうちいずれか１つに記載があり得。本明細書中、同文献全体を参考のため援用する：米国特許第７，８６６，９４４号、米国特許第８，６３８、０１４号、米国特許第８，６３６，４７９号およびＰＣＴ特許出願公開ＷＯ２０１３／０２０１６７。

圧力生成器４１４０は、治療デバイスコントローラ４２４０の制御下にある。

他の形態において、圧力生成器４１４０は、ピストン駆動ポンプ、高圧源（例えば、圧縮空気リザーバ）へ接続された圧力調節器、またはベローズであり得る。

５．４．１．４ 変換器（単数または複数）
変換器は、ＲＴデバイスの内部に設けてもよいし、あるいはＲＴデバイスの外部に設けてもよい。外部変換器は、例えば空気回路上に配置してもよいし、あるいは空気回路の一部を形成してもよい（例えば、患者インターフェース）。外部変換器は、非接触センサの形態をとり得る（例えば、データＲＴデバイスを送るかまたは移動させるドップラーレーダー移動センサ）。

本技術の一形態において、１つ以上の変換器４２７０が、圧力生成器４１４０の上流および／または下流に配置され得る。１つ以上の変換器４２７０は、空気流れの特性を示す信号（例えば、空気圧経路中の当該ポイントにおける流量、圧力または温度）を生成するように、構築および配置され得る。

本技術の一形態において、１つ以上の変換器４２７０は、患者インターフェース３０００の近隣に配置され得る。

一形態において、変換器４２７０からの信号が、（例えば、ローパス、ハイパスまたはバンドパスフィルタリングによって）フィルタリングされ得る。

５．４．１．４．１ 流量センサ
本技術による流量センサ４２７４は、差圧変換器（例えば、ＳＥＮＳＩＲＩＯＮからのＳＤＰ６００シリーズ差圧変換器）に基づき得る。

一形態において、流量センサ４２７４からの流量を示す信号が、中央コントローラ４２３０によって受信される。

５．４．１．４．２ 圧力センサ
本技術による圧力センサ４２７２は、空気圧経路と流体連通して配置され得る。適切な圧力センサの一実施例として、ＨＯＮＥＹＷＥＬＬ ＡＳＤＸシリーズからの変換器がある。別の適切な圧力センサとして、ＧＥＮＥＲＡＬ ＥＬＥＣＴＲＩＣからのＮＰＡシリーズからの変換器がある。

一形態において、圧力センサ４２７２からの信号は、中央コントローラ４２３０によって受信され得る。

５．４．１．４．３ モータ速度変換器
本技術の一形態において、モータ４１４４および／または送風機４１４２の回転速度を決定するために、モータ速度変換器４２７６が用いられ得る。モータ速度変換器４２７６からのモータ速度信号は、治療装置コントローラ４２４０へ提供され得る。モータ速度変換器４２７６は、例えば速度センサであり得る（例えば、ホール効果センサ）。

５．４．１．５ アンチスピルバック弁
本技術の一形態において、アンチスピルバック弁４１６０が、加湿器５０００と、空気圧ブロック４０２０との間に配置され得る。アンチスピルバック弁は、水が加湿器５０００から上流に（例えば、送風機のモータ４１４４へ）流れる危険性を低減させるように、構築および配置される。

５．４．２ ＲＴデバイス電気部品
５．４．２．１ 電源
電源４２１０は、ＲＴデバイス４０００の外部ハウジング４０１０の内部または外部に配置され得る。

本技術の一形態において、電源４２１０は、ＲＴデバイス４０００にのみ電力を供給する。本技術の別の形態において、電源４２１０から、電力がＲＴデバイス４０００および加湿器５０００双方へ提供される。

５．４．２．２ 入力デバイス
本技術の一形態において、ＲＴデバイス４０００は、患者がデバイスと相互作用を可能にするための入力デバイス４２２０を含む。１つのこのような形態において、入力デバイス４２２０は、１つ以上のボタン、スイッチまたはダイヤルを含む。

５．４．２．３ 中央制御装置
本技術の一形態において、中央コントローラ４２３０は、ＲＴデバイス４０００の制御に適した１つまたは複数のプロセッサである。

適切なプロセッサは、ＡＲＭ ＨｏｌｄｉｎｇｓからのＡＲＭ（登録商標）Ｃｏｒｔｅｘ（登録商標）−Ｍプロセッサに基づいたプロセッサであるｘ８６ＩＮＴＥＬプロセッサを含み得る（例えば、ＳＴ マクロ電子からのＳ（登録商標）３２シリーズのマイクロコントローラ）。本技術の特定の代替形態において、３２ビットＲＩＳＣ ＣＰＵ（例えば、ＳＴ ＭＩＣＲＯ電子ＳからのＳＴＲ９シリーズマクロコントローラ）または１６ビットＲＩＳＣ ＣＰＵ（例えば、ＴＥＸＡＳ ＩＮＳＴＲＵＭＥＮＴＳによって製造されたマクロコントローラのＭＳＰ４３０ファミリーからのプロセッサ）も適切であり得る。

本技術の一形態において、中央コントローラ４２３０は、専用電子回路である。

一形態において、中央コントローラ４２３０は、特定用途向け集積回路である。別の形態において、中央コントローラ４２３０は、個別電子コンポーネントを含む。

中央コントローラ４２３０は、１つ以上の変換器４２７０、１つ以上の入力デバイス４２２０および加湿器５０００から入力信号（複数）を受信するように、構成され得る。

中央コントローラ４２３０は、出力信号（複数）を出力デバイス４２９０、治療装置コントローラ４２４０、データ通信インターフェース４２８０および加湿器５０００のうち１つ以上へ提供するように、構成され得る。

本技術のいくつかの形態において、中央制御装置４２３０は、本明細書中に記載の１つ以上の方法を具現するように、構成される（例えば、非一時的なコンピュータで読出可能な記録媒体（例えば、メモリ４２６０）中に記録されたコンピュータプログラムまたは「ファームウェア」として表現された１つ以上のアルゴリズム）。例えば、１つのアルゴリズムが、呼吸治療時における患者の呼吸イベントを検出し得る。

５．４．２．４ 時計
ＲＴデバイス４０００は、中央コントローラ４２３０へ接続された時計４２３２を含み得る。

５．４．２．５ 治療デバイスコントローラ
本技術の一形態において、治療デバイスコントローラ４２４０は治療制御モジュールであり、中央制御装置４２３０によって実行されるアルゴリズムの一部を形成する。

本技術の一形態において、治療装置コントローラ４２４０は、専用モータ制御集積回路である。例えば、一形態において、ＯＮＳＥＭＩによって製造されたＭＣ３３０３５ブラシレスＤＣモータコントローラが用いられる。

５．４．２．６ 保護回路
本技術による１つ以上の保護回路４２５０は、電気保護回路、温度および／または圧力安全回路を含み得る。

５．４．２．７ メモリ
本技術の一形態によれば、ＲＴデバイス４０００は、メモリ４２６０（例えば、不揮発性メモリ）を含む。いくつかの形態において、メモリ４２６０は、電池式スタティックＲＡＭを含み得る。いくつかの形態において、メモリ４２６０は、揮発性ＲＡＭを含み得る。

メモリ４２６０は、ＰＣＢＡ４２０２上に配置され得る。メモリ４２６０は、ＥＥＰＲＯＭまたはＮＡＮＤフラッシュの形態をとり得る。

追加的にまたは代替的に、ＲＴデバイス４０００は、取り外し可能なメモリ４２６０（例えば、セキュアデジタル（ＳＤ）規格に従って作製されたメモリカード）を含む。

本技術の一形態において、メモリ４２６０は、非一時的コンピュータで読出可能な記録媒体として機能する。この記録媒体上に、本明細書中に記載の１つ以上の方法を表現するコンピュータプログラム命令（例えば、上記の１つ以上のアルゴリズム）が記録される。

５．４．２．８ 通信
本技術の一形態において、データ通信インターフェース４２８０が設けられ、中央コントローラ４２３０へ接続される。データ通信インターフェース４２８０は、遠隔外部通信ネットワーク４２８２および／またはローカル外部通信ネットワーク４２８４へ接続可能であり得る。遠隔外部通信ネットワーク４２８２は、遠隔外部デバイス４２８６へ接続可能であり得る。ローカル外部通信ネットワーク４２８４は、ローカル外部デバイス４２８８へ接続可能であり得る。ローカル外部通信ネットワーク４２８４は、有線であってもよく、無線であってもよい。

一形態において、データ通信インターフェース４２８０は、中央コントローラ４２３０の一部である。別の形態において、データ通信インターフェース４２８０は、中央コントローラ４２３０と別個であり、集積回路またはプロセッサを含み得る。

５．４．２．９ 出力デバイス
本技術による出力デバイス４２９０は、視覚、音声および触覚ユニットのうち１つ以上の形態をとり得る。１つの形態において、出力デバイス４２９０は、以上のＬＥＤを含み得る。

出力デバイス４２９０および入力デバイス４２２０は、ＲＴデバイス４０００のユーザインターフェースと総称され得る。

５．５ 空気回路
本技術の一態様による空気回路４１７０は、使用時において空気流れが２つのコンポーネント（例えば、ＲＴデバイス４０００および患者インターフェース３０００）間に移動するように、構築および配置された導管またはチューブである。

５．６ 加湿器
本技術の一形態において、患者へ送達されるべき空気またはガスの絶対湿度を周囲空気に相対して変化させるための加湿器５０００が提供される（例えば、図５Ａに示すようなもの）。典型的には、加湿器５０００は、患者気道へ送達される前に空気流れの（周囲空気に相対する）絶対湿度を増加させかつ温度を増加させるために、用いられる。

加湿器５０００は、加湿器リザーバ５１１０と、空気流れを受容する加湿器入口５００２と、加湿された空気流れを送達させるための加湿器出口５００４とを含み得る。図５Ａおよび図５Ｂに示すようないくつかの形態において、加湿器リザーバ５１１０の入口および出口はそれぞれ、加湿器入口５００２および加湿器出口５００４であり得る。加湿器５０００は、加湿器ベース５００６をさらに含み得る。加湿器ベース５００６は、加湿器リザーバ５１１０を受容するように適合され得、加熱要素５２４０を含み得る。

５．７ セキュアなネットワーク化された呼吸治療
図６は、本技術の一形態による、いくつかの外部エンティティとともに図示されたネットワーク化された呼吸治療システム６０００の概略図である。システムは、ＲＴデバイス４０００を含む。ＲＴデバイス４０００は、陽圧における空気流れを図１に示したような患者インターフェース３０００への空気回路４１７０を介して患者１０００へ供給するように構成される。

ＲＴデバイス４０００は、制御デバイス６０１０と無線接続６０１５を介して通信する。制御デバイス６０１０は、患者１０００と関連付けられる。制御デバイス６０１０は、図４Ｃのローカル外部デバイス４２８８に対応し得、無線接続６０１５は、ローカル外部通信ネットワーク４２８４に対応し得る。制御デバイス６０１０は、ＲＴデバイス４０００用の制御デバイスである（例えば、特殊目的用ソフトウェアアプリケーションまたは「アプリ（ａｐｐ）」の実行により構成される専用の「遠隔制御」または汎用演算デバイス）。このようなソフトウェアアプリケーションは、制御デバイス６０１０によりサーバー（例えば、ウェブサーバー）からネットワーク（例えば、イントラネットまたはインターネット）を介してダウンロードされ得る。制御デバイス６０１０は、携帯用であり得る。いくつかの形態において、無線接続６０１５は、１つ以上の無線通信プロトコル（例えば、ＢｌｕｅｔｏｏｔｈまたはＢｌｕｅｔｏｏｔｈＬＥ、ＮＦＣ、または消費者赤外線プロトコル）を用いる。よって、無線接続６０１５において、（制御デバイスとＲＴデバイスとの間の直接リンクであり得る）短距離または低エネルギーネットワーキングが用いられ得る。

図６は、無線接続６０２５を介してＲＴデバイス４０００と通信する第２の制御デバイス６０２０も示す。しかし、第２の制御デバイス６０２０は、呼吸治療システム６０００の一部を形成しない。無線接続６０２５が無線接続６０１５と同じプロトコルを用いる場合、第２の制御デバイス６０２０を所有している犯罪者６０３０が、制御デバイス６０１０とＲＴデバイス４０００との間の無線接続６０１５のセキュリティを第２の制御デバイス６０２０を介して危険にさらす可能性がある。この理由のため、第２の制御デバイス６０２０は、権限の無い制御デバイス６０２０と呼ばれ得る。権限の無い制御デバイス６０２０から提示される多様な脅威に対して無線接続６０１５をセキュアにするための配置構成について、以下により詳細に説明する。

ネットワーク化された呼吸治療システム６０００は、無線接続６０５０を介して制御デバイス６０１０と通信する遠隔サーバー６０４０も含む。遠隔サーバー６０４０は、制御デバイス（例えば、制御デバイス６０１０）にとって無線接続６０５０を介して１つ以上のネットワーク（例えば、インターネットまたはインターネット）を通じてアクセス可能であり得る。よって、無線接続６０５０は、遠隔サーバーに対して間接的ネットワーキングリンクとして機能し得る。このような無線ネットワーキングを挙げると、例えばＷＩＦＩネットワーク、Ｂｌｕｅｔｏｏｔｈネットワーク、無線セルラーネットワーク（例えば、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ（ＧＳＭ（登録商標））ネットワーク）がある。よって、無線接続６０５０においては、無線接続６０１５と比較して長距離無線通信が用いられ得る。制御デバイス６０１０は、ＲＴデバイス４０００と、遠隔サーバー６０４０との間の仲介者として機能するように構成され得る。ネットワーク化された呼吸治療システム６０００は、他のＲＴデバイス（図示せず）を含み得る。これらの他のＲＴデバイス（図示せず）はそれぞれ、対応する制御デバイス（図示せず）によって制御され、対応する無線接続（図示せず）を含む回してサーバー６０４０と通信する。そのため、サーバー６０４０は、複数のＲＴデバイス４０００として機能するように構成され、これらのデバイス間の混乱は無い。

ＲＴデバイス４０００は、呼吸療法に関連するデータ（例えば、利用時間、呼吸イベント数、またはコンプライアンス規則評価結果）を接続６０１５を介して制御デバイス６０１０へ送信するように構成され得る。その後、このような治療データは、制御デバイス６０１０から接続６０５０を介してサーバー６０４０へアップロードされ得る。制御デバイス６０１０は、呼吸療法に関する制御パラメータ（例えば、コンプライアンス規則）を接続６０１５を介してＲＴデバイス４０００へ送信するように、構成され得る。このような制御パラメータは、制御デバイス６０１０によりサーバー６０４０から接続６０５０を通じてダウンロードされ得る。制御デバイス６０１０は、アップグレードＲＴデバイス４０００のファームウエアへ接続６０１５を介して送信するようにも、構成され得る。このようなアップグレードは、制御デバイス６０１０によりサーバー６０４０から接続６０５０を通じてダウンロードされ得る。

図６は、演算デバイス６０６０が無線接続６０７０を介してサーバー６０４０と通信する様子も示す。しかし、演算デバイス６０６０は、ネットワーク化された呼吸治療システム６０００の一部を形成しない。加えて、演算デバイス６０６０は、ＲＴデバイスと通信していないため、関連付けられていない（制御）デバイスと呼ばれる。無線接続６０７０が無線接続６０５０と同じプロトコルを利用しており、かつ、（サーバー６０４０を正当な制御デバイス６０１０のようにみせるために）関連付けられていないデバイス６０６０が制御デバイス６０１０上において実行しているａｐｐの「スプーフィングされた」バージョンを実行させている場合、関連付けられていないデバイス６０６０を所有している犯罪者６０６５がネットワーク化された呼吸治療システム６０００（特にサーバー６０４０）の動作を関連付けられていないデバイス６０６０を介して危険にさらす可能性が有る。関連付けられていないデバイス６０６０によって提示される多様な脅威に対してサーバー６０４０をセキュアにするための配置構成について、以下により詳細に説明する。

ネットワーク化された呼吸治療システム６０００に対する脅威の第３のカテゴリは、ＲＴデバイス４０００と通信している制御デバイス６０１０が犯罪者（図示せず）の制御下にある場合に発生する。犯罪者は、権限を持つ制御デバイス上において実行している「スプーフィングされた」バージョンのａｐｐを制御デバイス６０１０上にインストールしている。このスプーフィングされたバージョンは、不法な目的のために、サーバー６０４０および／またはＲＴデバイス４０００に対して、権限を持つ制御デバイスであるかのように見せかけることを試みる。そのため、このような制御デバイス６０１０は、「スプーフィングされた」制御デバイスと呼ばれる。換言すると、サーバー６０４０は、自身と通信している任意の制御デバイス６０１０が「スプーフィング」されていないことを確信することができず、そのため、ネットワーク化された呼吸治療システム６０００中の任意の制御デバイス６０１０を信頼できないものとして取り扱う必要がある。このようなスプーフィングされた制御デバイス６０１０によって提示される多様な脅威に対してサーバー６０４０をセキュアにするための配置構成について、以下により詳細に説明する。

５．７．１ ＲＴデバイスおよび制御デバイス
上記したように、ＲＴデバイス４０００と制御デバイス６０１０との間の無線通信６０１５のセキュリティ違反が権限の無い制御デバイス６０２０によって行われる事態を回避することが、望まれる。制御デバイス６０１０とＲＴデバイス４０００との間のセキュアな通信回線の確立の複雑性を最小化させることも、さらに望まれる。さらに、極めて限られたユーザインターフェースともいえるものを用いて、セキュアな通信回線をＲＴデバイス４０００上に確立可能にする必要がある。ＲＴデバイス４０００の入力デバイス４２２０は、１つのボタンからなり得、ＲＴデバイス４０００の出力デバイス４２９０は、１つのＬＥＤからなり得る。しかし、この通信回線確立方法は、より高度なユーザインターフェースを備えたＲＴデバイス上にも利用可能であるべきである。

２つのデバイス間の通信回線を、双方のデバイスにとって既知でありかつ他のデバイスにとって未知である対称鍵を両者のデバイス間の通信を暗号化および復号化に用いることにより、セキュアにすることができる。通信回線のセキュリティは、対称鍵の暗号法の「強度」に直接関連する。強度は、可能な鍵値の数と、選択された値のエントロピーまたはランダム性とに概して等しい。一般的に、任意の値の発生する確率が可能な値全てについて同じである鍵について、可能な値の数が大きいほど、当該鍵のエントロピーおよび強度も増す。このようなセキュアな通信回線の確立における１つの困難として、双方のデバイスにとって既知の対称鍵を作製する際、未暗号化状態の通信がこれら２つのデバイス間にあるときに盗聴することができる権限の無い制御デバイス（例えば、６０２０）からこの対称鍵を秘密に保つことがある。

図７は、方法７０００を示すフローチャートである。方法７０００は、本技術の１つの形態に従って制御デバイス６０１０およびＲＴデバイス４０００が両者間にセキュアな通信回線を確立させるために両者によって用いられ得る。すなわち、制御デバイス６０１０および／またはＲＴデバイス４０００のコントローラまたはプロセッサは、例えば図７および図８に関連して本明細書中に記載のように方法を行う（例えば、プログラムされる）ように構成され得る。

方法７０００は、ステップ７０１０から開始する。ステップ７０１０において、制御デバイス６０１０およびＲＴデバイス４０００は、両者間に通信回線を確立する。このステップは、ＲＴデバイス４０００のユーザインターフェース上への何らかの入力活性化の（例えば、ＲＴデバイス４０００のユーザインターフェースの一部を形成するボタン４２２０の押圧）により、開始され得る。ＲＴデバイス４０００は、患者、臨床医または認証された技術者（例えば、医療装置プロバイダの技術者）のうち任意の１人以上に対するこのような活性化入力の利用可能性を制限または許可するように、構成され得る。ＬＥＤ４２９０も、ＲＴデバイス４０００のユーザインターフェースの一部を形成し、ＲＴデバイス４０００を制御デバイスへ接続する準備ができている旨を示すために強制発光をオンまたはオフし得る。このような開始アクションの結果、ＲＴデバイス４０００へ現在接続されている任意の制御デバイスが接続解除される。よって、ＲＴデバイス４０００との既存の制御関連通信回線は、ＲＴデバイス４０００によって終了される。

用いられる無線プロトコルが標準的な通信プロトコル（例えば、Ｂｌｕｅｔｏｏｔｈ）である方法７０００の実行様態において、ユーザの開始アクションに応答して、ＲＴデバイス４０００は、「発見可能」モードに入る。すなわち、プロトコル（例えば、Ｂｌｕｅｔｏｏｔｈ）をサポートするデバイスは、ステップ７０１０の一部としてＲＴデバイスとペアリングされ得る。１つのこのような実行様態において、これらのデバイスは、（例えばＢｌｕｅｔｏｏｔｈ Ｃｏｒｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ［１］のＬｉｓｂｏｎ ｒｅｌｅａｓｅのＳｉｍｐｌｅ ペアリング機能のＪｕｓｔ Ｗｏｒｋｓ関連付けモデルの使用により）対称鍵共有により暗号化された通信回線を両者間に確立させるように、構成される。次に、各デバイスは、共有対称鍵を用いて通信を暗号化および復号化し得る。Ｓｉｍｐｌｅ ペアリングを用いた場合、ｌｅｇａｃｙ Ｂｌｕｅｔｏｏｔｈ２．０＋ＥＤＲ（およびそれ以前）のペアリングに対する受動的盗聴攻撃に対する保護強度に等しい保護強度が得られる（ただし、後者が１６文字の大文字・小文字を区別する英数字ＰＩＮを用いた場合（およそ９５ビットのエントロピー））。その場合、使用がずっと簡単になるという利点が得られる。Ｓｉｍｐｌｅ ＰａｉｒｉｎｇのＪｕｓｔ Ｗｏｒｋｓ関連付けモデル下においては、ユーザは、制御デバイスのユーザインターフェース６０１０上において「はい／いいえ」制御について「はい」を選択することによりペアリングを受諾する以外はしなくてよい。Ｊｕｓｔ Ｗｏｒｋｓは、単一のボタン４２２０およびＬＥＤ４２９０からなる最も単純なユーザインターフェースを備えたＲＴデバイスに特に適している。なぜならば、このようなデバイスの場合、Ｓｉｍｐｌｅ ＰａｉｒｉｎｇのＮｕｍｅｒｉｃ Ｃｏｍｐａｒｉｓｏｎ関連付けモデルに必要とされるような不定の英数字コードを表示できなくなり得るからである。ステップ７０１０の他の実行様態（用いられる無線プロトコルがＢｌｕｅｔｏｏｔｈであるものを含む）において、ステップ７０１０によって確立される通信回線は、未暗号化状態である（すなわち、「クリアな」通信回線である）。

ステップ７０１０の結果、双方のデバイスは、両者間の双方向通信のための通信回線へのアクセスを有する。ＬＥＤ４２９０は、ステップ７０１０の完了を連続的な照光により示し得る。通信回線が未暗号化状態である場合、受動的盗聴のリスクに起因してセキュアではないとみなされる。

アクティブな権限の無い制御デバイス（例えば、６０２０）は、発見可能モードにあるとき、ＲＴデバイス４０００を発見し得る。Ｊｕｓｔ Ｗｏｒｋｓ関連付けモデルを介してＲＴデバイス４０００とペアリングして、これにより、制御デバイス６０１０へのサービスを拒否し得る。

この可能性を低減するために、いくつかの実行様態において、ステップ７０１０を開始するユーザアクションの効果は期限があり得る（例えば、「発見可能ウィンドウ」内）。このような実行様態において、ＲＴデバイス４０００が発見可能であるのは、発見可能ウィンドウ内（例えば、６２秒間の長さのもの）内においてのみであり得る。発見可能ウィンドウから外れると、ＲＴデバイス４０００は、標準的なプロトコルで通信している全デバイス（例えば、Ｂｌｕｅｔｏｏｔｈデバイス）から発見することはできなくなる。これは、ＬＥＤ４２９０の消光によって示され得る。その結果、権限の無い制御デバイス（例えば、６０２０）がＲＴデバイス４０００との通信においてサービスの必要性を拒否しようと試みる期間が、制御デバイス６０１０もＲＴデバイス４０００とのペアリングをアクティブに試行している短いインタバルに制限される。

権限の無い制御デバイス６０２０がＲＴデバイス４０００とのペアリングに万が一成功した場合、その固有のペアリングを特定の所定の期限までに完了できないため、この状況を制御デバイス６０１０を検出することができる。制御デバイス６０１０は、この失敗をユーザへ通信し得、開始アクション（例えば、ＲＴデバイス４０００上のボタン４２２０の押圧）を繰り返すようユーザを促し得る。この開始アクションの結果、上記したように、ＲＴデバイス４０００とペアリングされた全制御デバイスが接続解除される。１つの実行様態において、発見可能ウィンドウは、第１のペアリング試行よりも第２およびその後のペアリング試行においてより長時間継続し得る。

サービス拒否よりも深刻な脅威として、発見可能ウィンドウ時に権限の無い制御デバイス６０２０が（デバイス６０１０または４０００のいずれにも検出されずに）「審判」（ＭＩＴＭ）になり得る状況がある。審判攻撃は、権限の無い制御デバイス６０２０がＢｌｕｅｔｏｏｔｈペアリング動作において各デバイスに対してその他のデバイスのようにみせかけたときに発生する。次に、権限の無い制御デバイス６０２０は、これら２つのデバイス間の情報をリレーして、あたかもこれら２つのデバイスが直接ペアリングされているかのような幻想を各デバイスに付与し、対称鍵を演算する。よって、対称鍵を知った後、権限の無い制御デバイス６０２０は、これら２つのデバイス間の通信回線を盗聴することが可能になり得、通信回線への情報挿入および情報変更を行い得る（これは、「アクティブ盗聴」として知られている）。よって、ＲＴデバイス４０００と制御デバイス６０１０との間において対称鍵を交換または共有する場合も、ステップ７０１０によって確立された通信回線は、（上記したＪｕｓｔ ＷｏｒｋｓＳｉｍｐｌｅ Ｐａｉｒｉｎｇおよび／または「発見可能ウィンドウ」選択肢を用いた場合であっても）少なくともアクティブ盗聴についてはセキュアではないとみなされる。

方法７０００を参照して、制御デバイス６０１０がＲＴデバイス４０００とのセキュアではない通信回線の確立をステップ７０１０において成功した後は、ＲＴデバイス４０００は、標準的なプロトコルで通信している他のデバイスから自身を発見できないようにし得る。次に、受動的盗聴およびアクティブ盗聴の危険性を低減するために、ステップ７０２０および７０３０が実行され得る。ステップ７０２０および７０３０において、第１の共有秘密（例えば、トークン）が確立され、この第１の共有秘密をセキュアではない通信回線を介した通信により第２の共有秘密（例えば、第１の共有秘密よりも強力な第２のより複雑なトークン）へ変換する。第１の共有秘密は、権限の無い制御デバイス（例えば、６０２０）にとって既知であり得るため、ステップ７０１０において確立された対称鍵になることはできないし、ステップ７０１０から導出することもできない。よって、ステップ７０２０の目的は、ステップ７０１０において確立されたセキュアではない通信回線と異なる通信回線を用いて第１の共有秘密を確立することである。

制御デバイス６０１０と、権限の無い制御デバイス６０２０との間の共通の有意な差として、前者はＲＴデバイス４０００への物理的アクセスを有するが、後者はそうではない点がある。ステップ７０２０においては、この差を利用して、制御デバイス６０１０とＲＴデバイス４０００との間に第１の共有秘密を確立する。このような第１の秘密は、例えば製造業者によって事前決定され得、これにより、第１の秘密をＲＴデバイス４０００により例えばユーザへ分配できるようにする。よって、ＲＴデバイス４０００内のコントローラは、第１の秘密に基づいて分配するように、（例えば、第１の秘密と共に）事前プログラムされ得る。このような第１の秘密は、制御デバイス６０１０のために／制御デバイス６０１０によって入手されると、共有のものになる。第１の秘密は、制御デバイス６０１０とＲＴデバイス４０００との間にステップ７０１０において確立されたセキュアではない通信回線と異なる通信回線または媒体（例えば，図６中の通信回線６０１３）を介して、制御デバイス６０１０によって入手され得る。例えば、ステップ７０２０において、制御デバイス６０１０は、ＲＴデバイス４０００にとって既知のトークンまたは合い鍵を異なる通信回線６０１３を介して入手する。トークンまたは合い鍵は、第１の共有秘密とみなされ得る。合い鍵は、単一の製造業者から発生した各ＲＴデバイス４０００について異なり得、ランダム化され得る。異なる通信回線６０１３は、「帯域外」機構と呼ばれることがある。ステップ７０２０のいくつかの実行様態は、制御デバイス６０１０からＲＴデバイス４０００への物理的アクセスを利用し得る。他のこのような「異なる通信回線」による転送を、ステップ７０２０において（例えば、電話、郵便、ユーザ／取扱説明書、製造業者ウェブサイトアへのクセス、特定のＲＴデバイス４０００に固有の他の分配された材料（例えば、製造業者からのもの）を介して）用いてもよい。

次に、ステップ７０３０において、制御デバイス６０１０およびＲＴデバイス４０００は、トークンまたは合い鍵と、セキュアではない通信回線を介した情報交換（例えば、鍵交換）とを用いて、第２の共有秘密を確立する。よって、一方のデバイスまたは双方のデバイスは、（１）セキュアではない通信回線を介して通信されなかった第１の共有秘密および（２）セキュアではない通信回線を介して通信されなかった交換された情報から第２の共有秘密を別個に生成し得る。この第２の共有秘密は、先行トークンよりも複雑なトークン（例えば、よりビット数、桁数および／または文字数が大きい）であり得、「認証鍵」とみなされ得る。次に、第２の共有秘密を用いて、「セッション鍵」として知られる対称鍵を導出および生成することができる。第２の共有秘密またはセッション鍵のどちらも、セキュアではない通信回線上の通信を通じて交換する必要は無い。次に、どちらもセッション鍵を所有している制御デバイス６０１０およびＲＴデバイス４０００は、通信のためのセッション鍵（例えば、暗号化および復号化）を用いることにより、ステップ７０１０において確立されたセキュアではない通信回線よりもセキュアな通信回線を確立させる。合い鍵を知らなければ、権限の無いＭＩＴＭ制御デバイスは、第２の共有秘密またはセッション鍵を演算または導出することはできないため、ステップ７０３０時にセキュアではない通信回線内においてやり取りされたデータを全て知っていたとしても、ステップ７０３０時に確立された通信回線を盗聴することはできない。すなわち、権限の無いＭＩＴＭ制御デバイスは、セッション鍵を知らなければ、セッション鍵を用いて暗号化された情報を復号化することもできないし、分かり易い情報を通信回線に挿入することもできない。そのため、ステップ７０３０において確立された通信回線は、ステップ７０１０において確立されたセキュアではない通信回線よりもセキュアとみなされ得る。

ステップ７０２０の１つの「物理的アクセス」実行様態において、合い鍵は、ＲＴデバイス４０００の物理的部分（例えば、ハウジング４０１０）上に印刷されたトークンであるか、または、ＲＴデバイス４０００により分配され得るそのユーザマニュアル／取扱説明書または他の文書である。合い鍵は、人間が解読可能な形態、機械可読フォームまたは両方で印刷され得る。機械可読フォームの一実行様態において、トークンは、人間が簡単に理解することができないよう、難読化が施され得る。例えば、１つのこのような実行様態として、トークンは、バーコード６０１７（例えば、ＱＲコード）として符号化されるか、ハウジング４０１０上に印刷されるか、または他の符号化された図記号／表示とされ得る。このような実行様態において、制御デバイス６０１０は、バーコードリーダ（例えば、カメラおよび関連付けられたバーコード復号化画像処理機能）と共に構成され、ステップ７０２０において、制御デバイス６０１０は、バーコードリーダを用いてバーコードをスキャンし、よって合い鍵を入手する。人間が解読可能な形態の１つの実行様態において、合い鍵は、ハウジング４０１０上に英数字様態で印刷される。ステップ７０２０のこのような実行様態において、制御デバイス６０１０は、制御デバイス６０１０のユーザインターフェースへのユーザ手入力を通じて、合い鍵を入手する。１つのこのような実行様態において、人間が解読可能な形態の合い鍵は、１０進数が５個の数値コードである（１０００００個の可能性）。このような合い鍵は、エントロピーはおよそ１６ビットにしかならないため、「弱い」。別の実行様態において、人間が解読可能な形態の合い鍵は、１０進数が４個の桁数値コード（例えば、「７４０９」）であり、同様に弱いものとみなされ得る。

上記したように、合い鍵は、機械可読の形態および人間が解読可能な形態双方でハウジング４０１０上に印刷され得る。このような実行様態において、ステップ７０２０において、先ず、制御デバイス６０１０は、機械可読フォームの合い鍵を制御デバイス６０１０内にスキャンすることを試行する。これに失敗した場合、制御デバイス６０１０は、人間が解読可能な形態の合い鍵を制御デバイス６０１０のユーザインターフェースを通じて手入力するようユーザに促す。

ステップ７０２０の別の「物理的アクセス」実行様態において、制御デバイス６０１０は、近距離無線プロトコル（例えば、近距離無線通信（ＮＦＣ））を介してＲＴデバイス４０００からトークンを入手する。ステップ７０２０の別の「物理的アクセス」実行様態において、制御デバイス６０１０は、ＲＴデバイス４０００に埋設されたＲＦＩＤタグをスキャンすることにより、トークンをＲＴデバイス４０００から入手する。ＲＦＩＤタグは、トークンを符号化する。

ステップ７０３０において、双方のデバイスは、共有（対称）認証鍵の演算のためにセキュアではない通信回線を介して通信することにより、鍵交換プロトコルを共に実行する。ステップ７０２０において入手された合い鍵（第１の共有秘密）は、ステップ７０３０において鍵交換の認証に用いられる。ステップ７０３０のいくつかの実行様態において、ディフィー−ヘルマンに基づいた鍵交換プロトコルが用いられ得る（例えば、セキュアなリモートパスワード（ＳＲＰ）プロトコル）。ステップ７０３０の１つの実行様態において、ＳＲＰ６ａ［２］として知られる一種のディフィー−ヘルマンに基づいたプロトコルが用いられる。ＳＲＰ６ａは、以下の特性を有する：
・盗聴に対する安全性。合い鍵は、クリアな通信回線であっても暗号化された通信回線であっても、セキュアではない通信回線を介して送信されない。
・リプレイ攻撃に対する免疫。捕獲された情報をアクセス入手のために再利用することが回避される。
・オフライン辞書攻撃への抵抗。トラフィックを捕獲しても、オフラインの演算攻撃のための情報は何も得られない。
・順方向のセキュリティ。合い鍵が既知である場合、過去のセッションにより獲得されたトラフィックは、復号化から安全に守られる。
・証明書を認証を送るための通路となるバックエンド接続が不要である。

上記したように、ＳＲＰ６ａは、ディフィー−ヘルマンベースの計算反復を通じてセキュリティを達成する。ＳＲＰ６ａ下において、１つのデバイス（本技術においてはＲＴデバイス４０００）はサーバーとして指定され、他方のもの（制御デバイス６０１０）はクライアントとして指定される。サーバー（認証者）は、共有合い鍵を検証者へ変換する。次に、検証者は、ディフィー−ヘルマン指数化と組み合わされて、公開鍵を生成する。その結果、低エントロピーの合い鍵（例えば、５桁の合い鍵）と共に用いられた際のセキュリティが保持される。クライアント（ピア）は、ディフィー−ヘルマン型公開鍵も生成する。公開鍵は、セキュアではない通信回線を介して交換され、この情報から、クライアントおよびサーバー双方は、合い鍵よりも強力な共有秘密（認証鍵）を計算する。次に、任意選択的に、これら２つのデバイスは、自身の計算された認証鍵が同一であることを自身に証明するための完了したメッセージ確認シークエンスを行い得る。これは、ハッシュのシークエンスを通じて達成され、その結果は、デバイス間において交換され、比較される。いずれかの比較が失敗した場合、ステップ７０３０はアボートされる。なぜならば、この失敗は、ＭＩＴＭ制御デバイスが不正確に推測された合い鍵を用いて鍵交換に参加しようとしていることの証拠になるからである。セキュリティ増強のため、ステップ７０３０の好適な実行様態において、ステップ７０３０が同一の合い鍵と共に繰り返された場合、認証鍵が同一である可能性は統計的に低くなる。

双方のデバイスは、認証鍵セキュアな持続的ストレージのハッシュ（例えば、ＲＴデバイス４０００のためのメモリ４２６０）を保存する。上記したように、ステップ７０３０の最後のサブステップにおいて、各デバイスは、現在のセッションにおいて、暗号化／復号化のための認証鍵のハッシュからセッション鍵を演算する。セッション鍵演算は、「ナンス」と呼ばれるシングルユース乱数に基づいてもよい。「ナンス」は、１つのデバイスから他方のデバイスへ生成および送信される。一実行様態において、「ナンス」は乱数であり、サーバーによって生成され、（セッション鍵演算において双方のデバイスによって用いられる）セキュアではない通信回線を介してクライアントへ送信された後、捨象される。このサブステップを異なるナンスと共にデバイスの各後続の再ペアリングにおいて繰り返すことにより、各通信セッションのための異なるセッション鍵が演算され、これにより、上記した「順方向セキュリティ」が確立される。

合い鍵そのものは、ＲＴデバイス４０００のメモリ４２６０に保存する必要は無い。その代わりに、合い鍵のハッシュがメモリ４２６０中に保存され得る。なぜならば、これは、ＳＲＰ６ａに従ってステップ７０３０を行うためにサーバー側において必要な唯一のことであるからである。合い鍵ハッシュは、ＲＴデバイス４０００からの外部アクセスは不可能であるため、（ハッシュの保存場所である）メモリ４２６０内の場所にとってローカルまたは遠隔の外部演算デバイスへインターフェース４２８０を介してアクセスは提供できない。ステップ７０３０が完了した後は、合い鍵はその後の再ペアリング動作において使用されないため、合い鍵を制御デバイス６０１０に保存する必要は無い。

図８は、方法８０００および８０５０を示す２つのフローチャートを含む。方法８０００および８０５０は、サーバー（ＲＴデバイス４０００）およびクライアント（制御デバイス６０１０）それぞれにより、本技術の１つの形態に従って方法７０００におけるそれぞれの役割を実行するために実行され得る。

方法８０００はステップ８０１０から開始し、方法８０５０はステップ８０５５から開始する。ここで、サーバーおよびクライアントはそれぞれ、セキュアではない通信回線を相互に確立するために必要なアクションをとる（例えば、ＢｌｕｅｔｏｏｔｈプロトコルのＪｕｓｔ Ｗｏｒｋｓ Ｓｉｍｐｌｅ Ｐａｉｒｉｎｇ（ステップ７０１０））。これらのステップにおいては、双方向の点線矢印８００１によって示すように、これら２つのデバイス間にセキュアではない双方向通信が必要になる。これら２つのデバイス間の残りの通信は、方法８０００と方法８０５０との間の破線矢印によって示され（ステップ８０６０における通信を除く）、セキュアではない通信回線を介して行われる。

次に、方法８０５０のステップ８０６０が続く。ここで、クライアントは、例えばサーバーへの物理的アクセスを用いて、ステップ７０２０に関連して上記したように、合い鍵（Ｐ）または第１の共有秘密をサーバーから入手する。方法８０００および８０５０の残りのステップにおいて、方法７０００のステップ７０３０が行われる。方法８０００のステップ８０１５において、サーバーは、ソルト（ｓ）を用いてサーバー公開鍵（Ｂ）を演算する。ソルト（ｓ）は、サーバーによって生成される乱数である。ディフィー−ヘルマン鍵交換は、大きな素数（Ｎ）のモジュロの乗法群（素数群として知られる）に基づく。サーバー公開鍵（Ｂ）を計算するために、サーバーは、小さな整数（例えば、２）である群生成器（ｇ）と、素数群（Ｎ）とを用いる。先ず、サーバーは、合い鍵（Ｐ）のハッシュと連結されたソルト（ｓ）のハッシュとして指数（ｘ）を演算する：
ここで、「｜」は連結を示す。ハッシュ関数の一例として、ＳＨＡ２５６として知られる関数がある。次に、サーバーは、下記のように群生成器（ｇ）を指数（ｘ）のモジュロの素数群（Ｎ）まで上げることにより、検証者（ｖ）を演算する：

次に、サーバーは、素数群（Ｎ）および群生成器（ｇ）をハッシュすることにより、乗算器（ｋ）を演算する：
ここで、ＰＡＤ（）は、そのアーギュメントをハッシュ関数に必要な長さまで持って行くことを意図するパディング機能を示す。ＰＡＤ（）は、そのアーギュメントにゼロを付加するだけであり得るが、パディングの他の実行様態も用いられ得る。

次に、サーバーは、サーバー公開鍵 （Ｂ）を以下のように演算する：
ここで、ｂは、サーバーランダム指数である。次に、ステップ８０１５は、サーバー公開鍵（Ｂ）およびソルト（ｓ）をクライアントへ送信する。ステップ８０１５の態様はステップ８０１０後および／または通信プロセス時に行われ得るが、いくつかの場合において、公開鍵またはソルトをこのような通信の前（例えば、ステップ８０１０の前）に演算してもよく、その場合、ステップ８０１５における送信のために公開鍵またはソルトへのアクセスが可能になる。

クライアントは、方法８０５０のステップ８０６５においてサーバー公開鍵（Ｂ）およびソルト（ｓ）を受信する。クライアントは、群生成器（ｇ）および素数群（Ｎ）を知っているため、ステップ８０７０においては、群生成器（ｇ）をクライアントランダム指数（ａ）のモジュロ素数群（Ｎ）まで上げることにより、クライアント公開鍵（Ａ）を演算することができる：

またステップ８０７０において、クライアントは、クライアント公開鍵（Ａ）をサーバーへ送信する。このサーバーは、方法８０００のステップ８０２０において受信する。クライアント公開鍵（Ａ）はサーバー公開鍵（Ｂ）またはソルト（ｓ）に依存していないため、ステップ８０６５および８０７０を任意の順序で実行することができる点に留意されたい。ステップ８０７０がステップ８０６５に先行する場合、ステップ８０２０はステップ８０１５に先行し得る。

クライアントはクライアント公開鍵（Ａ）の演算において合い鍵（Ｐ）を必要としないため、ステップ８０６０はステップ８０６５および８０７０に追随し得る点にも留意されたい。しかし、いくつかの場合において、ステップ８０６０は、ステップ８０５５に先行し得る。

ステップ８０２５において、サーバーは、クライアントおよびサーバー公開鍵のハッシュ（ｕ）を演算する（ＡおよびＢ）：
次に、第２の共有秘密または認証鍵（Ｓ）をハッシュ（ｕ）、サーバーランダム指数（ｂ）、検証者（ｖ）およびクライアント公開鍵（Ａ）から以下のように演算する：

方法８０５０のステップ８０７５において、クライアントは、上記式を用いてハッシュ（ｕ）、乗算器（ｋ）および指数（ｘ）を演算する（指数（ｘ）を演算するには、ステップ８０６０において得られた合い鍵（Ｐ）が必要になる点に留意されたい）。次に、クライアントは、認証鍵（Ｓ）を以下のように演算する：

モジュロＮの計算を用いて、クライアントおよびサーバーは、ステップ８０２５および８０７５それぞれにおいて同じ認証鍵（Ｓ）を演算することが分かる。しかし、エラーまたは破損から保護するために、方法８０００および８０５０の後続ステップにおいて、サーバーおよびクライアントそれぞれが共通認証鍵（Ｓ）を共有している旨が両者に確認される。方法８０５０のステップ８０８０において、クライアントは、クライアントハッシュ値（Ｍｃｌｉｅｎｔ）を以下のように計算する：
そして、クライアントハッシュ値（Ｍｃｌｉｅｎｔ）をサーバーへ送信する。方法８０００のステップ８０３０において、サーバーは、クライアントハッシュ値（Ｍｃｌｉｅｎｔ）を受信する。次に、サーバーは、ステップ８０３５において、サーバーハッシュ値（Ｍｓｅｒｖｅｒ）を以下のように演算する：
そして、サーバーハッシュ値およびクライアントハッシュ値（ＭｓｅｒｖｅｒおよびＭｃｌｉｅｎｔ）を比較する。両者が等しくない場合、方法８０００はアボートし、セキュアな通信回線確立ステップ７０３０の失敗について、例えば制御デバイスのユーザインターフェース６０１０および／またはＲＴデバイス４０００の出力デバイス４２９０を介してユーザに通知する。

サーバーハッシュ値およびクライアントハッシュ値（ＭｓｅｒｖｅｒおよびＭｃｌｉｅｎｔ）が等しいと仮定した場合、方法８０００はステップ８０４０に進んで、サーバーは、第２のサーバーハッシュ値（ＨＡＭＫｓｅｒｖｅｒ）を以下のように演算する：

またステップ８０４０において、サーバーは、第２のサーバーハッシュ値（ＨＡＭＫｓｅｒｖｅｒ）と（サーバーがランダムに選択した）ナンスとをクライアントへ送信する。一方、方法８０５０のステップ８０８５において、クライアントは、第２のクライアントハッシュ値（ＨＡＭＫｃｌｉｅｎｔ）を以下のように演算する：

ステップ８０９０において、クライアントは、第２のサーバーハッシュ値（ＨＡＭＫｓｅｒｖｅｒ）およびナンスを受信し、第２のサーバーハッシュ値およびクライアントハッシュ値（ＨＡＭＫｓｅｒｖｅｒおよびＨＡＭＫｃｌｉｅｎｔ）を比較する。両者が等しくない場合、方法８０５０はアボートし、セキュアな通信回線確立ステップ７０３０の失敗をユーザに通知する（例えば、制御デバイス６０１０のユーザインターフェースおよび／またはＲＴデバイス４０００の出力デバイス４２９０を介してユーザ出力を生成すること）。

第２のサーバーハッシュ値およびクライアントハッシュ値（ＨＡＭＫｓｅｒｖｅｒおよびＨＡＭＫｃｌｉｅｎｔ）が等しいと仮定すると、方法８０５０はステップ８０９５へ進み、クライアントは、認証鍵（Ｓ）のハッシュおよびステップ８０９０において受信されたナンスをハッシュすることにより、セッション鍵（Ｋｓ）を演算する：

一方、方法８０００のステップ８０４５において、サーバーは、セッション鍵（Ｋｓ）を同様に演算する。

上記の配置構成により、権限の無い制御デバイス６０２０が接続６０１５をアクティブまたは受動的に盗聴する可能性が大幅に低下するため、制御デバイス６０１０とＲＴデバイス４０００との間の接続をセキュアなものとみなすことが可能になり得る。

しかし、制御デバイス６０１０とＲＴデバイス４０００との間の接続６０１５がこのようにセキュアであり、制御デバイス６０１０とサーバー６０４０との間の接続６０５０も名目上は「セキュアである」（例えば、ＳＳＬ接続プロトコルを遵守している）場合も、上記したような関連付けられていない制御デバイス６０６０およびスプーフィングされた制御デバイス６０１０に起因して、ネットワーク化された呼吸治療システム６０００に対する脅威が残っている。

５．７．２ 制御デバイスおよびサーバー
ネットワーク化された呼吸治療システム６０００内の各ＲＴデバイス（例えば、４０００）は、ＲＴデバイス自身およびサーバー６０４０にとって既知である固有の識別子により識別され得る。加えて、各ＲＴデバイス４０００は、サーバー６０４０以外の他のデバイス全てにとって既知ではない固有のデータブロックを知っており、このデータブロックは、その固有の識別子によりＲＴデバイス４０００と関連付けられた様態でサーバー６０４０内にセキュアに保存される。このデータブロックは、ＲＴデバイスの秘密と呼ばれる。制御デバイス６０１０がスプーフィングされた制御デバイスである場合でも、この秘密はＲＴデバイスとサーバー６０４０との間を仲介する制御デバイス６０１０にとって未知であるため、この秘密により、ＲＴデバイス４０００とサーバー６０４０との間のセキュリティ配置構成が可能になる。

５．７．２．１ ファームウエアのアップグレード
上記したように、ＲＴデバイス４０００のファームウエアをアップグレードすることが、場合によって必要になり得る。スプーフィングされた制御デバイス６０１０が（ＲＴデバイス４０００によって検出されることなく）アップグレードに対して不正を働き得る場合、当該制御デバイス６０１０は、ＲＴデバイス４０００の動作を変化させることが可能であるため、当該制御デバイス６０１０は呼吸療法において無効になる。よって、ファームウエアアップグレードの出所がサーバー６０４０であり、ファームウエアアップグレードがＲＴデバイス４０００のためであり、制御デバイス６０１０による不正を受けていないことをＲＴデバイス４０００が確認することができれば有用である。

図９は、方法９０００の模式図である。方法９０００は、ネットワーク化された呼吸治療システム６０００がＲＴデバイス４０００に対するファームウエアアップグレードを認証する際に用いられ得る。方法９０００において関与する３つのエンティティ（ＲＴデバイス４０００、制御デバイス６０１０およびサーバー６０４０）は、それぞれ垂直線として左側から右側に図示され、これらの間の通信および他のアクションは、時系列順に上から下へ矢印として図示される。

方法９０００は、ステップ９００５から開始し得る。ステップ９００５において、制御デバイス６０１０は、現在のファームウエアバージョン番号についてＲＴデバイス４０００へ任意選択的にクエリを送る。ステップ９０１０において、デバイス４０００は、自身のファームウエアバージョン番号と共に制御デバイス６０１０へ応答する。ステップ９０２０において、制御デバイス６０１０は、サーバー６０４０にファームウエアアップグレードを要求し、現在のファームウエアバージョン番号を送る。ステップ９０３０において、これが必要な場合、サーバー６０４０は、ファームウエアバージョン番号に基づいてファームウエアアップグレードファイルを制御デバイス６０１０へ送ることにより応答する（アップグレードが利用不可能である場合、サーバーは、メッセージ「無し」と共に応答し、その結果、制御デバイス６０１０は、ステップ９０３０後に方法９０００を終了する）。

いくつかのバージョンにおいて、方法は、ステップ９０２０から開始し得る。１つの種類の方法９０００において、ステップ９００５〜９０２０は省略され、方法９０００は、ステップ９０３０から開始する。ステップ９０３０において、サーバー６０４０は、ＲＴデバイス４０００のアップグレード履歴の自身固有の記録に基づいて、ファームウエアアップグレードファイルを制御デバイス６０１０へ送信する。

さらなる種類の方法９０００において、ステップ９００５は、ＲＴデバイスのファームウエアバージョン番号ではなく、ＲＴデバイスの固有の識別子をリクエストする。ステップ９０１０において、ＲＴデバイス４０００は、自身の固有の識別子と共に制御デバイス６０１０に応答する。ステップ９０２０において、制御デバイス６０１０は、サーバー６０４０にファームウエアアップグレードを要求し、固有の識別子を送る。ステップ９０３０において、１つが必要な場合、サーバー６０４０は、固有の識別子に基づいて、ファームウエアアップグレードファイルを制御デバイス６０１０へ送ることにより応用する。このような種類により、サーバー６０４０は、ファームウエアアップグレードの対象として（特定のファームウエアバージョン番号を有するデバイス全てではなく）特定のデバイスをターゲットとすることができる。

次のステップ９０３５において、制御デバイス６０１０は、アップグレードファイルをＲＴデバイス４０００へ送る。ステップ９０４０において、ＲＴデバイス４０００は、自身の固有の識別子を制御デバイス６０１０へ送る。（上記したさらなる種類において、制御デバイス６０１０にとってＲＴデバイス４０００の固有の識別子は既知であるため、ステップ９０４０は不要である。）次に、ステップ９０４５において、制御デバイス６０１０は、アップグレードのための認証コードをサーバー６０４０からリクエストし、ＲＴデバイス４０００の固有の識別子を送る。次に、ステップ９０５０において、サーバー６０４０は、制御デバイス６０１０から受信された固有の識別子と関連付けられた秘密（すなわち、ＲＴデバイス４０００と共有される秘密）から鍵を入手する。１つの実行様態において、鍵は、秘密からのデータのサブセットである。次に、サーバー６０４０は、鍵を用いて、ステップ９０３０において制御デバイス６０１０へ送られたアップグレードファイルから認証コードを導出する。ステップ９０５０の１つの実行様態において、認証コードは、アップグレードファイルのハッシュから導出されたハッシュ化メッセージ認証コード（ＨＭＡＣ）である。別の実行様態において、認証コードは、鍵を用いて暗号化されたアップグレードファイルのハッシュである。アップグレードファイルそのものではなくハッシュのアップグレードファイルを用いると、ネットワーク化された呼吸治療システム６０００内の異なるＲＴデバイスに対して同じ演算を複数回より同時的にまたはそれほど同時的にではなく行う必要の可能性が出てくるため、サーバー６０４０にとって有利である。

次に、ステップ９０５５において、サーバー６０４０は、認証コードを制御デバイス６０１０へ送る。ステップ９０６０において、制御デバイス６０１０は、認証コードをＲＴデバイス４０００へ送る。ステップ９０６５において、ＲＴデバイス４０００は、ステップ９０５０におけるサーバー６０４０と同じ方法で自身の秘密から鍵を導出する。次に、ＲＴデバイス４０００は、ステップ９０５０においてサーバー６０４０と同じ方法で導出された鍵を用いて、（やはりステップ９０６５において）ステップ９０３５において制御デバイス６０１０から受信されたアップグレードファイルから認証コードを演算する。よって、ステップ９０６５においてＲＴデバイス４０００により認証コードの演算を行うことにより、ステップ９０５０においてサーバー６０４０によって行われる演算が模倣される。次に、ＲＴデバイス４０００は、演算された認証コードと、ステップ９０６０において受信された認証コードとを比較する。これら２つのコードがマッチする場合、ＲＴデバイス４０００は、アップグレードファイルを認証する。次に、ＲＴデバイス４０００は、アップグレードファイルを自身の固有のファームウエアへ安全に適用する。

認証コードを演算する様態としては、（アップグレードファイルから認証コードを演算する方法が既知であっても）秘密も鍵もアップグレードファイルおよび認証コードから導出できないようにする様態がある。さらに、スプーフィングされた制御デバイス６０１０によってアップグレードファイルに対して不正が働かれた場合、ステップ９０６５においてＲＴデバイス４０００が計算した認証コードは、ステップ９０５５においてサーバー６０４０が受信したものと異なる。そのため、鍵も秘密も制御デバイス６０１０へ送られておらず、鍵が無くては制御デバイス６０１０は予測される認証コードを演算することはできないため、鍵または秘密を制御デバイス６０１０から導出することは不可能であり、スプーフィングされた制御デバイス６０１０が偽または不正のアップグレードをＲＴデバイス４０００のファームウエアへ提供することも不可能である。

５．７．２．２ 治療データのアップロード
上記したように、ネットワーク化された呼吸治療システム６０００内のＲＴデバイス（例えば、４０００）は、治療データを自身の制御デバイス６０１０を介してサーバー６０４０へアップロードするように、構成され得る。犯罪者６０６５の制御下にあるスプーフィングされた制御デバイス６０１０または関連付けられていない制御デバイス６０６０が、偽のまたは不正の治療データをサーバー６０４０へアップロードしようとする可能性がある。隔離された偽の治療データ源から発生するのは、多数のＲＴデバイスを含むネットワーク化された治療システム６０００全体に対するごくわずかな害のみであるため、これは受け入れられるリスクとみなされ得る。しかし、スプーフィングされた制御デバイス６０１０または関連付けられていない制御デバイス６０６０がシステム６０００内の他のＲＴデバイスのための制御デバイスになりすまし、偽の治療データをこれらのＲＴデバイスから来たものと嘘の主張をしてアップロードすることは受け入れられない。なぜならば、このような偽の治療データに起因して、権限を持つ制御デバイス６０１０からサーバー６０４０へアップロードされた真正の治療データが圧倒される可能性が有るからである。従って、アップロード時においては、制御デバイス６０１０が治療データのアップロード元として主張しているＲＴデバイス４０００と通信していることが望ましい。このような前提条件を設けることにより、ＲＴデバイス４０００と過去少なくとも１回はなんとか接続することに成功した関連付けられていない制御デバイス６０６０が後で権限を持つ制御デバイス６０１０と接続されてなりすましおよび偽の治療データの大規模アップロードを行う事態が回避される。

図１０は、方法１００００の模式図である。方法１００００は、図６のネットワーク化された呼吸治療システム６０００が本技術の１つの形態に従ってサーバーへの治療データアップロードを認証する際に用いられ得る。

方法１００００は、ステップ１０００５から開始する。ステップ１０００５において、ＲＴデバイス４０００は、治療データを制御デバイス６０１０へ送る。このステップは、方法１００００に相対して他の時に行われ得るが、サーバーへの治療データの転送の前に行う必要がある。ステップ１００１０において、制御デバイス６０１０は、「ナンス」およびオフセットをサーバー６０４０からリクエストし、ＲＴデバイス４０００の識別子を送る。ナンスは、持続期間が限られた（疑似）乱数であり、時間および／または使用回数によって支配される。この点について、ナンスは、所定の期間および／または所定の使用回数後に「期限切れ」になる。ナンスが期限切れになると、ナンスはサーバー６０４０によって用いられなくなる。例えば、ナンスの持続期間は、きっかり１回の使用であり得る。ステップ１００１５において、サーバー６０４０は、制御デバイス６０１０をナンスおよびオフセットと共に提供する。サーバー６０４０は、使用回数またはステップ１００１５においてナンスが初めて送られてからの経過時間と、ＲＴデバイス４０００の識別子とを追跡するため、サーバー６０４０は、ナンスが期限切れになったかを後で決定することができる。オフセットは、ポインタであり、ステップ１００１０において受信された識別子と関連付けられた秘密（すなわち、ＲＴデバイス４０００にとって既知の秘密）から鍵を導出するために用いられ得る。例えば、ポインタは識別子であり得、秘密からのデータのサブセットを鍵として用いるために選択するかまたはデータのサブセットから鍵を生成するためにハッシュを経験するために用いられる。

次に、ステップ１００２０において、制御デバイス６０１０は、ＲＴデバイス４０００に署名鍵を要求し、オフセットと、ステップ１００１５においてサーバーから受信されたナンスとを送る。ステップ１００２５において、ＲＴデバイス４０００は、オフセット、ナンスおよびその秘密を用いて、署名鍵を導出する。次のステップ１００３０において、ＲＴデバイス４０００は、署名鍵を制御デバイス６０１０へ送る。ステップ１００３５において、制御デバイス６０１０は、署名鍵を用いて、治療データのための認証コードを入手する。１つの実行様態において、認証コードはＨＭＡＣである。例えば、認証コードは、暗号法のハッシュ関数を用いて治療データおよび署名鍵と共に演算されたハッシュであり得る。ステップ１００４０において、制御デバイス６０１０は、治療データ、認証コードおよびＲＴデバイス４０００の識別子をサーバー６０４０へ送る。最後に、ステップ１００４５において、サーバー６０４０は、ステップ１００１５において送られた受信された識別子と関連付けられたナンスが期限切れになっているかをチェックする。ステップ１００１５において送られた受信された識別子と関連付けられたナンスが期限切れになっている場合、認証は失敗する。ステップ１００１５において送られた受信された識別子と関連付けられたナンスが期限切れになっていない場合、サーバー６０４０は、オフセットと、ステップ１００１５において送られたナンスと、識別子と関連付けられた秘密（すなわち、ＲＴデバイス４０００にとって既知の秘密）とを用いて署名鍵を導出する。サーバー６０４０は、署名鍵を用いて、治療データについて認証コードを演算する。署名鍵の導出認証コードの演算の方法は、ステップ１００２５および１００３５においてＲＴデバイス４０００および制御デバイス６０１０によって用いられる方法と同じである。演算された認証コードと、ステップ１００４０において受信された認証コードとの間にマッチが有る場合、治療データは認証される。

図１０中図示していないが、このような認証に基づいて、次に、サーバー６０４０は、治療データを用いた動作を任意選択的に行い得る。例えば、サーバー６０４０は、治療データを後で利用できるように治療関連データベース中に保存し得る。いくつかの場合において、サーバー６０４０は、コンプライアンスプロセスを行い得る（例えば、例えばコンプライアンス規則の適用および／または上記したようなコンプライアンス報告により治療データの評価を含めること）。

ＲＴデバイス４０００から受信された新規の治療データの後続アップロードにおいて、制御デバイス６０１０は、ステップ１００１０を省略し、方法１００００の前回の実行のステップ１００３０において受信された署名鍵を再利用し得る。しかし、ナンスが期限切れになっている場合において、後でアップロードの権限の無くなった場合、治療データをアップロードするためには、制御デバイス６０１０は、方法１０００のステップ１００１０以降を再開しなくてはならなくなる。このような場合、サーバー６０４０は、任意選択的にエラーメッセージを送って、このような再開を促し得る。

制御デバイス６０１０とサーバー６０４０との間の接続はセキュアではないため、関連付けられていない制御デバイス６０６０は、ステップ１００１５を盗聴して、オフセットおよびナンスを入手し得る。しかし、ＲＴデバイス４０００と制御デバイス６０１０との間の接続はセキュアであるため、関連付けられていない制御デバイス６０６０は、この接続を盗聴して署名鍵を入手することはできず、制御デバイス６０６０が偽の治療データをサーバー６０４０へアップロードすることも認可することはできない。加えて、ＲＴデバイス４０００へ接続されたことがあるため、署名鍵をかつて一度入手することができた制御デバイス６０１０は、この同じ署名鍵を無限に使用し続けることはできない。なぜならば、署名鍵を導出するためにサーバー６０４０が使用しているナンスは最終的に期限切れになるからである。さらに、スプーフィングされた制御デバイス６０１０は、任意の数の署名鍵、ナンスおよびオフセットから秘密を推測することはできないため、方法１００００においてどんなに高頻度に参加しても、将来の署名鍵を自身で推測することはできない。そのため、治療データアップロードを継続的に認可できるようにするためには、制御デバイス６０１０をＲＴデバイス４０００へ接続する必要が場合によって出てくる。ナンスの持続期間が短いほど、治療データのアップロード時期も制御デバイス６０１０とＲＴデバイス４０００との間の接続時期に近接させる必要が出てくるため、セキュリティ性が高まる。しかし、システム６０００にかかる演算負担も大きくなり、制御デバイス６０１０およびＲＴデバイス４０００の独立動作の利便性が低下する。また、その場合、ＲＴデバイス４０００と制御デバイス６０１０との間の連結依存性も高まり、両者間の独立性を高めることが望まれる。よって、ナンスの有効期限の呼気持続期間を、このような懸念のバランスがとれるように選択することができる。

１つの種類の方法１００００において、オフセットは用いられない。このような場合、ＲＴデバイス４０００およびサーバー６０４０は、署名鍵を秘密およびナンスのみから導出する。

方法１００００の場合、ＲＴデバイス４０００へ接続されたスプーフィングされた制御デバイス６０１０が（サイン（すなわち、認証コードの演算）の前に）治療データを用いて不正をするかまた治療データを偽造する事態を回避できない点に留意されたい。そのため、サーバー６０４０は、方法１００００を用いた場合、このような不正または偽造を検出することができない。

図１１は、さらなる方法１１０００の模式図である。方法１１０００は、図６のネットワーク化された呼吸治療システム６０００が本技術の１つの形態に従ってサーバーへの治療データアップロードを認可する際に用いられ得る。方法１１０００のステップ１１００５〜１１０２０は、方法１００００の対応する参照符号が付与されたステップ１０００５〜１００２０と同じである。

ステップ１１０２５において、ＲＴデバイス４０００は、オフセット、ナンスおよび自身の秘密を用いて、署名鍵を入手する。次に、ＲＴデバイス４０００は、署名鍵を用いて、ステップ１１００５において送られた治療データから認証コード（例えば、ＨＭＡＣ）を演算する。ステップ１１０３０において、ＲＴデバイス４０００は、認証コードを制御デバイス６０１０へ送る。次に、ステップ１１０４０において、制御デバイス６０１０は、治療データ、認証コードおよびＲＴデバイス識別子をサーバー６０４０へ送る。最後に、ステップ１１０４５において、サーバー６０４０は、ステップ１１０１５において送られたナンスが期限切れになっているかをチェックする。ステップ１１０１５において送られたナンスが期限切れになっている場合、認証は失敗する。ステップ１１０１５において送られたナンスが期限切れになっていない場合、サーバー６０４０は、ステップ１１０１５において送られたオフセットおよびナンスと、ＲＴデバイス識別子と関連付けられた秘密（すなわち、ＲＴデバイス４０００にとって既知の秘密）とを用いて、署名鍵を導出する。次に、サーバー６０４０は、署名鍵を用いて、治療データに対する認証コードを演算する。署名鍵の導出および認証コードの演算は、ステップ１１０２５においてＲＴデバイス４０００が用いるものと同じである。演算された認証コードと、ステップ１１０４０において受信された認証コードとがマッチする場合、治療データは認証される。

方法１１０００を用いた場合、秘密も署名鍵も制御デバイス６０１０へ送られることは無い。さらに、署名鍵および認証コードを導出する方法は、（署名鍵および認証コードを導出する方法が制御デバイス６０１０にとって既知であっても）オフセット、ナンス、認証コードおよび治療データから署名鍵を導出することが不可能な方法である。そのため、スプーフィングされた制御デバイス６０１０は、不正または偽造が為されたデータについて認証コードを生成するための鍵を持っていないため、（サーバー６０４０によって検出されずに）治療データに対する不正または偽造を行うことはできない。

方法１１０００の不利点として、余分な演算負荷および／または保管能力がＲＴデバイス４０００上に必要になり、治療データの小さな塊を多数サインおよび送信することまたは大量の治療データをメモリ中に蓄積した後このデータをサインして制御デバイス６０１０へ送ることが必要になる点がある。加えて、サーバー６０４０およびＲＴデバイス４０００へ同時に接続されていない場合がある制御デバイス６０１０にかかる事務的負担も発生する。そのため、制御デバイス６０１０は、（制御デバイス６０１０がサーバー６０４０へ接続されたときに）治療データを正しい認証コードと関連してサーバー６０４０へ後で転送するために、サーバー６０４０から接続解除されている状態で、治療データの各小塊と、ＲＴデバイス４０００から受信されたその関連付けられた認証コードとを追跡し続ける必要がある。

一種の方法１１０００において、オフセットもナンスも用いられない。このような場合、情報交換の必要性無しに秘密から導出可能な署名鍵が、ＲＴデバイス４０００およびサーバー６０４０双方によって用いられる。このような一種の一例において、署名鍵は秘密そのものである。このような種類において、ステップ１１００５〜１１０２０は省略され、ステップ１１０２５から開始する。ステップ１１０２５において、ＲＴデバイス４０００は、秘密から署名鍵を導出し、署名鍵を用いて、治療データから認証コードを演算する。ステップ１１０３０において、ＲＴデバイスは、ステップ１１０３０において治療データおよび認証コード双方を制御デバイス６０１０へ送る。次に、ステップ１１０４０において、制御デバイス６０１０は、治療データおよび認証コードをサーバー６０４０へ送る。最後に、ステップ１１０４５において、サーバー６０４０は、識別子と関連付けられた秘密（すなわち、ＲＴデバイス４０００にとって既知の秘密）を用いて署名鍵を導出し、この署名鍵を用いて、治療データのための認証コードを演算する。秘密からの署名鍵の導出および認証コードの演算の方法は、ステップ１１０２５においてＲＴデバイス４０００が用いたものと同じである。演算された認証コードと、ステップ１１０４０において受信された認証コードとの間にマッチがある場合、治療データは認証される。このような一種の場合、認証コードが固定鍵から本質的に導出されるため、ランダムナンスを用いる方法１００００と比較してあまり望ましくない（すなわち、セキュリティが弱くなる）。

この一種の方法１１０００の場合、もともとの方法１１０００よりもセキュリティが低い可能性がある。なぜならば、ＲＴデバイス４０００がスプーフィングされた制御デバイス６０１０または関連付けられていない制御デバイス６０６０それぞれにより１つでも違反が有った場合、任意の量の偽造治療データがＲＴデバイス４０００がから来たものであるとこのようなデバイスが主張してサーバー６０４０へアップロードする事態が招かれるからである。

５．８ 用語集
本技術の開示目的のため、本技術の特定の形態において、以下の定義のうち１つ以上が適用され得る。本技術の他の形態において、別の定義も適用され得る。

空気：本技術の特定の形態において、空気は大気を意味し得、本技術の他の形態において、空気は、他の呼吸可能なガスの組み合わせ（例えば、酸素を豊富に含む大気）を意味し得る。

自動的な気道陽圧（ＡＰＡＰ）療法：ＳＤＢ発症の兆候の存在または不在に応じて、例えば、呼吸間に最小限界と最大限界との間で治療圧力を自動的に調節することが可能なＣＰＡＰ療法。

持続的気道陽圧（ＣＰＡＰ）療法：治療圧力が患者の呼吸サイクルを通じてほぼ一定である呼吸圧療法。いくつかの形態において、気道への入口における圧力は、呼息時において若干上昇し、吸息時において若干低下する。いくつかの形態において、圧力は、患者の異なる呼吸サイクル間において変動する（例えば、部分的な上気道閉塞の兆候の検出に応答して増加され、部分的な上気道閉塞の通知の不在時において低減される）。

流量：単位時間あたりに送出される空気の瞬時の量（または質量）。流量とは、瞬間の量を指し得る。場合によっては、流量について言及した場合、スカラー量（すなわち、大きさのみを有する量）を指す。他の場合において、流量について言及した場合、ベクトル量（すなわち、大きさおよび方向両方を持つ量）を指す。流量には、符号Ｑが付与され得る。「流量」を簡略的に「流れ」もしくは「気流」と呼ぶ場合もある。

加湿器：「加湿器」という単語は、患者の医療呼吸疾患を改善するために治療上有益な量の水（Ｈ_２Ｏ）蒸気を空気流れへ提供することが可能な物理的構造を備えて構築、配置または構成された加湿装置を意味するものとして解釈される。

患者：呼吸器疾患に罹患しているかまたはしていない人。

呼吸治療（ＲＴ）：雰囲気（圧力治療）に対して典型的には陽圧である治療圧力におけるおよび／または典型的な呼吸流量（流れ治療）に対して上昇した流量における空気供給の気道入口への治療的付加。

人工呼吸器：患者が呼吸動作の一部または全てを行い際に圧力補助を提供する機械的デバイス。

５．９ 他の注意事項
本特許文書の開示の一部は、著作権保護が与えられる内容を含む。著作権所有者は、何者かが本特許文書または本特許開示をファックスにより再生しても、特許庁の特許ファイルまたは記録に記載されるものであれば目的のものであれば異論は無いが、その他の目的については全ての著作権を保持する。

他に文脈から明確に分かる場合および一定の範囲の値が提供されていない限り、下限の単位の１／１０、当該範囲の上限と下限の間、および記載の範囲の他の任意の記載の値または介入値に対する各介入値は本技術に包含されることが理解される。介入範囲中に独立的に含まれるこれらの介入範囲の上限および下限が記載の範囲における制限を特に超えた場合も、本技術に包含される。記載の範囲がこれらの制限のうち１つまたは双方を含む場合、これらの記載の制限のいずれかまたは双方を超える範囲も、本技術に包含される。

さらに、本明細書中に値（単数または複数）が本技術の一部として具現される場合、他に明記無き限り、このような値が近似され得、実際的な技術的実行が許容または要求する範囲まで任意の適切な有効桁までこのような値を用いることが可能であると理解される。

他に明記しない限り、本明細書中の全ての技術用語および科学用語は、本技術が属する分野の当業者が一般的に理解するような意味と同じ意味を持つ。本明細書中に記載の方法および材料に類似するかまたは等しい任意の方法および材料を本技術の実践または試験において用いることが可能であるが、限られた数の例示的方法および材料が本明細書中に記載される。

特定の材料が構成要素の構築に好適に用いられるものとして記載されているが、特性が類似する明白な代替的材料が代替物として用いられる。さらに、それとは反対に記載無き限り、本明細書中に記載される任意および全ての構成要素は、製造可能なものとして理解されるため、集合的にまたは別個に製造され得る。

本明細書中及び添付の特許請求の範囲において用いられるように、単数形である「ａ」、「ａｎ」および「ｔｈｅ」は、文脈から明らかにそうでないことが示されない限り、その複数の均等物を含む点に留意されたい。

本明細書中に記載される公開文献は全て、これらの公開文献の対象である方法および／または材料の開示および記載、参考のために援用される。本明細書中に記載の公開文献は、本出願の出願日前のその開示内容のみのために提供するものである。本明細書中のいずれの内容も、本技術が先行特許のためにこのような公開文献に先行していない、認めるものと解釈されるべきではない。さらに、記載の公開文献の日付は、実際の公開文献の日付と異なる場合があり、個別に確認が必要であり得る。

「ｃｏｍｐｒｉｓｅｓ」および「ｃｏｍｐｒｉｓｉｎｇ」という用語は、要素、構成要素またはステップを非排他的な意味合いで指すものとして解釈されるべきであり、記載の要素、構成要素たはステップが明記されていない他の要素、構成要素またはステップと共に存在、利用または結合され得ることを示す。

詳細な説明において用いられる見出しは、読者の便宜のためのものであり、本開示または特許請求の範囲全体において見受けられる内容を制限するために用いられるべきではない。これらの見出しは、特許請求の範囲または特許請求の範囲の制限の範囲の解釈において用いられるべきではない。

本明細書中の技術について、特定の実施例を参照して述べてきたが、これらの実施例は本技術の原理および用途を例示したものに過ぎないことが理解されるべきである。いくつかの場合において、用語および記号は、本技術の実施に不要な特定の詳細を示し得る。例えば、「ｆｉｒｓｔ（第１の）」および「ｓｅｃｏｎｄ（第２の）」（など）という用語が用いられるが、他に明記無き限り、これらの用語は任意の順序を示すことを意図しておらず、別個の要素を区別するために用いられる。さらに、本方法におけるプロセスステップについての記載または例示を順序付けて述べる場合があるが、このような順序は不要である。当業者であれば、このような順序が変更可能でありかつ／またはその様態を同時にまたはさらに同期的に行うことが可能であることを認識する。

よって、本技術の意図および範囲から逸脱することなく、例示的な実施例において多数の変更例が可能であり、また、他の配置構成が考案され得ることが理解されるべきである。多様なバージョンのこのような配置構成が、以下の番号付与された段落中の個別の例に関連して考えられ得る。

５．１０ 本技術の患者インターフェースの実施例
実施例 １．呼吸治療デバイスとの無線通信を行う方法であって、
呼吸治療デバイスとのセキュアではない無線通信回線を制御デバイスが確立することと、
制御デバイスがセキュアではない無線通信回線と異なる通信回線を第１の共有秘密を介して入手することであって、第１の共有秘密は、呼吸治療デバイスにとって既知である、ことと、
制御デバイスが第２の共有秘密を第１の共有秘密およびセキュアではない無線通信回線を介して通信されたデータを用いて演算することであって、第２の共有秘密は、呼吸治療デバイスにとって既知であり、第１の共有秘密よりも強力である、ことと、
制御デバイスが呼吸治療デバイスとの無線通信を第２の共有秘密に基づいて行うことと、
を含む、方法。

実施例 ２．第２の共有秘密を演算することは、ディフィー−ヘルマン鍵交換を含む、実施例１の方法。

実施例 ３．制御デバイスがセッション鍵を第２の共有秘密と用いて演算することをさらに含む、実施例１の方法。

実施例 ４．無線回線を介して呼吸治療デバイスと通信されるデータを制御デバイスがセッション鍵を用いて暗号化および復号化することをさらに含む、実施例３の方法。

実施例 ５．セキュアではない無線通信回線を確立することは、呼吸治療デバイスにとって既知の対称鍵を制御デバイスが演算することを含む、実施例１の方法。

実施例 ６．第１の共有秘密を異なる通信回線を介して入手することは、制御デバイスによる呼吸治療デバイスへの物理的アクセスに依存する、実施例１の方法。

実施例 ７．第１の共有秘密を入手することは、呼吸治療デバイスのハウジング上に印刷された機械可読フォームの第１の共有秘密を制御デバイスによってスキャンすることを含む、実施例６の方法。

実施例 ８．機械可読フォームはバーコードである、実施例７の方法。

実施例 ９．バーコードはＱＲコードである、実施例８の方法。

実施例 １０．第１の共有秘密を入手することは、制御デバイスのユーザインターフェースを介して入力された第１の共有秘密を制御デバイスにより受信することを含む、実施例６の方法。

実施例 １１．第２の共有秘密が呼吸治療デバイスにとって既知であることを制御デバイスにより確認することをさらに含む、実施例１の方法。

実施例 １２．確認することは、
第１のハッシュ値を第２の共有秘密を用いて演算することと、
呼吸治療デバイスからセキュアではない無線通信回線を介して第２のハッシュ値を受信することと、
を含む、
第１のハッシュ値を第２のハッシュ値と比較することと、
を含む、実施例１１の方法。

実施例 １３．第１のハッシュ値が第２のハッシュ値と等しくない場合、制御デバイスのユーザインターフェースを介してユーザ出力を生成することをさらに含む、実施例１２の方法。

実施例 １４．第２の共有秘密により、制御デバイスと呼吸治療デバイスとの間にセキュアな無線通信回線が確立される、実施例１から１３のうちいずれか１つの方法。

実施例 １５．第２の共有秘密からセッション鍵を演算することをさらに含む、実施例１４の方法。

実施例 １６．呼吸治療デバイスの呼吸療法動作を制御するための制御パラメータ制御デバイスが前記セキュアな無線通信回線を介して送信することをさらに含む、実施例１４の方法。

実施例 １７．制御パラメータは、圧力設定および流量設定のうち１つを含む、実施例１６の方法。

実施例 １８．呼吸治療デバイスの呼吸療法動作に関連するデータを制御デバイスが前記セキュアな無線通信回線を介して受信することをさらに含む、実施例１４から１７のうちいずれか１つの方法。

実施例 １９．データは、呼吸治療デバイスの利用時間および複数の呼吸イベントのうち任意の１つ以上を含む、実施例１８の方法。

実施例 ２０．符号化されたプログラム命令が載置された、コンピュータにより読出可能なデータ記憶媒体であって、プログラム命令は、実施例１〜１９のうちいずれか１つの方法を含む方法をプロセッサに行わせるように構成される、データ記憶媒体。

実施例 ２１．実施例２０に記載のコンピュータにより読出可能なデータ記憶媒体へのアクセスを有するサーバーであって、前記サーバーは、コンピュータにより読出可能なデータ記憶媒体のプログラム命令をネットワークを介して制御デバイスへダウンロードせよとの命令を受信するように構成される、サーバー。

実施例 ２２．呼吸治療デバイスと無線通信するように構成された制御デバイスであって、
処理命令を保存するメモリと、
であって、
呼吸治療デバイスとのセキュアではない無線通信回線を確立することと、
セキュアではない無線通信回線と異なる通信回線を介して第１の共有秘密を入手することであって、第１の共有秘密は、呼吸治療デバイスにとって既知である、ことと、
第１の共有秘密と、セキュアではない無線通信回線を介して通信されたデータとを用いて第２の共有秘密を演算することであって、第２の共有秘密は、呼吸治療デバイスにとって既知であり、第１の共有秘密よりも強力である、ことと、
を行うように構成されたプロセッサと、
を含む、制御デバイス。

実施例 ２３．バーコードリーダをさらに含み、プロセッサは、呼吸治療デバイスのハウジング上に印刷されたバーコードをバーコードリーダを用いてスキャンすることにより第１の共有秘密を入手するようにさらに構成され、バーコードは第１の共有秘密を符号化する、実施例２２の制御デバイス。

実施例 ２４．ユーザインターフェースをさらに含み、プロセッサは、ユーザインターフェースを通じて入力された入力を介して第１の共有秘密を入手するようにさらに構成される、実施例２２の制御デバイス。

実施例 ２５．呼吸治療デバイスと制御デバイスとの間の無線通信を行う方法であって、
制御デバイスとのセキュアではない無線通信回線を呼吸治療デバイスにより確立することと、
第１の共有秘密と、セキュアではない無線通信回線を介して通信されたデータとを用いて第２の共有秘密を呼吸治療デバイスにより演算することであって、第１の共有秘密および第２の共有秘密は、制御デバイスにとって既知であり、第２の共有秘密は、第１の共有秘密よりも強力である、ことと、
制御デバイスとの無線通信を呼吸治療デバイスが第２の共有秘密に基づいて行うことと、
を含む、方法。

実施例 ２６．制御デバイスと無線通信するように構成された呼吸治療デバイスであって、呼吸治療デバイスは、
処理命令を保存するメモリと、
コントローラであって、
制御デバイスとのセキュアではない無線通信回線を確立することと、
第１の共有秘密と、セキュアではない無線通信回線を介して通信されたデータとを用いて第２の共有秘密を演算することであって、第１の共有秘密および第２の共有秘密は、制御デバイスにとって既知であり、第２の共有秘密は第１の共有秘密よりも強力である、ことを行うように構成されたコントローラと、
を含む、呼吸治療デバイス。

実施例 ２７．印刷されたバーコードを含むハウジングであって、印刷されたバーコードは、第１の共有秘密を符号化する、ハウジンと、

実施例 ２８．呼吸治療システムであって、
呼吸治療デバイス；および
呼吸治療デバイスと無線通信するように構成された制御デバイスと、さらに含み、
制御デバイスは、
呼吸治療デバイスとのセキュアではない無線通信回線を確立することと、
セキュアではない無線通信回線と異なる通信回線を介して第１の共有秘密を入手することであって、第１の共有秘密は、呼吸治療デバイスにとって既知である、ことと、
第１の共有秘密と、セキュアではない無線通信回線を介して通信されたデータとを用いて第２の共有秘密を演算することであって、第２の共有秘密は、呼吸治療デバイスにとって既知であり、第１の共有秘密よりも強力である、ことと、
第２の共有秘密に基づいて呼吸治療デバイスとの無線通信を行うこととを行うように構成されたプロセッサを含む、
実施例２６の呼吸治療デバイス。

実施例 ２９．呼吸治療デバイスは、印刷されたバーコードを含むハウジングを含み、印刷されたバーコードは、第１の共有秘密を符号化する、実施例２８の呼吸治療システム。

実施例 ３０．制御デバイスは、バーコードリーダをさらに含み、プロセッサは、バーコードをスキャンすることにより第１の共有秘密をバーコードリーダにより入手するようにさらに構成される、実施例２９の呼吸治療システム。

実施例 ３１．制御デバイスは、ユーザインターフェースをさらに含み、プロセッサは、ユーザインターフェースを通じて入力された入力を介して第１の共有秘密を入手するようにさらに構成される、実施例２９の呼吸治療システム。

実施例 ３２．呼吸治療デバイスによって生成される治療データを呼吸治療デバイスとの通信および遠隔サーバーとの通信を行うように構成された制御デバイスを介して遠隔サーバーへアップロードする方法であって、
治療データを呼吸治療デバイスから制御デバイスが受信することと、
遠隔サーバーからナンスを制御デバイスが受信することと、
制御デバイスがナンスを呼吸治療デバイスへ送信することと、
制御デバイスが呼吸治療デバイスから署名鍵を受信することであって、署名鍵は、ナンスと、呼吸治療デバイスおよび遠隔サーバーにとって既知の秘密とに依存する、ことと、
制御デバイスが治療データおよび署名鍵を用いて認証コードを生成することであって、認証コードは、治療データの認証に用いられることと、
制御デバイスが治療データおよび認証コードを遠隔サーバーへ送信することと、
を含む、方法。

実施例 ３３．認証コードは、ハッシュ化メッセージ認証コードである、実施例３２の方法。

実施例 ３４．署名鍵は、共有秘密中へのオフセットにさらに依存し、オフセットは、遠隔サーバーから制御デバイスによって受信される、実施例３２〜３３のうちいずれか１つの方法。

実施例 ３５．ナンスは擬似乱数である、実施例３２〜３４のうちいずれか１つの方法。

実施例 ３６．制御デバイスは、呼吸治療デバイスにとって既知の対称鍵を用いて署名鍵を復号化することにより、呼吸治療デバイスから署名鍵セキュアに受信する、実施例３２〜３５のうちいずれか１つの方法。

実施例 ３７．制御デバイスであって、
メモリと、
プロセッサと、
を含み、
メモリはプログラム命令を含み、プログラム命令は、プロセッサによって実行されると、呼吸治療デバイスによって生成された治療データを遠隔サーバーへアップロードするように制御デバイスを制御し、プログラム命令は、
呼吸治療デバイスから治療データを受信することと、
遠隔サーバーからナンスを受信することと、
呼吸治療デバイスへナンスを送ることと、
呼吸治療デバイスから署名鍵を受信することであって、署名鍵は、ナンスと、呼吸治療デバイスおよび遠隔サーバーにとって既知の秘密とに依存する、ことと、
治療データおよび署名鍵を用いて認証コードを生成することであって、認証コードは、治療データの認証に用いられる、ことと、
治療データおよび認証コードを遠隔サーバーへ送ることと、
を行うように制御デバイスを制御する、
制御デバイス。

実施例 ３８．呼吸治療デバイスによって生成される治療データを認証する方法であって、
治療データおよび第１の認証コードを受信することと、
ナンスと、呼吸治療デバイスにとって既知の秘密とから、署名鍵を演算することと、
受信された治療データおよび署名鍵から第２の認証コードを演算することと、
第１の認証コードを第２の認証コードと比較することにより、治療データを認証することと、
を含む、方法。

実施例 ３９．オフセットを呼吸治療デバイスへ送信することをさらに含み、署名鍵はオフセットに依存する、実施例３８の方法。

実施例 ４０．認証コードは、ハッシュ化メッセージ認証コードである、実施例３８〜３９のうちいずれか１つの方法。

実施例 ４１．ナンスを呼吸治療デバイスへ送信することをさらに含む、実施例３８〜４０のうちいずれか１つの方法。

実施例 ４２．ナンスは擬似乱数である、実施例３８〜４１のうちいずれか１つの方法。

実施例 ４３．サーバーであって、
メモリと、
プロセッサと、
を含み、
メモリはプログラム命令を含み、プログラム命令は、プロセッサによって実行されると、呼吸治療デバイスによって生成された治療データを認証するようにサーバーを制御し、プログラム命令は、
治療データおよび第１の認証コードを受信することと、
ナンスと、呼吸治療デバイスにとって既知の秘密とから署名鍵を演算することと、
受信された治療データおよび署名鍵から第２の認証コードを演算することと、
第１の認証コードを第２の認証コードと比較することにより、治療データを認証することと、
を行うようにサーバーを制御する、
サーバー。

実施例 ４４．ネットワーク化された呼吸治療システムであって、
呼吸治療を患者に行うように構成された呼吸治療デバイスと、
遠隔サーバーと、
呼吸治療デバイスとの通信および遠隔サーバーとの通信を行うように構成された制御デバイスであって、制御デバイスは、
呼吸治療デバイスからの治療データを制御デバイスにより受信することと、
遠隔サーバーからのナンスを制御デバイスにより受信することと、
制御デバイスによりナンスを呼吸治療デバイスへ送ることと、
呼吸治療デバイスからの署名鍵を制御デバイスにより受信することであって、署名鍵は、ナンスと、呼吸治療デバイスおよび遠隔サーバーにとって既知の秘密とに依存する、ことと、
制御デバイスが治療データおよび署名鍵を用いて認証コードを生成することであって、認証コードは、治療データの認証に用いられる、ことと、
制御デバイスが治療データおよび認証コードを遠隔サーバーへ送ることと、
を行うように構成される、制御デバイス。

実施例 ４５．呼吸治療デバイスは、呼吸圧力治療デバイスである、実施例４４のシステム。

実施例 ４６．制御デバイスは、呼吸治療デバイスとの通信を共有対称鍵を用いてセキュアに行うように構成される、実施例４４〜４５のうちいずれか１つのシステム。

実施例 ４７．遠隔サーバーは、
治療データおよび第１の認証コードを受信することと、
ナンスと、呼吸治療デバイスにとって既知の秘密とから署名鍵を演算することと、
受信された治療データおよび署名鍵から第２の認証コードを演算することと、
第１の認証コードを第２の認証コードと比較することにより、治療データを認証することと、
を行うように構成される、実施例４４〜４６のうちいずれか１つのシステム。

実施例 ４８．ネットワーク化された呼吸治療システムであって、
呼吸治療を患者に行うように構成された呼吸治療デバイスと、
呼吸治療デバイスと通信するように構成された制御デバイスと、
制御デバイスと通信するように構成された遠隔サーバーであって、
制御デバイスから治療データおよび第１の認証コードを受信することと、
ナンスと、呼吸治療デバイスにとって既知の秘密とから署名鍵を演算することと、
受信された治療データおよび署名鍵から第２の認証コードを演算することと、
第１の認証コードを第２の認証コードと比較することにより、治療データを認証することと、
を行うように構成される、遠隔サーバー。

実施例 ４９．呼吸治療デバイスは、呼吸圧力治療デバイスである、実施例４８のシステム。

実施例 ５０．制御デバイスは、呼吸治療デバイスとの通信を共有対称鍵を用いてセキュアに行うように構成される、実施例４８〜４９のうちいずれか１つのシステム。

実施例 ５１．制御デバイスは、
呼吸治療デバイスから治療データを受信することと、
遠隔サーバーからナンスを受信することと、
呼吸治療デバイスへナンスを送ることと、
呼吸治療デバイスから署名鍵を受信することであって、署名鍵は、ナンスと、呼吸治療デバイスおよび遠隔サーバーにとって既知の秘密とに依存する、ことと、
治療データおよび署名鍵を用いて認証コードを生成することであって、認証コードは、治療データの認証に用いられる、ことと、
治療データおよび認証コードを遠隔サーバーへ送ることと、
を行うように構成される、実施例４８〜５０のうちいずれか１つのシステム。

実施例 ５２．呼吸治療デバイスは、
遠隔サーバーからナンスを受信することと、
ナンスからの署名鍵と、呼吸治療デバイスおよび遠隔サーバーにとって既知の秘密とを演算することと、
治療データおよび署名鍵を用いて認証コードを生成することと、
治療データおよび認証コードを遠隔サーバーへ送ることと、
を行うように構成される、実施例４８〜５０のうちいずれか１つのシステム。

実施例 ５３．呼吸治療デバイスによって生成される治療データを遠隔サーバーへアップロードする方法であって、
遠隔サーバーからナンスを呼吸治療デバイスが受信することと、
ナンスからの署名鍵と、遠隔サーバーにとって既知の秘密とを呼吸治療デバイスによって演算することと、
呼吸治療デバイスが治療データおよび署名鍵を用いて認証コードを生成することであって、認証コードは、治療データの認証に用いられる、ことと、
治療データおよび認証コードを呼吸治療デバイスから遠隔サーバーへ送信することと、
を含む、方法。

実施例 ５４．認証コードは、ハッシュ化メッセージ認証コードである、実施例５３の方法。

実施例 ５５．署名鍵は、共有秘密中へのオフセットにさらに依存し、オフセットは、遠隔サーバーから呼吸治療デバイスによって受信される、実施例５３〜５４のうちいずれか１つの方法。

実施例 ５６．ナンスは擬似乱数である、実施例５３〜５５のうちいずれか１つの方法。

実施例 ５７．呼吸治療デバイスは、遠隔サーバーと通信するように構成された制御デバイスを介してナンスを受信する、実施例５３〜５６のうちいずれか１つの方法。

実施例 ５８．呼吸治療デバイスは、制御デバイスにとって既知の対称鍵を用いてナンスを復号化することにより、ナンスを制御デバイスから受信する、実施例５７の方法。

実施例 ５９．呼吸治療デバイスは、遠隔サーバーと通信するように構成された制御デバイスを介して治療データおよび認証コードを送る、実施例５３〜５８のうちいずれか１つの方法。

実施例 ６０．制御デバイスは、制御デバイスにとって既知の対称鍵を用いて治療データおよび認証コードを暗号化することにより、治療データおよび認証コードを制御デバイスへ送る、実施例５９の方法。

実施例 ６１．呼吸治療デバイスであって、
患者インターフェースへ連結することおよび陽圧の空気流れを患者インターフェースへ供給することを行うように適合された圧力生成器と、
メモリと、
プロセッサと、
を含み、
メモリはプログラム命令を含み、プログラム命令は、プロセッサによって実行されると、呼吸治療デバイスによって生成された治療データを遠隔サーバーへアップロードするように呼吸治療デバイスを制御し、プログラム命令は、
遠隔サーバーからナンスを受信することと、
ナンスからの署名鍵と、遠隔サーバーにとって既知の秘密とを演算することと、
治療データおよび署名鍵を用いて認証コードを生成することであって、認証コードは、治療データの認証に用いられる、ことと、
治療データおよび認証コードを遠隔サーバーへ送ることと、
を行うように呼吸治療デバイスを制御する、
呼吸治療デバイス。

実施例 ６２．ネットワーク化された呼吸治療システムであって、
患者への呼吸治療の施行のための呼吸治療デバイスと、
呼吸治療デバイスと通信するように構成された遠隔サーバーと、
を含み、
呼吸治療デバイスは、
遠隔サーバーからナンスを受信することと、
ナンスからの署名鍵と、遠隔サーバーにとって既知の秘密とを演算することと、
治療データおよび署名鍵を用いて認証コードを生成することであって、認証コードは、治療データの認証に用いられる、ことと、
治療データおよび認証コードを遠隔サーバーへ送ることと、
を行うように構成される、
ネットワーク化された呼吸治療システム。

実施例 ６３．呼吸治療デバイスは、呼吸圧力治療デバイスである、実施例６２のシステム。

実施例 ６４．呼吸治療デバイスとセキュアに通信することおよび遠隔サーバーと通信することを行うように構成された制御デバイスをさらに含む、実施例６２〜６３のうちいずれか１つのシステム。

実施例 ６５．制御デバイスは、呼吸治療デバイスにとって既知の対称鍵を用いて呼吸治療デバイスとセキュアに通信するように構成される、実施例６４のシステム。

実施例 ６６．遠隔サーバーは、
治療データおよび第１の認証コードを受信することと、
ナンスと、呼吸治療デバイスにとって既知の秘密とから署名鍵を演算することと、
受信された治療データおよび署名鍵から第２の認証コードを演算することと、
第１の認証コードを第２の認証コードと比較することにより、治療データを認証することと、
を行うように構成される、実施例６２〜６５のうちいずれか１つのシステム。

実施例 ６７．装置であって、
呼吸治療デバイスから治療データを受信する手段と、
遠隔サーバーからナンスを受信する手段と、
ナンスを呼吸治療デバイスへ送信する手段と、
呼吸治療デバイスから署名鍵を受信する手段であって、署名鍵は、ナンスと、呼吸治療デバイスおよび遠隔サーバーにとって既知の秘密とに依存する、手段と、
治療データおよび署名鍵を用いて認証コードを生成する手段であって、認証コードは、治療データの認証に用いられる、手段と、
治療データおよび認証コードを遠隔サーバーへ送信する手段と、
を含む、装置。

実施例 ６８．装置であって、
呼吸治療デバイスおよび第１の認証コードから治療データを受信する手段と、
ナンスと、呼吸治療デバイスにとって既知の秘密とから、署名鍵を演算する手段と、
受信された治療データおよび署名鍵から第２の認証コードを演算する手段と、
第１の認証コードを第２の認証コードと比較することにより、治療データを認証する手段と、
を含む、装置。

実施例 ６９．装置であって、
呼吸治療を患者へ送達させる手段と、
遠隔サーバーからナンスを受信する手段と、
ナンスからの署名鍵と、遠隔サーバーにとって既知の秘密とを演算する手段と、
治療データおよび署名鍵を用いて認証コードを生成する手段であって、認証コードは、治療データの認証に用いられる、手段と、
治療データおよび認証コードを遠隔サーバーへ送信する手段と、
を含む、装置。

５．１１ 参照符号のリスト
患者 １０００
同床者 １１００
患者インターフェース ３０００
シール形成構造 ３１００
プレナムチャンバ ３２００
構造 ３３００
通気 ３４００
接続ポート ３６００
前額支持部 ３７００
ＲＴデバイス ４０００
外部ハウジング ４０１０
内側部位 ４０１２
部位 ４０１４
パネル ４０１５
シャーシ ４０１６
ハンドル ４０１８
空気圧ブロック ４０２０
空気フィルタ ４１１０
入口空気フィルタ ４１１２
出口空気フィルタ ４１１４
マフラー ４１２０
入口マフラー ４１２２
出口マフラー ４１２４
圧力生成器 ４１４０
送風機 ４１４２
モータ ４１４４
アンチスピルバック弁 ４１６０
空気回路 ４１７０
電気コンポーネント ４２００
ＰＣＢＡ ４２０２
電気電源 ４２１０
ボタン ４２２０
中央制御装置 ４２３０
時計 ４２３２
治療装置コントローラ ４２４０
保護回路 ４２５０
メモリ ４２６０
変換器 ４２７０
圧力センサ ４２７２
流量センサ ４２７４
モータ速度変換器 ４２７６
インターフェース ４２８０
遠隔外部通信ネットワーク ４２８２
ローカル外部通信ネットワーク ４２８４
遠隔外部デバイス ４２８６
ローカル外部デバイス ４２８８
出力デバイス ４２９０
加湿器 ５０００
加湿器入口 ５００２
加湿器出口 ５００４
加湿器ベース ５００６
加湿器リザーバ ５１１０
加湿器リザーバドック ５１３０
加熱要素 ５２４０
ネットワーク化された呼吸治療システム ６０００
制御デバイス ６０１０
チャンネル ６０１３
無線接続 ６０１５
バーコード ６０１７
第２の制御デバイス ６０２０
無線接続 ６０２５
犯罪者 ６０３０
サーバー ６０４０
無線接続 ６０５０
関連付けられていない制御デバイス ６０６０
犯罪者 ６０６５
無線接続 ６０７０
方法 ７０００
ステップ ７０１０
ステップ ７０２０
ステップ ７０３０
方法 ８０００
矢印 ８００１
ステップ ８０１０
ステップ ８０１５
ステップ ８０２０
ステップ ８０２５
ステップ ８０３０
ステップ ８０３５
ステップ ８０４０
ステップ ８０４５
方法 ８０５０
ステップ ８０５５
ステップ ８０６０
ステップ ８０６５
ステップ ８０７０
ステップ ８０７５
ステップ ８０８０
ステップ ８０８５
ステップ ８０９０
ステップ ８０９５
方法 ９０００
ステップ ９００５
ステップ ９０１０
ステップ ９０２０
ステップ ９０３０
ステップ ９０３５
ステップ ９０４０
ステップ ９０４５
ステップ ９０５０
ステップ ９０５５
ステップ ９０６０
ステップ ９０６５
方法 １００００
ステップ １０００５
ステップ １００１０
ステップ １００１５
ステップ １００２０
ステップ １００２５
ステップ １００３０
ステップ １００３５
ステップ １００４０
ステップ １００４５
方法 １１０００
ステップ １１００５
ステップ １１０１０
ステップ １１０１５
ステップ １１０２０
ステップ １１０２５
ステップ １１０３０
ステップ １１０４０
ステップ １００４５

６ 引用文献
１．Ｓｉｍｐｌｅ Ｐａｉｒｉｎｇ Ｗｈｉｔｅｐａｐｅｒ， ｖｅｒｓｉｏｎ １０ｒ００．Ｂｌｕｅｔｏｏｔｈ Ｃｏｒｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ， Ａｕｇｕｓｔ ２００６．
２．Ｕｓｉｎｇ ｔｈｅ Ｓｅｃｕｒｅ Ｒｅｍｏｔｅ Ｐａｓｓｗｏｒｄ （ＳＲＰ） Ｐｒｏｔｏｃｏｌ ｆｏｒ ＴＬＳ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ （ＲＦＣ−５０５４）， Ｔａｙｌｏｒ ｅｔ ａｌ．， Ｎｏｖｅｍｂｅｒ ２００７．

Claims (69)

1. 呼吸治療デバイスとの無線通信を行う方法であって、
   前記呼吸治療デバイスとのセキュアではない無線通信回線を制御デバイスが確立することと、
   前記制御デバイスが前記セキュアではない無線通信回線と異なる通信回線を第１の共有秘密を介して入手することであって、前記第１の共有秘密は、前記呼吸治療デバイスにとって既知である、ことと、
   前記制御デバイスが第２の共有秘密を前記第１の共有秘密および前記セキュアではない無線通信回線を介して通信されたデータを用いて演算することであって、前記第２の共有秘密は、前記呼吸治療デバイスにとって既知であり、前記第１の共有秘密よりも強力である、ことと、
   前記制御デバイスが前記呼吸治療デバイスとの無線通信を前記第２の共有秘密に基づいて行うことと、
   を含む、方法。
2. 前記第２の共有秘密を演算することは、ディフィー−ヘルマン鍵交換を含む、請求項１の方法。
3. 前記制御デバイスがセッション鍵を前記第２の共有秘密と用いて演算することをさらに含む、請求項１の方法。
4. 前記無線回線を介して前記呼吸治療デバイスと通信されるデータを前記制御デバイスが前記セッション鍵を用いて暗号化および復号化することをさらに含む、請求項３の方法。
5. セキュアではない無線通信回線を確立することは、前記呼吸治療デバイスにとって既知の対称鍵を前記制御デバイスが演算することを含む、請求項１の方法。
6. 前記第１の共有秘密を異なる回線を介して入手することは、前記制御デバイスによる前記呼吸治療デバイスへの物理的アクセスに依存する、請求項１の方法。
7. 前記第１の共有秘密を入手することは、前記呼吸治療デバイスのハウジング上に印刷された機械可読フォームの前記第１の共有秘密を前記制御デバイスによってスキャンすることを含む、請求項６の方法。
8. 前記機械可読フォームはバーコードである、請求項７の方法。
9. 前記バーコードはＱＲコードである、請求項８の方法。
10. 前記第１の共有秘密を入手することは、前記制御デバイスのユーザインターフェースを介して入力された前記第１の共有秘密を前記制御デバイスにより受信することを含む、請求項６の方法。
11. 前記第２の共有秘密が前記呼吸治療デバイスにとって既知であることを前記制御デバイスにより確認することをさらに含む、請求項１の方法。
12. 前記確認することは、
    第１のハッシュ値を前記第２の共有秘密を用いて演算することと、
    前記呼吸治療デバイスから前記セキュアではない無線通信回線を介して第２のハッシュ値を受信することと、
    前記第１のハッシュ値を前記第２のハッシュ値と比較することと、
    を含む、請求項１１の方法。
13. 前記第１のハッシュ値が前記第２のハッシュ値と等しくない場合、前記制御デバイスのユーザインターフェースを介してユーザ出力を生成することをさらに含む、請求項１２の方法。
14. 前記第２の共有秘密により、前記制御デバイスと前記呼吸治療デバイスとの間にセキュアな無線通信回線が確立される、請求項１の方法。
15. 前記第２の共有秘密からセッション鍵を演算することをさらに含む、請求項１４の方法。
16. 前記呼吸治療デバイスの呼吸療法動作を制御するための制御パラメータ前記制御デバイスが前記セキュアな無線通信回線を介して送信することをさらに含む、請求項１４の方法。
17. 前記制御パラメータは、圧力設定および流量設定のうち１つを含む、請求項１６の方法。
18. 前記呼吸治療デバイスの呼吸療法動作に関連するデータを前記制御デバイスが前記セキュアな無線通信回線を介して受信することをさらに含む、請求項１４の方法。
19. 前記データは、前記呼吸治療デバイスの利用時間および複数の呼吸イベントのうち任意の１つ以上を含む、請求項１８の方法。
20. 符号化されたプログラム命令が載置された、コンピュータにより読出可能なデータ記憶媒体であって、前記プログラム命令は、請求項１の方法を含む方法をプロセッサに行わせるように構成される、データ記憶媒体。
21. 請求項２０のコンピュータにより読出可能なデータ記憶媒体へのアクセスを有するサーバーであって、前記サーバーは、前記コンピュータにより読出可能なデータ記憶媒体の前記プログラム命令をネットワークを介して前記制御デバイスへダウンロードせよとのリクエストを受信するように構成される、サーバー。
22. 呼吸治療デバイスと無線通信するように構成された制御デバイスであって、
    処理命令を保存するメモリと、
    プロセッサであって、
    前記呼吸治療デバイスとのセキュアではない無線通信回線を確立することと、
    前記セキュアではない無線通信回線と異なる回線を介して第１の共有秘密を入手することであって、前記第１の共有秘密は、前記呼吸治療デバイスにとって既知である、ことと、
    前記第１の共有秘密と、前記セキュアではない無線通信回線を介して通信されたデータとを用いて第２の共有秘密を演算することであって、前記第２の共有秘密は、前記呼吸治療デバイスにとって既知であり、前記第１の共有秘密よりも強力である、ことと、
    を行うように構成される、プロセッサと、
    を含む、制御デバイス。
23. バーコードリーダをさらに含み、前記プロセッサは、前記呼吸治療デバイスのハウジング上に印刷されたバーコードを前記バーコードリーダを用いてスキャンすることにより前記第１の共有秘密を入手するようにさらに構成され、前記バーコードは前記第１の共有秘密を符号化する、請求項２２の制御デバイス。
24. ユーザインターフェースをさらに含み、前記プロセッサは、前記ユーザインターフェースを通じて入力された入力を介して前記第１の共有秘密を入手するようにさらに構成される、請求項２２の制御デバイス。
25. 呼吸治療デバイスと制御デバイスとの間の無線通信を行う方法であって、
    前記制御デバイスとのセキュアではない無線通信回線を前記呼吸治療デバイスにより確立することと、
    第１の共有秘密と、前記セキュアではない無線通信回線を介して通信されたデータとを用いて第２の共有秘密を前記呼吸治療デバイスにより演算することであって、前記第１の共有秘密および前記第２の共有秘密は、前記制御デバイスにとって既知であり、前記第２の共有秘密は、前記第１の共有秘密よりも強力である、ことと、
    前記制御デバイスとの無線通信を前記呼吸治療デバイスが前記第２の共有秘密に基づいて行うことと、
    を含む、方法。
26. 制御デバイスと無線通信するように構成された呼吸治療デバイスであって、
    処理命令を保存するメモリと、
    コントローラであって、
    前記制御デバイスとのセキュアではない無線通信回線を確立することと、
    第１の共有秘密と、前記セキュアではない無線通信回線を介して通信されたデータとを用いて第２の共有秘密を演算することであって、前記第１の共有秘密および前記第２の共有秘密は、前記制御デバイスにとって既知であり、前記第２の共有秘密は、前記第１の共有秘密よりも強力である、ことと、
    を行うように構成されたコントローラと、
    を含む、呼吸治療デバイス。
27. 印刷されたバーコードを含むハウジングをさらに含み、前記印刷されたバーコードは、前記第１の共有秘密を符号化する、請求項２６の呼吸治療デバイス。
28. 呼吸治療システムであって、
    呼吸治療デバイスと、
    前記呼吸治療デバイスと無線通信するように構成された制御デバイスと、
    を含み、
    前記制御デバイスはプロセッサを含み、前記プロセッサは、
    前記呼吸治療デバイスとのセキュアではない無線通信回線を確立することと、
    前記セキュアではない無線通信回線と異なる回線を介して第１の共有秘密を入手することであって、前記第１の共有秘密は、前記呼吸治療デバイスにとって既知である、ことと、
    前記第１の共有秘密と、前記セキュアではない無線通信回線を介して通信されたデータとを用いて第２の共有秘密を演算することであって、前記第２の共有秘密は、前記呼吸治療デバイスにとって既知であり、前記第１の共有秘密よりも強力である、ことと、
    前記第２の共有秘密に基づいて前記呼吸治療デバイスとの無線通信を行うことと、
    を行うように構成される、
    呼吸治療システム。
29. 前記呼吸治療デバイスは、印刷されたバーコードを含むハウジングを含み、前記印刷されたバーコードは、前記第１の共有秘密を符号化する、請求項２８の呼吸治療システム。
30. 前記制御デバイスは、バーコードリーダをさらに含み、前記プロセッサは、前記バーコードをスキャンすることにより前記第１の共有秘密を前記バーコードリーダにより入手するようにさらに構成される、請求項２９の呼吸治療システム。
31. 前記制御デバイスは、ユーザインターフェースをさらに含み、前記プロセッサは、前記ユーザインターフェースを通じて入力された入力を前記第１の共有秘密を介して入手するようにさらに構成される、請求項２９の呼吸治療システム。
32. 呼吸治療デバイスによって生成される治療データを前記呼吸治療デバイスとの通信および前記遠隔サーバーとの通信を行うように構成された制御デバイスを介して遠隔サーバーへアップロードする方法であって、
    前記治療データを前記呼吸治療デバイスから前記制御デバイスが受信することと、
    前記遠隔サーバーからナンスを前記制御デバイスが受信することと、
    前記制御デバイスが前記ナンスを前記呼吸治療デバイスへ送信することと、
    前記制御デバイスが前記呼吸治療デバイスから署名鍵を受信することであって、前記署名鍵は、前記ナンスと、前記呼吸治療デバイスおよび前記遠隔サーバーにとって既知の秘密とに依存する、ことと、
    前記制御デバイスが前記治療データおよび前記署名鍵を用いて認証コードを生成することであって、前記認証コードは、前記治療データの認証に用いられる、ことと、
    前記制御デバイスが前記治療データおよび前記認証コードを前記遠隔サーバーへ送信することと、
    を含む、方法。
33. 前記認証コードは、ハッシュ化メッセージ認証コードである、請求項３２の方法。
34. 前記署名鍵は、前記共有秘密中へのオフセットにさらに依存し、前記オフセットは、前記遠隔サーバーから前記制御デバイスによって受信される、請求項３２の方法。
35. 前記ナンスは擬似乱数である、請求項３２の方法。
36. 前記制御デバイスは、前記呼吸治療デバイスにとって既知の対称鍵を用いて前記署名鍵を復号化することにより、前記呼吸治療デバイスから前記署名鍵をセキュアに受信する、請求項３２の方法。
37. 制御デバイスであって、
    メモリと、
    プロセッサと、
    を含み、
    前記メモリはプログラム命令を含み、前記プログラム命令は、前記プロセッサによって実行されると、呼吸治療デバイスによって生成された治療データを遠隔サーバーへアップロードするように前記制御デバイスを制御し、前記プログラム命令は、
    前記呼吸治療デバイスから前記治療データを受信することと、
    前記遠隔サーバーからナンスを受信することと、
    前記呼吸治療デバイスへ前記ナンスを送ることと、
    前記呼吸治療デバイスから署名鍵を受信することであって、前記署名鍵は、前記ナンスと、前記呼吸治療デバイスおよび前記遠隔サーバーにとって既知の秘密とに依存する、ことと、
    前記治療データおよび前記署名鍵を用いて認証コードを生成することであって、前記認証コードは、前記治療データの認証に用いられる、ことと、
    前記治療データおよび前記認証コードを前記遠隔サーバーへ送ることと、
    を行うように前記制御デバイスを制御する、
    制御デバイス。
38. 呼吸治療デバイスによって生成される治療データを認証する方法であって、
    前記治療データおよび第１の認証コードを受信することと、
    ナンスと、前記呼吸治療デバイスにとって既知の秘密とから、署名鍵を演算することと、
    前記受信された治療データおよび前記署名鍵から第２の認証コードを演算することと、
    前記第１の認証コードを前記第２の認証コードと比較することにより、前記治療データを認証することと、
    を含む、方法。
39. オフセットを前記呼吸治療デバイスへ送信することをさらに含み、前記署名鍵は前記オフセットに依存する、請求項３８の方法。
40. 前記認証コードは、ハッシュ化メッセージ認証コードである、請求項３８の方法。
41. 前記ナンスを前記呼吸治療デバイスへ送信することをさらに含む、請求項３８の方法。
42. 前記ナンスは擬似乱数である、請求項３８の方法。
43. サーバーであって、
    メモリと、
    プロセッサと、
    を含み、
    前記メモリはプログラム命令を含み、前記プログラム命令は、前記プロセッサによって実行されると、呼吸治療デバイスによって生成された治療データを認証するように前記サーバーを制御し、前記プログラム命令は、
    前記治療データおよび第１の認証コードを受信することと、
    ナンスと、前記呼吸治療デバイスにとって既知の秘密とから署名鍵を演算することと、
    前記受信された治療データおよび前記署名鍵から第２の認証コードを演算することと、
    前記第１の認証コードを前記第２の認証コードと比較することにより、前記治療データを認証することと、
    を行うように前記サーバーを制御する、
    サーバー。
44. ネットワーク化された呼吸治療システムであって、
    呼吸治療を患者に行うに構成された呼吸治療デバイスと、
    遠隔サーバーと、
    前記呼吸治療デバイスとの通信および前記遠隔サーバーとの通信を行うように構成された制御デバイスであって、前記制御デバイスは、
    前記呼吸治療デバイスからの治療データを前記制御デバイスにより受信することと、
    前記遠隔サーバーからのナンスを前記制御デバイスにより受信することと、
    前記制御デバイスにより前記ナンスを前記呼吸治療デバイスへ送ることと、
    前記呼吸治療デバイスからの署名鍵を前記制御デバイスにより受信することであって、前記署名鍵は、前記ナンスと、前記呼吸治療デバイスおよび前記遠隔サーバーにとって既知の秘密とに依存する、ことと、
    前記制御デバイスが前記治療データおよび前記署名鍵を用いて認証コードを生成することであって、前記認証コードは、前記治療データの認証に用いられる、ことと、
    前記制御デバイスが前記治療データおよび前記認証コードを前記遠隔サーバーへ送ることと、
    を行うように構成される、制御デバイスと、
    を含む、
    システム。
45. 前記呼吸治療デバイスは、呼吸圧力治療デバイスである、請求項４４のシステム。
46. 前記制御デバイスは、前記呼吸治療デバイスとの通信を共有対称鍵を用いてセキュアに行うように構成される、請求項４４のシステム。
47. 前記遠隔サーバーは、
    前記治療データおよび第１の認証コードを受信することと、
    ナンスと、前記呼吸治療デバイスにとって既知の秘密とから署名鍵を演算することと、
    前記受信された治療データおよび前記署名鍵から第２の認証コードを演算することと、
    前記第１の認証コードを前記第２の認証コードと比較することにより、前記治療データを認証することと、
    を行うように構成される、
    請求項４４のシステム。
48. ネットワーク化された呼吸治療システムであって、
    呼吸治療を患者に行うように構成された呼吸治療デバイスと、
    前記呼吸治療デバイスと通信するように構成された制御デバイスと、
    前記制御デバイスと通信するように構成された遠隔サーバーであって、前記遠隔サーバーは、
    前記制御デバイスから治療データおよび第１の認証コードを受信することと、
    ナンスと、前記呼吸治療デバイスにとって既知の秘密とから署名鍵を演算することと、
    前記受信された治療データおよび前記署名鍵から第２の認証コードを演算することと、
    前記第１の認証コードを前記第２の認証コードと比較することにより、前記治療データを認証することと、
    を行うように構成される、遠隔サーバーと、
    を含む、システム。
49. 前記呼吸治療デバイスは、呼吸圧力治療デバイスである、請求項４８のシステム。
50. 前記制御デバイスは、前記呼吸治療デバイスとの通信を共有対称鍵を用いてセキュアに行うように構成される、請求項４８のシステム。
51. 前記制御デバイスは、
    前記呼吸治療デバイスから前記治療データを受信することと、
    前記遠隔サーバーからナンスを受信することと、
    前記呼吸治療デバイスへ前記ナンスを送ることと、
    前記呼吸治療デバイスから署名鍵を受信することであって、前記署名鍵は、前記ナンスと、前記呼吸治療デバイスおよび前記遠隔サーバーにとって既知の秘密とに依存する、ことと、
    前記治療データおよび前記署名鍵を用いて認証コードを生成することであって、前記認証コードは、前記治療データの認証に用いられる、ことと、
    前記治療データおよび前記認証コードを前記遠隔サーバーへ送ることと、
    を行うように構成される、
    請求項４８のシステム。
52. 前記呼吸治療デバイスは、
    前記遠隔サーバーからナンスを受信することと、
    前記ナンスからの署名鍵と、前記呼吸治療デバイスおよび前記遠隔サーバーにとって既知の秘密とを演算することと、
    前記治療データおよび前記署名鍵を用いて認証コードを生成することと、
    前記治療データおよび前記認証コードを前記遠隔サーバーへ送ることと、
    を行うように構成される、
    請求項４８のシステム。
53. 呼吸治療デバイスによって生成される治療データを遠隔サーバーへアップロードする方法であって、
    前記遠隔サーバーからナンスを前記呼吸治療デバイスが受信することと、
    前記ナンスからの署名鍵と、前記遠隔サーバーにとって既知の秘密とを前記呼吸治療デバイスによって演算することと、
    前記呼吸治療デバイスが前記治療データおよび前記署名鍵を用いて認証コードを生成することであって、前記認証コードは、前記治療データの認証に用いられる、ことと、
    前記治療データおよび前記認証コードを前記呼吸治療デバイスから前記遠隔サーバーへ送信することと、
    を含む、方法。
54. 前記認証コードは、ハッシュ化メッセージ認証コードである、請求項５３の方法。
55. 前記署名鍵は、前記共有秘密中へのオフセットにさらに依存し、前記オフセットは、前記遠隔サーバーから前記呼吸治療デバイスによって受信される、請求項５３の方法。
56. 前記ナンスは擬似乱数である、請求項５３〜５５の方法。
57. 前記呼吸治療デバイスは、前記遠隔サーバーと通信するように構成された制御デバイスを介して前記ナンスを受信する、請求項５３の方法。
58. 前記呼吸治療デバイスは、前記制御デバイスにとって既知の対称鍵を用いて前記ナンスを復号化することにより、前記ナンスを前記制御デバイスから受信する、請求項５７の方法。
59. 前記呼吸治療デバイスは、前記遠隔サーバーと通信するように構成された制御デバイスを介して前記治療データおよび前記認証コードを送信する、請求項５３の方法。
60. 前記制御デバイスは、前記制御デバイスにとって既知の対称鍵を用いて前記治療データおよび前記認証コードを暗号化することにより、前記治療データおよび前記認証コードを前記制御デバイスへ送信する、請求項５９の方法。
61. 呼吸治療デバイスは、
    患者インターフェースへ連結することおよび陽圧の空気流れを前記患者インターフェースへ供給することを行うように適合された圧力生成器と、
    メモリと、
    プロセッサと、
    を含み、
    前記メモリはプログラム命令を含み、前記プログラム命令は、前記プロセッサによって実行されると、前記呼吸治療デバイスによって生成された治療データを遠隔サーバーへアップロードするように前記呼吸治療デバイスを制御し、前記プログラム命令は、
    前記遠隔サーバーからナンスを受信することと、
    前記ナンスからの署名鍵と、前記遠隔サーバーにとって既知の秘密とを演算することと、
    前記治療データおよび前記署名鍵を用いて認証コードを生成することであって、前記認証コードは、前記治療データの認証に用いられる、ことと、
    前記治療データおよび前記認証コードを前記遠隔サーバーへ送ることを行うように前記呼吸治療デバイスを制御する、呼吸治療デバイス。
62. ネットワーク化された呼吸治療システムであって、
    患者への呼吸治療の施行のための呼吸治療デバイスと、
    前記呼吸治療デバイスと通信するように構成された遠隔サーバーと、
    を含み、
    前記呼吸治療デバイスは、
    前記遠隔サーバーからナンスを受信することと、
    前記ナンスからの署名鍵と、前記遠隔サーバーにとって既知の秘密とを演算することと、
    治療データおよび前記署名鍵を用いて認証コードを生成することであって、前記認証コードは、前記治療データの認証に用いられる、ことと、
    前記治療データおよび前記認証コードを前記遠隔サーバーへ送ることと、
    を行うように構成される、
    システム。
63. 前記呼吸治療デバイスは、呼吸圧力治療デバイスである、請求項６２のシステム。
64. 前記呼吸治療デバイスとセキュアに通信することおよび前記遠隔サーバーと通信することを行うように構成された制御デバイスをさらに含む、請求項６２のシステム。
65. 前記制御デバイスは、前記呼吸治療デバイスにとって既知の対称鍵を用いて前記呼吸治療デバイスとセキュアに通信するように構成される、請求項６４のシステム。
66. 前記遠隔サーバーは、
    前記治療データおよび第１の認証コードを受信することと、
    ナンスと、前記呼吸治療デバイスにとって既知の秘密とから署名鍵を演算することと、
    前記受信された治療データおよび前記署名鍵から第２の認証コードを演算することと、
    前記第１の認証コードを前記第２の認証コードと比較することにより、前記治療データを認証することと、
    を行うように構成される、
    請求項６２のシステム。
67. 装置であって、
    呼吸治療デバイスから治療データを受信する手段と、
    遠隔サーバーからナンスを受信する手段と、
    前記ナンスを前記呼吸治療デバイスへ送信する手段と、
    前記呼吸治療デバイスから署名鍵を受信する手段であって、前記署名鍵は、前記ナンスと、前記呼吸治療デバイスおよび前記遠隔サーバーにとって既知の秘密とに依存する、手段と、
    前記治療データおよび前記署名鍵を用いて認証コードを生成する手段であって、前記認証コードは、前記治療データの認証に用いられる、手段と、
    前記治療データおよび前記認証コードを前記遠隔サーバーへ送信する手段と、
    を含む、装置。
68. 装置であって、
    呼吸治療デバイスおよび第１の認証コードから治療データを受信する手段と、
    ナンスと、前記呼吸治療デバイスにとって既知の秘密とから、署名鍵を演算する手段と、
    前記受信された治療データおよび前記署名鍵から第２の認証コードを演算する手段と、
    前記第１の認証コードを前記第２の認証コードと比較することにより、前記治療データを認証する手段と、
    を含む、装置。
69. 装置であって、
    呼吸治療を患者へ送達させる手段と、
    遠隔サーバーからナンスを受信する手段と、
    前記ナンスからの署名鍵と、前記遠隔サーバーにとって既知の秘密とを演算する手段と、
    治療データおよび前記署名鍵を用いて認証コードを生成する手段であって、前記認証コードは、前記治療データの認証に用いられる、手段と、
    前記治療データおよび前記認証コードを前記遠隔サーバーへ送信する手段と、
    を含む、装置。