JP2018196760A - 医療デバイスの無線制御のためのデバイス、方法およびシステム - Google Patents

Abstract

【課題】医療デバイスの無線制御のためのデバイス、方法およびシステムを提供する。【解決手段】医療デバイスシステムは、デバイス８００、遠隔インターフェース８０２を含み、遠隔インターフェースは、ディスプレイアセンブリ８０４およびユーザ入力を受信する、少なくとも１つの入力アセンブリ８０６を含む。更に、遠隔インターフェースは、デバイスとの間に確立された無線通信チャネル８０８を介して、デバイスに命令する、および／または情報をデバイスから受信するように構成される。【選択図】図８

Description

本開示は、医療デバイスに関し、より具体的には、少なくとも１つの医療デバイスを制
御するためのシステムに関する。

生物学的製剤を含む、多くの潜在的に貴重な薬剤または化合物は、吸収率の悪さ、肝代
謝、または他の薬剤動態学的要因により、経口で有効ではない。加えて、いくつかの治療
化合物は、経口で吸収することができるが、頻繁に投与されることを必要とすることがあ
り、患者が所望のスケジュールを維持することは困難である。このような場合、非経口送
達がしばしば採用されるか、または採用することができる。

皮下注射、筋肉内注射、および静脈内（ＩＶ）投与等の、薬剤送達ならびに他の流体お
よび化合物の効果的な非経口経路は、針またはスタイレットによる皮膚の穿刺を含む。イ
ンスリンは、何百万人もの糖尿病患者によって自己注射される、治療流体の実施例である
。非経口送達された薬剤のユーザは、ある期間にわたって必要な薬剤／化合物を自動的に
送達する装着タイプデバイスから利益を享受し得る。

この目的を達成するために、治療薬の制御された放出のための携帯タイプかつ装着タイ
プのデバイスを設計する取り組みが行われてきた。そのようなデバイスは、カートリッジ
、シリンジ、またはバッグ等のリザーバを有すること、および電子的に制御されることが
知られている。これらのデバイスは、誤動作率を含む、多数の欠点を抱えている。これら
のデバイスのサイズ、重量、および費用を削減することも、継続的課題である。加えて、
これらのデバイスはしばしば、皮膚に適用し、適用のための頻繁な再配置という課題をも
たらす。

単一ユーザにとって、複数の医療デバイスを同時に管理することは、課題を呈する。そ
の１つとして、ハードウェアが挙げられ、多くの医療デバイスの場合、専用インターフェ
ースを含み、無線で制御される医療デバイスに対する、複数の「コントローラ」または「
ハンドヘルド」は、論理的課題を呈する。第１に、種々のインターフェースが、１つのイ
ンターフェースから別のインターフェースおよびマスタに注意を向けることは困難であり
得る。第２に、複数のデバイスを再充電することは、課題を呈し得、第３に、複数のコン
トローラとともに、医療デバイスを搬送することは、課題を呈する。

本発明の一側面によると、医療デバイスシステムが、開示される。医療デバイスシステ
ムは、第１の医療デバイスおよび第２の医療デバイスを含む。システムはまた、タッチス
クリーンを含む、遠隔インターフェースを含む。遠隔インターフェースは、第１の医療デ
バイスおよび第２の医療デバイスと無線通信する。遠隔インターフェースは、ユーザイン
ターフェースを第１の医療デバイスおよび第２の医療デバイスに提供するように構成され
る。遠隔インターフェースは、タッチスクリーンを通して、ユーザ入力を受信するように
構成される。また、充電デバイスも、含まれる。充電デバイスは、少なくとも第１の医療
デバイスおよび遠隔インターフェースを受容するように構成され、充電デバイスは、第１
の医療デバイスバッテリを再充電するように構成され、充電デバイスは、遠隔インターフ
ェース内のインターフェースバッテリを再充電するように構成される。充電デバイスは、
パーソナルコンピュータに接続され、パーソナルコンピュータは、情報を遠隔インターフ
ェースに提供する。

本発明の本側面のいくつかの実施形態は、以下のうちの１つ以上を含んでもよい。第１
の医療デバイスは、注入ポンプである。第１の医療デバイスはさらに、少なくとも１つの
使い捨て部分および少なくとも２つの再使用可能部分を含み、２つの再使用可能部分はそ
れぞれ、少なくとも１つの使い捨て部分に接続するように構成される。充電デバイスは、
第１の医療デバイスの少なくとも２つの再使用可能部分のうちの少なくとも１つを受容す
るように構成される。第２の医療デバイスは、少なくとも１つの送信機を備える、持続的
グルコースモニタシステムであって、少なくとも１つの送信機は、遠隔インターフェース
と無線通信する。システムはさらに、遠隔インターフェースと無線通信する、第３の医療
デバイスを含む。遠隔インターフェースは、ユーザインターフェースを第３の医療デバイ
スに提供するように構成される。第３の医療デバイスは、少なくとも１つの血中グルコー
スメータである。システムではさらに、無線通信は、無線周波数通信である。第１の医療
デバイスおよび遠隔インターフェースは、近距離通信を使用してペアリングされる。およ
び／または遠隔インターフェースは、少なくとも１つのカメラをさらに備える。

本発明の一側面によると、医療デバイスシステムが、開示される。医療デバイスシステ
ムは、第１の医療デバイスと、第１の医療デバイスと無線通信する、第２の医療デバイス
とを含む。システムはまた、タッチスクリーンを含む、遠隔インターフェースを含む。遠
隔インターフェースは、第１の医療デバイスと無線通信し、遠隔インターフェースは、ユ
ーザインターフェースを第１の医療デバイスおよび第２の医療デバイスに提供するように
構成される。遠隔インターフェースは、タッチスクリーンを通して、ユーザ入力を受信す
るように構成される。システムはまた、第１の医療デバイスおよび遠隔インターフェース
を受容するように構成される、充電デバイスを含む。充電デバイスは、第１の医療デバイ
スバッテリを再充電するように構成され、かつ充電デバイスは、遠隔インターフェース内
のインターフェースバッテリを再充電するように構成される。充電デバイスは、パーソナ
ルコンピュータに接続され、パーソナルコンピュータは、情報を遠隔インターフェースに
提供する。

本発明の本側面のいくつかの実施形態は、以下のうちの１つ以上を含んでもよい。第１
の医療デバイスは、注入ポンプである。第１の医療デバイスはさらに、少なくとも１つの
使い捨て部分および少なくとも２つの再使用可能部分を含み、２つの再使用可能部分はそ
れぞれ、少なくとも１つの使い捨て部分に接続するように構成される。充電デバイスは、
第１の医療デバイスの少なくとも２つの再使用可能部分のうちの少なくとも１つを受容す
るように構成される。第２の医療デバイスは、少なくとも１つの送信機を含む、持続的グ
ルコースモニタシステムを含み、少なくとも１つの送信機は、第１の医療デバイスと無線
通信する。第２の医療デバイスは、第１の医療デバイスと無線通信する、血中グルコース
メータを含む。第１の医療デバイスおよび遠隔インターフェースは、近距離通信を使用し
てペアリングされる。第１の医療デバイスおよび第２の医療デバイスは、近距離通信を使
用してペアリングされる。

本発明の一側面によると、注入ポンプシステムが、開示される。注入ポンプシステムは
、注入ポンプの少なくとも１つの使い捨て部分と、注入ポンプの少なくとも２つの再使用
可能部分であって、注入ポンプの２つの再使用可能部分はそれぞれ、少なくとも１つの使
い捨て部分に接続するように構成される、再使用可能部分とを含む。システムはまた、タ
ッチスクリーンを含む、遠隔インターフェースを含み、遠隔インターフェースは、少なく
とも２つの再使用可能部分のうちの少なくとも１つと無線通信し、遠隔インターフェース
は、ユーザ指示を少なくとも２つの再使用可能部分のうちの少なくとも１つに提供するよ
うに構成され、遠隔インターフェースは、タッチスクリーンを通して、ユーザ入力を受信
するように構成される。システムはまた、少なくとも２つの再使用可能部分および遠隔イ
ンターフェースのうちの少なくとも１つを受容するように構成される、充電デバイスを含
む。充電デバイスは、少なくとも２つの再使用可能部分のうちの少なくとも１つのポンプ
バッテリを再充電するように構成され、充電デバイスは、遠隔インターフェース内のイン
ターフェースバッテリを再充電するように構成される。充電デバイスは、パーソナルコン
ピュータに接続され、パーソナルコンピュータは、情報を遠隔インターフェースに提供す
る。

本発明の本側面のいくつかの実施形態は、以下のうちの１つ以上を含んでもよい。シス
テムはさらに、少なくとも１つの送信機を含む、持続的グルコースモニタシステムを含み
、少なくとも１つの送信機は、遠隔インターフェースと無線通信する。システムはさらに
、少なくとも１つの血中グルコースメータを含み、血中グルコースメータは、遠隔インタ
ーフェースと無線通信する。少なくとも１つの再使用可能部分および遠隔インターフェー
スは、近距離通信を使用してペアリングされる。遠隔インターフェースはさらに、少なく
とも１つの加速度計を含む。遠隔インターフェースはさらに、少なくとも１つのカメラを
含む。

本発明の一側面によると、注入ポンプシステムが、開示される。注入ポンプシステムは
、注入ポンプと、注入ポンプを制御するための指示を含む、注入ポンプと無線通信する、
遠隔インターフェースデバイスとを含み、指示は、セキュアなウェブポータルと同期され
てもよい。

本発明の本側面のいくつかの実施形態は、以下のうちの１つ以上を含んでもよい。シス
テムはさらに、送信機を含む、持続的グルコースモニタシステムを含み、送信機は、遠隔
インターフェースデバイスと無線通信する。システムはさらに、血中グルコースメータを
含み、血中グルコースメータは、遠隔インターフェースデバイスと無線通信する。無線通
信は、無線周波数（「ＲＦ」）通信である。注入ポンプおよび遠隔インターフェースデバ
イスは、近距離通信を使用してペアリングされる。システムはさらに、少なくとも１つの
加速度計を含む。

本発明の一側面によると、医療デバイスシステムが、開示される。医療デバイスシステ
ムは、第１の医療デバイスと、第１の医療デバイスと無線通信する、第２の医療デバイス
とを含み、第２の医療デバイスは、第１の医療デバイスを制御するための指示を含み、指
示は、セキュアなウェブポータルと同期されてもよい。

本発明の本側面のいくつかの実施形態は、以下のうちの１つ以上を含んでもよい。第１
の医療デバイスは、注入ポンプであって、第２の医療デバイスは、遠隔インターフェース
デバイスである。注入ポンプおよび遠隔インターフェースデバイスは、近距離通信を使用
してペアリングされる。第１の医療デバイスは、持続的グルコースモニタセンサであって
、第２の医療デバイスは、遠隔インターフェースデバイスである。注入ポンプおよび遠隔
インターフェースデバイスは、近距離通信を使用してペアリングされる。第１の医療デバ
イスは、血中グルコースメータであって、第２の医療デバイスは、遠隔インターフェース
デバイスである。注入ポンプおよび遠隔インターフェースデバイスは、近距離通信を使用
してペアリングされる。

本発明の一側面によると、２つの医療デバイス間の通信のための方法が、開示される。
本方法は、第１の医療デバイスが、無線信号とともに、音響信号を第２の医療デバイスに
送信するステップと、音響信号を使用して、第１の医療デバイスと第２の医療デバイスと
の間の距離を計算するステップと、計算された距離が所定の閾値を超えるかどうか判定す
るステップと、計算された距離が所定の閾値を超える場合、ユーザに通知するステップと
を含む。

本発明の本側面のいくつかの実施形態は、以下のうちの１つ以上を含んでもよい。第１
の医療デバイスは、遠隔インターフェースであって、第２の医療デバイスは、注入ポンプ
である。第１の医療デバイスは、遠隔インターフェースであって、第２の医療デバイスは
、持続的グルコースモニタセンサ／送信機である。第１の医療デバイスは、遠隔インター
フェースであって、第２の医療デバイスは、血中グルコースメータである。

本発明のこれらの側面は、排他的であることを意味するものではなく、本発明の他の特
徴、側面、および利点は、添付の請求項および付随の図面と併せて熟読されることによっ
て、当業者に容易に明白となるであろう。

本発明のこれらおよび他の特徴ならびに利点は、図面とともに、以下の発明を実施する
ための形態を熟読することによってより理解されるであろう。
例えば、本明細書は、以下を提供する。
（項目１）
医療デバイスシステムであって、
第１の医療デバイスと、
第２の医療デバイスと、
タッチスクリーンを備える遠隔インターフェースであって、上記遠隔インターフェース
は、上記第１の医療デバイスおよび上記第２の医療デバイスと無線通信し、上記遠隔イン
ターフェースは、ユーザインターフェースを上記第１の医療デバイスおよび上記第２の医
療デバイスに提供するように構成され、上記遠隔インターフェースは、タッチスクリーン
を通して、ユーザ入力を受信するように構成されている、遠隔インターフェースと、
少なくとも上記第１の医療デバイスおよび上記遠隔インターフェースを受容するように
構成された充電デバイスであって、上記充電デバイスは、第１の医療デバイスバッテリを
再充電するように構成され、上記充電デバイスは、上記遠隔インターフェース内のインタ
ーフェースバッテリを再充電するように構成され、上記充電デバイスは、パーソナルコン
ピュータに接続され、上記パーソナルコンピュータは、情報を上記遠隔インターフェース
に提供する、充電デバイスと
を備える、システム。
（項目２）
上記第１の医療デバイスは、注入ポンプである、項目１に記載のシステム。
（項目３）
上記第１の医療デバイスは、少なくとも１つの使い捨て部分および少なくとも２つの再
使用可能部分をさらに備え、上記２つの再使用可能部分のそれぞれは、上記少なくとも１
つの使い捨て部分に接続するように構成されている、項目２に記載のシステム。
（項目４）
上記充電デバイスは、上記第１の医療デバイスの上記少なくとも２つの再使用可能部分
のうちの少なくとも１つを受容するように構成されている、項目３に記載のシステム。
（項目５）
上記第２の医療デバイスは、少なくとも１つの送信機を備える持続的グルコースモニタ
システムであり、上記少なくとも１つの送信機は、上記遠隔インターフェースと無線通信
する、項目１に記載のシステム。
（項目６）
上記遠隔インターフェースと無線通信する第３の医療デバイスをさらに備える、項目１
に記載のシステム。
（項目７）
上記遠隔インターフェースは、ユーザインターフェースを上記第３の医療デバイスに提
供するように構成されている、項目６に記載のシステム。
（項目８）
上記第３の医療デバイスは、少なくとも１つの血中グルコースメータである、項目７に
記載のシステム。
（項目９）
さらに、上記無線通信が無線周波数通信であることを備える、項目１に記載のシステム
。
（項目１０）
上記第１の医療デバイスおよび上記遠隔インターフェースは、近距離通信を使用してペ
アリングされる、項目１に記載のシステム。
（項目１１）
上記遠隔インターフェースは、少なくとも１つのカメラをさらに備える、項目１に記載
のシステム。
（項目１２）
医療デバイスシステムであって、
第１の医療デバイスと、
上記第１の医療デバイスと無線通信する第２の医療デバイスと、
タッチスクリーンを備える遠隔インターフェースであって、上記遠隔インターフェース
は、上記第１の医療デバイスと無線通信し、上記遠隔インターフェースは、ユーザインタ
ーフェースを上記第１の医療デバイスおよび上記第２の医療デバイスに提供するように構
成され、上記遠隔インターフェースは、タッチスクリーンを通して、ユーザ入力を受信す
るように構成されている、遠隔インターフェースと、
上記第１の医療デバイスおよび上記遠隔インターフェースを受容するように構成された
充電デバイスであって、上記充電デバイスは、第１の医療デバイスバッテリを再充電する
ように構成され、上記充電デバイスは、上記遠隔インターフェース内のインターフェース
バッテリを再充電するように構成され、上記充電デバイスは、パーソナルコンピュータに
接続され、上記パーソナルコンピュータは、情報を上記遠隔インターフェースに提供する
、充電デバイスと
を備える、システム。
（項目１３）
上記第１の医療デバイスは、注入ポンプである、項目１２に記載のシステム。
（項目１４）
上記第１の医療デバイスは、少なくとも１つの使い捨て部分および少なくとも２つの再
使用可能部分をさらに備え、上記２つの再使用可能部分のそれぞれは、上記少なくとも１
つの使い捨て部分に接続するように構成されている、項目１３に記載のシステム。
（項目１５）
上記充電デバイスは、上記第１の医療デバイスの上記少なくとも２つの再使用可能部分
のうちの少なくとも１つを受容するように構成されている、項目１３に記載のシステム。
（項目１６）
上記第２の医療デバイスは、少なくとも１つの送信機を備える持続的グルコースモニタ
システムを備え、上記少なくとも１つの送信機は、上記第１の医療デバイスと無線通信す
る、項目１２に記載のシステム。
（項目１７）
上記第２の医療デバイスは、上記第１の医療デバイスと無線通信する血中グルコースメ
ータを備える、項目１２に記載のシステム。
（項目１８）
上記第１の医療デバイスおよび上記遠隔インターフェースは、近距離通信を使用してペ
アリングされる、項目１２に記載の注入ポンプシステム。
（項目１９）
上記第１の医療デバイスおよび上記第２の医療デバイスは、近距離通信を使用してペア
リングされる、項目１２に記載の注入ポンプシステム。
（項目２０）
注入ポンプシステムであって、
注入ポンプの少なくとも１つの使い捨て部分と、
注入ポンプの少なくとも２つの再使用可能部分であって、注入ポンプの上記２つの再使
用可能部分のそれぞれは、上記少なくとも１つの使い捨て部分に接続するように構成され
ている、少なくとも２つの再使用可能部分と、
タッチスクリーンを備える遠隔インターフェースであって、上記遠隔インターフェース
は、上記少なくとも２つの再使用可能部分のうちの少なくとも１つと無線通信し、上記遠
隔インターフェースは、ユーザ指示を上記少なくとも２つの再使用可能部分のうちの上記
少なくとも１つに提供するように構成され、上記遠隔インターフェースは、タッチスクリ
ーンを通して、ユーザ入力を受信するように構成されている、遠隔インターフェースと、
上記少なくとも２つの再使用可能部分および上記遠隔インターフェースのうちの少なく
とも１つを受容するように構成された充電デバイスであって、上記充電デバイスは、上記
少なくとも２つの再使用可能部分のうちの上記少なくとも１つのポンプバッテリを再充電
するように構成され、上記充電デバイスは、上記遠隔インターフェース内のインターフェ
ースバッテリを再充電するように構成され、上記充電デバイスは、パーソナルコンピュー
タに接続され、上記パーソナルコンピュータは、情報を上記遠隔インターフェースに提供
する、充電デバイスと、
を備える、注入ポンプシステム。
（項目２１）
少なくとも１つの送信機を備える持続的グルコースモニタシステムをさらに備え、上記
少なくとも１つの送信機は、上記遠隔インターフェースと無線通信する、項目２０に記載
の注入ポンプシステム。
（項目２２）
少なくとも１つの血中グルコースメータをさらに備え、上記血中グルコースメータは、
上記遠隔インターフェースと無線通信する、項目２０に記載の注入ポンプシステム。
（項目２３）
上記少なくとも１つの再使用可能部分および上記遠隔インターフェースは、近距離通信
を使用してペアリングされる、項目２０に記載の注入ポンプシステム。
（項目２４）
上記遠隔インターフェースは、少なくとも１つの加速度計をさらに備える、項目２０に
記載の注入ポンプシステム。
（項目２５）
上記遠隔インターフェースは、少なくとも１つのカメラをさらに備える、項目２０に記
載の注入ポンプシステム。

図１Ａは、注入ポンプのある実施形態の分解図である。 図１Ｂは、注入ポンプのある実施形態の分解図である。 図２は、注入ポンプおよび第２の再使用可能部分のある実施形態の分解図である。 図３は、外部注入セットを示す、注入ポンプ使い捨て部分の一実施形態の斜視図である。 図４Ａおよび４Ｂは、注入ポンプのある実施形態を描写する。 図５Ａ−５Ｃは、注入ポンプのある実施形態を描写する。 図５Ａ−５Ｃは、注入ポンプのある実施形態を描写する。 図５Ａ−５Ｃは、注入ポンプのある実施形態を描写する。 図５Ｄは、再使用可能部分のある実施形態の分解図である。 図５Ｅは、再使用可能部分のある実施形態の分解図である。 図５Ｆは、再使用可能部分のある実施形態の分解図である。 図５Ｇ−５Ｉは、防塵カバーの一実施形態を示す。 図５Ｇ−５Ｉは、防塵カバーの一実施形態を示す。 図５Ｇ−５Ｉは、防塵カバーの一実施形態を示す。 図６は、遠隔インターフェースのある実施形態の図である。 図７は、遠隔インターフェースのある実施形態の図である。 図７は、遠隔インターフェースのある実施形態の図である。 図８は、システムのある実施形態の図である。 図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。 図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。 図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。 図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。 図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。 図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。 図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。 図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。 図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。 図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。 図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。 図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。 図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。 図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。 図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。 図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。 図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。 図９Ａは、本デバイスの一実施形態内に含まれ得る、マルチプロセッサ制御構成のある実施形態を図式的に描写する。 図９Ｂは、いくつかの実施形態における、本デバイスの一実施形態内に含まれ得る、マルチプロセッサ制御構成のある実施形態を図式的に描写する。 図１０Ａおよび１０Ｂは、マルチプロセッサ機能性の一実施形態を図式的に描写する。 図１０Ａおよび１０Ｂは、マルチプロセッサ機能性の一実施形態を図式的に描写する。 図１１は、マルチプロセッサ機能性の一実施形態を図式的に描写する。 図１２は、マルチプロセッサ機能性の一実施形態を図式的に描写する。 図１２Ａ−１２Ｅは、一実施形態による、種々のソフトウェア層を図式的に描写する。 図１２Ａ−１２Ｅは、一実施形態による、種々のソフトウェア層を図式的に描写する。 図１２Ａ−１２Ｅは、一実施形態による、種々のソフトウェア層を図式的に描写する。 図１２Ａ−１２Ｅは、一実施形態による、種々のソフトウェア層を図式的に描写する。 図１２Ａ−１２Ｅは、一実施形態による、種々のソフトウェア層を図式的に描写する。 図１３は、システムの一実施形態の例証である。 図１４は、システムの一実施形態の例証である。 図１５Ａ−１５Ｂは、システムの一実施形態における、充電ステーションの一実施形態の例証である。 図１６Ａ−１６Ｆは、システムの一実施形態による、バッテリ充電器／充電ステーションのある実施形態の種々の図を描写する。 図１６Ａ−１６Ｆは、システムの一実施形態による、バッテリ充電器／充電ステーションのある実施形態の種々の図を描写する。 図１６Ａ−１６Ｆは、システムの一実施形態による、バッテリ充電器／充電ステーションのある実施形態の種々の図を描写する。 図１６Ａ−１６Ｆは、システムの一実施形態による、バッテリ充電器／充電ステーションのある実施形態の種々の図を描写する。 図１６Ａ−１６Ｆは、システムの一実施形態による、バッテリ充電器／充電ステーションのある実施形態の種々の図を描写する。 図１６Ａ−１６Ｆは、システムの一実施形態による、バッテリ充電器／充電ステーションのある実施形態の種々の図を描写する。 図１７は、システムの種々の要素の相互接続の一実施形態を図式的に描写する。 図１８は、システムの一実施形態の例証である。 図１９は、システムの一実施形態の例証である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。 図３１は、２Ｄバーコードのある実施形態である。 図３２は、遠隔インターフェースおよび２Ｄバーコードを使用して、基礎プロファイルをプログラミングするためのシステムのある実施形態である。 図３３は、２Ｄバーコード内に埋め込まれ得る、ある実施形態情報である。 図３４は、カメラを使用して、遠隔インターフェースにプログラムされ得る、基礎プロファイルのある実施例である。

定義
本説明および付随の請求項に使用されるように、以下の用語は、文脈によって別様に要
求されない限り、以下に示される意味を有するものとする。

「遠隔インターフェース」は、制限ではないが、医療デバイスを含み得る、デバイスと
無線通信するためのデバイスを意味するものとする。

「デバイス」は、制限ではないが、医療デバイス（制限ではないが、注入ポンプおよび
／またはマイクロ注入ポンプ、薬物送達ポンプおよび／または装置、センサ、測定デバイ
スおよび／または測定器、血圧モニタ、ＥＣＧモニタ、丸剤ディスペンサ、パルスオキシ
メトリモニタ、ＣＯ^２カプノメータ、点滴バッグ、滴下流メータ、温度モニタ、腹膜透析
機械（制限されないが、自宅用腹膜透析機械を含む）、血液透析機械（制限されないが、
自宅用血液透析機械を含む）、ならびに医療ケアを送達、取扱、および／または判定する
ように構成される、任意の他の医療デバイスまたはデバイスを含む）を含む、任意の医療
デバイスを意味するものとする。

デバイスの「入力」は、デバイスおよび／または遠隔インターフェースのユーザおよび
／または他のオペレータ／介護者が、デバイスおよび／または遠隔インターフェースの機
能を制御し得る、任意の機構を含む。ユーザ入力は、機械的配列（例えば、スイッチ、プ
ッシュボタン、ジョグホイール）、電気配列（例えば、スライダ、タッチスクリーン）、
遠隔インターフェースと通信するための無線インターフェース（例えば、無線周波数（「
ＲＦ」）、赤外線（「ＩＲ」）、ＢＬＵＥＴＯＯＴＨ（登録商標））、音響インターフェ
ース（例えば、音声認識を伴う）、コンピュータネットワークインターフェース（例えば
、ＵＳＢポート）、光／光波画像（制限されないが、カメラ入力および／またはカメラを
使用して捕捉された画像を含む）、音波、および／または他のタイプのインターフェース
を含んでもよい。

以下に論じられる、いわゆる「ボーラスボタン」等の入力の文脈における「ボタン」は
、所望の機能を果たすことが可能である、任意のタイプのユーザ入力であってもよく、プ
ッシュボタン、スライダ、スイッチ、タッチスクリーン、および／またはジョグホイール
に制限されない。

「アラーム」は、警告が、ユーザおよび／または第三者／オペレータ／介護者に対して
発生され得る、任意の機構を含む。アラームは、音声アラーム（例えば、スピーカ、ブザ
ー、音声発生器）、視覚アラーム（例えば、ＬＥＤ、ＬＣＤ画面、画像）、触知アラーム
（例えば、振動要素）、無線信号（例えば、遠隔インターフェースまたは介護者への無線
伝送）、および／または他の機構を含んでもよい。アラームは、冗長機構（例えば、２つ
の異なるオーディオアラーム）または相補的機構（例えば、オーディオアラーム、触知ア
ラーム、および無線アラーム）、および／または音量および／または強度を増加させる機
構（例えば、漸増アラームシーケンス）を含む、同時に、並行して、またはシーケンスと
して、複数の機構を使用して発生されてもよい。

「流体」は、流動ラインまたは流体ラインを通して流動可能な物質、例えば、液体を意
味するものとする。

「ユーザ」は、医療治療の一部またはその他としてかにかかわらず、デバイスから治療
を受容する、またはそれに接続される、人または動物、および／またはデバイスをプログ
ラミングする、または別様にデバイスと相互作用し、治療を与える、および／または情報
をデバイスから収集することに関与する、制限ではないが、医師および／または医療提供
者および／または随伴者および／または両親および／または保護者を含み得る、介護者ま
たは第三者を含む。

「カニューレ」は、流体をユーザに注入可能な使い捨てデバイスを意味するものとする
。カニューレは、本明細書で使用されるように、従来のカニューレ／可撓性チューブまた
は針を指し得る。

「使い捨て」は、固定持続時間の間、使用され、次いで、廃棄および交換されることが
意図される、部品、デバイス、部分、またはその他を指す。

「再使用可能」は、無制限の使用持続時間を有することが意図される、部分を指す。

「音響式体積測定」は、米国特許第５，３４９，８５２号および第５，６４１，８９２
号、ならびに２００７年２月９日出願の米国特許出願第１１／７０４，８９９号「Ｆｌｕ
ｉｄ Ｄｅｌｉｖｅｒｙ Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ」（２００７年１０
月４日公開の現米国特許公報第ＵＳ−２００７−０２２８０７１−Ａ１号）（弁理士整理
番号Ｅ７０）、および２００８年１２月３１日出願の米国特許出願第１２／３４７，９８
５号「Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ Ａｓｓｅｍｂｌｙ」（２００９年１２月３日公開の
現米国特許公報第ＵＳ−２００９−０２９９２７７号）（弁理士整理番号Ｇ７５）（それ
ぞれ、参照することによって、その全体として本明細書に組み込まれる）に説明されるも
の等の音響式技法、ならびに他の技法を使用する、関連体積の定量的測定を意味するもの
とする。

本明細書に説明されるデバイス、方法、およびシステムの種々の実施形態の例示的使用
は、糖尿病を患う人々へのインスリンの送達のためのものであるが、他の使用として、任
意の流体の送達、任意の病状および／または状態の感知、および／または医療治療および
／または医療ケアの提供が挙げられる。流体は、制限ではないが、疼痛に苦しむ人への鎮
痛薬、癌患者への化学療法、および代謝障害に患う患者への酵素を含んでもよい。種々の
治療薬流体は、制限ではないが、小分子、天然産物、ペプチド、タンパク質、核酸、炭水
化物、ナノ粒子懸濁液、および関連付けられた薬学的容認可能担体分子を含んでもよい。
療法的活性分子は、デバイスの安定性を改善するように修正されてもよい（例えば、ペプ
チドまたはタンパク質のペグ化によって）。本明細書の例証的実施形態は、薬物送達用途
について説明するが、本実施形態は、ラボ・オン・チップ用途および毛細管クロマトグラ
フィ等の高処理量分析測定のための試薬の液体分注を含む、他の用途に使用されてもよい
。以下の説明の目的のために、用語「治療薬」、「インスリン」、または「流体」は、同
義的に使用されるが、しかしながら、他の実施形態では、前述のような任意の流体が、使
用されてもよい。したがって、本明細書に含まれるデバイス、システム、方法、およびそ
の説明は、治療薬との併用に制限されない。

デバイスのいくつかの実施形態は、糖尿病を患う人々および／またはその介護者によっ
て使用するために適合される。したがって、これらの実施形態では、デバイス、方法およ
びシステムは、糖尿病に患う人々（ユーザと称される）の膵島ベータ細胞の作用を補完ま
たは置換する、インスリンを送達するように協働する。インスリン送達のために適合され
た実施形態は、流体送達の基礎レベルならびに流体送達のボーラスレベルの両方を提供す
ることによって、膵島ベータ細胞の作用の置換を模索する。基礎レベル、ボーラスレベル
、およびタイミングは、遠隔インターフェースユーザインターフェースを使用することに
よって、または直接、デバイス上のユーザインターフェースを使用することによって、ユ
ーザによって設定されてもよい。加えて、基礎および／またはボーラスレベルは、例示的
実施形態では、遠隔インターフェースと一体タイプである、または無線通信し得る、１つ
以上のグルコースメータおよび／またはグルコースモニタ（すなわち、デバイス）の出力
に応答して、トリガあるいは調節されてもよい。他の実施形態では、遠隔インターフェー
スは、制限ではないが、血液試料を受容する、および／または血液試料、例えば、血液グ
ルコース細片を受容するように構成される、デバイスを受容する、血中グルコースメータ
／デバイスを含み得る、１つ以上の検体監視デバイスを含んでもよい。いくつかの実施形
態では、ボーラスは、デバイス上、すなわち、注入ポンプ上および／または遠隔インター
フェース上に位置する、指定されたボタンまたは他の入力手段を使用して、ユーザによっ
てトリガされてもよい。さらに他の実施形態では、ボーラスまたは基礎は、デバイス上（
例えば、注入ポンプ上および／または遠隔インターフェース上）のいずれかに位置するユ
ーザインターフェースを通して、プログラムまたは管理されてもよい。

種々の実施形態全体を通して、本明細書の画面および画面のタイプに与えられる名称な
らびに種々の特徴に与えられる適切な名称に関して、これらの用語は、異なり得、かつ説
明目的のためのものである。本説明は、これらの名称に制限されない。

本明細書に説明されるデバイス、システム、および方法は、注入ポンプを制御するため
に使用されてもよい。本説明の目的のために、ユーザインターフェースおよび注入ポンプ
の種々の実施形態は、インスリンポンプ、すなわち、インスリンを注入するポンプを参照
して説明され得る。しかしながら、ユーザインターフェースは、注入ポンプ上にあっても
よく、および／または遠隔インターフェースおよび遠隔インターフェースが通信する医療
デバイスは、任意の医療デバイスであってもよく、すなわち、注入ポンプに制限されない
ことを理解されたい。加えて、説明が、注入ポンプ「画面」に関する場合、本「画面」は
また、遠隔インターフェース上に現れてもよく、または注入ポンプの代わりに、遠隔イン
ターフェース上に現れてもよい。

本説明によって想定される注入ポンプは、制限されないが、治療薬流体（制限ではない
が、インスリンを含む）を含む、任意の流体を圧送し得る、ポンプを含む。したがって、
本説明が、インスリンに関する実施形態を説明する場合、これは、単に、説明目的のため
だけに意味されるものであって、インスリンに制限されることを意図しない。他の流体も
また、想定される。いくつかの実施形態では、本明細書に説明される方法、システム、お
よびデバイスは、他の流体送達デバイス、例えば、当技術分野において公知のペンおよび
／または注射器と併用されてもよい。

本明細書に説明されるデバイスを制御するためのシステムは、任意の１つ以上のデバイ
スのために使用されてもよく、いくつかの実施形態では、デバイスは、流体を送達し得る
、および／またはカニューレを通してユーザに流体を送達するように構成され得る、注入
ポンプおよび／または注入ポンプシステムを含んでもよい。説明目的のためだけに、少な
くとも１つのインスリンポンプを含み得る、注入ポンプシステムが、本明細書に説明され
る。しかしながら、システムは、１つ以上の注入ポンプおよび／またはインスリンポンプ
システムとの併用に制限されず、むしろ、任意のデバイスおよび／または任意の１つ以上
のデバイスと併用されてもよい。

次に、図１Ａおよび１Ｂを参照すると、デバイス１００の一実施形態が、示される。デ
バイス１００は、例証的実施形態では、任意の注入ポンプであり得る、注入ポンプである
が、しかしながら、いくつかの実施形態では、２００７年１０月４日公開の米国公報第Ｕ
Ｓ−２００７−０２２８０７１号（Ｅ７０）または２００９年１２月３日公開の米国公報
第ＵＳ−２００９−０２９９２７７−Ａ１号（弁理士整理番号Ｇ７５）に図示および説明
される、注入ポンプの実施形態のうちの１つであってもよい。しかしながら、上記で議論
されるように、種々の他の実施形態では、デバイスは、任意の医療デバイスであってもよ
く、いくつかの実施形態では、１つ以上のデバイスが、システム内に含まれる。

デバイス１００は、再使用可能部分１０２および使い捨て部分１０４を含む。種々の実
施形態では、使い捨て部分１０４は、リザーバおよび流体ライン、すなわち、注入ポンプ
の「湿潤」構成要素を含む。いくつかの実施形態では、使い捨て部分１０４は、タブ１１
６を含む。

再使用可能部分１０２は、リザーバ内の流体を、リザーバから、カニューレ（図示され
ないが、図３に３０８として示される）に接続され得る、管類１０６に圧送させるように
構成される、機械的および電気構成要素１０８を含む。いくつかの実施形態では、再使用
可能部分１０２は、係止リングアセンブリ１１０と、係止リングアセンブリ１１０の回転
を促進し得る、位置決め突起８０８とを含んでもよい。再使用可能部分１０２は、使い捨
て部分１０４に取り外し可能に係合されてもよく、これは、例えば、制限されないが、螺
着、捻転係止、または圧縮嵌合構成、または他の構成によってもたらされ得る。いくつか
の実施形態では、再使用可能部分１０４は、使い捨て部分１０２に対して適切に位置付け
られてもよく、係止リングアセンブリ１１０は、再使用可能部分１０４を使い捨て部分１
０２に取り外し可能に係合させるように回転されてもよい。

加えて、例えば、使い捨て筐体アセンブリ１０４のタブ１１６に対する、突起１１２の
位置は、再使用可能部分１０２が、使い捨て部分１０４と完全に係合されたことの検証を
提供してもよい。例えば、図４Ａに示されるように、再使用可能部分４０２が、使い捨て
部分１０４と適切に整合されると、突起４１２は、タブ４１６に対して、第１の位置に整
合され得る。係止リングアセンブリ４１０の回転（図４Ａにおける矢印によって示される
回転方向）によって、完全に係合された状態を達成すると、突起４１２は、図４Ｂに示さ
れるように、タブ４１６に対して、第２の位置に整合され得る。

次に、また、図２を参照すると、システムのいくつかの実施形態では、システムは、１
つ以上のデバイスを含んでもよく、いくつかの実施形態では、システムは、２つのデバイ
ス２００、２０２を含んでもよい。システムのいくつかの実施形態では、システムは、２
つの再使用可能部分２００、２０２および少なくとも１つの使い捨て部分２０４を含んで
もよい。再使用可能部分２００、２０２および使い捨て部分２０４は、いくつかの実施形
態では、前述のデバイス１００の実施形態であってもよい。システムのいくつかの実施形
態では、システムは、それぞれ、再充電可能電力デバイス、例えば、再充電可能バッテリ
を含み得る、２つの再使用可能部分２００、２０２を含んでもよい。したがって、いくつ
かの実施形態では、一方の再使用可能部分２００は、使い捨て部分２０４に接続され、ユ
ーザによって使用されるが、他方の再使用可能部分２０２は、再充電されてもよい。した
がって、いくつかの実施形態では、システムは、他のデバイスが使用中、再充電または点
検され得る、バックアップデバイスを含んでもよい。

また、図３を参照すると、いくつかの実施形態では、使い捨て部分３００は、管類３０
２に接続されたオス型コネクタ３０４を含み得る、管類３０２を含む。オス型コネクタ３
０４は、いくつかの実施形態では、メス型コネクタ３０６に接続されるように構成される
。オス型コネクタ３０４とメス型コネクタ３０６の想定される接続は、管類３０２からカ
ニューレ３０８、したがって、リザーバからカニューレへの流体路を提供する。カニュー
レ３０８は、カニューレ接着剤パッド３１０によって、ユーザ上の定位置に保持されても
よい。管類３０２、オス型コネクタ３０４、メス型コネクタ３０６、カニューレ３０８、
およびカニューレ接着剤パッド３１０は、集合的に、注入セット３１２と称されてもよい
。いくつかの実施形態では、再使用可能部分３００は、いくつかの実施形態では、例えば
、使い捨て接着パッチ（使い捨て部分３００の下側表面に接続され、接着剤が、暴露され
、次いで、ユーザに取着され得る）または面ファスナーパッチであり得る、パッチ３１４
によって、ユーザ上に保持されてもよい。使い捨てパッチが、面ファスナーパッチ（例え
ば、ＶＥＬＣＲＯ ＵＳＡ Ｉｎｃ．（Ｍａｎｃｈｅｓｔｅｒ， ＮＨ）によって提供さ
れる面ファスナーシステム等）である実施形態では、使い捨て部分３００の下側表面は、
相補的フックまたはループ表面を含んでもよい。

次に、また、図５Ａ−５Ｆを参照すると、いくつかの実施形態では、再使用可能部分５
００は、ユーザコマンド（例えば、ボーラス送達の場合、遠隔インターフェースとのペア
リングまたは同等物）を受信するように構成される、入力スイッチアセンブリを含んでも
よい。入力スイッチアセンブリは、いくつかの実施形態では、本体５２０の開口部５２６
内に配置され得る、ボタン８２４を含んでもよい。示されるように、例えば、図５Ｂでは
、係止リングアセンブリ５０６は、係止リングアセンブリ５０６が、本体５２０に対して
回転されることを可能にするように構成され得る一方、依然として、ボタン５２４への容
易なアクセスを提供する、半径方向スロット５２８を含んでもよい。

依然として、図５Ａ−５Ｆを参照すると、電気制御アセンブリ５１６は、印刷回路基板
５３０と、いくつかの実施形態では、再充電可能バッテリであり得る、バッテリ５３２と
を含んでもよい。印刷回路基板５３０は、圧送済みおよび／または圧送中の注入可能流体
の量を監視ならびに制御するための種々の制御電子機器を含んでもよい。例えば、電気制
御アセンブリ５１６は、分注されたばかりの注入可能流体の量を測定し、ユーザによって
要求された用量に基づいて、十分な注入可能流体が分注されたかどうか判定してもよい。
十分な注入可能流体が分注されていない場合、電気制御アセンブリ５１６は、より多くの
注入可能流体が圧送されるべきであることを判定し得る。電気制御アセンブリ５１６は、
任意の付加的必要用量が圧送され得るように、適切な信号を機械的制御アセンブリ５１２
に提供してもよく、または電気制御アセンブリ５１６は、付加的用量が次の用量とともに
分注され得るように、適切な信号を機械的制御アセンブリ５１２に提供してもよい。代替
として、多過ぎる注入可能流体が分注された場合、電気制御アセンブリ５１６は、より少
ない注入可能流体が次の用量において分注され得るように、適切な信号を機械的制御アセ
ンブリ５１２に提供してもよい。電気制御アセンブリ５１６は、１つ以上のマイクロプロ
セッサを含んでもよい。例示的実施形態では、電気制御アセンブリ５１６は、３つのマイ
クロプロセッサを含んでもよい。１つのプロセッサ（例えば、制限ではないが、Ｃｈｉｐ
ｃｏｎ ＡＳ（Ｏｓｌｏ， Ｎｏｒｗａｙ）から利用可能なＣＣ２５１０マイクロコント
ローラ／無線周波数（「ＲＦ」）送受信機を含んでもよい）は、遠隔インターフェースと
通信するための無線通信専用であってもよい。２つの付加的マイクロプロセッサ（その実
施例として、制限ではないが、Ｔｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓ Ｉｎｃ．（Ｄａｌ
ｌａｓ， Ｔｅｘａｓ）から利用可能なＭＳＰ４３０マイクロ遠隔インターフェースが挙
げられ得る）は、コマンドの発行および実施専用であってもよい（例えば、ある用量の注
入可能流体を分注するため、体積測定デバイスからのフィードバック信号を処理するため
、および同等物）。

図５Ｃに示されるように、ベースプレート５１８は、例えば、再充電可能バッテリ５３
２のための電気制御アセンブリ５１６に電気的に連結され得る、電気接点５３４へのアク
セスを提供してもよい。ベースプレート５１８は、使い捨て筐体アセンブリ５０４の協働
特徴（例えば、タブ）を介して、使い捨て筐体アセンブリ５０４との適切な整合を促進す
るように構成され得る、１つ以上の特徴（例えば、開口部５３６、５３８）を含んでもよ
い。加えて、ベースプレート５１８は、弁アセンブリ５１４および電気制御アセンブリ５
１６を搭載するため、ならびに弁アセンブリ５１４（図５Ｄ−５Ｆに示される）によって
使い捨て部分５０４へのアクセスを提供するための種々の特徴を含んでもよい。

係止リングアセンブリ５０６は、例えば、再使用可能部分５００および使い捨て部分５
０４を係合／係脱させるために、係止リングアセンブリ５０６の把持ならびに捻転を促進
し得る、例えば、エラストマーまたはテクスチャ加工された材料を含み得る、グリップイ
ンサート５４０、５４２を含んでもよい。加えて、係止リングアセンブリ５０６は、いく
つかの実施形態では、磁石５４４であり得るが、他の実施形態では、電気接点または他の
感知構成要素であり得る、１つ以上の感知構成要素を含んでもよい。種々の実施形態では
、感知構成要素は、再使用可能部分５００の１つ以上の構成要素（例えば、ホール効果セ
ンサ）と相互作用し、例えば、噛合構成要素（例えば、いくつかの実施形態では、制限で
はないが、使い捨て部分５０４、充電ステーション、または充填ステーションのうちの１
つ以上を含んでもよい）の性質、および／または再使用可能部分５００が噛合構成要素と
係合適切に係合されているかどうかの表示を提供してもよい。いくつかの実施形態では、
ホール効果センサ（図示せず）は、ポンプ印刷回路基板５３０上に位置してもよい。ホー
ル効果センサは、係止リングアセンブリ５０６が、閉鎖位置に回転されると、それを検出
してもよい。したがって、いくつかの実施形態では、ホール効果センサは、磁石５４４と
ともに、係止リングアセンブリ５０６が閉鎖位置に回転されたかどうかを判定するための
システムを提供してもよい。

感知構成要素（磁石）５４４は、再使用可能部分構成要素、すなわち、いくつかの実施
形態では、ホール効果センサとともに、再使用可能部分５００が、意図された構成要素ま
たはデバイスに適切に取着されたかどうかの判定を提供するように協働してもよい。いく
つかの実施形態では、係止リングアセンブリ５０６は、制限ではないが、使い捨て部分５
０４、防塵カバー（図示せず）、またはバッテリ充電器（図示せず）を含み得る、構成要
素に取着されていない場合、旋回しなくてもよい。したがって、感知構成要素５４４は、
再使用可能部分５００とともに、多くの有利な安全性特徴を注入ポンプシステムに提供す
るように機能し得る。これらの特徴は、制限ではないが、以下のうちの１つ以上を含んで
もよい。システムが、使い捨て部分５０４、防塵カバー、または充電器に取着されている
ことを検出しない場合、システムは、ユーザに、再使用可能部分５００、例えば、弁およ
び圧送構成要素が、汚染または破損を被り得、再使用可能アセンブリの完全性を損なわせ
得ることを通知、警告、またはアラームしてもよい。したがって、システムは、ユーザに
、潜在的再使用可能完全性の脅威を警告するための完全性アラームを提供し得る。また、
システムが、再使用可能アセンブリが防塵カバーに取着されていることを感知する場合、
システムは、電源をオフにする、または電力を低減し、電力を節約してもよい。これは、
再使用可能部分が、相互作用する必要がある構成可能に接続していない場合、電力のより
効率的使用を提供し得る。

再使用可能部分５００は、使い捨て筐体アセンブリ、防塵カバー、またはバッテリ充電
器／バッテリ充電ステーションを含むが、それらに制限されない、いくつかの異なる構成
要素に取着してもよい。いずれの場合も、ホール効果センサは、係止リングアセンブリ５
０６が、閉鎖位置にある、したがって、再使用可能部分５００が、使い捨て部分５０４、
防塵カバー、またはバッテリ充電器／バッテリ充電ステーション（または、種々の実施形
態では、別の構成要素）に取り外し可能に係合されていることを検出してもよい。注入ポ
ンプシステムは、前述の参照された特許公報および特許に説明されるもの等のＡＶＳシス
テムを使用することによって、または電子接点によって、そこに取着されている構成要素
を判定してもよい。次に、また、図５Ｇ−５Ｉを参照すると、防塵カバー（例えば、防塵
カバー５３９）の一実施形態が、示される。例示的実施形態では、防塵カバー５３９は、
再使用可能部分５００の係止リングアセンブリ５０６が、防塵カバー５３９に取り外し可
能に係合し得るように、特徴５４１、５４３、５４５、５４７を含んでもよい。加えて、
防塵カバー５３９はさらに、再使用可能部分５００の弁作用および圧送特徴を収容するた
めの陥凹領域５８４９を含んでもよい。例えば、防塵カバーに関して、ＡＶＳシステムは
、使い捨て部分ではなく、防塵カバーが、再使用可能部分に接続されていることを判定し
てもよい。ＡＶＳシステムは、ルックアップテーブルまたは他の比較データを使用して、
測定データと特徴的防塵カバーまたは空の使い捨て部分のデータを比較して、区別しても
よい。バッテリ充電器に関して、バッテリ充電器は、いくつかの実施形態では、電気接点
を含んでもよい。再使用可能部分が、バッテリ充電器に取着されると、注入ポンプアセン
ブリ電子システムは、接触が行なわれたことを感知し得、したがって、再使用可能部分が
、バッテリ充電器に取着されていることを示すであろう。

注入ポンプの種々の実施形態は、注入可能流体を含有するように構成される、リザーバ
アセンブリを含んでもよい、またはそれに類似してもよい。いくつかの実施形態では、リ
ザーバアセンブリは、２００９年３月３日発行の米国特許第７，４９８，５６３号「Ｏｐ
ｔｉｃａｌ Ｄｉｓｐｌａｃｅｍｅｎｔ Ｓｅｎｓｏｒ ｆｏｒ Ｉｎｆｕｓｉｏｎ Ｄ
ｅｖｉｃｅｓ」（弁理士整理番号Ｄ７８）（参照することによって、全体として本明細書
に組み込まれる）、および／または２００７年１２月１１日発行の米国特許第７，３０６
，５７８号「Ｌｏａｄｉｎｇ Ｍｅｃｈａｎｉｓｍ ｆｏｒ Ｉｎｆｕｓｉｏｎ Ｐｕｍ
ｐ」（弁理士整理番号Ｃ５４）、２００９年１０月９日出願のＰＣＴ出願第ＰＣＴ／ＵＳ
２００９／０６０１５８号「Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ Ａｓｓｅｍｂｌｙ」（２０１
０年４月１５日公開の現公報第ＷＯ２０１０／０４２８１４号）（弁理士整理番号Ｆ５１
ＷＯ）、および／または２００８年１０月１０日出願の米国特許出願第１２／２４９，８
８２号「Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ Ａｓｓｅｍｂｌｙ」（２０１０年４月１５日公開
の現米国特許公報第ＵＳ−２０１０−００９４２２２号）（弁理士整理番号Ｆ５１）、お
よび／または２０１１年３月３０日出願の米国特許出願第１３／０７６，０６７号「Ｉｎ
ｆｕｓｉｏｎ Ｐｕｍｐ Ｍｅｔｈｏｄｓ， Ｓｙｓｔｅｍｓ ａｎｄ Ａｐｐａｒａｔ
ｕｓ」（２０１１年９月２２日公開の現米国特許公報第ＵＳ−２０１１−０２３０８３７
号（弁理士整理番号Ｉ７０）、および／または２０１１年３月３０日出願の米国特許出願
第１３／１２１，８２２号「Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ Ａｓｓｅｍｂｌｙ」（２０１
１年８月２５日公開の現米国特許公報第ＵＳ−２０１１−０２０８１２３号）（弁理士整
理番号Ｉ７３）（全て、参照することによって、その全体として本明細書に組み込まれる
）に説明されるものに類似するリザーバアセンブリであってもよい。

いくつかの実施形態では、注入ポンプの種々の実施形態は２００７年１２月１１日発行
の米国特許第７，３０６，５７８号「Ｌｏａｄｉｎｇ Ｍｅｃｈａｎｉｓｍ ｆｏｒ Ｉ
ｎｆｕｓｉｏｎ Ｐｕｍｐ」（弁理士整理番号Ｃ５４）、２００８年１０月１０日出願の
米国特許出願第１２／２４９，８８２号「Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ Ａｓｓｅｍｂｌ
ｙ」、（２０１０年４月１５日公開の現米国特許公報第ＵＳ−２０１０−００９４２２２
号）（弁理士整理番号Ｆ５１）、および２００８年１０月１０日出願の米国特許出願第１
２／２４９，８９１号「Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ Ａｓｓｅｍｂｌｙ」（２００９年
４月１６日公開の現米国特許公報第ＵＳ−２００９−００９９５２３号）（弁理士整理番
号Ｇ４６）（全て、参照することによって、その全体として本明細書に組み込まれる）に
説明される１つ以上を含んでもよい、またはそれらに類似してもよい。

いくつかの実施形態では、いくつかの実施形態では、前述のもの等の注入ポンプであり
得る、デバイスは、遠隔インターフェースとワイヤレス無線周波数（「ＲＦ」）通信する
ためのハードウェアを含む。しかしながら、種々の実施形態では、デバイスは、任意のデ
バイスであってもよく、注入ポンプに制限されない。システムのいくつかの例示的実施形
態では、デバイスは、制限ではないが、ユーザへの視覚表示を含む、少なくとも１つの画
面または他のディスプレイのうちの１つ以上を含み得る、ディスプレイアセンブリを含ん
でもよい。しかしながら、図１Ａ−５Ｆに示されるもの等、他の実施形態では、デバイス
は、ディスプレイアセンブリを含まなくてもよい。これらの実施形態では、ディスプレイ
アセンブリは、遠隔インターフェース上に含まれてもよい。システムのいくつかの実施形
態では、デバイスが、ディスプレイを含む場合でも、システムは、ディスプレイもまた含
む、遠隔インターフェースを含んでもよい。遠隔インターフェースのいくつかの実施形態
が、図６、７、７Ａ、および８に示される。

図１Ａ−５Ｉに示される注入ポンプシステムだけではなく、また、システムと併用され
得る、他のデバイスも参照すると、デバイスは、デバイスが動作するために要求され得る
１つ以上のプロセスを実行する、１つ以上のプロセッサと称され得る、処理論理（図示せ
ず）を含んでもよい。処理論理は、１つ以上のマイクロプロセッサ（図示せず）、１つ以
上の入力／出力遠隔インターフェース（図示せず）、およびキャッシュメモリデバイス（
図示せず）を含んでもよい。１つ以上のデータバスおよび／またはメモリバスは、１つ以
上のサブシステムとの処理論理を相互接続するために使用されてもよい。

システムが、ユーザとデバイスとの間の相互作用を要求する場合、相互作用は、遠隔イ
ンターフェース上またはデバイス上のいずれかにおいて、入力を使用して達成されてもよ
く、例えば、いくつかの実施形態では、デバイスが、注入ポンプである場合、デバイス上
の入力は、注入ポンプ上のスイッチアセンブリであってもよい。

処理論理は、いくつかの実施形態では、入力をユーザから受信するために使用される。
ユーザは、ボタン／スイッチアセンブリ、スライダアセンブリ、制限されないが、容量ス
ライダ（例えば、２００７年１２月４日出願の米国特許出願第１１／９９９，２６８号「
Ｍｅｄｉｃａｌ Ｄｅｖｉｃｅ Ｉｎｃｌｕｄｉｎｇ ａ Ｓｌｉｄｅｒ Ａｓｓｅｍｂ
ｌｙ」（２００８年７月２４日公開の現米国特許公報第ＵＳ−２００８−０１７７９００
号）（弁理士整理番号Ｆ１４）（参照することによって、全体として本明細書に組み込ま
れる）に説明される任意のスライダを含むが、それらに制限されないものを含み得る）、
ジョグホイール、オーディオ入力、触知入力、および／またはタッチスクリーンうちの１
つ以上を含むが、それらに制限されない、１つ以上の入力デバイスまたはアセンブリを使
用してもよい。いくつかの実施形態では、デバイスは、加えて、入力を内部システムから
受信してもよい。これらの内部システムは、例えば、デバイスが注入ポンプである実施形
態では、制限ではないが、閉塞検出プロセス、確認プロセス、および体積測定技術、例え
ば、音響体積感知（「ＡＶＳ」）うちの１つ以上を含んでもよい。これらの入力を使用し
て、いくつかの実施形態では、注入ポンプであり得る、デバイスは、出力、例えば、制限
されないが、ユーザへの注入流体送達を含む、出力を生成してもよく、および／またはこ
れらの入力は、制限ではないが、ユーザへのコメント、警告、アラーム、または警報のう
ちの１つ以上を含み得る、出力を生成してもよい。入力は、したがって、直接、ユーザか
らデバイス、直接、デバイスシステムから処理論理、または別のデバイスまたは遠隔イン
ターフェースからデバイスのいずれかに行なわれる。ユーザ相互作用経験は、したがって
、制限ではないが、ディスプレイ上でのテキストおよび／またはグラフィックの読取／視
認を含む、ディスプレイ（デバイス自体または遠隔インターフェースまたは両方のいずれ
か上）との相互作用、例えば、タッチスクリーンを通したディスプレイとの直接相互作用
、１つ以上のボタン、スライダ、ジョグホイール、または他の入力との相互作用、１つ以
上のグルコース細片リーダとの相互作用、ならびに触覚または聴覚、１つ以上の振動モー
タ、および／またはオーディオシステムのいずれかを通した感知のうちの１つ以上を含む
が、それらに限定されない。したがって、用語「ユーザインターフェース」は、ユーザが
、デバイスと相互作用し、デバイスからの情報を制御および／または受信するために使用
される、システム、方法、およびデバイスの全てを包含するために使用される。

次に、図６および７Ａ−７Ｂを参照すると、注入ポンプシステムのいくつかの実施形態
では、注入ポンプは、遠隔インターフェース６００、７００を使用して、遠隔で制御され
てもよい。遠隔インターフェースの２つの実施形態が、示されるが、しかしながら、種々
の他の実施形態では、遠隔インターフェースは、無線および／または遠隔通信を介してを
含む、デバイスと相互作用可能な任意のタイプのデバイスであってもよい。遠隔インター
フェース６００、７００は、いくつかの実施形態では、図１Ａ−５Ｉに関して本明細書に
図示および説明されるものに類似する注入ポンプを含み得る、デバイスの機能性の全部ま
たは一部を含んでもよい。上記で議論されるように、説明の目的のために、デバイスは、
注入ポンプとして説明され得るが、しかしながら、本開示は、注入ポンプに制限されない
。また、本明細書に説明されるシステム、方法、および装置は、任意のデバイスと併用さ
れてもよい。

前述の注入ポンプのいくつかの実施形態では、注入ポンプは、遠隔インターフェース６
００、７００を使用して構成されてもよい。これらの実施形態では、注入ポンプは、注入
ポンプと遠隔インターフェース６００、７００との間の通信（例えば、有線または無線）
を可能にし、したがって、遠隔インターフェース６００、７００が、注入ポンプを遠隔で
制御することを可能にする、テレメトリ回路（図示せず）を含んでもよい。遠隔インター
フェース６００、７００（また、テレメトリ回路（図示せず）を含み得、かつ注入ポンプ
と通信可能であり得る）は、ディスプレイアセンブリ６０２、７０２と、入力制御デバイ
ス（ジョグホイール６０６、スライダアセンブリ６１０、またはデバイスへの入力のため
の別の従来のモード等）、および／またはスイッチアセンブリ６０４、６０８、７０４の
うちの１つ以上を含み得る、少なくとも１つの入力アセンブリとを含んでもよい。したが
って、遠隔インターフェース６００は、図６に示されるように、ジョグホイール６０６お
よびスライダアセンブリ６１０を含むが、いくつかの実施形態は、ジョグホイール６０６
またはスライダアセンブリ６１０のいずれかの１つのみ、あるいはデバイスへの入力のた
めの別の従来のモードを含んでもよい。ジョグホイール６０６を有する実施形態では、ジ
ョグホイール６０６は、少なくとも部分的に、ホイール、リング、ノブ、または同等物の
移動に基づいて、制御信号を提供するために、回転式エンコーダまたは他の回転式変換器
に連結され得る、ホイール、リング、ノブ、または同等物を含んでもよい。

いくつかの実施形態では、遠隔インターフェースはタッチスクリーンを含んでもよく、
そのような実施形態では、図７Ａおよび７Ｂに描写されるように、タッチスクリーンは、
遠隔インターフェース７００の機能を示す、１つ以上のアイコン７０６、７１０を含んで
もよい。いくつかの実施形態では、１つ以上のアイコン７０６、７１０は、デバイスと通
信するように構成される、起動アプリケーションに関連してもよい。図７Ａに示されるよ
うに、いくつかの実施形態では、１つ以上のアイコン７０６は、いくつかの実施形態では
、医療デバイス（例えば、医療デバイス１、医療デバイス２、医療デバイス３）アプリケ
ーションであり得る、１つ以上のデバイスを示してもよい。しかしながら、種々の実施形
態では、３つ未満または４つ以上のアイコン７０６が、遠隔インターフェース７００上に
含まれてもよい。また、図７Ａに示されるように、いくつかの実施形態では、遠隔インタ
ーフェース７００は、遠隔インターフェース７００の別の機能性に関連する起動アプリケ
ーションに関連するアイコン７１０を含んでもよい（少なくとも１つのデバイスとの通信
に加えて）。いくつかの実施形態では、これらとして、制限ではないが、ウェブブラウザ
の起動、携帯電話または携帯電話機能性の起動、および／またはＭＰ３または他の「オー
ディオ」プレーヤ機能性の起動が挙げられ得る。いくつかの実施形態では、ユーザが、遠
隔インターフェース７００の種々の機能および／またはアプリケーションを「起動」する
ことが望ましくあり得る。いくつかの実施形態では、非デバイス関連機能性は、起動され
るまで、休止状態であってもよく、および／または「スリープ」させてもよい。これは、
制限されないが、バッテリ寿命の延長、および／または１つ以上のデバイスと通信するた
めの遠隔インターフェース７００の使用に関して、混乱の防止および／または動作の減速
を含む、多くの理由から望ましくあり得る。いくつかの実施形態では、デバイスが、遠隔
インターフェース７００とペアリングされると（以下により詳細に説明されるように）、
アプリケーションは、自動的に、起動されてもよい。いくつかの実施形態では、遠隔イン
ターフェース７００上のデバイスに関するアイコン７０６は、「アプリケーション」が、
ディスプレイ７０２上で「最小化」されているが、アプリケーションが、アクティブであ
ることを示してもよい。したがって、いくつかの実施形態では、アイコン７０６を使用し
たデバイスに関連するアプリケーションの起動は、必要でなくてもよく、遠隔インターフ
ェース７００が、デバイスとペアリングされると、自動化されてもよい。図７Ｂを参照す
ると、いくつかの実施形態では、遠隔インターフェース７００は、ディスプレイアセンブ
リ上に、メモおよび／またはタグをログブックに追加するためのリンクである、種々のボ
タンを含んでもよい。したがって、いくつかの実施形態では、ユーザが、ボタンの１つを
タップすると、メモが、開かれもよく、ユーザは、メモをログブックに追加してもよい。
いくつかの実施形態では、アイコンのタップは、自動的に、その事象をログブック内に登
録してもよい。

遠隔インターフェースの種々の実施形態は、基礎比率、ボーラスアラーム、送達制限、
ユーザプロファイル等を事前にプログラムする能力を含み、ユーザが、履歴、ログブック
等を閲覧し、ユーザ選好を確立することを可能にしてもよい。いくつかの実施形態では、
遠隔インターフェースはまた、グルコース細片リーダを含んでもよい。しかしながら、種
々の実施形態では、遠隔インターフェースが、注入ポンプではなく、他のデバイスと通信
する場合、遠隔インターフェースの能力は、異なってもよい。

使用時、いくつかの実施形態では、遠隔インターフェース６００、７００は、遠隔イン
ターフェース６００、７００と注入ポンプとの間に確立される無線通信チャネルを使用し
て、注入ポンプアセンブリと通信してもよい。故に、ユーザは、遠隔インターフェース６
００、７００を使用して、注入ポンプをプログラム／構成してもよい。いくつかの実施形
態では、遠隔インターフェース６００、７００と注入ポンプとの間の通信の一部または全
部は、向上されたレベルのセキュリティを提供するように、暗号化されてもよい。

ユーザインターフェースの種々の実施形態では、ユーザインターフェースは、ユーザ確
認および／またはユーザ入力を要求してもよい。いくつかの実施形態では、ユーザインタ
ーフェースは、デバイスとの種々の相互作用の効果を把握することを確実にすることに焦
点が当てられる。多くの実施例は、ユーザにユーザの作用の結果を通信するデバイスの本
説明全体を通して提示されるであろう。これらの特徴は、ユーザが、その作用を理解して
いることを確実にし、したがって、ユーザにさらなる安全性をもたらす。そのような実施
例の１つは、ユーザが、値が変化した後、画面上の戻るボタンを押下する場合、ユーザイ
ンターフェースが、「変更を取り消しますか？」とういう確認画面を表示させることであ
る。ユーザが、「はい」を選択する場合、種々の実施形態では、ユーザインターフェース
は、任意の保留中の変更を廃棄し、確認画面を閉じ、前の画面（すなわち、ユーザが戻る
ボタンを押下した画面の前の画面）に戻る。作用選択が、「変更を取り消しますか？」確
認画面上において、「いいえ」であるとき、ユーザは、実施形態に応じて、改行ボタンま
たはその他を押下し、ユーザインターフェースは、確認画面を閉じ、保留中の変更を伴う
画面に戻る。本特徴は、ユーザが、変更が実装されたと仮定するが、実際は、そうではな
いという結果を防止する。したがって、本特徴は、そのような状況を防止し、ユーザが、
変更が実装されていないことを理解することを確実にする。これは、ユーザ確認および／
または入力を要求するユーザインターフェースの多くの実施例のうちの１つにすぎない。

加えて、また、図８を参照すると、デバイスのいくつかの実施形態では、デバイス８０
０は、遠隔インターフェース８０２によって構成されてもよい。いくつかの実施形態では
、デバイス８００は、デバイス８００と少なくとも１つの遠隔インターフェース８０２と
の間の通信（例えば、有線または無線）を可能にし、したがって、遠隔インターフェース
８０２が、デバイス８００と遠隔で通信することを可能にする、テレメトリ回路（図示せ
ず）を含んでもよい。遠隔インターフェース８０２（また、テレメトリ回路（図示せず）
を含み、デバイス８００と通信可能であってもよい）は、種々の実施形態では、ディスプ
レイアセンブリ８０４および少なくとも１つの入力アセンブリ８０６を含んでもよい。入
力アセンブリ８０６は、いくつかの実施形態では、少なくとも１つのスイッチアセンブリ
を含んでもよく、いくつかの実施形態では、制限ではないが、前述の入力アセンブリのう
ちの１つ以上のいずれかを含んでもよい。したがって、いくつかの実施形態では、入力ア
センブリは、ジョグホイール、複数のスイッチアセンブリ、容量スライダ、または同等物
を含んでもよい。

遠隔インターフェース８０２は、デバイスに命令する、および／または情報をデバイス
から受信する能力を含んでもよい。いくつかの実施形態では、遠隔インターフェース８０
２は、履歴を閲覧し、アラームを受信および閲覧し、制限、例えば、送達制限をプログラ
ムし、および／またはユーザ選好を確立するための能力を含んでもよい。いくつかの実施
形態では、遠隔インターフェース８０２は、ユーザが、電力状態、送達状態、読み取られ
た値、アラーム状態、デバイスの進捗度、および／またはデバイスから遠隔インターフェ
ース８０２に通信され得る、任意の他のデータを含み得る、デバイスの状態を閲覧するこ
とを可能にしてもよい。いくつかの実施形態では、遠隔インターフェース８０２は、グル
コース細片リーダおよび／または温度表示デバイス、および／または治療および／または
診断を行なう、および／または医療サービスをユーザに提供するために所望され得る、他
の医療機能性を含んでもよい。

いくつかの実施形態では、遠隔インターフェース８０２は、遠隔インターフェース８０
２とデバイス８００との間に確立された無線通信チャネル８０８を介して、指示をデバイ
ス８００に提供してもよい。故に、ユーザは、遠隔インターフェース８０２を使用して、
デバイス８００をプログラム／構成してもよい。遠隔インターフェース８０２とデバイス
との間の通信の一部または全部は、向上されたレベルのセキュリティを提供するために、
暗号化されてもよい。

遠隔インターフェース８０２とデバイス８００との間の通信は、標準通信プロトコルを
利用して達成されてもよい。さらに、デバイス８００内に含まれる種々の構成要素の間の
通信が、同じプロトコルを使用して達成されてもよい。そのような通信プロトコルの一例
は、ＤＥＫＡ Ｒｅｓｅａｒｃｈ ＆ Ｄｅｖｅｌｏｐｍｅｎｔ（Ｍａｎｃｈｅｓｔｅｒ
， ＮＨ）によって開発されたＰａｃｋｅｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｇａｔｅｗ
ａｙ Ｐｒｏｔｏｃｏｌ（ＰＣＧＰ）である。上記で議論されるように、いくつかの実施
形態では、注入ポンプであり得る、デバイス８００は、１つ以上の電気構成要素を含み得
る、電気制御アセンブリ５１６を含んでもよい。例えば、電気制御アセンブリ５１６は、
複数のデータプロセッサ（例えば、スーパーバイザプロセッサおよびコマンドプロセッサ
）と、デバイス８００が遠隔インターフェース８０２と通信することを可能にするための
無線プロセッサとを含んでもよい。したがって、遠隔インターフェース８０２は、１つ以
上の電気構成要素を含んでもよく、その実施例として、遠隔インターフェース８０２がデ
バイス８００と通信することを可能にするためのコマンドプロセッサおよび無線プロセッ
サが挙げられ得るが、それらに制限されない。そのようなシステムの一例の高レベル線図
が、図８Ｂに示される。

これらの電気構成要素のそれぞれは、異なる構成要素の提供業者から製造されてもよく
、したがって、固有の（すなわち、一意の）通信コマンドを利用してもよい。したがって
、標準通信プロトコルの使用を通して、そのような異種構成要素間の効率的な通信が達成
されてもよい。

ＰＣＧＰは、パケットを構築し、ルーティングするために、デバイス８００および遠隔
インターフェース８０２内のプロセッサ上で使用されてもよい、融通性のある拡張可能な
ソフトウェアモジュールであってもよい。ＰＣＧＰは、種々のインターフェースを抽象化
してもよく、各プロセッサ上で実行されている種々のアプリケーションに統一アプリケー
ションプログラミングインターフェース（ＡＰＩ）を提供してもよい。ＰＣＧＰはまた、
種々のドライバに適応インターフェースを提供してもよい。例証的目的のみで、ＰＣＧＰ
は、所与のプロセッサについて図８Ｃに図示された概念構造を有してもよい。

ＰＣＧＰは、周期的冗長検査（ＣＲＣ）を利用することによって、データ完全性を確保
してもよい。ＰＣＧＰはまた、保証された送達状態を提供してもよい。非制限的実施例と
して、全ての新規メッセージが返信を有するべきである。そのような返信が時間内に返送
されない場合、メッセージがタイムアウトしてもよく、ＰＣＧＰがアプリケーションに対
する否定応答返信メッセージ（すなわち、ＮＡＣＫ）を生成してもよい。したがって、メ
ッセージ返信プロトコルは、アプリケーションがメッセージの送信を再試行すべきかどう
かをアプリケーションに知らせてもよい。

いくつかの実施形態では、ＰＣＧＰはまた、所与のノードからのインフライトメッセー
ジの数を制限してもよく、メッセージ送達に決定論的手法を提供するように、ドライバレ
ベルで流量制御機構と連結されてもよく、パケットをドロップすることなく、個々のノー
ドに異なる分量のバッファを持たせてもよい。ノードにバッファがなくなると、ドライバ
は、他のノードに背圧を提供し、新規メッセージの送信を防止してもよい。

ＰＣＧＰは、データコピーを最小限化するために、共有バッファプール方式を使用して
もよく、かつ相互排除を回避してもよく、これは、アプリケーションへのメッセージを送
信／受信するために使用されるＡＰＩにはわずかに影響を及ぼし、ドライバにはさらに大
きな影響を及ぼし得る。ＰＣＧＰは、ルーティングおよびバッファ所有権を提供する、「
ブリッジ」ベースクラスを使用してもよい。主要なＰＣＧＰクラスは、ブリッジベースク
ラスから下位分類されてもよい。いくつかの実施形態では、ドライバは、ブリッジクラス
から導出されるか、または導出ブリッジクラスと通信するか、あるいはそれを所有しても
よい。

いくつかの実施形態では、ＰＣＧＰは、いくつかの呼び出しが再入可能であり、複数ス
レッド上で作動することができるように、共有データを保護するためにセマフォを使用す
ることによって、オペレーティングシステムの有無を問わず、埋め込み環境で稼働するよ
うに設計されてもよい。そのような実装の１つの非制限的例証的実施例の１つが、図８Ｄ
に示される。ＰＣＧＰは、両方の環境で同じ方法で動作してもよいが、特定のプロセッサ
タイプ（例えば、ＡＲＭ９／ＯＳバージョン）に対する呼び出しのバージョンがあっても
よい。したがって、いくつかの実施形態では、機能性は同じであってもよいが、例えば、
ＡＲＭ ９ Ｎｕｃｌｅｕｓ ＯＳ環境に合せた、わずかに異なる呼び出しを伴うオペレ
ーティングシステム抽象化層があってもよい。

図８Ｅも参照すると、ＰＣＧＰは、以下を行ってもよい。
・複数の送信／返信呼び出しが生じることを可能にする
・異なるインターフェース上のＲＸおよびＴＸについて非同期的に作動する複数のドラ
イバを有する、および／または
・送信／受信のためのパケット順序付け、およびメッセージ送信の決定論的タイムアウ
トを提供する

いくつかの実施形態では、各ソフトウェアオブジェクトは、使用する次のバッファをバ
ッファマネジャに求めてもよく、次いで、そのバッファを別のオブジェクトに与えてもよ
い。バッファは、ある独占オーナから別のオーナに自動的に渡ってもよく、キューは、シ
ーケンス番号別にバッファを順序付けることによって、自動的に発生してもよい。いくつ
かの実施形態では、バッファがもはや使用されていないときは、バッファはリサイクルさ
れてもよい（例えば、オブジェクトが、バッファを自身に与えようとするか、または後で
再割り当てするようにバッファマネジャに対して解放する）。したがって、いくつかの実
施形態では、データは、概して、コピーされる必要がなく、ルーティングは、単純にバッ
ファオーナバイトを上書きする。

ＰＣＧＰのそのような実装は、種々の有益性を提供し得、その実施例は、以下を含み得
るが、それらに制限されない。
・メッセージがバッファに入ると、アプリケーションによって転送または受信されるま
でメッセージがそこで存続し得るため、バッファの欠如によるメッセージのドロップが不
可能であり得る。
・ドライバ、ＰＣＧＰ、およびバッファのペイロードセクションにアクセスするために
オフセットが使用されるため、データがコピーされなくてもよい。
・ドライバは、１バイト（すなわち、バッファ所有権バイト）を上書きすることによっ
て、メッセージデータの所有権を交換してもよい。
・単一のバッファオーナがバッファを同時に使用すること、または新規シーケンス番号
を獲得することを望み得るときだけに、相互排除が必要とされ得るため、再入可能呼び出
しを除く複数の排除の必要性がなくてもよい。
・アプリケーションライターが信頼性のあるシステムを実装するように従うためのルー
ルがより少なくあり得る。
・ドライバからバッファ管理システムの外へデータをプッシュ／プルするように提供さ
れた、一式の呼び出しがあるため、ドライバは、ＩＳＲ／プッシュ／プル／およびポーリ
ングしたデータモデルを使用してもよい。
・ドライバがコピー、ＣＲＣ、または何らかのチェックを行わなくてもよいが、宛先バ
イトおよびＣＲＣならびに他のチェックが後でＩＳＲホットパスから行われ得るため、ド
ライバは、ＴＸおよびＲＸ以外、ほとんど稼働しなくてもよい。
・バッファマネジャがシーケンス番号別にアクセスを順序付け得るため、キューの順序
付けが自動的に生じ得る。
・小さなコード／可変専有エリアが利用されてもよい、すなわち、ホットパスコードが
小さくてもよく、オーバーヘッドが低くなり得る。

図８Ｆに示されるように、メッセージを送信する必要があるときに、ＰＣＧＰは、迅速
にパケットを構築してもよく、それをバッファ管理システムに挿入してもよい。バッファ
管理システムの中に入ると、「ｐａｃｋｅｔＰｒｏｃｅｓｓｏｒ」への呼び出しは、プロ
トコルの規則を適用してもよく、ドライバ／アプリケーションにメッセージを与えてもよ
い。

新規メッセージを送信する、または返信を送信するために、ＰＣＧＰは、以下のうちの
１つ以上を行なってもよい。
・例えば、パケット長が合法であること、宛先が正しいこと等を確認するように、呼び
出し引数をチェックする。
・ダウンリンクが、リンク、ペア等を確立するためにＰＣＧＰが無線プロセッサによっ
て使用されることを可能にしてもよい、およびＰＣＧＰが（タイムアウトする代わりに）
機能していないリンク上で通信しようとしているときにアプリケーションに通知してもよ
い、いくつかの実施形態では、無線リンクでない限り、ダウンしているリンク上でメッセ
ージを送信しようとすることを回避する。
・新規メッセージのシーケンス番号を取得する、または既存のメッセージの既存のシー
ケンス番号を利用する。
・パケットを構築し、ペイロードデータをコピーし、ＣＲＣに書き込み、（この時点以
降）パケットの完全性がＣＲＣによって保護されてもよい。および／または
・返信または新規メッセージとして、メッセージをバッファマネジャに与え、このバッ
ファをバッファマネジャに入れることが、待機状態の送信メッセージの最大数を超えるか
どうかを確かめる。

また、図８Ｇ−８Ｈを参照すると、いくつかの実施形態では、相互排除を回避するよう
に、および送信／返信またはドライバ呼び出しに多大な作業を行うことを回避するように
、１つのスレッドに主要な作業の全てを行うことによって、ＰＣＧＰが稼働してもよい。
「ｐａｃｋｅｔＰｒｏｃｅｓｓｏｒ」呼び出しは、返信、新規送信メッセージ、および受
信メッセージにプロトコル規則を適用する必要があってもよい。返信メッセージは、単純
に送られてもよいが、新規メッセージおよび受信メッセージには、メッセージを送るため
の規則があってもよい。それぞれの場合において、ソフトウェアは、パケットを処理する
ことができなくなるまで、正しい種類のメッセージがプロトコル規則を適用することが可
能である間に、ループしてもよい。

新規メッセージの送信は、いくつかの実施形態では、以下の規則のうちの１つ以上に従
ってもよい。
・２つだけのメッセージが、ネットワーク上の許可された「インフライト」であっても
よい。および／または
・応答に一致し、タイムアウトに対処するように、インフライトメッセージに関する十
分なデータが記憶されてもよい。
メッセージの受信は、以下の規則に従ってもよい。
・一致する応答が「インフライト」情報スロットをクリアしてもよいため、新規パケッ
トを送信することができる。
・一致しない応答がドロップされてもよい。
・新規メッセージは、プロトコルに対するものであってもよい（例えば、このノードに
対するネットワーク統計を取得／クリアする）。
・メッセージを受信するために、バッファがアプリケーションに与えられてもよく、コ
ールバックを使用してもよい。および／または
・バッファが解放されるか、またはアプリケーションによって所有されたままであって
もよい。
したがって、いくつかの実施形態では、ＰＣＧＰは、以下のように構成されてもよい。
コールバック機能は、ペイロードデータアウトをコピーしてもよく、または戻る前にそれ
を完全に使用してもよい。
・コールバック機能は、戻る前にそれを完全に行うまたは使用するペイロードデータを
コピーしてもよい。
・コールバック機能は、バッファを所有してもよく、バッファおよびペイロードアドレ
スによるバッファのペイロードを参照してもよく、メッセージは、後で処理されてもよい
。
・アプリケーションは、受信したメッセージについてＰＣＧＰシステムをポーリングし
てもよい、および／または
・アプリケーションは、事象を設定するためにコールバックを使用し、次いで、受信メ
ッセージについてポーリングしてもよい。

通信システムは、制限数のバファを有してもよい。ＰＣＧＰにバッファがなくなると、
ドライバは、新規パケットを受信することを止めてよく、アプリケーションは、アプリケ
ーションが新規パケットを送信できないことを告げられてもよい。このことを回避し、最
適な性能を維持するために、アプリケーションは、１つ以上の手順を行おうとしてもよく
、その例は、以下を含み得るが、それらに制限されない。
ａ）アプリケーションは、ＰＣＧＰを無線状態で最新の状態に保ってもよい。具体的に
は、いくつかの実施形態では、リンクがダウンし、ＰＣＧＰが認識していない場合、ＰＣ
ＧＰは、送信する新規メッセージを受け取り、待ち行列に入れてもよく（または、最適に
メッセージをタイムアウトしなくてもよい）、これは、送信キューを妨害し、リンクを最
適に使用することからアプリケーションを遅延させる場合がある。
ｂ）アプリケーションは、「タイムアウトをデクリメントする」を定期的に呼び出して
もよい。最適には、いくつかの実施形態では、アプリケーションは、プロセッサがスリー
プしていない限り、２０〜１００ミリ秒ごとに、「タイムアウトをデクリメントする」を
呼び出してもよい。一般に、メッセージは、速く移動する（数ミリ秒）、遅く移動する（
数秒）、または全く移動しない。タイムアウトは、いくつかの実施形態では、バッファお
よび帯域幅を解放するようにドロップされるべきである「インフライト」メッセージを除
去しようとする試行である。これをあまり頻繁に行わないと、新規メッセージが送信され
るとき、またはアプリケーションが新規メッセージを待ち行列に入れるときを遅延させる
場合がある。
ｃ）アプリケーションは、スリープに入る前に保留中の行うべき作業があるかどうかを
ＰＣＧＰに尋ねてもよい。したがって、いくつかの実施形態では、ＰＣＧＰに行うべき作
業がない場合、ドライバアクティビティがシステム、ひいては、ＰＣＧＰをウェークアッ
プしてもよく、したがって、新規パケットがシステムに進入するまで、ＰＣＧＰは、「ｐ
ａｃｋｅｔＰｒｏｃｅｓｓｏｒ」または「タイムアウトをデクリメントする」への呼び出
しを必要としない。いくつかの実施形態では、これを行うことに失敗すると、タイムアウ
ト状態により、送信／転送／受信が成功するはずだったメッセージがドロップされる場合
がある。
ｄ）アプリケーションは、受信メッセージを無期限に持ち続けるべきではない。メッセ
ージシステムは迅速な返信に依存する。アプリケーションがＰＣＧＰバッファを共有して
いれば、メッセージを持ち続けることは、ＰＣＧＰバッファを持ち続けることを意味する
。いくつかの実施形態では、受信ノードの受信は、送信ノードに、低速または高速無線通
信のために構成されたタイムアウトがあるかどうかを認識していない。このことは、ノー
ドがメッセージの受信に応じて、ネットワークの高速タイムアウト速度を測定するべきで
あることを意味する。および／または
ｅ）アプリケーションは、「ｐａｃｋｅｔＰｒｏｃｅｓｓｏｒ」を頻繁に呼び出しても
よい。いくつかの実施形態では、呼び出しは、アプリケーションによって待ち行列に入れ
られた新規メッセージを送信させてもよく、新規メッセージの受信に対処してもよい。呼
び出しはまた、バッファを再割り当てさせてもよく、あまり頻繁に呼び出さないと、メッ
セージトラフィックを遅延させる場合がある。

図８Ｉに示されるように、いくつかの実施形態では、ある時点で、ＲＸドライバは、イ
ンターフェースの反対側からメッセージを受信するように求められてもよい。いくつかの
実施形態では、メッセージがドロップされないことを確実にするために、ＲＸドライバは
、新規メッセージを記憶するために利用可能なバッファがあるかどうかをバッファマネジ
ャに尋ねてもよい。次いで、ドライバは、バッファポインタを求めてもよく、受信データ
でバッファを充填し始めてもよい。完全なメッセージが受信されると、ＲＸドライバは、
パケットをルーティングする機能を呼び出してもよい。ルーティング機能は、パケットヘ
ッダにおける宛先バイトを検査してもよく、いくつかの実施形態では、以下のうちの１つ
以上を行なう：他のドライバおよび／またはアプリケーションにオーナを変更してもよく
、および／またはパケットが不良であることを検出してもよく、かつバッファを解放する
ことによってパケットをドロップしてもよい。

ＰＣＧＰ ＲＸオーバーヘッドは、次の利用可能なバッファを求めること、およびルー
ト機能を呼び出すことから成ってもよい。そのような機能を果たすコードの非制限的実施
例は、以下の通りである。
＠ Ｒｅｃｅｉｖｅ ｒｅｑｕｅｓｔ
ｕｉｎｔ８ ｉ＝ ０，＊ｐ；
ｉｆ （Ｂｒｉｄｇｅ：：ｃａｎＲｅｃｅｉｖｅＦｌｏｗＣｏｎｔｒｏｌ（） ）
｛
ｐ ＝ Ｂｒｉｄｇｅ：：ｎｅｘｔＢｕｆｆｅｒＲＸ（）；
ｗｈｉｌｅ （ｎｏｔ ｄｏｎｅ） ｛ ｐ［ｉ］ ＝ ｔｈｅ ｎｅｘｔ ｂ
ｙｔｅ； ｝
Ｂｒｉｄｇｅ：：ｒｏｕｔｅ（ｐ）；
｝

ドライバは、次の送信するバッファへのポインタをバッファマネジャに求めることによ
って、ＴＸを行ってもよい。次いで、ＴＸドライバは、パケットを受け取ることができる
かどうかをインターフェースの反対側に尋ねてもよい。反対側がパケットを拒否する場合
、ＴＸドライバは、その状態が変化していないため、バッファに何もしなくてもよい。そ
うでない場合、ドライバは、パケットを送信してもよく、かつバッファをリサイクル／解
放してもよい。そのような機能を果たすコードの非制限的実施例は、以下の通りである。
ｕｉｎｔ８ ＊ｐ ＝ Ｂｒｉｄｇｅ：：ｎｅｘｔＢｕｆｆｅｒＴＸ（）；
ｉｆ （ｐ ！＝ （ｕｉｎｔ８ ＊）０）
｛
ｓｅｎｄ ｔｈｅ ｂｕｆｆｅｒ ｐ；
Ｂｒｉｄｇｅ：：ｒｅｃｙｃｌｅ（ｐ）；
｝

最大メッセージシステムタイムアウト時間を超えたパケットを転送することを回避する
ために、いくつかの実施形態では、ｎｅｘｔＢｕｆｆｅｒを求めることにより、解放する
バッファをスキャンし得る、ＢｕｆｆｅｒＭａｎａｇｅｒ：：ｆｉｒｓｔ（ｕｉｎｔ８
ｏｗｎｅｒ）関数を呼び出してもよい。したがって、タイムアウトの可能性がない完全Ｔ
Ｘバッファは、バッファを所有するスレッド上で解放されてもよい。いくつかの実施形態
では、ＴＸを行っている（すなわち、次のＴＸバッファを探しながら）ブリッジは、処理
のために次のＴＸバッファを受信する前に期限切れになるＴＸバッファの全てを解放して
もよい。

図８Ｊ−８Ｌに示されるように、いくつかの実施形態では、バッファ割り当てプロセス
中に、使用可能とマークされたバッファは、新規パケットを受信するようにドライバへ、
またはＴＸに対する新規ペイロードを受信するようにＰＣＧＰに転送されてもよい。「使
用可能」からの割り当ては、「ｐａｃｋｅｔＰｒｏｃｅｓｓｏｒ」機能によって行われて
もよい。「ｐａｃｋｅｔＰｒｏｃｅｓｓｏｒ」呼び出しの間の送信および受信の数は、い
くつのＬＴ＿Ｄｒｉｖｅｒ＿ＲＸ、ＧＴ＿Ｄｒｉｖｅｒ＿ＲＸ、およびＰＣＧＰ＿Ｆｒｅ
ｅバッファを割り当てる必要があるかを決定してもよい。ＬＴ＿Ｄｒｉｖｅｒは、ノード
アドレスよりも少ないアドレスを取り扱うドライバを表してもよい。ＧＴ＿Ｄｒｉｖｅｒ
は、ノードアドレスよりも多いアドレスを取り扱うドライバを表してもよい。

ドライバがパケットを受信すると、ドライバは、ルータに渡されるＲＸバッファにデー
タを入れてもよい。次いで、ルータは、バッファをＰＣＧＰ＿Ｒｅｃｅｉｖｅまたは他の
ドライバのＴＸ（図示せず）に再割り当てしてもよい。バッファが明らかに無効なデータ
を含有する場合、バッファは使用可能状態に移行してもよい。

ルータがＴＸに対するバッファをマークした後、ドライバは、バッファがＴＸであるこ
とを発見してもよく、かつメッセージを送信してもよい。メッセージを送信した後、ドラ
イバにＲＸバッファが不足していれば、バッファは即座にＲＸバッファになってもよく、
または、バッファが再割り当てのために解放されてもよい。

「ｐａｃｋｅｔＰｒｏｃｅｓｓｏｒ」呼び出し中、ＰＣＧＰは、ルータがＰＣＧＰ＿Ｒ
ｅｃｅｉｖｅとしてマークした全てのバッファを処理してもよい。この時点で、データが
作用を受けてもよいため、ＣＲＣおよび他のデータアイテムがチェックされてもよい。デ
ータが破損されていれば、統計値がインクリメントされてもよく、バッファが解放されて
もよい。そうでない場合、バッファは、アプリケーションによって所有されているとマー
クされてもよい。アプリケーションによって所有されているとマークされたバッファは、
ＰＣＧＰの使用のためにリサイクルされるか、またはバッファマネジャによる再割り当て
のために解放されてもよい。

いくつかの実施形態では、アプリケーションが新規メッセージを送信したいときは、再
入可能な分かりやすい／相互排除様式で行われてもよい。バッファが割り当てられてもよ
い場合、ＰＣＧＰは、バッファを使用中とマークしてもよい。使用中とマークされると、
送信または返信機能の呼び出しの発動によって所有されているため、この機能を呼び出す
他のスレッドのいずれも、このバッファを捕らえてはいけない。誤差チェックを行い、メ
ッセージを作成するプロセスの残りは、孤立競合状態相互排除保護コードの外側で行われ
てもよい。バッファは、使用可能状態に遷移してもよく、または、有効な充填したＣＲＣ
チェックされたバッファになり、ルータに渡されてもよい。いくつかの実施形態では、こ
れらのバッファは、即座に送られなくてもよく、後でメッセージを送ることができるよう
に待ち行列に入れられてもよい（プロトコル規則が許容すると仮定する）。返信メッセー
ジが通常の送信メッセージよりも高い優先度で送られてもよく、返信メッセージには、い
くつ／いつ送ることができるかを制限する規則がなくてもよいため、返信メッセージは、
新規送信メッセージとは異なってマークされてもよい。

いくつかの実施形態では、ＰＣＧＰは、流量制御と協働し、流量制御は、インターフェ
ースの反対側にバッファが欠けている（これが送信ノード上で背圧を引き起こす場合があ
る）ため、バッファが決してドロップされないように、１つのノードから別のノードへの
メッセージの転送について交渉してもよい。

流量制御は、共有バッファ形式の一部であってもよい。いくつかの実施形態では、最初
の２バイトは、ドライバが決してパケットバイトをシフトする必要がないように、ドライ
バのために留保されてもよい。２バイトは、１バイトがＤＭＡ長−１であり、第２のバイ
トがメッセージの流れを制御するものであるように、使用されてもよい。これらの同じ２
バイトは、ＰＣＧＰメッセージがＲＳ２３２上で伝送される場合に、バイトを同期化して
もよい。種々の他の構成およびサイズが、種々の実施形態では、使用されてもよい。

いくつかの実施形態では、パケットが「インフライト」であるときに、パケットは、そ
の宛先の途中でドライバによって送信される、宛先によって処理される、または応答とし
て返送されるプロセスにあってもよい。
典型的な遅延は、以下の通りである。

したがって、いくつかの実施形態では、メッセージは、往復を迅速に完了する（例えば
、＜５０ｍｓ）、ゆっくりと完了する（例えば、１秒以上）、または全く完了しない傾向
がある。

種々の実施形態では、ＰＣＧＰは、全てのタイムアウトに２つの異なる時間（初期化に
おいて設定される）を使用してもよく、１つは、ＲＦリンクが高速ハートビートモードで
あるときに対するもので、もう１つは、ＲＦリンクが低速モードであるときに対するもの
である。しかしながら、他の実施形態では、ＰＣＧＰは、３つ以上または２つ未満の異な
る時間を使用してもよい。いくつかの実施形態では、メッセージがインフライトであり、
リンク状態が高速から低速に変化する場合、タイムアウトが調整されてもよく、高速と低
速との間の差が、パケットに対する有効期限カウンタに追加されてもよい。前後への付加
的な遷移のいずれも、メッセージに対する有効期限に影響を及ぼしてはいけない。

いくつかの実施形態では、ＰＣＧＰ内のバッファ割り当てを監視するために使用される
、低速タイムアウトの２倍の長さであり得る、第２のタイムアウトがある。したがって、
例えば、流量制御またはハードウェア破損により、メッセージがドライバ内に「取り残さ
れ」、送信されていない場合、バッファは、バッファマネジャによって解放されてもよく
、バッファをドロップさせる。「新規」メッセージについては、これは、パケットがすで
にタイムアウトし、メッセージが送達されなかったという返信がすでにアプリケーション
に与えられたことを意味してもよく、バッファを解放させる。ドライバが、送信される必
要のあるバッファに対するバッファマネジャをポーリングするため、次に障害物を取り除
くときに、送信することができるメッセージがドライバに渡されるように、バッファが解
放される。返信メッセージについては、返信が単純にドロップされてもよく、送信ノード
がタイムアウトしてもよい。

いくつかの実施形態では、ＰＣＧＰメッセージングシステムは、ヘッダ情報およびペイ
ロードを含有するメッセージをパスしてもよい。しかしながら、種々の実施形態では、Ｐ
ＣＧＰメッセージングシステムは、異なる情報を含有するメッセージをパスしてもよい。
ＰＣＧＰの外側では、ヘッダは、呼び出し署名の中の一式のデータアイテムであってもよ
い。いくつかの実施形態では、しかしながら、ＰＣＧＰ内部には、一貫したドライバが使
用しやすいバイトレイアウトがあってもよい。いくつかの実施形態では、ドライバは、以
下のように、ＰＣＧＰパケットの中に、またはＰＣＧＰパケットの前にバイトを挿入して
もよい。
・ＤＥ、ＣＡ：ＲＳ２３２とともに使用するための同期バイトで、０ｘＤＥ、０ｘＣＡ
または０ｘ５Ａ、０ｘＡ５の公称値。
・ＬＤ：ドライバＤＭＡ長バイトで、サイズバイトまたは同期バイトを含まない合計サ
イズである、このＤＭＡ転送においてドライバがプッシュ配信している量に等しい。
・Ｃｍｄ：流量制御のために使用される、ドライバコマンドおよび制御バイト。
・ＬＰ：ＰＣＧＰパケット長で、常に、バイト＋ＣＲＣサイズにおいて合計ヘッダ＋ペ
イロードサイズである。ＬＤ＝ＬＰ＋１である。
・Ｄｓｔ：宛先アドレス。
・Ｓｒｃ：ソースアドレス。
・Ｃｍｄ：コマンドバイト。
・Ｓｃｄ：サブコマンドバイト。
・ＡＴ：アプリケーションタグは、アプリケーションによって定義され、ＰＣＧＰにと
って重要性を持たない。これは、アプリケーションが、メッセージに、例えば、メッセー
ジの起源となったスレッド等、さらなる情報を添付することを可能にする。
・ＳｅｑＮｕｍ：３２ビットのシーケンス番号が、送信された新規メッセージに対して
ＰＣＧＰによってインクリメントされ、番号が切り上げられず、トークンの役割を果たし
、エンディアンネスが無関係であることを保証する。
・ＣＲＣ１６：ＰＣＧＰヘッダおよびペイロードの１６ビットＣＲＣ。

ペイロードがなく、ｃｍｄ＝１、ｓｕｂｃｍｄ＝２であるメッセージの例は、以下の通
りである。
０ｘＤＥ，０ｘＣＡ，０ｘＣ，０ｘ５，０ｘ１４，１，２，０，０，０，０，０ｘ１，
ｃｒｃｈｉｇｈ，ｃｒｃｌｏｗ．
０ｘ０Ｄ，ｃｍｄ，０ｘＣ，０ｘ５，０ｘ１４，１，２，０，０，０，０，０ｘ１，ｃ
ｒｃｈｉｇｈ，ｃｒｃｌｏｗ．

この方法論には、いくつかの利点があり得、その例は、以下を含み得るが、それらに制
限されない。
・種々の実施形態では、ハードウェアＤＭＡエンジンの大部分は、いくつの追加バイト
を動かすのかを定義するために、第１のバイトを使用してもよく、したがって、この方法
論では、ドライバおよびＰＣＧＰは、バッファを共有してもよい。
・ドライバ間で流量制御情報を渡すように、ＤＭＡ長の直後にバイトが提供されてもよ
い。
・ドライバ長および「Ｃｍｄ」バイトがＣＲＣ領域の外側にあり得るため、それらは、
ドライバによって改変されてもよく、ドライバ輸送機構によって所有されてもよく、ドラ
イバは、無効な長さについて警戒してもよい。
・ＣＲＣ保護される、別個のＰＧＣＰパケット長バイトがあってもよい。したがって、
アプリケーションは、そのペイロード長が正しいことを信頼してもよい。
・シーケンス番号のエンディアンネスは、同様に、偶然３２ビットの整数である、一致
させられ得るバイトパターンすぎないため、関連性がなくてもよい。
・シーケンス番号は、共有バッファプール長の縁に整列した、４バイトであってもよい
。
・メッセージストリームをデバッグしながら、ユーザがケーブルをあちこちに動かして
もよく、インターフェースの両側が再同期化してもよいように、オプションのＲＳ２３２
同期バイトがあってもよい。
・アプリケーション、ドライバ、およびＰＣＧＰは、バッファを共有してもよく、それ
らをポインタによって解放してもよい。

いくつかの実施形態では、ＰＣＧＰは、事象駆動タイプソフトウェア設計でなくてもよ
いが、サブクラスが書き込まれる方法によって、事象駆動タイプアーキテクチャで使用さ
れてもよい。データは、（図８Ｍ−８Ｎに示されるように）概念的にクラス間で交換され
てもよい。

いくつかの実施形態では、ドライバにおけるいくつかの事象モデルは、ドライバをウェ
ークしてもよく、メッセージを受信してもよく、（ドライバまたはＰＣＧＰへのブリッジ
を通して）新規メッセージの新規オーナにメッセージを送るバッファマネジャの中へ、ブ
リッジを通してメッセージを渡してもよい。

以下は、いくつかの例示的事象を要約する。

以下の例示的実施例は、全ての送信されたメッセージ、返信、またはＮＡＣＫを生成し
たｄｅｃタイムアウトの後に、ＰＣＧＰタスクをウェークアップするように、どのように
ＰＣＧＰ事象モデルがＮｕｃｌｅｕｓと連動し得るかを示す。
ｃｌａｓｓ ＰｃｇｐＯＳ ： ｐｕｂｌｉｃ Ｐｃｇｐ
｛
ｖｉｒｔｕａｌ ｖｏｉｄ ｓｃｈｅｄｕｌｅＰａｃｋｅｔＰｒｏｃｅｓｓｏｒ（ｖｏ
ｉｄ）
｛
ＯＳ＿ＥｖｅｎｔＧｒｐ＿Ｓｅｔ（ｇ＿ＲＣＶＥｖＧｒｐｓ［ＥＶＧ＿ＲＦ＿ＴＡＳＫ
］．ｐＥｖｇＨａｎｄｌｅ，
ＲｆＲａｄｉｏＴｘＥｖｅｎｔ， ＯＳ＿ＥＶ＿ＯＲ＿ＮＯ＿ＣＬＥＡＲ）；
｝
｝

以下は、ドライバ事象がどのように稼働するかを例証する、事象ベースの疑似コードド
ライバである。ＤｒｉｖｅｒがＢｒｉｄｇｅを下位分類し、ｈａｓＭｅｓｓａｇｅｓＴｏ
ＳｅｎｄおよびｆｌｏｗＣｏｎｔｒｏｌＴｕｍｅｄＯｆｆを無効にして、ＴＸおよびＲＸ
機能がすでに作動していない場合、それらを作動するように予定する。
ｃｌａｓｓ ＳＰＩ＿Ｄｒｉｖｅｒ ： ｐｕｂｌｉｃ Ｂｒｉｄｇｅ
｛
ｖｉｒｔｕａｌ ｖｏｉｄ ｈａｓＭｅｓｓａｇｅｓＴｏＳｅｎｄ（）
｛
Ｔｒｉｇｇｅｒ＿ＩＳＲ（ＴＸ＿ＩＳＲ， ｔｈｉｓ）；
｝
ｖｉｒｔｕａｌｖｏｉｄｆｌｏｗＣｏｎｔｒｏｌＴｕｒｎｅｄＯｆｆ（）
｛
Ｔｒｉｇｇｅｒ＿ＩＳＲ（ＲＸ＿ＩＳＲ， ｔｈｉｓ）；
｝
ｓｔａｔｉｃ ｖｏｉｄ ＴＸ＿ＲｅｔｒｙＴｉｍｅｒ （）
｛
Ｔｒｉｇｇｅｒ＿ＩＳＲ（ＴＸ＿ＩＳＲ， ｔｈｉｓ）；
｝
ｓｔａｔｉｃ ｖｏｉｄＴＸ＿ＩＳＲ（Ｂｒｉｄｇｅ ^＊ｂ）
｛
ＤｉｓａｂｌｅＩＳＲｓ（）；
ｄｏ
｛
ｕｉｎｔ８ ^＊ｐ ＝ ｂ−＞ｎｅｘｔＢｕｆｆｅｒＴＸ（）；
ｉｆ （ｐ ＝＝ ｎｕｌｌ） ｂｒｅａｋ；
ｉｆ （ｂ−＞＿ｂｕｆｆｅｒＭａｎａｇｅｒ−＞ｂｕｆｆｅｒＴｉｍｅｄＯｕｔ（ｐ
）＝＝ｆａｌｓｅ）
｛
ｉｆ （ＯｔｈｅｒＳｉｄｅＳＰＩ＿ＦｌｏｗＣｏｎｔｒｏｌ（） ＝＝ ｆａｌｓｅ
）
｛
Ｔｒｉｇｇｅｒ ＴＸ＿ＲｅｔｒｙＴｉｍｅｒ ｉｎ ２０ ｍｓｅｃ．
ｂｒｅａｋ；
｝
ｓｅｎｄ（ｐ）；
｝
ｆｒｅｅ（ｐ）；
｝ｗｈｉｌｅ （ｔｒｕｅ） ；
ＥｎａｂｌｅＩＳＲｓ（）；
｝
ｓｔａｔｉｃ ｖｏｉｄ ＲＸ＿ＩＳＲ（Ｂｒｉｄｇｅ ^＊ｂ）
｛
ＤｉｓａｂｌｅＩＳＲｓ（）；
ｄｏ
｛
ｕｉｎｔ８^＊ ｐ ＝ ｂ−＞ｎｅｘｔＢｕｆｆｅｒＲＸ（）；
ｉｆ （ｐ ＝＝ ｎｕｌｌ） ｂｒｅａｋ；
ｕｉｎｔ ｉ；
ｗｈｉｌｅ （ｎｏｔ ｄｏｎｅ ｒｅｃｅｉｖｉｎｇ）
ｐ［ｉ＋＋］ ＝ ｇｅｔＣｈａｒ（）；
ｂ−＞ｒｏｕｔｅ（ｐ）；
｝ ｗｈｉｌｅ （ｔｒｕｅ） ；
ＥｎａｂｌｅＩＳＲｓ（）；
｝
｝

制限されないが、１つ以上の統計が、ＰＣＧＰによってサポートされてもよい。
・送信されたパケットの数
・受信されたパケットの数
・ＣＲＣ誤差
・タイムアウト
・利用不可能なバッファ（バッファがなくなった）

種々の実施形態では、ＰＣＧＰは、複数の処理環境中で作動するように設計されてもよ
い。ほとんどのパラメータは、試験、および性能のランタイム微調整を促進するため、ラ
ンタイム構成されてもよい。他のパラメータは、コンパイル時間であってもよく、例えば
、コンパイル時間において静的に行われなければならないメモリ割り当てを改変する、あ
らゆるものであってもよいが、依然として、その他のパラメータが、種々の実施形態では
使用されてもよい。

以下は、ＰＣＧＰが実装される場所を変動させ得る、コンパイル時間構成の数の定義で
あり得る。
・ドライババイト数：ドライバに対する共通バッファスキームに留保される、２バイト
であってもよいが、いくつかの実施形態では、これは、ＲＦプロトコル等の他のドライバ
に適応するコンパイル時間オプションであってもよい。
・ＲＸドライババッファ数：そのプロセッサ／トラッフィクフロー等に所望されるバッ
ファの数に同調されてもよい。
・ＰＣＧＰ ＲＸバッファ数：そのプロセッサ／トラッフィクフロー等に所望されるバ
ッファの数に同調されてもよい。
・バッファの総数：そのプロセッサに所望されるバッファの数に同調されてもよい。

いくつかの実施形態では、ＣＲＣは、データ完全性を確保するために使用されてもよい
。いくつかの実施形態では、ＣＲＣが無効であれば、それはアプリケーションに送達され
なくてもよく、ＣＲＣ誤差が追跡されてもよい。メッセージは、最終的にタイムアウトし
てもよく、発信元によって再試行されてもよい。

同様に、メッセージが送達されなかったときに送達されたとメッセージングシステムが
アプリケーションに知らせる場合、これは、システムにとって望ましくあり得ない。ボー
ラス停止コマンドが、そのようなコマンドの実施例である。これは、治療法を変更するた
めにアプリケーションによって必要とされ得る、メッセージの要求／アクションシーケン
スによって軽減され得る。いくつかの実施形態では、遠隔インターフェース８０２は、デ
バイス８００アプリケーションからマッチングコマンドを受信し、送達されたメッセージ
を検討してもよい。

いくつかの実施形態では、（図８Ｏに示されるように）ＡＲＭ９上のＮｕｃｌｅｕｓ
ＯＳシステムにＰＣＧＰをインターフェース接続する参照方法を使用してもよい。

図８Ｐに示されるように、ｐｃｇｐＯＳ．ｃｐｐファイルは、ＰＣＧＰノードインスタ
ンス（Ｐｃｇｐ、Ｂｒｉｄｇｅ等）のインスタンスを作成してもよく、Ｃ＋＋コードに「
Ｃ」言語インターフェースを提供する、「Ｃ」リンク可能な一式の関数呼び出しを、ｐｃ
ｇｐＯＳ．ｈを通して提供してもよい。これは、作用を受けるオブジェクトとしての「Ｃ
」コードが暗示的であることを単純化し得る。
いくつかの実施形態では、以下の一般規則が適用されてもよい。
・ＰＣＧＰは、全てのノード上で作動してもよい。任意のドライバが、一般的ドライバ
インターフェースをサポートしてもよい。
・競合状態が許容されなくてもよい。
・スレーブプロセッサとマスタプロセッサとの間のＳＰＩポート上で半二重をサポート
してもよい。
・成功するか、または失敗／偽を戻すため、データ転送が試行されなくてもよい。
・低オーバーヘッド（浪費された時間、処理、帯域幅）を必要としてもよい。
・ＤＭＡ（高速）ＳＰＩクロック比率で動作するＣＣ２５１０をサポートしてもよい。

いくつかの実施形態では、受信側に、パケットを配置するための空のバッファが現在な
い場合、ＳＰＩ流量制御は、データが送信されることを防止してもよい。いくつかの実施
形態では、これは、送信する許可を求め、そうする許可が与えられたことを示す応答を待
機することによって、達成されてもよい。いくつかの実施形態では、別の方法が、現在空
いたバッファがなく、後で転送を試行するべきであると相手側に示すために使用されても
よい。

いくつかの実施形態では、全ての伝送は、長さバイト自体を含まない、送信されるバイ
トの数を示す長さバイトで開始してもよい。長さに続くのは、送信されているコマンドを
示す単一バイトであってもよい。

いくつかの実施形態では、パケットの実際の伝送は、コマンドバイトについては、パケ
ットの長さプラス１であってもよく、それに続いて、添付されたメッセージに対するコマ
ンドバイト、最終的にパケット自体がある。しかしながら、他の実施形態では、パケット
の伝送は、異なってもよい。

送信されるコマンドバイトに加えて、流量制御ラインと呼ばれる追加ハードウェアライ
ンが、従来の４つのＳＰＩ信号に追加されてもよい。本ラインは、事前設定された遅延な
しで、可能な限り迅速にプロトコルが作動することを可能にするために使用されてもよい
。それはまた、送信されるのを待機しているパケットがあることを、スレーブプロセッサ
がマスタプロセッサに伝えることを可能にし、したがって、マスタプロセッサが状態につ
いてスレーブプロセッサにポーリングする必要性を排除する。

以下の例示的コマンド値が、いくつかの実施形態では、使用されてもよい。
マスタプロセッサによって送信されるコマンド：

スレーブプロセッサによって送信されるコマンド：

図８Ｑに図示されるように、スレーブプロセッサが、マスタプロセッサに送信するパケ
ットを有するとき、スレーブプロセッサは、送信されるのを待機している保留中のパケッ
トがあることを、（例えば、流量制御ラインをアサートすることによって）マスタプロセ
ッサに通知してもよい。そうすることにより、マスタプロセッサ上のＩＲＱをもたらして
もよく、その時点で、マスタプロセッサが、スレーブプロセッサからメッセージを回収す
るときを決定してもよい。パケットの回収は、マスタプロセッサの判断で遅延させられて
もよく、マスタプロセッサは、スレーブプロセッサから回収する前に、スレーブプロセッ
サへのパケットの送信を試行することを決定してもよい。

いくつかの実施形態では、マスタプロセッサは、スレーブプロセッサＭ＿ＣＴＳコマン
ドを送信することによって、回収を開始してもよい。これは、いくつかの実施形態では、
パケット自体とともにＳ＿ＭＳＧ＿ＡＰＰＥＮＤＥＤコマンドを送信することによって、
スレーブプロセッサが応答するまで、反復されるものである。流量制御ラインは、パケッ
トが送信された後に解除されてもよい。予期しないときに、Ｍ＿ＣＴＳコマンドがスレー
ブプロセッサによって受信された場合、Ｍ＿ＣＴＳコマンドは無視されてもよい。

図８Ｒに図示されるように、いくつかの実施形態では、マスタプロセッサが、スレーブ
プロセッサに送信するパケットを有するとき、マスタプロセッサは、Ｍ＿ＲＴＳコマンド
を送信することによって転送を開始してもよい。Ｍ＿ＲＴＳコマンドを受信すると、いく
つかの実施形態では、スレーブプロセッサに現在、保留中の送信パケットがあれば、スレ
ーブプロセッサは、送信許可信号として再利用されてもよいように、流量制御ラインを下
げる。次いで、スレーブプロセッサは、パケットを受信するようにＳＰＩ ＤＭＡを準備
するプロセスであることをマスタプロセッサに伝えてもよく、その間に、マスタプロセッ
サは、バス上でバイトの時間を測定することを止めてもよく、スレーブプロセッサが受信
の準備を終了することを可能にしてもよい。

いくつかの実施形態では、次いで、スレーブプロセッサは、（ＣＴＳ信号として使用さ
れている）流量制御ラインを上昇させることによって、全パケットを受信する準備ができ
ていることを示してもよい。ＣＴＳ信号を受信すると、マスタプロセッサは、続けて、パ
ケット自体とともにＭ＿ＭＳＧ＿ＡＰＰＥＮＤＥＤコマンドを送信してもよい。

転送の完了後、スレーブプロセッサは、流量制御ラインを下げてもよい。パケットが転
送の開始時に保留中であった、または、パケットが受信されているときに送信がスレーブ
プロセッサ上で発生した場合、スレーブプロセッサは、保留中のパケットがあることを示
している流量制御ラインを再アサートしてもよい。

再度、図８を参照すると、デバイス８００は、ユーザ（図示せず）が、少なくとも１つ
のタスク、およびいくつかの実施形態では複数のタスクを行うことを可能にしてもよい、
電気制御アセンブリ５１０（図５Ｄ）に連結されるスイッチアセンブリ８１０を含んでも
よい。そのようなタスクの１つの例証的実施例は、デバイス８００が、注入ポンプである
、または他の薬物送達デバイスである、実施形態では、ディスプレイアセンブリを使用し
ない、注入可能流体（例えば、インスリン）のボーラス用量の投与である。遠隔インター
フェース８０２は、ユーザが、インスリンのボーラス用量を投与するように、デバイス８
００を有効化／無効化／構成することを可能にしてもよい。

ディスプレイアセンブリ８０４は、少なくとも部分的には、ユーザがディスプレイアセ
ンブリ８０４上にレンダリングされたメニューベースの情報を操作することを可能にする
ように構成されてもよい。実施例は、ディスプレイアセンブリ８０４が、タッチスクリー
ンであるものであり得る。いくつかの実施形態では、タッチスクリーン／ディスプレイア
センブリ８０４は、例えば、メニューのハイライトされた部分が「上向きに」または「下
向きに」スクロールする比率が、起点に対するユーザの指の変位に応じて、変動するよう
に構成されてもよい。したがって、いくつかの実施形態では、例えば、ユーザが、「上向
きに」急スクロールすることを所望する場合、ユーザは、その指をディスプレイアセンブ
リ８０４の上部近傍に位置付けてもよい。同様に、ユーザが、「下向きに」急スクロール
することを所望する場合、ユーザは、その指をディスプレイアセンブリ８０４の底部近傍
に位置付けてもよい。加えて、ユーザがゆっくりと「上向き」にスクロールすることを所
望する場合、ユーザは、起点に対してわずかに「上向き」に指を位置付けてもよい。さら
に、ユーザがゆっくりと「下向き」にスクロールすることを所望する場合、ユーザは、起
点に対してわずかに「下向き」に指を位置付けてもよい。適切なメニューアイテムがハイ
ライトされると、ユーザは、例えば、ハイライトされたメニューアイテムの近傍のいずれ
かにおいて、画面を所定の回数タッチすることによって、および／またはいくつかの実施
形態では、遠隔インターフェース８０２上に含まれ得る、１つ以上のスイッチアセンブリ
８０６を使用することによってのいずれかによって、ハイライトされたメニューアイテム
を選択してもよい。

上記で議論されるように、前述の注入ポンプデバイスの一実施形態では、デバイス８０
０は、遠隔インターフェース８０２と通信するために使用されてもよい。そのような遠隔
インターフェース８０２が利用されるとき、デバイス８００および遠隔インターフェース
８０２は、定期的に相互にコンタクトをとり、２つのデバイスが、依然として、相互に通
信していることを確実にしてもよい。例えば、デバイス８００は、遠隔インターフェース
８０２に「ｐｉｎｇ」を送り、遠隔インターフェース８０２が存在し、アクティブである
ことを確実にしてもよい。さらに、遠隔インターフェース８０２は、デバイス８００に「
ｐｉｎｇ」を送り、デバイス８００が、依然として、存在し、アクティブであることを確
実にしてもよい。デバイス８００および遠隔インターフェース８０２のうちの１つが、他
方と通信を確立できない場合、通信を確立できない一方（すなわち、デバイス８００また
は遠隔インターフェース８０２のいずれか）は、「分離」アラームを発報してもよい。例
えば、遠隔インターフェース８０２が、ユーザの車内に残される一方、デバイス８００は
、ユーザのポケット内にあると仮定する。したがって、定義された期間後、デバイス８０
０は、「分離」アラームを発報し始め、インターフェース８０２との通信を確立できない
ことを示してもよい。いくつかの実施形態では、ユーザは、スイッチアセンブリ８１０を
使用することによって、肯定応答する、および／または「分離」アラームを無音化しても
よい。

種々の実施形態では、ユーザは、遠隔インターフェース８０２が、デバイス８００と通
信していない間、デバイス８００のスイッチアセンブリ８１０を使用して、流体の送達を
定義および投与してもよく、デバイス８００は、デバイス８００内に記憶されるログファ
イル（図示せず）内に投与されたボーラスインスリン用量に関する情報を記憶してもよい
。このログファイル（図示せず）は、デバイス８００内に含まれる不揮発性メモリ（図示
せず）内に記憶されてもよい。デバイス８００と遠隔インターフェース８０２との間に確
立される通信に応じて、デバイス８００は、デバイス８００のログファイル（図示せず）
内に記憶された投与されたボーラスインスリン用量に関する情報を遠隔インターフェース
８０２に提供してもよい。

さらに、いくつかの実施形態では、ユーザが、遠隔インターフェース８０２をデバイス
８００から分離することを予期すると、ユーザは、デバイス８００および遠隔インターフ
ェース８０２を「分離」モードに構成し、したがって、前述の「分離」アラームの発生を
排除してもよい。しかしながら、いくつかの実施形態では、遠隔インターフェース８０２
およびデバイス８００は、相互に通信する状態に戻ると、デバイス８００および遠隔イン
ターフェース８０２が、自動的に、「分離」モードから解除され得るように、相互に「ｐ
ｉｎｇ」を送り続けてもよい。

さらに、いくつかの実施形態では、ユーザが、航空機で旅行することを予期する場合、
ユーザは、遠隔インターフェース８０２を使用して、デバイス８００および遠隔インター
フェース８０２を「航空機」モードに構成してもよく、デバイス８００および遠隔インタ
ーフェース８０２はそれぞれ、あらゆるデータ伝送を一時停止させる。「航空機」モード
にある間、デバイス８００および遠隔インターフェース８０２は、データを受信し続けて
もよく、またはそうでなくてもよい。

いくつかの実施形態では、スイッチアセンブリ８１０は、制限ではないが、再使用可能
部分５０２のバッテリ寿命のチェック、再使用可能部分５０２と遠隔インターフェース８
０２のペアリング、および／または注入可能流体のボーラス用量の投与の中断のうちの１
つ以上を含み得る、付加的機能を行なうために使用されてもよい。

また、図９Ａを参照すると、上記で議論されるように、いくつかの実施形態では、例え
ば、デバイス８００の安全性を向上させるために、電気制御アセンブリ５１６は、２つの
別個かつ個別のマイクロプロセッサ、すなわち、スーパーバイザプロセッサ９００および
コマンドプロセッサ９０２を含んでもよい。具体的には、コマンドプロセッサ９０２は、
制限されないが、ポンプ駆動信号の発生等の機能を果たしてもよく、例えば、形状記憶ア
クチュエータの機能性を制御する、継電器／スイッチアセンブリを制御してもよい。コマ
ンドプロセッサ９０２は、いくつかの実施形態では、形状記憶アクチュエータであり得る
、ポンプアクチュエータ９２２、９２４に印加される電圧信号の状態（例えば、電圧レベ
ル）に関するフィードバックを信号調整器９０８から受信してもよい。コマンドプロセッ
サ９００は、継電器／スイッチアセンブリ９０４、９０６から独立して、継電器／スイッ
チアセンブリ９１０を制御してもよい。故に、例えば、注入事象が所望されると、スーパ
ーバイザプロセッサ９００およびコマンドプロセッサ９０２は両方とも、注入事象が、適
切であることに合意しなければならず（固有またはユーザ選択／事前プログラムされる、
および／または計画的であるとき、注入事象用量がシステムの任意の設定制限を超えない
かどうかを含んでもよい）、両方とも、その個別の継電器／スイッチを作動させなければ
ならない。スーパーバイザプロセッサ９００およびコマンドプロセッサ９０２のいずれか
が、その個別の継電器／スイッチを作動しない場合、注入事象は、生じないであろう。故
に、スーパーバイザプロセッサ９００およびコマンドプロセッサ９０２の使用および生じ
なければならない協働および同時発生を通して、デバイス８００の安全性が、向上される
。

いくつかの実施形態では、スーパーバイザプロセッサ９００は、コマンドプロセッサ９
０２が適切ではないときに送達することを防止してもよく、また、コマンドプロセッサ９
０２が送達するべきときに送達していない場合、アラームしてもよい。スーパーバイザプ
ロセッサ９００は、例えば、コマンドプロセッサ９０２が間違ったスイッチを作動させた
場合、またはコマンドプロセッサが過剰に長く電力を印加しようとした場合、継電器／ス
イッチアセンブリを非アクティブ化してもよい。

スーパーバイザプロセッサ９００は、送達されるべき流体の量の計算を冗長的に行なっ
てもよい（すなわち、コマンドプロセッサ９０２の計算の二重チェック）。いくつかの実
施形態では、コマンドプロセッサ９０２は、送達スケジュールを判定してもよく、スーパ
ーバイザプロセッサ９００は、それらの計算を冗長的にチェック／確認してもよい。

スーパーバイザプロセッサ９００は、コマンドプロセッサ９０２が、正しい計算を行い
得るように、プロファイル（例えば、デバイスに事前にプログラム／事前に入力された送
達プロファイルおよび／またはユーザ選好）をＲＡＭ内に冗長的に保持してもよいが、不
良ＲＡＭを有する場合、コマンドに誤った結果を生じさせるであろう。したがって、スー
パーバイザプロセッサ９００は、プロファイル／ユーザ選好、例えば、基礎プロファイル
等のローカルコピーを使用して、二重にチェック／確認する。

スーパーバイザプロセッサ９００は、デバイスによって行なわれる１つ以上の計算、例
えば、ＡＶＳ測定を、ＡＶＳ計算および適用された安全性チェックを検討することによっ
て二重チェックしてもよい。デバイスのいくつかの実施形態では、例えば、ＡＶＳ測定が
行なわれるたびに、スーパーバイザプロセッサ９００は、二重チェックを行なう。

図９Ｂも参照すると、スーパーバイザプロセッサ９００およびコマンドプロセッサ９０
２のうちの１つ以上は、注入ポンプ／デバイス８００の種々の部分に診断を行ってもよい
。例えば、分圧器９１２、９１４は、例えば、形状記憶アクチュエータ９２２の遠位端に
おいて感知される、電圧（それぞれ、Ｖ１およびＶ２）を監視するように構成されてもよ
い。継電器／スイッチアセンブリ９０４、９１０に印加される信号を知った上で、電圧Ｖ
１およびＶ２の値は、（例証的な診断表９１６に示されるのと同様の様式で）図９Ｂに示
される回路の種々の構成要素に診断が行われることを可能にする。

上記で議論され、図９Ａ−９Ｂに図示されるように、デバイス８００の安全性を向上さ
せるために、電気制御アセンブリ９１０は、複数のマイクロプロセッサ（例えば、スーパ
ーバイザプロセッサ９００およびコマンドプロセッサ９０２）を含んでもよく、そのそれ
ぞれは、作用をもたらすために（例えば、デバイス８００が、薬物の送達をもたらす場合
、作用は、例えば、ある用量の注入可能流体の送達であってもよい）、相互作用し、同時
動作することが要求されてもよい。マイクロプロセッサ９００、９０２が相互作用／同時
動作できなかった場合、注入可能流体の用量の送達／作用が失敗する場合があり、１つ以
上のアラームがトリガされてもよく、したがって、デバイス８００の安全性および信頼性
を向上させる。

経時的に、送達された流体の体積が、要求されるもの未満または超であることを指し得
る、誤差、例えば、体積誤差を追跡する、マスタアラームが利用されてもよい。したがっ
て、誤差の合計が大きくなりすぎれば、マスタアラームが開始され、システムに異常があ
るかもしれないことを示してもよい。したがって、マスタアラームは、行われている総体
積比較および判明した相違を示してもよい。マスタアラームを開始するために必要とされ
る相違の典型的な値は、前述の注入ポンプを含む実施形態では、１．００ミリリットルで
あってもよい。マスタアラームは、漏洩方式で合計を監視してもよい（すなわち、不正確
性は、時間的水平線を有する）。

図１０Ａ−１０Ｂも参照すると、注入可能流体の用量の送達中の、複数のマイクロプロ
セッサ間のそのような相互作用の１つのそのような例証的実施例が示されている本実施例
では、相互作用は、注入ポンプによるある用量の注入可能流体の送達の際に行なわれる。
具体的には、コマンドプロセッサ９０２が、最初に、体積センサチャンバ内の注入可能流
体の初期体積を判定してもよい９００。次いで、コマンドプロセッサ９０２は、スーパー
バイザプロセッサ９００に「ポンプ電力要求」メッセージを提供してもよい１００２。「
ポンプ電力要求」メッセージの受信に応じて１００４、スーパーバイザプロセッサ９００
が、例えば、継電器／スイッチ９１０を励起してもよく１００６（したがって、形状記憶
アクチュエータ９２２を励起する）、コマンドプロセッサ９０２に「ポンプ電力オン」メ
ッセージを送信してもよい１００８。「ポンプ電力オン」メッセージの受信に応じて１０
１０、コマンドプロセッサ９０２は、例えば、ポンプアセンブリを作動させてもよく１０
１２（継電器／スイッチ９０４を励起させ、これによって、弁アセンブリ５１４を励起さ
せることによって）、その間、スーパーバイザプロセッサ９００は、例えば、ポンプアセ
ンブリの作動を監視してもよい１０１４。

ポンプアセンブリの作動が完了すると、コマンドプロセッサ９０２が、スーパーバイザ
プロセッサ９００に「ポンプ電力オフ」メッセージを提供してもよい１０１４。「ポンプ
電力オフ」メッセージの受信１０１６に応じて、スーパーバイザプロセッサ９００は、継
電器／スイッチ９１０を脱励起し１０１８、「ポンプ電力オフ」メッセージをコマンドプ
ロセッサ９０２に提供してもよい１０２０。「ポンプ電力オフ」メッセージの受信に応じ
て１０２２、コマンドプロセッサ９０２が、ポンプアセンブリ（いくつかの実施形態では
、弁アセンブリ５１４を含んでもよい）によって圧送された注入可能流体の分量を測定し
てもよい１０２４。これは、体積センサチャンバ内の現在の分量を測定し、それを上記で
（ステップ１０００で）判定された分量と比較することによって、達成されてもよい。判
定されると１０２４、コマンドプロセッサ９０２が、スーパーバイザプロセッサ９００に
「弁開放電力要求」メッセージを提供してもよい１０２６。「弁開放電力要求」メッセー
ジの受信に応じて１０２８、スーパーバイザプロセッサ９００が、継電器／スイッチ９１
０を励起してもよく１０３０（したがって、形状記憶アクチュエータ９２４を励起する）
、コマンドプロセッサ９０２に「弁開放電力オン」メッセージを送信してもよい１０３２
。「弁開放電力オン」メッセージの受信に応じて１０３４、コマンドプロセッサ９０２が
、例えば、（継電器／スイッチ９０６を励起することによって）測定弁アセンブリを作動
させてもよく１０３６、その間に、スーパーバイザプロセッサ９００が、例えば、測定弁
アセンブリの作動を監視してもよい１０３８。

測定弁アセンブリの作動が完了すると、コマンドプロセッサ９０２が、スーパーバイザ
プロセッサ９００に「弁電力オフ」メッセージを提供してもよい１０４０。「弁電力オフ
」メッセージの受信に応じて１０４２、スーパーバイザプロセッサ９００が、継電器／ス
イッチ９１０を脱励起し１０４４、コマンドプロセッサ９０２に「弁電力オフ」メッセー
ジを提供してもよい１０４６。

「弁電力オフ」メッセージの受信に応じて１０４８、コマンドプロセッサ９０２が、ス
ーパーバイザプロセッサ９００に「弁閉鎖電力要求」メッセージを提供してもよい１０５
０。「弁閉鎖電力要求」メッセージの受信に応じて１０５２、スーパーバイザプロセッサ
９００が、継電器／スイッチ９１０を励起してもよく１０５４（したがって、形状記憶ア
クチュエータを励起する）、コマンドプロセッサ９０２に「電力オン」メッセージを送信
してもよい１０５６。「電力オン」メッセージの受信に応じて１０５８、コマンドプロセ
ッサ９０２が、形状記憶アクチュエータを励起するように構成される、励起継電器／スイ
ッチ（図示せず）を作動させてもよく１０６０、その間に、スーパーバイザプロセッサ９
００が、例えば、形状記憶アクチュエータの作動を監視してもよい１０６２。

種々の実施形態では、形状記憶アクチュエータが、電気接点を使用して第１端に固着さ
れてもよい。形状記憶アクチュエータの他方の端は、ブラケットアセンブリに接続されて
もよい。形状記憶アクチュエータがアクティブ化されると、形状記憶アクチュエータは、
ブラケットアセンブリを前方に引き、弁アセンブリを解放してもよい。そのようなものと
して、測定弁アセンブリは、形状記憶アクチュエータを介してアクティブ化されてもよい
。測定弁アセンブリがアクティブ化されると、ブラケットアセンブリは、アクティブ化位
置で測定弁アセンブリに自動でで掛け金を掛けてもよい。形状記憶アクチュエータを作動
させることにより、ブラケットアセンブリを前方に引き、弁アセンブリを解放してもよい
。形状記憶アクチュエータがもはやアクティブ化されないと仮定して、ブラケットアセン
ブリが測定弁アセンブリを解放すると、測定弁アセンブリが非アクティブ化状態になって
もよい。したがって、形状記憶アクチュエータを作動させることによって、測定弁アセン
ブリが非アクティブ化状態になってもよい。

形状記憶アクチュエータの作動が完了すると、コマンドプロセッサ９０２が、スーパー
バイザプロセッサ９００に「電力オフ」メッセージを提供してもよい１０６４。「電力オ
フ」メッセージの受信に応じて１０６６、スーパーバイザプロセッサ９００が、継電器／
スイッチ９１０を脱励起し１０６８、コマンドプロセッサ９０２に「電力オフ」メッセー
ジを提供してもよい１０７０。「電力オフ」メッセージの受信に応じて１０７２、コマン
ドプロセッサ９０２が、体積センサチャンバ内の注入可能流体の分量を判定してもよく、
したがって、コマンドプロセッサ９０２が、この測定された分量を、上記で（ステップ１
０２４で）判定された分量と比較して、ユーザに送達された注入可能流体の分量を判定す
ることを可能にする１０７４。

ユーザに送達された注入可能流体の分量１０７４が、基礎／ボーラス注入事象に対して
指定される注入可能流体の分量より少ない場合、（ループ１０７６を介して）上記の手順
が反復されてもよい。

図１１を参照すると、今回は、注入可能流体の用量のスケジューリング中の、プロセッ
サ９００、９０２間の相互作用の別の例証的実施例が示されている。コマンドプロセッサ
９０２は、（それぞれ）基礎スケジューリングメッセージまたはボーラス要求メッセージ
の受信について監視してもよい１１００、１１０２。これらのメッセージのうちのいずれ
か一方を受信すると１１００、１１０２、コマンドプロセッサ９０２が、所望の送達体積
を設定してもよく１１０４、スーパーバイザプロセッサ９００に「送達要求」メッセージ
を提供してもよい１１０６。「送達要求」メッセージの受信に応じて１１０８、スーパー
バイザプロセッサ９００が、コマンドプロセッサ９０２によって定義される体積１１０４
を検証してもよい１１１０。検証されると１１１０、スーパーバイザプロセッサ９００が
、コマンドプロセッサ９０２に「送達容認」メッセージを提供してもよい１１１２。「送
達容認」メッセージの受信に応じて１１１４、コマンドプロセッサ９０２は、遠隔インタ
ーフェース（例えば、上記で議論され、図６−８に図示される遠隔インターフェース）を
更新し１１１６、注入可能流体の基礎／ボーラス用量の送達を実行してもよい１１１８。
コマンドプロセッサ９０２は、（上記で議論され、かつ図１０Ａ−１０Ｂに図示されるよ
うに）ユーザに送達された注入可能流体の総分量を監視し、更新してもよい１１２２。適
切な分量の注入可能流体がユーザに送達されると、コマンドプロセッサ９０２が、スーパ
ーバイザプロセッサ９００に「送達終了」メッセージを提供してもよい１１２４。「送達
終了」メッセージの受信に応じて１１２６、スーパーバイザプロセッサ９００が、ユーザ
に送達された注入可能流体の総分量を更新してもよい１１２８。ユーザに送達された注入
可能流体の総分量１１１８が、上記で（ステップ１１０４で）定義された分量より少ない
場合、（ループ１１３０を介して）上記で議論される注入プロセスが反復されてもよい。

図１２も参照すると、（上記で説明されるように）体積センサアセンブリを介した体積
測定を達成しながら、スーパーバイザプロセッサ９００およびコマンドプロセッサ９０２
が相互作用し得る方式の実施例が示されている。

具体的には、コマンドプロセッサ９０２が、体積センサアセンブリを初期化し１２５０
、体積センサアセンブリからデータを収集し始めてもよく１２５２、そのプロセスは、例
えば、２００９年１２月３日公開の米国公報第ＵＳ−２００９−０２９９２７７−Ａ１号
（弁理士整理番号Ｇ７５）に説明されるように、上記の正弦波掃引で利用される各周波数
について反復されてもよい。データが特定の掃引周波数について収集されるたびに、デー
タ点メッセージがコマンドプロセッサ９０２から提供されてもよく１２５４、これは、ス
ーパーバイザプロセッサ９００によって受信されてもよい１２５６。

正弦波掃引全体についてデータ収集１２５２が完了すると、コマンドプロセッサ９０２
が、デバイス８００の注入によって送達される注入可能流体の体積を推定してもよい１２
５８。コマンドプロセッサ９０２は、スーパーバイザプロセッサ９００に体積推定メッセ
ージを提供してもよい１２６０。この体積推定メッセージの受信に応じて１２６２、スー
パーバイザプロセッサ９００が、体積推定メッセージをチェック（すなわち、確認）して
もよい１２６４。チェック（すなわち、確認）されると、スーパーバイザプロセッサ９０
０が、コマンドプロセッサ９０２に検証メッセージを提供してもよい１２６６。スーパー
バイザプロセッサ９００から受信されると１２６８、コマンドプロセッサ９０２が、体積
センサアセンブリによって送達された注入可能流体の用量に対する測定状態を設定しても
よい。

上記で議論されるように（かつ図１Ａ−５Ｉを一時的に参照すると）、注入ポンプシス
テムの種々の実施形態および構成要素は、遠隔インターフェース８０２を使用して構成さ
れてもよい（図６−８参照）。遠隔インターフェース８０２を介して構成可能であるとき
、注入ポンプ８００は、注入ポンプと、例えば、遠隔インターフェース８０２との間の通
信（例えば、有線または無線）を可能にし、したがって、遠隔インターフェース８０２が
、注入ポンプ８００と遠隔で通信することを可能にする、テレメトリ回路（図示せず）を
含んでもよい。遠隔インターフェース８０２（同様にテレメトリ回路（図示せず）を含ん
でもよく、注入ポンプ８００と通信可能であってもよい）の種々の実施形態は、ディスプ
レイアセンブリ（６０２、７０２、８０４）および少なくとも１つの入力アセンブリ６０
８、６０４、６１０、６０６、７０４、７０２、８０４、８０６）、を含んでもよいが、
しかしながら、種々の実施形態では、ディスプレイアセンブリはまた、入力アセンブリと
しての役割を果たしてもよい。

本明細書で使用されるとき、用語「遠隔インターフェース」は、遠隔インターフェース
の任意の実施形態を指す。しかしながら、図８に示される実施形態は、以下では、例証目
的のために使用されるが、説明は、図８に示される遠隔インターフェースのその実施形態
に制限されない。

いくつかの実施形態では、遠隔インターフェース８０２は、２つのプロセッサを含んで
もよく、１つのプロセッサ（例えば、Ｃｈｉｐｃｏｎ ＡＳ（Ｏｓｌｏ， Ｎｏｒｗａｙ
）から入手可能なＣＣ２５１０マイクロコントローラインターフェース／ＲＦ送受信機を
含んでもよいが、それに制限されない）は、無線通信、例えば、デバイス８００と通信す
るための無線通信専用であってもよい。遠隔インターフェース８０２内に含まれる第２の
プロセッサ（Ｈｏｌｄｉｎｇｓ ＰＬＣ（Ｕｎｉｔｅｄ Ｋｉｎｇｄｏｍ）製造のＡＲＭ
９２０ＴおよびＡＲＭ９２２Ｔを含んでもよいが、それらに制限されない）は、コマンド
プロセッサであってもよく、例えば、デバイス８００の構成と関連付けられたデータ処理
タスクを行なってもよい。しかしながら、種々の他の実施形態では、以下に説明されるよ
うに、遠隔インターフェース８０２は、種々のプロセッサおよび／または通信プロトコル
および／または通信のための種々のアンテナを含んでもよい。

さらに、上記で議論されるように、電気制御アセンブリ５１６の一実施形態は、３つの
マイクロプロセッサを含んでもよい。１つのプロセッサ（例えば、Ｃｈｉｐｃｏｎ ＡＳ
（Ｏｓｌｏ， Ｎｏｒｗａｙ）から入手可能なＣＣ２５１０マイクロ遠隔インターフェー
ス／ＲＦ送受信機を含んでもよいが、それに制限されない）は、例えば、遠隔インターフ
ェース８０２と通信するために、無線通信に専念してもよい。２つの追加マイクロプロセ
ッサ（例えば、スーパーバイザプロセッサ１８００およびコマンドプロセッサ１８０２）
は、（上記で議論されるように）注入可能流体の送達を達成してもよい。スーパーバイザ
プロセッサ１８００およびコマンドプロセッサ１８０２の例は、Ｔｅｘａｓ Ｉｎｓｔｒ
ｕｍｅｎｔｓ Ｉｎｃ．（Ｄａｌｌａｓ， Ｔｅｘａｓ）から入手可能なＭＳＰ４３０マ
イクロ遠隔インターフェースを含んでもよいが、それに制限されない。

ＯＳは、優先度にかかわらず、次のタスクを実行することが可能になる前に、全てのタ
スクが完了するまで実行するという点で、非割り込みタイプスケジューリングシステムで
あってもよい。加えて、コンテキスト切替は行われてなくてもよい。タスクが実行を完了
すると、実行が現在予定されている、最高優先度のタスクが、実行されてもよい。いずれ
のタスクも実行が予定されていない場合、ＯＳがプロセッサ（例えば、スーパーバイザプ
ロセッサ９００および／またはコマンドプロセッサ９０２）を低電力休止モードにしても
よく、次のタスクが予定されると、ウェークしてもよい。ＯＳは、主要ループコードを管
理するためだけに使用されてもよく、割り込みに基づいた機能性が影響されないままにし
てもよい。

いくつかの実施形態では、ＯＳは、Ｃ＋＋言語を利用するように書かれてもよい。イン
ヘリタンスならびに仮想関数は、タスクの容易な作成、スケジューリング、および管理を
可能にする設計の重要な要素であってもよい。

ＯＳインフラストラクチャのベースには、システム時間を追跡する能力があってもよく
、プロセッサを低電力モード（ＬＰＭ、休止モードとしても知られている）にする能力を
制御する。この機能性は、全てのシステムクロックの制御および構成とともに、ＳｙｓＣ
ｌｏｃｋｓクラスによってカプセル化されてもよい。

ＳｙｓＣｌｏｃｋｓクラスは、プロセッサ（例えば、スーパーバイザプロセッサ９００
および／またはコマンドプロセッサ９０２）をＬＰＭにしてエネルギー消費を低減する機
能性を含有してもよい。ＬＰＭである間、低速リアルタイムクロックが実行され続けても
よい一方で、ＣＰＵコアおよびほとんどの周辺機器を実行する、高速システムクロックが
無効にされてもよい。

いくつかの実施形態では、プロセッサをＬＰＭにすることは、常に、提供されたＳｙｓ
Ｃｌｏｃｋｓによって行われてもよい。この機能は、ＬＰＭになるとき、またはＬＰＭで
はなくなるときはいつでも一貫性をもたらす、全ての必要な電力低下および電力増加シー
ケンスを含有してもよい。ＬＰＭからのウェークは、低速クロックに基づく任意の割り込
みによって開始されてもよい。

ＯＳは、秒数、ミリ秒数、および時刻の３つの時間の局面を追跡してもよい。秒数に関
して、ＳｙｓＣｌｏｃｋｓは、プロセッサがリセットから脱するときに始めて、秒をカウ
ントしてもよい。秒数カウンタは、低速システムクロックに基づいてもよく、したがって
、プロセッサがＬＰＭであるか、または全電力であるかどうかにかかわらず、インクリメ
ントしてもよい。結果として、これが、プロセッサが休止からウェークして、以前に予定
されたタスクを実行する境界である。タスクが、割り込み処理ルーチン（ＩＳＲ）の直後
に実行される予定であれば、ＩＳＲが、終了時にプロセッサをＬＰＭからウェークさせて
もよく、タスクが即座に実行されてもよい。ミリ秒数に関して、電力オンになってから秒
数をカウントすることに加えて、ＳｙｓＣｌｏｃｋｓは、プロセッサが全電力モードであ
る間にミリ秒数もカウントしてもよい。高速クロックがＬＰＭ中に停止させられるため、
ミリ秒カウンタはインクリメントしなくてもよい。したがって、タスクがミリ秒数に基づ
いて実行される予定であるときはいつでも、プロセッサがＬＰＭにならなくてもよい。時
刻に関して、時刻は、特定の時点以降の秒数（例えば、２００８年１月１日、および／ま
たはいくつかの実施形態では、ＰＯＳＩＸ標準時間１９７１年１月１日以降の秒数）のよ
うにＳｙｓＣｌｏｃｋｓ内に表されてもよい。

ＳｙｓＣｌｏｃｋｓクラスは、コマンドおよびスーパーバイザプロジェクトコードベー
スの全体を通して使用される、有用な機能性を提供してもよい。コード遅延は、ハードウ
ェアが安定すること、またはアクションが完了することを可能にするために必要であって
もよい。ＳｙｓＣｌｏｃｋｓは、秒数に基づく遅延、またはミリ秒数に基づく遅延の２つ
の形態の遅延を提供してもよい。遅延が使用されると、プロセッサは、現在のコード経路
を続ける前に所望の時間が経過するまで、単純に待機してもよい。この時間の間、ＩＳＲ
のみが実行されてもよい。ＳｙｓＣｌｏｃｋｓは、必要な機能性の全てを提供して、現在
の時刻を設定または回収してもよい。

用語「タスク」とは、より複雑なスケジューリングシステムと関連付けられてもよく、
したがって、ＯＳ内で、タスクは、マネージド関数（Ｍａｎａｇｅｄ Ｆｕｎｃｔｉｏｎ
ｓ）によって表され、かつマネージド関数と呼ばれてもよい。ＭａｎａｇｅｄＦｕｎｃク
ラスは、所望の機能性を管理し、予定に入れるために必要な制御要素および機能性の全て
を提供する、抽象タイプベースクラスであってもよい。

ＭａｎａｇｅｄＦｕｎｃベースクラスは、５つの制御要素を有してもよく、２つがスケ
ジューリング操作要素関数であり、１つがマネージド機能性を含有し得る、純粋仮想実行
関数である。ＭａｎａｇｅｄＦｕｎｃ制御要素の全ては、導出クラスから隠されてもよく
、作成中に導出クラスによって直接設定されるのみであってもよく、したがって、使用を
簡略化し、注入ポンプ８００の安全性を向上させる。

いくつかの実施形態では、関数ＩＤは、作成時に設定されてもよく、決して変更されな
くてもよい。全ての関数ＩＤは、単一の．ｈファイル内で定義されてもよく、ベースＭａ
ｎａｇｅｄＦｕｎｃコンストラクタは、同じＩＤが２つ以上のマネージド関数に使用され
てはならないことを強制的に履行してもよい。ＩＤはまた、割り当てられた関数ＩＤに基
づいて（他の関数に対する）関数の優先度を定義してもよく、より高い優先度の関数は、
割り当てられたより低い関数ＩＤである。実行が現在予定されている、最高優先度のタス
クは、より低い優先度のタスクの前に実行されてもよい。

全ての他の制御要素は、実行されるべきであるとき、および（実行時に）以前に設定さ
れた時間量で関数が再び予定に入れられるべきであれば、関数の現在の予定された状態を
表すために使用されてもよい。これらの制御および状態の操作は、周知のメンバ関数のみ
を通してであるが、可能になってもよい（したがって、全ての設定に安全性制御を履行す
る）。

マネージド関数のスケジューリングを制御するために、設定開始および設定反復関数が
使用されてもよい。これらのメンバ関数のそれぞれは、反復設定を構成または無効化する
、ならびに、マネージド関数が秒数、ミリ秒数、または時刻によって予定に入れられる、
非アクティブ状態であるかどうかを制御する能力を可能にする、単純インターフェースで
あってもよい。

インヘリタンスを通して、導出クラスを作成し、スケジューリング制御を受ける必要が
あるコードを含有する純粋仮想「実行」関数を定義することによって、マネージド関数の
作成が行われてもよい。ＭａｎａｇｅｄＦｕｎｃベースクラスコンストラクタは、関数の
一意のＩＤに基づいてもよいが、始動時にデフォルト制御値を設定するためにも使用され
てもよい。

例えば、始動してから３０秒後、かつその後１５秒ごとに実行される関数を作成するた
めに、例えば、所望のコードが仮想実行関数に入れられ、３０秒の開始時間である、秒数
状態によって予定に入れられる関数ＩＤ、および１５秒の反復設定が、コンストラクタに
提供される。

以下は、マネージド関数の作成に関する、例証的なコードの実施例である。この特定の
実施例では、デバイス８００の始動後１秒で初めて実行し、その後１０秒ごとに実行する
ことが予定される、「ハートビート」関数が作成される。
＃ｉｎｃｌｕｄｅ “ＭａｎａｇｅｄＦｕｎｃ．ｈ”
／／ Ｔｈｅ ＳｅｎｄＧｏｏｄＦｕｎｃ ｉｓ ａ “ｈｅａｒｔｂｅａｔ” ｓｔ
ａｔｕｓ ｍｅｓｓａｇｅ
ｃｌａｓｓ ＳｅｎｄＧｏｏｄＦｕｎｃ ： ｐｕｂｌｉｃ ＭａｎａｇｅｄＦｕｎｃ
｛
ｐｕｂｌｉｃ：
／／ Ｉｎｉｔｉａｌｉｚｅ ｔｈｅ ｍａｎａｇｅｄ ｆｕｎｃ ｔｏ ｒｕｎ ２
ｓｅｃｏｎｄｓ ａｆｔｅｒ ｓｔａｒｔ ｕｐ
／／ ａｎｄ ｒｅｐｅａｔ ｅｖｅｒｙ ｓｅｃｏｎｄ．
ＳｅｎｄＧｏｏｄＦｕｎｃ（） ：
ＭａｎａｇｅｄＦｕｎｃ（ＩＰＣ＿ＳＥＮＤ＿ＧＯＯＤ，ＳＣＨＥＤＵＬＥＤ＿ＳＥＣ
， １， ｔｒｕｅ， １０） ｛｝；
〜ＳｅｎｄＧｏｏｄＦｕｎｃ（） ｛｝；
ｐｒｏｔｅｃｔｅｄ：
ｖｏｉｄ ｅｘｅｃｕｔｅ（ｖｏｉｄ）；
｝；
ｖｏｉｄ ＳｅｎｄＧｏｏｄＦｕｎｃ：：ｅｘｅｃｕｔｅ（ｖｏｉｄ）
｛
／／ ＜＜ ｃｏｄｅ ｔｏ ｓｅｎｄ ｔｈｅ ｈｅａｒｔｂｅａｔ ＞＞
｝
ＳｅｎｄＧｏｏｄＦｕｎｃ ｇ＿ｓｅｎｄＧｏｏｄＦｕｎｃ；
／／ ｔｏ ｍａｎｉｐｕｌａｔｅ ｔｈｅ ｈｅａｒｔｂｅａｔ ｔｉｍｉｎｇ ｓ
ｉｍｐｌｙ ｃａｌｌ：
／／ ｇ＿ｓｅｎｄＧｏｏｄＦｕｎｃ．ｓｅｔＦｕｎｃＳｔａｒｔ（…） ｏｒ ｇ＿
ｓｅｎｄＧｏｏｄＦｕｎｃ．ｓｅｔＲｅｐｅａｔ（ … ）

マネージド関数の実際の実行は、ＳｌｅｅｐＭａｎａｇｅｒクラスによって制御され、
実施されてもよい。ＳｌｅｅｐＭａｎａｇｅｒは、マネージド関数の実際の優先順位リス
トを含有してもよい。この関数の優先順位リストは、マネージド関数作成プロセスによっ
て自動的にデータ投入されてもよく、各関数が適正に作成され、一意のＩＤを有すること
を確実にしてもよい。

ＳｌｅｅｐＭａｎａｇｅｒクラスの主要な役割は、その「管理」関数を、プロセッサの
主要ループから、および／または永久ｗｈｉｌｅループから繰り返し呼び出させることで
あり得る。管理の各呼び出し時に、ＳｌｅｅｐＭａｎａｇｅｒは、ＳｌｅｅｐＭａｎａｇ
ｅｒが全ての予定された関数を使い果たすまで実行されることが予定される、全ての関数
を実行し、そのときに、ＳｌｅｅｐＭａｎａｇｅｒは、プロセッサをＬＰＭにしてもよい
。プロセッサがＬＰＭからウェークすると、プロセッサが再びＬＰＭになる準備ができる
まで、管理関数が再入力されてもよい（このプロセスは、例えば、ユーザによって、また
はシステムによって停止されるまで、反復されてもよい）。

プロセッサが長期間にわたって（例えば、アナログ／デジタル変換がサンプリングされ
ている間）全電力モードで保たれなければならない場合、ＳｌｅｅｐＭａｎａｇｅｒは、
ＬＰＭになることを無効にする機能性を提供してもよい。ＬＰＭが無効になっている間、
管理関数は、引き続き、予定されたタスクを検索してもよい。

ＳｌｅｅｐＭａｎａｇｅｒはまた、スケジューリングを操作し、関数の一意のＩＤの使
用を通して任意のマネージド関数の設定を反復する、インターフェースを提供してもよく
、これは、所望のＭａｎａｇｅｄＦｕｎｃオブジェクトへの直接アクセス、またはそれの
不必要な知識がなくても、コードの任意のセクションが、任意の必要なスケジューリング
を行うことを可能にしてもよい。

デバイス８００および遠隔インターフェース８０２内に含まれる無線回路は、遠隔イン
ターフェース８０２とデバイス８００との間の無線通信をもたらしてもよい。いくつかの
実施形態では、内部８０５１マイクロ遠隔インターフェースを伴う、２．４ＧＨｚ無線通
信チップ（例えば、Ｔｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓ ＣＣ２５１０無線送受信機）
が、無線通信に使用されてもよい。

無線リンクは、リンク可用性、待ち時間、およびエネルギーの３つのオブジェクトのバ
ランスを保ってもよい。

リンク可用性に関して、遠隔インターフェース８０２は、デバイス８００に命令するた
めの一次手段を提供してもよく、遠隔インターフェース８０２のグラフィカルユーザイン
ターフェース（ＧＵＩ）（ディスプレイアセンブリ８０４）を介して、詳細なフィードバ
ックをユーザに提供してもよい。待ち時間に関して、通信システムは、遠隔インターフェ
ース８０２からデバイス８００に（その逆も同様）にデータを送達する、少ない待ち時間
を提供するように設計されてもよい。エネルギーに関して、遠隔インターフェース８０２
およびデバイス８００は両方とも、無線通信のための最大エネルギー消費を有してもよい
。

無線リンクは、半二重通信をサポートしてもよい。いくつかの実施形態では、遠隔イン
ターフェース８０２は、全ての通信を開始する、無線リンクのマスタであってもよい。こ
れらの実施形態では、デバイス８００は、通信に応答するだけであってもよく、決して通
信を開始しなくてもよい。そのような無線通信システムの使用は、向上したセキュリティ
、簡略化された設計（例えば、航空機利用のため）、および無線リンクの協調制御の種々
の利点を提供し得る。他の実施形態では、デバイス８００は、ある作用を引き起こしても
よいが、通信は、遠隔インターフェース８０２によって引き起こされてもよい。

図１２も参照すると、上記で議論される、無線通信システムの種々のソフトウェア層の
１つの例証的実施例が示されている。
いくつかの実施形態では、遠隔インターフェース８０２およびデバイス８００に含まれる
無線プロセッサは、ＳＰＩポートと２．４ＧＨｚ無線リンクとの間（その逆も同様）で、
メッセージングパケットを転送してもよい。いくつかの実施形態では、無線は、常にＳＰ
Ｉスレーブであってもよい。デバイス８００上では、無線プロセッサ（ＰＲＰ）９１８（
図９Ａ−９Ｂ参照）が、いくつかの実施形態では、ＳＰＩポートを経由して、上流（すな
わち、コマンドプロセッサ９００およびスーパーバイザプロセッサ９０２）にある、２つ
の付加的ノード（付加的ノードの数は、種々の実施形態では、異なってもよい）にサービ
ス提供してもよい。いくつかの実施形態では、遠隔インターフェース８０２上で、無線プ
ロセッサ９１８（ＣＲＰ）は、上流または下流のいずれか一方にあり得るＳＰＩポート上
で２つの追加ノードを使用可能にしてもよく、例えば、いくつかの実施形態では、上記の
遠隔制御プロセッサ（ＵＩ）および持続的グルコースモニタ（ＣＧＭ）および／または血
液グルコースモニタ（ＢＧＭ）である。

メッセージングシステムは、ネットワーク中の種々のノード間で、メッセージの通信を
可能にしてもよい。遠隔インターフェース８０２のＵＩプロセッサ、および、例えば、ス
ーパーバイザプロセッサ９００は、２つのシステム無線上でモード切替の一部を構成し、
開始するために、メッセージングシステムを使用してもよい。それはまた、ネットワーク
中の他のノードに無線およびリンク状態情報を伝えるために、無線によって使用されても
よい。

いくつかの実施形態では、遠隔インターフェース８０２の無線が、デバイス８００から
チャネル統計を収集すること、または、デバイス８００の無線のマスタチャネルリストを
更新することを所望すると、遠隔インターフェース８０２の無線がシステムメッセージを
使用してもよい。新しい更新されたリストを発効させるための同期化は、タイミングの不
確定性を除去するために、ハートビートメッセージでフラグを使用してもよい。

無線通信システムは、メッセージングソフトウェアと互換性があるように、Ｃ＋＋で書
かれてもよい。いくつかの実施形態では、各無線ノードに対処するために、４バイト無線
シリアル番号が使用されてもよい。デバイス「可読」シリアル番号列と無線シリアル番号
との間で１対１の翻訳を提供するために、ハッシュテーブルが使用されてもよい。ハッシ
ュテーブルは、同様の可読シリアル番号を伴うデバイスまたは遠隔インターフェースが、
一意の論理アドレスを有する可能性が高いように、よりランダム化された、例えば、８ビ
ット論理アドレスを提供してもよい。いくつかの実施形態では、デバイス８００と遠隔イ
ンターフェース８０２との間の無線シリアル番号は、それぞれが無線プロトコルにおいて
有する一意の役割により、一意である必要がなくてもよい。

遠隔インターフェース８０２の無線シリアル番号およびデバイス８００の無線シリアル
番号は、いくつかの実施形態では、遠隔インターフェース８０２の無線シリアル番号のみ
を含んでもよいＲＦペアリング要求メッセージを除いて、全ての無線パケットに含まれて
もよく、したがって、それがペアリングされる遠隔制御アセンブリ／注入ポンプアセンブ
リとしか発生しないことを確実にする。ＣＣ２５１０は、１バイト論理ノードアドレスを
サポートしてもよく、受信パケットをフィルタにかけるレベルを提供するために、論理ノ
ードアドレスとして無線シリアル番号の１バイトを使用することが有利であってもよい。

基板上の他のシステムによる、遠隔インターフェース８０２の基板上の雑音干渉を防止
するために、Ｑｕｉｅｔ＿Ｒａｄｉｏ信号が、遠隔インターフェース８０２のＵＩプロセ
ッサによって使用されてもよい。Ｑｕｉｅｔ＿Ｒａｄｉｏがアサートされると、遠隔イン
ターフェース８０２の無線アプリケーションが、デバイス８００の無線にメッセージを送
信して、所定の期間にわたって無線休眠（Ｒａｄｉｏ Ｑｕｉｅｔ）モードをアサートし
てもよい。いくつかの実施形態では、Ｑｕｉｅｔ＿Ｒａｄｉｏ特徴は、遠隔インターフェ
ース８０２のＰＣ基板上で測定される雑音干渉レベルに基づいて、必要とされなくてもよ
い。この期間中、遠隔インターフェース８０２の無線は、最大で１００ｍｓにわたって休
止モード２のままであってもよい。遠隔インターフェース８０２の無線は、Ｑｕｉｅｔ＿
Ｒａｄｉｏ信号がアサート停止された、または最大期間が満了したときに、休止モード２
から脱してもよい。遠隔インターフェース８０２のＵＩプロセッサは、事象をアサートす
る必要がある前に、少なくとも１つの無線通信の間隔で、Ｑｕｉｅｔ＿Ｒａｄｉｏをアサ
ートしてもよい。遠隔インターフェース８０２の無線は、この休眠期間中に通信がシャッ
トダウンされることを、デバイス８００の無線に通知してもよい。周期的無線リンクプロ
トコルは、Ｑｕｉｅｔ＿Ｒａｄｉｏが必要とされない限りＱｕｉｅｔ＿Ｒａｄｉｏ特徴を
収容する、状態ビット／バイトを有してもよい。

無線ソフトウェアは、同じプロセッサ上でメッセージングシステムおよび無線ブートロ
ーダと一体化してもよく、スループット試験を使用して検証されてもよい。無線ソフトウ
ェアは、全て同じプロセッサ（例えば、ＴＩ ＣＣ２５１０）上で、メッセージングシス
テム、ＤＭＡを使用するＳＰＩドライバ、および無線ブートローダと一体化してもよい。

いくつかの実施形態では、遠隔インターフェース８０２の無線は、３日でわずか３２ｍ
Ａｈを消費するように構成されてもよい（１日あたり１００分の高速ハートビートモード
通信を仮定する）。いくつかの実施形態では、デバイス８００の無線は、３日でわずか２
５ｍＡｈを消費するように構成されてもよい（１日あたり１００分の高速ハートビートモ
ード通信を仮定する）。しかしながら、これらの構成は、実施形態全体を通して異なって
もよく、いくつかの実施形態では、述べられた実施例を上回る、または下回ってもよい。

通信を再取得する最大時間は、接続要求モードおよび取得モードを含み、＜６．１秒で
あってもよいが、しかしながら、種々の他の実施形態では、最大時間は、より短いまたは
長くてもよい。いくつかの実施形態では、遠隔インターフェース８０２の無線は、電力を
節約し、ユーザにとっての待ち時間を最小限化するために、高速ハートビートモードまた
は低速ハートビートモード設定を有利に使用してもよい。取得モードになる、デバイス８
００と遠隔インターフェース８０２との間の差異は、通信が最大待ち時間内に復旧され得
ることを確実にするのに十分頻繁に、デバイス８００が取得モードになる必要があること
であり得る。しかしながら、遠隔インターフェース８０２は、低速ハートビートモードで
あり、ハートビートが失われたときに、デバイス８００とともに取得モードになる頻度を
変化させてもよい。いくつかの実施形態では、遠隔インターフェース８０２の無線には、
ユーザＧＵＩ相互作用の知識があってもよいが、デバイス８００にはなくてもよい。

遠隔インターフェース８０２の無線は、両方の無線に対するハートビート期間を設定し
てもよい。いくつかの実施形態では、期間は、活動に応じて電力およびリンク待ち時間を
最適化するために、選択可能であってもよい。所望のハートビート期間は、遠隔インター
フェース８０２の無線からデバイス８００の無線へと、各ハートビートにおいて伝達され
てもよい。これは、どのモードになるかを判定する他の条件により、デバイス８００のハ
ートビート比率を独占的に確立しない場合がある。高速ハートビートモードであるとき、
遠隔インターフェース８０２の無線は、データパケットを送信または受信することが可能
であれば、ハートビート期間を２０ｍｓに設定してもよく、したがって、データが活発に
交換されているときに、少ない待ち時間の通信を提供する。

高速ハートビートモードであるとき、遠隔インターフェース８０２の無線は、データパ
ケットが無線上で両方向性に最後に交換されてから４つのハートビート後に、ハートビー
ト期間を６０ｍｓに設定してもよい。データパケットが送信または受信された後に、無線
ハートビート期間を短く保つことにより、任意のデータ応答パケットも、少ないリンク待
ち時間を使用して提供され得ることを確実にする。低速ハートビートモードであるとき、
ハートビート比率は、それぞれ、オンラインまたはオフライン状態に応じて、２．００秒
または６．００秒であってもよい。しかしながら、種々の実施形態では、これらの値は、
異なってもよい。

デバイス８００は、遠隔インターフェース８０２の無線によって設定されるハートビー
ト比率を使用してもよい。遠隔インターフェース８０２の無線は、いくつかの実施形態で
は、制限されないが、１つ以上のメッセージングシステムを介して、以下のモード要求を
サポートしてもよい。
・ペアリングモード
・接続モード
・取得モード（所望のペアリングされた注入ポンプアセンブリ１００、１００’、４０
０、５００の無線シリアル番号を含む）
・同期モード−高速ハートビート
・同期モード−低速ハートビート
・ＲＦオフモード
注入ポンプアセンブリ１００、１００’、４００、５００の無線は、メッセージングシ
ステムを介して、以下のモード要求をサポートしてもよい。
・ペアリングモード
・取得モード
・ＲＦオフモード

いくつかの実施形態では、無線は、ローカル無線シリアル番号を得るために、システム
メッセージを使用してもよい。遠隔インターフェース８０２上で、無線は、遠隔インター
フェース８０２のＵＩプロセッサからシリアル番号を得てもよい。無線は、システムメッ
セージを使用して、ペアリングされた無線シリアル番号を記憶してもよい。
遠隔インターフェース８０２およびデバイス８００の無線は、いくつかの実施形態では
、制限されないが、１つ以上の以下の状態が変化するときは、常時、メッセージングシス
テムを使用して、状態メッセージを遠隔インターフェース８０２およびコマンドプロセッ
サ９０２のＵＩプロセッサに発行してもよい。
・高速オンライン：接続成功
・高速オンライン：取得モードから高速ハートビートモードへの変更
・低速オンライン：高速ハートビートから低速ハートビートへの変更要求の成功
・オフライン：ハートビート交換の不足による、検索同期モードへの自動変更
・高速オンライン：低速ハートビートから高速ハートビートへの変更要求の成功
・オフライン：帯域幅が同期モードで１０％を下回る
・オンライン：帯域幅が検索同期モードで１０％を上回る
・オフライン：ＲＦオフモードへの変更要求の成功

いくつかの実施形態では、無線構成メッセージは、無線再試行の数を構成するために使
用されてもよい。このメッセージは、メッセージングシステム上で送信されてもよい。い
くつかの実施形態では、遠隔インターフェース８０２のＵＩプロセッサは、遠隔インター
フェース８０２の無線およびデバイス８００の無線の両方に、このコマンドを送信して、
これらの無線設定を構成する。

いくつかの実施形態では、無線構成メッセージには、２つのパラメータ、すなわち、Ｒ
Ｆ再試行の数（例えば、値は０から１０であってもよい）、および無線オフラインパラメ
ータ（例えば、値は帯域幅の割合で１から１００であってもよい）があってもよい。しか
しながら、種々の他の実施形態では、３つ以上または２つ未満のパラメータが存在しても
よい。

遠隔インターフェース８０２およびデバイス８００の両方の無線アプリケーションは、
メッセージングシステムがＲＦ再試行の数および無線オフラインパラメータを構成するこ
とを可能にする、ＡＰＩを有してもよい。

いくつかの実施形態では、制限されないが、以下のパラメータのうちの１つ以上が、無
線ハードウェア構成に推奨されてもよい。
・基礎無線仕様
・ＭＳＫ
・２５０ｋｂｐｓ以上の無線通信比率
・最大８４個のチャネル
・１０００ｋＨｚのチャネル間隔
・８１２ｋＨｚのフィルタ帯域幅
・マンチェスター符号化方式がない
・データ消去
・４バイトプリアンブル
・４バイト同期（単語）
・パケットに付加されたＣＲＣ
・パケットに付加されたＬＱＩ（リンク品質インジケータ）
・有効化された自動ＣＲＣフィルタリング

いくつかの実施形態では、順方向誤差補正（ＦＥＣ）が、使用されても、されなくても
よい。順方向誤差補正（ＦＥＣ）は、有効信号動的範囲を約３ｄＢ増加させるために使用
されるが、ＦＥＣは、固定パケットサイズを必要とし、同一固定サイズメッセージのため
の無線ビット数を倍にし、したがって、これは、いくつかの実施形態では、望ましくない
場合がある。

いくつかの実施形態では、無線は、（ペアリングモードを除いて）公称動作条件下で１
．８３メートルの距離内で機能してもよい。いくつかの実施形態では、無線が公称動作条
件下で７．３２メートルの距離内で機能することが目標であってもよい。いくつかの実施
形態では、伝送電力レベルは、（ペアリングモードを除いて）０ｄＢｍであってもよく、
ペアリングモードの伝送電力レベルは、−２２ｄＢｍであってもよい。デバイス８００の
所望の無線ノードアドレスが、ペアリングモードの遠隔インターフェース８０２によって
把握されていない場合があるため、デバイス８００および遠隔インターフェース８０２の
両方は、いくつかの実施形態では、別の注入ポンプアセンブリと偶発的にペアリングする
可能性を低減するために、より低い伝送電力を使用してもよい。しかしながら、種々の他
の実施形態では、デバイス８００または遠隔インターフェース８０２のいずれかは、より
低い伝送電力を使用してもよい。

いくつかの実施形態では、ＡＥＳ暗号化は、全てのパケットに使用されてもよいが、例
えば、Ｔｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓ ＣＣ２５１０無線送受信機を使用する実施
形態では、本送受信機は、本機能性を含むため、必要とされなくてもよい。ＡＥＳ暗号化
が使用される実施形態では、固定キーは、固定キーがキーを渡すことなく暗号化を可能に
する迅速な方法を提供することを含む、多くの理由から、望ましくあり得るため、固定キ
ーが利用されてもよい。しかしながら、いくつかの実施形態では、キー交換が、デバイス
８００内に提供されてもよい。いくつかの実施形態では、固定キーは、固定キーデータ以
外の他の変数を伴わない、１つの別個のヘッダソースに含有されてもよく、したがって、
ファイルのリードアクセスのより容易な管理を可能にする。
いくつかの実施形態では、無線ソフトウェアは、制限されないが、以下の８つのモード
のうちの１つ以上をサポートしてもよい。
・ペアリングモード
・ＲＦオフモード
・接続モード
・取得モード
・高速ハートビートモード
・低速ハートビートモード
・検索同期モード
・同期化取得モード
これらの全ては、図１２Ｂ−１２Ｃに図式的に描写される。

ペアリングは、遠隔インターフェース８０２と、デバイス８００との間で無線シリアル
番号を交換するプロセスであってもよい。遠隔インターフェース８０２は、デバイス８０
０がそのシリアル番号を把握しているとき、デバイス８００と「ペアリング」されてもよ
い。デバイス８００は、遠隔インターフェース８０２がそのシリアル番号を把握している
とき、遠隔インターフェース８０２と「ペアリング」されてもよい。
いくつかの実施形態では、ペアリングモード（その一実施形態は、図１２Ｄに図式的に
描写される）は、以下４つのメッセージがＲＦリンク上で交換されることを要求してもよ
い（しかしながら、種々の実施形態は、ＲＦリンクを経由して、交換されるより多い、少
ない、メッセージが交換される、または交換されないことを要求してもよい）。
・ＲＦペアリング要求（遠隔インターフェース８０２から任意のデバイス８００にブロ
ードキャストされる）
・ＲＦペアリング肯定応答（デバイスから遠隔インターフェース８０２）
・ＲＦペアリング確認要求（遠隔インターフェース８０２からデバイス８００）
・ＲＦペアリング確認肯定応答（デバイス８００から遠隔インターフェース８０２）

加えて、遠隔インターフェース８０２は、ＲＦペアリング中断メッセージを使用して、
随時、ペアリングプロセスを中断してもよい（遠隔インターフェース８０２からデバイス
８００）。いくつかの実施形態では、ペアリングモードは、メッセージングシステムデー
タ転送をサポートしなくてもよい。

いくつかの実施形態では、デバイス８００の無線は、ペアリングモード要求メッセージ
の受信に応じて、ペアリングモードになってもよい。いくつかの実施形態では、デバイス
８００に取着された使い捨て部分が存在せず、ユーザが、所定の時間量、例えば、６秒（
実施形態全体を通して異なり得る）の間、デバイス８００のスイッチアセンブリ８１０を
押下し、システムに、ペアリングモードが要求されたことを示す場合、無線にペアリング
モードになるよう要求することは、デバイス８００上のスーパーバイザプロセッサ９００
の責任であってもよい。デバイス８００の無線は、ペアリングモードに対する適切な伝送
電力レベルを設定してもよい。いくつかの実施形態では、デバイス８００は、１度に１つ
の遠隔インターフェース８０２とのみペアリングされてもよい。

いくつかの実施形態では、近距離通信（「ＮＦＣ」）プロトコルが使用され、デバイス
８００および遠隔インターフェース８０２がペアリングされていることを識別してもよい
。例えば、ＮＦＣを使用して、ユーザは、デバイスがペアリングモードにある間、遠隔イ
ンターフェース８０２の使い捨て部分にタッチしてもよく、これは、ペアリングプロトコ
ルをトリガし得、すなわち、デバイス８００および遠隔インターフェース８０２がペアリ
ングされていることが、識別される。いくつかの実施形態では、遠隔インターフェース８
０２上に位置する、カメラが使用され、デバイス８００上の２Ｄバーコードの画像を捕捉
し、本画像および／または画像識別を使用して、デバイス８００を識別してもよい。いく
つかの実施形態では、デバイス８００は、認識のために、ＮＰＣプロトコルにおいて使用
され得る、ＲＦＩＤ送信機を含んでもよい。

いくつかの実施形態では、ペアリングモードにある間、第１の有効なＲＦペアリング要
求メッセージの受信に応じて、デバイス８００の無線は、ペアリングモードの持続時間に
わたって、遠隔インターフェース８０２のシリアル番号を使用し、デバイス８００の無線
シリアル番号を含有する、ＲＦペアリング肯定応答メッセージで応答してもよい。

いくつかの実施形態では、デバイス８００の無線は、ＲＦペアリング要求が受信されな
い場合、所定の時間量、例えば、２．０±０．２秒後に自動的にペアリングモードからタ
イムアウトしてもよい。デバイス８００の無線は、ＲＦペアリング要求が受信されない場
合、自動的に、例えば、２．０±０．２秒後、ペアリングモードからタイムアウトしても
よい。いくつかの実施形態では、本時間は、２．０±０．２秒未満または超であってもよ
い。いくつかの実施形態では、デバイス８００の無線は、ＲＦペアリング肯定応答を伝送
した後に、ペアリング要求受信メッセージを発行してもよい。スーパーバイザプロセッサ
９００への本メッセージは、ペアリング確認プロセス中にユーザへのフィードバックを可
能にするであろう。デバイス８００の無線は、自動的に、ＲＦペアリング確認要求が受信
されない限り、ＲＦペアリング肯定応答を伝送してから、例えば、１．０±０．１秒後に
自動的にペアリングモードからタイムアウトしてもよい。いくつかの実施形態では、本時
間は、１．０±０．１秒秒未満または超であってもよい。いくつかの実施形態では、デバ
イス８００の無線は、ＲＦペアリング要求メッセージを受信した後にＲＦペアリング確認
要求メッセージが受信される場合、ペアリング無線シリアル番号の記憶メッセージを発行
してもよい。このアクションは、遠隔インターフェース８０２の無線シリアル番号をデバ
イス８００の不揮発性メモリに記憶してもよく、デバイス８００の既存のペアリングデー
タに上書きしてもよい。

デバイス８００の無線は、ペアリング無線シリアル番号の記憶メッセージからの肯定応
答が受信された後に、ＲＦペアリング確認肯定応答を伝送し、ペアリングモードを終了し
てもよい。いくつかの実施形態では、これは、デバイス８００上のペアリングモードから
のデフォルト終了であってもよく、ユーザによって接続モードまたはペアリングモードに
なるまで、デバイス８００の電力を低下させてもよい。

いくつかの実施形態では、デバイス８００の無線が、ペアリング確認要求メッセージの
正常受信に応じて、ペアリングモードを終了する場合、デバイス８００の無線は、新しく
ペアリングされた遠隔インターフェース８０２に戻ってもよく、ペアリング完了成功メッ
セージをコマンドプロセッサ９０２に送信してもよい。いくつかの実施形態では、デバイ
ス８００の無線は、ＲＦペアリング中断メッセージの受信に応じて、ペアリングモードを
終了してもよい。デバイス８００の無線は、それにアドレス指定されたペアリング中断要
求メッセージの受信に応じて、ペアリングモードを終了してもよい。いくつかの実施形態
では、これは、コマンドプロセッサ９０２またはスーパーバイザプロセッサ９００が、デ
バイス８００上でローカルにペアリングプロセスを中断することを可能にし得る。

いくつかの実施形態では、遠隔インターフェース８０２の無線は、ペアリングモード要
求メッセージの受信に応じて、ペアリングモードになってもよい。いくつかの実施形態で
は、無線が適切な条件下でペアリングモードになることを要求することが、遠隔インター
フェース８０２のＵＩプロセッサの責任であってもよい。遠隔インターフェース８０２の
無線は、ペアリングモードに対する適切な伝送電力レベルを設定してもよい。いくつかの
実施形態では、遠隔インターフェース８０２の無線は、ＲＦペアリング肯定応答が受信さ
れるか、またはペアリングが中断されるまで、ＲＦペアリング要求を伝送してもよい。

いくつかの実施形態では、遠隔インターフェース８０２の無線は、ペアリングモードに
なってから、所定の時間、例えば、３０．０±１．０秒以内にＲＦペアリング肯定応答メ
ッセージが受信されない場合、ペアリングモードを自動的に中断してもよい。しかしなが
ら、種々の実施形態では、所定の時間は、３０．０±１．０秒超または未満であってもよ
い。いくつかの実施形態では、ペアリングモードにある間、最初の有効ＲＦペアリング肯
定応答メッセージの受信に応じて、遠隔インターフェース８０２の無線は、デバイス８０
０のシリアル番号を含む、ペアリング成功メッセージを遠隔インターフェース８０２のＵ
Ｉプロセッサに送信してもよく、ペアリングモードの持続時間にわたってそのシリアル番
号を使用してもよい。このメッセージは、遠隔インターフェース８０２のＵＩプロセッサ
がユーザに所望のデバイス８００のシリアル番号を確認させるための手段を提供してもよ
い。いくつかの実施形態では、遠隔インターフェース８０２の無線がデバイス８００から
複数の応答（単一のペアリング要求に関して）を受信した場合、最初の有効なものが使用
されてもよい。

いくつかの実施形態では、遠隔インターフェース８０２の無線は、ペアリングモードで
ある間にＲＦペアリング肯定応答が受信された後に、ＲＦペアリング確認肯定応答メッセ
ージを容認するのみであってもよい。遠隔インターフェース８０２の無線は、遠隔インタ
ーフェース８０２のＵＩプロセッサからペアリング確認要求メッセージの受信に応じて、
ＲＦペアリング確認メッセージを伝送してもよい。

いくつかの実施形態では、遠隔インターフェース８０２の無線は、デバイス８００をペ
アリングリストに追加する前に、デバイス８００がペアリングを確認することをチェック
してもよい。いくつかの実施形態では、遠隔インターフェース８０２の無線は、ＲＦペア
リング完了メッセージが受信される場合、ペアリング無線シリアル番号の記憶メッセージ
を発行してもよい。このアクションは、遠隔インターフェース８０２のＵＩプロセッサが
デバイス８００の新規シリアル番号を記憶し、成功したペアリングのユーザフィードバッ
クを提供することを可能にしてもよい。ペアリングされた注入ポンプアセンブリのリスト
を管理することは、遠隔インターフェース８０２のＵＩプロセッサの責任であってもよい
。したがって、システムのいくつかの実施形態では、システムは、２つ以上のデバイスを
含んでもよく、２つ以上のデバイスはそれぞれ、遠隔インターフェース８０２とペアリン
グされてもよい。しかしながら、いくつかの実施形態では、ペアリングされたデバイスの
一方のデバイスが、任意の所与の時間において、遠隔インターフェース８０２と併用され
ることが望ましくあり得る。したがって、これらの実施形態では、初期ペアリングプロセ
スが完了し、遠隔インターフェース８０２は、ペアリングされたデバイスのそのリスト上
のデバイスを含むと、ユーザは、遠隔インターフェース８０２に、使用のためのその持続
時間（所定の時間量）の間、通信が所望されるデバイスを示す。

いくつかの実施形態では、遠隔インターフェース８０２の無線は、ペアリング中断要求
メッセージを送信し、ペアリング中断要求メッセージの受信に応じて、ペアリングモード
を終了してもよい。これは、遠隔インターフェース８０２のＵＩプロセッサが、遠隔イン
ターフェース８０２および肯定応答されたデバイス８００の両方でペアリングプロセスを
中断することを可能にしてもよい。

接続要求モードでは、遠隔インターフェース８０２の無線が、そのペアリングデバイス
リストの中の各デバイス８００を取得し、その「接続準備完了」状態を回復しようとして
もよい。その一実施形態が、図１２Ｅに図式的に描写される、「接続」プロセスは、いく
つかの実施形態では、遠隔インターフェース８０２が、使用される準備ができ得る、その
ペアリングされたデバイスのうちの１つを迅速に識別することを可能にし得る。遠隔イン
ターフェース８０２の無線は、複数のデバイス、例えば、いくつかの実施形態では、注入
ポンプの最大６つのペアリングされた再使用可能部分と接続要求モードを行なうことが可
能であってもよい。接続要求モードは、遠隔インターフェース８０２上でのみサポートさ
れてもよく、特殊な形態の取得モードであってもよい。接続要求モードでは、遠隔インタ
ーフェース８０２は、第１のデバイスと接続して応答してもよい。しかしながら、各メッ
セージは、特定のデバイスシリアル番号にダイレクトされてもよい。

いくつかの実施形態では、遠隔インターフェース８０２の無線は、接続モードになると
、最新のペアリングされたデバイスのシリアル番号のリストを取得してもよい。遠隔イン
ターフェース８０２の無線は、接続モード要求メッセージの受信に応じて、接続モードに
なってもよい。ペアリングデバイスとの通信を所望するときに、無線が接続モードになる
ことを要求することが、遠隔インターフェース８０２のＵＩプロセッサの責任であっても
よい。遠隔インターフェース８０２の無線は、該当する場合、「接続準備完了」である、
第１のデバイスの無線シリアル番号を含有する接続評価メッセージを、遠隔８０２インタ
ーフェースのＵＩプロセッサに発行してもよい。遠隔インターフェース８０２の無線は、
接続要求モードになってから、所定の時間量、例えば、３０秒以内に、接続査定メッセー
ジを発生させてもよい。しかしながら、所定の時間量は、種々の実施形態では、３０秒未
満または超であってもよい。いくつかの実施形態では、遠隔インターフェース８０２の無
線は、接続評価肯定応答の受信時に接続要求モードを終了し、高速ハートビートモードに
遷移してもよい。遠隔インターフェース８０２の無線は、遠隔インターフェース８０２の
ＵＩプロセッサから接続要求中断メッセージの受信に応じて、接続要求モードを終了して
もよい。

遠隔インターフェース８０２上では、特定のペアリングされたデバイスを見出すために
、取得モードが使用されてもよい。いくつかの実施形態では、遠隔インターフェース８０
２の無線は、ＲＦ ＲＵＴ（ａＲｅｙｏ ＵＴｈｅｒｅ）パケットを所望のペアリングデ
バイスに送信してもよい。デバイスが、ＲＦＲＵＴメッセージを受信する場合、遠隔イン
ターフェース８０２の無線に応答してもよい。いくつかの実施形態では、複数のチャネル
は、取得モードアルゴリズムで使用され、遠隔インターフェース８０２の無線が、ペアリ
ングされたデバイスを見出す機会を改善してもよい。

遠隔インターフェース８０２の無線は、ＲＦオフモードである間に、取得モード要求ま
たは高速ハートビートモード要求メッセージの受信に応じて、取得モードになってもよい
。遠隔インターフェース８０２の無線は、検索同期モードである間に、取得モード要求ま
たは高速ハートビートモード要求メッセージの受信に応じて、同期化取得モードになって
もよい。ＲＦリンクがオフラインであり、遠隔インターフェース８０２がデバイスとの通
信を所望するときに、無線が取得モードになることを要求することが、遠隔インターフェ
ース８０２のＵＩプロセッサの責任であってもよい。

いくつかの実施形態では、特に、デバイスが、注入ポンプであるそれらの実施形態では
、遠隔インターフェース８０２の無線は、１つのペアリングされた注入ポンプ８００との
み通信してもよい（ペアリングおよび接続モードを除いて）。いくつかの実施形態では、
通信が喪失されると、遠隔インターフェース８０２のＵＩプロセッサは、通信を復旧しよ
うとするために、（電力予算によって制限される、なんらかの周期率で）取得モードを使
用してもよい。
いくつかの実施形態では、デバイス８００は、以下の状態のうちの１つ以上の下、取得
モードになってもよいが、種々の他の実施形態では、付加的状態が、取得モードをトリガ
してもよい。
・無線オフモードであって、取得モードが要求されてもよいとき
・ハートビートの不足により検索同期モードがタイムアウトするとき

取得モードになると、デバイス８００の無線は、最後に記憶されたペアリング遠隔イン
ターフェース８０２のシリアル番号を得てもよい。デバイス８００の無線は、（「ペアリ
ング要求」モードである間を除いて）それが「ペアリング」されている遠隔インターフェ
ース８０２と通信するのみであってもよい。デバイス８００の無線は、遠隔インターフェ
ース８０２との同期化の取得が成功すると、取得モードから高速ハートビートモードに遷
移してもよい。デバイス８００の取得モードは、いくつかの実施形態では、６．１秒以内
に同期化を取得することが可能であってもよく、これは、取得モードであるときに、デバ
イス８００が、常に少なくとも約６秒ごとにリスニングしていてもよいことを示してもよ
い。しかしながら、種々の実施形態では、リスニングは、より短いまたは長い持続時間で
あってもよい。

いくつかの実施形態では、データパケットは、デバイス８００および遠隔インターフェ
ース８０２が、同期モードで、かつオンラインであるときに、例えば、ペアリングデバイ
ス８００と遠隔インターフェース８０２との間で送信されてもよい。２つのデバイスは、
データパケットが交換される前に、ハートビートパケットを介して同期化してもよい。各
無線は、ハートビート交換後に、既知の時間間隔でデータパケットを送信してもよい。デ
バイス８００は、パケットの受信を予期するタイミングを調整してもよい。いくつかの実
施形態では、無線は、各ハートビート上で各方向に１つのデータパケットをサポートして
もよい。無線は、無線がオフラインであれば、高速ハートビートモード要求に否定応答を
提供してもよい。遠隔インターフェース８０２の無線は、低速ハートビートモードであり
、無線がオンラインである間に、高速ハートビートモードのシステム要求が受信される場
合、高速ハートビートモードに変更してもよい。

取得モードから高速ハートビートモードに遷移すると、遠隔インターフェース８０２の
無線は、マスタチャネルリストメッセージを送信してもよい。マスタチャネルリストは、
遠隔インターフェース８０２の無線によって構築され、過去の性能に基づいて周波数ホッ
ピングチャネルの選択を可能にするように、デバイス８００の無線に送信されてもよい。
高速ハートビートモードまたは低速ハートビートモードであるときに、周期的ハートビー
トメッセージが遠隔インターフェース８０２の無線とデバイス８００の無線との間で交換
されてもよい。これらのメッセージの周期性は、ハートビート比率におけるものであって
もよい。ハートビートメッセージは、データパケット転送が行われることを可能にしても
よく、また、状態情報を交換してもよい。いくつかの実施形態では、２つの無線が、休眠
モード、データ可用性、バッファ可用性、ハートビート比率、および以前のチャネル性能
の状態情報を交換してもよいが、しかしながら、他の実施形態では、付加的情報またはよ
り少ない情報が、交換されてもよい。いくつかの実施形態では、電力を節約するために、
ハートビートメッセージのパケットサイズを小さく保つことが、目標であってもよい。こ
れらの実施形態では、無線は、同期モードであるときに、８２バイトの最大データパケッ
トサイズを提供してもよい。メッセージングシステムは、例えば、最大６４バイトのパケ
ットペイロードサイズをサポートするように設計されてもよい。この最大サイズは、最小
メッセージタイプと非断片化メッセージとの間の最適なトレードオフとして、選択されて
もよい。いくつかの実施形態では、８２バイトは、パケットオーバーヘッドを含む、メッ
セージングシステムの最大パケットサイズであってもよい、しかしながら、種々の実施形
態では、本最大パケットサイズは、大きいまたは小さくてもよい。

いくつかの実施形態では、メッセージングシステムは、無線プロトコルがそれに受信無
線パケットを送信することを可能にする、ＡＰＩを有する。メッセージングシステムはま
た、無線ネットワーク上での伝送のために、無線プロトコルがパケットを得ることを可能
にする、ＡＰＩを有してもよい。メッセージングシステムは、無線プロトコルとＳＰＩポ
ートとの間のパケットルーティングに関与してもよい。データパケットは、処理のために
メッセージングシステムに与えられてもよい。メッセージングシステムは、無線プロトコ
ルが、無線ネットワーク上で送信されることを待機しているデータパケットの数のカウン
トを得ることを可能にする、ＡＰＩを有してもよい。無線プロトコルは、各ハートビート
においてメッセージングシステムに問い合せを行い、データパケットが無線ネットワーク
上で送信するために利用可能であるかどうかを判定してもよい。往復メッセージ待ち時間
を最小限化するように、ハートビートが送信される直前に、ソフトウェアがメッセージの
可用性をチェックすることが望ましくてもよい。

無線プロトコルは、１つの受信無線データパケットをバッファリングすること、および
メッセージングシステムにパケットをパスすることが可能であってもよい。いくつかの実
施形態では、無線プロトコルは、データパケットの受信時に、メッセージングシステムに
データパケットを送信してもよい。メッセージシステムは、適正な宛先ノードに無線デー
タパケットを送ることに関与してもよい。無線プロトコルは、メッセージングシステムか
らの１つのパケットをバッファリングすることが可能であってもよい。

無線プロトコルは、送信無線へのＲＦ ＡＣＫ返信パケットを介して、ＲＦリンク上で
の有効なデータパケットの受信を肯定応答することに関与してもよい。ＲＦ ＡＣＫパケ
ットは、ソースおよび宛先無線シリアル番号、ＲＦ ＡＣＫコマンド識別、および肯定応
答されているデータパケットのシーケンス番号を含有してもよい。

いくつかの実施形態では、無線データパケットを伝送する無線は、ＲＦ ＡＣＫが受信
されず、再試行カウントが許容される最大ＲＦ再試行以内であれば、同じシーケンス番号
とともに、次のハートビート上で、その無線データパケットを再伝送してもよい。干渉が
、特定の周波数上の伝送を妨害する場合、いくつかの実施形態では、ＲＦ再試行は、同じ
パケットが、異なる周波数において次の機会で再伝送されることを可能にする。シーケン
ス番号は、短い時間枠でパケットを一意的に識別する手段を提供する。無線パケット再試
行の数は、無線構成コマンドを使用して構成可能であってもよい。より多くの再試行を許
容にすることにより、交換されているパケットの確率を増加させてもよいが、往復メッセ
ージのさらなる待ち時間を導入する。電力増加時の無線再試行のデフォルト数は、１０で
あってもよい（すなわち、メッセージをドロップする前の最大伝送試行）。しかしながら
、本最大数は、種々の実施形態では異なってもよい。

いくつかの実施形態では、１バイト（モジュロ２５６）無線シーケンス番号が、ＲＦリ
ンク上の全ての無線データパケットに含まれてもよい。肯定応答されない場合、データパ
ケット伝送を再試行することに無線が関与し得るため、シーケンス番号は、データパケッ
トが重複するかどうかを２つの無線が把握するための方法を提供してもよい。伝送された
シーケンス番号は、それぞれの新規無線データパケットについてインクリメントされても
よく、ロールオーバーすることが可能になってもよい。以前に受信が成功したデータパケ
ットと同じシーケンス番号とともに（かつ同じ方向で）、データパケットの受信が成功す
ると、データパケットが肯定応答されてもよく、受信されたデータパケットが廃棄されて
もよい。これは、ネットワークに導入される前に、ＲＦプロトコルによって生成された重
複パケットを除去してもよい。極限状況下で、同じシーケンス番号とともに、連続した複
数のデータパケットがドロップされる必要があり得る状態が起こり得る場合があることに
留意されたい。

いくつかの実施形態では、ハートビートが欠落する場合、遠隔インターフェース８０２
の無線およびデバイス８００の無線は、それぞれ、後続ハートビートを送信し、リスニン
グしようとしてもよい。遠隔インターフェース８０２の無線およびデバイス８００の無線
は、ハートビートが２秒間欠落する場合、高速ハートビートモードまたは低速ハートビー
トモードから検索同期モードへ自動的に変化してもよい。２秒が全てのチャネルを次々と
切り替えるのに十分な時間を許容するため、これは、無線が同期化情報を使用し続けるこ
とを可能にすることによって、リンクが失われたときに電力消費を最小限化してもよい。

いくつかの実施形態では、無線は、以下のモードであるときにオンラインと見なされて
もよい。
・高速ハートビートモード
・低速ハートビートモード
いくつかの実施形態では、これらは、メッセージングシステムトラフィックが交換され
てもよい、唯一の状態であり得る。全ての他の状態は、オフラインと見なされてもよい。

無線は、リセットからのコード実行の開始時に、無線オフモードに初期化してもよい。
コードが最初に無線プロセッサ上で実行すると、初期状態は、無線が動作中となることを
要求する前に、他のプロセッサがセルフテストを行うことを可能にするように、無線オフ
モードであってもよい。この要件は、休止モードからウェークするときにモードを定義す
ることを意図しない。無線は、無線オフモードに設定されると、ＲＦ通信を中止してもよ
い。遠隔インターフェース８０２上で、このモードは、ＲＦ放出を抑制するための航空機
上、すなわち、航空機モードでの使用を意図してもよい。デバイス８００が、遠隔インタ
ーフェース８０２（航空機モードで伝送を中止する）からの伝送にしか応答しないため、
無線オフモードは、充電するとき、デバイス８００上でのみ使用されてもよい。

いくつかの実施形態では、コマンドプロセッサ９０２は、航空機モード、したがって、
ウォークアウェイ警告を生成しないように、ＲＦが遠隔インターフェース８０２上で意図
的にオフにされたことを通知されてもよい。しかしながら、これは、デバイス８００の無
線から完全に隠されてもよい。

いくつかの実施形態では、遠隔インターフェース８０２の無線およびデバイス８００の
無線は、検索同期モードである間に、データ帯域幅を再確立するために、周期的にハート
ビートを交換しようとしてもよい。遠隔インターフェース８０２の無線は、ハートビート
の交換が成功せず、所定の時間周期、例えば、検索同期モードの２０分後に、無線オフモ
ードに遷移してもよい。

いくつかの実施形態では、デバイスの無線は、ハートビートの交換が成功せず、所定の
時間量、例えば、検索同期モードの２０分後に、取得モードに遷移してもよい。いくつか
の実施形態では、事前同意されたタイムスロット中にリスニングすることは、ＲＦリンク
を再確立するための、デバイス８００の電力の最も効率的な使用である。通信の喪失後、
結晶耐性および温度ドリフトが、経時的にデバイス８００の受信時間枠を拡張することを
必要とし得る。長期間（例えば、５〜２０分）にわたって、通信喪失後、検索同期モード
にとどまっていることにより、消費される瞬時電力に、デバイス８００の無線に割り当て
られた平均電力を超えさせる場合がある。遠隔インターフェース８０２の無線は、その時
間枠を拡張することを強いられなくてもよいため、検索同期モードにとどまっていること
は、非常に電力効率が良くあり得る。取得モードは、遠隔インターフェース８０２により
多くの電力を消費してもよい。いくつかの実施形態では、遠隔インターフェース８０２の
無線およびデバイス８００の無線の両方で電力消費のバランスを保つために、２０分が妥
協として使用されてもよいが、しかしながら、本時間は、実施形態に伴って異なってもよ
い。

遠隔インターフェース８０２の無線およびデバイス８００の無線は、あるハートビート
群の所定のパーセンテージ、例えば、最後の５つのハートビートのうちの３つの交換が成
功する場合、低速ハートビートモードに遷移してもよい。次いで、所定の間隔、例えば、
約６秒ごとに、５つのハートビートのバースト（または、実施形態に応じて、それ以上、
またはそれ未満）が試行されてもよい。これらの所定のパーセンテージ、例えば、これら
のうちの３つが成功する場合、帯域幅が低速ハートビートに遷移するのに十分と仮定され
てもよい。デバイス８００の無線は、例えば、６．１秒の待ち時間を伴う検索同期モード
である間に、取得可能であってもよいが、しかしながら、本待ち時間は、実施形態に伴っ
て異なってもよい。本実施形態では、これは、デバイス８００が、検索同期モードである
とき、常に、少なくとも約６秒ごとにリスニングしていてもよいことを示し得る。

無線プロトコル性能統計が、無線のトラブルシューティングを推進するため、および無
線性能を評価するために、所望され得る。いくつかの実施形態では、以下の無線性能統計
は、無線プロトコルによってデータ構造内で維持されてもよい。しかしながら、これらは
、単に、一実施形態であって、これらは、実施形態全体を通して異なってもよい。いくつ
かの実施形態は、統計を使用しなくてもよく、あるいはより多い、少ない、または異なる
統計を使用してもよい。

いくつかの実施形態では、チャネルごとに、以下の追加無線性能統計のうちの１つ以上
を収集するために、＃ｄｅｆｉｎｅＤＥＢＵＧオプション（コンパイラオプション）が使
用されてもよい（１６ビット数）が、しかしながら、種々の他の実施形態では、付加的情
報もまた、収集されてもよい。
・欠落ホップの数
・良好ＣＣＡカウント
・不良ＣＣＡカウント
・平均ＲＳＳＩ（良好ＲＸパケットのみについて累積される）
・周波数ホップリストカウントからのドロップ
・取得モードカウント（このチャネル上で見出された１対）

いくつかの実施形態では、デバッグオプションが、エンジニアリング専用統計を収集す
るために使用されてもよい。プロセッサ性能、電力、およびメモリが許容する場合、本情
報をランタイムに維持することが望ましくあり得る。無線統計は、メッセージングシステ
ムに利用可能になってもよい。

いくつかの実施形態では、リンク品質は、遠隔インターフェース８０２上で使用／閲覧
可能であって、携帯電話と同様に、無線リンク品質のバーインジケータを提供することを
意図してもよい。リンク品質は、遠隔インターフェース８０２およびデバイス８００の両
方に利用可能であってもよい。いくつかの実施形態では、リンク品質状態は、無線リンク
の品質の１バイトインジケータから成ってもよい。

いくつかの実施形態では、無線は、各ハートビートごとに周波数を変化させてもよい。
適応擬似乱数周波数ホッピングアルゴリズムが、同期モードのために使用されてもよく、
ハートビートが、検索同期モードにおいて試行される。いくつかの実施形態では、周波数
ホッピングに、例えば、６４のチャネルを使用することが目標であってもよい。しかしな
がら、周波数ホッピングを使用する他の実施形態では、６４超または未満のチャネルが、
使用されてもよい。いくつかの実施形態では、アルゴリズムは、周波数ホッピングに関し
て、遠隔インターフェース８０２上でチャネルリストを適応的に発生させるように開発さ
れてもよい。遠隔インターフェース８０２の無線は、マスタチャネルリストを構築、維持
、配信してもよい。いくつかの実施形態では、以前のチャネル統計および過去の性能情報
が、性能要件を満たすために、必要に応じてメッセージングシステムを使用して、遠隔イ
ンターフェース８０２の無線によって、デバイス８００の無線から取得されてもよい。デ
バイス８００および遠隔インターフェース８０２の両方の観点からチャネルリストを作成
することによって、両ユニットの無線干渉環境が、考慮されてもよい。無線は、望ましい
ＲＦ環境において動作している間、ホッピングチャネルを適応的に選択し、往復メッセー
ジ待ち時間を満たしてもよい。

次に、また、図１３を参照すると、いくつかの実施形態では、システムは、注入ポンプ
の少なくとも２つの再使用可能部分１３００、１３０８と、注入ポンプの少なくとも１つ
の使い捨て部分１３１０とを含んでもよい。いくつかの実施形態では、再使用可能部分１
３００、１３０８は、再充電可能バッテリ５３２を含む。いくつかの実施形態では、２つ
の使い捨て部分は、図１３に１３０２として示される実施形態および／または図６−８に
６００、７００、８０２として示される任意の１つ以上を含み得る、同一の遠隔インター
フェースにペアリングされてもよい。いくつかの実施形態では、ユーザは、前述のように
、再使用可能部分１３０８と使い捨て部分１３１０を接続するように、使い捨て部分１３
１０に一致させながら、矢印１３１６の方向に、再使用可能部分１３０８を回転させるこ
とによって、再使用可能部分１３０８を使い捨て部分１３１０に接続してもよい。第２の
再使用可能部分１３００は、再充電エリア１３０６内の電気接点（図示せず）を通して、
再充電ステーション１３０４に接続することによって、再充電ステーション１３０４上に
ドッキングされてもよい。ユーザが、睡眠中、または別様に、長時間周期の間、例えば、
３時間、単一エリア内に留まっている間、遠隔インターフェース１３０２は、スロット１
３１８内の電気接点（図示せず）を通して、再充電ステーション１３０４に接続すること
により、遠隔インターフェース１３０２を再充電ステーション１３０４上にドッキングす
ることによって、再充電されてもよい。いくつかの実施形態では、電気接点は、遠隔イン
ターフェース１３０２がスロット１３１８内に配置されると、遠隔インターフェース１３
０２と連結するように構成され得る、ＵＳＢプラグであってもよい。ＵＳＢプラグは、遠
隔インターフェース１３０２へ／からのデータ転送ならびに遠隔インターフェース１３０
２の充電を可能にしてもよい。いくつかの実施形態では、ユーザは、第２の再使用可能部
分１３００を再充電しながら、一方の再使用可能部分１３０８を使用してもよい。

次に、図１４Ａ−１４Ｅを参照すると、注入ポンプシステムの別の実施形態が、示され
る。システムは、遠隔インターフェース１４０２と、１つの再使用可能部分１４００と、
第２の再使用可能部分１４０６と、少なくとも１つの使い捨て部分１４０８と、遠隔イン
ターフェース１４０２を充電し、および／または１つまたは２つの使い捨て部分１４００
、１４０６を充填するための充電ステーション１４０４とを含んでもよい。いくつかの実
施形態では、充電ステーションは、２００７年１０月４日公開の米国公報第ＵＳ−２００
７−０２２８０７１号（弁理士整理番号Ｅ７０）および２００９年１２月３日公開の米国
公報第ＵＳ−２００９−０２９９２７７号（弁理士整理番号Ｇ７５）ならびに２０１０年
１２月２９日出願の米国特許出願第１２／９８１，２８３号「Ｉｎｆｕｓｉｏｎ Ｐｕｍ
ｐ Ａｓｓｅｍｂｌｙ」（弁理士整理番号Ｉ４１）（参照することによって、全体として
本明細書に組み込まれる）のうちの１つ以上に図示および／または説明されるものに示さ
れる任意の充電ステーション、または任意の充電ステーションに類似してもよい。図１３
に関して上記で議論されるように、充電ステーションは、遠隔インターフェース１４０２
がスロット１４１４内に配置されると、遠隔インターフェース１４０２と連結するように
構成され得る、ＵＳＢプラグを含んでもよい。ＵＳＢプラグは、遠隔インターフェース１
４０２へ／からのデータ転送ならびに遠隔インターフェース１４０２の充電を可能にして
もよい。

次に、図１５Ａ−１５Ｂを参照すると、充電ステーション１５００の別の実施形態が、
示される。示されるように、いくつかの実施形態では、充電ステーション１５００は、再
使用可能部分のための充電エリア１５０４と、ＵＳＢプラグを含み得る、遠隔インターフ
ェースのための充電エリア１５０２とを含んでもよい。いくつかの実施形態では、充電ス
テーション１５００は、ＵＳＢポート１５０８を含んでもよく、いくつかの実施形態では
、ミニＵＳＢポートを含み、いくつかの実施形態では、ＵＳＢ１５０６を通して、再使用
可能部分および／または遠隔インターフェースを充電するために、充電ステーション１５
００が、電力を受容することを可能にしてもよい。加えて、および／または代替として、
ＵＳＢポート１５０８は、遠隔インターフェースおよび／または再使用可能部分へ／から
のデータ転送のため、および／またはコンピュータあるいは他のデバイスおよび／または
他のコンピュータタイプ装置への接続によって、構成されてもよい。ＵＳＢポートを含む
実施形態では、遠隔インターフェースが充電されている間、システムは、パーソナルコン
ピュータおよび／またはウェブポータルを呼び出し、アップデートされたソフトウェアを
チェックし、アップデートされたソフトウェアが利用可能である場合、ソフトウェアアッ
プデートをダウンロードしてもよい。これらのアップデートは、次いで、ペアリングに応
じて、再使用可能部分に転送されてもよい。

次に、また、図１６Ａ−１６Ｆを参照すると、上記で議論されるように、再使用可能部
分１６０２は、例えば、再充電可能バッテリを含み得る、バッテリ１６３２を含んでもよ
い。バッテリ充電器１６００は、バッテリ１６３２を再充電するように構成されてもよい
。バッテリ充電器１６００は、上部プレート１６０４を有する、筐体１６０２を含んでも
よい。上部プレート１６０４は、概して、再使用可能筐体アセンブリ１６０２の電気接点
１６３４に電気的に連結されるように構成される、１つ以上の電気接点１６０６を含んで
もよい。電気接点１６０６は、制限ではないが、電気接点パッド、バネ偏向電気接点部材
、または同等物を含んでもよい。加えて、上部プレート１６０４は、再使用可能筐体アセ
ンブリ１６０２のベースプレート１６１８内の開口部１６３６、１６３８と噛合するよう
に構成され得る、整合タブ１６０８、１６１０を含んでもよい（例えば、図５Ｃに示され
るように）。整合タブ１６０８、１６１０および開口部１６３６、１６３８の協働は、バ
ッテリ充電器１６００の電気接点１６０６が、再使用可能筐体アセンブリ１６０２の電気
接点１６３４と電気的に連結し得るように、再使用可能筐体アセンブリ１６０２が、バッ
テリ充電器１６００と整合されることを確実にし得る。

バッテリ充電器１６００は、再使用可能部分１６０２に取り外し可能に係合するように
構成されてもよい。例えば、使い捨て部分と同様の様式で、バッテリ充電器１６００は、
１つ以上の係止タブ（例えば、係止タブ１６１２、１６１４）を含んでもよい。係止タブ
（例えば、係止タブ１６１２、１６１４）は、係止リングアセンブリ１６０６のタブ１６
４２、１６４４、１６４６、１６４８によって係合されてもよい。したがって、再使用可
能部分１６０２は、図１６Ｃに示されるように、係止リング１６０６を第１の係止解除位
置に伴う、バッテリ充電器１６００と整合されてもよい（整合タブ１６０８、１６１０を
介して）。係止リング１６０６は、矢印１６１６の方向に、バッテリ充電器１６００に対
して回転され、図１６Ｄに示されるように、係止リング１６０６のタブ１６４２、１６４
４、１６４６、１６４８と、バッテリ充電器１６００の係止タブ（例えば、係止タブ１６
１２、１６１４）を取り外し可能に係合してもよい。

いくつかの実施形態では、バッテリ充電器１６００は、例えば、いくつかの実施形態で
は、再使用可能部分１６０２の圧送および弁作用構成要素を収容するための隙間を提供し
得る、陥凹領域１６１８を含んでもよい。また、図１６Ｅ−１６Ｆを参照すると、バッテ
リ充電器１６００は、再使用可能部分１６０２の再充電バッテリ１６３２のために、電流
を電気接点１６０６（それによって、電気接点１６３４を介して、再使用可能部分１６０
２）に提供してもよい。いくつかの実施形態では、完全係合された再使用可能部分を示す
信号が提供されないと、電流は、電気接点１６０６に提供されなくてもよい。そのような
実施形態によると、短絡回路（例えば、異物が電気接点１６０６に接触することによって
生じる）および再使用可能部分１６０２への損傷（例えば、電気接点１６０６と電気接点
１６３４との間の不適切な初期整合から生じる）と関連付けられたリスクが、低減され得
る。加えて、いくつかの実施形態では、バッテリ充電器１６００は、バッテリ充電器が、
再使用可能部分１６０２を充電していないとき、不必要に電流を引き込まなくてもよい。

依然として、図１６Ｅ−１６Ｆを参照すると、バッテリ充電器１６００は、下側筐体部
分１６２４および上部プレート１６０４を含んでもよい。印刷回路基板１６２２（例えば
、電気接点１６０６を含んでもよい）は、上部プレート１６０４と下側筐体部分１６２４
との間に含まれる空洞内に配置されてもよい。

依然として、図１６Ａ−１６Ｆを参照すると、いくつかの実施形態では、バッテリ充電
器１６００は、壁充電器および／またはコンピュータおよび／またはパーソナルコンピュ
ータおよび／または遠隔インターフェースと連結するように構成され得る、ＵＳＢプラグ
１６５０を含んでもよい。ＵＳＢプラグ１６５０は、バッテリ充電器１６００を使用して
、コンピュータ／遠隔インターフェース１４０２へ／からのデータ転送ならびに再使用可
能部分１６０２の充電への電力の提供を可能にし得る。

また、図１７を参照すると、注入ポンプシステムの種々の部品が、相互に接続／通信す
る様式の一例証的実施例が示される。例えば、バッテリ充電器１７０４は、例えば、いく
つかの実施形態では、ＲＳ２３２フォーマットデータを、例えば、Ｉ２Ｃフォーマットデ
ータに変換する、バス変換装置１７０２を介して、コンピューティングデバイス１７００
（いくつかの実施形態では、パーソナルコンピュータ、またはパーソナルコンピュータと
類似方式で使用され得る、任意のデバイス、例えば、制限されないが、タブレットであっ
てもよい）に連結されてもよい。バス変換装置１７０２は、上記の変換を達成する、パス
スループログラムを実行してもよい。バッテリ充電器１７０４は、（上記で説明される）
電気接点１６０６を介して、無線プロセッサ１７１８に連結されてもよい。次いで、無線
プロセッサ１７１８は、例えば、ＲＳ２３２バスを介して、スーパーバイザプロセッサ９
００およびコマンドプロセッサ９０２に連結されてもよい。無線プロセッサ１７１８は、
いくつかの実施形態では、スーパーバイザプロセッサ９００およびコマンドプロセッサ９
０２によってアクセス可能なフラッシュメモリの更新を、無線プロセッサ１７１８が制御
／編成することを可能にする、更新プログラムを実行してもよい。したがって、上記の連
結の使用を通して、計算デバイス１７００によって得られるソフトウェア更新が、スーパ
ーバイザプロセッサ９００およびコマンドプロセッサ９０２によってアクセス可能なフラ
ッシュメモリ（図示せず）にアップロードされてもよい。上記のソフトウェア更新は、い
くつかの実施形態では、スクリプトプロセスによって自動的に呼び出されてもよい、コマ
ンドラインプログラムであってもよい。

次に、図１８および図１９を参照すると、デバイス、遠隔インターフェース、およびパ
ーソナルコンピュータ（いくつかの実施形態では、１つ以上のウェブポータルおよび／ま
たは１つ以上のセキュアなウェブポータルへのアクセスを有する）間の通信の２つの実施
形態が、示される。図１８では、遠隔インターフェース１８００は、注入ポンプ１８０２
と、いくつかの実施形態では、血中グルコースメータ１８０６および持続的グルコースモ
ニタセンサ／送信機１８０４を含み得る、２つの他のデバイスと通信する。いくつかの実
施形態では、通信は、無線通信であって、ＲＦ通信、例えば、前述のようなＲＦ通信プロ
トコルを使用してもよく、および／またはＢＬＵＥＴＯＯＴＨ（登録商標）または他の非
専用プロトコルを使用してもよい。いくつかの実施形態では、遠隔インターフェース１８
００は、パーソナルコンピュータ１８０８と無線通信するが、しかしながら、いくつかの
実施形態では、遠隔インターフェース１８００は、ＵＳＢ接続および／または他の有線接
続を介して、パーソナルコンピュータ１８０８に接続されてもよい。いくつかの実施形態
では、遠隔インターフェース１８００およびパーソナルコンピュータ１８０８は、ウェブ
／インターネット接続１８１０を介しておよび／または遠隔インターフェース１８００が
情報をインターネットにアップロードし、かつパーソナルコンピュータ１８０８が情報を
インターネットからダウンロードすることによって、通信してもよい。

図１９では、遠隔インターフェース１９００は、注入ポンプ１９０２と通信する。注入
ポンプ１９０２は、いくつかの実施形態では、血中グルコースメータ１９０６および／ま
たは持続的グルコースモニタセンサ／送信機１９０４を含み得、いくつかの実施形態では
、２つの持続的グルコースモニタセンサであり得る、２つの他のデバイスと通信する。い
くつかの実施形態では、通信は、無線通信であって、ＲＦ通信、例えば、前述のようなＲ
Ｆ通信プロトコルを使用してもよく、および／またはＢＬＵＥＴＯＯＴＨ（登録商標）、
あるいは低エネルギーＢＬＵＥＴＯＯＴＨ（登録商標）を含むが、それらに制限されない
、他の非専用プロトコルを使用してもよい。いくつかの実施形態では、遠隔インターフェ
ース１９００と無線通信する、注入ポンプ１９０２は、２つのデバイス１９０４、１９０
６から受信した情報を遠隔インターフェース１９００に通信してもよい。遠隔インターフ
ェース１９００は、したがって、遠隔インターフェース１９００が、いくつかの実施形態
では、ディスプレイを含むため、視覚ＵＩとしての役割を果たす。いくつかの実施形態で
は、遠隔インターフェース１９００は、パーソナルコンピュータ１９０８（いくつかの実
施形態では、少なくとも１つのウェブポータルおよび／またはセキュアなウェブポータル
へのアクセスを有する）と無線通信するが、しかしながら、いくつかの実施形態では、遠
隔インターフェース１９００は、ＵＳＢ接続および／または他の有線接続を介して、パー
ソナルコンピュータ１９０８に接続されてもよい。いくつかの実施形態では、遠隔インタ
ーフェース１９００およびパーソナルコンピュータ１９０８は、ウェブ／インターネット
接続１９１０を介して、および／または遠隔インターフェース１９００が情報をインター
ネットにアップロードし、パーソナルコンピュータ１９０８が、情報をインターネットか
らダウンロードすることを介して、通信してもよい。

図１８および１９の両方に関して、直接または間接的にのいずれかで、遠隔インターフ
ェースと通信する、３つのデバイスが示されるが、システムは、３つのデバイスに制限さ
れず、いくつかの実施形態では、４つ以上のデバイスを含んでもよい。加えて、いくつか
の実施形態では、システムは、遠隔インターフェース１９００と通信する１つのデバイス
を含んでもよい。また、１つのパーソナルコンピュータが、図１８および１９に図示され
るが、他の実施形態では、１つ以上のパーソナルコンピュータが、情報を遠隔インターフ
ェースから受信するために使用されてもよい。加えて、バッテリ充電器および充電ステー
ションに関して上記で議論されるように、いくつかの実施形態では、注入ポンプおよび／
または遠隔インターフェースは、充電ステーションに接続されてもよく、ＵＳＢ接続を介
して、アップロードおよび／またはダウンロードする、および／またはパーソナルコンピ
ュータと通信されてもよい。

上記で議論されるように、注入ポンプ実施形態の種々の実施形態では、システムは、２
つ以上の再使用可能部分を含んでもよい。これらの場合には、いくつかの実施形態では、
一方の再使用可能部分が使用中、他方は、再充電器上にあってもよい。第１の再使用可能
部分が、前述のように、使用中、治療薬が、スーパーバイザプロセッサおよびコマンドプ
ロセッサによって投与されてもよい。再使用可能部分による作用は、遠隔インターフェー
スに通信される。再使用可能部分を「切り替える」ために（充電器上の再使用可能部分が
、使用中の再使用可能部分となる、またはその逆となるように）、使用中、第１の再使用
可能部分から情報をアップロードしたコントローラは、第２の再使用可能部分上のメモリ
が、第１の再使用可能部分と同一のメモリの全てを含むように、種々のログを第２の再使
用可能部分上にダウンロードする。これは、ペアリングプロセスの間に行なわれる。プロ
セスのあるステップでは、ポンプアクティブ化後、いくつかの実施形態では、遠隔インタ
ーフェースが接続モードにある間、ユーザが再使用可能部分上のスイッチアセンブリを押
下することによって行なわれる。本ステップの間、プロファイルおよびユーザ療法構成が
、第２の再使用可能ポンプに転送され、および／または再使用可能部分不揮発性メモリと
同期される。

本ステップが完了すると、いくつかの実施形態では、第２の再使用可能部分は、内部化
後、遠隔インターフェースが、基礎プロファイルが正しいことを検証するように、基礎プ
ロファイルを遠隔インターフェースに返送する。本ステップは、第２の再使用可能部分が
、正しい情報を情報したことを確認し得る。いくつかの実施形態では、ディスプレイは、
ユーザに、基礎プロファイルを示してもよく、ユーザは、確認してもよい。

したがって、療法投与に関して前述のように、注入ポンプは、全決定を完了し、注入可
能流体の送達を制御する。遠隔インターフェースは、注入ポンプへのインターフェースで
あって、いくつかの実施形態では、デバイス（例えば、注入ポンプ）および／またはユー
ザと相互作用する多様な機会を伴う、向上したユーザインターフェース（例えば、ディス
プレイ画面）を提供する。

療法に関連する情報は、したがって、コントローラ上および再使用可能部分／注入ポン
プ不揮発性メモリ内の両方に記憶される。したがって、再使用可能部分と遠隔インターフ
ェースとの間の接続プロセスの間、遠隔インターフェースは、再使用可能部分がアップデ
ートされた情報を含有することを確認してもよい。遠隔インターフェースが、再使用可能
部分がアップデートされた情報を含有していないと判定する場合、遠隔インターフェース
は、情報をアップデートし、および／または再使用可能部分の不揮発性メモリをアップデ
ートされた情報と同期させる。したがって、種々の実施形態では、全ての療法情報および
／またはプロファイルは、注入ポンプの再使用可能部分および遠隔インターフェース上の
両方に記憶されてもよい。

上記で議論されるように、デバイス８００（いくつかの実施形態では、注入ポンプであ
る）は、注入可能流体をユーザに送達するように構成されてもよい。さらに、注入ポンプ
８００は、連続および／または複数回、および／または離散注入事象および／または単回
注入事象を含み得る、注入事象を介して、注入可能流体を送達してもよい。注入事象のう
ちのいくつかは、制限されないが、ボーラス、拡張ボーラス、基礎量、一時的基礎量、組
み合わせボーラスのうちの１つ以上を含んでもよい。当技術分野で公知のように、基礎注
入事象とは、例えば、ユーザによって、またはシステムによって、停止されるまで反復さ
れてもよい、所定の間隔（例えば、３分ごと）での注入可能流体の少量の反復注入を指す
。さらに、基礎注入比率は、事前にプログラムされてもよく、事前にプログラムされた時
間枠に対する指定比率、例えば、午前６時〜午後３時までは毎時０．５０単位の比率、午
後３時〜午後１０時までは毎時０．４０単位の比率、および午後１０時〜午前６時までは
毎時１．０単位の比率を含んでもよく、および／または、例えば、１時間に０．５０単位
、次いで、２時間に１．０単位、次いで、３０分間に０．０５単位という、事前にプログ
ラムされた時間枠を含んでもよい。いくつかの実施形態では、基礎比率は、一定、例えば
、毎時１．０単位のままであるように事前にプログラムされてもよく、時間枠全体を通し
て変化しなくてもよい。基礎比率は、別様に変更されない限り、定期的に／毎日および／
または特定の日に反復されてもよい。これらの事前にプログラムされた基礎比率は、基礎
プロファイルと称されてもよい。

一時的基礎比率は、所定の時間枠の間の既存の基礎プロファイル／基礎比率の修正を指
す。例えば、既存の基礎プロファイルが、午前６時から午前１０までは２．０単位の比率
を含む場合、一時的基礎比率は、そのパーセンテージあたりで２．０単位比率を増減のい
ずれかを行なうことによって、例えば、所定の時間周期、例えば、３０分にわたって、比
率を２０％減少させることによって、パーセンテージあたりで２．０単位の比率を修正す
ることが要求され得る。いくつかの事例では、一時的基礎は、基礎プロファイル比率より
高いかまたは低いかのいずれかの１００％の修正を含んでもよく、したがって、いくつか
の事例では、一時的基礎比率は、所定の時間周期の間、毎時０．００単位であってもよい
。

当技術分野において公知のように、ボーラスは、通常ボーラスとして送達されるとき、
典型的には、デバイスが流体を送達することができる比率で送達される、所定の流体の体
積である。いくつかの実施形態では、所定の体積、例えば、２０単位以上のボーラス体積
は、「通常ボーラス」比率よりゆっくり送達されてもよく、これは、例えば、組織中への
吸収の目的のために、ユーザによって所望され得る。しかしながら、いずれの場合も、典
型的には、ボーラス事象は、短い時間周期にわたって、例えば、いくつかの実施形態では
、１０分以下で送達される。

さらに、当技術分野で公知のように、拡張ボーラス注入事象は、所定の時間周期（例え
ば、３時間）にわたって、所定の間隔（例えば、３分ごと）での少量の注入可能流体の反
復注入において送達される所定の流体体積を指し得る。いくつかの拡張ボーラス注入事象
は、通常ボーラスとして送達される注入可能流体の所定の体積（すなわち、通常ボーラス
として送達される拡張ボーラス体積の合計のあるパーセンテージ）に続いて、拡張ボーラ
ス注入事象として（すなわち、所定の時間周期にわたって）送達される所定の体積の残り
の体積を含んでもよい。

拡張ボーラス注入事象は、基礎注入事象と同時に発生してもよい。種々の実施形態では
、種々のタイプの注入事象の送達の同時制御は、２０１０年７月１５日出願の米国特許出
願第１２／８３７，１９号「Ａｐｐａｒａｔｕｓ， Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈ
ｏｄｓ ｆｏｒ Ａｎ Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ Ａｓｓｅｍｂｌｙ」（２０１１年
６月１６日公開の現米国特許公報第ＵＳ−２０１１−０１４４５７４号）（弁理士整理番
号Ｉ２３）（参照することによって、全体として本明細書に組み込まれる）に説明される
ようなものであってもよい。

本明細書に図示および説明される注入ポンプの種々の実施形態、ならびにまた注入ポン
プの種々の実施形態は、制限されないが、２００９年３月３日発行の米国特許第７，４９
８，５６３号「Ｏｐｔｉｃａｌ Ｄｉｓｐｌａｃｅｍｅｎｔ Ｓｅｎｓｏｒ ｆｏｒ Ｉ
ｎｆｕｓｉｏｎ Ｄｅｖｉｃｅｓ（弁理士整理番号Ｄ７８）；２００７年１２月１１日発
行の米国特許第７，３０６，５７８号「Ｌｏａｄｉｎｇ Ｍｅｃｈａｎｉｓｍ ｆｏｒ
Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ」（弁理士整理番号Ｃ５４）；２００９年１０月９日出願の
ＰＣＴ出願第ＰＣＴ／ＵＳ２００９／０６０１５８号「Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ Ａ
ｓｓｅｍｂｌｙ」（２０１０年４月１５日公開の現公報第ＷＯ２０１０／０４２８１４号
）（弁理士整理番号Ｆ５１ＷＯ）；２０１１年３月３０日出願の米国特許出願第１３／０
７６，０６７号「Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ Ｍｅｔｈｏｄｓ， Ｓｙｓｔｅｍｓ ａ
ｎｄ Ａｐｐａｒａｔｕｓ」（２０１１年９月２２公開の現米国特許公報第ＵＳ−２０１
１−０２３０８３７）（弁理士整理番号Ｉ７０）；２０１１年３月３０日出願の米国特許
出願第１３／１２１，８２２号「Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ Ａｓｓｅｍｂｌｙ」、（
２０１１年８月２５日公開の現米国特許公報第ＵＳ−２０１１−０２０８１２３号）（弁
理士整理番号Ｉ７３）；２００７年２月９日出願の米国特許出願第１１／７０４，８９９
号「Ｆｌｕｉｄ Ｄｅｌｉｖｅｒｙ Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ」（２０
０７年１０月４日公開の現米国特許公報第ＵＳ−２００７−０２２８０７１−Ａ１号）（
弁理士整理番号Ｅ７０）；２００８年１２月３１日出願の米国特許出願第１２／３４７，
９８５号「Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ Ａｓｓｅｍｂｌｙ」（２００９年１２月３日公
開の現米国特許公報第ＵＳ−２００９−０２９９２７７−Ａ１号）（弁理士整理番号Ｇ７
５）；２００９年９月１５日出願の米国特許出願第１２／５６０，１０６号「Ｓｙｓｔｅ
ｍｓ ａｎｄ Ｍｅｔｈｏｄｓ ｆｏｒ Ｆｌｕｉｄ Ｄｅｌｉｖｅｒｙ」（２０１０年
７月２２日公開の現米国特許公報第ＵＳ−２０１０−０１８５１４２−Ａ１号）（弁理士
整理番号Ｇ４７）；２０１０年７月１５日出願の米国特許出願第１２／８３７，１９３号
「Ａｐｐａｒａｔｕｓ， Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ ｆｏｒ Ａｎ Ｉ
ｎｆｕｓｉｏｎ Ｐｕｍｐ Ａｓｓｅｍｂｌｙ」（２０１１年６月１６日公開の現米国特
許公報第ＵＳ−２０１１−０１４４５７４号）（弁理士整理番号Ｉ２３）；および２０１
１年１月２１日出願の米国特許出願第１３／０１１，３８４号「Ｍｅｔｈｏｄ ａｎｄ
Ｓｙｓｔｅｍ ｆｏｒ Ｓｈａｐｅ−Ｍｅｍｏｒｙ Ａｌｌｏｙ Ｗｉｒｅ Ｃｏｎｔｒ
ｏｌ」（２０１１年１２月８日公開の現米国特許公報第ＵＳ−２０１１−０３００００１
号）（弁理士整理番号Ｉ４８）（全て、参照することによって、その全体として本明細書
に組み込まれる）のうちの１つ以上に類似する、またはそこに説明される、それらの装置
、方法、デバイスおよびシステムを含んでもよく、ならびに種々のデバイスの種々の実施
形態では、遠隔インターフェースが、使用されてもよい。いくつかの実施形態では、遠隔
インターフェースは、専用デバイスまたは非専用デバイスであってもよく、図６−８に関
して前述のものを含んでもよい。しかしながら、いくつかの実施形態では、遠隔インター
フェースは、制限ではないが、Ｍｏｔｏｒｏｌａ， Ｉｎｃ．（Ｓｃｈａｕｍｂｕｒｇ，
Ｉｌｌｉｎｏｉｓ， Ｕ．Ｓ．Ａ．）によるＤＲＯＩＤ ＲＡＺＥＲ；ＨＴＣ（Ｔａｏ
ｙｕａｎ ３３０， Ｔａｉｗａｎ）による、ＨＴＣ ＧＯＯＧＬＥ Ｎｅｘｕｓ ｏｎ
ｅ；ＳＡＭＳＵＮＧ ＣｏｒｐｏｒａｔｉｏｎによるＳＡＭＳＵＮＧ Ｎｅｘｕｓ Ｓ；
およびＣＡＳＩＯ ＣＯＭＰＵＴＥＲ ＣＯ．， ＬＴＤ．（東京、日本）によるＣＡＳ
ＩＯ Ｇ’ｚＯｎｅ Ｃｏｍｍａｎｄｏを含み得る、オープンソースオペレーティングシ
ステム、例えば、ＡＮＤＲＯＩＤ（登録商標）オペレーティングシステムを使用して実行
され得る、多機能ウェブ接続／ウェブ対応デバイス、例えば、ＧＯＯＧＬＥ ＡＮＤＲＯ
ＩＤ（登録商標）タイプデバイスまたは任意の他のデバイスであってもよい。いくつかの
実施形態では、遠隔インターフェースは、タブレットまたは他のパーソナルコンピューテ
ィングデバイスであってもよく、および／またはいくつかの実施形態では、遠隔インター
フェースは、任意のいわゆる「スマートフォン」タイプのデバイスであってもよい。した
がって、種々の実施形態では、遠隔インターフェースは、ＧＰＳ、加速度計、電話、ウェ
ブ接続、カメラ、電子メール等を含むが、それらに制限されない、周辺機器を含んでもよ
い。

次に、また、図１８および図１９を参照すると、いくつかの実施形態では、遠隔インタ
ーフェース１８００、１９００は、制限されないが、ウェブベースのセキュアなポータル
を通して、および／または電子メールを通して、および／または無線通信プロトコルを介
してを含む、制限ではないが、アプリケーションをダウンロードする、ソフトウェアアッ
プデートをダウンロードする、情報をアップロードする、および／または情報を種々の機
械に送信する能力を含み得る、ウェブ接続された遠隔インターフェースの能力であっても
よい、あるいはそれを有してもよい。したがって、種々の実施形態では、遠隔インターフ
ェースアプリケーションは、任意の対応デバイス上で実行されてもよく、いわゆる専用デ
バイスに制限されない。さらに、いくつかの実施形態では、遠隔インターフェースは、例
えば、無線周波数（「ＲＦ」）通信を使用して、制限ではないが、注入ポンプ１８０２、
１９０２および／または持続的グルコースモニタ送信機／センサ１８０４、１９０４（「
ＣＧＭ」）および／またはＢＬＵＥＴＯＯＴＨ（登録商標）または他の通信プロトコル対
応血中グルコースメータ１８０６、１９０６および／または任意の他の医療デバイスおよ
び／または患者ケアデバイスあるいは任意の他のデバイスの１つ以上を含み得る、１つ以
上のデバイスと通信するために、ＢＬＵＥＴＯＯＴＨ（登録商標）対応またはその他に対
応するものであってもよい。

図１８−１９は、パーソナルコンピュータ１８０８、１９０８、注入ポンプ１８０２、
１９０２、血中グルコースメータ１８０６、１９０６および／またはＣＧＭ１８０４、１
９０４と通信する、遠隔インターフェース１８００、１９００を図示するが、種々の実施
形態では、遠隔インターフェース１８００、１９００は、パーソナルコンピュータ１８０
８、１９０８（いくつかの実施形態では、ウェブポータルであってもよい）、注入ポンプ
１８０２、１９０２、血中グルコースメータ１８０６、１９０６および／またはＣＧＭ１
８０４、１９０４、および／または制限されないが、医療デバイスを含む、任意の他のデ
バイスのうちの任意の１つ以上のいずれか１つのうちの１つ以上と通信してもよい。さら
に、いくつかの実施形態では、パーソナルコンピュータ１８０８、１９０８（いくつかの
実施形態では、ウェブポータルであってもよい）、注入ポンプ１８０２、１９０２、血中
グルコースメータ１８０６、１９０６および／またはＣＧＭ１８０４、１９０４のうちの
１つ以上はまた、遠隔インターフェース１８００、１９００との通信に加え、パーソナル
コンピュータ１８０８、１９０８（いくつかの実施形態では、ウェブポータルであっても
よい）、注入ポンプ１８０２、１９０２、血中グルコースメータ１８０６、１９０６およ
び／またはＣＧＭ１８０４、１９０４のうちの１つ以上と通信してもよい。いくつかの実
施形態では、遠隔インターフェース１８００、１９００は、本明細書に説明されない１つ
以上のデバイスと通信してもよいが、しかしながら、遠隔インターフェース１８００、１
９００は、任意のデバイスと通信してもよいことを理解されたい。さらに、通信は、一方
向および／または双方向通信として定義されてもよい。いくつかの実施形態では、ウェブ
ポータルは、セキュアなウェブポータルであってもよい。

いくつかの実施形態では、遠隔インターフェースデバイス１８００、１９００は、デー
タをセキュアなウェブページ／ウェブポータル／パーソナルコンピュータ１８０８、１９
０９と共有してもよい。本共有されるデータは、いくつかの実施形態では、所定のおよび
／または事前にプログラムされた間隔において、自動的に、転送されてもよい１８１０、
１９１０（すなわち、同期される）。いくつかの実施形態では、遠隔インターフェース１
８００、１９００からのデータは、いくつかの実施形態では、情報が共有されないことを
確実にする、パスワードで保護されたアプリケーションによって、セキュアなウェブペー
ジ／ウェブポータル／パーソナルコンピュータ１８０８、１９０８にアップロードされる
。いくつかの実施形態では、遠隔インターフェース１８００、１９００からの情報は、セ
キュア化されたウェブページ上に記憶されてもよく、したがって、情報は、要求に応じて
、代用遠隔インターフェースおよび／または第２の遠隔インターフェースおよび／または
他のデバイスにダウンロードされてもよい。したがって、いくつかの実施形態では、本シ
ステムは、遠隔インターフェース１８０８、１９０８が、故障および／または紛失に応じ
て、容易に交換されることを可能にする。上記で議論されるように、いくつかの実施形態
では、セキュアなウェブページおよび／またはデータの転送は、パスワードまたは他のタ
イプのセキュリティによって、セキュア化される。

さらに、セキュアなウェブポータル／パーソナルコンピュータ１８０８、１９０８は、
ユーザによって、注入ポンプ療法、ＣＧＭデータおよび／またはグルコースメータデータ
（ならびに、いくつかの実施形態では、同一の場所において、遠隔インターフェース１８
００、１９００および／またはセキュアなウェブページ／パーソナルコンピュータ１８０
８、１９０８のいずれかに接続された付加的デバイス）を検討するために利用されてもよ
い。さらに、セキュアなウェブページ／パーソナルコンピュータ１８０８、１９０８は、
食品ライブラリ、および／またはユーザによって、例えば、パーソナルコンピュータ上で
カスタマイズされ、次いで、いくつかの実施形態では、自動的に、遠隔インターフェース
１８００、１９００と同期される、ユーザカスタマイズ可能療法を含んでもよい。いくつ
かの実施形態では、ユーザは、ＣＧＭおよび／または注入ポンプおよび／または他のデー
タを編集および／または事象と「タグ付け」してもよい。これらの編集は、リアルタイム
で、すなわち、事象が生じている間、または後で入力されてもよい。これらの事象は、い
くつかの実施形態では、次いで、ユーザによって「命名」されてもよく、いくつかの実施
形態では、療法計画が、ユーザによって、これらの事象のそれぞれに対して、事前にプロ
グラムされてもよい。例えば、ユーザが、ピザを食している場合、ユーザは、与えられた
療法と摂取されている食品を関連付けてもよく、制限ではないが、スライスの数およびス
ライスの原料の表示、例えば、「Ｓａｌ’ｓ Ｐｉｚｚａ、チーズ、２切れ」を含んでも
よい。したがって、ユーザは、これを遠隔インターフェース１８００、１９００に入力し
てもよく、いくつかの実施形態では、後で、ＣＧＭおよび／またはポンプおよび／または
グルコースメータデータを検討しながら、ユーザは、「Ｓａｌ’ｓ Ｐｉｚｚａ、チーズ
、２切れ」を食しているときに使用されるべき療法を設計してもよい。ユーザは、本事象
を命名してもよく、療法が、本名称と関連付けられてもよい。したがって、ユーザは、「
Ｓａｌ’ｓＰｉｚｚａ、チーズ、２切れ」事象を随時選択し、遠隔インターフェース１８
００、１９００が、ピザと関連付けられた保存された療法を施行することを承認してもよ
い。いくつかの実施形態では、事象は、食品ライブラリにリンクされてもよく、したがっ
て、ユーザは、食品ライブラリからのアイテムを含むにつれて、遠隔インターフェース１
８００、１９００は食品アイテムと療法および／またはＣＧＭおよび／または血中グルコ
ースメータデータを「リンク」させてもよい。上記で議論されるように、ソフトウェアお
よび／またはプロファイルへの変更は、パーソナルコンピュータ（および／またはセキュ
アなウェブページ）１８０８、１９０８を使用して、ユーザによって行なわれてもよく、
これらの変更は、遠隔インターフェース１８００、１９００上にアップロードされてもよ
い。これらの変更が、パーソナルコンピュータ（および／またはセキュアなウェブページ
）１８０８、１９０８から遠隔インターフェース１８００、１９００にアップロードされ
ると、次いで、制限されないが、注入ポンプ１８０２、１９０２を含む、遠隔インターフ
ェース１８００、１９００に接続された他のデバイス上にダウンロードされてもよい。

いくつかの実施形態では、ウェブページではなく、遠隔インターフェース１８００、１
９００上に、例えば、食品ライブラリ、および／または、直接、遠隔インターフェースデ
バイス上で行なわれ得る、ユーザカスタマイズ可能療法推奨に関して上記で議論されるよ
うな類似機能性を含む、専用アプリケーションが存在してもよい。これらの実施形態のう
ちのいくつかでは、専用アプリケーションは、例えば、いくつかの実施形態では、セキュ
アなウェブデータベースであり得る、ウェブデータベースから情報をダウンロードするこ
とによって、遠隔インターフェース１８００、１９００にアップデートされてもよい。

したがって、ユーザは、事後事象分析および設計を行い、および／または分析に基づい
て、療法に変更を行ってもよい。いくつかの実施形態では、ユーザは、本情報を使用して
、傾向を調べ、基礎および／またはボーラスプロファイルを修正してもよい。いくつかの
実施形態では、分析は、セキュアなウェブページ１８０８、１９０８を用いて、あるいは
それを通して、医師および／または介護者によって、完了されてもよい。いくつかの実施
形態では、ユーザは、具体的事象および／または摂取食品に対して、データベースを「フ
ィルタリング」し、その介護者とともに、または単独で、それらを分析し、基礎および／
またはボーラスプロファイルを判定し、具体的事象および／または食品アイテムとリンク
させてもよい。したがって、いくつかの実施形態では、ユーザは、遠隔インターフェース
１８００、１９００（または、セキュアなウェブページ１８０８、１９０８）を使用して
、例えば、「Ｓａｌ’ｓ Ｐｉｚｚａ、チーズ、２切れ」の全事象をフィルタリングし、
療法、事象の時間ならびにその事象に対するＣＧＭプロファイルおよび／または血液メー
タ示度値の両方を分析してもよい。

いくつかの実施形態では、遠隔インターフェース１８００、１９００は、収集されたＣ
ＧＭおよび／またはポンプおよび／またはグルコースメータデータと、ユーザによって入
力された情報の両方から、ユーザ習慣を学習してもよい。アプリケーションおよび／また
はソフトウェアは、療法変更を推奨してもよく、それらの推奨は、ユーザによって承諾ま
たは拒否されてもよい。

いくつかの実施形態では、ＣＧＭおよび／または注入ポンプおよび／または血中グルコ
ースメータデータおよび／または事象データは、ユーザとユーザの医師および／または医
療提供者との間で設定されたセキュアなウェブポータル１８０８、１９０８に配信されて
もよい。いくつかの実施形態では、ユーザの医師および／または医療提供者によって使用
されるセキュアなウェブポータルは、ユーザのセキュアなウェブポータルと別個であって
もよい。したがって、いくつかの実施形態では、ポータルは、ユーザが、ユーザの医師お
よび／または医療提供者によってアクセスされるセキュアなウェブポータル１８０８、１
９０８からダウンロードされ、および／または遠隔インターフェース１８００、１９００
と同期されるのに先立って、推奨された変更等を承諾または拒否のいずれかを行なうこと
を要求してもよい。

いくつかの実施形態では、ＣＧＭセンサ１８０４、１９０４は、直接、注入ポンプ１８
０２、１９０２および／または遠隔インターフェース１８００、１９００と通信してもよ
い（図１８および１９参照）。いくつかの実施形態では、ＣＧＭセンサ１８０４、１９０
４は、一方または他方と通信してもよく、いくつかの実施形態では、ＣＧＭセンサ１８０
４、１９０４は、注入ポンプ１８０２、１９０２および遠隔インターフェース１８００、
１９００の両方と通信してもよい。いくつかの実施形態では、安全臨界情報、例えば、ア
ラームが、直接、注入ポンプ１８０２、１９０２に通信されてもよく、遠隔インターフェ
ース１８００、１９００は、単に、ディスプレイとして使用されてもよい。

次に、また、図７を参照すると、いくつかの実施形態では、遠隔インターフェース１８
００、１９００は、いくつかの実施形態では、ユーザによってカスタマイズ可能であり得
る、少なくとも１つの加速度計ならびに複数のボタン７０６、７１０を含有する少なくと
も１つの画面を含んでもよい。ボタン７０６、７１０は、いくつかの実施形態では、例え
ば、制限されないが、事象に関する情報を入力し、および／または単に、遠隔インターフ
ェース５２４に、事象が生じていることを示すために、直接、特定の画面にナビゲートす
るために使用されてもよい。いくつかの実施形態では、本情報は、記憶され、療法／注入
ポンプ情報および／またはＣＧＭおよび／または血中グルコースメータ情報と同期する能
力を含み得る、セキュアなウェブページおよび／またはその他に送信されてもよい。

いくつかの実施形態では、情報は、安全性監視サービスのための遠隔インターフェース
１８００、１９００に送信されてもよい。サービスは、監視を行い、データが、問題が存
在し得ることを示す、例えば、低血液グルコースが示されるとき、および／または注入ポ
ンプ警告／アラームおよび／またはＣＧＭ警告／アラームが確認されていない、例えば、
アラーム／警告が、制限ではないが、アラーム／警告の受信を肯定応答するためのボタン
押下および／または画面タッチを含み得る、ユーザによって肯定応答／承認がされていな
いとき、電話をかける、および／または遠隔インターフェース１８００、１９００にテキ
スト（例えば、「大丈夫ですか？」）を送ってもよい。例えば、いくつかの実施形態では
、ユーザが、サービスコールおよび／またはテキストに応答しない場合、サービスは、次
いで、救急サービスおよび／または両親または保護者および／または緊急連絡先に電話を
かけてもよい。いくつかの実施形態では、遠隔インターフェース１８００、１９００内の
ＧＰＳが、ユーザを測位してもよく、したがって、救急隊員に委託され、ユーザの場所に
派遣されてもよい。いくつかの実施形態では、サービスが、両親または救急隊員または緊
急連絡先と連絡がとれた場合、サービスはまた、現在のＣＧＭおよび／またはポンプデー
タを検討のために送信してもよい。

上記で議論されるように、いくつかの実施形態では、遠隔インターフェース１８００、
１９００は、ウェブ対応であってもよく（および／または遠隔インターフェース１８００
、１９００上にダウンロードされる、または遠隔インターフェース１８００、１９００に
よってアクセスされるかのいずれかであり得る、データベースへのアクセスを有する）、
いくつかの実施形態では、ユーザは、遠隔インターフェース１８００、１９００を使用し
て、メニューおよび／または栄養情報に容易にアクセスしてもよい。いくつかの実施形態
では、本情報は、ボーラス計算機および／またはその他に「自動入力」され、炭水化物、
脂肪含量等を計算し、適切な療法の判定を支援してもよい。いくつかの実施形態では、実
際の計算は、デバイス（いくつかの実施形態では、注入ポンプ１８０２、１９０２であっ
てもよい）上で行なわれてもよいが、遠隔インターフェース１８００、１９００が、ユー
ザが情報を入力するためのユーザインターフェースであってもよい。

いくつかの実施形態では、遠隔インターフェース１８００、１９００、セキュアなウェ
ブページ１８０８、１９０８および注入ポンプ１８０２、１９０２は、いくつかの実施形
態では、１２８ビット暗号化を用いて、暗号化されてもよい。しかしながら、他の実施形
態では、暗号化は、異なってもよい。

いくつかの実施形態では、遠隔インターフェース１８００、１９００は、一連の音声表
示、すなわち、音を通して、注入ポンプ１８０２、１９０２および／またはＣＧＭセンサ
１８０２、１９０２ ５３２および／または血中グルコースメータ１８０６、１９０６を
含み得る、デバイスとペアリングしてもよい。音は、各遠隔インターフェース１８００、
１９００に個別化される、および／または一意であってもよく、これは、遠隔インターフ
ェース１８００、１９００をユーザのデバイスにペアリングする際の安全性を増加させ得
る。いくつかの実施形態では、ペアリングは、ＮＦＣ（近距離通信）を使用して、すなわ
ち、デバイスおよび遠隔インターフェース１８００、１９００を近距離内で十分に近接し
て保持し、その２つが通信およびペアリングし得る、すなわち、通信可能となることによ
って達成されてもよい。

いくつかの実施形態では、遠隔インターフェースディスプレイ／画面は、ユーザに、予
定された送達軌跡とともに、送達された実際の体積を示してもよい。これは、注入ポンプ
によって送達される流体の量に対するユーザ認識を増加させ、したがって、ユーザが、よ
り知識に基づいた療法決定を行なうことを可能にし得る。さらに、送達された実際の体積
は、医療介護提供者が、基礎レベル、インスリンと炭水化物の比等を微調整または遂行す
るのに有用となり得る。

いくつかの実施形態では、遠隔インターフェースは、医療デバイスではなく、通常のデ
バイスであるように見えるため、遠隔インターフェースは、療法を変更するために要求さ
れる、パスワード保護を含んでもよい。例えば、「療法画面」（この用語は、制限されな
いが、インスリン／薬物感度、炭水化物と薬物の比、薬物の持続時間、基礎プロファイル
、ボーラス要求、食品ライブラリ情報、血液グルコース画面等を含む、療法への任意の変
更を行うことが可能な任意の画面を指すために使用され得る）を開くために、ユーザは、
いくつかの実施形態では、パスワードを入力することが要求されてもよい。いくつかの実
施形態では、指紋またはその他が、使用されてもよい。いくつかの実施形態では、「タッ
プコード」、すなわち、ある間隔において遠隔インターフェースに印加される力が、使用
されてもよい（例えば、遠隔インターフェース１８００、１９００が、少なくとも１つの
加速度計を含み得る実施形態では、具体的コードにおけるデバイスのタップは、情報を伝
達し得る。いくつかの実施形態では、少なくとも１つの加速度計を有する遠隔インターフ
ェース１８００、１９００に加えて、またはその代わりに、注入ポンプ１８０２、１９０
０２が、少なくとも１つの加速度計を含んでもよい）。

遠隔インターフェースが、ウェブ対応および／またはＢＬＵＥＴＯＯＴＨ（登録商標）
対応である、いくつかの実施形態では、１つ以上のデバイス（例えば、ＣＧＭセンサ／送
信機１８０４、１９０４、注入ポンプ１８０２、１９０２、血中グルコースメータ１８０
６、１９０６）が、問題を被る場合、ユーザは、直接、その特定のデバイスに関するエン
ジニアリングログを製造業者に送信してもよい。これは、ユーザが問題を被っているデバ
イスを製造業者に郵送する必要性をなくし得るため、望ましくあり得る。製造業者は、受
信に応じて、製造業者が問題の原因を判定すると、アラームまたはその他を止めるための
コードまたはその他をユーザに推奨してもよい。いくつかの実施形態では、遠隔インター
フェースは、医療情報ではなく、エンジニアリングログのみを製造業者に送信するように
事前にプログラムされたプロトコルを含んでもよい。これは、ユーザが、そのセキュアな
医療情報を製造業者に非意図的に送信しないように確実にし得る。したがって、遠隔イン
ターフェース１８００、１９００は、いくつかの実施形態では、遠隔インターフェース１
８００、１９００に接続されたデバイスの全てに関するログおよび／または情報を含む。
したがって、デバイスの交換は、デバイスが、ユーザによって、最小「設定」時間を伴っ
て使用され得るように、かつ代用デバイスが、交換された古いデバイス通り機能し得る／
構成され得るように、遠隔インターフェース１８００、１９００から、ログ、ユーザプロ
ファイル、ユーザ選好等をダウンロードすることによって達成されてもよい。

いくつかの実施形態では、画面、例えば、「スクリーンショット」を、遠隔インターフ
ェース１８００、１９００から、サービス担当者および／または製造業者に送信すること
が望ましくあり得る、すなわち、サービス担当者は、例えば、ウェブチャットおよび／ま
たは電話のいずれかを介して、デバイスに関する任意の問題について議論しながら、画面
を確認可能であってもよい。

いくつかの実施形態では、製造業者は、遠隔インターフェース１８００、１９００に、
デバイスの補正に関する指示のための「ビデオ」またはウェブサイトへのリンクを送信し
てもよい。いくつかの実施形態では、「ビデオ」または他の動画は、遠隔インターフェー
ス１８００、１９００自体で利用可能であってもよく、これは、制限ではないが、デバイ
ス１８０２、１９０２、１８０４、１９０４、１８０６、１９０６および／またはデバイ
スの遠隔インターフェース１８００、１９００に関するアラームおよび／または他の作用
に応対するユーザおよび／または介護者に、示す／説明するおよび／または「段階的に説
明」するためのビデオまたは動画を含み得る（例えば、いくつかの実施形態の図２９Ａ−
２９Ｆ参照）。

さらに、いくつかの実施形態では、遠隔インターフェース１８００、１９００は、制限
ではないが、医療情報を含み得る、セキュアな情報を送信するための承認されたアドレス
のリストをコンパイルする能力を含んでもよい。したがって、ユーザが、正しくない電子
メールアドレスまたはウェブアドレス等を非意図的に入力する場合、遠隔インターフェー
ス１８００、１９００は、ユーザが、例えば、承認されたアドレスリスト上の新しいアド
レスの入力を含み得る、さらなるステップを伴わずに、セキュアな情報を送信可能となら
ないように防止してもよい。いくつかの実施形態では、リストの改変は、パスワードまた
はその他（タップ、指紋等）で保護されてもよい。

いくつかの実施形態では、制限ではないが、現在のグルコース示度値を含み得る、デバ
イス（すなわち、ＣＧＭセンサ／送信機１８０４、１９０４および／または注入ポンプ１
８０２、１９０２および／または血中グルコースメータ１８０６、１９０６）のうちの１
つ以上の状態は、遠隔インターフェース１８００、１９００に接続されたイヤホンおよび
／または遠隔インターフェース１８００、１９００上のスピーカを通した音声音を通して
示されてもよい。

いくつかの実施形態では、デバイス１８０２、１９０２、１８０４、１９０４、１８０
６、１９０６は、デバイスのうちの１つ以上の近接性を示すための無線信号、いわゆる「
雷鳴と閃光」と連結される、音響信号を使用して、遠隔インターフェース１８００、１９
００と通信してもよい。いくつかの実施形態では、メッセージは、第１のデバイスによっ
て、無線信号を使用して、第２のデバイスに送信されてもよい。本無線信号は、同時に、
超音波「チャープ」と連結されてもよい。これは、デバイス間の距離を判定および／また
は計算するために使用されてもよい。本方法は、例えば、遠隔インターフェース１８００
、１９００によって送信されるメッセージおよび／またはそれによって行なわれる要求が
、デバイスから適切な距離にあることを確実にするために使用されてもよく、これは、デ
バイスの遠隔インターフェース１８００、１９００のユーザが、メッセージを送信してい
るかどうかを示し得る、あるいは別の（すなわち、非ユーザ）遠隔インターフェースおよ
び／またはデバイスが、メッセージを送信しているかどうかを示し得る。これは、遠隔イ
ンターフェース１８００、１９００によって、デバイスのうちの１つ以上の通信および制
御の安全性を確実にするために使用されてもよい。例えば、ユーザが、信号／通信をその
遠隔インターフェース１８００、１９００からその注入ポンプ１８０２、１９０２に送信
している場合、これは、遠隔インターフェース１８００、１９００が、注入ポンプ１８０
２、１９０２から特定の距離、例えば、４フィートを上回る可能性はないため、ユーザが
、注入ポンプ１８０２、１９０２を装着していることを確実にし得る。したがって、シス
テムが、前述の説明される方法を使用して、遠隔インターフェース１８００、１９００が
、注入ポンプ１８０２、１９０２から閾値（いくつかの実施形態では、製造業者および／
またはユーザのいずれかによって、事前決定および／または事前設定されてもよく、閾値
は、いくつかの実施形態では、例えば、ユーザ独自の測定値および／または管類の長さに
基づいてもよい）距離を上回ると判定および／または計算する場合、遠隔インターフェー
ス１８００、１９００は、ユーザに警告／アラームおよび／または通知してもよい。いく
つかの実施形態では、アラーム／警告はまた、未確認デバイスが注入ポンプ１８０２、１
９０２と通信を試みていることを記すメッセージを含んでもよい。したがって、これは、
遠隔インターフェース１８００、１９００が、受信されている通信および／またはシステ
ム内のデバイスに伝送されている通信が、「承認されたデバイス」、すなわち、ユーザが
システム内に組み込んだ、すなわち、遠隔インターフェース１８００、１９００にペアリ
ングされた、デバイスおよび／または遠隔インターフェース１８００、１９００とペアリ
ングされ得る別のデバイスにペアリングされたデバイスによるものであるかどうかを判定
する方法の１つであり得る。

いくつかの実施形態では、承認されていないデバイスと承認されたデバイスとの間の通
信を管理する方法は、以下のようであってもよい。遠隔インターフェース１８００、１９
００が、メッセージを送信するとき、デバイスと遠隔インターフェース１８００、１９０
０との間に、無線および応答の既知の遅延が存在する。例えば、デバイス１８０２、１９
０２、１８０４、１９０４、１８０６、１９０６が、メッセージを受信してから、メッセ
ージを送信するまでの時間の間の遅延が、測定され、往復時間を判定し得る。これは、遠
隔インターフェース１８００、１９００とデバイス１８０２、１９０２、１８０４、１９
０４、１８０６、１９０６との間の距離を判定するために使用されてもよい。測定された
距離が、距離が事前にプログラムされた閾値を上回ることを示す場合、遠隔インターフェ
ース１８００、１９００は、いくつかの実施形態では、例えば、ユーザに警告および／ま
たはアラームしてもよい。

いくつかの実施形態では、遠隔インターフェース１８００、１９００からウェブポータ
ル／パーソナルコンピュータ１８０８、１９０９にアップロードされた情報はまた、電子
カレンダ、例えば、制限されないが、ＯＵＴＬＯＯＫカレンダまたはその他と同期されて
もよい。したがって、ユーザの生活における事象が、システムに接続されたデバイス１８
０２、１９０２、１８０４、１９０４、１８０６、１９０６のデータにリンクされてもよ
い。これは、生じた事象を示し、分析のために、データに関連性および広がりをもたらす
ために望ましくあり得る。また、ユーザが、遠隔インターフェース１８００、１９００に
事象を入力していない場合があっても、事象が、電子カレンダ上にある場合、事象が、検
討および分析のために、自動的に、データとともに入力されてもよい。例えば、ユーザの
カレンダが、「サッカーの練習」を示し得るが、サッカーの練習の間、ユーザが、遠隔イ
ンターフェース１８００、１９００上に事象を示していなかった場合、遠隔インターフェ
ース１８００、１９００からウェブポータル／パーソナルコンピュータ１８０８、１９０
８へのデータのアップロードに応じて、遠隔インターフェース１８００、１９００からの
データは、例えば、送達された流体の量（基礎比率であってもよい）および血液グルコー
スデータ、例えば、ＣＧＭセンサ／送信機１８０４、１９０４からのデータおよび／また
は血中グルコースメータ１８０６、１９０６からのデータを表すエリアの上方に、例えば
、デバイスからの情報およびデータを容易に閲覧するように設計されたソフトウェアプロ
グラムに、事象「サッカーの練習」を組み込んでもよい。したがって、ユーザは、一代表
的グラフでは、例えば、薬物送達データ、ＣＧＭ、および血液グルコースデータとともに
、ユーザがその時間に行なっていたことの表示を閲覧してもよい。

したがって、ユーザは、遠隔インターフェース１８００、１９００をパーソナルコンピ
ュータ１８０８、１９０８に接続し、および／または、いくつかの実施形態では、データ
を遠隔インターフェース１８００、１９００からウェブポータルまたはその他にアップロ
ードしてもよい。いくつかの実施形態では、これは、遠隔インターフェース１８００、１
９００の「再充電」の間、達成されてもよく、これは、いくつかの実施形態では、パーソ
ナルコンピュータ１８０８、１９０８へのＵＳＢ接続を使用して行なわれてもよく、充電
／再充電に加えて、遠隔インターフェース１８００、１９００は、データを同期および／
またはパーソナルコンピュータ１８０８、１９０８および／またはウェブポータルからア
ップロード／ダウンロードし得る。本時点において、システムは、デバイスのうちの１つ
以上および／または遠隔インターフェース１８００、１９００のためのソフトウェアアッ
プデートが利用可能であることを判定してもよい。ユーザは、「アップデートをダウンロ
ードする」を選択してもよく、これらは、再び、充電のとき、および／または遠隔インタ
ーフェース１８００、１９００が、直接または間接的にのいずれかにおいて、パーソナル
コンピュータ１８０８、１９０８および／またはシステム専用に設計されたウェブポータ
ルに接続される任意の時間に、遠隔インターフェース１８００、１９００にダウンロード
されてもよい。上記で議論されるように、遠隔インターフェース１８００、１９００は、
種々のデバイスと通信可能である。したがって、ソフトウェアアップデートは、遠隔イン
ターフェース１８００、１９００によって、任意の１つ以上のデバイスに通信されてもよ
い。これは、制限されないが、データ／情報をデバイスの全てからアップロードし、およ
び／またはアップデートおよび／またはアプリケーションをパーソナルコンピュータおよ
び／またはインターネット／ウェブポータルからデバイスのいずれかにダウンロードする
両方のために、遠隔インターフェース１８００、１９００をパーソナルコンピュータ／ウ
ェブポータル１８０８、１９０８に接続する必要のみあることを含む、多くの利点を有す
る。これは、１つの接続から全デバイスを効率的かつ容易にアップデートする能力、およ
び／または１つの場所において、全デバイスからのデータの全てを閲覧する能力、および
／または遠隔インターフェースを通して、情報および／または設定をパーソナルコンピュ
ータ／ウェブポータルからデバイスのいずれかにダウンロードする能力を含むが、それら
に制限されない、多くの理由から、望ましくあり得る。

したがって、いくつかの実施形態では、パーソナルコンピュータ／ウェブポータルは、
随時、制限されないが、遠隔インターフェースを含む、全デバイスからの全情報を含有す
るため、新しい「遠隔インターフェース」が、システムに導入されてもよい。これは、新
しい遠隔インターフェースをパーソナルコンピュータ／ウェブポータルに接続し、システ
ムに関する全情報を遠隔インターフェースにダウンロードすることによって達成されても
よい。いくつかの実施形態では、これは、最初に、古い遠隔インターフェースが、「承認
されたデバイス」から除去されることを要求し得るが、しかしながら、他の実施形態では
、システムは、ユーザからの許可によって、付加的遠隔インターフェースを「許容」して
もよい。したがって、システムは、デバイスに通信可能であって、パーソナルコンピュー
タおよび／またはウェブポータルに接続可能である、任意のインターネット接続され、お
よび／または遠隔のインターフェースに、全情報およびアプリケーションをダウンロード
する能力を含む。

これはまた、遠隔インターフェースが、任意のアプリケーションをインターネットから
システム内の任意のデバイスにダウンロードすることを可能にする。したがって、システ
ムの種々の実施形態では、ユーザは、任意の装置（パーソナルコンピュータおよび／また
はウェブポータルに無線通信し、接続する能力等のいくつかのパラメータを含む）を種々
のデバイス、例えば、注入ポンプを制御し、および／またはデータをＣＧＭセンサ／送信
機、および／または他の検体センサ、および／または他のデバイスから受信し、および／
または制御し得る、デバイスにすることができる。いくつかの実施形態では、遠隔インタ
ーフェースおよび／または遠隔インターフェース上の１つ以上のアプリケーションは、パ
スワードまたはその他で保護されてもよく、１つ以上のデバイスとペアリングされる、例
えば、注入ポンプおよび／またはＣＧＭセンサおよび／または１つ以上の他のデバイスと
ペアリングされる。

いくつかの実施形態では、遠隔インターフェース上の情報は、アップロードされ、およ
び／または、制限されないが、パスワードで保護され得る、インターネットサイト（ウェ
ブポータル）へのデータのアップロードを含め、別のデバイスおよび／またはコンピュー
タおよび／または機械と同期されてもよい。したがって、ユーザは、任意のデバイスから
の情報にアクセスしてもよく、および／または任意のデバイス専用アプリケーションを含
む、情報を任意のデバイスにダウンロードしてもよく、したがって、ユーザ情報は、制限
されないが、履歴、好ましい設定等の情報を含め、任意のデバイスにダウンロードされて
もよい。

システムのいくつかの実施形態では、血中グルコースメータ１８０６、１９０６が、含
まれてもよく、これは、ユーザインターフェースではなく、細片リーダおよび機能するた
めの最小構成要素のみを含み得る。いくつかの実施形態では、血中グルコースメータ１８
０６、１９０６は、遠隔インターフェース１８００、１９００と通信し、遠隔インターフ
ェース１８００、１９００ディスプレイは、示度値を示し、および／またはいくつかの実
施形態では、遠隔インターフェース１８００、１９００は、制限ではないが、血中グルコ
ースメータ１８０６、１９０６示度値のグラフィカル表現および／または履歴データなら
びにユーザ選好等を含み得る、血中グルコースメータ１８０６、１９０６より広範囲の機
能を含む。

システムは、上記で議論されるように、注入ポンプシステムの例示的形態をとるが、種
々の実施形態では、デバイスは、任意の医療デバイスを含む、任意のデバイスであっても
よく、および／または示される図に表されるデバイスの数を上回るまたは下回ってもよい
。

上記で議論されるように、種々の実施形態では、遠隔インターフェース１８００、１９
００は、タブレットコンピュータまたは多機能ウェブ接続／ウェブ対応デバイスを含んで
もよく、例えば、いくつかの実施形態では、遠隔インターフェースは、ＤＲＯＩＤ ＲＡ
ＺＥＲであってもよい。いくつかの実施形態では、１つ以上の周辺機器は、遠隔インター
フェースが、システム内のデバイスのうちの１つ以上、例えば、医療デバイスと通信して
いる間、オフにされてもよく、および／または「スリープ」してもよい。いくつかの実施
形態では、アンテナおよび／または無線通信ソフトウェアは、例えば、前述のような、ま
たは参照することによって組み込まれる情報のいずれかにおける、専用バージョンに修正
されてもよい。いくつかの実施形態では、無線通信は、遠隔インターフェースデバイス自
体内にあるもの、例えば、ＢＬＵＥＴＯＯＴＨ（登録商標）低エネルギー無線通信プロト
コルであってもよい。いくつかの実施形態では、本通信プロトコルとともに、変換装置が
、システム内のデバイスのうちの１つ以上上の専用プロトコルに変化するために含まれて
もよい。いくつかの実施形態では、メッセージングは、本明細書で論じられるプロトコル
を通して、または類似プロトコルを通して、および／または遠隔インターフェースデバイ
スからのプロトコルを使用して、達成されてもよい。

遠隔インターフェースは、したがって、種々の実施形態では、カラータッチスクリーン
を含み得る、ディスプレイアセンブリを含む。いくつかの実施形態では、遠隔インターフ
ェースは、加えて、少なくとも１つのスイッチアセンブリを含む。いくつかの実施形態で
は、遠隔インターフェースは、１つ以上のデバイスのための動画化された「設定」指示を
含む。加えて、いくつかの実施形態では、遠隔インターフェースは、制限ではないが、ア
ラーム状態をチェックおよび／または確認し、および／またはそこから復元するためのユ
ーザへの指示を含み得る、アラーム復元および／またはアラーム動画を含む。これらの動
画は、制限ではないが、文書／文字指示および／または音声指示を含んでもよい。いくつ
かの実施形態では、グラフィカルユーザインターフェースは、異なる状態を表すための異
なる色背景、例えば、アラームのための「赤色」、アイドル状態のための「青色」、送達
／作用のための「緑色」等を提示してもよい。いくつかの実施形態では、前述の機能のう
ちの１つ以上は、加えて、制限ではないが、音声指示、ビープ音等を含み得る、音／音声
を含んでもよい。

次に、図２０Ａ−３０を参照すると、注入ポンプ、例えば、本明細書に説明される注入
ポンプの実施形態のうちの１つ用の遠隔インターフェースのためのグラフィカルユーザイ
ンターフェースのいくつかの実施形態としての役割を果たす、種々の「スクリーンショッ
ト」が、描写される。いくつかの実施形態では、血中グルコースメータ用の遠隔インター
フェースのためのスクリーンショットが、示される。いくつかの実施形態では、画面は、
指示インターフェースとして使用されてもよい。

次に、図２０Ａ−２２Ｈを参照すると、いくつかの実施形態では、遠隔インターフェー
スは、デバイスに関するある作用を行なうための方法をユーザに実証するための動画およ
び／または写真／グラフィカル指示を含んでもよい。いくつかの実施形態では、これらの
動画および／または写真／グラフィカル指示は、ナレーションおよび／または音声を含ん
でもよく、および／またはテキストならびに文書指示を含んでもよい。図２０Ａ−２２Ｈ
は、注入ポンプを設定するためのグラフィカルユーザインターフェース（ＧＵＩ）のいく
つかの実施形態および／または実施形態の実施例を含む。これらの実施例は、例証的スク
リーンショットとして示され、種々の実施形態は、示される文字および／または写真に限
定されない。また、スクリーンショットの順序は、実施形態全体を通して異なってもよい
。加えて、いくつかの実施形態では、種々のスクリーンショットは、以下のボタン：「戻
る（ｂａｃｋ）」、「中止（ｃａｎｃｅｌ）」、および／または「次へ（ｎｅｘｔ）」ボ
タンのうちの１つ以上を含んでもよい。これらの実施形態では、任意の画面上において、
ユーザは、戻る、画面を中止する、および／または次の画面に進むことを選択してもよい
。動画が含まれる、いくつかの実施形態では、動画は、ユーザが、ボタン、例えば、戻る
、中止、および／または次へを選択するまで、無限に再生してもよい。いくつかの実施形
態では、ボタンは、ハイライトされる、および／またはハイライト解除されてもよい（図
中に点線として表されてもよい）。

次に、図２０Ａ−２０Ｍを参照すると、使い捨て部分（リザーバとも称され得る）を充
填し、使い捨て部分に呼水を差すためのグラフィカル指示が、示される。図２０Ａを参照
すると、いくつかの実施形態は、ユーザに、その手を洗浄するように指示する、少なくと
も１つの画面を含む。いくつかの実施形態では、その手を洗浄するユーザを示す、少なく
とも１つの画面が含まれ、ユーザに、その手を石鹸およびお湯で洗浄するように指示して
もよい。いくつかの実施形態では、画面は、その手を石鹸および水で洗浄するユーザを示
す、動画を含んでもよい。図２０Ｂを参照すると、いくつかの実施形態は、ユーザに、使
い捨て部分のカバーおよび蓋を除去するように指示する、少なくとも１つの画面を含む。
いくつかの実施形態では、画面は、使い捨て部分を示してもよい。本実施形態では、画面
は、パッケージング内の使い捨て部分の実施形態を示し、ユーザに、カバーおよび蓋をパ
ッケージから除去するように指示する。いくつかの実施形態では、本実施形態は、動画で
あって、いくつかの実施形態では、グラフィカル動画は、パッケージから除去されている
カバーおよび蓋を示す。次に、図２０Ｃを参照すると、いくつかの実施形態は、パッケー
ジの基部が蓋に取り付けられる様子を示す、少なくとも１つのスクリーンショットを含む
。いくつかの実施形態では、本実施形態は、動画であって、いくつかの実施形態では、グ
ラフィカル動画は、蓋に取り付けられるパッケージの基部を示す。次に、図２０Ｄを参照
すると、いくつかの実施形態は、清浄される（注入可能流体の）バイアルを示す、少なく
とも１つの画面を含む。本実施形態では、画面は、バイアルおよびアルコール消毒綿の実
施形態を示し、ユーザに、インスリンバイアルの上部をアルコール消毒綿で清浄するよう
に指示する。いくつかの実施形態では、本実施形態は、アルコール消毒綿で清浄されてい
るバイアルの動画である。次に、図２０Ｅを参照すると、いくつかの実施形態は、パッケ
ージ内の注射器を示す、少なくとも１つの画面を含む。本実施形態では、画面は、パッケ
ージ内の注射器の実施形態を示し、ユーザに、注射器をパッケージから除去し、針を接続
するように指示する。いくつかの実施形態では、本実施形態は、パッケージから除去され
る注射器および接続される針の動画である。次に、図２０Ｆを参照すると、いくつかの実
施形態は、注射器およびバイアルを示す、少なくとも１つの画面を含む。本実施形態では
、画面は、バイアルおよび注射器の実施形態を示し、ユーザに、注射器を最大３日分の供
給量のインスリンで充填するように指示する。リザーバは、最大３ｍＬを保持することが
できる。注射器内のいかなる気泡も除去する。いくつかの実施形態では、本実施形態は、
バイアルからのインスリンで充填される注射器の動画である。

次に、図３０を参照すると、いくつかの実施形態では、流体で充填された（「充填され
た」とは、必ずしも、容量を意味するものではなく、「充填された」とは、注射器および
／またはリザーバに装填された任意の体積の流体を指すために使用され得る）注射器と、
ユーザによって保持され、注射器の写真を撮影する、注射器の近傍に置かれた遠隔インタ
ーフェースの実施形態を示し得る、少なくとも１つの画面が、含まれてもよい。いくつか
の実施形態では、本実施形態は、遠隔インターフェースおよび注射器の動画であって、遠
隔インターフェースは、注射器の写真を撮影する。いくつかの実施形態では、少なくとも
１つの画面は、ユーザに、注射器の写真を撮影するように指示してもよい。いくつかの実
施形態では、ユーザが、本画面に到達すると、遠隔インターフェースは、ユーザが、次い
で、ディスプレイアセンブリ内のファインダを確認し、充填された注射器の写真を撮影し
得るように、自動的に、カメラモードに入ってもよい。いくつかの実施形態では、遠隔イ
ンターフェースは、写真が容認可能であるかどうか確認してもよい。いくつかの実施形態
では、遠隔インターフェースが、「充填された注射器の写真を撮影する」画面から、カメ
ラモードに入ると、カメラモードは、「オートフォーカス」モードになってもよく、およ
び／またはいくつかの実施形態では、本タスク専用に設計される、パターン認識ソフトウ
ェアが、注射器内の流体レベルを判定し得るような解像度で写真を撮影するように設計さ
れた専用カメラモードになってもよい。いくつかの実施形態では、本認識ソフトウェアは
、２Ｄバーコードを読み取るために使用されるソフトウェアに類似してもよい。いくつか
の実施形態では、遠隔インターフェース上のカメラは、他の目的のために、例えば、例え
ば、使い捨て部分および／または再使用可能部分上の２Ｄバーコードを走査するために（
例えば、いくつかの実施形態では、これは、遠隔インターフェースとペアリングされたデ
バイスのために使用されてもよい）、および／またはシステムが注入ポンプを含むかどう
か、インスリンおよび／または注入可能流体バイアルおよび／またはシステムの種々の実
施形態において使用され得る他の周辺機器上の２Ｄバーコードを走査するために、使用さ
れてもよい。

次に、また、図３１−３４を参照すると、いくつかの実施形態では、基礎プロファイル
が、遠隔インターフェース３００４内のカメラと、制限されないが、２Ｄバーコード（そ
の実施例は、例証目的のためだけに与えられる、図３１のアイテム３０００および図３２
のアイテム３００２を参照されたい）を含む、バーコード３０００を使用して、遠隔イン
ターフェースに入力されてもよい。種々の実施形態では、２Ｄバーコードは、ユーザの医
師による処方箋によって生成されてもよい。いくつかの実施形態では、２Ｄバーコードは
、ユーザに通信されてもよく、その通信機構は、制限ではないが、２Ｄバーコードのハー
ドコピーを提供する、および／または２Ｄバーコードを、例えば、電子メール内および／
またはセキュアなウェブポータル上に提供することを含んでもよい。種々の実施形態では
、遠隔インターフェース３００４内のカメラは、２Ｄバーコード３０００、３００２を読
み取る。２Ｄバーコードは、バーコード読取ソフトウェアによって読み取られると、遠隔
インターフェースによって必要とされる情報を提供し、基礎プロファイルをプログラムす
る、２Ｄバーコード内に埋め込まれた埋込処方箋基礎プロファイルを含む。含まれ得る２
Ｄバーコード内に含まれる情報の実施例は、図３３に３００６として示される。情報は、
制限ではないが、ユーザの氏名、生年月日、プロファイルタイプ、プロファイルの有効期
限、および時間枠別に与えられる毎時比率のうちの１つ以上を含んでもよい。いくつかの
実施形態では、２Ｄバーコードが、有効期限を含む場合、遠隔インターフェースは、ユー
ザが、上記で議論されるように、その医師に、アップデートされた基礎プロファイル２Ｄ
バーコードを入力するように促し得るように、有効期限が近づくと、ユーザに警告／アラ
ームしてもよい。種々の実施形態では、プロファイルの有効性が切れると、遠隔インター
フェースは、アップデートされたプロファイル処方箋が入力されない限り、圧送を停止し
てもよい。種々の実施形態では、ユーザは、例えば、制限ではないが、平日、週末、運動
、シックデイ等を含み得る、それぞれ、異なる基礎プロファイルを含む、複数の２Ｄバー
コードを受信してもよい。いくつかの実施形態では、単一２Ｄバーコードが、２つ以上の
基礎プロファイルをエンコードしてもよい。種々の実施形態では、前述のシステムは、３
Ｄバーコードを使用してもよく、他の実施形態では、システムは、ＱＲコード（登録商標
）、すなわち、「クイックレスポンスコード」を使用してもよい。本システムは、手動プ
ログラミングエラーの事例を防止または減少させる（例えば、ユーザが処方箋を手動で入
力する場合、複写エラーがあり得る）ことを含むが、それらに制限されない、多くの理由
から、有益であり得る。しかしながら、２Ｄバーコードを使用して、プログラミングエラ
ーは、排除され、したがって、システムは、手動入力より安全であり得る。加えて、シス
テムは、電子メールで送られ得る、および／またはユーザに電子的に、例えば、セキュア
なウェブポータルにおいて利用可能であり得る、処方箋に有益であり得る。いくつかの実
施形態では、システムは、ユーザに、システムが２Ｄバーコードを読み取る前に、パスコ
ード／パスワードを入力することを要求してもよい。これは、処方箋バーコードが、誤っ
た遠隔インターフェースに読み取られ、プログラムされないように防止するために有益で
あり得る。いくつかの実施形態では、遠隔インターフェース３００４が、２Ｄバーコード
３０００、３００２を読み取ると、遠隔インターフェース３００４は、ユーザが検討する
ために、基礎プロファイルをグラフィカル形態で表示してもよい。

次に、また、図３４を参照すると、いくつかの実施形態では、遠隔インターフェース３
００４は、カメラを使用して、例えば、紙上または電子形式で提示されるかどうかにかか
わらず、基礎プロファイル３００８の写真をグラフィカル形態で撮影してもよい。遠隔イ
ンターフェース３００４は、いくつかの実施形態では、基礎プロファイル３００８のパラ
メータを認識し得、意図された基礎プロファイル３００８が、自動的に、遠隔インターフ
ェース３００４に入力されるように、基礎プロファイル３００８を遠隔インターフェース
３００４にプログラムし得る、認識ソフトウェアを含んでもよい。本システムは、手動プ
ログラミングエラーの事例を防止または減少させる（例えば、ユーザが処方箋を手動で入
力する場合、複写エラーがあり得る）ことを含むが、それらに制限されない、多くの理由
から、有益であり得る。しかしながら、遠隔インターフェース３００４によって読み取ら
れる基礎プロファイル３００８を使用して、プログラミングエラーは、排除され、したが
って、システムは、手動入力より安全であり得る。いくつかの実施形態では、遠隔インタ
ーフェース３００４が、基礎プロファイル３００４を読み取ると、遠隔インターフェース
３００４は、ユーザが検討するために、基礎プロファイル３００８をグラフィカル形態で
表示してもよい。いくつかの実施形態では、システムは、システムが基礎プロファイル３
００８を読み取る前に、パスコード／パスワードを入力することを要求してもよい。これ
は、処方箋基礎プロファイルが、ユーザの同意なく、遠隔インターフェースに読み取られ
、プログラムされないように防止するために有益であり得る。

次に、図２０Ｇを参照すると、いくつかの実施形態は、ユーザに、基部リザーバを充填
するように指示する、少なくとも１つの画面を含む。いくつかの実施形態では、画面は、
リザーバパッケージの中の充填補助具内の注射器の実施形態を示し、ユーザに、注射器を
充填補助具内に挿入し、インスリンを基部リザーバに移すように指示し得る（注射器はま
だ除去されない）。いくつかの実施形態では、本実施形態は、充填補助具内に挿入される
注射器と、プランジャを基部に向かって移動させ、インスリンを基部リザーバに移す動画
である。

次に、図２０Ｈを参照すると、いくつかの実施形態は、泡を充填されたリザーバから除
去する注射器を示す、少なくとも１つの画面を含む。本実施形態では、画面は、リザーバ
パッケージの中の充填補助具内の注射器の実施形態を示し、ユーザに、リザーバの泡をチ
ェックし、いかなる気泡も注射器内に引き戻すように指示する。いくつかの実施形態では
、本実施形態は、ユーザがリザーバ泡をチェックし、気泡を注射器内に引き戻す動画であ
る。

次に、図２０Ｉを参照すると、いくつかの実施形態は、注射器および「鋭利物」容器を
示す、少なくとも１つの画面を含む。本実施形態では、画面は、ユーザが注射器を鋭利物
容器に隣接して保持する実施形態を示し、ユーザに、注射器を除去し、針を鋭利物容器内
に廃棄するように指示する。いくつかの実施形態では、本実施形態は、ユーザが注射器を
除去し、針を鋭利物容器内に廃棄する動画である。

図２０Ｊを参照すると、いくつかの実施形態では、ユーザに、リザーバ体積を入力する
ように要求する画面が、含まれてもよい。いくつかの実施形態では、図２０Ｊに示される
ように、キーパッドが、含まれてもよく、ユーザは、ディスプレイが、単位として、いく
つかの実施形態では、リザーバに移された流体の体積を反映するように、適切な数字ボタ
ンをタッチしてもよい。いくつかの実施形態では、システムは、入力された体積を充填さ
れた注射器の画像から判定された体積と比較してもよい。いくつかの実施形態では、２つ
の体積が、誤差の閾値、例えば、＋または−０．５単位以内である場合、システムは、一
方または他方のいずれかに依拠してもよく、いくつかの実施形態では、ユーザ入力（例え
ば、図２０Ｊにおけるキーパッド上の単位入力）に依拠してもよい。いくつかの実施形態
では、遠隔インターフェースは、２つの数字の間の差異が閾値を超える場合、ユーザに、
再入力を促す、または「間違いないですか？」と尋ねてもよい。これは、リザーバに移さ
れた流体の体積の確認のために望ましくあり得る。

次に、図２０Ｋを参照すると、いくつかの実施形態では、ユーザインターフェースは、
リザーバ体積とともに、少なくとも１つの確認画面を含んでもよく、いくつかの実施形態
では、「リザーバ体積を修正する」ためのボタンを含んでもよく、これは、いくつかの実
施形態では、異なる体積値を入力するための画面、例えば、図２０Ｊに示される画面にユ
ーザを導いてもよい。

次に、図２０Ｌを参照すると、いくつかの実施形態は、ユーザに、使い捨て部分に呼水
を差すように指示する、少なくとも１つの画面を含む。本実施形態では、画面は、使い捨
て部分／リザーバ上の充填補助具を押下する親指／手と、注入セットコネクタのキャプシ
ョンを示し、インスリンの液滴が、注入セットコネクタから可視となるまで、ユーザに、
充填補助具上の呼水ボタンを長押しするように指示する。いくつかの実施形態では、本実
施形態は、インスリンの液滴が、注入セットコネクタから可視となるまで、充填補助具上
の呼水ボタンを長押しする親指／手の動画である。

次に、図２０Ｍを参照すると、いくつかの実施形態は、ユーザに、充填補助具を除去す
るように指示する、少なくとも１つの画面を含む。本実施形態では、画面は、使い捨て部
分／リザーバ上の充填補助具を回転させる手を示し、ユーザに、充填補助具を反時計回り
に回転させることによって、充填補助具を基部から除去し、充填補助具を廃棄するように
指示する。いくつかの実施形態では、本実施形態は、充填補助具を反時計回りに回転させ
ることによって、充填補助具を基部から除去し、充填補助具を廃棄する手の動画である。

次に、図２０Ｎを参照すると、いくつかの実施形態は、ユーザに、ポンプを基部に取り
付けるように指示する、少なくとも１つの画面を含む。本実施形態では、画面は、ポンプ
を基部に取り付けるユーザを示し、「ロック」および「ロック解除」位置アイコンの拡大
図であり得る、挿絵／キャプションを含み、ユーザに、最初に、保護防塵カバーまたは充
電器を除去し、次いで、ポンプを基部に取り付け、ロック位置に回転させるように指示す
る。ポンプは、基部が定位置にあることを検出すると、確認トーンを再生するであろう。
いくつかの実施形態では、本実施形態は、最初に、保護防塵カバーまたは充電器を除去し
、次いで、ポンプを基部に取り付け、ロック位置に回転させる手の動画である。

次に、図２０Ｏを参照すると、いくつかの実施形態は、ユーザに、ポンプボタンを押下
するように指示する、少なくとも１つの画面を含む。本実施形態では、画面は、再使用可
能部分上のポンプボタンを押下するユーザを示し、ユーザに、ポンプボタンを長押しする
ことによって、ポンプをアクティブ化するように指示する。ポンプボタンは、アクティブ
化されると、音を再生するであろう。いくつかの実施形態では、本実施形態は、ポンプボ
タンを長押しすることによって、ポンプをアクティブ化する手の動画である。

次に、図２０Ｐを参照すると、いくつかの実施形態は、ユーザに、ポンプがアクティブ
化されたことを示す、少なくとも１つの画面を含む。本実施形態では、画面は、ポンプ振
動または音の再生を示し、ユーザに、ポンプがアクティブ化されたことを示し、次のボタ
ンを押下し、設定に進むように指示する。

次に、図２０Ｑを参照すると、いくつかの実施形態は、ユーザに、ポンプ試験を開始さ
せることを要求する、少なくとも１つの画面を含む。本実施形態では、画面は、ユーザに
、カニューレが管類セットに接続されていないことを確認するように指示する注意標識を
示す（ポンプ試験は、少量のインスリンを送達するであろう）。画面上のボタンは、ユー
ザが、注意に従ってから、ポンプ試験を開始するために押下すべきことを示す。

次に、図２０Ｒを参照すると、いくつかの実施形態は、ポンプが、ポンプ自己試験を行
なっていることを記す、少なくとも１つの画面を含む。本実施形態では、画面は、ユーザ
に、カニューレが管類セットに接続されていないことを確認するように指示する注意標識
を示し（ポンプ試験は、少量のインスリンを送達するであろう）、また、ポンプが、ポン
プ自己試験を行なっていることを示す。試験は、概して、約１分かかるであろう。

次に、図２０Ｓを参照すると、いくつかの実施形態は、ポンプ試験が完了したことを記
す、少なくとも１つの画面を含む。本実施形態では、画面は、「チェックマーク」を示し
、ユーザに、試験に合格したことを示し（ポンプおよび基部が、適切に機能している）、
「次へ」ボタンを押し、次に進むように指示する。いくつかの実施形態では、「戻る」ボ
タンは、ハイライト解除された状態となり、いくつかの実施形態では、システムが、次へ
進むまたは中断することを示唆することを示してもよい。図２０Ｔを参照すると、いくつ
かの実施形態は、ユーザに、製造業者の指示に従って、注入セットを挿入するように指示
する、少なくとも１つの画面を含む。

次に、図２１Ａを参照すると、いくつかの実施形態は、ユーザに、ＶＥＬＣＲＯをポン
プに取り付けるように指示する、少なくとも１つの画面を含む。前述のように、いくつか
の実施形態では（例えば、図３に関して説明および図示されるように）、使い捨て部分は
、いくつかの実施形態では、ＶＥＬＣＲＯファスナーシステムを含み得る、接着パッチを
含んでもよい。本実施形態では、画面は、使い捨て部分の裏面上のパッチの裏当てに触れ
ているユーザを示し、ユーザに、裏当てを除去し、小さい方のＶＥＬＣＲＯパッチを基部
の裏面に取り付けるように指示する。いくつかの実施形態では、本実施形態は、裏当てを
除去し、小さい方のＶＥＬＣＲＯパッチを基部の裏面に取り付ける手の動画である。

次に、図２１Ａを参照すると、いくつかの実施形態は、ユーザに、ＶＥＬＣＲＯをポン
プに取り付けるように指示する、少なくとも１つの画面を含む。前述のように、いくつか
の実施形態では（例えば、図３に関して説明および図示されるように）、使い捨て部分は
、いくつかの実施形態では、ＶＥＬＣＲＯファスナーシステムを含み得る、接着パッチを
含んでもよい。本実施形態では、画面は、使い捨て部分の裏面上のパッチの裏当てに触れ
ているユーザを示し、ユーザに、裏当てを除去し、小さい方のＶＥＬＣＲＯパッチを基部
の裏面に取り付けるように指示する。いくつかの実施形態では、本実施形態は、裏当てを
除去し、小さい方のＶＥＬＣＲＯパッチを基部の裏面に取り付ける手の動画を含む。

次に、図２１Ｂを参照すると、いくつかの実施形態は、ユーザに、パッチをユーザの身
体に取り付けるように指示する、少なくとも１つの画面を含む。前述のように、いくつか
の実施形態では（例えば、図３に関して説明および図示されるように）、使い捨て部分は
、いくつかの実施形態では、身体に取り付ける、ＶＥＬＣＲＯファスナーシステムを含み
得る、接着パッチを含んでもよい。本実施形態では、画面は、大きい方のパッチの裏当て
および大きい方のパッチに触れているユーザを示し、ユーザに、裏当を除去し、大きい方
のＶＥＬＣＲＯパッチをその身体に取り付け、次に、ポンプをＶＥＬＣＲＯに取り付ける
ように指示する。いくつかの実施形態では、本実施形態は、裏当てを除去し、大きい方の
ＶＥＬＣＲＯパッチを身体に取り付け、ポンプをパッチに取り付ける手の動画である。

次に、図２１Ｃを参照すると、いくつかの実施形態は、ユーザに、注入セットキャップ
を除去するように指示する、少なくとも１つの画面を含む。本実施形態では、画面は、注
入セットキャップを除去するユーザを示し、ユーザに、注入セット上の２つのタブを圧搾
し、保護キャップを除去するように指示する。いくつかの実施形態では、本実施形態は、
注入セット上の２つのタブを圧搾し、保護キャップを除去する手の動画である。

次に、図２１Ｄを参照すると、いくつかの実施形態は、ユーザに、注入セットを接続す
るように指示する、少なくとも１つの画面を含む。本実施形態では、画面は、注入セット
をカニューレに接続するユーザを示し、ユーザに、注入セットをカニューレに接続するよ
うに指示する。いくつかの実施形態では、本実施形態は、注入セットをカニューレに接続
する手の動画である。

次に、図２２Ａを参照すると、いくつかの実施形態は、カニューレに呼水を差すための
少なくとも１つの画面を含む。本実施形態では、画面は、呼水体積を示し、カニューレ呼
水を開始するためのボタンを含み、カニューレ呼水体積が正しいことを検証し、次いで、
カニューレ呼水開始ボタンを押下するように指示する。画面上のボタンは、ユーザが、カ
ニューレ呼水を開始するために押下すべきことを示す。

次に、図２２Ａを参照すると、いくつかの実施形態は、進行中のカニューレ呼水を示す
ための少なくとも１つの画面を含む。本実施形態では、画面は、送達された呼水の体積お
よび総呼水体積を示し、呼水を停止するためのボタンを含む。画面はまた、要求される総
呼水体積のうちの送達された体積を表す、状態バーを含む。

次に、図２２Ｂを参照すると、いくつかの実施形態は、カニューレ呼水が終了したこと
を確認するための少なくとも１つの画面を含む。図２２Ｄを参照すると、いくつかの実施
形態は、設定が完了したことを確認するための少なくとも１つの画面を含み、基礎量を開
始するためのボタンを含む。いくつかの実施形態では、本画面は、自動的に、設定が完了
した後に現れ、これは、制限されないが、ユーザに、注入ポンプに基づく基礎量を開始す
るように再認識させることを含む、多くの理由から有益であり得る。

次に、図２３Ａを参照すると、いくつかの実施形態は、基礎プロファイルをプログラム
するための少なくとも１つの画面を含む。示される実施形態では、基礎プロファイルをプ
ログラムするために、ユーザは、いくつかの実施形態では、体積（毎時単位）であり得る
、比率と、開始および終了時間とを入力する。種々の実施形態では、ユーザは、種々の曜
日用（例えば、月曜日のプロファイル等）、および／または平日用、および／または週末
用の基礎プロファイルを作成してもよく、および／または事象（例えば、スキー）用のカ
スタムプロファイルを作成してもよい。

次に、図２３Ｂを参照すると、いくつかの実施形態は、２４時間周期のグラフィカル表
現と、また、確認時現在の比率の表示の両方を含み得る、１日の基礎プロファイルを視覚
的に検討するための少なくとも１つの画面を含む。

次に、図２３Ｃおよび２３Ｄを参照すると、いくつかの実施形態は、例えば、２４時間
周期の時間の範囲の間、各比率を含むボタンを含む、少なくとも１つの基礎プロファイル
画面を含む。いくつかの実施形態では、ユーザは、時間の範囲のうちの１つを表し、ユー
ザをその特定の時間枠を編集するための画面に導く、ボタンを選択してもよい。いくつか
の実施形態では、画面は、加えて、現在の基礎プロファイルおよび現在の時間枠両方のグ
ラフィカル表現を上部に含んでもよい。

次に、図２４Ａおよび２４Ｂを参照すると、いくつかの実施形態では、遠隔インターフ
ェースは、血中グルコースメータに無線で接続されるか、および／または血中グルコース
メータを含むかのいずれかであってもよい。ユーザが、血液グルコースの読取を行なうと
、いくつかの実施形態では、図２４Ａに示される画面は、自動的に、可視となる。いくつ
かの実施形態では、画面は、例えば、図２４Ａに示されるように、自動的に、時刻に基づ
いて、可能性として考えら得る「タグ」（画面ボタンは、「昼食」を示す）を表す、ボタ
ンを含んでもよい。しかしながら、ユーザは、本タグを編集してもよい。例えば、ユーザ
は、ボタン「追加／編集」を選択してもよく、ユーザは、図２４Ｂに示されるものに類似
する画面に導かれてもよい。メモおよびタグ編集画面は、カスタム編集のためのエリア（
すなわち、編集ボックス）を含んでもよく、ユーザは、編集ボックスにコメントをタイプ
してもよい。タグリストは、ユーザが、パーソナルコンピュータ／ウェブポータルを使用
することによって、または遠隔インターフェースを使用することによってのいずれかによ
って、ユーザ設定に事前にプログラムされ得る、カスタムタグを含んでもよい。いくつか
の実施形態では、ＧＵＩのための設定は、編集され得る、デフォルトリストを含んでもよ
い。

次に、図２５Ａおよび２５Ｂを参照すると、いくつかの実施形態は、図２５Ａに示され
るように、ユーザが、血液グルコース示度値を手動で入力する、画面を含んでもよい。い
くつかの実施形態では、入力し、「次へ」を選択後、例えば、図２５Ｂに示されるような
ラベル画面が、ユーザが、ラベルを選択することを可能にしてもよい。ラベルリストは、
ユーザが、パーソナルコンピュータ／ウェブポータルを使用することによって、または遠
隔インターフェースを使用することによってのいずれかによって、ユーザ設定に事前にプ
ログラムされ得る、カスタムタグを含んでもよい。いくつかの実施形態では、ＧＵＩのた
めの設定は、編集され得る、デフォルトラベルを含んでもよい。

いくつかの実施形態では、例えば、図２５Ａに示されるもの等の画面を使用して、血液
グルコース値を手動で入力することに応じて、ユーザインターフェースは、ユーザが摂取
すべき炭水化物の量を示してもよい。例えば、ユーザが、「４０ｍｇ／ｄＬ」を入力する
場合、システムは、ユーザプロファイルに関して入力される補正情報（すなわち、その医
療介護提供者とともにユーザによって判定され得る、低血液グルコースレベル／低血糖症
を治療するために使用される炭水化物の量）を使用することによって、低血糖症を治療す
るための炭水化物の量を算出してもよい。いくつかの実施形態では、遠隔インターフェー
スは、具体的指示とともに、例えば、１５個のスキットルズ（ｓｋｉｔｔｌｅｓ）（例え
ば、または任意の他の菓子、すなわち、グルコースアイテム）および４オンスのリンゴジ
ュース（しかしながら、いくつかの実施形態では、これらは、異なってもよい）（全て、
遠隔インターフェースまたはパーソナルコンピュータ／ウェブポータルのいずれかを通し
て、ユーザによって、ユーザプロファイルに入力されてもよい）とともに、低血糖症を治
療するように事前にプログラムされてもよく、ユーザインターフェースは、低血糖症グル
コース数値（数値は、システムに事前にプログラムされてもよい）の入力に応じて、食品
、例えば、１５個のスキットルズおよび／または４オンスのリンゴジュースの写真をユー
ザに示してもよい。いくつかの実施形態では、ユーザは、同様に、文字および／または写
真の形態でＧＵＩ上にユーザに提示され得る、付加的提案を要求してもよい。これは、低
血糖症事象の迅速かつ容易な治療を含むが、それらに制限されない、多くの理由から、望
ましくあり得る（ユーザは、低血糖症事象を治療するために食すべき食品を迅速に把握し
、および／またはユーザは、友人または別の人物に、写真を示し、その食品の提供を要求
してもよい）。いくつかの実施形態では、これは、特に、ユーザが現地の言語を話せない
国において、有益となり得る。

次に、図２５Ｃを参照すると、いくつかの実施形態は、いくつかの実施形態では、時間
およびグルコース示度値のリストを含み得る、少なくとも１つのグルコース履歴画面を含
んでもよい。いくつかの実施形態では、付加的情報は、このような画面上において容易に
利用可能となり得るが、あるいはユーザがある示度値を選択する場合、より詳細、例えば
、食した食品および／または活動および／またはラベルおよび／またはタグ、もしくはユ
ーザが示度値にタグ付けまたはラベル付けした任意の他の表示を伴う別の画面が、含まれ
得るかのいずれかとなる。いくつかの実施形態では、「グラフ」タブは、血液グルコース
値のグラフを閲覧するために、グルコース画面からアクセス可能であってもよい。いくつ
かの実施形態では、グラフは、双方向であってもよく、ユーザは、その入力のためのさら
なる詳細および／または時間周期等を含む画面にユーザを導く、グラフ上の点または場所
をタッチしてもよい。いくつかの実施形態では、ＧＵＩは、同一のグラフ上に、持続的グ
ルコースモニタ（ＣＧＭ）、血中グルコースメータ（ＢＧＭ）、および注入ポンプ体積を
示してもよい。

いくつかの実施形態では、グラフィカルユーザインターフェースは、ボーラスをプログ
ラムするための１つ以上の画面を含んでもよい。次に、図２６Ａ−２６Ｄを参照すると、
いくつかの実施形態では、ユーザは、上記で議論されるように、ユーザによるカスタム入
力（遠隔インターフェースを使用するか、および／または食品ライブラリをウェブからダ
ウンロードするか、および／またはパーソナルコンピュータおよび／またはウェブポータ
ル上でカスタム入力を完了し、遠隔インターフェースにダウンロード／それと同期させる
かのいずれか）を含み得る、および／またはデフォルト入力を含み得る、食品ライブラリ
からの品を入力選択してもよい。いくつかの実施形態では、ユーザは、食品ライブラリ画
面にナビゲートし（例えば、いくつかの実施形態では、画面は、図２６Ｋおよび２６Ｌに
示される画面に類似し得る）、食品を選択する、および／または「キーパッド」を選択し
、食品を検索画面にタイプしてもよく、次いで、別の画面、例えば、いくつかの実施形態
では、図２６Ａに示されるもの、またはそれに類似するものが、ユーザに、食品の量を入
力することを要求してもよい。いくつかの実施形態では、画面はまた、例えば、制限では
ないが、炭水化物、脂肪、および／またはカロリーのうちの１つ以上を含み得る、食品の
栄養値の表示を含んでもよい。いくつかの実施形態では、食品が、食品ライブラリから選
択されない場合、確認画面は、いくつかの実施形態では、図２６Ｍに示される画面の実施
形態に類似し得るものをユーザに示すであろう。

いくつかの実施形態では、ユーザは、いくつかの実施形態では、図２６Ｄに示されるも
のに類似し得る、キーパッドを使用して、炭水化物量を入力してもよい。いくつかの実施
形態では、ユーザが、食品アイテムを入力すると、ユーザは、例えば、図２６Ｊに示され
る画面に示されるものと類似するボタンを使用して、付加的アイテムの追加に戻ってもよ
く、そこで、ユーザは、「食品／炭水化物追加」ボタンを選択してもよい。ユーザが、ボ
ーラスのために、食品アイテムを含む、全炭水化物を追加すると、ユーザは、「ＯＫ」を
選択してもよく、図２６Ｂに示されるものに類似し得る、画面が、ユーザに、遠隔インタ
ーフェースが注入ポンプと無線通信を確立していることを示してもよい。

いくつかの実施形態では、ユーザは、炭水化物または食品アイテムおよび量の入力では
なく、ボーラスのために要求されるインスリンの単位を入力することを選択してもよい。
いくつかの実施形態では、これは、例えば、図２６Ｎに示される画面に類似し得る、キー
パッド画面を使用して達成されてもよい。ユーザが、要求される体積を入力すると、ユー
ザは、「ＯＫ」を選択してもよく、図２６Ｂに示されるものに類似し得る、画面が、ユー
ザに、遠隔インターフェースが、注入ポンプと無線通信を確立していることを示してもよ
い。

いくつかの実施形態では、ボーラスプロセスの間、遠隔インターフェースは、最新の血
中グルコースメータ結果を含む、画面を示してもよく、いくつかの実施形態では、ユーザ
に、試験が行なわれた時間と、また、試験からの経過時間を示してもよい。いくつかの実
施形態では、画面は、図２６Ｈにおける画面に類似してもよい。いくつかの実施形態では
、画面は、ユーザに、ボーラス計算機が、ボーラスの補正部分に対して、本最新のグルコ
ース試験を使用することを所望するかどうか確認するように指示してもよい。ユーザは、
いくつかの実施形態では、「いいえ、再試験する」を選択してもよく、その場合、ユーザ
インターフェースは、血中グルコースメータ画面を開いてもよい。いくつかの実施形態で
は、ユーザは、「いいえ、補正ボーラスをスキップする」を選択してもよく、その場合、
ボーラス計算機は、その値を使用せず、自動的に、ユーザを血中グルコースメータ画面に
導かないであろう。いくつかの実施形態では、ユーザは、「ＯＫ」を選択してもよく、ボ
ーラスプロセスが、継続してもよい。

いずれの場合も、ユーザが、制限ではないが、炭水化物値、食品アイテム、血液グルコ
ース値、および／または要求されるインスリン体積の単位のうちの１つ以上を含み得る、
ボーラスに関して入力を所望する情報の全てを入力すると、ユーザインターフェースは、
いくつかの実施形態では、ボーラスカテゴリのそれぞれに対する推奨、例えば、食事ボー
ラス（食品用）、補正ボーラス（グルコース用）を示し、ユーザに、残留ボーラス量（い
くつかの実施形態では、残留インスリン量またはＩＯＢとも称され得る）を示し、推奨さ
れる総ボーラスを示す、例えば、図２６Ｉに示される実施形態に類似し得る、概要画面を
提示する。ユーザは、本ウィンドウからナビゲートし、例えば、画面の「総ボーラス」エ
リアをタッチし、単位あたり値を調節することによって、送達されるべき総ボーラスを調
節してもよい。いくつかの実施形態では、これは、キーパッドを使用して行なわれてもよ
い。いくつかの実施形態では、これは、いくつかの実施形態では、図２６Ｇに示されるも
のに類似し得る、スライド調節ＧＵＩを使用して行なわれてもよい。本実施形態では、推
奨される総量、例えば、３．５１単位が、「ボーラス量修正」ボックス２６００内に示さ
れる。ユーザは、スライダ２６０２を移動させることによって、総体積を調節してもよい
。例えば、ユーザが、スライダ２６０２を左に向かってスライドさせるにつれて、ボーラ
ス量修正ボックス２６００内の総量は、減少し、減少したパーセンテージが、ボーラス量
修正ボックス２６００内に表される。例えば、ユーザが、スライダ２６０２を右に向かっ
てスライドさせるにつれて、ボーラス量修正ボックス２６００内の総量は、増加し、増加
したパーセンテージが、ボーラス量修正ボックス２６００内に表される。これは、制限さ
れないが、ユーザが、推奨されるボーラス量を所与のパーセンテージだけ増減させること
を所望する場合、例えば、運動前の間、２０％減少させる、および／または病気の間、４
０％増加させる場合、ボーラス量修正ボックス２６００が、ユーザにとって、本計算を容
易にすることを含む、多くの理由から、望ましくあり得る。
送達されるべき体積が判定されると、いくつかの実施形態では、ユーザインターフェース
は、ユーザが〜を判定することを可能にする画面を提示する。

しかしながら、ユーザが、推奨検討画面から進むことを所望する場合、ユーザは、いく
つかの実施形態では、「次へ」ボタンを使用して、ナビゲートしてもよい。ユーザが、ボ
ーラス量修正画面からナビゲートする場合、ユーザは、いくつかの実施形態では、「ＯＫ
」ボタンを使用してもよい。いくつかの実施形態では、ユーザは、ユーザが、ボーラスが
送達される方法、すなわち、通常、拡張、または組み合わせを判定することを可能にする
画面に導かれるであろう。次に、図２６Ｅおよび２６Ｆを参照すると、送達されるべきイ
ンスリンの総体積は、いくつかの実施形態では、ユーザが、少なくとも、拡張ボーラスと
して送達されるべきパーセンテージを追加するように修正しない限り、デフォルトとして
、通常ボーラスとして送達されてもよい。いくつかの実施形態では、図２６Ｅに示される
画面の入力に応じて、通常２６０４は、推奨される総量を含み得、拡張２６０８は、０．
００単位を含み得る。送達されるべき総単位２６０６は、スライダ２６１０下に示されて
もよい。通常２６０４および拡張２６０８はまた、いくつかの実施形態では、その方式、
すなわち、通常または拡張のいずれかで送達されるであろう合計のパーセンテージを表す
、パーセンテージを含んでもよい。

ユーザは、スライダ２６１０を移動させることによって、通常２６０４および拡張２６
０８として送達され得る総体積を調節してもよい。例えば、ユーザが、スライダ２６１０
を左に向かってスライドさせるにつれて、総量および通常２６０４内の合計のパーセンテ
ージが増加し、総量および拡張２６０８内の総量のパーセンテージが減少する。しかしな
がら、例えば、ユーザが、スライダ２６１０を右に向かってスライドさせるにつれて、総
量および拡張２６０８内の合計のパーセンテージが増加し、総量および通常２６０４内の
合計のパーセンテージが減少する。これは、制限されないが、ユーザが、特定のパーセン
テージを拡張として送達することを所望する場合、例えば、ユーザが、８０％を拡張とし
て送達することを所望する場合、ユーザが、拡張２６０８内のパーセンテージが「８０％
」を示すまで、スライダ２６１０を右にスライドさせ得ることを含め、多くの理由から、
望ましくあり得る。また、ユーザが、特定の体積、例えば、１．０単位を通常として送達
することを所望する場合（これは、制限されないが、ユーザが、補正ボーラスに起因する
合計の体積を通常として送達することを所望する場合を含む、多くの状況において所望さ
れ得る）、ユーザは、通常２６０４内の体積が１．００単位になるまで、スライダ２６１
０を右に向かってスライドさせてもよい。いくつかの実施形態では、通常２６０４および
／または拡張２６０８下の増減量に関するスライダ２６１０の方向は、異なってもよい。

次に、図２６Ｆを参照すると、ボーラスの任意のパーセンテージまたは体積が、拡張と
して送達されるべきと選択される場合、いくつかの実施形態では、図２６Ｆに示されるも
のに類似する画面が、通常および拡張ボーラス量画面から「次へ」を選択後、ユーザに提
示されてもよい。ユーザは、拡張体積（図２６Ｅから）が拡張ボーラスとして送達される
べき時間量を入力してもよい。いくつかの実施形態では、ユーザが、スライダ２６１２を
右にスライドさせるにつれて、拡張ボーラスのための時間が増加し、ユーザが、スライダ
２６１２を左にスライドさせるにつれて、拡張ボーラスのための時間が、減少する。いく
つかの実施形態では、時間の増減に関するスライダ２６１２の方向は、異なってもよい。
いくつかの実施形態では、図２６Ｆに示されるもの等の持続時間画面は、デフォルト時間
、例えば、１時間として開き、ユーザが修正することを可能にしてもよい。いくつかの実
施形態では、デフォルトは、最新のプログラムされた拡張ボーラスであってもよい。

ユーザが、ボーラス体積の送達のための方法をプログラムすると、ユーザは、いくつか
の実施形態では、「ＯＫ」を選択してもよく、例えば、いくつかの実施形態では、図２６
Ｃに図示されるものに類似する、ボーラス設定検討画面が、可視となってもよい。いくつ
かの実施形態では、ボーラス設定検討画面は、送達されるべき総ボーラス量、送達の方法
、通常として送達されるべき合計の体積、および拡張として送達されるべき合計の体積を
提供し、拡張として送達されるべき体積が存在する場合、拡張ボーラスの持続時間が、示
されてもよい。ユーザは、したがって、ボーラス体積および送達の方法を明確に検討する
機会を有する。いくつかの実施形態では、ボーラス送達を開始するために、ユーザは、「
確認」ボタンを「スライド」させなければならない。これは、潜在的に、「確認」ボタン
の偶発的または非意図的タップの発生を減少させることを含むが、それらに制限されない
、多くの理由から、望ましくあり得る。したがって、中止ボタンを使用して、「中止」す
るための作用、すなわち、タップは、「確認」と、すなわち、スライドと完全に異なる作
用である。また、「中止」ボタンから非常に異なる場所にある、「確認」ボタンおよびス
ライドの場所は、非意図的中止を防止し得る。したがって、本方法は、非意図的中止と、
また、中止が所望されたときの非意図的送達を減少させ得る。また、いくつかの実施形態
では、「次へ」または「ＯＫ」ボタンの場所は、多くの画面上において、類似場所にある
。したがって、療法変更が行なわれるとき、非意図的確認を防止するために、いくつかの
実施形態では、システムは、異なる作用、例えば、タッチ／タップではなく、スライドを
要求し、加えて、いくつかの実施形態では、スライドの開始は、「次へ」または「ＯＫ」
ボタンと反対側にある。

制限されないが、以下を含む、ボーラス体積をプログラムする本方法には、多くの利点
がある。ユーザは、最初に、ボーラスの体積を判定し、次いで、その後、送達の方法を判
定してもよい。したがって、ユーザは、ユーザが総ボーラスの食品ボーラス部分を拡張ボ
ーラスとしておよび総ボーラスの補正部分を通常ボーラスとして送達することを所望し得
る、いくつかの状況において、前述のように、例えば、炭水化物／食品および／または血
液グルコース値を入力する前に、ボーラスが「拡張」されることを決定する必要はない。
また、図２６Ｇ、２６Ｅ、および２６Ｆに示されるスライダ実施形態は、ユーザが、パー
センテージ変更ならびに任意の所与の時間における総体積を閲覧することを可能にする。
本方法は、したがって、誤計算を防止し、インスリン療法のより綿密な微調整およびカス
タマイズを可能にし得る。また、ユーザが、拡張ボーラスとして送達されるべきボーラス
体積の部分の入力後、拡張ボーラスの持続時間をプログラミングすることに関して、ユー
ザは、持続時間を修正する前に、送達を「確認」する可能性が低くなり得る。

次に、図２７Ａ、２７Ｂ、２７Ｃ、および２７Ｅを参照すると、種々の実施形態では、
ユーザインターフェースは、ユーザが作用を中止する種々の機会を含む。いくつかの実施
形態では、ボタン「中止」が押下されると、ユーザが中止を所望することを確認する、別
の画面が現れる。これは、例えば、ユーザが中止ボタンを非意図的にタップする場合、ユ
ーザが、中止ではなく、継続する機会を有するため、望ましくあり得る。

次に、図２７Ｆおよび２７Ｇを参照すると、いくつかの実施形態では、ボーラスがアク
ティブである、例えば、前述の実施例では、ボーラスの一部は、通常として送達され得、
一部は、拡張として送達され得る間、ユーザインターフェースは、アクティブ送達の状態
を示す、「送達中」画面を含んでもよい。例えば、いくつかの実施形態では、図２７Ｆに
示されるように、送達された体積および送達されるべき総体積２７１６が、示されてもよ
く、状態バー２７１４は、送達されるべき総体積の関数として、送達された体積を表す。
加えて、いくつかの実施形態では、送達中画面はまた、プロファイル名、例えば、「平日
」と、事前にプログラムされた基礎比率、例えば、０．８２単位／時間の両方を示し得る
、現在の基礎プロファイル２７１８を含んでもよい。

いくつかの実施形態では、ボーラスがアクティブである間、ユーザインターフェースの
ためのホーム画面は、ボーラス送達状態画面または送達中画面に変わってもよく、例えば
、いくつかの実施形態では、図２７Ｆに示される送達中画面に類似してもよい。いくつか
の実施形態では、アクティブボーラスが送達されているときは常に、ホーム画面（いくつ
かの実施形態では、前述のように、送達中画面に類似してもよい）は、フリーズし、タイ
ムアウトしない。

いくつかの実施形態では、注入ポンプが送達中である間、送達中画面および／またはユ
ーザインターフェースの種々の画面は、ユーザに、送達が生じていることを視覚的に示す
ための異なるスプラッシュスクリーンおよび／または背景画面を含んでもよい。いくつか
の実施形態では、背景は、送達中を示す「緑色」であってもよい。しかしながら、これは
、一実施形態にすぎず、注入ポンプ状態を示す、および／または区別するための他の実施
形態が、使用されてもよい。

依然として、図２７Ｆを参照すると、いくつかの実施形態では、注入ポンプが、ボーラ
スを送達している間、「ボーラス停止」ボタン２７２０が、送達画面上に含まれてもよい
。いくつかの実施形態では、ボーラス停止ボタン２７２０は、画面の残りと異なる色であ
ってもよく、例えば、いくつかの実施形態では、ボーラス停止ボタン２７２０は、赤色で
あってもよい。

次に、図２７Ｇを参照すると、いくつかの実施形態では、アクティブボーラスが送達さ
れている間、ユーザが、「基礎停止」を選択する場合、基礎停止ポップアップ画面２７２
２が現れ、ユーザに、基礎インスリンの送達を停止することを所望することを確認し、ユ
ーザに、これはまた、現在のボーラス送達を停止することになることを再認識させてもよ
い。いくつかの実施形態では、注入ポンプは、ユーザが、ボーラスも停止しない限り、基
礎を停止することを可能にしなくてもよく、これは、ユーザが、基礎インスリンの送達の
停止を所望する場合、全インスリン送達を停止すべきであることを示し得るため、望まし
くあり得る。基礎停止ポップアップ画面２７２２は、「基礎停止」のためのプロセスを開
始することを選択するとき、ユーザが認識していない場合、ボーラス送達が進行中である
ことを再認識させる。

次に、図２７Ｈおよび２７Ｉを参照すると、いくつかの実施形態では、アクティブボー
ラスが送達されている間、ユーザが、「ボーラス停止」を選択する場合、基礎停止ポップ
アップ画面２７２４が現れ、ユーザに、基礎インスリンの送達の停止を所望することを確
認してもよい。いくつかの実施形態では、注入ポンプは、基礎も停止させない限り、ユー
ザが、ボーラスを停止することを可能にしなくてもよく、これは、ユーザが、ボーラスイ
ンスリンの送達の停止を所望する場合、全インスリン送達を停止すべきであることを示し
得るため、望ましくあり得る。図２７Ｈを参照すると、いくつかの実施形態では、ユーザ
が、ボーラスの中止を選択する場合、中止の確認画面が現れ、プログラムされた総体積の
うちの送達された単位２７２６を示してもよい。

次に、図２８Ａを参照すると、ホーム画面の実施形態が、示される。示される実施形態
では、ホーム画面は、いくつかの異なる情報を示し、いくつかの実施形態では、ホーム画
面上の情報の量は、異なってもよい。しかしながら、いくつかの実施形態では、例えば、
注入ポンプが送達中であるという、注入ポンプ状態の表示２８００；アクティブ基礎プロ
ファイルの表示２８０２；残ボーラス量の表示２８０４；いくつかの実施形態では、最後
の結果の時間を含む、最後のグルコース結果の表示２８０６；リザーバ内に残っているイ
ンスリンの体積２８０８；ポンプバッテリの残り寿命のパーセンテージ２８１０；バッテ
リ値２８１４（バッテリレベル表示を含んでもよい）；現在の時間２８１８；接続状態２
８１６；およびそのページが存在するユーザインターフェースのセクション２８１２の情
報が、ホーム画面上に含まれてもよいが、しかしながら、種々の他の実施形態では、その
情報のうちの１つ以上および／または付加的情報が、含まれてもよい。

いくつかの実施形態では、上記で議論されるように、注入ポンプが送達中である間、画
面は、その状態を容易に示す、バックスプラッシュ、アイコン、または他の表示を含んで
もよく、例えば、ページのバックスプラッシュは、状態に応じて、異なる色であってもよ
い。いくつかの実施形態では、送達中状態は、緑色であってもよく、グルコース状態は、
橙色であってもよく、アラーム状態は、赤色であってもよく、アイドル状態は、青色であ
ってもよい。これらの実施形態では、画面に関係なく、注入ポンプの状態は、ユーザによ
って学習されてもよい。アラーム状態画面の実施形態は、図２９Ａ−２９Ｆに見出され得
、アイドル画面の実施形態は、図２８Ｃに見出され得る。いくつかの実施形態では、注入
ポンプがアイドル中であるとき、これは、送達がないことを示し、多くの状況では、長時
間である場合、望ましくない場合がある。したがって、いくつかの実施形態では、注入ポ
ンプが、アイドル状態であるとき、ホーム画面は、アイドル状態２８２８を示し、アイド
ル状態ホーム画面は、「基礎開始」２８３０のための大ボタンを含む。

いくつかの実施形態では、１つ以上の画面は、特定の画面、例えば、ホーム２８１２、
グルコース２８２０、ボーラスまたは基礎２８２２、ログブック２８２４、および／また
は設定２８２６にナビゲートするためのアイコンボタンを含んでもよい。これらの画面の
一実施形態の実施例は、ホーム（図２９Ａ）、グルコース（図２８Ｂ）、インスリン（例
えば、ボーラスまたは基礎）（図２８Ｄ−２８Ｇ）、ログブック（図２８Ｈ）、および／
または設定（図２８Ｉ）のように示される。

次に、インスリン画面の実施形態、図２８Ｄ−２８Ｇを参照すると、いくつかの実施形
態では、インスリン画面は、制限されないが、ボーラス計算機２８３０、ボーラスプログ
ラム２８３２、基礎プログラム２８３４、および基礎停止２８３６のボタンのうちの１つ
以上を含む。いくつかの実施形態では、インスリン画面はまた、体積および時間を含み得
る、最後のボーラス２８３８、ならびに比率およびプロファイル名を含み得る、現在アク
ティブである基礎プロファイル２８４０の表示を含んでもよい。

次に、図２９Ａ−２９Ｆを参照すると、閉塞検出アラームの実施形態が、示される。い
くつかの実施形態では、上記で議論されるように、アラーム状態は、異なるバックスプラ
ッシュ／背景または色に変換してもよく、すなわち、画面のバックスプラッシュは、アラ
ーム状態を示すために赤色であってもよい。いくつかの実施形態では、アラーム状態が、
システムによって感知されると、システムは、ユーザが、アラーム状態を復元および／ま
たは確認するのを支援する、一連のＧＵＩ画面を提供してもよい。例えば、図２９Ａでは
、いくつかの実施形態では、画面は、インスリンの流動が遮断されており、したがって、
閉塞状態が存在することを示してもよい。いくつかの実施形態では、ユーザは、「次へ」
を選択してもよく、ＧＵＩは、ユーザに、推奨される措置を段階的に説明してもよい。例
えば、いくつかの実施形態では、例えば、図２９Ｂでは、画面は、ユーザに、その血液グ
ルコースをチェックすることを再認識させてもよい。図２９Ｃおよび２９Ｄを参照すると
、画面は、ユーザに、ポンプ試験を開始するように指示してもよい（例えば、閉塞が、使
い捨て部分またはカニューレ内であるかどうか判定するため）。ポンプ試験は、いくつか
の実施形態では、使い捨て部分が閉塞を有するかどうか判定してもよい。ポンプ試験を開
始する前に、いくつかの実施形態では、画面は、ユーザに、管類セットから分断すること
を再認識させる。次に、図２９Ｅおよび２９Ｆを参照すると、いくつかの実施形態では、
システムは、閉塞が使い捨て部分内ではないと判定してもよく、ユーザに、カニューレを
交換することを再認識させてもよい。いくつかの実施形態では、システムは、自動的に、
いくつかの実施形態では、前述のものを含み、いくつかの実施形態では、ユーザに、新し
いカニューレに接続すること（および、新しいカニューレに呼水を差す等）を再認識させ
る、動画を含む、一連の画面を開始してもよい。いくつかの実施形態では、システムが、
閉塞が使い捨て部分にあると判定する場合、システムは、ユーザに、使い捨て部分を交換
するように指示してもよい。

システムの種々の実施形態は、したがって、１つ以上のデバイスおよび遠隔インターフ
ェースを含む。いくつかの実施形態では、遠隔インターフェースは、ウェブポータルおよ
び／またはパーソナルコンピュータと接続するように構成され、それらと通信してもよい
。いくつかの実施形態では、遠隔インターフェースは、パーソナルコンピュータであって
もよい。

いくつかの実施形態では、システムは、再充電装置、および／または遠隔インターフェ
ースを再充電するため、および／または１つ以上のデバイスを再充電するためのデバイス
を含む。いくつかの実施形態では、再充電の間、デバイスおよび／または遠隔インターフ
ェースは、ソフトウェアアップデート／ソフトウェアダウンロードを受信し、および／ま
たはデータベースと同期させてもよい。いくつかの実施形態では、再充電デバイスおよび
／または充電器は、パーソナルコンピュータへのＵＳＢ接続を含み、接続は、データポー
トおよび／または充電装置として使用されてもよい。

いくつかの実施形態では、システムは、注入ポンプおよび／または他のデバイスの少な
くとも２つの再使用可能部分を含み、いくつかの実施形態では、両方とも、情報を受信し
、および／または遠隔インターフェースと通信するように構成される。いくつかの実施形
態では、２つの再使用可能部分の１つ目が、再充電されている間、２つの再使用可能部分
の２つ目が、使用中であってもよい。１つ目の再使用可能部分から２つ目の再使用可能部
分への交換は、２つ目の再使用可能部分が、使用されると、アップデートされた情報を含
むように、遠隔インターフェースが、データを２つ目の再使用可能部分と同期することを
含んでもよい。いくつかの実施形態では、再使用可能部分はそれぞれ、不揮発性メモリを
含み、デバイスに命令する１つ以上のプロセッサに関する、全制御および命令能力を含ん
でもよい。したがって、いくつかの実施形態では、遠隔インターフェースは、ユーザイン
ターフェースとして使用されてもよく、コマンド、指示、およびプロファイルは、遠隔イ
ンターフェースを使用して、ユーザによって入力されてもよいが、しかしながら、それら
のコマンドは、デバイスに送信され、いくつかの実施形態では、遠隔インターフェースに
よって、デバイスが情報を正しく受信したことを確認後、デバイスは、全作用を命令し、
例えば、注入ポンプは、注入可能流体の送達を命令する。

いくつかの実施形態では、ユーザが第１の再使用可能部分から第２の再使用可能部分に
使用を変更するために、ユーザは、遠隔インターフェースに、再使用可能部分の変更を所
望することを示してもよい。第１の再使用可能部分は、使用中、現在の残インスリン量お
よび／または残ボーラス量（ＩＯＢとも称され得る）情報を遠隔インターフェースに送信
する。遠隔インターフェースは、本情報を受信し、ＩＯＢ情報に関して、時間の計測を開
始する。第２の再使用可能部分が、遠隔インターフェースに接続されると、遠隔インター
フェースは、タイムスタンプとともに、ＩＯＢ情報を第２の再使用可能部分に送信する。
第２の再使用可能部分は、ＩＯＢ情報に関する時間を確認する。再使用可能部分が、タイ
ムスタンプが一致しないことを見出す場合（いくつかの実施形態では、第１の再使用可能
部分のバッテリが適切に機能していない、および／または充電器に置かれたときに、１０
０％充電が切れていた指標であり得る）、メッセージが、遠隔インターフェースに送信さ
れ、時間が一致していないことをユーザに示す。ユーザは、正しい時間を入力し、本時間
を遠隔インターフェースおよび再使用可能部分の両方に対して入力してもよい。しかしな
がら、タイムスタンプが一致する場合、第２の再使用可能部分は、ＩＯＢ情報に依拠して
もよく、したがって、ＩＯＢ計算は、第１の再使用可能部分から第２の再使用可能部分に
交換中でも、継続し得る。タイムスタンプが一致しない事例では、いくつかの実施形態で
は、ＩＯＢ情報は、削除されてもよく、計算が、新しい設定時間において０から開始し、
ユーザは、遠隔インターフェースを使用して、それを通知される。

遠隔インターフェースは、少なくとも１つのデバイスと通信するために使用されてもよ
い。いくつかの実施形態では、遠隔インターフェースは、種々のデバイスと通信するため
に使用されてもよい。これは、制限されないが、ユーザの親しみやすさを含む、多くの理
由から、望ましくあり得る。単一遠隔インターフェースを使用して、そのソフトウェアプ
ラットフォームが設計されてもよく、多くの実施形態では、単一ユーザが、有意な学習時
間を伴わずに、種々のデバイスのための種々のソフトウェア／アプリケーションを習得し
得るように、性質上、類似するように設計される。加えて、遠隔インターフェースは、Ｕ
ＳＢを介して、パーソナルコンピュータに接続される間、および／またはウェブポータル
に接続される間のいずれかにおいて、通信し得るデバイスの全てのための全ソフトウェア
アップデートをダウンロードしてもよく、次いで、これらのアップデートをデバイス自体
に転送してもよい。これは、制限されないが、能率的プロセスにおいて、デバイスを維持
する、および効率的様式においてデバイスをアップデートするためを含む、多くの理由か
ら、有益であり得る。

加えて、いくつかの実施形態では、パーソナルコンピュータ上にロードされる、および
／またはウェブポータルを通してアクセスされ得る、種々のソフトウェアアプリケーショ
ンを使用して、ユーザは、種々のプロファイルを構成し、および／または１つの場所にお
いて、デバイスに関する種々のデータを検討してもよい。情報および／またはプロファイ
ルに行なわれる変更は、遠隔インターフェース上にダウンロードされてもよい。任意の関
連変更が、次いで、デバイスに無線で通信される。いくつかの実施形態では、デバイス自
体が、パーソナルコンピュータへのＵＳＢ接続を介して、情報を受信してもよい。

いくつかの実施形態では、遠隔インターフェースは、デバイスの制御を支援する画像を
捕捉するために使用されてもよい。例えば、いくつかの実施形態では、ユーザは、遠隔イ
ンターフェース（および、ユーザインターフェース）が、充填された注射器内の流体の体
積に関してユーザ入力された情報の検証、および／または充填された注射器内の流体の体
積の判定のいずれかを行い得るように、遠隔インターフェース上のカメラを使用して、充
填された注射器の写真を撮影するように指示されてもよい。これは、制限されないが、リ
ザーバ内に装填される流体のほぼ正しい体積（いくつかの実施形態では、ユーザのさらな
る安全性につながり得る）を含む、多くの理由から、有益であり得る。いくつかの実施形
態では、注入ポンプは、リザーバ内に残留する流体の体積を判定し、体積が、特定の、い
くつかの実施形態では、事前にプログラムされた体積未満であるとき、ユーザにアラーム
する。これらの実施形態では、ユーザは、体積が完全に枯渇する前に、リザーバを変更（
すなわち、充填されたリザーバと交換）してもよい。したがって、これは、ユーザが薬剤
が全くない事象を被らないように防止する。したがって、リザーバに移されたとして、ユ
ーザによって、正しくない流体の体積が入力される場合、リザーバ内の流体の体積の計算
は、不正確となり得る。これは、制限されないが、リザーバに移される流体の体積が、よ
り高い数値に誤計算される場合、リザーバが、計算されたよりも早く枯渇し得、したがっ
て、ユーザに、予想外な様式において、薬剤がなくなり得ることを含む、所望の多くの理
由から、望ましくあり得ない。しかしながら、リザーバに移される流体の体積が、より低
い数値に誤計算される場合、リザーバは、計算されたよりもゆっくり枯渇し得、したがっ
て、ユーザは、リザーバを早期に交換し、したがって、未使用流体を廃棄し得る。

いくつかの実施形態では、カメラは、前述のように使用されてもよいが、カメラは、遠
隔インターフェースの周辺デバイスの一部であってもよい。いくつかの実施形態では、周
辺デバイスは、画像を遠隔インターフェースに転送してもよく、遠隔インターフェースは
、遠隔インターフェースのカメラによって提供された場合と同様に、画像を処理してもよ
い。

本発明の原理が、本明細書に説明されたが、本説明は、本発明の範囲に関する制限とし
てではなく、一例にすぎないことが、当業者によって理解されるはずである。本明細書に
図示および説明される例示的実施形態に加え、他の実施形態も、本発明の範囲内で想定さ
れる。当業者による修正および代用も、本発明の範囲内であると見なされる。

Claims (1)

1. 装置またはシステムまたは方法。