本開示には、種々の変形および代替形態がある。図面に例示したいくつかの代表的な実施形態について、本明細書において以下に詳述する。ただし本発明は、開示された特定の形態に限定されることを意図してはいないものと理解すべきであり、本開示はむしろ、添付の請求項によって定義された本発明の精神および範囲内にあるすべての変形、均等物、および代替物を網羅するものである。
本発明は、数多くの異なる形態で具現化することできる。代表的な実施形態を図面に示しており、本明細書において以下に詳述する。本開示は、本開示の原理の一例または例示であり、本開示の広範な態様を、例示された実施形態に限定することを意図するものではない。そのため、例えば「要約」、「発明の概要」、「発明を実施するための形態」の各節で開示されていても、請求項に明記されていない要素や制限は、単独でも集合的にも、暗示、推論、または他の方法によって請求項に組み込むべきでない。本明細書中では、特に断りがない限り、単数形は複数形を含み、その逆もある。「~を含む」という語は、「~を含むがそれ(ら)に限定されない」を意味する。さらに、本明細書においては、「概ね」、「略」、「実質的に」、「約」といった近似を表す語を、例えば、「ちょうど」、「付近」、「前後」、「~の3~5%以内」、「許容可能な製造公差の範囲内」、またはそれらの任意の論理的な組み合わせを意味する目的で使用することできる。
本開示は、呼吸圧力治療デバイスのユーザに合わせて選択されたマスクからフィードバックデータを収集するシステムおよび方法に関連する。マスクは、ユーザに合わせて収集された顔のデータに基づいたサイズにされる。ユーザに対し、サイズ決めされたマスクについてのフィードバックデータを収集するインターフェースが提示される。このデータは、類似の患者用のマスクの設計を要素(例えば、動作データ、患者人口統計、患者の顔フィーチャ)に基づいてさらに精緻にするために分析される。
図1は、患者インターフェース100を装着している患者10を含むシステムを示す。このシステムは、フルフェイスマスク(FFM)の形態をとり、呼吸圧力治療(RPT)デバイス40から供給される陽圧の空気を受容する。RPTデバイス40からの空気は、加湿器60によって加湿され、空気回路50に沿って患者10へと移動する。
図2は、本技術の一態様による患者インターフェース100を示す。患者インターフェース100において、以下の機能態様が含まれる。シール形成構造160、プレナムチャンバ120、位置決めおよび安定化構造130、通気部140、前額支持部150、図1中の空気回路50への接続のための一形態の接続ポート170。いくつかの形態において、機能態様が、1つ以上の物理的コンポーネントによって提供され得る。いくつかの形態において、1つの物理的コンポーネントは、1つ以上の機能態様を提供し得る。使用時において、シール形成構造160は、気道への陽圧での空気供給を促進するように、患者の気道の入口を包囲するように配置される。
本技術の一形態において、シール形成構造160は、シール形成表面を提供し、クッション機能をさらに提供し得る。本技術によるシール形成構造160は、柔らかく、可撓性がありかつ弾力性のある材料(例えば、シリコーン)から構成され得る。一形態において、非侵襲的患者インターフェース100のシール形成部分は、一対の鼻パフまたは鼻枕を含む。各鼻パフまたは鼻枕は、患者の鼻の各鼻孔とのシールを形成するように構成および配置される。
本技術による鼻枕は、円錐台を含む。円錐台のうち少なくとも一部は、患者の鼻の下側、柄部、円錐台の下側上の可撓性領域上に密閉を形成し、円錐台を柄部へ接続させる。加えて、本技術の鼻枕が接続される構造は、柄部のベースに隣接する可撓性領域を含む。可撓性領域は、自在接合構造を促進するように機能し得る。自在接合構造は、円錐台の変位および角度双方と、鼻枕が接続される構造との相互移動に対応する。例えば、円錐台は、柄部が接続された構造に向かって軸方向に変位し得る。
一形態において、非侵襲的患者インターフェース100は、患者の顔の上唇領域(すなわち、上唇)上にシールを形成するシール形成部分を含む。一形態において、非侵襲的患者インターフェース100は、使用時に患者の顔の顎領域上に密閉を形成するシール形成部分を含む。
好適には、プレナムチャンバ120は、使用時にシールが形成される領域において平均的な人の顔の表面輪郭に対して相補的である形状の縁部を有する。使用時において、プレナムチャンバ120の周辺縁部は、顔の隣接する表面に近接して位置決めされる。顔との実際の接触は、シール形成構造160によって提供される。シール形成構造160は、使用時においてプレナムチャンバ120の縁部全体の周りに延び得る。
好適には、本技術の患者インターフェース100のシール形成構造160は、使用時において位置決めおよび安定化構造130によって密閉位置において保持され得る。
一形態において、患者インターフェース100は、吐き出された二酸化炭素の押し出しを可能にするように構成および配置された通気部140を含む。本技術による一形態の通気部140は、複数の穴(例えば、約20個~約80個の穴または約40個~約60個の穴または約45個~約55個の穴)を含む。
図3Aは、内眼角、鼻翼、鼻唇溝、上唇および下唇、上唇紅および下唇紅ならびに口角点を含むヒトの顔の前面図を示す。また、口幅と、頭部を左部および右部に分割する矢状面と、方向インジケータとが図示される。方向インジケータは、ラジアル内方/外方および上方/下方方向を示す。図3Bは、眉間、セリオン、鼻筋、鼻尖点、鼻下点、上唇および下唇、スプラメントン、鼻翼頂上点、ならびに上耳底点および下耳底点を含むヒトの顔の側面図である。上方/下方および前方/後方方向を示す方向インジケータも図示される。図3Cは、鼻唇溝、下唇、上唇紅、鼻孔、鼻下点、鼻柱、鼻尖点、鼻孔の主軸および矢状面を含むいくつかの特徴を含む鼻の底面図である。
以下に、図3A~図3Cに示すヒトの顔のフィーチャをより詳細に説明する。
翼(Ala):外部の外壁または各鼻孔の「翼」(複数形:alar)
Alare:鼻翼上の最外側の点。
翼曲率(または鼻翼頂上)点:各翼の曲線状基準線における最後方点であり、翼および頬の結合によって形成される折り目において見受けられる。
耳介:耳の視認できる部分全体。
鼻柱:鼻孔を分離する皮膚片であり、鼻尖点から上唇へ延びる。
鼻柱角度:鼻孔の中点を通じて引かれる線と、鼻下点と交差しつつフランクフルト水平に対して垂直に引かれる線との間の角度。
眉間:軟組織中に配置され、前額部の正中矢状において最も顕著な点。
鼻孔(鼻穴):概して楕円体の翼穴であり、鼻腔への入口を形成する。鼻孔(nares)の単数形は鼻孔(naris)(鼻穴)である。これらの鼻孔は、鼻中隔によって分離される。
鼻唇溝または鼻唇折り目:皮膚の折り目または溝であり、鼻の各側から口腔の角部へ延びて、頬を上唇から分離させる。
鼻唇角:鼻柱と上唇との間の角度であり、鼻下点と交差する。
下耳底点:耳介の顔の皮膚への取り付けの最低点。
上耳底点:耳介の顔の皮膚への取り付けの最高点。
鼻尖点:鼻の最も突出した点または先端であり、頭部の部分の残り部分の側面図中に確認され得る。
人中:鼻中隔の下側境界から上唇領域中の唇の上部へ延びる正中線溝。
ポゴニオン:軟組織上に配置された、顎の最前方中点。
(鼻)堤:鼻堤は、鼻の正中線隆起であり、セリオンから鼻尖点へ延びる。
矢状面:前方(前)から後方(後)へ続く垂直面であり、本体を右半分および左半分に分割する。
セリオン:軟組織上に配置された、前頭鼻骨縫合の領域上の最も凹状の点である。
中隔軟骨(鼻):鼻中隔軟骨は、隔膜の一部であり、鼻腔の前部分を分割する。
鼻翼最下点:翼ベースの下側周縁における点であり、翼ベースは上(上)唇の皮膚と接合する。
鼻下点:軟組織上に配置され、鼻柱が正中矢状における上唇と合体する点。
スプラメントン:下唇中点と軟組織ポゴニオンとの間の下唇の正中線中の最も凹状の点。
下記に説明するように、図1中のマスク10などの患者インターフェースのサイズ決めの選択において用いられ得る顔からのいくつかの重要寸法がある。本例において、顔高さ、鼻幅および鼻深さを含む3つの寸法がある。図3A~図3Bに示す線3010は、顔高さを示す。図3Bから分かるように、顔高さは、セリオンからスプラメントンまでの距離である。図3A中の線3020は、左翼点と右翼点との間の鼻幅を示す。図3B中の線3030は、鼻深さを示す。
図4Aは、機械、空気圧式、および/または電気部品を含み、1つ以上のアルゴリズム(例えば全体的にせよ部分的にせよ本明細書に記載の方法のうちいずれか)を実行するように構成される本技術の一態様による例示的なRPTデバイスのコンポーネントの分解図を示す。図4Bは、RPTデバイス40の下部を示す。図4Cは、本技術の一態様に従ったRPTデバイス40の電気部品の概略図である。上流および下流の方向が、送風機および患者インターフェースに対して示される。任意の特定の瞬間における実際の流れ方向に関係無く、送風機は患者インターフェースの上流にあるものとして規定され、患者インターフェースは送風機の下流にあるものとして規定される。送風機と患者インターフェースとの間の空気圧経路内に配置されたアイテムは、送風機の下流および患者インターフェースの上流にある。RPTデバイス40は、例えば呼吸状態のうち1つ以上の治療のために患者の気道へ送達される空気流れを生成するように構成され得る。
RPTデバイス40は、外部ハウジング4010を持ち得る。外部ハウジング4010は、2つの部分(すなわち、上部4012および下部4014)によって形成される。さらに、外部ハウジング4010は、1つ以上のパネル(単数または複数)4015を含み得る。RPTデバイス40は、RPTデバイス40の1つ以上の内部コンポーネントを支持するシャーシ4016を含む。RPTデバイス40は、ハンドル4018を含み得る。
空気圧RPTデバイス40の空気圧経路は、1つ以上の空気経路アイテム(例えば、入口空気フィルタ4112、入口マフラー4122、空気を陽圧で供給することが可能な圧力生成器4140(例えば、送風機4142)、出口マフラー4124)ならびに1つ以上の変換器4270(例えば、圧力センサ4272、流量センサ4274、およびモータ速度センサ4276)を含み得る。
空気経路アイテムのうち1つ以上は、空気圧ブロック4020と呼ばれる取り外し可能な一体構造内に配置され得る。空気圧ブロック4020は、外部ハウジング4010内に配置され得る。一形態において、空気圧ブロック4020は、シャーシ4016によって支持されるかまたはシャーシ4016の一部として形成される。
RPTデバイス40は、電源4210、1つ以上の入力デバイス4220、中央コントローラ4230、圧力生成器4140、データ通信インターフェース4280、および1つ以上の出力デバイス4290を有することができる。治療デバイスには別のコントローラが設けられ得る。電気部品4200は、シングルプリント回路基板アセンブリ(PCBA)4202上に取り付けられ得る。一代替形態において、RPTデバイス40は、1つよりも多くのPCBA4202を含み得る。また、1つ以上の保護回路4250、トランスデューサ4270、データ通信インターフェース4280、および記憶装置など他の部品も、PCBA4202に搭載され得る。
RPTデバイスは、以下のコンポーネントのうち1つ以上を一体ユニット中に含み得る。一代替形態において、以下のコンポーネントのうち1つ以上が、それぞれの別個のユニットとして配置され得る。
本技術の一形態によるRPTデバイスは、空気フィルタ4110または複数の空気フィルタ4110を含み得る。一形態において、入口空気フィルタ4112は、圧力生成器4140の空気圧経路上流の始まり部に配置される。一形態において、出口空気フィルタ4114(例えば抗菌ファクタ)は、空気圧ブロック4020の出口と、患者インターフェース100との間に配置される。
本技術の一形態によるRPTデバイスは、マフラー4120または複数のマフラー4120を含み得る。本技術の一形態において、入口マフラー4122は、空気圧経路内において圧力生成器4140の上方に配置される。本技術の一形態において、出口マフラー4124は、空気圧経路内において圧力生成器4140と図1の患者インターフェース100との間に配置される。
本技術の一形態において、空気の流れまたは供給を陽圧において生成する圧力生成器4140は、制御可能な送風機4142である。例えば、送風機4142は、1つ以上のインペラを備えたブラシレスDCモータ4144を含み得る。インペラが、ボリュート内へ配置され得る。送風機は、空気供給の送達を例えば約120リットル/分までの速度で、約4cmH2O~約20cmH2Oの範囲の陽圧で、または他の形態において約30cmH2Oまで行うことができる。送風機については、以下の特許または特許出願のうちいずれか1つに記載があり得る。本明細書中、同文献全体を参考のため援用する。米国特許第7,866,944号、米国特許第8,638,014号、米国特許第8,636,479号およびPCT特許出願公開WO2013/020167。
圧力生成器4140は、治療デバイスコントローラ4240の制御下にある。他の形態において、圧力生成器4140は、ピストン駆動ポンプ、高圧源(例えば、加圧空気リザーバ)へ接続された圧力調節器、またはベローズであり得る。
本技術の一態様による空気回路4170は、使用時において加圧空気流れが2つのコンポーネント(例えば、加湿器60および患者インターフェース100)間に移動するように、構築および配置された導管またはチューブである。詳細には、空気回路4170は、加湿器60の出口および患者インターフェース100のプレナムチャンバ120と流体連通し得る。
本技術の一形態において、アンチスピルバック弁4160が、加湿器60と、空気圧ブロック4020との間に配置され得る。アンチスピルバック弁は、水が加湿器60から上流に(例えば、送風機のモータ4144へ)流れる危険性を低減させるように、構築および配置される。
電源4210は、RPTデバイス40の外部ハウジング4010の内部または外部に配置され得る。本技術の一形態において、電源4210は、RPTデバイス40にのみ電力を供給する。本技術の別の形態において、電源4210から、電力がRPTデバイス40および加湿器60双方へ提供される。
RTシステムは、RTシステム、その患者、および/またはその環境に関連する任意の数のパラメータのうちの1つ以上を測定するように構成された1つ以上のトランスデューサ(センサ)4270を備え得る。トランスデューサは、トランスデューサが測定するように構成された1つ以上のパラメータを表す出力信号を作り出すように構成され得る。
この出力信号は、電気信号、磁気信号、機械信号、視覚信号、光学信号、音信号など、当技術分野で公知である任意数の他の信号のうちの1つ以上であり得る。
トランスデューサは、RTシステムの他の部品と一体化され得、RPTデバイスにトランスデューサが内蔵されているのが1つの例示的な配置である。トランスデューサは、RTシステムの実質的に「スタンドアローン」の部品であり得、トランスデューサがRPTデバイスの外部にあるのが例示的な配置であろう。
トランスデューサは、その出力信号を、RPTデバイス、ローカル外部デバイス、またはリモートの外部デバイスなど、RTシステムの1つ以上の部品に伝達するように構成され得る。外部トランスデューサは、例えば、患者インターフェースや、スマートフォンなどの外部演算装置に所在し得る。外部変換器は、例えば空気経路上に配置してもよいし、あるいは空気経路の一部を形成してもよい(例えば、患者インターフェース)。
1つ以上の変換器4270は、空気の特性を示す信号(例えば、流量、圧力または温度)を生成するように、構築および配置され得る。空気は、RPTデバイスから患者への空気流れ、患者から大気への空気流れ、周囲の空気、またはその他であり得る。信号は、RPTデバイスと患者との間の空気圧経路における空気流れなど、特定の地点における空気流れの性質を表し得る。本技術の一形態において、1つ以上の変換器4270が、圧力生成器60の上流および/または下流に配置され得る。
本技術の一態様によれば、1つ以上のトランスデューサ4270は、空気圧経路と流体連通して所在する圧力センサを備える。適切な圧力センサの一実施例として、HONEYWELL ASDXシリーズからの変換器がある。別の適切な圧力センサとして、GENERAL ELECTRICからのNPAシリーズからの変換器がある。一実施形態において、圧力センサは、加湿器60の排出口に隣接する空気回路4170に所在する。
マイクロフォン圧力センサ4278が、空気回路4170内の圧力の変化を表す音信号を生成するように構成されている。マイクロフォン4278からの音信号は、以下に説明するアルゴリズムのうちの1つ以上によって構成されるとおり、音響処理および分析のために中央コントローラ4230によって受信され得る。マイクロフォン4278は、音に対する感度を高めるために空気経路に直接露出し得るか、可撓性膜材料の薄層の裏側に封入され得る。この膜は、マイクロフォン4278を熱および/または湿気から保護するように機能し得る。
圧力センサ4272、流量センサ4274、モータ速度センサ4276、およびマイクロフォン4278などのトランスデューサ4270からのデータが、中央コントローラ4230によって周期的に収集され得る。このようなデータは、RPTデバイス40の動作状態に主に関連する。本例において、中央コントローラ4230は、センサからのこのようなデータの符号化を専用データフォーマットにて行う。データ符号化は、標準化されたデータフォーマットにて行ってもよい。
本技術の一形態において、RPTデバイス40は、人間がデバイスと相互作用を可能にするためのボタン、スイッチまたはダイヤルの形態をとる1つ以上の入力デバイス4220を含む。ボタン、スイッチまたはダイヤルは、タッチスクリーンを介してアクセスすることが可能な物理的デバイスまたはソフトウェアデバイスであり得る。ボタン、スイッチまたはダイヤルは、一形態において外部ハウジング4010に物理的に接続させてもよいし、あるいは、別の形態において中央コントローラ4230と電気接続された受信器と無線通信してもよい。一形態において、入力デバイス4220は、人間が値および/またはメニュー選択肢を選択することを可能にするように、構築および配置され得る。
本技術の一形態において、中央コントローラ4230は、RPTデバイス40の制御に適した1つまたは複数のプロセッサである。適切なプロセッサは、ARM HoldingsからのARM(登録商標)Cortex(登録商標)-Mプロセッサに基づいたプロセッサであるx86INTELプロセッサを含み得る(例えば、ST マクロ電子からのS(登録商標)32シリーズのマイクロコントローラ)。本技術の特定の代替形態において、32ビットRISC CPU(例えば、ST MICRO電子SからのSTR9シリーズマクロコントローラ)または16ビットRISC CPU(例えば、TEXAS INSTRUMENTSによって製造されたマクロコントローラのMSP430ファミリーからのプロセッサ)も適切であり得る。本技術の一形態において、中央コントローラ4230は、専用電子回路である。一形態において、中央コントローラ4230は、特定用途向け集積回路である。別の形態において、中央コントローラ4230は、個別電子コンポーネントを含む。中央コントローラ4230は、1つ以上の変換器4270、1つ以上の入力デバイス4220および加湿器60から入力信号(単数または複数)を受信するように、構成され得る。
中央コントローラ4230は、出力信号(単数または複数)を出力デバイス4290、治療デバイスコントローラ4240、データ通信インターフェース4280および加湿器60のうち1つ以上へ提供するように、構成され得る。
本技術のいくつかの形態において、中央コントローラ4230は、本明細書中に記載の1つ以上の方法を具現するように、構成される(例えば、内部メモリ上の非一時的なコンピュータで読出可能な記録媒体の中に記録されたコンピュータプログラムとして表現された1つ以上のアルゴリズム)。本技術のいくつかの形態において、中央コントローラ4230は、RPTデバイス40と一体化され得る。しかし、本技術のいくつかの形態において、いくつかの方法が、遠隔配置されたデバイス(例えば、モバイル演算装置)によって行われ得る。例えば、遠隔配置されたデバイスは、記録されたデータ(例えば、本明細書中に記載のセンサのうちいずれかからのもの)の分析により、人工呼吸器の制御設定を決定し得るか、または、呼吸関連イベントを検出し得る。上記したように、外部ソースまたは中央コントローラ4230のデータおよび動作は全て、RPTデバイス40の製造業者専用であることが多い。そのため、センサからのデータおよび他の任意のさらなる動作データは、他の任意のデバイスからはアクセスできないことが多い。
本技術の1つの形態において、データ通信インターフェースが設けられ、中央コントローラ4230へ接続される。データ通信インターフェースは、遠隔外部通信ネットワークおよび/またはローカル外部通信ネットワークへ接続可能であり得る。遠隔外部通信ネットワークは、遠隔外部デバイス(例えば、サーバまたはデータベース)へ接続可能であり得る。ローカル外部通信ネットワークは、ローカル外部デバイス(例えば、モバイルデバイスまたは健康監視デバイス)へ接続可能であり得る。そのため、ローカル外部通信ネットワークは、他のデバイスからデータを収集する目的で、RPTデバイス40またはモバイルデバイスのいずれかによって使用され得る。
一形態において、データ通信インターフェースは、中央コントローラ4230の一部である。別の形態において、データ通信インターフェース4280は、中央コントローラ4230と別個であり、集積回路またはプロセッサを含み得る。一形態において、遠隔外部通信ネットワークはインターネットである。データ通信インターフェースは、インターネットへ接続するために、(例えば、イーサネット(登録商標)または光ファイバーを介して)有線通信を用い得るかまたは無線プロトコル(例えば、CDMA、GSM(登録商標)、2G、3G、4G/LTE Cat-M、NB-IoT、5G ニューラジオ、人工衛星、beyond 5G)を用い得る。一形態において、ローカル外部通信ネットワーク4284は、1つ以上の通信規格(例えば、ブルートゥース(登録商標)またはコンシューマー赤外線プロトコル)を用いる。
図4Cに示すように、例示的なRPTデバイス40は、集積型センサおよび通信電子装置を含む。旧型のRPTデバイスの場合、収集データの送信のために通信電子装置を含み得るセンサモジュールとのレトロフィットが可能であり得る。このようなセンサモジュールは、RPTデバイスへ取り付けられ得るため、動作データを遠隔分析エンジン130へ送信し得る。
開示の音響分析技術のいくつかの実行において、センサ(例えば、音声センサ4278)からの音声信号に基づいたケプストラム分析が実行され得る。音声信号は、ユーザの生理学的状態(例えば、睡眠または呼吸)ならびにRPTの動作データを反映し得る。ケプストラムは、例えば、デシベルスペクトルのフォワードフーリエ変換の対数スペクトルの逆フーリエ変換とみなされ得る。この操作により、インパルス応答関数(IRF)および音源の畳み込みを加算演算へ実質的に変換することができ、これにより、その後、音源を容易に考慮するかまたはIRFデータを分析のために分離させるように音源を除去することができ得る。ケプストラム分析の技術については、下記文献中に詳細な記載がある科学文献(名称:「The Cepstrum: A Guide to Processing」(Childersら、Proceedings of the IEEE, Vol. 65, No. 10,Oct 1977))およびRandall RB、Frequency Analysis, Copenhagen: Bruel & Kjaer, p. 344 (1977, revised ed. 1987)。呼吸治療システムコンポーネント特性へのケプストラム分析の適用について、PCT公開第WO2010/091462(名称:「Acoustic Detection for Respiratory Treatment Apparatus」)中に記載がある。本明細書中、同文献全体を参考のため援用する。
上記したように、呼吸治療システムは典型的には、RPTデバイス、加湿器、空気送達導管および患者インターフェースを含む(例えば、図1に示すコンポーネント)。多様な異なる形態の患者インターフェースが、所与のRPTデバイスと共に用いられ得る(例えば、鼻枕、鼻プロング、鼻マスク、鼻&口(口腔鼻)マスクまたはフルフェイスマスク)。さらに、異なる形態の空気送達導管が用いられ得る。患者インターフェースへの治療送達の制御向上のために、治療パラメータ(例えば、患者インターフェース中の圧力および通気流れ)の測定または推定が分析され得る。旧型のシステムにおいては、患者が利用しているコンポーネントの種類の判別は、患者にとって最適なインターフェースの決定のために以下のように行われ得る。いくつかのRPTデバイスにおいて、患者がシステムコンポーネントの種類(例えば、使用されている患者インターフェース)(例えば、ブランド、形態、モデル)を選択することを可能にするメニューシステムが含まれる。患者がコンポーネントの種類を入力すると、RPTデバイスは、選択されたコンポーネントと最適に協働する流れ生成器の適切な動作パラメータを選択することができる。RPTデバイスによって収集されたデータは、特定の選択されたコンポーネント(例えば、患者への加圧空気供給における患者インターフェース)の有効性の評価に用いられ得る。
この技術に含まれる分析方法によれば、その他のシステムノイズおよび応答(例を非限定的に挙げると、送風機音)からの音響マスクの反射の分離が可能になる。その結果、異なるマスクからの音響反射(これは、マスクの形状、構成および材料によって決まることが多い)間の差を特定することが可能になり、ユーザまたは患者の介入無しに異なるマスクを特定することが可能になり得る。
マスクを特定するための例示的方法として、マイクロフォン4278によって生成された出力音声信号y(t)のサンプリングを少なくともナイキスト速度(例えば、20kHz)において行い、サンプリング後の出力信号からケプストラムを計算した後、ケプストラムの反射コンポーネントをケプストラムの入力信号コンポーネントから分離させる方法がある。ケプストラムの反射コンポーネントは、入力音声信号のマスクからの音響反射を含むため、マスクの「音響署名」または「マスク署名」と呼ばれる。次に、音響署名を、事前規定されたデータベースまたは既知のマスクを含むシステムから得られた先行測定された音響署名の所定のデータベースと比較する。任意選択的に、適切な類似性の決定のために、一定の判定基準が設定される。1つの例示的実施形態において、上記比較は、測定および保存された音響署名間の相互相関における単一の最大データピークに基づいて完了され得る。しかし、このアプローチは、いくつかのデータピークの比較による向上も可能であり得、あるいは、これらの比較は、抽出されたケプストラムフィーチャの一意のセットについて完了される。
その後、本技術によれば、反射コンポーネントと関連付けられたデータは、前回特定されたマスク反射コンポーネント(例えば、マスク反射コンポーネントのメモリまたはデータベース中に含まれるもの)からの類似のデータと比較され得る。
上記したように、RPTデバイス40は、患者インターフェースの種類のデータおよび動作データを提供し得る。動作データをマスク種類および患者関連データと相関付けることにより、特定のマスク種類が有効であるかを決定することができ得る。例えば、動作データは、RPTデバイス40の使用時間および使用による治療有効性の有無双方を反映し得る。患者インターフェースの種類と、RPTデバイス40によって収集された動作データから決定されるような患者順守または治療有効性のレベルとが相関付けられ得る。相関データを用いることにより、類似のRPTデバイスからの呼吸治療を必要としている新規患者にとって有効なインターフェースがより効果的に決定され得る。この選択を新規患者の顔スキャンから得られた顔寸法と組み合わせることにより、インターフェースの選択が支援される。
よって、本技術によれば、RPTデバイス使用から収集されたデータの統合を、(スキャンプロセスによって決定された個々の患者の顔フィーチャを含む)患者集団による異なるマスクに関連して行うことにより、患者がマスクなどの患者インターフェースをより迅速かつ簡便に入手することが可能になる。スキャンプロセスにより、患者が自身の顔の解剖学的構造の測定を自宅から快適にコンピューティングデバイス(例えば、デスクトップコンピュータ、タブレット、スマートフォンまたは他のモバイルデバイス)を用いて迅速に行うことが可能になる。その後、コンピューティングデバイスは、患者の顔寸法の分析後の適切な患者インターフェースサイズと、異なるインターフェースに関連する全般的患者集団からの種類およびデータとについて推奨を受信し得る。顔のデータ収集は、事前保存された顔画像などの他の方法によって行ってもよい。このような顔データは、保存され、患者に関連する情報とRPTデバイスからの動作データと相関付けられる。
本例において、顔のデータ収集のために、製造業者またはサードパーティサーバから一体型カメラを備えたスマートフォンまたはタブレットへのダウンロードが可能なアプリケーションが用いられ得る。起動されると、アプリケーションから、視覚的命令および/音声命令が提供され得る。命令に従って、ユーザ(すなわち、患者)は、鏡の前方に立って、ユーザインターフェース上のカメラボタンを押圧し得る。次に、活性化されたプロセスは、ユーザの顔の一連の写真を撮影した後、例えば約2秒以内に、インターフェースの選択のための顔寸法を(プロセッサによる写真分析に基づいて)入手し得る。以下に述べるように、マスクの選択およびRPT40との使用の開始後は、このようなアプリケーションを用いて、フィードバックをユーザから収集することが可能になり得る。
ユーザ/患者は、自身の顔構造の1つの画像または一連の画像をキャプチャし得る。コンピュータにより読出可能な媒体上に保存されたアプリケーションから提供される命令が例えばプロセッサによって実行された場合、画像内の多様な顔のランドマークが検出され、当該ランドマーク間の距離が測定およびスケーリングされ、これらの距離がデータ記録と比較され、適切な患者インターフェースサイズが推奨される。よって、消費者の自動化デバイスにより、高精度の患者インターフェース選択を例えば自宅において行うことが可能になり得、顧客がサイズ決めを(訓練を受けた提携者の同席無しに)行うことが可能になり得る。
図5に示す例示的システム200は、患者インターフェースフィードバックデータを患者から収集する際に用いられ得る。システム200は、自動的な顔フィーチャ測定および患者インターフェースの選択も含み得る。システム200は、サーバ210、通信ネットワーク220およびコンピューティングデバイス230のうち1つ以上を主に含み得る。サーバ210およびコンピューティングデバイス230は、通信ネットワーク220を介して通信し得る。通信ネットワーク220は、有線ネットワーク222、無線ネットワーク224、または無線リンク226を備えた有線ネットワークデータであり得る。いくつかのバージョンにおいて、サーバ210は、コンピューティングデバイス230へ情報を提供することにより、コンピューティングデバイス230と一方向通信し得、またその逆も成り立つ。他の実施形態において、サーバ210およびコンピューティングデバイス230は、情報および/または処理タスクを共有し得る。システム200は、例えば患者インターフェース(例えば、図1中のマスク100)の自動化購入を可能にするように実行され得、ここで、プロセスにおいて、本明細書中により詳細に記載される自動サイズ決めプロセスが含まれ得る。例えば、顧客は、マスク選択プロセスを実行した後、マスクをオンラインデータ注文することができ得る。このマスク選択プロセスによれば、顧客の顔フィーチャの画像分析を他のマスクからの動作データならびに異なる種類およびサイズのマスクを利用している患者集団からのRPT動作データと組み合わせることにより、適切なマスクサイズが自動的に特定される。マスクが患者によって利用された後、システム200は、フィードバックデータを継続的に収集する。
サーバ210および/またはコンピューティングデバイス230は、呼吸治療デバイス(例えば、図1に示すRPT40に類似するRPT250)とも通信し得る。本例において、RPTデバイス250は、動作データ収集を患者の利用、マスク漏洩および他の関連データに関連して行って、マスク利用に関連してフィードバックを提供し得る。RPTデバイス250からのデータは、収集され、患者データベース260中のRPTデバイス250を用いて患者の個人患者データと相関付けられる。患者インターフェースデータベース270は、新規患者が利用することが可能な異なる種類およびサイズのインターフェース(例えば、マスク)についてのデータを含む。患者インターフェースデータベース270は、各種のマスクの音響署名データも含み得る。この音響署名データにより、呼吸治療デバイスから収集された音声データからのマスク種類の決定が可能になり得る。サーバ210によって実行されるマスク分析エンジンは、個人の顔寸法データからの有効なマスクサイズおよび形状と、RPTデバイス250によって収集された(患者集団全体を包含する)動作データからの対応する有効性との相関付けおよび決定のために用いられる。例えば、フィッティングが有効であることの証拠を挙げると、漏洩検出が最小であること、治療プラン(例えば、マスクオンの時間およびマスクオフの時間ならびにオンイベントおよびオフイベントの頻度)の最大順守、一晩における無呼吸数、AHIレベル、患者のデバイス上において用いられる圧力設定や規定の圧力設定がある。このデータは、新規患者の顔寸法データと相関付けられ得る。以下に述べるように、サーバ210は、データベース260中に保存された複数の患者ならびにデータベース270中に保存された対応するマスクサイズ種別データからデータを収集して、新規患者から収集されたスキャン顔寸法データに最良にフィットする最適なマスクと、顔の寸法、睡眠挙動データおよび新規患者に類似する人口統計データを有する患者について最良の動作データを達成したマスクとに基づいて適切なマスクを選択する。このようなデータは、患者がRPTデバイス250を用いて入力した主観的データの形態をとる追加フィードバックと、患者インターフェースまたはマスクに関連するRPTデバイス250からの動作データとによって補足される。
コンピューティングデバイス230は、デスクトップまたはラップトップコンピュータ232またはモバイルデバイス(例えば、スマートフォン234またはタブレット236)であり得る。図6は、コンピューティングデバイス230の一般的アーキテクチャ300を示す。コンピューティングデバイス230は、1つ以上のプロセッサ310を含み得る。コンピューティングデバイス230は、ディスプレイインターフェース320、ユーザ制御/入力インターフェース331、センサ340および/または1つ以上のセンサ(単数または複数)のためのセンサインターフェース、慣性測定ユニット(IMU)342および不揮発性メモリ/データ記憶装置350も含み得る。
センサ340は、1つ以上のカメラ(例えば、CCD電荷結合素子またはアクティブ画素センサ)であり得、コンピューティングデバイス230と一体化される(例えば、スマートフォン内またはラップトップ内に設けられたもの)。あるいは、コンピューティングデバイス230がデスクトップコンピュータである場合、デバイス230は、外部カメラ(例えば、図5に示すウェブカメラ233)との接続のためにセンサインターフェースを含み得る。本明細書中に記載の方法の支援に用いられ得る他の例示的センサは、コンピューティングデバイスと一体化されてもよいし、あるいはコンピューティングデバイスの外部に設けられてもよく、例を挙げると、3次元画像キャプチャのためのステレオカメラまたはレーザーもしくはストローブ/構造の光源からの反射光の検出が可能な光検出器がある。
ユーザ制御/入力インターフェース331により、ユーザは、コマンドの提供またはユーザへ提供されたプロンプトまたは命令への応答を行うことができる。これは、例えば、タッチパネル、キーボード、マウス、マイクロフォンおよび/またはスピーカーであり得る。
ディスプレイインターフェース320は、以下の表示のために、モニター、LCDパネルなどを含み得る。プロンプト、出力情報(例えば、顔測定またはインターフェースサイズの推奨)および他の情報(例えば、以下にさらに詳述するようなキャプチャ表示)。
メモリ/データ記憶装置350は、コンピューティングデバイスの内部メモリ(例えば、RAM、フラッシュメモリまたはROM)であり得る。いくつかの実施形態において、メモリ/データ記憶装置350は、コンピューティングデバイス230へリンクされた外部メモリ(例えば、SDカード、サーバ、USBフラッシュドライブまたは光ディスク)であってもよい。他の実施形態において、メモリ/データ記憶装置350は、外部メモリおよび内部メモリの組み合わせであり得る。メモリ/データ記憶装置350は、保存データ354と、特定のタスクを実行するようプロセッサ310に命令するプロセッサ制御命令352とを含む。保存データ354は、センサ340によって受信されたデータ(例えば、キャプチャ画像)と、アプリケーションのコンポーネント部分として提供された他のデータとを含み得る。プロセッサ制御命令352は、アプリケーションのコンポーネント部分として提供してもよい。
上記したように、顔画像は、モバイルコンピューティングデバイス(例えば、スマートフォン234)によってキャプチャされ得る。コンピューティングデバイス230またはサーバ210上において実行される適切なアプリケーションにより、適切なマスク選択の支援のために3次元の関連する顔データが得られ得る。このアプリケーションにおいて、任意の適切な顔スキャン方法が用いられ得る。このようなアプリケーションの例を以下に挙げる。the Capture (StandardCyborg) (https://www.standardcyborg.com/)、Scandy Proからのアプリケーション (https://www.scandy.co/products/scandy-pro)、Qianxun3d からのBeauty3D アプリケーション(http://www.qianxun3d.com/scanpage), Unre 3D FaceApp (http://www.unre.ai/index.php?route=ios/detail)およびBellus3Dからのアプリケーション (https://www.bellus3d.com/)。顔スキャンの詳細なプロセスにおいて、WO2017000031中に開示の技術が含まれる。本明細書中、同文献全体を参考のため援用する。
1つのそのようなアプリケーションとして、顔フィーチャの測定および/または患者データ収集360のためのアプリケーションがあり、モバイルデバイス(例えば、スマートフォン234および/またはタブレット236)へダウンロード可能である。アプリケーション360は、そのようなマスクからのフィードバック収集の向上のために、顔フィーチャおよび既にマスクを利用している患者のデータも収集し得る。コンピュータにより読出可能な媒体(例えば、メモリ/データ記憶装置350)上に保存され得るアプリケーション360は、顔フィーチャの測定および/または患者インターフェースのサイズ決めに関連する特定のタスクをプロセッサ310に行わせるためのプログラムされた命令を含む。このアプリケーションは、自動化方法のアルゴリズムによって処理され得るデータも含む。このようなデータを挙げると、以下にさらに詳述するようなデータ記録、基準フィーチャおよび補正係数がある。
アプリケーション360がプロセッサ310によって実行されると、患者の顔フィーチャが2次元画像または3次元画像を用いて測定され、得られた測定に基づいて、適切な患者インターフェースサイズおよび種別が例えば標準的サイズのグループから選択される。本方法は、以下の3つまたは4つの異なるフェーズを含むものとして主に特徴付けられ得る。キャプチャ前フェーズ、キャプチャフェーズ、キャプチャ後画像処理フェーズ、ならびに比較および出力フェーズ。
いくつかの場合において、顔フィーチャ測定のためのアプリケーションは、プロセッサ310を制御して、ディスプレイインターフェース320上に基準フィーチャを含む視覚表示を出力させ得る。ユーザは、例えばカメラを動かすことにより、このフィーチャを自身の顔フィーチャに隣接して位置決めし得る。次に、特定の条件(例えば、アライメント条件)が満たされた場合、プロセッサは、顔フィーチャの1つ以上の画像をキャプチャし、基準フィーチャと関連付けて保存し得る。これは、鏡の利用によって行われ得る。鏡は、表示された基準フィーチャおよびユーザの顔をカメラへ反射させる。次に、アプリケーションは、プロセッサ310を制御して画像内の特定の顔フィーチャを特定させ、両者間の距離を測定させる。次に、画像分析処理により、縮尺係数を用いて、画素カウント数であり得る顔フィーチャ測定を、基準フィーチャに基づいた標準マスク測定値へ変換することができ得る。このような値は、例えば、基準測定単位(例えば、メートルまたはインチ)と、マスクサイズ決めに適した単位で表現された値とであり得る。
さらなる補正係数が、これらの測定へ適用され得る。顔フィーチャ測定は、特定の患者インターフェース形態(例えば、鼻マスクおよびFFM)に合った異なる患者インターフェースサイズに対応する測定範囲を含むデータ記録と比較され得る。次に、推奨サイズが選択され得、比較(単数または複数)に基づいて推奨としてユーザ/患者へ出力され得る。このようなプロセスは、任意の好適なユーザの場所において快適に簡便に実行され得る。アプリケーションは、本方法を数秒以内に行い得る。一例において、アプリケーションは、本方法をリアルタイムで行う。
キャプチャ前フェーズにおいて、特に、プロセッサ310は、サイズ決め処理のための1つ以上の画像のキャプチャに適した条件の確立においてユーザを支援する。これらの条件のうちいくつかを挙げると、例えば、適切な照明およびカメラ方向ならびに(手で保持されているため不安定になっているコンピューティングデバイス230に起因する)動きボケがある。
ユーザは、コンピューティングデバイス230において自動測定およびサイズ決めを行うためのアプリケーションをサーバ(例えば、サードパーティアプリケーション保存サーバ)から自身のコンピューティングデバイス230上へ簡便にダウンロードすることができ得る。ダウンロードされると、このようなアプリケーションは、コンピューティングデバイスの内部の不揮発性メモリ(例えば、RAMまたはフラッシュメモリ)上へ保存され得る。コンピューティングデバイス230は、好適にはモバイルデバイス(例えば、スマートフォン234またはタブレット236)である。
ユーザがアプリケーションを起動させると、プロセッサ310は、ディスプレイインターフェース320を介して、患者に特定の情報(例えば、年齢、性別、体重および身長)を提供するよう患者をプロンプトし得る。しかし、プロセッサ310は、この情報の入力を任意のタイミングで(例えば、ユーザの顔フィーチャの測定後およびユーザがマスクをRPTと共に使用した後に)行うようユーザにプロンプトし得る。プロセッサ310は、チュートリアルも提示し得る。このチュートリアルは、音声利用によりおよび/または視覚的に提供され得る(例えば、ユーザにプロセス時における自身の役割を理解してもらう支援のためにアプリケーションによって提供されるもの)。プロンプトは、患者インターフェース種別(例えば、鼻またはフルフェース)の情報と、患者インターフェースの対象となるデバイスの種類とについての情報も必要とし得る。また、キャプチャ前フェーズにおいて、アプリケーションは、例えばユーザの顔のキャプチャ画像の受信後にかつ、機械学習技術に基づいてまたは人工知能を通じて、ユーザが既に収集した情報に基づいて、患者特有の情報を外挿し得る。他の情報も、以下に述べるように、インターフェースを通じて収集され得る。
ユーザが次に進む準備ができた状態は、ユーザ入力またはユーザ制御/入力インターフェース331を介したプロンプトに応答して示され得る。ユーザが次に進む準備ができた場合、プロセッサ310は、プロセッサ制御命令352の指示通りにセンサ340を起動させる。センサ340は好適には、モバイルデバイスの前方を向くカメラであり、ディスプレイインターフェース320と同じ側にモバイルデバイスに配置される。カメラは一般的には、2次元画像をキャプチャするように構成される。2次元画像をキャプチャするモバイルデバイスは、ユビキタスである。本技術では、ユーザが特殊な機器を入手する負担の必要性を回避するために、この遍在性を利用している。
センサ/カメラ340の起動とほぼ同時期に、プロセッサ310は、アプリケーションの指示通りに、キャプチャディスプレイをディスプレイインターフェース320上に提示する。キャプチャディスプレイは、カメラのライブアクションプレビュー、基準フィーチャ、目標設定ボックス、および1つ以上の状態インジケータまたはこれらの任意の組み合わせを含み得る。本例において、基準フィーチャは、ディスプレイインターフェース上の中央に表示され、ディスプレイインターフェース320の幅に対応する幅を有する。基準フィーチャの垂直位置は、基準フィーチャの上縁がディスプレイインターフェース320の最上縁に隣接するかまたは基準フィーチャの下縁がディスプレイインターフェース320の最下縁に隣接するようなものであり得る。ディスプレイインターフェース320の一部は、カメラライブアクションプレビュー324を表示する。カメラライブアクションプレビュー324は典型的には、(ユーザが正しい位置および方向にいる場合に)センサ/カメラ340によってリアルタイムでキャプチャされたユーザの顔フィーチャを示す。
基準フィーチャは、(所定の)コンピューティングデバイス230にとって既知のフィーチャであり、プロセッサ310がキャプチャ画像のスケーリングを行うことを可能にする基準フレームを提供する。基準フィーチャは好適には、ユーザの顔フィーチャまたは解剖学的フィーチャ以外のフィーチャであり得る。よって、画像処理フェーズ時において、基準フィーチャにより、特定のアライメント条件が満たされるタイミング(例えば、キャプチャ前フェーズ時)のプロセッサ310による決定が支援される。基準フィーチャは、クイックレスンポンス(QR)コード(登録商標)または公知の模範またはマーカーであり得、プロセッサ310へ特定の情報(例えば、スケーリング情報、方向および/またはQRコード(登録商標)の構造から任意選択的に決定され得る他の任意の所望の情報)を提供し得る。QRコード(登録商標)は、四角形または矩形の形状を有し得る。ディスプレイインターフェース320上に表示される際、基準フィーチャは、所定の寸法(例えば、ミリメートルまたはセンチメートル単位)を有する。寸法値は、アプリケーション中へコード化され得、適切なタイミングでプロセッサ310へ通信され得る。基準フィーチャ326の実際の寸法は、多様なコンピューティングデバイスによって異なり得る。いくつかのバージョンにおいて、アプリケーションは、コンピューティングデバイスモデルに対して特異的になるように構成され得る。すなわち、基準フィーチャ326の寸法は、特定のモデル上に表示される際、既知になっている。しかし、他の実施形態において、アプリケーションは、特定の情報(例えば、ディスプレイサイズおよび/またはズーム特性)をデバイス230から入手するようプロセッサ310に命令し得る。その結果、プロセッサ310は、スケーリングを介してディスプレイインターフェース320上に表示されるような基準フィーチャの現実世界/実際の寸法を計算することができる。それにもかかわらず、このようなコンピューティングデバイスのディスプレイインターフェース320上に表示されるような基準フィーチャの実際の寸法は、キャプチャ後画像処理の前に既知であることが多い。
基準フィーチャと共に、目標設定ボックスは、ディスプレイインターフェース320上に表示され得る。目標設定ボックスにより、ユーザが特定のコンポーネントを目標設定ボックス中のキャプチャディスプレイ322内において整合させることが可能になる。これは、画像キャプチャの成功において望ましい。
状態インジケータは、プロセスの状態に関する情報をユーザへ提供する。その結果、ユーザがセンサ/カメラの位置決めの主要調節を画像キャプチャの完了前に確実に行うことが支援される。
よって、ユーザがディスプレイインターフェース320を測定対象である顔フィーチャに対して平行に保持し、ユーザディスプレイインターフェース320を鏡または他の反射面へ提供すると、基準フィーチャは大きく表示され、カメラ/センサ340によってみられているリアルタイム画像上にオーバーレイされ、鏡によって反射される。この基準フィーチャは、ディスプレイインターフェース320の上部の近隣において固定され得る。この基準フィーチャは、少なくとも部分的にこのように大きく表示されるため、センサ340は、基準フィーチャを明確にみることができ、プロセッサ310は、フィーチャを容易に特定することができる。加えて、基準フィーチャは、ユーザの顔のライブビューにオーバーレイされ得るため、ユーザの混乱の回避が支援される。
ユーザに対するプロセッサ310からの命令は、位置ディスプレイインターフェース320を測定対象である顔フィーチャの面内に位置決めするために、ディスプレイインターフェース320を介して(コンピューティングデバイス230のスピーカーを介した)可聴命令によって行ってもよいし、あるいは、チュートリアルよりも時間的に先行して行ってもよい。例えば、ユーザは、ディスプレイインターフェース320が前方に対向しかつ測定対象である特定の顔フィーチャと整合されたユーザの顎の下側かまたはユーザの顎に対向してもしくはユーザの顎に隣接して配置されるように、ディスプレイインターフェース320を位置決めするよう命令され得る。例えば、ディスプレイインターフェース320は、セリオンおよびスプラメントン(suprementon)と面アライメントを保ちながら配置され得る。最終キャプチャされた画像が2次元である場合、面アライメントにより、基準フィーチャ326のスケールを顔フィーチャ測定へ等しく適用することが確実にできることの支援が得られる。この点について、鏡と、ユーザの顔フィーチャおよびディスプレイ双方との間の距離は、ほぼ同じである。
ユーザが鏡の前方に配置され、基準フィーチャを含むディスプレイインターフェース320が、測定対象の顔フィーチャと面アライメントを保持しつつおおまかに配置されると、プロセッサ310は、十分なアライメントの確保を支援するための特定の条件を確認する。アプリケーションによって確立され得る1つの例示的条件として、上記したように、進行のために、基準フィーチャ全体を目標設定ボックス328内において検出する必要がある点がある。プロセッサ310は、基準フィーチャ全体が目標設定ボックス内に配置されていないことを検出した場合、プロセッサ310は、画像キャプチャを禁止するかまたは遅延させ得る。次に、ユーザは、自身の顔をディスプレイインターフェース320と共に動かすことにより、ライブアクションプレビュー内に表示されているような基準フィーチャが目標設定ボックス内に配置されるまで平面性を維持し得る。これにより、画像キャプチャのための鏡に対する顔フィーチャおよびディスプレイインターフェース320の最適なアライメントが、支援される。
プロセッサ310が目標設定ボックス内の基準フィーチャ全体を検出すると、プロセッサ310は、コンピューティングデバイスのIMU342をデバイス傾斜角の検出のために読み出し得る。IMU342は、例えば加速度計またはジャイロスコープを含み得る。よって、プロセッサ310は、デバイス傾斜の評価を(例えば1つ以上の閾値との比較によって)行うことにより、デバイス傾斜が適切な範囲内にあることを確認することができ得る。例えば、コンピューティングデバイス230ならびに(その結果の)ディスプレイインターフェース320およびユーザの顔フィーチャが約+-5度以内においていずれかの方向に傾斜していると決定された場合、プロセスは、キャプチャフェーズに進み得る。他の実施形態において、カウント対象となる傾斜角は、約+-10度、+-7度、+-3度または+-1度内であり得る。過度の傾斜が検出された場合、望ましくない傾斜の修正のために、警告メッセージの表示または音声提供が行われ得る。これは、(特に前後方向における)過度の傾斜の回避または低減のためのユーザ支援において特に有用であり、過度の傾斜が修正されない場合、キャプチャされた基準画像のアスペクト比が不適切になることに起因して、測定誤差に繋がり得る。
アプリケーションによって制御された通りにプロセッサ310によりアライメントが決定されると、プロセッサ310は、キャプチャフェーズへ進む。キャプチャフェーズは、アライメントパラメータおよび他の任意の先行条件が満たされたときに自動的に行われると好適である。しかし、いくつかの実施形態において、ユーザは、キャプチャを行うようにとのプロンプトに応答して、キャプチャを開始してもよい。
画像キャプチャが開始すると、プロセッサ310は、(好適には1つよりも多くの画像である)複数の画像をセンサ340を介してキャプチャする。例えば、センサ340を介してプロセッサ310によってキャプチャされるのは、例えば約5~20個の画像、10~20個の画像または10~15個の画像である。キャプチャされる画像数は、時間に基づき得る。換言すると、キャプチャされる画像の数は、センサ340によって所定の時間間隔でキャプチャされ得る所定の解像度の画像の数に基づき得る。例えば、センサ340が1秒間に所定の解像度においてキャプチャすることのできる画像数が40個の画像であり、キャプチャの際の所定の時間間隔が1秒である場合、センサ340は、プロセッサ310により処理のために40個の画像をキャプチャする。画像数は、ユーザによって規定されてもよいし、検出された環境条件の人工知能または機械学習に基づいてサーバ210によって決定してもよいし、あるいは、意図される精度標的に基づいてもよい。例えば、高精度が必要である場合、より多数のキャプチャ画像が必要になり得る。処理のためには複数の画像をキャプチャすることが好適であるが、1個の画像も考えられ、高精度測定を可能にするための利用のために有用に用いられ得る。しかし、1個よりも多数の画像を用いると、平均測定が可能になる。その結果、誤差/不一致が低減し得、精度が向上し得る。これらの画像は、キャプチャ後の処理のために、プロセッサ310によってメモリ/データ記憶装置350の保存データ354中へ保存され得る。
画像のキャプチャ完了後、画像はプロセッサ310によって処理されて、顔フィーチャ/ランドマークが検出または特定され、両者間の距離が測定される。その結果得られる測定を用いて、適切な患者インターフェースサイズの推奨が行われ得る。あるいは、この処理を、送信されたキャプチャ画像を受信したサーバ210によっておよび/またはユーザのコンピューティングデバイス(例えば、スマートフォン)上において行ってもよい。処理は、プロセッサ310およびサーバ210の組み合わせによって行ってもよい。一例において、推奨される患者インターフェースサイズは、主にユーザの鼻幅に基づき得る。他の例において、推奨される患者インターフェースサイズは、ユーザの口寸法および/または鼻寸法に基づき得る。
アプリケーションによって制御されるようなプロセッサ310は、1つ以上のキャプチャ画像を保存データ354から取り出す。次に、これらの画像は、2次元キャプチャ画像を含む各画素の特定のために、プロセッサ310によって抽出される。次に、プロセッサ310は、特定の事前指定された顔フィーチャを画素配置構成内において検出する。
プロセッサ310による検出は、エッジ検出(例えば、Canny、Prewitt、Sobel、またはRobertのエッジ検出)を用いて行われ得る。これらのエッジ検出技術/アルゴリズムにより、画像キャプチャのために提示されるような患者の実際の顔フィーチャに対応する画素配置構成内の特定の顔フィーチャの場所の特定が支援される。例えば、エッジ検出技術によれば、先ず画像内のユーザの顔が特定され得、特定の顔フィーチャ(例えば、眼およびその境界、口およびその角部、左翼および右翼、セリオン、スプラメントン、眉間ならびに左鼻唇溝および右鼻唇溝)に対応する画像内の画素の場所も特定され得る。次に、プロセッサ310は、これらの顔フィーチャそれぞれの特定の画素場所(単数または複数)をマーク付け、タグ付けまたは保存し得る。あるいは、プロセッサ310/サーバ210によるこのような検出が成功しなかった場合、事前指定された顔フィーチャを人間のオペレータによって手動で検出およびマーク付け、タグ付けまたは保存してもよい。これらのキャプチャ画像は、プロセッサ310/サーバ210のユーザインターフェースを通じて視覚的アクセスが可能である。
これらの顔フィーチャの画素座標が特定されると、アプリケーションは、プロセッサ310を制御して、特定されたフィーチャのうち特定のものの間の画素距離を測定させる。例えば、この距離は、各フィーチャの画素数によって主に決定され得、スケーリングを含み得る。例えば、左翼と右翼との間の測定によって、鼻の画素幅および/またはセリオンおよびスプラメントン間の画素幅を決定することにより、顔の画素高さが決定され得る。他の例を挙げると、眼間の画素距離、口角部の間の画素距離、左鼻唇溝および右鼻唇溝の間の画素距離があり、口などの特定の構造のさらなる測定データが得られ得る。顔フィーチャ間のさらなる距離が、測定され得る。本例において、特定の顔の寸法が、患者インターフェース選択プロセスのために用いられる。
事前指定された顔フィーチャの画素測定が得られた後、これらの測定に対し、人体測定学的補正係数(単数または複数)が適用され得る。この補正係数の適用は、以下に述べるように、縮尺係数の適用の前または後に行われ得ることが理解されるべきである。人体測定学的補正係数により、自動化プロセスにおいて発生し得る誤差(これは、患者間において一貫して発生し得る)の修正が可能になる。換言すると、補正係数が無く、自動化プロセスを単独で用いた場合、患者間において一貫した結果は得られ得るものの、特定の量の誤ったサイズの患者インターフェースに繋がり得る。補正係数は、集団試験から経験的に抽出され得、補正形成により、真正の測定に近い結果へより近い結果が得られ、誤ったサイズ決めの低減または排除が支援される。各患者についての測定およびサイズ決めのデータが各コンピューティングデバイスからサーバ210へ通信されるにつれて、この補正係数の精度を経時的に精緻化または向上させることができる。サーバ210において、このようなデータをさらに処理することにより、補正係数の向上が可能になり得る。人体測定学的補正係数は、患者インターフェースの形態によっても異なり得る。例えば、FFMを探している特定の患者の補正係数は、鼻マスクを探している場合の補正係数と異なり得る。このような補正係数は、(例えば、マスク返品を監視し、交換用マスクと返品されたマスクとの間のサイズ差を決定することによる)マスク購入の追跡から導出され得る。
顔フィーチャ測定を患者インターフェースのサイズ決めへ適用するために、人体測定学的補正係数による修正または未修正に関係無く、これらの測定は、画素単位から画像キャプチャのために提示されるような患者の顔フィーチャ間の距離を実際に反映する他の値へスケーリングされ得る。基準フィーチャは、スケーリング値(単数または複数)の入手のために用いられ得る。よって、プロセッサ310は、基準フィーチャの寸法を同様に決定する(例えば、基準フィーチャ全体の画素幅および/または画素高さ(xおよびy)の測定(例えば、画素カウント数))。QRコード(登録商標)基準フィーチャならびに/または基準フィーチャおよびその構成部分によって占有される画素領域を含む多数の四角形/点の画素寸法のより詳細な測定も、決定され得る。よって、QRコード(登録商標)基準フィーチャの各四角形または点は、各点の画素測定に基づいて縮尺係数を決定するために画素単位で測定され得、その後、測定された四角形または点全ての平均が計算され得、その結果、QRコード(登録商標)基準フィーチャの全体サイズの単一の測定と比較して縮尺係数の精度が向上し得る。しかし、基準フィーチャがどのように測定されるにしろ、これらの測定を用いて、基準フィーチャの画素測定を対応する既知の寸法の基準フィーチャへスケーリングすることができ得ることが理解されるべきである。
基準フィーチャの測定がプロセッサ310によって行われた後、アプリケーションによって制御されるように、縮尺係数がプロセッサ310によって計算される。基準フィーチャの画素測定は、基準フィーチャの既知の対応する寸法に関連する(例えば、変換または縮尺係数を得るための、画像キャプチャのためにディスプレイインターフェース320によって表示されるような基準フィーチャ326)。このような縮尺係数は、長さ/画素または領域/画素A2の形態をとり得る。換言すると、既知の寸法(単数または複数)は、対応する画素測定(単数または複数)(例えば、カウント(単数または複数))によって除算され得る。
次に、プロセッサ310は、縮尺係数を顔フィーチャ測定(画素カウント数)へ適用して、マスクサイズ決めに適した患者の実際の顔フィーチャ間の距離を反映するように、測定を画素単位から他の単位へ変換する。この変換においては、典型的には、例えば、縮尺係数と、マスクサイズ決めに関連する顔フィーチャに関する距離(単数または複数)の画素カウント数との乗算が行われ得る。
セット中の各画像の顔フィーチャ測定がスケーリングおよび/または修正されるまで、顔フィーチャおよび基準フィーチャ双方のためのこれらの測定ステップおよび計算ステップを各キャプチャ画像に対して繰り返す。
次に、1組の画像の収集およびスケーリングされた測定は、プロセッサ310によって任意選択的に平均化されて、患者の顔の解剖学的構造の最終測定が得られる。このような測定は、患者の顔フィーチャ間の距離を反映し得る。
比較および出力フェーズにおいて、キャプチャ後画像処理フェーズからの結果は、対象者へ直接出力(表示)してもよいし、あるいは、データ記録(単数または複数)と比較して、患者インターフェースサイズの自動推奨を得てもよい。
測定全てが決定された後、結果(例えば、平均)が、プロセッサ310によってディスプレイインターフェース320を介してユーザへ表示され得る。一実施形態において、これにより、自動化プロセスは終了され得る。ユーザ/患者は、ユーザによるさらなる使用のために、これらの測定を記録し得る。
あるいは、最終測定を自動的にまたはユーザのコマンドによってコンピューティングデバイス230から通信ネットワーク220を介してサーバ210へ転送してもよい。サーバ210またはサーバ側の個人が、さらなる処理および分析を行って、適切な患者インターフェースおよび患者インターフェースサイズを決定し得る。
さらなる実施形態において、患者の実際の顔フィーチャ間の距離を反映する最終顔フィーチャ測定が、プロセッサ310により、例えばデータ記録中の患者インターフェースサイズデータと比較される。このデータ記録は、顔フィーチャの自動測定および患者インターフェースのサイズ決めのためのアプリケーションの一部であり得る。このデータ記録の例として、例えばプロセッサ310からのアクセスが可能なルックアップテーブルがあり、一定範囲の顔フィーチャの距離/値に対応する患者インターフェースサイズを含み得る。複数の表が、データ記録中に含まれ得、そのうち多くは、特定の形態の患者インターフェースおよび/または製造業者から提供される特定のモデルの患者インターフェースに対応し得る。
患者インターフェースの選択のための例示的プロセスにより、上記方法によってキャプチャされた顔画像から主要ランドマークが特定される。本例において、潜在的インターフェースへの初期相関において、顔のランドマーク(例えば、図3A~図3B中の線3010、3020および3030によって示されるような顔高さ、鼻幅および鼻深さ)が含まれる。これら3つの顔ランドマーク測定は、例えばルックアップテーブルまたは上記した表を通じた適合するマスクのサイズ選択を支援するために、アプリケーションによって収集される。
上記したように、マスクの選択後またはある患者のためのマスクの詳細な製造後に、各RPTの動作データが、患者の大集団について収集され得る。これは、各患者がRPTを操作する時期に基づいた利用データを含み得る。そのため、順守データ(例えば、患者がRPTを所定の期間にわたって利用する時間の長さおよび頻度)を、収集された動作データから決定することができ得る。漏洩データは、動作データから決定され得る(例えば、流量データまたは圧力データの分析)。音響信号分析を用いたマスク切換データを導出して、マスクを切り換えているかを決定することができ得る。RPTは、内部音声センサまたは外部音声センサ(例えば、図4B中のマイクロフォン4278)および上記したようなケプストラム分析の組み合わせに基づいてマスク種類を決定するように、動作可能であり得る。あるいは、旧型のマスクの場合、動作データを用いて、収集された音響データと既知のマスクの音響署名との相関を通じてマスクの種類を決定することができ得る。
本例において、フィードバックデータの患者入力の収集は、コンピューティングデバイス230またはスマートフォン234上において実行されるユーザアプリケーションを介して行われ得る。ユーザアプリケーションは、顔のランドマークフィーチャまたは別個のアプリケーションを入手するようユーザへ命令するユーザアプリケーション360の一部であり得る。これは、質問表を介して得られた主観的データも含み得る。この質問表には、以下が含まれる。快適性の選好についてのデータの収集のための質問、患者が口呼吸者であるかまたは鼻呼吸者であるか(例えば、「起床時に口内が乾いていますか?」などの質問)、およびマスク材料の選好(例えば、シリコーン、発泡体、織物、ゲル)。例えば、患者入力の収集は、患者インターフェースの快適性に関連した主観的質問に対するユーザアプリケーションを介した患者の応答を通じて、行われ得る。他の質問は、関連するユーザ挙動(例えば、睡眠特性)に関連し得る。例えば、主観的な質問に含まれ得る質問を以下に挙げる。起床時に口内が乾いていますか?、あなたは口呼吸者であるか?、またはあなたの快適性選好を教えて下さい。このような睡眠情報を挙げると、睡眠時間、ユーザの睡眠様態、外部要素(例えば、温度、ストレス要素)がある。主観的データは、快適性またはより詳細な反応についての単純な数値評価であってもよい。このような主観的データは、グラフィカルインターフェースから収集してもよい。例えば、インターフェースからの漏洩を選択するには、選択されたインターフェースの図示部分をユーザに選択してもらい、収集することができ得る。収集された患者入力データは、図6中の患者データベース260へ割り当てられ得る。患者からの主観的入力データは、マスク設計に関するフィードバックおよび今後に参照されるフィーチャとして用いられ得る。他の主観的データが、患者の心理的安全性に関連して収集され得る。例えば、質問(例えば、患者が特定のマスクについて閉所恐怖症を感じるか、または、患者がマスクを装着した状態で同床者と共に居る際に心理的に快適に感じるか)をして、入力を収集することができ得る。
他のデータソースが、RPT利用外のデータのうち特定のマスクに相関付けられ得るデータを収集し得る。そのようなデータを挙げると、患者人口統計データ(例えば、年齢、性別または場所);患者が経験している睡眠無呼吸のレベルを示すAHI重症度。他のデータとして、RPTデバイスの新規患者のための規定圧力設定があり得る。
マスク選択後、システム200は、RPT250からの動作データ収集を引き続き行う。収集されたデータは、データベース260および270へ追加される。新規患者からのフィードバックを用いて、マスク選択肢の向上のために推奨内容を精緻化することができ得る。例えば、推奨マスクに高レベルの漏洩があることが動作データから決定された場合、別の種類のマスクを患者へ推奨することができ得る。フィードバックループを通じて、特定のマスクに最適である可能性のある特定の態様の顔のジオメトリの学習のために、選択アルゴリズムが精緻化され得る。この相関を用いて、当該顔ジオメトリを備えた新規患者に対するマスク推奨を精緻化することができ得る。よって、収集されたデータおよび相関付けられたマスク種類データにより、マスクの選択および設計の判定基準のさらなる更新が可能になり得る。よって、本システムにより、患者のためのマスクの選択または設計の向上のためのさらなる知見が得られ得る。
マスク選択に加えて、本システムによれば、呼吸治療の有効性および順守に関連したマスク選択の分析も可能になり得る。このようなさらなるデータにより、フィードバックループを通じたデータに基づいた呼吸治療の最適化が可能になる。
機械学習の適用により、マスク種類/特性間の相関の提供と、呼吸治療に対する順守の向上とが可能になり得る。これらの相関は、新規マスク設計のための特性の選択または設計に用いられ得る。このような機械学習は、サーバ210によって実行され得る。マスク分析アルゴリズムは、好適な動作結果および入力(例えば、患者の人口統計、マスクのサイズおよび種類、ならびに患者から収集された主観的データ)の出力に基づいた訓練用データセットを用いて学習され得る。機械学習を用いて、所望のマスク特性と、予測入力(例えば、顔の寸法、患者人口統計、RPTデバイスからの動作データ、および環境条件)との間の相関を発見することができ得る。機械学習において、ニューラルネットワーク、クラスタリングまたは従来の回帰技術などの技術が用いられ得る。試験データを用いて、異なる種類の機械学習アルゴリズムを試験し、相関予測に関連して最良の精度を有するものを決定することができ得る。
最適なインターフェースの選択のためのモデルは、図5中のシステムからの新規入力データによって継続的に更新され得る。よって、分析プラットフォームの利用拡大により、モデルの高精度化が可能になり得る。
上記したように、図5中のシステムの1つの部分は、RPTを利用している患者に対するインターフェースの推奨に関連する。システムの第2の機能として、フィードバックデータ収集プロセスがある。このプロセスは、将来のマスク設計または調節のためのデータを収集する。患者に対して推奨されるマスクが提供され、患者がそのマスクを一定期間(例えば、2日間、2週間、または別の期間)にわたって使用した後、システムは、RPT利用を監視し、他のデータを収集し得る。この収集されたデータに基づいて、(漏洩、順守低下または不満足なフィードバックを示す好ましくないデータから決定されるように)マスク性能が高レベルではない場合、システムは、マスク選択を再評価して、データベース260および機械学習アルゴリズムを患者の結果と共に更新し得る。次に、システムは、新規の収集データに適した新規マスクを推奨し得る。例えば、音響署名または他のセンサからのデータから比較的高い漏洩流量が決定された場合、REM睡眠時に患者の口が開いている可能性がある。その場合、(初期に選択された鼻専用またはより小型のフルフェイスマスクではなく)異なる種類のインターフェース(例えば、フルフェイスマスク)が必要であることを示し得る。
本システムは、満足なフォローアップデータに応答して、推奨を調節することもでき得る。例えば、動作データにおいて、選択されたフルフェイスマスクからの漏洩が無いことが示された場合、ルーチンは、より小型のマスクを試してみるよう推奨し得る。順守の最大化のために、スタイル、材料、バリエーション、患者選好との相関間のトレードオフが用いられ得、推奨のフォローアップが可能になり得る。個々の患者におけるトレードオフは、アプリケーションから患者へ表示される入力ツリーを通じて決定され得る。例えば、患者が潜在的問題のメニューから皮膚刺激が問題である旨を示した場合、特定の刺激発生箇所としてのデータを患者から収集するために、顔画像上の潜在的刺激の場所の図示が表示され得る。この特定のデータにより、特定の患者に最適なマスクへの相関の向上が可能になり得る。
本プロセスにより、フィードバックデータの収集と、顔フィーチャデータとの相関とが可能になり、他のマスクの設計のためのデータをマスク設計者へ提供することができる。顔のデータを収集するアプリケーション360またはコンピューティングデバイス(例えば、図5中のコンピューティングデバイス230またはモバイルデバイス234)によって実行される別のアプリケーションの一部として、マスクに関連するフィードバック情報が収集され得る。
アプリケーション360は、初期患者情報を収集し得、データ(例えば、パスワード設定)の保護のためのセキュリティ手段を提供し得る。患者がアプリケーションを設定し、アプリケーション360を特定の患者の識別情報と相関付けた後、アプリケーションは、フィードバックデータを収集し得る。
患者について顔のデータが既に収集されている場合、アプリケーション360は、他のデータの収集に進む。当該患者について以前収集された顔データが無い場合、アプリケーション360は、顔のデータ収集に関する選択肢を患者へ提供する。図7Aにおいて、アプリケーションのインターフェース700上に、顔画像710が示されている。患者は、マスク選択について上記した顔スキャンプロセスと同様の顔画像710をキャプチャし得る。顔画像710の表示後、顔メッシュが生成され得る。図7Bに示す第2のインターフェース720は、顔画像710から生成された顔メッシュ712を表示する。次に、顔データは、顔メッシュ710から導出および保存され得、図5中のデータベース260への保存対象としてサーバ210へ送信され得る。
アプリケーション360は、表示された他のインターフェースを通じた患者からのマスク設計のための特性評価のために、全ての関連データを収集する。図7Cに示す睡眠データ収集インターフェース730により、睡眠の質に関連する主観的な患者データの収集が可能になる。このデータは、収集され得、上記したRPTによって収集された客観的睡眠データまたは関連動作データと相関付けられ得る。インターフェース730は、睡眠位置に関連する質問732を含む。インターフェース730には、ユーザに選択してもらう選択肢(例えば、背中選択734、腹部選択736および横向き選択738)が含まれる。ユーザが選択に確信を持てない場合、ユーザは、「分からない」の選択肢740を選択し得る。よって、インターフェース730は、特定のユーザと相関付けられた睡眠位置データを収集する。
図7Dに示す別の睡眠インターフェース750は、睡眠種別を収集するために表示される。インターフェース750は、睡眠種別についての質問752を含む。インターフェース750は、「浅い睡眠」の選択754、「中程度の睡眠深さ」の選択756、および「深い睡眠」の選択758を含む選択をユーザに対して含む。ユーザが選択に確信を持てない場合、ユーザは、「分からない」の選択肢760を選択し得る。よって、インターフェース750は、特定のユーザと相関付けられた睡眠種別データを収集する。
アプリケーション360は、患者によって利用される現在のマスクについての情報も収集する。図8Aは、鼻専用または鼻および口用のマスクの選択を含むインターフェース800である。よって、ユーザは、鼻専用のマスクの選択802または鼻および口用のマスクの選択804を選択する。本例において、選択802および804は、マスク種類の説明のための有用な図示を含む。この選択により、製造業者およびマスクモデルに対して特異的なさらなるインターフェースが決定される。患者による選択が為された後、図8Bに示すマスクブランド選択インターフェース810が表示され、これにより、患者がマスクのブランドを選択することを可能になる。インターフェース810は、製造業者Aの選択812、製造業者Bの選択814、製造業者Cの選択816、および製造業者Dの選択818を含む。アプリケーションにより、製造業者A~Dそれぞれの全マスクモデルへのアクセスが可能になり、この情報が後続インターフェースへ提供されて、選択された製造業者A~Dの特定のマスクの選択が可能になる。
図8Cは、マスクモデルの選択のためのインターフェース820を示す。インターフェース820における選択は、図8B中のインターフェース810中において選択された製造業者によって決定される。インターフェース820は、製造業者から提供される各適用可能なモデルについての選択(例えば、選択822、824、826および828)を羅列する。
マスクモデルの選択後、アプリケーション360は、図8Dに示すようなマスクのクッションサイズを決定するためのインターフェース830を表示する。インターフェース830は、図8C中のインターフェース820から選択されたマスクのモデルの図解画像832を含む。図解画像832は、マスクのサイズを決定する場所をユーザへ示す。インターフェース830は、小サイズ選択834、中サイズ選択836、および大サイズ選択838を含む。
あるいは、アプリケーション360は、マスクの得られた図解画像を分析し、この画像を既知のマスクモデルに関連する識別用データと比較することにより、マスク識別を行うようにプログラムされてもよい。図9Aに示す命令インターフェース900は、マスクの自動的な視覚的識別を得るための選択肢を提供する。図9Bに示す写真インターフェース910により、マスクの画像912のキャプチャが可能になる。図9Cに示す写真インターフェース920は、マスクのキャプチャ画像912を示す。
アプリケーション360は、使用されているマスクを決定するためのデータを収集するインターフェースも含む。図9D中の短期利用インターフェース930は、直近30日間のマスク使用についての質問932を表示することにより、マスクが単回使用用途のものであるかを決定する。インターフェース930は、ユーザが前回選択したマスクモデルの図示を表示し得る。ユーザは、「はい」の選択934または(他のマスクが使用されていることを示す)選択無し936を選択し得る。アプリケーション360は、以前のマスクについてのデータを収集するための入力も提供し得る。
図9Eに示す長期使用インターフェース940は、マスク使用に関連する質問942の表示により、マスクが唯一のものであるかを決定する。インターフェース940は、ユーザが前回選択したマスクモデルの図示を表示し得る。ユーザは、「はい」の選択944または(他のマスクが使用されていることを示す)選択無し946を選択し得る。
アプリケーション360は、患者からの快適性フィードバックデータも決定し得る。図10Aに示すインターフェース1000は、マスク不快感が少しでもあるかを決定する。質問1002が表示されて、マスクから少しでも不快感を感じるかについて患者が尋ねられる。患者は、「いいえ」の選択肢1004または「はい」の選択肢1006を選択し得る。
患者が「はい」の選択肢1006を選択した場合、視覚的不快感識別インターフェース1010が図10Bに示すように表示される。インターフェース1010は、顔フィーチャの画像1020を表示する。画像1020は、患者の性別または他の特性に応じて包括的顔画像から選択され得る。あるいは、画像1020は、個人の顔画像であり得、その場合、(アプリケーション320によって取得された場合は)ポータブルコンピューティングデバイス上に保存してもよいし、患者の以前取得された顔画像からデータベースからアクセスしてもよい。マスクの形状をした場所グリッド1022が、患者の顔画像1020へオーバーレイされる。選択リスト1024が表示される。選択リスト1024は、例えば、以下の5つの潜在的不快感領域を記述する。a)鼻梁、b)鼻上側、c)鼻の下側/角部、d)口の側部/角部、およびe)顎/下唇。場所グリッド1022は、患者による不快感領域の発見を支援するために、リスト1024中に記述される領域に対応する5つの領域1030、1032、1034、1036および1038を規定する線を含む。これらの領域1030、1032、1034、1036および1038はそれぞれ、顔とマスクとの間の接触領域を示す。ユーザは、1つ以上の不快感領域をリスト1024から選択し得る。次に、不快感のリストと、グリッド1022中の対応する領域とが強調表示される。本例において、場所マスクは、フルフェイスマスクに対して特異的であるが、他の種類のマスク(例えば、クレードル型マスク)は、異なる場所グリッド1022と共に、マスクの種類に対して特異的である異なる不快感領域を有し得る。
図10Cは、患者が不快感領域を選択した際のインターフェース1010の例を示す。本例において、患者は、リスト1024中から鼻上側を選択している。そのため、この選択が強調表示される。鼻上側を示すグリッド1022の領域1032も強調表示されることにより、不快感領域が顔画像1020に相対して示される。
アプリケーション360は、患者からの漏洩フィードバックデータも決定し得る。図10Dに示すインターフェース1050は、マスクと顔との間のシールにおいて少しでも空気漏れが無いかを決定する。質問1052を表示して、マスクからの漏洩を少しでも経験しているかについて患者に尋ねる。患者は、「いいえ」の選択肢1054または「はい」の選択肢1056を選択し得る。
患者が「はい」の選択肢1056を選択した場合、視覚的不快感識別インターフェース1060が、図10Eに示すように表示される。インターフェース1060は、患者の画像1070を表示する。画像1070は、アプリケーション320によって取得された場合はポータブルコンピューティングデバイス上に保存され得るか、または、患者の以前取得された顔画像からのデータベースからアクセスされ得る。マスク形状をとる場所グリッド1072が、患者の顔画像1070にオーバーレイされる。選択リスト1074が表示されて、以下の5つの潜在的空気漏れ領域を記述する。a)鼻梁、b)鼻上側、c)鼻の下側/角部、d)口の側部/角部、およびe)顎/下唇。場所グリッド1072は、リスト1074中に記載の上記に対応する5つの領域1080、1082、1084、1086および1088を規定する線を含むことにより、マスクと(顔とマスクとの間の接触領域を示す)領域1080、1082、1084、1086および1088内の自身の顔との間の漏洩を患者が発見することを支援する。ユーザは、1つ以上の不快感領域をリスト1074から選択し得る。次に、不快感リストは、グリッド1072中の対応する領域と共に強調表示される。
図10Fは、患者が不快感領域を選択した際のインターフェース1060の例を示す。本例において、患者は、リスト1074中の「鼻上側」を選択している。そのため、この選択が強調表示される。グリッド1072の領域1082も強調表示されるため、この不快感領域は、顔画像1070に相対して表示される。
図11Aに示すインターフェース1100は、空気漏れによる影響についての主観的フィードバックデータを患者から収集する。ユーザが図10E中のインターフェース1050から「はい」の選択肢1056を選択した場合、インターフェース1100が表示される。インターフェース1100に含まれる質問1102により、空気漏れに困っているレベルを数値スケール入力で表すよう患者に依頼する。インターフェース1100には、0(困っていない)~10(大変困っている)の範囲のスケール1104が含まれる。患者は、スライダー1106を選択し得る。スライダー1106は、インターフェース1100’の画像に示すように、スケールからの数値入力を表示する。他の質問(例えば、顔上の特定の領域または区域における不快感に関連する質問)のために、他の類似のインターフェースが提供され得る。
図11Bに示すインターフェース1150は、現在のマスクに対する患者の満足度についての主観的フィードバックデータを患者から収集する。インターフェース1150に含まれる質問1152により、特定のマスクモデルを推奨するかについて当該マスクの数値評価をするよう患者に依頼する。インターフェース1150には、0(可能性はあまり無い)~10(極めて高い可能性)の範囲のスケール1154が含まれる。患者は、スライダー1156を選択し得る。スライダー1156は、インターフェース1150’の画像に示すように、スケールからの数値入力を表示する。
図11Cは、患者人口統計データの収集のために表示され得る例示的インターフェース1160である。インターフェース1160は、年齢選択フィールド1162、性別選択フィールド1164および人種フィールド1166を含む。よって、患者は、フィールド1162、1164および1166を用いて、自身の年齢、性別および人種のデータを入力することができ得る。このデータは、患者人口統計に関連するマスク設計の分析の支援のために、収集され得る。
図11Dは、例示的な模式図であり、生成されたインターフェース中のマスク種類の選択に応じて不快感および空気漏れについて収集するために挿入されて、例えば図10Bに示すような不快感の決定または例えば図10Cに示すような漏洩の決定のために用いられる。図11Dに示す一連の5個の異なるオーバーレイ図示1170、1172、1174、1776および1178は、異なるマスクの形状を示す。例えば、オーバーレイ図示1170、1176および1178は、異なる種類の鼻専用マスクを示す。オーバーレイ図示1172および1174は、異なる種類のマスクおよび鼻マスクを示す。ユーザによるマスク選択に基づいて、適切な図示1170、1172、1174、1776および1178が挿入される。
図12は、本明細書中に記載の例示的アプリケーション360を通じて収集されたデータの樹形図1200を示す。入力1210により、ユーザの状況に1番近いものを選択するようリクエストする。入力1210は、ベンダーにより製造されたマスクのユーザ1212と、サードパーティにより製造されたマスクのユーザ1214と、現在マスクがまだ無いユーザ1216とを含み得る。ユーザが自分がベンダーにより製造されたマスクのユーザであるかまたはサードパーティにより製造されたマスクのユーザであるかを特定した場合、入力1220により、マスクが鼻または鼻および口を被覆しているかを決定する。次に、データ収集において、睡眠位置1222に関連するデータが収集される。現在使用しているマスクは無い旨をユーザが示した場合、ルーチンは、睡眠位置1222に関連するデータを直接収集する。入力1224により、ユーザが両腕を頭よりも高く上げることが難しいかについてのデータを収集する。入力1226において、ユーザが鼻呼吸が難しいかについて決定する。入力1228において、ユーザが鼻の乾燥に困っているかを決定する。入力1230において、ユーザが閉所恐怖症があるかを決定する。入力1232において、ユーザが顔用クリームを夜間に使うかを決定する。
性別が異なれば、異なる顔フィーチャも異なるため、入力1234において、ユーザの性別を決定する。ユーザは、男性または女性を選択し得る。ユーザが回答を拒否した場合、入力1236において、ユーザの生誕時の性別を決定する。ユーザは、男性、女性または回答拒否と回答し得る。ユーザが入力1234または1236に対して男性と回答した場合、入力1238において、ユーザが顔上に毛を有するかを決定する。次に、ルーチンは、以下を含む性別に関する1組の一般的質問を提示する。顔または皮膚に刺激を受けやすいかに関連する入力1240、入力1242(ユーザが眼鏡をかけているか)、入力1244(ユーザに同床者はいるか)、入力1246(ユーザがマスク1248を着用したときの外観を気にするか)、および入力1250(ユーザが入眠に困難があるか)。上記したように、収集されたデータを用いて、ユーザにとって適切なマスクを推奨または選択することができ得る。収集されたデータを他のユーザ固有のデータと共にカテゴリ分けまたは相関付けることもでき、これにより、特定の患者サブ集団または一般的患者集団に関連する新規マスク設計についてのガイドラインを得ることができ得る。
例えば、患者入力データは、特定の領域(例えば、鼻上側)におけるマスク漏洩を示し得る。この漏洩は、RPTデバイスからの動作データを通じて確認することができ得る。次に、このデータは、鼻上側に関連する顔データと相関付けられ得る。分析を行って、鼻上側とインターフェースをとるマスク縁部を漏洩最小化のために長尺化することにより、マスクの寸法を変更することができ得る。別の例として、患者入力データが、「鼻上側にマスクを載せた際に不快感を感じる」旨を示す場合がある。次に、このデータは、鼻上側に関連する顔データと相関付けられ得る。分析を行って、鼻上側とインターフェースをとるマスク縁部を漏洩最小化のために短尺化することにより、マスクの寸法を変更することができ得る。もちろん、このようなデータを、不快感または漏洩の低減のために異なるサイズまたは種類のマスクを推奨するためにヘルスケアプロバイダへ提供してもよい。あるいは、このデータを用いて、患者が最初に選択したマスクを患者に合わせて個別調整されたものへ変更してもよい。
上記アプリケーションから収集された患者データおよびさらなるデータ(例えば、図5中のRPTデバイス250からの動作データ)は、ユーザにとって向上したインターフェースの設計支援のためのデータ処理ステップにおいて流用または処理され得る。スキャンされた顔の鏡画像(表面トポグラフィー)を用いて、マスクなどのインターフェースを生成することができ得る。しかし、このような患者インターフェースは必ずしも理想的ではないことがある。なぜならば、顔上のシーリング領域の特定の領域において、異なるレベルのシーリング力が必要になり得るか、高ヘッドギア圧力に対してより高感度になるか、または、複雑な顔のジオメトリに起因して当該場所における漏洩の可能性がより高くなるからである。このような性能および快適性に関連する微細な詳細をさらなる処理において考慮に入れることにより、より最適なマスク設計に繋がる。
一例において、変形状態のジオメトリの直接的測定ができないかまたは変形状態のジオメトリが利用不可能である場合、弛緩状態データの収集からの弛緩状態ジオメトリのデータを用いて、変形状態のジオメトリの表示を試行および提供することができ得る。シミュレーションソフトウェアを弛緩データ後処理において用いて、変形状態をシミュレートすることができ得る。適切なシミュレーションソフトウェアの例を非限定的に挙げると、弛緩データ中の「弛緩」から「変形」への状態ジオメトリデータの変換を行うANSYSがある。
さらなる顔画像を取得することにより、顔のジオメトリの弛緩状態および変形状態を決定することができ得る。ジオメトリデータの「弛緩」状態および「変形」状態双方を得ることにより、有限要素ソフトウェア(例えば、ANSYS)を用いて、患者インターフェース接触領域と患者の顔との間に発生する(シミュレーションにおいて発生する圧力における)おおよその圧力値を計算することができ得る。あるいは、圧力データを圧力マッピングを介して別個に収集してもよい。よって、弛緩状態データの収集から、変形ジオメトリおよび発生圧力の推定が可能になり得る。
ジオメトリデータまたは圧力データのいずれかである測定データにより、特定のフィーチャ処理において、特別な考慮を必要とする患者の顔上の領域またはフィーチャの決定および対処が可能になり得る。任意選択的に、任意の組み合わせの測定ソースからのデータにより、ジオメトリデータセットおよび圧力データセット双方を含む包括的モデルが得られ得るため、設計の快適性、有効性および順守を提供する目的がさらに達成される。
顔は、静的表面ではない。すなわち、顔は、外部条件(例えば、患者インターフェースからの力、顔上の空気圧力および重力)との相互作用に合わせて順応および変化する。これらの相互作用を考慮に入れることにより、患者に最適なシールおよび快適性が提供されるというさらなる恩恵が得られる。3つの例により、この処理を示す。
第1に、これらの患者インターフェースを着用しているユーザはCPAP圧力を経験するため、この知識を患者インターフェースの快適性およびシーリングの向上のために用いることができ得る。シミュレーションソフトウェアを既知の特性(例えば、軟組織特性または弾性係数)と共に用いることにより、患者インターフェース内における特定の空気圧力における顔表面の変形の予測を支援することができ得る。
以下の顔の場所のうちいずれかに関連する集団について、組織特性が既知であり得、収集され得る。眉間上部、眉間、鼻根点、鼻端部、人中、上唇縁部、下唇縁部、顎唇溝、オトガイ隆起、下顎底、前方隆起、眼窩上、眉間側部、側鼻、眼窩下、下頬部、鼻孔側部、鼻唇堤、上犬歯(supra canina)、下犬歯(sub canina)、オトガイ結節ant.、眼窩外側中間、関節窩上、頬骨、外側、supra-M2、咬筋中間、咬合線、sub-m2、ゴニオン、および中間下顎角度。
例えば、軟組織厚さは、以下の顔フィーチャのうち少なくとも1つについての人体測定学データベースから既知である。例えば、ナジオン(nasian)、鼻端部、人中、顎唇溝、オトガイ隆起、眼窩下、下頬部、鼻孔側部、鼻唇堤、上犬歯(supra canina)および下犬歯(sub canina)。特定の場所(例えば、眼窩下、下頬部、鼻孔側部、鼻唇堤、上犬歯(supra canina)および下犬歯(sub canina))が、顔の両側に配置される。
これらの場所のうち任意の1つ以上における既知の組織特性は、以下のうち任意の1つ以上を含み得る。軟組織厚さ、力に基づいたモジュラスデータ、撓み、モジュラスおよび厚さ、軟組織厚さ比情報、ならびにボディー・マス・インデックス(BMI)。
第2に、患者の顔上の皮膚表面は、CPAP患者インターフェースが顔上にストラップ掛けされた際に大きく変形する。弛緩状態における頭部および顔のジオメトリ表面の初期3D測定を用いると、上記した皮膚/軟組織特性の知識およびシミュレーションソフトウェアによる表面変化の予測が可能になり得る。このような技術は、反復的な最適化プロセスであり、設計プロセスと共に用いられ得る。
第3に、睡眠位置に来たとき、皮膚表面は、重力に起因して移動し得る。これらの変化を皮膚特性および軟組織特性の知識ならびにシミュレーションソフトウェアを用いて予測すれば、多様な睡眠位置におけるよりロバストかつ快適な高性能の患者インターフェースの設計の支援に繋がり得る。直立から仰向けへのジオメトリ変化に関連するデータを、1つ以上の顔の対象領域(例えば、ナジオン(nasian)、鼻端部、人中、顎唇溝、眼窩下、鼻孔側部、鼻唇堤、上犬歯(supra canina)および下犬歯(sub canina))から収集および利用することができ得る。
有限要素分析(FEA)ソフトウェア(例えば、ANSYS)は、インターフェース接触領域とユーザの顔との間に発生するおおよその圧力値を計算するために用いられ得る。一形態において、入力に含まれ得るものとして、「弛緩」状態および「変形」状態における顔ジオメトリ、顔の多様な場所における特性(例えば、測定された弾性係数、または(剛性などの特性が既知である)サブ構造)がある。このような入力を用いて、顔の有限要素(FE)モデルの構築が可能になり得、その後、この有限要素(FE)モデルを用いて、入力(例えば、変形または負荷)に対する顔の1つ以上の応答を予測することができ得る。例えば、顔のFEモデルを用いて、患者インターフェースにおける所与の圧力レベル(例えば、15cmH2O)における顔形状を予測することができ得る。いくつかの形態において、FEモデルは、患者インターフェースモデルまたはその一部(例えば、クッション)をさらに含み得、患者インターフェースモデルまたはその一部は、クッションジオメトリおよびその特性(例えば、弾性係数などの機械的特性)を含む。このようなモデルは、(例えばCPAP圧力付加に起因して内部負荷がクッションへ付加された際の)クッション変形と、その結果発生するクッションと顔との間の相互作用(例えば、両者間の負荷/圧力、顔の変形)とを予測することができ得る。詳細には、弛緩状態と変形状態との間の各点における距離変化を対応する組織特性と共に用いることにより、所与の点(例えば、頬骨において)発生する圧力を予測することができ得る。
顔上の特定の領域またはフィーチャにおいては、特別な考慮が必要になり得る。これらのフィーチャの特定および調節により、インターフェースの全体的快適性が向上し得る。上記したデータ収集技術および推定技術から、適切なフィーチャをカスタム患者インターフェースへ適用することができ得る。
上記した圧力感度、圧力順守、剪断感度および剪断順守インジケータに加えて、顔の毛、髪型および極端な顔のランドマーク(例えば、顕著な鼻梁、削げた頬)へ特別な考慮が付与され得る。本明細書中用いられるように、「剪断感度」とは、患者が感じる剪断を指し、「剪断順守」とは、患者の皮膚が剪断と共に平滑に移動するかまたは剪断に対して順守的であるかのレベルを指す。
図13に示すフィードバックデータ収集ルーチンは、患者によるインターフェースの初期選択後に特定の期間(単数または複数)にわたって実行され得る。例えば、フォローアップルーチンが、インターフェースおよびRPTの使用の最初の2日間にわたって実行され得る。図13中のフロー図は、異なる患者種別に合わせて最適化された呼吸圧力治療のインターフェース特性を選択するためにフィードバックデータを収集および分析せよとの例示的な機械可読命令を示す。本例において、機械可読命令は、以下によって実行されるアルゴリズムを含む。(a)プロセッサ、(b)コントローラ、および/または(c)1つ以上の他の適切な処理デバイス(単数または複数)。アルゴリズムは、有形媒体(例えば、フラッシュメモリ、CD-ROM、フロッピー(登録商標)ディスク、ハードドライブ、デジタルビデオ(バーサタイル)ディスク(DVD)または他のメモリデバイス)上に保存されたソフトウェア中に埋設され得る。しかし、当業者であれば、アルゴリズム全体および/またはその一部を、プロセッサ以外のデバイスによって実行しおよび/またはファームウェアまたは専用ハードウェア中に周知の様態で埋設してもよい(例えば、これは、特定用途向け集積回路[ASIC]、プログラマブル論理デバイス[PLD]、フィールドプログラマブル論理デバイス[FPLD]、フィールドプログラマブルゲートアレイ[FPGA]、個別論理によって実行され得る)ことを理解する。例えば、インターフェースのコンポーネントのうちいずれかまたは全てを、ソフトウェア、ハードウェアおよび/またはファームウェアによって実行することができる。また、フローチャートによって示される機械可読命令のうちいくつかまたは全てを手動で実行してもよい。さらに、例示的なアルゴリズムについて図13中に示すフローチャートを参照して述べているが、当業者であれば、例示的な機械可読命令を実行するための他の多数の方法も用いられ得ることを容易に理解する。例えば、ブロックを実行する順序を変更し、および/または記載のブロックのうちいくつかを変更、除去または組み合わせてもよい。
以下に述べるように、図13中のルーチンにより、インターフェースの異なる特性(例えば、顔の領域と接触する領域)の設計変更についての推奨が得られ得る。このデータにより、例示的な機械学習駆動型の相関エンジンの連続的更新が可能になり得る。
ルーチンにおいて、先ず、患者についての顔データが収集されているか(1310)を決定する。顔データが収集されていない場合、ルーチンアプリケーション360を起動させて、ユーザの顔スキャンを上記したアプリケーションを実行するモバイルデバイス(例えば、図5中のモバイルデバイス234(1312))を用いて行うようリクエストする。
顔画像データの収集(1312)後または顔データが既に前回のスキャンから保存されている場合、ルーチンは、RPTからの(1つの設定期間(例えば、2日間の使用)における)収集動作データへアクセスする(1314)。もちろん、2日間よりも長期または短期の他の適切な期間を、RPTからの動作データおよび他の関連データの収集期間として用いてもよい。例えば、図2中のシステムは、2日の使用からの順守的な客観的データ(例えば、使用時間またはRPT250からの漏洩データ)を収集し得る。
加えて、主観的フィードバックデータ(例えば、シール、快適性、一般的な好き嫌い)を、コンピューティングデバイス230によって実行されるユーザアプリケーション360のインターフェースから収集することができ得る(1316)。上記したように、主観的データは、患者への質問を提供するインターフェースを介して収集され得る。よって、主観的データは、不快感または漏洩および心理的安全性の質問(例えば、患者がマスクに対して心理的に快適であるか)に関連する回答を含み得る。他のデータが、顔画像に関連してマスクの視覚表示に基づいて収集され得る。
次に、ルーチンは、客観的データおよび主観的データを選択されたマスク種類および患者の顔スキャンデータと相関付ける(1318)。結果が良好である場合、ルーチンは、動作データが高順守と、低漏洩と、患者からの良好な主観的な結果データとを示していると決定する(1320)。次に、ルーチンは、データベースおよび学習アルゴリズムを成功したマスク特性またはフィーチャとして相関データと共に更新する(1322)。結果が良くない場合、ルーチンは、相関データも分析し、マスク特性の調節によって結果を向上させることができるかを決定する(1324)。次に、ルーチンは、この分析に従った特性の変更を提案する(1326)。例えば、ルーチンは、漏洩の検出または報告を回避するために、マスクのうち鼻と接合する部分を肉厚にすることを提案し得る。次に、ルーチンは、データベースおよび学習アルゴリズムの更新により、結果を保存する(1322)。
図14に示す例示的生成システム1400は、図5中のデータ収集システム200からの収集データに基づいて変更されたインターフェースを生成する。サーバ210は、RPTデバイス1410の集団からの収集された動作データと、アプリケーション230によって患者1412の集団から収集された主観的データとを分析モジュール1420へ提供する。
分析モジュール1420は、1つ以上の異なる製造業者の異なるモデルのマスクに関連するデータを含むインターフェースデータベース270へのアクセスを含む。分析モジュール1420は、患者集団の1つのサブグループによって用いられる特定の患者またはインターフェースにおけるインターフェースの特性またはフィーチャに対して変更の提案を提供する機械学習ルーチンを含み得る。例えば、収集された動作および患者入力データを顔画像データと共に分析モジュール1420へ入力することにより、マスク設計の新規特性が得られ得る。製造データ(例えば、既存のマスク設計のCAD/CAMファイル)が、データベース1430中に保存される。変更された設計は、分析モジュールによって生成され、製造システム1440へ通信されて、寸法、サイズ決め、材料などの変更を用いたマスクが生成される。本例において、製造システム1440は、マスク生成のために、ツーリングマシン、成形機、3D印刷システムなどを含み得る。
付加製造よりもカスタムコンポーネントの製造方法をより効率的にするために、製造システム1440中の成形ツールの試作(例えば、3D印刷)を変更された変更に基づいて高速に行うことができる。いくつかの例において、高速の3次元印刷によるツーリングにより、少量の製造方法のコスト効果の向上が可能になり得る。アルミニウムおよび/または熱可塑プラスチック製の軟質ツールも可能である。軟質ツールにより、少量の成形部品が可能になり、鋼製ツールよりもコスト効果が高くなる。
カスタムコンポーネントの製造時において、硬質ツーリングを用いてもよい。好適な量のインターフェースが収集されたフィードバックデータに基づいて生成される場合、硬質ツーリングが望ましい場合がある。硬質ツールは、成形プロセス/機械加工プロセス時において用いられる多様なグレードの鋼または他の材料によって構成され得る。製造プロセスは、患者インターフェースのコンポーネントのうちいずれかの作製のために、高速プロトタイプ、軟質ツールおよび硬質ツールの任意の組み合わせの使用も含み得る。ツールの構造も、例えばツーリングの種類のうちいずれかまたは全てを用いたツールそのものにおいて異なり得る。すなわち、部分のより包括的なフィーチャを規定し得るツールの1/2を硬質ツーリングによって構成し、カスタムコンポーネントを規定するツールの残り1/2を高速プロトタイプまたは軟質ツーリングから構築することができ得る。硬質ツーリングまたは軟質ツーリングの組み合わせも可能である。
同一コンポーネント内においてインターフェースを有するインターフェースの場合、他の製造技術は、マルチショット射出成形も含み得る。例えば、患者インターフェースクッションは、患者インターフェースの異なる領域において、異なる材料または異なる軟質グレードの材料を含み得る。熱成形(例えば、真空形成)を用いてもよく、その場合、例えば、プラスチックシートが加熱され、これらのシートは、ツールモールド上に真空引きされた後、モールドの形状をとるまで冷却され得る。これは、カスタム鼻孔カバーのコンポーネント成形のための実行可能な選択肢である。さらに別の形態において、カスタマイズされた患者インターフェースフレーム(または他の任意の適切なコンポーネント(例えば、ヘッドギアまたはその一部(例えば、リジダイザ)))の生成のために、初期に可鍛性であり得る材料が用いられ得る。本明細書中に記載の1つ以上の技術を用いて患者の「雄」モールドが生成され得、この「雄」モールド上に可鍛性の「テンプレート」コンポーネントを配置することにより、患者に適したコンポーネントの形状を作製することができ得る。次に、カスタマイズされたコンポーネントを「硬化」させることにより、これらのコンポーネントが可鍛性状態にならないようにすることができ得る。このような材料の一例として、特定の温度になるまでは初期可鍛性を有し(その後は、不可逆的に硬化される)熱硬化性ポリマーまたは特定の温度を超えると可鍛性になる熱軟化性プラスチック(熱可塑プラスチックとも呼ばれる)があり得る。カスタム布地織り/ニッティング/形成を用いてもよい。この技術は、プラスチックではなく糸を用いている点を除いて、3次元印刷プロセスに類似する。テキスタイルコンポーネントの構造を編むことにより、カスタムヘッドギア作製に理想的な任意の3次元形状を持たせることができ得る。
本出願で使用される「部品」、「モジュール」、「システム」などの用語は、ハードウェア(例えば、回路)、ハードウェアとソフトウェアの組み合わせ、ソフトウェア、または1つ以上の具体的な機能を有する動作機械に関するエンティティのいずれかであるコンピュータ関連エンティティを概して指す。例えば、部品は、プロセッサ(例えば、デジタル信号プロセッサ)上で実行される処理、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および/またはコンピュータであり得るが、これらに限定されない。例として、コントローラと、コントローラ上で動作するアプリケーションの両方が部品であり得る。1つ以上の部品が、プロセスおよび/または実行スレッド内に存在し得、ある部品が、1台のコンピュータ上でローカライズされたり、2台以上のコンピュータ間で分散されたりし得る。さらに、「デバイス」は、特別に設計されたハードウェア、具体的な機能の実行を可能にするソフトウェアの実行によって特殊化された被汎用化ハードウェア、コンピュータ可読媒体に記憶されたソフトウェア、またはこれらの組み合わせの形態をとることができる。
本明細書中に用いられる用語は、特定の実施形態を説明することのみを目的とし、本発明を限定するものではない。本明細書で使用している単数形「a」、「an」、および「the」は、文脈から明らかな場合を除き、複数形も含むことが意図されている。さらに、発明を実施するための形態および特許請求の範囲において、「含む」、「有する」、またはそれらの活用形が使用されており、これらの用語は、「備える」という用語と同様に包括的であることが意図されている。
以下の請求項1~28のうちいずれかの1つ以上からの1つ以上の要素、態様またはステップもしくはその一部(単数または複数)をその他の請求項1~28のいずれかの1つ以上もしくはその組み合わせからの1つ以上の要素、態様またはステップもしくはその一部(単数または複数)と組み合わせることにより、本開示の1つ以上のさらなる実行および/または請求項を形成することができ得る。
本開示について1つ以上の特定の実施形態または実行を参照して説明してきたが、当業者であれば、本開示の意図および範囲から逸脱すること無く多数の変更が可能であり得ることを認識する。これらの実行およびその明確な変更例はそれぞれ、本開示の意図および範囲に収まるものとして企図される。本開示の態様に従ったさらなる実行または代替的実行において、本明細書中に記載の実行(例えば、以下に述べる代替的実行におけるもの)のいずれかからの任意の数のフィーチャが組み合わされ得ることも企図される。