JP7794769B2 - リモート呼吸治療デバイスの管理 - Google Patents

Description

１ 関連出願の相互参照
本出願は、米国仮出願第６２／９３５，３５６号（出願日：２０１９年１１月１４日）に対する優先権を主張する。本明細書中、同文献の内容全体を参考のため援用する。米国公開第２０１７／０１３６１９８について、本明細書中、同文献の内容を参考のため援用する。

２ 技術の背景
２．１ 技術の分野
本技術は、呼吸関連障害のスクリーニング、診断、監視、治療、予防および改善のうち１つ以上に関する。本技術はまた、医療デバイスまたは装置と、その使用とに関する。本技術は、メディカルデバイスまたは装置、その使用および更新に関する。

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

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

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

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

２．２．２ 治療
多様な呼吸治療（例えば、持続的気道陽圧（ＣＰＡＰ）療法、非侵襲的換気（ＮＩＶ）、侵襲的換気（ＩＶ）、および高流量療法（ＨＦＴ））が上記の呼吸障害の１つ以上の治療のために用いられている。

呼吸圧力治療は、気道入口への空気供給を制御された目標圧力において付加することである。この目標圧力は、（タンクベンチレータまたは陽陰圧体外式人工呼吸器などの負圧治療と対照的に）患者の呼吸サイクル全体において雰囲気に対してノミナルに正である。

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

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

侵襲的換気（ＩＶ）は、自身で有効に呼吸することができなくなった患者に対して換気補助を提供し、気管切開管を用いて提供され得る。いくつかの形態において、これらの治療の快適性および有効性が向上し得る。

人工呼吸器は、患者中へポンプされる呼吸のタイミングおよび圧力を制御し得、患者がとる呼吸を監視し得る。これらの患者の制御および監視方法は、従量型方法および圧力サイクル型方法を典型的に含む。従量型方法の例を挙げると、圧制御従量式調節換気（ＰＲＶＣ）、換気量（ＶＶ）、および量制御持続的強制換気法（ＶＣ－ＣＭＶ）技術がある。圧力サイクル型方法の例を挙げると、アシスト制御（ＡＣ）、同期型間歇的強制換気（ＳＩＭＶ）、調節機械換気（ＣＭＶ）、圧補助換気法（ＰＳＶ）、持続的気道陽圧（ＣＰＡＰ）、または終末呼気陽圧（ＰＥＥＰ）技術がある。

２．２．３ 呼吸治療システム
これら呼吸治療は、呼吸治療システムまたはデバイスによって提供され得る。このようなシステムおよびデバイスは、疾病を治療することなくスクリーニング、診断、または監視するためにも、用いられ得る。

呼吸治療システムは、呼吸圧力治療デバイス（ＲＰＴデバイス）、空気回路、加湿器、患者インターフェース、酸素呼吸源、およびデータ管理を含み得る。

２．２．３．１ 患者インターフェース
患者インターフェースは、例えば気道入口への空気流れを提供することにより呼吸装具へのインターフェースを装着者へ提供するために、用いられ得る。空気流れは、鼻および／または口へのマスク、口への管、または患者気管への気管切開管を介して提供され得る。適用される治療に応じて、患者インターフェースは、例えば患者の顔の領域とのシールを形成し得、これにより、治療実行のための周囲圧力と共に充分な分散の圧力において（例えば、例えば周囲圧力に対して約１０ｃｍＨ_２Ｏの陽圧において）ガス送達を促進する。酸素送達などの他の治療形態において、患者インターフェースは、約１０ｃｍＨ_２Ｏの陽圧において気道へのガス供給の送達を促進するのに充分な密閉を含まない場合がある。鼻ＨＦＴなどの流れ治療の場合、患者インターフェースは、鼻孔への吹き込みを行いかつ完全な密閉を明確に回避するように、構成される。このような患者インターフェースの一例は、鼻カニューレである。

ＣＰＡＰ治療は、患者が治療を承諾している場合、特定の呼吸障害の治療においては極めて効果的である。マスクが不快である場合または使用が難しい場合、患者は、治療を承諾しない場合がある。患者はマスクを定期的に洗浄するよう推奨されることが多いため、マスクの清浄が難しい（例えば、組立または分解が困難である場合）、患者は、マスクを清浄することができず、患者のコンプライアンスに影響が出る場合がある。

他の用途（例えば、飛行士）用のマスクの場合、睡眠呼吸障害の治療の使用には不適である場合があるため、睡眠呼吸障害の治療の使用のために設計されたマスクは、他の用途に適している場合がある。

これらの理由のため、睡眠時のＣＰＡＰ送達のための患者インターフェースは、明瞭な分野を形成する。

２．２．３．２ 呼吸圧力治療（ＲＰＴ）デバイス
呼吸圧力治療（ＲＰＴ）デバイスは、例えばデバイスを動作させて気道へのインターフェースへの空気送達流れを生成することにより、上記した複数の治療のうち１つ以上の送達に個別的に、またはシステムの一部として用いられ得る。空気流れは、（呼吸圧力治療のために）圧力制御され得るかまたは（ＨＦＴなどの流れ治療のために）流れ制御され得る。そのため、ＲＰＴデバイスは、流れ治療デバイスとしても機能し得る。ＲＰＴデバイスの例を挙げると、ＣＰＡＰデバイスおよび人工呼吸器がある。ＲＰＴデバイスは、流れ生成器として公知である。

空気圧力生成器は、広範な用途（例えば、工業規模換気システム）において公知である。しかし、医療用途のための空気圧力生成器は、より一般的な空気圧力生成器（例えば、医療機器の信頼性要件、サイズ要件および重量要件）では満足できない特定の要件を有する。加えて、医療治療向けに設計されたデバイスであっても、以下のうち１つ以上に関連して欠陥を免れない場合がある：快適性、ノイズ、使いやすさ、有効性、サイズ、重量、製造可能性、コストおよび信頼性。

特定のＲＰＴデバイスの特殊な要件の一例として、音響ノイズがある。

従来のＲＰＴデバイスのノイズ出力レベルの表（試料１個のみをＩＳＯ３７４４に指定の試験方法を用いてＣＰＡＰモードにおいて１０ｃｍＨ_２Ｏにて測定）。

デバイスの設計者には、無数の選択肢が提示され得る。設計基準同士が対立することが多くあるため、特定の設計選択肢が慣例からほど遠くなるかあるいは避けられないことがある。さらに、特定の態様の快適性および有効性は、１つ以上のパラメータの些細な変更から大きく影響を受ける可能性もある。

２．２．３．３ 空気回路
空気回路は、使用時において空気流れが呼吸治療システムの２つの構成要素（例えば、ＲＰＴデバイスおよび患者インターフェース）間に移動するように、構築および配置された導管またはチューブである。いくつかの場合において、吸息および呼息のための空気回路の別個の脚部であり得る。他の場合において、単一の脚部空気回路が、吸息および呼息双方のために用いられる。

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

２．２．３．５ データ管理
臨床的理由により、呼吸治療が処方された患者が「コンプライアンスを遵守している」（例えば、患者が自身のＲＰＴデバイスを１つ以上の「コンプライアンスルール」に則っているか）を決定するためのデータを入手する場合がある。ＣＰＡＰ治療についてのコンプライアンスルールの一例として、患者がコンプライアンスを遵守しているとみなすためには、患者が連続３０日間のうち少なくとも２１日間にわたってＲＰＴデバイスを一晩あたり少なくとも４時間にわたって使用する必要がある。患者のコンプライアンスを決定するためには、ＲＰＴデバイスのプロバイダ（例えば、ヘルスケアプロバイダ）は、ＲＰＴデバイスを用いた患者の治療を記述するデータを手作業で入手し、所定期間にわたる使用率を計算し、これをコンプライアンスルールと比較し得る。ヘルスケアプロバイダが患者が自身のＲＰＴデバイスをコンプライアンスルールに則って使用したと決定すると、当該ヘルスケアプロバイダは、患者がコンプライアンスを遵守している旨を第三者に通知し得る。

患者の治療において、治療データの第三者または外部システムへの通信から恩恵を受ける他の態様があり得る。

このようなデータを通信および管理するための既存のプロセスの場合、高コスト、時間がかかること、エラーの発生し易さのうち１つ以上が発生し得る。

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

本技術の特定の形態の一態様は、呼吸治療についての患者のコンプライアンスを向上させる方法および／または装置を提供することである。

本技術の一形態は、複数の多様な患者デバイスに対して更新の管理および維持（例えば、ソフトウェア、設定、ファームウェア）を自動的に行う技術を含む。

本技術の一形態の別の態様は、規則に基づいた処理の使用である。この規則に基づいた処理は、患者デバイスからの個別に提出されたリクエストに応答する。これらのリクエストは、特定のデバイスと関連付けられた識別データを含む。このような情報により、患者デバイスへ適用される更新の内容を（このような更新を手動更新する必要無く）システムが自動的に決定することが可能になる。

記載される方法、システム、デバイスおよび装置により、プロセッサにおける機能（例えば、特定目的用コンピュータのプロセッサ、呼吸モニターおよび／または呼吸治療装置の機能）の向上が可能となるように具現され得る。さらに、（例えば、睡眠呼吸障害の監視および／または治療を提供するデバイスを含めて）記載の方法、システム、デバイスおよび装置により、呼吸器疾病の自動管理、監視、および／または治療の技術分野における向上が可能になる。

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

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

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

４．１ 呼吸治療システム：患者インターフェース３０００を装着している患者１０００を含むシステムを示す。このシステムは、鼻枕の形態をとり、ＲＰＴデバイス４０００から供給される陽圧の空気を受容する。ＲＰＴデバイス４０００からの空気は、加湿器５０００によって調節され、空気回路４１７０に沿って患者１０００へと移動する。同床者１１００も図示される。患者は、仰臥位睡眠位置において睡眠している。 患者インターフェース３０００を装着している患者１０００を含むシステムを示す。このシステムは、鼻マスクの形態をとり、ＲＰＴデバイス４０００から供給される陽圧の空気を受容する。ＲＰＴデバイスからの空気は、加湿器５０００によって加湿され、空気回路４１７０に沿って患者１０００へと移動する。 患者インターフェース３０００を装着している患者１０００を含むシステムを含む。患者インターフェース３０００は、フルフェイスマスクをとり、陽圧の空気供給をＲＰＴデバイス４０００から受容する。ＲＰＴデバイスからの空気は、加湿器５０００によって加湿され、空気回路４１７０に沿って患者１０００へと移動する。患者は、側臥位睡眠位置において睡眠している。 ４．２ 呼吸器系および顔の解剖学的構造：鼻腔および口腔、喉頭、声帯ひだ、食道、気管、気管支、肺、肺胞嚢、心臓および横隔膜を含むヒト呼吸器系の概要を示す。 ４．３ 患者インターフェース：本技術の一形態による鼻マスクの形態の患者インターフェースを示す。 ４．４ ＲＰＴデバイス：本技術の一態様に従ったＲＰＴデバイスの電気部品の概略図である。 本技術の一形態によるＲＰＴデバイス中において実行されるアルゴリズムの概略図である。 本技術の一態様に従った図４Ｄの治療エンジンモジュールによって実施される方法を説明したフローチャートである。 ４．５ 加湿器：本技術の一形態による加湿器の等角図である。 本技術の一形態による加湿器の等角図であり、加湿器リザーバ５１１０を加湿器リザーバドック５１３０から除去した様子を示す。 ４．６ 呼吸波形：睡眠時のヒトの典型的な呼吸波形のモデルを示す。 ４．７ データ管理システム：特定の例に従って患者デバイス１０２（１０２Ａ、１０２Ｂ、１０２Ｃ）と通信することおよび患者デバイス１０２（１０２Ａ、１０２Ｂ、１０２Ｃ）へ更新を提供することを行うために用いられる例示的機械管理サービスシステム１０６を示す。 例示的ＲＰＴデバイスと、図７の例示的機械管理サービスシステムとの間の通信を示す信号図である。 特定の例において実行され得るコンピュータ動作のフローチャートである。 特定の例において実行され得るコンピュータ動作のフローチャートである。 特定の例に従ったブローカーのリクエスト（ｂｒｏｋｅｒｅｄ ｒｅｑｕｅｓｔ）の患者デバイスへの送達に関連して多様なコンピューティングデバイスおよび／またはサービス間において発生し得る通信の信号図を示す。 特定の例に従ったブローカーのリクエストの患者デバイスへの送達に関連して多様なコンピューティングデバイスおよび／またはサービス間において発生し得る通信の信号図を示す。 特定の例に従ったブローカーのリクエストの患者デバイスへの送達に関連して多様なコンピューティングデバイスおよび／またはサービス間において発生し得る通信の信号図を示す。 ４．８ コンピューティングデバイス：本明細書中に記載の特徴の実行のためにいくつかの実施形態において用いられ得る例示的コンピューティングデバイスを示す。

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

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

５．１ 治療
一形態において、本技術は、呼吸障害の治療方法を含む。本方法は、患者１０００の気道の入口へ陽圧を付加することを含む。本技術の特定の例において、陽圧における空気供給が鼻孔の片方または双方を介して患者の鼻通路へ提供される。本技術の特定の例において、口呼吸が制限されるか、限定されるかまたは妨げられる。

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

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

患者インターフェースが最低レベルの陽圧を快適に気道へ送達できない場合、患者インターフェースは呼吸圧力治療に不適切であり得る。

本技術の一形態による患者インターフェース３０００は、周囲に対して少なくとも６ｃｍＨ_２Ｏの陽圧で空気供給を提供できるように構築および配置される。

本技術の一形態による患者インターフェース３０００は、周囲に対して少なくとも１０ｃｍＨ_２Ｏの陽圧で空気供給を提供できるように構築および配置される。

本技術の一形態による患者インターフェース３０００は、周囲に対して少なくとも２０ｃｍＨ_２Ｏの陽圧で空気供給を提供できるように構築および配置される。

５．４ ＲＰＴデバイス
本技術の一態様によるＲＰＴデバイス４０００は、機械、空気圧式、および／または電気部品を含み、１つ以上のアルゴリズム４３００（例えば全体的にせよ部分的にせよ本明細書に記載の方法のうちいずれか、プロセス、ソフトウェアモジュールなど）を実行するように構成される。ＲＰＴデバイス４０００は、例えば本文書中のいずれかに記載の呼吸器疾病のうち１つ以上の治療のために患者の気道へ送達される空気流れを生成するように構成され得る。

一形態において、ＲＰＴデバイス４０００は、少なくとも６ｃｍＨ_２Ｏまたは少なくとも１０ｃｍＨ_２Ｏまたは少なくとも２０ｃｍＨ_２Ｏの陽圧を維持しつつ、空気流れを－２０Ｌ／分～＋１５０Ｌ／分の範囲で送達できるように構築および配置される。

ここで図４Ｃを参照すると、ＲＰＴデバイス４０００は、電気電源４２１０、１つ以上の入力デバイス４２２０、中央コントローラ４２３０、治療デバイスコントローラ４２４０、圧力生成器４１４０、１つ以上の保護回路４２５０、メモリ４２６０、変換器４２７０、データ通信インターフェース４２８０、および１つ以上の出力デバイス４２９０を有することができる。電気部品４２００は、シングルプリント回路基板アセンブリ（ＰＣＢＡ）４２０２上に取り付けられ得る。一代替形態において、ＲＰＴデバイス４０００は、１つよりも多くのＰＣＢＡ４２０２を含み得る。特定の例示的実施形態において、ＲＰＴデバイス４００は、図１１に関連して述べるようなコンピューティングデバイスを含み得る。特定の例において、図４Ｃに関連して述べる電気部品は、図１１に記載のような対応物に対応し得る。

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

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

５．４．１．２ 入力デバイス
本技術の一形態において、ＲＰＴデバイス４０００は、人間がデバイスと相互作用を可能にするためのボタン、スイッチまたはダイヤルの形態をとる１つ以上の入力デバイス４２２０を含む。ボタン、スイッチまたはダイヤルは、タッチスクリーンを介してアクセスすることが可能な物理的デバイスまたはソフトウェアデバイスであり得る。ボタン、スイッチまたはダイヤルは、一形態において外部ハウジング４０１０へ物理的に接続させてもよいし、あるいは、別の形態において、中央コントローラ４２３０へ電気接続された受信器と無線通信させてもよい。

一形態において、入力デバイス４２２０は、人間が値および／またはメニュー選択肢を選択することを可能にするように、構築および配置され得る。

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

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

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

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

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

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

本技術のいくつかの形態において、中央コントローラ４２３０は、本明細書中に記載の１つ以上の方法（例えば、非一時的なコンピュータ可読記憶媒体（例えば、メモリ４２６０）のような中に格納されたコンピュータプログラムとして表現された１つ以上のアルゴリズム４３００（図４Ｄに関連して説明））を具現するように構成される。本技術のいくつかの形態において、中央コントローラ４２３０は、ＲＰＴデバイス４０００と一体化され得る。しかし、本技術のいくつかの形態において、いくつかの方法は、リモートに配置されたコンピューティングデバイス（例えば、コンピューティングデバイス１１００）によって行われ得る。例えば、リモートに配置されたデバイスは、保存されたデータ（例えば、本明細書中に記載のセンサのうちいずれかからのもの）の分析により、人工呼吸器の制御設定を決定し得るか、または、呼吸関連イベントを検出し得る。

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

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

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

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

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

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

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

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

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

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

一形態において、リモート外部通信ネットワーク４２８２は、インターネットである。データ通信インターフェース４２８０は、インターネットへの接続のために、有線通信（例えば、イーサネットまたは光ファイバを介して）あるいは無線プロトコル（例えば、ＣＤＭＡ、ＧＳＭ、ＬＴＥ）を用い得る。

一形態において、ローカル外部通信ネットワーク４２８４は、１つ以上の通信規格を用いる（例えば、Ｂｌｕｅｔｏｏｔｈまたは消費者赤外線プロトコル）。

一形態において、リモート外部デバイス４２８６は、１つ以上のコンピュータである（例えば、ネットワークされたコンピュータのクラスター）。一形態において、リモート外部デバイス４２８６は、物理的コンピュータではなく仮想コンピュータであり得る。いずれの場合も、このようなリモート外部デバイス４２８６は、適切に権限付与された者（例えば、臨床医）にとってアクセス可能であり得る。

ローカル外部デバイス４２８８は、パーソナルコンピュータ、携帯電話、タブレットまたはリモートコントロール器であり得、ローカル外部通信ネットワーク４２８４を介してＲＰＴデバイス４０００のデータ通信インターフェース４２８０と通信する。

５．４．１．９ 任意選択のディスプレイ、警告を含む出力デバイス
本技術による出力デバイス４２９０は、視覚、音声および触覚ユニットのうち１つ以上の形態をとり得る。Ａ視覚ディスプレイは、液晶ディスプレイ（ＬＣＤ）または発光ダイオード（ＬＥＤ）ディスプレイであり得る。

５．４．１．９．１ ディスプレイドライバ
ディスプレイドライバ４２９２は、ディスプレイ４２９４上に表示されるべき文字、記号または画像を入力として受信し、これらをコマンドに変換する。これらのコマンドにより、ディスプレイ４２９４は、文字、記号または画像を表示する。

５．４．１．９．２ ディスプレイ
ディスプレイ４２９４は、ディスプレイドライバ４２９２から受信されたコマンドに応答して、文字、記号または画像を視覚表示するように構成される。例えば、ディスプレイ４２９４は、８セグメントディスプレイであり得る。この場合、ディスプレイドライバ４２９２により、各文字または記号（例えば、「０」という数字）は、（８個の各セグメントが特定の文字または記号の表示のために起動されたかを示す）８個の論理信号に変換される。

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

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

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

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

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

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

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

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

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

５．４．２ ＲＰＴデバイスアルゴリズム
上記したように、本技術のいくつかの形態において、中央コントローラ４２３０は、図４Ｄに示すような１つ以上のアルゴリズム４３００を実行するように構成され得る。これらのアルゴリズムは、非一時的なコンピュータ可読記憶媒体（例えば、メモリ４２６０）中に保存されたコンピュータプログラムとして表現され得る。アルゴリズム４３００は、モジュールまたはソフトウェアモジュールと呼ばれるグループに概してグループ分けされる。

本技術の他の形態においては、アルゴリズム４３００の一部または全部が、ローカル外部デバイス４２８８またはリモート外部デバイス４２８６などの外部デバイスのコントローラによって具現され得る。かかる形態においては、アルゴリズム４３００のうち外部デバイスで実行される部分に必要な入力信号および／または中間アルゴリズム出力を表すデータが、ローカル外部通信ネットワーク４２８４またはリモート外部通信ネットワーク４２８２を介して外部デバイスへと通信され得る。かかる形態においては、アルゴリズム４３００のうち外部デバイスで実行される部分が、外部デバイスのコントローラにとってアクセス可能な非一時的なコンピュータ可読記憶媒体に格納されたコンピュータプログラムとして表現され得る。かかるプログラムは、外部デバイスのコントローラを、アルゴリズム４３００の一部を実行するように構成する。

かかる形態においては、治療エンジンモジュール４３２０を介して外部デバイスによって生成された治療パラメータが（かかる形態においては、アルゴリズム４３００の部分の一部が、外部デバイスによって実行される）、中央コントローラ４２３０に伝達されて治療制御モジュール４３３０に渡され得る。

５．４．２．１ 事前処理モジュール
本技術の一形態による事前処理モジュール４３１０は、変換器４２７０（例えば流量センサ４２７４または圧力センサ４２７２）からの信号を入力として受信し、１つ以上の出力値を計算するための１つ以上のプロセスステップを行う。これらの出力値は、別のモジュール（例えば、治療エンジンモジュール４３２０）への入力として用いられる。

本技術の一形態において、出力値は、インターフェース圧力Ｐｍ、呼吸流量Ｑｒおよび漏洩流量Ｑｌを含む。

本技術の多様な形態において、事前処理モジュール４３１０は、以下のアルゴリズムのうち１つ以上を含む：インターフェース圧力推定４３１２、通気流量推定４３１４、漏洩流量推定４３１６および呼吸流量推定４３１８。

５．４．２．１．１ インターフェース圧力推定
本技術の一形態において、インターフェース圧力推定アルゴリズム４３１２は、空気圧ブロックの出口の近隣の空気圧経路中の圧力（デバイス圧力Ｐｄ）を示す信号を圧力センサ４２７２から入力として受信し、ＲＰＴデバイス４０００を排出する気流の流量（デバイス流量Ｑｄ）を示す信号を流量センサ４２７４から入力として受信する。補充用ガスを全く含まないデバイス流量Ｑｄが、合計流量Ｑｔとして用いられ得る。インターフェース圧力アルゴリズム４３１２は、空気回路４１７０を通じた圧力降下ΔＰを推定する。合計流量Ｑｔに対する圧力降下ΔＰの依存関係は、圧力降下特性ΔＰ（Ｑ）により特定の空気回路４１７０についてモデル化することができ得る。次に、インターフェース圧力推定アルゴリズム４３１２は、患者インターフェース３０００または３８００中の推定圧力Ｐｍを出力として提供する。患者インターフェース３０００または３８００中の圧力Ｐｍは、デバイス圧力Ｐｄから空気回路圧力降下ΔＰを減算した値として推定することができ得る。

５．４．２．１．２ 通気流量推定
本技術の一形態において、通気流量推定アルゴリズム４３１４は、インターフェース圧力推定アルゴリズム４３１２から患者インターフェース３０００または３８００中の推定圧力Ｐｍを入力として受信し、患者インターフェース３０００または３８００中の通気部３４００からの空気の通気流量Ｑｖを推定する。特定の通気部３４００におけるインターフェース圧力Ｐｍに対する通気流量Ｑｖの使用時の依存関係は、通気特性Ｑｖ（Ｐｍ）によってモデル化され得る。

５．４．２．１．３ 漏洩流量推定
本技術の一形態において、漏洩流量推定アルゴリズム４３１６は、合計流量Ｑｔおよび通気流量Ｑｖを入力として受信し、漏洩流量Ｑｌの推定を出力として提供する。一形態において、漏洩流量推定アルゴリズムは、いくつかの呼吸サイクル（例えば、約１０秒）を含むくらいに充分に長い期間にわたって合計流量Ｑｔと通気流量Ｑｖとの間の差平均を計算することにより、漏洩流量Ｑｌを推定する。

一形態において、漏洩流量推定アルゴリズム４３１６は、漏洩流量Ｑｌを出力として提供し、漏洩コンダクタンスを計算することおよび漏洩流量Ｑｌを漏洩コンダクタンスおよび圧力Ｐｍの関数となるように決定することにより、患者インターフェース３０００または３８００中の合計流量Ｑｔ、通気流量Ｑｖ、および推定圧力Ｐｍを入力として受信する。漏洩コンダクタンスは、合計流量Ｑｔと通気流量Ｑｖとの間の差に等しいローパスフィルタされた非通気流量の商と、圧力Ｐｍのローパスフィルタされた平方根として計算され、ローパスフィルタ時定数は、いくつかの呼吸サイクル（例えば、約１０秒）を含むだけの充分な値を有する。漏洩流量Ｑｌは、漏洩コンダクタンスおよび圧力の関数Ｐｍの積として推定され得る。

５．４．２．１．４ 呼吸流量推定
本技術の一形態において、呼吸流量推定アルゴリズム４３１８は、合計流量Ｑｔ、通気流量Ｑｖおよび漏洩流量Ｑｌを入力として受信し、（通気流量Ｑｖおよび漏洩流量Ｑｌを合計流量Ｑｔから除算することにより）呼吸空気流量Ｑｒを患者について推定する。
５．４．２．２ 治療エンジンモジュール

本技術の一形態において、治療エンジンモジュール４３２０は、患者インターフェース３０００または３８００中の圧力Ｐｍおよび患者への空気呼吸流量Ｑｒのうち１つ以上を入力として受信し、１つ以上の治療パラメータを出力として提供する。

本技術の一形態において、治療パラメータは、治療圧力Ｐｔである。

本技術の一形態において、治療パラメータは、圧力変化の振幅、ベース圧力および目標換気のうち１つ以上である。

多様な形態において、治療エンジンモジュール４３２０は、以下のアルゴリズムのうち１つ以上を含む：フェーズ決定４３２１、波形決定４３２２、換気決定４３２３、吸気流制限決定４３２４、無呼吸／呼吸低下決定４３２５、いびき決定４３２６、気道開通性決定４３２７、目標換気決定４３２８、および治療パラメータ決定４３２９。

５．４．２．２．１ フェーズ決定
本技術の一形態において、ＲＰＴデバイス４０００は、フェーズを決定しない。

本技術の一形態において、フェーズ決定アルゴリズム４３２１は、呼吸流量Ｑｒを示す信号を入力として受信し、患者１０００の現在の呼吸サイクルのフェーズを出力Φとして提供する。

離散フェーズ決定として知られるいくつかの形態において、フェーズ出力Φは、別個の変数である。離散フェーズ決定の１つの実行は、吸息または呼息の値を有する２値フェーズ出力Φを提供し、この２値フェーズ出力Φは、（自発的な吸息および呼息それぞれの開始の検出時において）例えば回転数０および回転数０．５の値としてそれぞれ表される。「トリガ」および「サイクル」するＲＰＴデバイス４０００は、離散フェーズ決定を有効に行う。なぜならば、トリガ点およびサイクル点は、フェーズが呼息から吸息へおよび吸息から呼息へそれぞれ変化する瞬間であるからである。二値フェーズ決定の一実行において、フェーズ出力Φは、呼吸流量Ｑｒが正の閾値を超える値を有するときに、離散値０を有し（これによりＲＰＴデバイス４０００を「トリガ」する）、呼吸流量Ｑｒの値が負の閾値よりもより大きな負の値であるときに０．５回転の離散値（これにより、ＲＰＴデバイス４０００を「サイクルさせる」）を有するように、決定される。吸息時間Ｔｉおよび呼息時間Ｔｅは、（吸気を示す）０および（呼気を示す）０．５それぞれに等しいフェーズΦと共に費やされた時間の多くの呼吸サイクルにわたって推定された典型的値であり得る。

離散フェーズ決定の別の実行により、吸息、吸息中の一時停止および呼息のうち１つの値を備えた３値フェーズ出力Φが得られる。

他の形態において、連続フェーズ決定として知られるフェーズ出力Φは連続する変数であり、例えば０回転～１回転または０～２πラジアンの間で変動する。連続フェーズ決定を行うＲＰＴデバイス４０００は、連続フェーズが０回転および０．５回転それぞれに到達したときに、トリガおよびサイクルし得る。連続フェーズ決定の一実行において、フェーズの連続値Φは、呼吸流量Ｑｒのファジー論理分析を用いて決定される。この実行において決定されるフェーズの連続値は、「ファジーフェーズ」と呼ばれることが多い。ファジーフェーズ決定アルゴリズム４３２１の１つの実行において、以下の規則は、呼吸流量Ｑｒに適用される：
１．呼吸流量がゼロでありかつ高速増加する場合、フェーズの回転数は０である。
２．呼吸流量が大きく正でありかつ安定している場合、フェーズの回転数は０．２５である。
３．呼吸流量がゼロでありかつ高速に下降する場合、フェーズの回転数は０．５である。
４．呼吸流量が大きく負でありかつ安定している場合、フェーズの回転数は０．７５である。
５．呼吸流量がゼロでありかつ安定しており、呼吸流量の５秒ローパスフィルタリングされた絶対値が大きい場合、フェーズの回転数は０．９である。
６．呼吸流量が正でありかつフェーズが呼気である場合、フェーズの回転数は０である。
７．呼吸流量が負でありかつフェーズが吸気である場合、フェーズの回転数は０．５である。
８．呼吸流量の５秒のローパスフィルタされた絶対値が大きい場合、フェーズは、時定数２０秒によってローパスフィルタされた患者の呼吸速度に等しい一定速度で増加する。

各規則の出力は、フェーズが規則の結果でありかつ大きさが（規則が真である）ファジー範囲であるベクトルとして表され得る。呼吸流量が例えば「大きい」、「安定している」ファジー範囲は、適切なメンバシップ関数によって決定される。ベクトルとして表される規則結果は、その後何らかの関数（例えば、セントロイドの取得）によって組み合わされる。このような組み合わせにおいて、これらの規則は、均等に重み付けしてもよいし、あるいは異なる様態で重み付けしてもよい。

連続フェーズ決定の別の実行において、フェーズΦは、吸息時間Ｔｉおよび呼息時間Ｔｅと同様、上記のように先ず呼吸流量Ｑｒから個別に推定される。任意の瞬間における連続フェーズΦは、先行トリガ瞬間から経過した吸息時間Ｔｉの割合の半分または０．５回転に先行サイクル瞬間から経過した呼息時間Ｔｅの割合を加算した値（これらのうち、より直近の瞬間）として決定される。

５．４．２．２．２ 波形決定
本技術の一形態において、治療パラメータ決定アルゴリズム４３２９は、患者の呼吸サイクル全体を通じてほぼ一定の治療圧力を提供する。

本技術の他の形態において、治療制御モジュール４３３０は、圧力生成器４１４０を制御して、波形テンプレートΠ（Φ）に従って患者呼吸サイクルのフェーズΦの関数として変動する治療圧力Ｐｔを提供させる。

本技術の一形態において、波形決定アルゴリズム４３２２は、波形テンプレートΠ（Φ）を提供する。波形テンプレートは、治療パラメータ決定アルゴリズム４３２９によって用いられる予定のフェーズ決定アルゴリズム４３２１によって提供されるフェーズ値Φの変域について［０，１］の範囲内の値を有する。

一形態において、離散的または連続的に値をとるフェーズに適したものとして、波形テンプレートΠ（Φ）は矩形波テンプレートであり、０．５回転までのフェーズ値に対して１の値を有し、０．５回転を超えるフェーズ値に対して０の値を有する。一形態において、連続的に値をとるフェーズに適したものとして、波形テンプレートΠ（Φ）は、２つの平滑に曲線状の部分を含む（すなわち、０．５回転までのフェーズ値に対して平滑に曲線状の（例えば、上昇コサインの）０から１への上昇、および０．５回転を超えるフェーズ値に対して１から０への平滑に曲線状の（例えば、指数関数的）低下）。一形態において、連続的に値をとるフェーズに適したものとして、波形テンプレートΠ（Φ）は矩形波に基づくが、０．５回転よりも低い「立上がり時間」までのフェーズ値に対して０～１の平滑な上昇を持ち、０．５回転後の「下降時間」内のフェーズ値に対して１から０への、０．５回転よりも低い「下降時間」をもつ平滑な下降を有する。

本技術のいくつかの形態において、波形決定アルゴリズム４３２２は、ＲＰＴデバイスの設定に応じて、波形テンプレートΠ（Φ）を波形テンプレートのライブラリから選択する。ライブラリ中の各波形テンプレートΠ（Φ）は、フェーズ値Φに対する値Πのルックアップテーブルとして提供され得る。他の形態において、波形決定アルゴリズム４３２２は、恐らくは１つ以上のパラメータ（例えば、指数曲線部分の時間定数）によってパラメータ化された所定の関数形態を用いて、波形テンプレートΠ（Φ）を「オンザフライ」で計算する。機能形式のこれらのパラメータは、事前に決定されてもよいし、あるいは、患者１０００の現在の状態に依存し得る。

吸息（Φ＝０回転）または呼息（Φ＝０．５回転）の離散二値フェーズに適した本技術のいくつかの形態において、波形決定アルゴリズム４３２２は、最も直近のトリガ瞬間から測定された離散フェーズΦおよび時間ｔの関数として、波形テンプレートΠを「オンザフライ」で計算する。１つのこのような形態において、波形決定アルゴリズム４３２２は、波形テンプレートΠ（Φ，ｔ）を２つの部分（吸気および呼気）において以下のように計算する：
ここで、Π_ｉ（ｔ）およびΠ_ｅ（ｔ）は、波形テンプレートΠ（Φ，ｔ）の吸気部分および呼気部分である。１つのこのような形態において、波形テンプレートの吸気部分Π_ｉ（ｔ）は、立上がり時間によってパラメータ化された０から１への平滑な上昇であり、波形テンプレートの呼気部分Π_ｅ（ｔ）は、下降時間によってパラメータ化された１から０への平滑な下降である。

５．４．２．２．３ 換気決定
本技術の一形態において、換気決定アルゴリズム４３２３は、呼吸流量Ｑｒを入力として受信し、現在の患者換気Ｖｅｎｔを示す測定を決定する。

いくつかの実行において、換気決定アルゴリズム４３２３は、実際の患者換気の推定である換気Ｖｅｎｔの測定を決定する。１つのこのような実行は、呼吸流量Ｑｒの絶対値の半分をとることであり、これは、ローパスフィルタ（例えば、２次ベッセルローパスフィルタ）によりコーナ周波数０．１１Ｈｚにより任意選択的にフィルタリングされる。

他の実行において、換気決定アルゴリズム４３２３は、実際の患者換気に広範に比例する換気Ｖｅｎｔの測定を決定する。１つのこのような実行において、ピーク呼吸流量Ｑｐｅａｋをサイクルの吸気部分にわたって推定する。上記および呼吸流量Ｑｒのサンプリングを用いた他の手順により、換気に広範に比例する測定が生成される（ただし、流量波形が大きく変化しない場合（ここで、２つの呼吸の形状は、（時間および振幅において正規化された呼吸の流量波形が類似する場合に）類似するものとしてとられる））。いくつかの簡単な例を挙げると、正の呼吸流量のメジアン、呼吸流量の絶対値のメジアン、および流量の標準偏差がある。正の係数を用いた（およびさらには正の係数および負の係数双方を用いた）呼吸流量の絶対値の任意の順序統計量の任意の線形的組み合わせは、換気に概ね比例する。別の例として、吸気部分の（時間的な）中間Ｋ比例における呼吸流量の平均があり、ここで、０＜Ｋ＜１である。流量形状が一定である場合、換気に対して高精度に比例する任意の多数の測定が存在する。

５．４．２．２．４ 吸気流制限の決定
本技術の一形態において、中央コントローラ４２３０は、吸気流制限の範囲の決定について、吸気流制限決定アルゴリズム４３２４を実行する。

一形態において、吸気流制限決定アルゴリズム４３２４は、呼吸流量信号Ｑｒを入力として受信し、呼吸の吸気部分が吸気流制限を示す範囲の計量を出力として提供する。

本技術の一形態において、各呼吸の吸気部分は、ゼロ交差検出器によって特定される。複数の等間隔で配置された点（例えば、６５個の点）が、時点を示し、各呼吸について吸気流量－時間曲線に沿って補間器によって補間される。その後、これらの点によって記述された曲線をスケーラーによって単位長さ（継続期間／期間）および単位面積を持つようにスケールすることにより、呼吸数および深さの変化による影響を除去する。次に、スケールされた呼吸を通常の非閉塞呼吸を示す（図６Ａに示す呼吸の吸気部分と同様の）事前保存されたテンプレートと比較器において比較する。吸気時の任意の時点において呼吸が（例えば咳、ため息、嚥下およびしゃっくりに起因してに起因して）指定された閾値（典型的にはスケーリング単位として１）を超えてこのテンプレートから（試験要素によって決定されたように）逸脱した場合、拒否される。データが拒否されなかった場合、第１のこのようなスケールされた点の移動平均が、先行するいくつかの吸気イベントについて中央コントローラ４２３０によって計算される。これを、例えば第２のこのような点についての同一吸気イベントについて同様に繰り返していく。よって、例えば、６５個のスケールされたデータ点が中央コントローラ４２３０によって生成され、先行するいくつかの吸気イベント（例えば、３つのイベント）の移動平均を示す。本明細書中、以下において、（例えば、６５個の）点の連続更新された値の移動平均を「スケールされた流量」と呼び、Ｑｓ（ｔ）として指定する。あるいは、単一の吸気イベントを移動平均の代わりに用いてもよい。

スケールされた流量から、部分閉塞の決定に関連する２つの形状係数が計算され得る。

形状係数１は、中間（例えば、３２個の）スケールされた流量点の全体平均（例えば、６５個の）スケールされた流量点に対する中間（例えば、３２個の）スケールされた流量点の平均の比率である。この比率が１を超えた場合、呼吸は正常であるととられる。この比率が１以下である場合、呼吸に閉塞が発生しているととられる。比率が約１．１７である場合、部分閉塞呼吸と無閉塞の呼吸との間の閾値としてとられ、一定レベルの閉塞と同等となり、典型的な患者における適切な酸素投与のメンテナンスが許可される。

形状係数２は、単位スケールされた流量からの平均二乗偏差として計算され、中間（例えば、３２個の）点にわたってとられる。平均二乗偏差が約０．２単位である場合、正常とみなされる。平均二乗偏差がゼロである場合、呼吸の流れが全体的に制限されているとみなされる。平均二乗偏差がゼロに近いほど、呼吸の流れ制限が顕著であるものとみなされる。

形状係数１および２は、代替的に用いてもよいし、あるいは組み合わせて用いてもよい。本技術の他の形態において、サンプリングされた点、呼吸および中間点の数は、上記したものと異なり得る。さらに、閾値も上記したものと異なり得る。

５．４．２．２．５ 無呼吸および呼吸低下の決定
本技術の一形態において、中央コントローラ４２３０は、無呼吸および／または呼吸低下の存在の決定のために、無呼吸／呼吸低下決定アルゴリズム４３２５を実行する。

一形態において、無呼吸／呼吸低下決定アルゴリズム４３２５は、呼吸流量信号Ｑｒを入力として受信し、無呼吸または呼吸低下が検出されたかを示すフラッグを出力として提供する。

一形態において、呼吸流量Ｑｒの関数が所定の期間流量閾値を下回った場合、無呼吸が検出されるものとされる。この関数は、ピーク流量、比較的短期間の平均流量、または比較的短期間の平均およびピーク流量の流量中間値を決定し得る（例えば、ＲＭＳ流量）。流量閾値は、流量の比較的長期の測定であり得る。

一形態において、呼吸流量Ｑｒの関数が所定の期間にわたって第２の流量閾値を下回った場合、呼吸低下が検出されるものとする。この関数は、ピーク流量、比較的短期間の平均流量、または比較的短期間の平均およびピーク流量の流量中間値を決定し得る（例えば、ＲＭＳ流量）。第２の流量閾値は、流量の比較的長期の測定であり得る。第２の流量閾値は、無呼吸の検出に用いられる流量閾値よりも高い。

５．４．２．２．６ いびきの決定
本技術の一形態において、中央コントローラ４２３０は、いびきの範囲の決定のために１つ以上のいびき決定アルゴリズム４３２６を実行する。

一形態において、いびき決定アルゴリズム４３２６は、呼吸流量信号Ｑｒを入力として受信し、いびきが存在している範囲の測定値を出力として提供する。

いびき決定アルゴリズム４３２６は、流量信号の強度を３０～３００Ｈｚの範囲内において決定するステップを含み得る。さらに、いびき決定アルゴリズム４３２６は、背景ノイズ（例えば、送風機からのシステム中の気流音）を低減するために呼吸流量信号Ｑｒをフィルタリングするステップを含み得る。

５．４．２．２．７ 気道開通性の決定
本技術の一形態において、中央コントローラ４２３０は、気道開通性の範囲の決定のために１つ以上の気道開通性決定アルゴリズム４３２７を実行する。

一形態において、気道開通性決定アルゴリズム４３２７は、呼吸流量信号Ｑｒを入力として受信し、信号の出力を約０．７５Ｈｚ～約３Ｈｚの周波数範囲内において決定する。この周波数範囲内にピークが有る場合、気道の開口を示すものとみなされる。ピークが無い場合、気道閉鎖を示すものとみなされる。

一形態において、ピークの探索範囲となる周波数範囲は、治療圧力Ｐｔにおける小さな強制振動の周波数である。１つの実行において、強制振動は、２Ｈｚの周波数であり、振幅は約１ｃｍＨ_２Ｏである。

一形態において、気道開通性決定アルゴリズム４３２７は、呼吸流量信号Ｑｒを入力として受信し、心臓発生信号の有無を決定する。心臓発生信号が無い場合、気道閉鎖があるものとみなされる。

５．４．２．２．８ 目標換気の決定
本技術の一形態において、中央コントローラ４２３０は、現在の換気Ｖｅｎｔの測定を入力としてとり、換気測定のための目標値Ｖｔｇｔの決定のために、１つ以上の目標換気決定アルゴリズム４３２８を実行する。

本技術のいくつかの形態において、目標換気決定アルゴリズム４３２８は存在せず、目標値Ｖｔｇｔは、例えばＲＰＴデバイス４０００の構成時におけるハードコーディングによってまたは入力デバイス４２２０を通じた手動入力によって事前決定される。

順応性サーボ換気（ＡＳＶ）などの本技術の他の形態において、目標換気決定アルゴリズム４３２８は、患者の典型的な最近の換気を示す目標値Ｖｔｇｔを値Ｖｔｙｐから演算する。

順応性サーボ換気のいくつかの形態において、目標換気Ｖｔｇｔは、典型的な最近の換気Ｖｔｙｐの高比率としてかつ典型的な最近の換気Ｖｔｙｐ未満の値として演算される。このような形態の高比率は、（８０％、１００％）または（８５％、９５％）または（８７％、９２％）の範囲であり得る。

順応性サーボ換気の他の形態において、目標換気Ｖｔｇｔは、典型的な最近の換気Ｖｔｙｐの１よりも若干大きな倍数として演算される。

典型的な最近の換気Ｖｔｙｐは、一定の所定の時間スケールにわたる複数の時刻にわたる現在の換気Ｖｅｎｔの測定の分布がクラスター化する傾向となる値（すなわち、最近の履歴にわたる現在の換気の測定の中央傾向の測定）である。目標換気決定アルゴリズム４３２８の１つの実行において、直近の履歴は、数分間のオーダーであるが、いずれの場合も、チェーン・ストークスの漸増サイクルおよび漸減サイクルの時間スケールよりも長くする必要がある。目標換気決定アルゴリズム４３２８は、典型的な最近の換気Ｖｔｙｐを現在の換気Ｖｅｎｔの測定から決定するための中央傾向の多様な周知の測定のうちいずれを用い得る。１つのこのような測定として、現在の換気Ｖｅｎｔの測定に対するローパスフィルタ出力があり、時定数は１００秒に等しい。

５．４．２．２．９ 治療パラメータの決定
本技術のいくつかの形態において、中央コントローラ４２３０は、治療エンジンモジュール４３２０中のその他のアルゴリズムのうち１つ以上から返送された値を用いて、１つ以上の治療パラメータの決定のための１つ以上の治療パラメータ決定アルゴリズム４３２９を実行する。

本技術の一形態において、治療パラメータは、瞬間的治療圧力Ｐｔである。この形態の１つの実行において、治療パラメータ決定アルゴリズム４３２９は、上記式を用いて治療圧力Ｐｔを決定する：
ここで、
● Ａは振幅であり、
● Π（Φ，ｔ）は、フェーズの現在の値Φおよび時間のｔにおける（０から１の範囲の）波形テンプレート値であり、
● Ｐ_０はベース圧力である。

波形決定アルゴリズム４３２２がフェーズΦによってインデックスされた値Πのルックアップテーブルとして波形テンプレートΠ（Φ，ｔ）を提供する場合、治療パラメータ決定アルゴリズム４３２９は、フェーズ決定アルゴリズム４３２１から返送されたフェーズの現在の値Φに対して最近接ルックアップテーブル入力をロケートすることまたはフェーズの現在の値Φにまたがる２つの入力間の補間により、方程式（１）を適用する。

振幅Ａベース圧力Ｐ_０の値は、治療パラメータ決定アルゴリズム４３２９によって選択された呼吸圧力治療モードに応じて以下に述べるような方法により設定され得る。

５．４．２．３ 治療制御モジュール
本技術の一態様による治療制御モジュール４３３０は、治療エンジンモジュール４３２０の治療パラメータ決定アルゴリズム４３２９からの治療パラメータを入力として受信し、これらの治療パラメータに従って圧力生成器４１４０から空気流れを送達するように、圧力生成器を制御する。

本技術の一形態において、治療パラメータは治療圧力Ｐｔであり、治療制御モジュール４３３０は、患者インターフェース３０００または３８００におけるインターフェース圧力Ｐｍが治療圧力Ｐｔに等しい空気流れを圧力生成器４１４０から送達するように、圧力生成器を制御する。

５．４．２．４ 故障状態の検出
本技術の一形態において、中央コントローラ４２３０は、故障状態の検出のための１つ以上の方法４３４０を実行する。１つ以上の方法４３４０によって検出される故障状態は、以下のうち少なくとも１つを含み得る：
● 停電（電力無しまたは電力不足）
● 変換器故障の検出
● 構成要素の存在の検出が無いこと
● 動作パラメータが推奨範囲から外れている（例えば、圧力、流量、温度、ＰａＯ_２）
● 検出可能な警告信号の生成のための試験警告が無いこと。

故障状態が検出されると、対応するアルゴリズム４３４０は、故障の存在の信号生成を以下のうち１つ以上によって行う：
● 可聴、視覚および／またはキネティック（例えば、振動）警告の開始
● 外部デバイスへのメッセージ送信
● インシデントの記録

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

詳細には、空気回路４１７０は、空気圧ブロックの出口および患者インターフェースと流体接続され得る。空気回路は、空気送達管と呼ばれ得る。いくつかの場合において、吸息および呼息のために回路の別個の脚部が設けられ得る。他の場合において、単一の脚部が用いられる。

いくつかの形態において、空気回路４１７０は、例えば空気温度の維持または上昇のために空気回路中の空気を加熱するように構成された１つ以上の加熱要素を含み得る。この加熱要素は、熱線回路の形態をとり得、１つ以上の変換器（例えば、温度センサ）を含み得る。一形態において、熱線回路は、空気回路４１７０の軸の周囲においてらせん状に巻かれ得る。加熱要素は、コントローラ（例えば、中央コントローラ４２３０）と通信し得る。

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

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

加湿器リザーバ５１１０は、図５Ａ～図５Ｂに示すように水位インジケータ５１５０を含み得る。いくつかの配置において、加湿器リザーバドック５１３０は、ロック機能を含み得る（例えば、リザーバ５１１０を加湿器リザーバドック５１３０内に保持するように構成されたロックレバー５１３５）。１つの配置によれば、リザーバ５１１０は、加熱要素５２４０からリザーバ５１１０中の一定量の液体への効率的な熱伝達を可能にするように構成された伝導性部分５１２０を含む。一形態において、伝導性部分５１２０はプレートとして配置され得るが、他の形状も適切であり得る。

５．７ 呼吸波形
図６Ａは、睡眠時のヒトの典型的な呼吸波形のモデルを示す。横軸は時間であり、縦軸は呼吸流量である。パラメータ値は変動し得るため、典型的な呼吸は、以下のおおよその値を持ち得る：一回換気量、Ｖｔ、０．５Ｌ、吸息時間、Ｔｉ、１．６秒、ピーク吸気流量、Ｑピーク、０．４Ｌ／秒、呼息時間、Ｔｅ、２．４ｓ、ピーク呼気流量、Ｑピーク、－０．５Ｌ／秒。呼吸の合計継続期間Ｔｔｏｔは、約４ｓである。人間は典型的には、１分あたり呼吸を約１５回行い（ＢＰＭ）、換気Ｖｅｎｔは約７．５Ｌ／ｍｉｎである。典型的な負荷サイクル、ＴｉとＴｔｏｔの比は約４０％である。

５．８ 呼吸治療モード
多様な呼吸治療モードは、開示した呼吸治療システムによって実行され得る。

５．８．１ ＣＰＡＰ治療
呼吸圧力治療のいくつかの実行において、中央コントローラ４２３０は、治療圧力Ｐｔを治療圧力方程式（１）に従って治療パラメータ決定アルゴリズム４３２９の一部として設定する。いくつかのそのような実行において、振幅Ａは等しくゼロであるため、治療圧力Ｐｔ（現在瞬間の時間におけるインターフェース圧力Ｐｍによって達成される目標値をしめす）は呼吸サイクル全体において同様にベース圧力Ｐ_０に等しい。このような実行は一般的には、ＣＰＡＰ治療のヘッディングの下にグループ分けされる。このような実行において、フェーズΦまたは波形テンプレートΠ（Φ）を決定するための治療エンジンモジュール４３２０は不要である。

ＣＰＡＰ治療において、ベース圧力Ｐ_０は一定の値であり得、ハードコードされるかまたはＲＰＴデバイス４０００へ手動入力される。中央コントローラ４２３０は、治療エンジンモジュール４３２０中の各アルゴリズムから返送された睡眠呼吸障害の指標または測定（例えば、流れ制限、無呼吸、呼吸低下、開通性、およびいびきのうち１つ以上）の関数としてベース圧力Ｐ_０を繰り返して計算し得る。この代替法は、ＡＰＡＰ治療とも呼ばれる。

図４Ｅは、中央コントローラ４２３０によって実行される方法４５００を示すフローチャートである。方法４５００において、圧力補助Ａがゼロに等しい場合、ベース圧力Ｐ_０を治療パラメータ決定アルゴリズム４３２９のＡＰＡＰ治療実行の一部として連続的に計算する。

方法４５００は、ステップ４５２０から開始する。ステップ４５２０において、中央コントローラ４２３０は、無呼吸／呼吸低下の存在の測定を第１の閾値と比較し、無呼吸／呼吸低下の存在の測定が事前決定された期間にわたって第１の閾値を超えている（これは、無呼吸／呼吸低下の発生を示す）かを決定する。方法４５００は、ステップ４５４０へ進み、そうでない場合、方法４５００は、ステップ４５３０に進む。ステップ４５４０において、中央コントローラ４２３０は、気道開通性の測定を第２の閾値と比較する。気道開通性の測定が第２の閾値を超える場合、気道が開存していることを示し、検出された無呼吸／呼吸低下が中枢性であるとみなされ、方法４５００はステップ４５６０に進む。気道開存性の測定が第２の閾値を超えない場合、無呼吸／呼吸低下は閉塞性であるとみなされ、方法４５００は、ステップ４５５０へ進む。

ステップ４５３０において、中央コントローラ４２３０は、流れ制限の測定を第３の閾値と比較する。流れ制限の測定が第３の閾値を超える場合、吸気流が制限されていることを示す。その場合、方法４５００は、ステップ４５５０へ進む。流れ制限の測定が第３の閾値を超えない場合、方法４５００は、ステップ４５６０に進む。

ステップ４５５０において、得られた治療圧力Ｐｔが最大治療圧力Ｐｍａｘを超えない場合、中央コントローラ４２３０は、ベース圧力Ｐ_０を事前決定された圧力インクリメントΔＰだけ増加させる。一実行において、事前決定された圧力インクリメントΔＰおよび最大治療圧力Ｐｍａｘは、それぞれ１ｃｍＨ_２Ｏおよび２５ｃｍＨ_２Ｏである。他の実行において、圧力インクリメントΔＰは、０．１ｃｍＨ_２Ｏまで低くかつ３ｃｍＨ_２Ｏまで高くすることができるか、または、０．５ｃｍＨ_２Ｏまで低くかつ２ｃｍＨ_２Ｏまで高くすることができる。他の実行において、最大治療圧力Ｐｍａｘは、１５ｃｍＨ_２Ｏまで低くかつ３５ｃｍＨ_２Ｏまで高くすることができるか、または、２０ｃｍＨ_２Ｏまで低くかつ３０ｃｍＨ_２Ｏまで高くすることができる。次に、方法４５００は、ステップ４５２０に戻る。

ステップ４５６０において、低下したベース圧力Ｐ_０が最低治療圧力Ｐｍｉｎを下回っていない場合、中央コントローラ４２３０は、ベース圧力Ｐ_０をデクリメントだけ低下させる。次に、方法４５００は、ステップ４５２０に戻る。一実行において、デクリメントはＰ_０－Ｐｍｉｎの値に比例するため、検出されたイベントが無い場合、Ｐ_０の最低治療圧力Ｐｍｉｎへの低下は、指数関数的になる。一実行において、比例関係の定数は、Ｐ_０の指数関数的低下の時定数τが６０分でありかつ最低治療圧力Ｐｍｉｎが４ｃｍＨ_２Ｏとなるように、設定される。他の実行において、時定数τは、１分まで短くかつ３００分まで長くすることができるか、または、５分まで短くしかつ１８０分まで長くすることができる。他の実行において、最低治療圧力Ｐｍｉｎは、０ｃｍＨ_２Ｏまで低くすることができかつ８ｃｍＨ_２Ｏまで高くすることができるか、または、２ｃｍＨ_２Ｏまで低くすることができかつ６ｃｍＨ_２Ｏまで高くすることができる。あるいは、検出されたイベントが無い場合にＰ_０の最低治療圧力Ｐｍｉｎまでの低下が線状になるように、Ｐ_０のデクリメントを事前決定してもよい。

５．８．２ バイレベル治療
本技術のこの形態の他の実行において、方程式（１）中の振幅Ａの値は正であり得る。このような実行は、バイレベル治療として公知である。なぜならば、治療圧力Ｐｔを正の振幅Ａの方程式（１）を用いて決定する場合、治療パラメータ決定アルゴリズム４３２９は、患者１０００の自発呼吸努力と同期して治療圧力Ｐｔを２つの値またはレベル間で振動させるからである。すなわち、上記した典型的な波形テンプレートΠ（Φ，ｔ）に基づいて、治療パラメータ決定アルゴリズム４３２９は、吸気の開始時または吸気の最中に治療圧力ＰｔをＰ_０＋Ａ（ＩＰＡＰとして公知）まで増加させ、呼気開始時または呼気の最中に治療圧力Ｐｔをベース圧力Ｐ_０（ＥＰＡＰとして公知）まで低下させる。

バイレベル治療のいくつかの形態において、ＩＰＡＰは、ＣＰＡＰ治療モードにおける治療圧力と同じ目的の治療圧力であり、ＥＰＡＰは、ＩＰＡＰから振幅Ａを減算した値であり、呼気圧力解放（ＥＰＲ）とも呼ばれる「小さな」値（数ｃｍＨ_２Ｏ）を有する。このような形態は、ＥＰＲを用いたＣＰＡＰ治療とも呼ばれ、直接的なＣＰＡＰ治療よりも快適であると一般的に思われている。ＥＰＲを用いたＣＰＡＰ治療の場合、ＩＰＡＰおよびＥＰＡＰのうちいずれかまたは双方は、一定の値であり得、ハードコードされるかまたはＲＰＴデバイス４０００へ手動入力される。あるいは、治療パラメータ決定アルゴリズム４３２９は、ＥＰＲを用いたＣＰＡＰ時において、ＩＰＡＰおよび／またはＥＰＡＰを繰り返して計算し得る。この代替例において、治療パラメータ決定アルゴリズム４３２９は、治療エンジンモジュール４３２０中の各アルゴリズムから返送された睡眠呼吸障害の指標または測定の関数としてＥＰＡＰおよび／またはＩＰＡＰを繰り返して計算する。これは、上記したＡＰＡＰ治療におけるベース圧力Ｐ_０の計算と同様に行われる。

バイレベル治療の他の形態において、振幅Ａは、ＲＰＴデバイス４０００が患者１０００の呼吸機能の一部または全てを行えるくらいに十分に大きい。圧力補助換気治療として知られるこのような形態において、振幅Ａは、圧力補助またはスイングと呼ばれる。圧力補助換気治療において、ＩＰＡＰは、ベース圧力Ｐ_０＋圧力補助Ａであり、ＥＰＡＰはベース圧力Ｐ_０である。

一定圧力補助換気治療として知られる圧力補助換気治療のいくつかの形態において、圧力補助Ａは、所定の値において固定される（例えば、１０ｃｍＨ_２Ｏ）。この所定の圧力補助値は、ＲＰＴデバイス４０００の設定であり、例えばＲＰＴデバイス４０００の構成時においてハードコーディングによって設定してもよいし、入力デバイス４２２０を通じた手動入力によって設定してもよい。

サーボ換気として広範に知られる圧力補助換気治療の他の形態において、治療パラメータ決定アルゴリズム４３２９は、呼吸サイクル（例えば、換気の現在測定Ｖｅｎｔ）の一定の現在測定されているまたは推定されているパラメータと、当該呼吸パラメータの目標値（例えば、換気の目標値Ｖｔｇｔ）とを入力としてとり、式（１）のパラメータを繰り返して調節して、呼吸パラメータの現在の測定を目標値に接近させる。ＣＳＲ治療に用いられる適応型サーボ換気（ＡＳＶ）として公知のサーボ－換気の形態において、呼吸パラメータは換気であり、目標換気値Ｖｔｇｔは、上記したように典型的な最近の換気Ｖｔｙｐから目標換気決定アルゴリズム４３２８によって計算される。

サーボ換気のいくつかの形態において、治療パラメータ決定アルゴリズム４３２９は、呼吸パラメータの現在の測定を目標値へと達するように、圧力補助Ａを繰り返し計算する制御方法を適用する。１つのこのような制御方法として、比例積分（ＰＩ）制御がある。目標換気Ｖｔｇｔが典型的な最近の換気Ｖｔｙｐよりも若干低くなるように設定されたＡＳＶモードに適したＰＩ制御の一実行において、圧力補助Ａは、以下のように繰り返して計算される：
式中、Ｇは、ＰＩ制御の利得である。利得Ｇの値が大きいほど、治療エンジンモジュール４３２０におけるフィードバックが正になり得る。利得Ｇの値が小さいほど、残っている未処理のＣＳＲまたは中枢性睡眠時無呼吸が可能になり得る。いくつかの実行において、利得Ｇは、所定の値において固定される（例えば、－０．４ｃｍＨ_２Ｏ／（Ｌ／分）／秒）。あるいは、利得Ｇは、ＣＳＲを実質的に除いた値に到達するまで、治療セッション間において変更され得る（最初は低い値から開始し、セッション間において増加させる）。治療セッション時のＣＳＲの重篤度の評価のために治療セッションのパラメータ遡及的分析を行う従来の手段が、このような実行において用いられ得る。他の実行において、利得Ｇは、換気の現在の測定Ｖｅｎｔと目標換気Ｖｔｇｔとの間の差に応じて変化し得る。

治療パラメータ決定アルゴリズム４３２９によって適用され得る他のサーボ換気制御方法を挙げると、比例（Ｐ）、比例微分（ＰＤ）および比例積分－微分（ＰＩＤ）がある。

方程式（２）を介して計算された圧力補助Ａの値は、［Ａｍｉｎ、Ａｍａｘ］として規定された範囲までクリップされ得る。この実行において、圧力補助Ａは、（Ａが増加し始めるポイントである）現在の換気Ｖｅｎｔの測定が目標換気Ｖｔｇｔを下回るまで、デフォルトで最小圧力補助Ａｍｉｎになるため、Ｖｅｎｔが再度Ｖｔｇｔを超えたときは、Ａｍｉｎまで下降するだけである。

圧力補助制限ＡｍｉｎおよびＡｍａｘは、ＲＰＴデバイス４０００の設定であり、例えばＲＰＴデバイス４０００の構成時においてハードコーディングによって設定してもよいし、あるいは入力デバイス４２２０を通じて手動入力によって設定してもよい。

圧力補助換気治療モードにおいて、ＥＰＡＰは、ベース圧力Ｐ_０である。ＣＰＡＰ治療におけるベース圧力Ｐ_０と同様に、ＥＰＡＰは一定の値であり得、タイトレーション時に処方または決定される。このような一定のＥＰＡＰは、例えばＲＰＴデバイス４０００の構成時においてハードコーディングによって設定してもよいし、あるいは入力デバイス４２２０を通じて手動入力によって設定してもよい。この代替法は、固定ＥＰＡＰ圧力補助換気治療とも呼ばれる。所与の患者についてのＥＰＡＰのタイトレーションは、閉塞性無呼吸を予防する目的のために、ＰＳＧを用いたタイトレーションセッション時に臨床医によって行われ得、これにより、一定ＣＰＡＰ治療におけるベース圧力Ｐ_０のタイトレーションと同様の様態で、圧力補助換気治療のために気道確保が維持される。

あるいは、治療パラメータ決定アルゴリズム４３２９は、圧力補助換気治療時のベース圧力Ｐ_０を繰り返して計算し得る。このような実行において、治療パラメータ決定アルゴリズム４３２９は、治療エンジンモジュール４３２０中の各アルゴリズムから返送された睡眠呼吸障害の指標または測定（例えば、流れ制限、無呼吸、呼吸低下、開通性およびいびきのうち１つ以上）の関数としてＥＰＡＰを繰り返して計算する。ＥＰＡＰの連続的計算は、ＥＰＡＰのタイトレーション時における臨床医によるＥＰＡＰの手動調節に類似するため、このプロセスは、ＥＰＡＰの自動タイトレーションとも呼ばれ、治療モードは、自動タイトレーションＥＰＡＰ圧力補助換気治療または自動ＥＰＡＰ圧力補助換気治療として知られる。

５．９ データ管理システム
図７は、特定の例に従って患者デバイス１０２（１０２Ａ、１０２Ｂ、１０２Ｃ）と通信することおよび患者デバイス１０２（１０２Ａ、１０２Ｂ、１０２Ｃ）へ更新を提供することを行うために用いられる例示的機械管理サービスシステム１０６を示す。図８に示す信号図は、例示的患者デバイスと、図７の例示的機械管理サービスシステムとの間の通信を示す。少なくとも図７～図１０Ｃに示す例は、本明細書中に記載される特徴の範囲または有用性の開示を制限するものとしてみなされるべきではないことが理解される。

図７に戻って、患者デバイス１０２は、機械管理サービス（ＭＭＳ）システム１０６との通信をネットワーク１０４を介して行う。ＭＭＳシステム１０６は、１つ以上のコンピューティングデバイス（例えば、図１１に関連して述べるもの）を含み得る。特定の例において、ＭＭＳシステム１０６によって提供される特定の機能は、（例えば、ＡｍａｚｏｎＡＷＳ、Ｍｉｃｒｏｓｏｆｔ Ａｚｕｒｅなどを介して）クラウドベースのコンピューティングアーキテクチャ上に設けられ得る。

図７中に示す３つの異なる患者デバイス１０２（１０２Ａ、１０２Ｂおよび１０２Ｃ）がＭＭＳシステム１０６と通信しているが、任意の数の患者デバイスが設けられ得、ＭＭＳシステムと通信され得ることも理解されるべきである。換言すると、ＭＭＳシステム１０６は、世界中の患者によって用いられる患者デバイスの１つ以上のフリート（それぞれが複数の個々の患者デバイスを含む）と通信するように構成され得る。

患者デバイスは、異なる種類の患者デバイスを含み得る。例えば、患者デバイスは、ＲＰＴ４０００、加湿器５０００または患者インターフェース３０００であり得る。特定の例において、患者デバイスは、個々の患者デバイスの一部である構成要素を含み得る。例えば、ＲＰＴデバイスである患者デバイスは、ネットワーク１０４を介したＭＭＳシステム１０６との通信に用いられるセルラーモデムを含み得る。患者デバイスの構成要素は、デバイスの異なるハードウェア構成要素および／またはソフトウェア構成要素を含み得る。例えば、Ｂｌｕｅｔｏｏｔｈソフトウェアドライバが１つの構成要素とされ得、別の構成要素が、ＡｕｔｏＳｅｔのための流れ生成器の機能様態を制御するアプリケーションとされ得る。別の構成要素は、流れ生成器の制御に用いられるＳｏＣに対するＢＩＯＳとされ得る。特定の例において、ソフトウェア、ファームウェアを動作させるかまたは他の様態でプログラム可能である任意の種類のデバイスまたは構成要素が、本明細書中に記載の技術による患者デバイスとしてみなされ得る。換言すると、患者デバイスの構成要素そのものを、本明細書中に記載の技術による「患者デバイス」とみなすことができる。

一般的に、個々の患者デバイス１０２は、図１１および／または図４Ｃに関連して記載される構成要素のうちいずれかを含み得る。例えば、流れ生成器は、１つ以上のプロセッサ１１０２と、１つ以上のメモリデバイス１１０４と、１つ以上のネットワークインターフェースデバイス１１０６とを含み得る。ネットワークインターフェースデバイスのうち１つは、例えばＢｌｕｅｔｏｏｔｈトランシーバであり得る。特定の例において、所与の患者デバイスは、別のコンピューティングデバイス（例えば、携帯電話またはパーソナルコンピュータ）と通信し得る。次に、この別のコンピューティングデバイスは、患者デバイスからＭＭＳシステム１０６へ提供される通信またはメッセージリレーし得る。構成要素は、所与の構成要素の使用を可能にするファームウェア、ソフトウェアなどと関連付けられえるかまたはそのようなファームウェア、ソフトウェアなどを有し得る。

本文書中の多数の箇所（例を非限定的に挙げると、図７）において、ソフトウェアモジュール（など）と、ソフトウェアモジュール（など）によって行われるアクションについて記載がある。これは、説明を容易にするためのものであり、本文書中においてソフトウェアモジュールが任意のアクションを行うという記載が有る場合、ソフトウェアモジュールを含む指示項目に従って当該アクションを実際に行うのは、常に（ソフトウェアモジュールの下側にある）ハードウェア要素（例えば、プロセッサおよびメモリデバイス）であることが理解されるべきである。これに関するさらなる詳細は、図１１の記載などにおいて以下に記載される。

本明細書中記載のように、患者デバイス１０２は、１つ以上の識別データピースを通信し得る。これを図８中の２００に示す。識別データを挙げると、例えばバージョン番号、領域識別子または名前、構成要素種別（例えば、当該バージョンが適用される構成要素）または他の識別子がある。特定の例において、患者デバイスから送信される識別データは、患者デバイスを使用している患者（単数または複数）にとってアグノスティックであるデータであり得る。換言すると、送信される識別データは、患者識別データを排除し得る。この種の実行は、アップグレードパッケージを個々の患者デバイスのために展開させるために患者データを取得する必要またはＭＭＳシステム１０６へ送信する必要が無いため、特定の例において有利であり得る。

特定の例において、送信され得る識別データは、患者デバイス１０２と共に含まれるトランシーバと関連付けられた一意の識別子を含む。例えば、セルラートランシーバ／モジュールと関連付けられたセルラー識別子が、患者デバイス１０２と共に含まれる。特定の例において、識別子は、所与の患者デバイス１０２を一意に識別し得る。他の特定の例において、識別データは、患者の識別子を含み得る。特定の例において、各患者デバイス１０２から送信されるデバイス識別データは一意の（例えば、ＧＵＩＤ／ＵＵＩＤ）であるため、（例えば、ステータスＤＢ１１２の調査により）患者デバイスと共に含まれる他の構成要素またはデバイスの詳細を（ＭＭＳ１０６によって）決定するために用いることが可能である。

任意のイベントにおいて、ＭＭＳシステム１０６は、各患者デバイス１０２からメッセージを受信し、メッセージを各患者デバイス１０２へ送達する。ＭＭＳシステム１０６に含まれ得る規則マネージャモジュール１０８は、対応する患者デバイスから送信された情報に基づいて、アップグレードパッケージを対応する患者デバイス（または関連付けられたコンピューティングデバイス）へ送達するべきかを決定するように構成される。以下にさらに詳細に説明するように、特定の例において、アップグレードパッケージを送達するべきかについての決定は、ステータスＤＢ１１２中の保存されたデータにさらに基づき得る。

ＭＭＳシステム１０６は、規則データベース１１０を含み得る。規則データベース１１０において、規則マネージャモジュール１０８、ステータスデータベース１１２、未決定のリクエストデータベース１１４、およびアップグレードパッケージ１１６によって用いられる規則が保存される。本明細書中で用いられるように、「データベース」という用語は、コンピュータシステムについてのデータの任意の組織的集合を含み、例えば関係データベース、ＸＭＬまたはＪＳＯＮ（または他のファイル種別）ファイルなどを含み得る。

特定の例示的実施形態において、ＭＭＳシステム１０６により、アップグレードリクエストをステートレスな様態で処理することが可能になるため、ＭＭＳシステム１０６が各個々の患者デバイス１０２による個々のアップグレードリクエスト（例えば、ジョブ）の処理が正確かを追跡する必要が無くなる。この種の実行により、他の種類のステートフル実行（例えば、ジョブに基づいたシステム）に比して恩恵が得られ得る。

所与の患者デバイス１０２へ適用および／または送達されるアップグレードパッケージの詳細を決定する処理が、規則マネージャモジュール１０８により行われる。このプロセスについて、図８および図９Ｂに関連してより詳細に説明するが、このプロセスの例を挙げると、例えば、（例えば、２００において患者デバイス１０２Ｂから送信される）デバイス識別データを用いて当該デバイス（例えば、更新可能なデータフィールド、ソフトウェアおよび／またはファームウェアを有するもの）の多様な構成要素を決定し、適用可能な更新を有し得る構成要素を決定した後、これらの更新を（患者デバイスへの更新および／またはインストールのために）送達する（またはそのような更新の存在を患者デバイスへ通知する）。このようなプロセスは、２０１においてデバイスプロファイル情報をステータスデータベース１１２から入手することと、２０２において当該データを１つ以上の規則に照らしてチェックして、（２０４において）患者デバイス１０２へ２０６において送達されるべきアップグレードパッケージを決定することとを含み得る。

各規則は、規則データベース１１０中の別個の入力または記録であり得、各規則は、ファームウェア／ソフトウェア／設定または上記全てについての１つ以上のアップグレードを含むアップグレードパッケージに対応し得る。各規則は、所与の規則をトリガする際に用いられる患者デバイスの構成要素のバージョンまたは他のデータを表示または規定し得る。各規則は、対応する規則がトリガされた際に患者デバイスへ適用または通信されるべきタスクまたはアップグレードファイルも含み得る。規則データベース１１０中に保存され得る規則の例を、以下の表１～４に関連して示す。

本明細書中で用いられるように、「アップグレード」という用語は、デバイスのデータ、ソフトウェアまたはファームウェアに変更が発生する状況を網羅することを意図していることが理解される。よって、いくつかの場合において、「アップグレード」という用語において、（例えばセキュリティ上の欠陥に起因して）例えば前回適用された更新をロールバックさせるダウングレードが含まれ得る。例えば、バージョン１０のアプリケーションからバージョン９への変更、再インストールまたはロールバックを行う「アップグレード」パッケージが送達され得る。

ＭＭＳシステム１０６は、各患者デバイスの構成要素について現在インストールされているバージョン／設定の記録を含むステータスデータベース１１２も含み得る。ステータスデータベース１１２中に含まれ得る例示的データは、以下の表２～表４および表８に示す「ＩｄｅｎｔｉｆｉｃａｔｉｏｎＰｒｏｆｉｌｅｓ」に類似し得、所与のデバイスそれぞれの多様な構成要素は、現在デバイスの構成要素において使用されているファームウェアまたはソフトウェア（または設定）バージョンのバージョンまたは他の識別子に関連して保存される。特定の例において、規則マネージャモジュール１０８は、提供された識別データによって指定された所与のデバイスの各構成要素のバージョニング情報の取得のために、ステータスデータベース１１２を用い得る。例えば、所与のデバイスからＭＭＳシステムへ通信される識別データは、ＧＵＩＤまたは他の一意の識別子であり得、所与のデバイスと共に含まれる構成要素全て（および関連付けられたバージョニング情報）をルックアップする際に用いられる。その後、このような情報は、所与の患者デバイス上にインストールされた構成要素について規則１１０のうちいずれかが適用可能であるかを（規則マネージャモジュール１０８を介して）決定する際に用いられ得る。ステータスデータベース１１２は、特性、特質または他の構成情報全てのためのデータ記憶部であり得る。このような情報をＭＭＳシステム１０６内に保存すると、（アップグレードが利用可能であるかを決定するために）患者デバイスがＭＭＳシステム１０６にチェックインする度に患者デバイスから当該情報を送信する必要無く情報の取り出しが可能になるため、有利であり得る。

しかし、特定の例において、個々の患者デバイスがＭＭＳシステム１０６にチェックインした際に、ステータスデータベース１１２中に保存されたデータの一部または全てを（例えば、都度）通信することができる。

特定の例示的実施形態において、各個々の患者デバイスの製造時において、ステータスデータベース１１２は構成要素情報についてポピュレートされる。製造時において、デバイス（またはその構成要素）に対し、一意の識別子が割り当てられ得る。このとき、一意の識別子は、デバイスと共に含まれる多様な構成要素についての構成要素データに関連して保存され得る。特定の例において、販売業者または他のサードパーティからも、個々のデバイスのバージョニングおよび構成要素情報についてのデータが提供され得る。特定の例において、ステータスデータベース１１２は、各一意の患者デバイス識別子に関連して同様に保存される組織および／または領域識別子を含み得る。このような情報は、特定の組織および／または世界中の特定の領域（例えば、中国内の患者デバイス用のアップグレードパッケージ）向けのアップグレードパッケージを標的化するために有利に用いられ得る。

未決定のリクエスト１１４は、現在未決定のリクエスト全てのリスト／キュー（または他のデータ構造）を含み得る。特定の例において、未決定のリクエストは、未決定でありかつ未だ個々の患者デバイスへ通信させる必要がある、（例えば、何らかの特定のアクション（例えば、ファームウェアまたはソフトウェアのアップグレードの適用または設定変更）をデバイスにとってもらいたい旨の）リクエストの集合である。特定の例において、本明細書中記載のように、患者デバイスがチェックインし、デバイス識別データを供給すると、当該データを用いて、当該デバイスについて未決定のリクエストが存在するかをルックアップすることが可能になる。

ＭＭＳシステム１０６は、所与の患者デバイスと通信し、特定のリクエストを取り扱うよう当該デバイスに命令する。リクエストは、（例えば、ファイルのダウンロードおよびインストールのために）特定のアップグレードパッケージを適用することであり得る。特定の例において、リクエストが患者デバイスへ通信され、未決定のリクエスト１１４へ付加された後は、ＭＭＳシステム１０６は、その特定のリクエストの完了成功を追跡しなくなる。これにより、リクエストがＭＭＳシステム１０６によってどのように取り扱われたかがステートレスシステムへ提供され得る。他の特定の例において、患者デバイスへ通信された未決定のリクエストの記録は、未決定のリクエスト１１４内に維持され、通知または患者デバイスから提供される他の情報に基づいて、「進捗中」または「完了成功」などとマーク付けされる。この後者の実行により、（例えば、リクエストの状態の追跡により）リクエストがＭＭＳシステム１０６によって取り扱われる様態におけるステートフルシステムが得られ得る。特定の例において（および上記実行双方に適用可能な例において）、ＭＭＳシステム１０６は、何らかの情報ステータスおよび／または患者デバイスから報告されるような障害状態（単数または複数）を追跡し得、当該情報を未決定のリクエスト１１４中に保存し得る。未決定のリクエスト１１４は、（例えば、図１０Ａ～図１０Ｃ中のキュー４０４として）キューまたは他のデータ構造中へ保存され得る。特定の例において、未決定のリクエスト１１４は、データベースなどに保存され得る。

アップグレードパッケージ１１６は、患者デバイスのうちいずれかに適用され得るアップグレードパッケージ全てのためのデータ記憶部であり得る。アップグレードパッケージは、ソフトウェアまたはファームウェアに対するコード変更および／または所与の患者デバイスの１つ以上のパラメータの調節のための設定変更を含み得る。次に、このようなパラメータ、ソフトウェアおよび／またはファームウェアの変更は、患者デバイスの動作様態に影響を付与し得るかまたは患者デバイスの動作様態を変更し得る。例えば、ＲＰＴデバイスの流れ生成器のファンまたは送風機の動作が、患者への治療提供をより有効にするように調節され得る。本明細書中のいずれかの箇所に記載のように、特定の例において、患者デバイスの設定を調節するためには、臨床医または他の医療専門家からのさらなる権限付与が必要になり得る。そのため、特定の例において、規則マネージャモジュールは、そのようなさらなる入力に基づいて、アップグレード（例えば、設定変更）を適用すべきかを決定し得る。特定の例において、アップグレードパッケージは、以下のうちいずれかまたは全てを含み得る：セキュリティ向上、さらなる機能（例えば、ＲＰＴデバイス上において新たに利用可能となった新規治療モード）、異なる言語（例えば、ＲＰＴデバイス中に埋設された言語ストリングの更新のための異なる音声および／またはテキストを含む異なる言語パック）、患者調査または質問表、患者へのコーチングまたはヒント付与、あるいは他の設定、構成またはアプリケーション。

特定の例示的実施形態において、アップグレードパッケージ１１６は、患者デバイスによる各アップグレードファイル／データの取得が可能なネットワークまたはウェブサイトアドレスのリストを保存する。よって、ＭＭＳシステム１０６は、リンクを（アップグレードファイルそのものへではなく）アップグレードファイルが発見され得る場所へ提供するように、構成され得る。特定の例において、実際のインストール用ファイルは、ＭＭＳシステム１０６と別個に保存され得る。

以下の表１～表４は、規則データベース１１０に関連して見受けられ得るアップグレード仕様の例を示す。表１は、アップグレードパッケージのトリガのために識別プロファイルを用いる複数の異なる規則に関連して構築されるアップグレード仕様の様態を示す。各規則に含まれる識別プロファイルは、ステータスデータベース１１２中の各患者デバイスについて保存されたデバイスプロファイルデータのサブセットであり得る。異なる規則（アップグレード仕様のセグメントとも呼ばれる）およびこれらの規則をトリガする際に用いられる識別プロファイルと、各識別プロファイルに関連して提供されるべきアップグレードパッケージとを、表２、表３および表４に関連して示す。各トリガ（例えば、事前条件）は、ＭＭＳシステム１０６が規則（セグメント）を参照および／または追跡することを可能にするための一意の識別子と関連付けられ得る。これにより、デバイスのフリートにわたって所与のアップグレードが提供された回数を決定することが可能になり得る。

表２において、流れ生成器構成要素のデバイス識別データに以下のバージョン値が含まれる場合、ＦＧ ＡｕｔｏＳｅｔＡｐｐｌｉｃａｔｉｏｎのバージョン４．０．１から４．０．３へのアップグレードがトリガされる：１）“’ＢｏｏｔｌｏａｄｅｒＩｄｅｎｔｉｆｉｅｒ’：‘ＳＷ０３９０１．００．３．０．０．４８２５５’”；２）“’ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒ’：‘ＳＷ０３９００．０１．４．０．１．５０５７８’、および３）“’ＣｏｎｆｉｇｕｒａｔｉｏｎＩｄｅｎｔｉｆｉｅｒ’：‘ＣＦ０３９００．０１．０３．００．５０５７８’。この事前条件が満たされる場合、規則マネージャモジュール１０８は、表示された「ＵｐｇｒａｄｅＦｉｌｅ」を当該患者デバイスの構成要素に適用すべきかを決定する。患者デバイスに通知が送られ、表示されたアップグレードファイルが、患者デバイスから適用される。特定の例において、「ＰｏｓｔＣｏｎｄｉｔｉｏｎ」が満たされた後、ステータスＤＢ１１２は、対応するデバイスが更新された旨を反映して（例えば、４．０．３へ）更新され得る。特定の例において、規則の事後条件部分は無視され得る。

表３において、デバイス識別データ流れ生成器構成要素が以下の値を含む場合、ＦＧ ＡｕｔｏＳｅｔＡｐｐｌｉｃａｔｉｏｎのバージョン４．０．２から４．０．３へのアップグレードがトリガされる：１）“’ＢｏｏｔｌｏａｄｅｒＩｄｅｎｔｉｆｉｅｒ’：‘ＳＷ０３９０１．００．３．０．０．４８２５５”；２）“’ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒ’：‘ＳＷ０３９００．０１．４．０．２．５０８１３、および３）“’ＣｏｎｆｉｇｕｒａｔｉｏｎＩｄｅｎｔｉｆｉｅｒ’：‘ＣＦ０３９００．０１．０３．００．５０８１３’。この事前条件が満たされる場合、規則マネージャモジュール１０８は、表示された「ＵｐｇｒａｄｅＦｉｌｅ」を当該患者デバイスの構成要素に適用すべきかを決定する。患者デバイスには通知が送られ、表示されたアップグレードファイルが適用される。特定の例において、「ＰｏｓｔＣｏｎｄｉｔｉｏｎ」値が満たされた後、ステータスＤＢ１１２は、対応するデバイスが（例えば、４．０．３に）が更新された旨を反映するように更新される。表２および表３は、同一構成要素の同一バージョンに対するアップグレードパッケージを示すことが理解されるべきである。しかし、事前条件が異なるため、バージョンが異なる構成要素を有する患者デバイスについてアップグレードをトリガするために、２つの異なる識別プロファイルが用いられ得る。

表４において、ＢｌｕｅｔｏｏｔｈｉＯＳアップグレードがトリガされるのは、デバイス識別データ流れ生成器構成要素に以下の値が含まれる場合である：１）“’ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒ’：‘ＳＷ０３９００．０１．４．０．３．５０９２７’”およびＢｌｕｅｔｏｏｔｈモジュール構成要素のデバイス識別データが以下の値を含む場合：１）“’ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒ’：‘ＳＴ２６６．１．１．２．１８２．２’”。よって、事前条件は、システムの複数の構成要素に関するバージョニングデータを含み得る。この事前条件が満たされる場合、規則マネージャモジュール１０８は、表示された「ＵｐｇｒａｄｅＦｉｌｅ」を当該患者デバイスの構成要素に適用すべきかを決定する。患者デバイスには通知が送られ、表示されたアップグレードファイルが適用される。特定の例において、「ＰｏｓｔＣｏｎｄｉｔｉｏｎ」値が満たされた後、ステータスＤＢ１１２が、対応するデバイスが（例えばＳＴ２６６．１．１．３．１９９．２に）更新された旨を反映するように更新され得る。

適切な規則および当該規則の対応するアップグレードパッケージが、提供されたデバイス識別データ（および／またはステータスＤＢ１１２から取り出されたデバイスプロファイルデータ）に基づいて決定された後、２０６において患者デバイス１０２に対してアップグレードパッケージが通知され得る。特定の例において、これは、ＭＭＳシステム１０６から送達されたメッセージ内のアップグレードに適用されるべきデータを提供することを含み得る。他の例において、アップグレードパッケージの送達は、ＵＲＩまたは他のアドレスの仕様を（他のデータ（例えば、情報、サイズ、ファイル名）と共に）含み得るため、表示されたＵＲＩの使用により１つ以上のファイルをその後にダウンロードすることが可能になる。

２０８において、患者デバイスは、アップグレードパッケージを適用する。これは、アップグレードパッケージが完全であるか、正確であるかまたは他の場合に破損していないことを検証（例えば、チェックサム実行）することと、既存の設定に上書きすることならびに／あるいはソフトウェア更新および／またはファームウェア更新をインストールすることとを含み得る。

アップグレードが患者デバイスによってインストールされた後、患者デバイス１０２は、ＭＭＳシステム１０６に再度チェックインし得、更新された構成要素の新規バージョン情報をＭＭＳシステム１０６へ通信させ得る。その後、更新されたバージョン情報は、当該患者デバイスおよび所与の構成要素に関連して（例えば、前回の値への上書きにより）ステータスＤＢ１１２内に保存され得る。よって、ＭＭＳシステム１０６は、所与の患者デバイス上に現在インストールされているファームウェア／ソフトウェア／設定バージョンについて最新状態に保持される。この種の実行により、個々のアップグレードリクエストの連続的追跡の必要無くシステムが有利に実行されることが可能になり得る。特定の例において、患者デバイス１０２によってアップグレードの完了時において、患者デバイス１０２は、ＭＭＳシステム１０６に対して再度ステータス更新を通信し得る。その後、このメッセージに含まれ得るデバイス識別データおよび／または構成要素識別データ（例えば、ソフトウェアバージョンまたはファームウェアバージョン）がＭＭＳシステム１０６によって用いられて、更新が患者デバイス１０２によって実行／インストールされているかを検証し得る。特定の例において、患者デバイス１０２は、ＭＭＳシステム１０６に対し、（患者デバイス１０２によるリクエストの完了成功を妨げる）障害が発生したかについてプグレードプロセスにおける自身の進捗を再度通信し得る。この進捗情報または障害情報は、ＭＭＳシステム１０６によって未決定のリクエスト１１４中に保存され得る。進捗情報は、例えばファイルのダウンロードが成功した旨、アップグレードが適用中である旨、アップグレードが進捗中である旨、アップグレードが完了しており患者デバイスが再起動中である旨などを含み得る。

規則仕様全体に含まれ得る個々の規則の生成が可能になることにより、数千人または数百万人の異なる患者デバイスにわたるスケーリングが可能な更新の管理のための自動化システムを得ることができることが理解される。これが実現される理由として、個々の患者デバイスからの通信により、規則マネージャモジュール１０８が（ステータスＤＢ１１２から取得されたデバイスプロファイルデータおよび規則１１０からの規則仕様に基づいて）個々の患者デバイスへ送信されるべき正しいアップグレードパッケージを適切に選択することが促進される点がある。そのため、デバイスへのインストール／適用が可能な新規アップグレードパッケージが利用可能となった際に患者デバイスの更新を手動監視する必要がそれほど無くなり得る。

図９Ａおよび図９Ｂは、特定の例において例えば患者デバイス１０２およびＭＭＳシステム１０６それぞれによって実行され得るコンピュータ動作のフローチャートである。図９Ａは、例示的患者デバイス１０２に行われ得る例示的なクライアント側の処理を示し、図９Ｂは、ＭＭＳシステム１０６の１つ以上のプロセッサによって行われ得る例示的なサーバー側の処理を示す。

図９Ａにおいて、３００において、患者デバイスは、チェックインプロセスを行うべきかを決定する。このチェックは、例えば毎日、毎週、毎月行われ得る。特定の例において、時計４２３２が、チェックインプロセスを実行すべき時間を決定するために用いられ得る。チェックインの時間ではない場合、プロセスは、３００に戻る。

３０２において、チェックインプロセスを行うべきである場合、患者デバイス１０２は、デバイス識別データを別のコンピュータシステム（例えば、ＭＭＳシステム１０６）へ送信する。本明細書中記載のように、デバイス識別データは、（例えば、他の患者デバイス間において一意となるように）患者デバイスのＧＵＩＤであり得るかまたは患者デバイスのと関連付けられ得る。特定の例示的実施形態において、ＧＵＩＤは、患者デバイス１０２によって用いられるネットワークインターフェースへ割り当てられる。特定の別の例において、送信されたデータは、ソフトウェア／ファームウェア／設定バージョン情報の送信を含み得る。「ＧＵＩＤ」という用語は、他の識別子も（一意であるかに関わらず）患者デバイスまたはその構成要素の識別の促進のために用いられ得る本明細書中の患者デバイスまたはその構成要素に関連して用いられることが理解される。

３０４において、デバイス識別データの送信後、患者デバイス１０２は、アップグレードデータパッケージをＭＭＳシステム１０６から受信する。特定の例示的実施形態において、アップグレードデータパッケージは、アップグレードのためのファイル（単数または複数）をダウンロード先としてリンク、ＵＲＩまたは他の位置を含み得る。よって、３０４においてアップグレードデータパッケージ内においてこのような情報が受信されると、患者デバイスは、表示された位置（例えば、リモートコンピュータシステム）へリクエストを提出し得、アップグレードデータパッケージによって指定されたファイルを取り出し得る。このようなファイルが受信されると、プロセスは、ステップ３０６に進み得る。

特定の例示的実施形態において、アップグレードデータパッケージは、設定用のデータまたは患者デバイス上において変更すべき他のパラメータを含み得る（かまたはそのようなものであり得る）。表５は、ステップ３０４を介して患者デバイスへ送達されるアップグレードデータパッケージの一部として含まれ得る「ＢｒｏｋｅｒＩｔｅｍ」要素の例を示す。

よって、患者デバイス１０２がアップグレードデータパッケージ中に含まれるこのブローカーアイテムを受信すると、このブローカーアイテムは、患者デバイスの構成プロファイルへ適用され得る。

特定の例示的実施形態において、アップグレードデータパッケージのコンテンツは、患者デバイス１０２へ適用されるべきソフトウェアまたはファームウェアも含み得る。よって、アップグレードデータパッケージをＭＭＳシステム１０６から受信した後にソフトウェアファイルまたはファームウェアファイル（例えば、表９に示すようなもの）を別個にリクエストする代わりに、このようなファイルが、アップグレードデータパッケージと関連して設けられ得る。

３０６において、受信されたアップグレードデータパッケージは、患者デバイスによって検証される。これは、ＭＭＳシステム１０６から送信されたメッセージを検証することおよび／または別個に取り出されたアップグレードファイルを検証することを含み得る。これは、受信されたデータまたは他のファイルをハッシュすることと、アップグレードデータパッケージメッセージ中に含まれたハッシュ値とこのハッシュとを比較することとを含み得る。特定の例において、この検証は、受信されることが予測されるファイルサイズ（例えば、ＭＭＳシステム１０６によって表示されたもの）と、取り出されたファイルの実際のファイルサイズとを比較することを含み得る。アップグレードファイルの検証が失敗した場合、患者デバイスは、ファイルのダウンロードにリトライし得る。特定の例において、患者デバイスは、ダウンロードまたはメッセージまたはファイル検証の障害についてＭＭＳシステムへ通知を送り得る。この障害は、将来の分析および／または報告のためにＭＭＳシステム１０６（または他のデバイス）によって記録され得る。

特定の例において、アップグレードファイルのダウンロード障害により、クライアント側の処理を（例えば、ＭＭＳシステム１０６への障害報告後に）終了し得、プロセスは、３００に戻り得、次のチェックイン時間が活性化されるまで待機し得る。チェックが再度行われると、患者デバイスに対し、前回アップグレードが失敗した同一のアップグレードデータパッケージが提供され得る。

３０８において、検証が成功した後、アップグレードデータパッケージは、患者デバイス１０２へ適用され得る。これの例を挙げると、例えば、患者デバイス１０２によって用いられる特定のパラメータ値を上書きまたは交換することならびに／あるいはソフトウェア更新および／またはファームウェアをインストールすることまたは他の様態でソフトウェア更新および／またはファームウェア更新を患者デバイスへ適用することがある。このインストール手順は、患者デバイスによって検証されてもよい（例えば、インストールが失敗したかまたは成功したか）。

３１０において、患者デバイスは、アップグレードのステータスを再度ＭＭＳシステム１０６へ送信する。特定の例示的実施形態において、これは、患者デバイス上にアップグレードされたばかりの構成要素の現在のバージョニング情報を報告することを含み得る。特定の例において、ステータス報告は、複数の異なる構成要素（例えば、流れ生成器およびＢｌｕｅｔｏｏｔｈモジュール）のためのものであり得る。特定の例において、ステータス報告は、全体的にアップグレードリクエストに関連し得る（例えば、リクエストが成功した旨）。表６は、ＭＭＳシステム１０６へ送信され得る例示的要素を示す。特定の例示的実施形態において、表６のコンテンツは、（例えば、リクエストが受信されたことまたはリクエストに関連して発生した任意の障害を検証するために）３０４においてアップグレードデータパッケージが受信されると、患者デバイスからＭＭＳシステム１０６へ送信され得る。

特定の例において、３１０において送信されるデバイスステータスは、アップグレード（および恐らくは障害エラーコードまたはメッセージ）の適用のための障害通知あるいはアップグレードされたばかりの構成要素（単数または複数）のバージョニング情報を含み得る。換言すると、特定の例において、アップグレードの成功は、現在のバージョニング情報をＭＭＳシステム１０６へ提供する患者デバイスから暗黙的に提供される。よって、ＭＭＳシステムは、患者デバイス１０２のステータスおよび／または患者デバイスへ供給されたアップグレードパッケージについて通知を受け得る。

図９Ｂは、ＭＭＳシステム１０６によって行われ得る例示的なサーバー側の処理を示す。

３５０において、デバイス識別データは、患者デバイスから受信される。本明細書中記載のように、デバイス識別データは、多様な異なる様態で提供され得る。下記の表７は、デバイス識別データがＭＭＳシステム１０６へ提出され得る様態の例を示す。

表７からの上記例において、リクエストの発行元である患者デバイスを一意に特定するＧＵＩＤ（ＵＲＩ中のｕｉｄ）は、患者デバイス（この場合は流れ生成器）とペアにされたセルラーＩＤである。このＩＤは、製造された各セルラーモジュールへ割りあてられているため、一意である。そのため、当該セルラーモジュールとペアにされた患者デバイスを位置に特定するために用いられ得る。これは、ＨＴＴＰｇｅｔ方法の一部としてＭＭＳシステム１０６へ提出される。

３５１において、ＭＭＳシステム１０６は、提供されたデバイス識別データを用いて、表示された患者デバイスのデバイスプロファイルデータ（例えば、構成要素全て）を（ステータスデータベース１１２の参照により）ルックアップする。表８は、デバイスプロファイルデータの一部がステータスＤＢ１１２内において配置され得る様態の例である。

ここで、ユニバーサル識別子は、患者デバイスから送信されたデバイス識別データである識別子であり得る。これは、全記録（例えば、当該ユニバーサル識別子と関連付けられたステータスＤＢ１１２内の全ての「ＩｄｅｎｔｉｆｉｃａｔｉｏｎＰｒｏｆｉｌｅｓ」）の発見のために用いられる。表８からの上記例は、流れ生成器構成要素を、「ハードウェア」バージョニング情報と、表示された識別子と関連付けられた患者デバイス上に存在する当該構成要素の現在のインストールされている「ソフトウェア」バージョンと共に示す。さらなる記録も、当該デバイスの異なる構成要素についてステータスＤＢ１１２内に設けられ得る。例えば、Ｂｌｕｅｔｏｏｔｈモジュール、セルラーモジュール、加湿器モジュールなどはそれぞれ、別個の入力を有し得る。これらの構成要素はそれぞれ、ユニバーサル識別子入力（“‘ＵｎｉｖｅｒｓａｌＩｄｅｎｔｉｆｉｅｒ’：‘６ａ７ａ２ｅ７ｅ－５ｄ９ｄ－４ｃ８７－ｂ４５ｅ－ｆａａ３５６３ｆ２１ａ８’”）とも関連付けられるため、所与の患者デバイスの全構成要素をルックアップすることが可能になる。特定の例において、ユニバーサル識別子は、デバイス内の全構成要素について同一である。特定の例において、ユニバーサル識別子は、同一患者デバイス内の（またはデバイス内のに連結された）いくつかの構成要素について異なる。

３５２において、次に、多様な構成要素の識別プロファイルからのバージョニング情報が（ＭＭＳシステム１０６上に保存された規則に照らして）規則マネージャモジュール１０８を介して処理されて、この患者デバイスの構成要素について利用可能なアップグレードパッケージが有るかを決定する。利用可能なアップグレードが無い場合、プロセスは終了し、ＭＭＳシステム１０６は、「無し」（または（今回利用可能なアップグレードは無い旨の）同様のメッセージ）とだけ当該リクエストに対して応答し得る。

１つ以上の利用可能なアップグレードパッケージ（単数または複数）がある場合、これらのアップグレードパッケージは、３５４において患者デバイスへ送信される。複数のアップグレードパッケージがある場合、当該複数のパッケージは、複数の異なるリクエストを介して患者デバイスからＭＭＳシステム１０６へ順次適用され得る。換言すると、（例えば、同一デバイスがＭＭＳシステム１０６へチェックインする異なる場合に応答した）規則マネージャモジュール１０８による規則の各順次適用を用いて、所与の患者デバイスへ適用されるべきさらなるアップグレードが決定され得る。よって、これらの規則が規則マネージャモジュール１０８によって処理される順序により、適用すべきアップグレードパッケージが（複数の可能なアップグレードパッケージから）決定され得る。特定の例において、ＭＭＳシステム１０６が決定した後にアップグレードパッケージをデバイスへ送達する方法により、アップグレードを連続的かつ／または決定論的に適用することが可能になる。例えば、デバイスは、複数の異なる事前条件（例えば、複数のアップグレードの適用が必要）に適合し得る。ＭＭＳシステム１０６は、アップグレード仕様内のセグメントの順序に基づいて送達すべきパッケージを決定することにより、このようなリクエストを有利に仲裁し得る。よって、例えば、満足されている事前条件を選択する代わりに、ＭＭＳシステムは、第１の事前条件をアップグレード仕様内において選択し得る（例えば、第１の事前条件が順番に処理されると仮定する）。この種の例示的アプローチにより、ＭＭＳシステム１０６の構築（例えば、リクエスト元のデバイスのアップグレードの既知の安全な連鎖）が可能になる。

任意のイベントにおいて、３５４において、アップグレードパッケージが患者デバイスへ送信される。次に、３５６において、デバイスステータス（例えば、図９Ａ中のステップ３１０において送信されたもの）は、ＭＭＳシステム１０６によって受信される。

３５８において、３５６において受信されたデバイスステータスが保存される。例えば、患者デバイスが所与の構成要素についてバージョン情報を送信すると、当該バージョニング情報は、ステータスＤＢ１１２に保存され得る（例えば、当該構成要素について前回保存されたバージョニング情報が上書きされる）。あるいは、アップグレードが成功しなかった場合、当該エラーの記録が保存され得、将来のフォローアップの可能性のためにフラグ付けされ得る。

特定の例において、ＭＭＳシステム１０６は、異なるコンピューティングデバイス上においてそれぞれ実行またはホストされ得る１つ以上のサービスを含み得る。このようなサービスを含む例示的システムを図１０Ａに示す。サービスは、クラウドサービス４００、リクエストサービス４０２、キュー４０４および／またはアップグレードサービス４０６を含み得る。例示的ＭＭＳシステムは、患者デバイス１０２とインターフェースをとる／通信するクラウドサービス４００を含み得る。特定の例において、クラウドサービス４００ｍａｙｂｅｈｏｓｔｅｄｉｎａクラウドコンピューティング環境（例えば、Ａｍａｚｏｎ ＡＷＳ、Ｍｉｃｒｏｓｏｆｔ Ａｚｕｒｅ）においてホストされて、利用可能性アップタイムを長くし、待ち時間低減のために地理位置情報をもとに配置されたサービスを提供する。本明細書中に記載のサービスのそれぞれまたはいずれかは、クラウドベースのコンピュータシステム内の別個の仮想コンテナまたはインスタンス内にホストされ得る。特定の例において、いくつかのサービスが、クラウドベースの実行の外部にホストされ得、クラウドベースの実行内の他のサービスと通信し得る。特定の例において、それぞれのサービスまたはいずれかのサービスが、当該サービス自身のコンピューティングノード上にホストされ得、そのうちいくつかまたはいずれかは、クラウドベースのシステムおよび他の外部内に配置され得る。コンピューティングノードは、別個の物理的コンピュータハードウェアおよび／または別個の仮想コンテナまたはインスタンスを含み得る。

クラウドサービス４００は、リクエストの管理および生成に用いられる別個に提供されたリクエストサービス４０２と通信し得る。特定の例において、リクエストは、アップグレードパッケージをカプセル化するために用いられる（例えば、所与のデバイスがアップグレードパッケージを適用するためのリクエスト）。生成されたリクエストは、未決定のリクエスト１１４中に保存され得る。特定の例において、リクエストは、所与の患者デバイスおよび／またはその構成要素の構成または他の設定を更新または変更せよとのリクエストも含み得る。リクエストサービス４０２は、未決定のリクエスト（例えば、未だ患者デバイスへ送信されておらずかつ／または未だ患者デバイスによって完了されていない）を保存するために用いられるキュー４０４とインターフェースをとり得る。リクエストサービス４０２は、アップグレードサービス４０６とも通信し得る。アップグレードサービス４０６は、所与のリクエストに対してソフトウェアまたはファームウェアのアップグレードが利用可能であるかを決定するため（または図１０Ｂに記載のようにアップグレードが利用可能である場合にリクエストを生成するため）に用いられる。

図１０Ａに戻って、ブローカーの関与を伴う（または未決定の）リクエストの取り出し例を、特定の例に従って示す。図１０Ａ～図１０Ｃにおいて、分散型サービス（例えば、４００、４０２、４０４および４０６）は、別個のコンピューティングリソース上に設けられ、それぞれが異なる機能を提供する。特定の例において、これらのサービスのそれぞれまたはいずれかは、クラウドコンピューティング環境上に設けられ得る。上記したように、このようなサービスは、集合的にＭＭＳシステム１０６全体内に設けられ得る。

４１０において、患者デバイス１０２は、患者デバイスの識別データをクラウドサービス４００へ送信する。これは、例えば、セルラーモジュールユニバーサル識別子または患者デバイス１０２を一意に識別するために用いられる他の一意の識別子であり得る。特定の例において、ＭＡＣアドレスは、セルラーモデムと対照的に患者デバイスからのリクエストが患者デバイスのネットワークインターフェースカードを介して送信される場合に用いられ得る。

４１２において、クラウドサービス４００は、送信された識別データと関連付けられた現在のリクエストを得るためのリクエストをリクエストサービス４０２へ発行する。換言すると、これにより、提供されたＩＤと関連付けられた現在のリクエストがあるかが決定される。これにより、リクエストサービス４０２は４１４においてキュー４０４へアクセスして、現在のリクエストを発見する。

その後、キュー４０４中のリクエストは、４１６においてブローカーのリクエストとしてリクエストサービス４０２へ返送され、その後リクエストサービス４０２は４１８においてこれをクラウドサービス４００へ返送させる。その後、ブローカーのリクエストは、４２０において患者デバイス１０２へ返送される。この種のアーキテクチャにより、リクエストの機能およびアップグレードサービスが、（少なくともチェックインしている任意の患者デバイスの観点から）クラウドサービスによってカプセル化され得る。

患者デバイス１０２へ返送されるブローカーのリクエストの一部として設けられ得るデータの例（「ＢｒｏｋｅｒＩｔｅｍ」）は、上記に示した表５中のブローカーアイテムである。別の例を、下記の表９中に示す。この例は、アップグレードデータパッケージについてのブローカーのリクエスト（この場合はファームウェアアップグレード）に関連する。

別の例を下記の表１０に示す。この例は、ブローカーのリクエスト中に含まれ得る設定プロファイルリクエストに関連する。

よって、患者デバイスの設定のためのプロファイルは、ブローカーのリクエストを介して送達され得る。

特定の例示的実施形態において、患者デバイスへ送達されるブローカーのリクエストは、１つ以上のブローカーの関与を伴うアイテムを含み得る。このようなインスタンスにおいて、リクエスト全体における個々のブローカーの関与を伴うアイテムは、患者デバイスへ別個に（かつ順次に）送達され得る。換言すると、患者デバイスは、１つのＢｒｏｋｅｒＩｔｅｍを処理した後、次のＢｒｏｋｅｒＩｔｅｍをリクエストする。例えば、表５、表９および表１０からのＢｒｏｋｅｒＩｔｅｍそれぞれは、所与の患者デバイスについての単一のブローカーのリクエスト中に含まれ得る。各ＢｒｏｋｅｒＩｔｅｍは、本明細書中に記載の実施形態により、患者デバイスへ送達され得る。特定の例において、各リクエストは、単一のＢｒｏｋｅｒＩｔｅｍのみを含み得、複数のリクエストが、所与の患者デバイスに対して生成され得る。

特定の例示的実施形態において、ブローカーのリクエストが受信されると、対応するリクエスト内のそれぞれのまたはいずれかのＢｒｏｋｅｒＩｔｅｍがパーズされ得、適切なアクションが患者デバイス１０２によってとられ得る。次に、例えば、ＢｒｏｋｅｒＩｔｅｍ内に表示され得るファイル（単数または複数）がダウンロードされ得る。特定の例示的実施形態において、患者デバイス１０２は、ファイルのダウンロードが成功した旨の報告をクラウドサービス４００へ提供し得る。次に、このステータスは、所与の患者デバイスについて現在未決定であるリクエスト（例えば、キュー４０４中に保存されたリクエスト）中に添付または採用され得る。ファイルは、ダウンロードされた後、患者デバイス１０２へ適用され得る。次に、特定の例において、患者デバイス１０２は再開し得、アップグレード構成要素が今やアップグレードバージョンになっている（例えば、アップグレードバージョン番号が指定され得る）旨のデバイスステータスメッセージが、クラウドサービスへ送信され得る。特定の例において、ステータスメッセージは、患者デバイス１０２へのアップグレードの適用が成功した旨の情報を含み得る。

特定の例において、ＢｒｏｋｅｒＩｔｅｍは、デバイスへ送信された後、キュー４０４から除去され得る（例えば、前回提出されたブローカーリクエストが除去され得る）。特定の例において、ファームウェアアップグレードの適用が成功したことに起因して、当該リクエストと関連付けられたＢｒｏｋｅｒＩｔｅｍが除去され得る。未決定のＢｒｏｋｅｒＩｔｅｍが無い場合、キュー４０４中のブローカーのリクエスト（単数または複数）は、当該患者デバイス１０２について消去され得る。

特定の例において、患者デバイス１０２に対するアップグレードプロセス時においてエラーが発生した場合、エラーの性質がクラウドサービス４００を通じて報告のため返送され得、将来の分析のために分析され得る。

図１０Ｂを参照して、ブローカーの関与を伴うファームウェアアップグレードリクエストの例が提供される。ここで、５００において、識別データが、患者デバイス１０２からクラウドサービス４００へ送信される。次に、クラウドサービス４００は、提供された識別データに基づいて、５０２においてリクエストサービス４０２から現在のブローカーのリクエストをリクエストする。リクエストサービス４０２は、キュー４０４により問い合わせして、５０４において現在のリクエストを発見する。

しかし、本例においては現在のリクエストは無いため、空のセットが５０６において返送される。次に、リクエストサービス４０２は、患者デバイス１０２について提供された識別データに基づいてファームウェア、ソフトウェアまたは他のアップグレードが利用可能であるかを決定せよとの旨のリクエストをアップグレードサービス４０６へ提出する。本明細書中記載のように、これは、ステータスＤＢ１１２に問い合わせて、提供された識別データと関連付けられた患者デバイスのプロファイルデータを入手することおよび／または規則マネージャモジュール１０８を用いて、アップグレードまたは変更を所与の患者デバイス１０２へ適用すべきかを決定することを含み得る。

ファームウェア（またはソフトウェアの他のアップグレードなど）が利用可能である場合、当該アップグレードの詳細が、５１０においてアップグレードサービス４０６からリクエストサービス４０２へ返送される。このような詳細は、例えば表９に示す詳細に類似し得る。例えば、ファイル（単数または複数）が配置された位置が提供され得、これらのファイルのハッシュ、サイズ、当該ファイルの対象となる患者デバイスの構成要素などがある。

アップグレード詳細がリクエストサービス４０２へ返送されると、リクエストサービス４０２は、５１２におけるこれらの詳細に基づいて、ブローカーのリクエストを生成し得る。これは、ブローカーのリクエストについての上記表に示すような１つ以上のＢｒｏｋｅｒＩｔｅｍの生成を含み得る。次に、生成されたリクエストまたはアイテムは、５１４においてキュー４０４へ付加され、その後、５１６において（例えば、図１Ａ中の４１６におけるリクエストの返送と同様に）返送される。これにより、各個々の患者デバイスについて処理する必要のあるリクエストの進捗（アップグレードを含む）をシステムにより追跡することが可能になる。次に、生成されたブローカーリクエスト（またはＢｒｏｋｅｒＩｔｅｍ）は、５１８においてクラウドサービス４００へルートバックされ、その後、５２０においてブローカーのリクエストを再度患者デバイス１０２へ通信させる。その後の処理は、上記において図１０Ａに関連して述べた（アップグレードの検証および適用が行われ得る）ものと同様であり得る。

図１０Ｃは、患者デバイス１０２についてブローカーリクエストが無い場合に発生する詳細の信号図を示す。６００において、患者デバイス１０２は、識別データをクラウドサービス４００へ提出する。その後、クラウドサービスは、６０２においてブローカーのリクエストについてのリクエストをリクエストサービスへ提出する。リクエストサービスは、６０４においてキュー４０４を問い合わせる。キュー４０４中には何も無いため、６０６においては何も返送されない。次に、リクエストサービスは、６０８におけるリクエストをアップグレードサービス４０６へ提出して、アップグレード詳細を取り出す。６１０において、応答が「何も無い」かまたは他の類似の応答がある場合（例えば、適用可能なアップグレードが無い場合）、表示されたデバイスについてアップグレードは存在しない旨をが、アップグレードサービス４０６から返送される。無しの応答は、６１２においてクラウドサービス４００へ返送され、クラウドサービス４００は、この応答を６１４において患者デバイス１０２へリレーする。

５．１０ コンピューティングデバイス
図１１は、いくつかの実施形態による例示的コンピューティングデバイス１１００のブロック図である（これは、例えば、「コンピュータデバイス」、「コンピュータシステム」または「コンピューティングシステム」とも呼ばれ得る）。いくつかの実施形態において、コンピューティングデバイス１１００は、以下のうち１つ以上を含む：１つ以上のプロセッサ１１０２；１つ以上のメモリデバイス１１０４；１つ以上のネットワークインターフェースデバイス１１０６；１つ以上のディスプレイインターフェース１１０８；および１つ以上のユーザ入力アダプタ１１１０。さらに、いくつかの実施形態において、コンピューティングデバイス１１００は、ディスプレイデバイス（単数または複数）１１１２へ接続されるかまたはディスプレイデバイス（単数または複数）１１１２を含む。さらに、いくつかの実施形態において、コンピューティングデバイス１１００は、１つ以上の入力デバイス１１１４へ接続されるかまたは１つ以上の入力デバイス１１１４を含む。いくつかの実施形態において、コンピューティングデバイス１１００は、１つ以上の外部デバイス１１１６へ接続され得る。以下に述べるように、これらの要素（例えば、プロセッサ１１０２、メモリデバイス１１０４、ネットワークインターフェースデバイス１１０６、ディスプレイインターフェース１１０８、ユーザ入力アダプタ１１１０、ディスプレイデバイス１１１２、入力デバイス１１１４、外部デバイス１１１６）は、ハードウェアデバイス（例えば、電子回路または回路の組み合わせ）であり、コンピューティングデバイス１１００のための多様な異なる機能および／またはコンピューティングデバイス１１００に関連する多様な異なる機能を行うように構成される。

いくつかの実施形態において、プロセッサ１１０２のそれぞれまたはいずれかは、以下のものであるかまたは以下のものを含む：例えば、シングルコアまたはマルチコアのプロセッサ、マイクロプロセッサ（例えば、中央処理ユニットまたはＣＰＵと呼ばれ得るもの）、デジタル信号プロセッサ（ＤＳＰ）、ＤＳＰコアと関連するマイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプロマブルゲートアレイ（ＦＰＧＡ）回路、またはシステムオンアチップ（ＳＯＣ）（例えば、例えば、ＣＰＵ、ＧＰＵおよび他のハードウェア構成要素（例えば、メモリおよび／またはメモリコントローラ（例えば、Ｎｏｒｔｈｂｒｉｄｇｅ）、Ｉ／Ｏコントローラ（例えば、Ｓｏｕｔｈｂｒｉｄｇｅ）、ネットワーキングインターフェース）を含む集積回路）。いくつかの実施形態において、プロセッサ１１０２それぞれまたはいずれかは、命令セットアーキテクチャを用いる（例えば、ｘ８６またはアドバンストＲＩＳＣマシン（ＡＲＭ））。いくつかの実施形態において、プロセッサ１１０２それぞれまたはいずれかは、例えば、（画像などを生成するように設計された電子回路であり得る）グラフィカル処理ユニット（ＧＰＵ）であるかまたはグラフィカル処理ユニット（ＧＰＵ）を含む。

いくつかの実施形態において、メモリデバイス１１０４のそれぞれまたはいずれかは、ランダムアクセスメモリ（ＲＡＭ）（例えば、ダイナミックＲＡＭ（ＤＲＡＭ）またはスタティックＲＡＭ（ＳＲＡＭ））、フラッシュメモリ（例えば、ＮＡＮＤまたはＮＯＲ技術に基づいたもの）、ハードディスク、光磁気媒体、光媒体、キャッシュメモリ、（例えば、プロセッサ１１０２のうち１つ以上によって実行され得る指示項目を保持する）レジスター、またはデータおよび／または指示項目の揮発型または不揮発型の保存を行う他の種類のデバイス（例えば、プロセッサ１１０２上において実行されるかまたはそれによって実行されるソフトウェア）であるかまたはそのようなものを含む。いくつかの実施形態において、メモリデバイス１１０４それぞれまたはいずれかは、コンピューティングデバイス１１００から取り外し可能である。（例えば、ＵＳＢフラッシュドライブ、フロッピーディスク、コンパクトディスク（ＣＤ）など）。メモリデバイス１１０４は、非一時的なコンピュータ可読記憶部の例である。本明細書中で用いられるように、「非一時的なコンピュータ可読記憶媒体」という用語は、以下を含む：レジスター、キャッシュメモリ、ＲＯＭ、半導体メモリデバイス（例えば、Ｄ－ＲＡＭ、Ｓ－ＲＡＭまたは他のＲＡＭ）、磁気媒体（例えば、フラッシュメモリ、ハードディスク、光磁気媒体）、光媒体（例えば、ＣＤ－ＲＯＭ、ＤＶＤ、またはブルーレイディスク）、あるいは非一時的な電子データ保存のための他の種類のデバイス。「非一時的なコンピュータ可読記憶媒体」という用語は、一時的な伝搬性の電磁気信号を含まない。

いくつかの実施形態において、ネットワークインターフェースデバイス１１０６それぞれまたはいずれかは、１つ以上の回路（例えば、ベースバンドプロセッサおよび／または有線トランシーバまたは無線トランシーバ）を含み、１つ以上の有線通信技術（例えば、イーサネット（ＩＥＥＥ８０２．３））および／または無線通信技術（例えば、Ｂｌｕｅｔｏｏｔｈ、ＷｉＦｉ（ＩＥＥＥ８０２．１１）、ＧＳＭ、ＣＤＭＡ２０００、ＵＭＴＳ、ＬＴＥ、ＬＴＥアドバンスト（ＬＴＥ－Ａ）のための第１の層、第２の層および／またはより上位層ならびに／あるいは他の短距離、中距離および／または長距離の無線通信技術）を実行する。トランシーバは、送信器および受信器のための回路機構を含み得る。送信器および受信器は、共通ハウジングを共有し得、送信および受信を行うためにハウジング内の回路機構のうちいくつかまたは全てを共有し得る。いくつかの実施形態において、トランシーバの送信器および受信器は、任意の共通回路を共有しない場合がありかつ／または同一または別個のハウジング内に設けられ得る。

いくつかの実施形態において、ディスプレイインターフェース１１０８のそれぞれまたはいずれかは、以下を行う１つ以上の回路であるかまたはそのような回路を含む：プロセッサ１１０２からのデータ受信、受信データに基づいた（例えば、離散ＧＰＵ、集積ＧＰＵ、グラフィカル処理を実行するＣＰＵなどを介した）対応する画像データの生成および／または出力（例えば、高解像度マルチメディアインターフェース（ＨＤＭＩ）、ディスプレイポートインターフェース、ビデオグラフィックスアレイ（ＶＧＡ）インターフェース、デジタルビデオインターフェース（ＤＶＩ）など）を介した、（画像データを表示する）ディスプレイデバイス１１１２への画像データの出力。代替的にまたは追加的に、いくつかの実施形態において、ディスプレイインターフェース１１０８それぞれまたはいずれかは、例えば、ビデオカード、ビデオアダプタまたはグラフィックス処理ユニット（ＧＰＵ）であるかまたはそのようなものを含む。換言すると、ディスプレイインターフェース１１０８それぞれまたはいずれかは、画像データ生成に用いられるプロセッサを内部に含み得る。生成またはこのような画像は、プロセッサ１１０２のうち１つ以上によって行われる処理に関連して発生し得る。

いくつかの実施形態において、ユーザ入力アダプタ１１１０それぞれまたはいずれかは、１つ以上の回路であるかまたは１つ以上の回路を含む。これらの回路は、（コンピューティングデバイス１１００に含まれるかそれへ取り付けられるかまたは他の方法でそれと通信する）１つ以上のユーザ入力デバイス１１１４からのユーザ入力データを受信および処理し、受信された入力データに基づいてデータをプロセッサ１１０２へ出力する。代替的にまたは追加的に、いくつかの実施形態においてユーザ入力アダプタ１１１０それぞれまたはいずれかは、例えばＰＳ／２インターフェース、ＵＳＢインターフェース、タッチスクリーンコントローラなどであるかまたは例えばＰＳ／２インターフェース、ＵＳＢインターフェース、タッチスクリーンコントローラなどを含み、かつ／または、ユーザ入力アダプタ１１１０により、ユーザ入力デバイス１１１４からの入力が促進される。

いくつかの実施形態において、ディスプレイデバイス１１１２は、液晶表示（ＬＣＤ）ディスプレイ、発光ダイオード（ＬＥＤ）ディスプレイ、または他の種類のディスプレイデバイスであり得る。ディスプレイデバイス１１１２がコンピューティングデバイス１１００の構成要素である（例えば、コンピューティングデバイスおよびディスプレイデバイスが一体型ハウジング内に設けられる）実施形態において、ディスプレイデバイス１１１２は、タッチスクリーンディスプレイまたは非タッチスクリーンディスプレイであり得る。ディスプレイデバイス１１１２がコンピューティングデバイス１１００へ接続された（例えば、コンピューティングデバイス１１００の外部にあり、有線および／または無線通信技術を介してコンピューティングデバイス１１００と通信する）実施形態において、ディスプレイデバイス１１１２は、例えば外部モニタ、プロジェクタ、テレビ、表示画面である。

いくつかの実施形態において、入力デバイス１１１４それぞれまたはいずれかは、物理的現象に応答してユーザ入力アダプタ（単数または複数）１１１０へ提供される信号を生成する機械および／または電子機器であるかまたはそのような機械および／または電子機器を含む。入力デバイス１１１４の例を挙げると、例えば、キーボード、マウス、トラックパッド、タッチスクリーン、ボタン、ジョイスティック、センサ（例えば、加速度センサ、ジャイロセンサ、温度センサ、圧力センサ（例えば、ガス圧力を測定するもの）、流れセンサ（例えば、ガスまたは液体の流れの速度を測定するもの）など）、マイクロフォンがある。いくつかの例において、１つ以上の入力デバイス１１１４は、ユーザから（例えば、ボタン押圧、音声コマンドの発声などにより）提供される入力に応答して提供される信号を生成する。他の例において、１つ以上の入力デバイスは、感知された物理量（例えば、力、圧力、温度）に基づいて信号を生成する。いくつかの実施形態において、入力デバイス１１１４それぞれまたはいずれかは、コンピューティングデバイスの構成要素である（例えば、ボタンが、プロセッサ１１０２、メモリデバイス１１０４、ネットワークインターフェースデバイス１１０６、ディスプレイインターフェース１１０８、ユーザ入力アダプタ１１１０などを含むハウジング上に設けられる）。

いくつかの実施形態において、外部デバイス（単数または複数）１１１６それぞれまたはいずれかは、コンピューティングデバイス１１００と通信する他のコンピューティングデバイスを含み得る（例えば、コンピューティングデバイス１１００の他のインスタンス）。例を挙げると、サーバコンピュータ、クライアントコンピュータシステム、モバイルコンピューティングデバイス、クラウドベースのコンピュータシステム、コンピューティングノード、モノのインターネット（ＩｏＴ）デバイス、流れ生成器などがあり、これらは全て、コンピューティングデバイス１１００と通信し得る。一般的に、外部デバイス（単数または複数）１１１６は、コンピューティングデバイス１１００と（例えば、電子的に）通信するデバイスを含み得る。一例として、コンピューティングデバイス１１００は、流れ生成器または患者インターフェースデバイスまたはマスク（例えば、外部デバイス１１１６の例）と通信するモバイルデバイスである。逆に、コンピューティングデバイス１１００は、流れ生成器であり得、サーバまたはクラウドベースのコンピュータシステムと通信する。このサーバまたはクラウドベースのコンピュータシステムは、外部デバイス１１１６の例であり、データおよび／またはソフトウェア更新を流れ生成器へ提供する。

多様な実施形態において、コンピューティングデバイス１１００は、上記の要素のうちそれぞれまたはいずれかを１つまたは２つ、または３つ、４つ以上を含む（例えば、プロセッサ（単数または複数）１１０２、メモリデバイス（単数または複数）１１０４、ネットワークインターフェースデバイス（単数または複数）１１０６、ディスプレイインターフェース（単数または複数）１１０８、ユーザ入力アダプタ（単数または複数）１１１０、ディスプレイデバイス（単数または複数）１１１２、入力デバイス（単数または複数）１１１４）。代替的にまたは追加的に、いくつかの実施形態において、コンピューティングデバイス１１００は、以下のうち１つ以上を含む：プロセッサ１１０２を含む処理システム；メモリデバイス１１０４を含むメモリまたは記憶システム；およびネットワークインターフェースデバイス１１０６を含むネットワークインターフェースシステム。

コンピューティングデバイス１１００は、多様な実施形態において多数の異なる様態で配置され得る。ひとえに一例として、コンピューティングデバイス１１００は、プロセッサ１１０２が以下のものを含むように配置され得る：マルチコア（またはシングルコア）のプロセッサ；（例えば、ＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ、ＮＦＣなどを実行する）第１のネットワークインターフェースデバイス；１つ以上のセルラー通信技術（例えば、３Ｇ、４ＧＬＴＥ、ＣＤＭＡなど）を実行する第２のネットワークインターフェースデバイス；メモリまたは記憶デバイス（例えば、ＲＡＭ、フラッシュメモリまたはハードディスク）。プロセッサ、第１のネットワークインターフェースデバイス、第２のネットワークインターフェースデバイスおよびメモリデバイスは、同一ＳＯＣ（例えば、１つの集積回路チップ）の一部として集積され得る。別の例として、コンピューティングデバイス１１００は、以下が可能となるように配置され得る：プロセッサ１１０２が２つ、３つ、４つ、５つ以上のマルチコアプロセッサを含み；ネットワークインターフェースデバイス１１０６が、イーサネットを実行する第１のネットワークインターフェースデバイスと、ＷｉＦｉおよび／またはＢｌｕｅｔｏｏｔｈを実行する第２のネットワークインターフェースデバイスとを含み；メモリデバイス１１０４が、ＲＡＭおよびフラッシュメモリまたはハードディスクを含む。別の例として、コンピューティングデバイス５｜００は、ＳｏＣを以下のものとともに含み得る：１つまたはプロセッサ５｜０２、複数のネットワークインターフェースデバイス５｜０６（例えば、セルラー接続を介した通信を行うものおよびＢｌｕｅｔｏｏｔｈ接続を介して通信するもの）、システムメモリおよびアプリケーションプログラムおよび他のソフトウェアのためのメモリを含むメモリデバイス５｜０４、映像信号を出力するように構成されたディスプレイインターフェース５｜０８、ハウジングと一体化されかつタッチスクリーン入力デバイス５｜１４と積層されたディスプレイデバイス５｜１２、ならびに複数の入力デバイス５｜１４（例えば、１つ以上のボタンおよび／またはおよび１つ以上のセンサ）。

上記したように、本文書中、ソフトウェアモジュールまたはソフトウェアプロセスが任意のアクションを行うことが記載されている場合は必ず、当該アクションは、実際は、ソフトウェアモジュールを含む指示項目に従って下側のハードウェア要素によって行われる。上記と一貫して、多様な実施形態において、クラウドサービス４００、リクエストサービス４０２、キュー４０４、アップグレードサービス４０６、ＭＭＳシステム１０６、規則マネージャモジュール１０８、規則１１０、ステータスデータベース１１２、アップグレードパッケージ１１６および未決定のリクエスト１１４それぞれまたは任意の組み合わせについて、本段落の残り部分においてそれぞれが個別に明確さのために「構成要素」と呼ばれ、図５のコンピューティングデバイス１１００の例を用いて実行される。このような実施形態において、以下は、各構成要素について適用される：（ａ）図１１に示す１１００コンピューティングデバイス１１００の要素（すなわち、１つ以上のプロセッサ１１０２、１つ以上のメモリデバイス１１０４、１つ以上のネットワークインターフェースデバイス１１０６、１つ以上のディスプレイインターフェース１１０８、および１つ以上のユーザ入力アダプタ１１１０）、または上記の適切な組み合わせまたはサブセットであり、１つ以上のディスプレイデバイス１１１２、１つ以上の入力デバイス１１１４および／または外部デバイス１１１６を備えるかまたは備えないもの）は、構成要素によっておよび／または構成要素内に含まれるものとして本明細書中に記載される任意のソフトウェアモジュールによって行われるような本明細書中に記載のアクション、活動または機能それぞれまたは任意の組み合わせを実行するように構成され、適合されかつ／またはプログラムされるように構成され；（ｂ）代替的にまたは追加的に、１つ以上のソフトウェアモジュールが構成要素内に設けられる本明細書中に記載の範囲まで、いくつかの実施形態において、このようなソフトウェアモジュール（およびソフトウェアモジュールによって取り扱いかつ／または用いられるような本明細書中に記載の任意のデータ）は、メモリデバイス１１０４内に保存される（例えば、多様な実施形態において、揮発性メモリデバイス（例えば、ＲＡＭまたは命令レジスタ）内かつ／または不揮発性メモリデバイス（例えば、フラッシュメモリまたはハードディスク）内に保存され）、ソフトウェアモジュールによって行われるような本明細書中に記載の全アクションは、コンピューティングデバイス１１００内のその他の要素および／またはコンピューティングデバイス１１００へ接続されたその他の要素（例えば、ネットワークインターフェースデバイス１１０６、ディスプレイインターフェース１１０８、ユーザ入力アダプタ１１１０、ディスプレイデバイス（単数または複数）１１１２、入力デバイス（単数または複数）１１１４および／または外部デバイス（単数または複数）１１１６）と共にプロセッサ１１０２により適宜行われ；（ｃ）代替的にまたは追加的に、本明細書中に記載の範囲まで、構成要素プロセスおよび／または他のものは、データを取り扱い、いくつかの実施形態において、このようなデータは、メモリデバイス１１０４中（例えば、いくつかの実施形態において、揮発性メモリデバイス（例えば、ＲＡＭ）および／または不揮発性メモリデバイス（例えば、フラッシュメモリまたはハードディスク））中に保存され、かつ／または、コンピューティングデバイス１１００内のその他の要素および／またはコンピューティングデバイス１１００へ接続されたその他の要素（例えば、ネットワークインターフェースデバイス１１０６、ディスプレイインターフェース１１０８、ユーザ入力アダプタ１１１０、ディスプレイデバイス（単数または複数）１１１２、入力デバイス（単数または複数）１１１４および／または外部デバイス（単数または複数）１１１６）と共にプロセッサ１１０２により適宜処理され／取り扱われ；（ｄ）代替的にまたは追加的に、いくつかの実施形態において、メモリデバイス１１０２は、命令を保存する。これらの命令は、プロセッサ１１０２によって実行されると、コンピューティングデバイス１１００内に設けられかつ／またはコンピューティングデバイス１１００へ接続されたその他の要素（例えば、メモリデバイス１１０４、ネットワークインターフェースデバイス１１０６、ディスプレイインターフェース１１０８、ユーザ入力アダプタ１１１０、ディスプレイデバイス（単数または複数）１１１２、入力デバイス（単数または複数）１１１４および／または外部デバイス（単数または複数）１１１６）と適宜連動して、下記をプロセッサ１１０２に行わせる：構成要素によってかつ／または構成要素内に設けられるような本明細書中に記載の任意のソフトウェアモジュールによって行われるような本明細書中に記載のアクションそれぞれまたはその組み合わせ。

図１１中に図示および上記に記載されるハードウェア構成は、例としてのものであり、本明細書中に記載の内容は、多様な異なるハードウェアアーキテクチャおよび要素と関連して用いられ得る。例えば：本文書中の図の多くにおいて、個々の機能／アクションブロックが図示されており；多様な実施形態において、これらのブロックの機能は、（ａ）個々のハードウェア回路を用いて、（ｂ）記載の機能／アクションを行うように詳細に構成された特定用途向け集積回路（ＡＳＩＣ）を用いて、（ｃ）記載の機能／アクションを行うように詳細に構成された１つ以上のデジタル信号プロセッサ（ＤＳＰ）を用いて、（ｄ）図１１を参照して上記されたハードウェア構成を用いて、（ｅ）他のハードウェア配置構成、アーキテクチャおよび構成を介して、ならびに／あるいは（ａ）～（ｅ）に記載の技術の組み合わせを介して、実行され得る。

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

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

周囲：本技術の特定の形態において、「周囲」という用語は、（ｉ）治療システムまたは患者の外部、および（ｉｉ）治療システムまたは患者を直接包囲するものを意味するものとしてとられるべきである。

例えば、加湿器に対する周囲湿度とは、加湿器を直接包囲する空気の湿度であり得る（例えば、患者が睡眠をとっている部屋の内部の湿度）。このような周囲湿度は、患者が睡眠をとっている部屋の外部の湿度と異なる場合がある。

別の例において、周囲圧力は、身体の直接周囲または外部の圧力であり得る。

特定の形態において、周囲（例えば、音響）ノイズは、例えばＲＰＴデバイスから発生するかまたはマスクまたは患者インターフェースから発生するノイズ以外の、患者の居る部屋の中の背景ノイズレベルとみなすことができる。周囲ノイズは、部屋の外の発生源から発生し得る。

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

流れ治療：患者の呼吸サイクル全体にかけて通常陽圧である治療流量と称される制御された流量において気道への入口に空気流れを送達することを含む、呼吸治療。

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

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

呼吸圧力治療（ＲＰＴ）：雰囲気に対して典型的には陽圧である治療圧力における空気供給の気道入口への付加。

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

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

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

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

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

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

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

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

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

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

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

よって、本技術の意図および範囲から逸脱することなく、例示的な例において多数の変更例が可能であり、また、他の配置構成が考案され得ることが理解されるべきである。

Claims (17)

1. 患者呼吸デバイスと通信するコンピュータシステムと共に用いられる、コンピュータにより実行可能な命令を保存する非一時的なコンピュータ可読媒体であって、前記患者呼吸デバイスは、前記患者呼吸デバイスの動作の制御に用いられるファームウェア及び／またはソフトウェアを保存する電子メモリを含み、前記コンピュータにより実行可能な命令は、前記コンピュータシステムに、
   前記患者呼吸デバイスから、前記患者呼吸デバイスのための識別データを含む第１のメッセージを受信するステップであって、前記第１のメッセージが前記コンピュータシステムからの第１のプロンプトなしに前記患者呼吸デバイスから通信される、受信するステップと、
   複数の患者呼吸デバイスのための記録を含むステータスデータベースの１つまたは複数の記録から、前記患者呼吸デバイスのためのデバイスプロファイルデータを取得するステップであって、前記記録のそれぞれが、複数の異なる患者呼吸デバイスのそれぞれにインストールされたファームウェア及び／またはソフトウェアを識別するバージョニングデータ、受信された前記第１のメッセージの処理に基づいて取得された前記デバイスプロファイルデータ、及び前記第１のメッセージに含まれる前記患者呼吸デバイスの前記識別データを含む、取得するステップと、
   前記患者呼吸デバイスのための前記デバイスプロファイルデータに基づいて、前記患者呼吸デバイスに適用されることとなる複数の利用可能なアップグレードパッケージから少なくとも１つのアップグレードパッケージを選択するステップであって、前記複数の利用可能なアップグレードパッケージのそれぞれが、識別プロファイルデータを含む少なくとも１つのアップグレード規則と関連付けられる、選択するステップと、
   選択された前記少なくとも１つのアップグレードパッケージに基づいて、前記患者呼吸デバイスの前記ソフトウェア及び／またはファームウェアをアップデートするのに使用されるデータを含む第２のメッセージを生成するステップと、
   前記第２のメッセージを前記患者呼吸デバイスに送信するステップであって、前記第２のメッセージが、前記ファームウェア及び／またはソフトウェアに対するアップデートを前記患者呼吸デバイスへ適用するアップデートプロセスを、前記患者呼吸デバイスに行わせる、送信するステップと、
   を含む動作を実行させるように構成された命令を含む、非一時的なコンピュータ可読媒体。
2. 前記少なくとも１つのアップグレードパッケージを選択するステップは、前記デバイスプロファイルデータの前記識別プロファイルデータに対する比較に基づいて適用する前記アップグレード規則を選択するステップを含む、請求項１に記載の非一時的なコンピュータ可読媒体。
3. 前記動作がさらに、
   異なるアップグレード規則にそれぞれ対応する複数の記録を含む規則データベースにアクセスするステップを含み、
   前記少なくとも１つのアップグレードパッケージを選択するステップが、前記デバイスプロファイルデータの前記識別プロファイルデータに対する比較に基づいて適用する前記アップグレード規則を選択するステップを含む、請求項１に記載の非一時的なコンピュータ可読媒体。
4. 前記規則データベースの前記複数の記録のそれぞれが、少なくとも１つの事前条件を含み、
   前記少なくとも１つのアップグレードパッケージを選択するステップが、前記アップグレード規則の前記少なくとも１つの事前条件を前記患者呼吸デバイスの前記デバイスプロファイルデータのデータと整合させるステップを含む、請求項３に記載の非一時的なコンピュータ可読媒体。
5. 前記動作がさらに、
   前記第１のメッセージに含まれる前記患者呼吸デバイスのための前記識別データに基づいて、前記患者呼吸デバイスについての未決定のリクエストが存在するか否かを決定するステップを含む、請求項１に記載の非一時的なコンピュータ可読媒体。
6. 前記動作がさらに、
   前記患者呼吸デバイスについての未決定のリクエストが存在することの決定に基づいて、リクエストを生成してデータ構造に前記リクエストを保存するステップを含み、前記リクエストが前記選択された少なくとも１つのアップグレードパッケージに基づくデータを含む、請求項５に記載の非一時的なコンピュータ可読媒体。
7. 未決定のリクエストが存在するか否かの決定が、前記ステータスデータベースから１つまたは複数の記録を取得するのに先立って行われる、請求項１に記載の非一時的なコンピュータ可読媒体。
8. 前記動作がさらに、
   第２の患者呼吸デバイスについての未決定のリクエストが存在することの決定に基づいて、前記第２の患者呼吸デバイスについてのデバイスプロファイルを最初に取得することなくアップデートメッセージを生成し、前記第２の患者呼吸デバイスに送信するステップを含む、請求項７に記載の非一時的なコンピュータ可読媒体。
9. 前記動作がさらに、
   第２の患者呼吸デバイスについての未決定のリクエストが存在することの決定に基づいて、複数のアップグレードパッケージからアップグレードパッケージを最初に選択することなくアップデートメッセージを生成し、前記第２の患者呼吸デバイスに送信するステップを含む、請求項８に記載の非一時的なコンピュータ可読媒体。
10. 前記患者呼吸デバイスについての前記デバイスプロファイルデータが、前記患者呼吸デバイスを他の患者呼吸デバイスから一意に識別する一意の識別子を含む、請求項１に記載の非一時的なコンピュータ可読媒体。
11. 前記一意の識別子が、前記患者呼吸デバイスとともに含まれるトランシーバと関連付けられる、請求項１０に記載の非一時的なコンピュータ可読媒体。
12. 前記患者呼吸デバイスの前記ソフトウェアまたはファームウェアについてのバージョニング情報が、前記第１のメッセージに含まれていない、請求項１に記載の非一時的なコンピュータ可読媒体。
13. 前記コンピュータシステムが、前記動作のうち異なるものをそれぞれ実行する第１のコンピューティングノード及び第２のコンピューティングノードを含む、請求項１に記載の非一時的なコンピュータ可読媒体。
14. 前記動作がさらに、
    アップグレードセグメントの１つの事前条件が前記患者呼吸デバイスについての前記デバイスプロファイルデータの前記バージョニングデータと整合されるまで、アップグレード仕様に特定される複数のアップグレードセグメントを通じてパーズする（ｐａｒｓｉｎｇ）ステップを含む、請求項１に記載の非一時的なコンピュータ可読媒体。
15. ファームウェア及び／またはソフトウェアをアップデートするためのシステムであって、前記システムが、
    請求項１に記載のコンピュータシステムを含むアップデートシステムであって、前記アップデートシステムが、前記患者呼吸デバイスからリモートに配置される、アップデートシステムと、
    請求項１に記載の患者呼吸デバイスと、を含み、前記患者呼吸デバイスが、
    前記第１のメッセージを、前記アップデートシステムと通信させることであって、前記第１のメッセージが前記患者呼吸デバイスについての識別データを含む、通信させることと、
    前記第２のメッセージを受信することと、
    前記第２のメッセージに基づいて、前記ファームウェア及び／またはソフトウェアに対するアップデートを前記患者呼吸デバイスに適用するアップデートプロセスを実行することと、
    を含む動作を実行するように構成された、システム。
16. 患者呼吸デバイスに提供されるアップデートを管理するコンピュータシステムで実行される方法であって、前記方法が、
    患者呼吸デバイスの動作を制御するために用いられるファームウェアおよびソフトウェアを保存する電子メモリを含む患者呼吸デバイスから、前記患者呼吸デバイスについての識別データを含む第１のメッセージを受信するステップであって、前記第１のメッセージが前記コンピュータシステムからの第１のプロンプトなしに前記患者呼吸デバイスから通信される、受信するステップと、
    複数の患者呼吸デバイスについての記録を含むステータスデータベースの１つまたは複数の記録から、前記患者呼吸デバイスのデバイスプロファイルデータを取得するステップであって、前記記録のそれぞれが、複数の異なる患者呼吸デバイスのそれぞれにインストールされたファームウェア及び／またはソフトウェアを識別するバージョニングデータ、受信された前記第１のメッセージの処理に基づいて取得された前記デバイスプロファイルデータ、及び前記第１のメッセージに含まれる前記患者呼吸デバイスの前記識別データを含む、取得するステップと、
    前記患者呼吸デバイスについての前記デバイスプロファイルデータに基づいて、前記患者呼吸デバイスに適用されることとなる複数の利用可能なアップグレードパッケージから少なくとも１つのアップグレードパッケージを選択するステップであって、前記複数の利用可能なアップグレードパッケージのそれぞれが、識別プロファイルデータを含む少なくとも１つのアップグレード規則と関連付けられる、選択するステップと、
    選択された前記少なくとも１つのアップグレードパッケージに基づいて、前記患者呼吸デバイスの前記ソフトウェア及び／またはファームウェアをアップデートするために使用されるデータを含む第２のメッセージを生成するステップと、
    前記第２のメッセージを前記患者呼吸デバイスに送信するステップであって、前記第２のメッセージが、前記患者呼吸デバイスに前記ファームウェア及び／またはソフトウェアに対するアップデートを適用するためのアップデートプロセスを、前記患者呼吸デバイスに実行させる、送信するステップと、
    前記患者呼吸デバイスについての識別データを含む第３のメッセージを受信するステップであって、前記第３のメッセージが、前記コンピュータシステムからの第１のプロンプトなしに前記患者呼吸デバイスから通信される、受信するステップと、
    前記第３のメッセージに基づいて、第４のメッセージを前記第３のメッセージにおいて識別された患者呼吸デバイスに返送するステップであって、前記第４のメッセージが、ファームウェア及び／またはソフトウェアに対するアップデートを適用するためのデータを含む、返送するステップと、を含む、方法。
17. 前記第３のメッセージの受信の結果、アップグレードされるファームウェア及び／またはソフトウェアを特定する既存のブローカーのリクエストを取り出すことと、
    前記既存のブローカーのリクエストに基づいて、前記第４のメッセージを生成することと、をさらに含み、
    前記第３のメッセージが受信されると、前記第４のメッセージの生成が、デバイスプロファイルデータを取得することまたは複数の利用可能なアップグレードパッケージからアップグレードパッケージを選択することに依存することなく実行される、請求項１６に記載の方法。