(57)【要約】埋め込みアウトオブバンド（ＯＯＢ）キー生成を使用して、デバイスが認証情報を入力するための入出力（ＩＯ）能力を必要とすることなく、第１および第２のデバイス間の安全なペアリングのためのキー生成を実装するデバイス、システムおよび方法が提供される。ブルートゥース（Ｒ）スマートまたは低エネルギー（ＢＬＥ）ＯＯＢペアリングオプションは、ＯＯＢキー生成のセキュリティが追加された医療デバイスのペアリングに使用することができる。ＯＯＢキー生成は、第１および第２のデバイスに同じ所定の資格証明書およびセキュアハッシュアルゴリズムを提供すること、および第１および第２のデバイスのハッシュアルゴリズムの入力を同一にすることを含む。第１のデバイスは、同様の入力を共有および計算するために、固有のデータを第２のデバイスに送信する（例えば、ＢＬＥアドバタイジング経由で）。第１および第２のデバイスは、資格証明書および共有されるデータをハッシュ関数と共に使用して、第１および第２のデバイスのそれぞれにおいて同じキーを生成する。
2020522162.tif 000002
【特許請求の範囲】
【請求項１】
無線通信のために第１のデバイスと第２のデバイスとを安全にペアリングするためのキー生成の方法であって、
前記第１のデバイスおよび前記第２のデバイスのそれぞれに資格証明書およびハッシュ関数を提供するステップと、
前記第１のデバイスが、第１のアンテナを介して選択された間隔でかつ選択された無線周波数範囲においてアドバタイジング信号を送信するステップと、
前記第２のデバイスが、第２のアンテナを介して前記選択された無線周波数で走査するステップと、
前記第１のデバイスが、前記アドバタイジング信号で前記第２のデバイスと共有されるデータを提供するステップと、
前記第２のデバイスが、前記走査を介して前記共有されるデータを受信するステップと、
前記第２のデバイスおよび前記第１のデバイスのそれぞれが、前記ハッシュ関数への入力として前記共有されるデータおよび前記資格証明書を使用してキーを生成するステップであって、前記第１のデバイスによって生成されたキーは、前記第２のデバイスによって生成されたキーと同一である、ステップと、
を含むキー生成の方法。
【請求項２】
前記提供するステップは、前記資格証明書および前記ハッシュ関数により前記第１のデバイスおよび前記第２のデバイスを事前構成することを含む、請求項１に記載のキー生成の方法。
【請求項３】
前記資格証明書は、事前定義された１２８ビットの秘密鍵である、請求項１に記載のキー生成の方法。
【請求項４】
前記アドバタイジング信号は、ブルートゥース（Ｒ）低エネルギー（ＢＬＥ）規格に従って生成および送信される、請求項１に記載のキー生成の方法。
【請求項５】
前記ハッシュ関数は、ＡＥＳ−１２８またはＳＨＡ−２５６からなる群から選択されるセキュアハッシュアルゴリズムである、請求項１に記載のキー生成の方法。
【請求項６】
前記共有されるデータは、第１のデバイスに固有であり、メディアアクセス制御（ＭＡＣ）アドレス、および動的な固有パラメータのうちの少なくとも１つを含む、請求項１に記載のキー生成の方法。
【請求項７】
前記キーが１２８ビットのアウトオブバンド（ＯＯＢ）キーである、請求項１に記載のキー生成の方法。
【請求項８】
無線通信のために第２のデバイスと安全にペアリングするためのデバイスであって、
資格証明書およびハッシュ関数を記憶するように構成されたメモリデバイスと、
少なくとも１つのアンテナを介して無線周波数（ＲＦ）信号を送受信するためのＲＦインタフェースと、
前記ＲＦインタフェースおよび前記アンテナを介して、選択された間隔でかつ選択された無線周波数範囲においてアドバタイジング信号を送信し、前記アドバタイジング信号は第２のデバイスと共有されるデータを含み、
前記共有されるデータおよび前記資格証明書をハッシュ関数に入力してキーを生成し、前記デバイスによって生成されたキーは、前記デバイスから前記共有されるデータを含む前記アドバタイジング信号を走査して受信するときに、前記第２のデバイスによって生成されたキーと同一である
ように構成されたコントローラと、
を備えたデバイス。
【請求項９】
無線通信のために第２のデバイスと安全にペアリングするためのデバイスであって、
資格証明書およびハッシュ関数を記憶するように構成されたメモリデバイスと、
少なくとも１つのアンテナを介して無線周波数（ＲＦ）信号を送受信するためのＲＦインタフェースと、
前記ＲＦインタフェースおよび前記アンテナを介して、選択された間隔でかつ選択された無線周波数範囲において第２のデバイスによって送信されるアドバタイジング信号を走査および受信し、前記アドバタイジング信号は、前記デバイスと共有される前記第２のデバイスからのデータを含み、
前記共有されるデータおよび前記資格証明書をハッシュ関数に入力してキーを生成し、前記デバイスによって生成されたキーは、前記第２のデバイスによって生成されたキーと同一である
ように構成されたコントローラと
を備えたデバイス。
【請求項１０】
前記デバイスおよび前記第２のデバイスは、前記資格証明書および前記ハッシュ関数により事前構成されている、請求項８または９に記載のデバイス。
【請求項１１】
前記資格証明書は、事前定義された１２８ビットの秘密鍵である、請求項８または９に記載のデバイス。
【請求項１２】
前記アドバタイジング信号は、ブルートゥース（Ｒ）低エネルギー（ＢＬＥ）規格に従って生成および送信される、請求項８または９に記載のデバイス。
【請求項１３】
前記ハッシュ関数は、ＡＥＳ−１２８またはＳＨＡ−２５６からなる群から選択されるセキュアハッシュアルゴリズムである、請求項８または９に記載のデバイス。
【請求項１４】
前記共有されるデータは、前記デバイスに固有であり、メディアアクセス制御（ＭＡＣ）アドレス、および動的な固有パラメータのうちの少なくとも１つを含む、請求項８に記載のデバイス。
【請求項１５】
前記共有されるデータは、前記第２のデバイスに固有であり、メディアアクセス制御（ＭＡＣ）アドレス、および動的な固有パラメータのうちの少なくとも１つを含む、請求項９に記載のデバイス。
【請求項１６】
前記キーは、１２８ビットのアウトオブバンド（ＯＯＢ）キーである、請求項８または９に記載のデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、デバイスと意図しないデバイスとの間のペアリングおよびペアリングされたデバイスによる悪意のある干渉を最小限に抑えるための、埋め込みアウトオブバンド（ＯＯＢ）キー生成を使用した２つのデバイス間の安全な無線ペアリングのためのシステム、方法および装置に関する。
【背景技術】
【０００２】
身体上の医療デバイス（例えば、ウェアラブル注入ポンプ）およびボディエリアネットワーク（ＢＡＮ）医療デバイス（例えば、手持ち式血糖計、病状管理アプリを備えたスマートフォン、および身体上のデバイス用の無線コントローラ）の需要が、糖尿病などの病状に対する患者の管理を改善し、より便利にしたいという患者および医療提供者の要望の高まりと共に増加している。
【０００３】
ウェアラブル医療デバイスと別個の専用コントローラまたはスマートフォン（例えば、ウェアラブル医療デバイスの操作に関連するアプリを備えたスマートフォン）との間など、２つのデバイス間の安全なペアリングは、意図しない操作、または医療デバイスの操作への悪意のある干渉を避けるために重要である。さらに、医療デバイスを別の意図しない機器とペアリングすることを避けることも重要である。特に、同じエリア内で医療デバイスとペアリングすることができる潜在的なデバイスが複数ある場合は重要である。
【０００４】
ブルートゥース（Ｒ）スマートまたはブルートゥース（Ｒ）低エネルギー（ＢＬＥ）技術は、ウェアラブルデバイスでよくあり得るように、コイン形電池などの電源で動作するデバイスを含む、デバイスを無線接続するための効果的な低電力プロトコルを提供する。ブルートゥース（Ｒ）スマートまたはＢＬＥには現在、３つのペアリングオプション、すなわちＰａｓｓｋｅｙ  Ｅｎｔｒｙ、Ｊｕｓｔ  Ｗｏｒｋｓ、およびＯＯＢ（Ｏｕｔ−ｏｆ−Ｂａｎｄ）があり、これはデバイスの入出力（ＩＯ）機能、およびペアリングされたデバイスのアプリケーションまたは機能に必要な必須のセキュリティのレベル、などの様々な要因に応じて様々なデバイスと使用される場合または使用されない場合がある。例えば、物理ＩＯまたは近距離無線通信（ＮＦＣ）機能のいずれのＩＯ機能も有しないＢＬＥデバイスは、ＯＯＢ認証データをユーザがピアデバイスに入力する必要があるため、ＯＯＢペアリング方法を使用することができない。一方、Ｊｕｓｔ  ＷｏｒｋペアリングおよびＰａｓｓｋｅｙ  Ｅｎｔｒｙのペアリングオプションはいずれも、高度なセキュリティ、したがってより安全なペアリングの方法を必要とする医療アプリケーションなどの多くの無線アプリケーションに対して十分に安全であることが証明されていない。
【発明の概要】
【０００５】
本発明の例示的な実施形態により、上記および他の課題が克服され、追加の利点が実現される。例示的な実施形態はＯＯＢキー生成方法（例えば、ＯＯＢペアリングと共に使用する）を提供し、それによりペアリングされるデバイスが認証データを入力するためのＩＯ機能を必要としない。例示的な実施形態は、身体上および／または薬剤送達デバイスを無線またはモバイルデバイスと安全にペアリングするための埋め込みＯＯＢキー生成方法も提供し、それにより身体上および／または薬剤送達デバイスは、認証データを入力するディスプレイまたはキー入力デバイスを必要とせず、設計が簡素化され、コストが削減される。
【０００６】
本発明の例示的な実施形態の一態様は、第１のデバイスおよび第２のデバイスのそれぞれに資格証明書およびハッシュ関数を提供すること、第１のデバイスが第１のアンテナを介して選択された間隔で選択された無線周波数範囲においてアドバタイジング信号を送信すること、第２のデバイスが第２のアンテナを介して選択された無線周波数において走査すること、第１のデバイスがアドバタイジング信号で第２のデバイスと共有されるデータを提供すること、第２のデバイスが走査を介して共有されるデータを受信すること、および２のデバイスおよび第１のデバイスがハッシュ関数への入力として共有されるデータおよび資格証明書をそれぞれ使用してキーを生成することであって、第１のデバイスによって生成されるキーは、第２のデバイスによって生成されるキーと同一であることを含む、第１のデバイスと第２のデバイスとの間の無線通信のために安全にペアリングするキー生成の方法を提供する。
【０００７】
本発明の例示的な実施形態の態様によれば、提供することは、資格証明書およびハッシュ関数を用いて第１のデバイスおよび第２のデバイスを事前構成することを含む。
【０００８】
本発明の例示的な実施形態の態様によれば、資格証明書は、事前定義された１２８ビットの秘密鍵である。
【０００９】
本発明の例示的な実施形態の態様によれば、アドバタイジング信号は、ブルートゥース（Ｒ）低エネルギー（ＢＬＥ）規格に従って生成および送信される。
【００１０】
本発明の例示的な実施形態の態様によれば、ハッシュ関数は、ＡＥＳ−１２８またはＳＨＡ−２５６からなる群から選択されるセキュアハッシュアルゴリズムである。
【００１１】
本発明の例示的な実施形態の態様によれば、共有されるデータは第１のデバイスに固有であり、メディアアクセス制御（ＭＡＣ）アドレスおよび動的な固有パラメータのうちの少なくとも１つを含む。
【００１２】
本発明の例示的な実施形態の態様によれば、キーは１２８ビットのアウトオブバンド（ＯＯＢ）キーである。
【００１３】
本発明の例示的な実施形態の態様によれば、選択された無線周波数範囲は、２．４０〜２．４８ギガヘルツ（ＧＨｚ）範囲とすることができる。
【００１４】
本発明の例示的な実施形態の態様は、資格証明書およびハッシュ関数を記憶するように構成されるメモリデバイス、少なくとも１つのアンテナを介してＲＦ信号を送受信するための無線周波数（ＲＦ）インタフェース、およびコントローラを備える、無線通信のために第２のデバイスと安全にペアリングするためのデバイスを提供する。コントローラは、選択された間隔で、選択された無線周波数範囲において、ＲＦインタフェースおよびアンテナを介してアドバタイジング信号を送信するように構成されている。アドバタイジング信号は、第２のデバイスと共有されるデータを含む。コントローラは、共有されるデータおよび資格証明書をハッシュ関数に入力してキーを生成する。デバイスによって生成されたキーは、それがデバイスからの共有されるデータを含むアドバタイジング信号を走査して受信するときに、第２のデバイスによって生成されたキーと同一である。
【００１５】
本発明の例示的な実施形態の態様は、資格証明書およびハッシュ関数を記憶するように構成されるメモリデバイス、少なくとも１つのアンテナを介して無線周波数（ＲＦ）信号を送受信するためのＲＦインタフェース、およびコントローラを備える、無線通信のために第２のデバイスと安全にペアリングするためのデバイスを提供する。コントローラは、ＲＦインタフェースおよびアンテナを介して、選択された間隔で選択された無線周波数範囲において第２のデバイスによって送信されるアドバタイジング信号を走査しおよび受信するように構成されている。アドバタイジング信号は、デバイスと共有される第２のデバイスからのデータを含む。コントローラは、共有されるデータおよび資格証明書をハッシュ関数に入力してキーを生成する。デバイスによって生成されたキーは、第２のデバイスによって生成されたキーと同一である。
【００１６】
本発明の例示的な実施形態の態様によれば、デバイスおよび第２のデバイスは、資格証明書およびハッシュ関数により事前に構成されている。
【００１７】
本発明の例示的な実施形態の態様によれば、資格証明書は、事前定義された１２８ビットの秘密鍵である。
【００１８】
本発明の例示的な実施形態の態様によれば、アドバタイジング信号は、ブルートゥース（Ｒ）低エネルギー（ＢＬＥ）規格に従って生成および送信される。
【００１９】
本発明の例示的な実施形態の態様によれば、ハッシュ関数は、ＡＥＳ−１２８またはＳＨＡ−２５６からなる群から選択されるセキュアハッシュアルゴリズムである。
【００２０】
本発明の例示的な実施形態の態様によれば、共有されるデータは、アドバタイジング信号を送信するデバイスおよび第２のデバイスのいずれかに対して固有である。共有されるデータは、メディアアクセス制御（ＭＡＣ）アドレス、ならびにアドバタイジング信号を送信するデバイスおよび第２デバイスの対応する１つに関連付けられた動的な固有パラメータの少なくとも１つを含む。
【００２１】
本発明の例示的な実施形態の態様によれば、キーは１２８ビットのアウトオブバンド（ＯＯＢ）キーである。
【００２２】
本発明の例示的な実施形態の追加のおよび／または他の態様および利点は、以下の説明に記載され、またはその説明から明らかになるか、または本発明の例示的な実施形態の実施により習得され得る。本発明の例示的な実施形態は、上記の態様のうちの１つ以上、および／またはそれらの機能および組み合わせのうちの１つ以上を有する、ペアリングされるデバイスおよびその動作方法を含み得る。本発明の例示的な実施形態は、例えば添付の特許請求の範囲に記載されている上記の態様の特徴および／または組み合わせの１つ以上を含むことができる。
【図面の簡単な説明】
【００２３】
本発明の実施形態の上記および／または他の態様および利点は、添付の図面と併せて以下の詳細な説明からより容易に理解されるであろう。
【００２４】
【図１】本発明の例示的な実施形態による医療デバイスおよびコントローラを示す図である。
【図２Ａ】本発明の例示的な実施形態による医療デバイスのブロック図である。
【図２Ｂ】本発明の例示的な実施形態によるコントローラのブロック図である。
【図３】図２Ａおよび図２Ｂに示された本発明の例示的な実施形態による医療デバイスおよびコントローラの無線周波数（ＲＦ）コンポーネントを示すブロック図である。
【図４】本発明の実施形態による医療デバイスおよびコントローラから送信される信号の図である。
【図５】本発明の実施形態による医療デバイスおよびコントローラから送信される信号の図である。
【図６】本発明の実施形態による医療デバイスおよびコントローラから送信される信号の図である。
【図７】図７Ａおよび図７Ｂの関係を示す図である。
【図７Ａ】図２Ａおよび図２Ｂに示された本発明の例示的な実施形態による医療デバイスおよびコントローラの動作の図である。
【図７Ｂ】図２Ａおよび図２Ｂに示された本発明の例示的な実施形態による医療デバイスおよびコントローラの動作の図である。
【図８】図８Ａおよび図８Ｂの関係を示す図である。
【図８Ａ】図２Ａおよび図２Ｂに示された本発明の別の例示的な実施形態による医療デバイスおよびコントローラの動作の図である。
【図８Ｂ】図２Ａおよび図２Ｂに示された本発明の別の例示的な実施形態による医療デバイスおよびコントローラの動作の図である。
【図９】本発明の例示的な実施形態による、安全な無線ペアリングのための埋め込みアウトオブバンド（ＯＯＢ）キー生成を使用するピアデバイスの動作の図である。
【００２５】
図面全体を通して、同様の参照符号は、同様の要素、機能、および構造を指すことが理解されるであろう。
【発明を実施するための形態】
【００２６】
次に、添付図面に示されている本発明の実施形態を詳細に参照する。本明細書に記載の実施形態は、図面を参照することにより本発明の態様を例示するが、限定するものではない。
【００２７】
図１、２Ａ、および２Ｂを参照すると、医療デバイス１２と、ディスプレイ２４または他のユーザインタフェースを備えたコントローラ１４とを有する例示的な薬剤送達システム１０が示されている。
【００２８】
医療デバイス１２は、ウェアラブルデバイスまたは患者が携帯するデバイスであり得る。医療デバイス１２は、そのコントローラ１４として統合ユーザインタフェースを有することができ、または医療デバイスは、図１に示すように無線コントローラ１４などの別個のコントローラ機器によって制御されるように構成することができる。例示の実施形態において、医療デバイス１２は、無線コントローラ１４によって制御されるが、本発明の例示的な実施形態の態様は、それ自体のコントローラおよび医療デバイス１２とペアリングされる別のデバイス１４を備えた医療デバイス１２に適用されることを理解されたい。さらに、無線コントローラ１４は、例えば、スマートフォンであり得る。
【００２９】
例えば、医療デバイス１２は、インスリン療法を必要とする２型糖尿病（Ｔ２ＤＭ）患者の管理のための設定および可変の基礎（２４時間）レートおよびボーラス（オンデマンド）投与量でインスリンを連続皮下送達するように構成された、単一患者用の使い捨てインスリン送達デバイス（ＩＤＤ）とすることができる。しかしながら、医療デバイス１２は、任意の身体上医療デバイス（例えば、ウェアラブル注入ポンプ、連続血糖計）またはボディエリアネットワーク（ＢＡＮ）医療デバイス（例えば、ハンドヘルド血糖計、病状管理アプリ付きスマートフォン、または身体に装着したデバイス用の無線コントローラ）であり得ることを理解されたい。
【００３０】
以下に説明するように、本発明の例示的な実施形態にしたがって、図７Ｂまたは図８Ｂに示すＢＬＥ規格ペアリングプロトコルのセキュリティを強化する図９を参照して、埋め込みＯＯＢキー生成プロセスを説明する。図７Ａまたは図８Ａに関連して説明される範囲ベースの事前ペアリングプロセスは、ＯＯＢキー生成プロセスの利点を実現するために、ペアリングのためにデバイス１２および１４を介して実装される必要がないことを理解されたい。ＢＬＥ規格ペアリングプロトコルのＯＯＢペアリングオプションは、ＢＬＥのＪｕｓｔ  ＷｏｒｋおよびＰａｓｓｋｅｙ  Ｅｎｔｒｙペアリングオプションよりも高いセキュリティを提供するため、採用されている。
【００３１】
引き続き図１、２Ａおよび２Ｂを参照すると、ＩＤＤ１２は、２型糖尿病（Ｔ２ＤＭ）を有する患者が使用するための高度なインスリン送達システムであるシステム１０の一部である。それは、通常、対象ユーザが居住するすべての環境で２４時間使用することができるように構成されている。それは、患者ユーザが３日間（最大８４時間）ＩＤＤを装着することができるように構成されている。それは、４つの主な機能がある。すなわち、ユーザが設定した毎日の基礎インスリンレートを供給し、ユーザ設定のボーラスインスリン量を供給し、手動のボーラスインスリン投与量を供給し、およびシステムのステータスと通知を生成する。このシステムは、従来の複雑なインスリンポンプの代替として、個々の、単純な、かつ費用効果があるインスリン送達を必要とする複数の毎日の注射（ＭＤＩ）を行う多くの２型糖尿病患者の満たされていないニーズに対処する。しかし、医療デバイス１２は、任意のタイプの流体の送達に使用することができ、インスリンの送達に限定されないことを理解されたい。
【００３２】
無線コントローラ（ＷＣ）１４は、患者に毎日の基礎インスリンレートおよび食事時インスリン量を送達するために、身体装着型ＩＤＤをプログラムするために使用される。ＷＣ１４はまた、ＩＤＤ１２のステータス情報とユーザへの通知も提供する。装着型ＩＤＤ１２は、インスリンを保存し、患者に皮下投与する。ＩＤＤは、問題を検出した場合（例えば、リザーバの容量が少ない、バッテリが少ない）、ＷＣを介して患者にフィードバックを送信する。システム１０の通信ソフトウェアがサポートする重要な機能は、ＷＣ１４とＩＤＤ１２との間の無線通信であり、これにより、ＩＤＤ１２がＷＣ１４にフィードバックを提供し、ユーザがＩＤＤ１２によるそれらのインスリン送達を、単純なかつ個別の方法でＷＣ１４を介して無線で制御することができるようにする。
【００３３】
図２Ａに示される図示の実施形態において、ＩＤＤ１２は、ポンピング機構５２、ＷＣとの無線通信（例えば、マッチ回路（match circuit）およびアンテナを有するＲＦ回路５４を介して）、ならびにポンプ操作を制御するように構成されたマイクロコントローラ６０を有する。ＩＤＤは、プログラムされた薬剤送達に加えて、薬剤の手動送達のためのボーラスボタン６４を有する。ポンピング機構５２は、カニューレ６８を介してＩＤＤを装着している患者に送達される流体薬剤（例えば、インスリン）を保存するためのリザーバ７６と、カニューレを通してリザーバから指定された量の薬剤を制御可能に送達するためのポンプ７２とを備える。リザーバ７６は、シリンジを使用し、セプタム７８を介して充填することができる。ＩＤＤは、カニューレ６８を患者に挿入するための手動挿入機構６６を備えている。ただし、プロセッサ６０は、カニューレ６８を患者内に配置するために挿入機構６６の動作を自動化するオプションの駆動回路を動作させるように構成することができる。さらに、ＩＤＤ１２には、オプションとして、流体センサ７４または圧力センサ７０を設けることができる。ＬＥＤ６２は、例えば、リザーバプライミング中などの１つ以上のポンプ動作中にオンまたは点滅するようにマイクロコントローラ６０によって動作させることができる。ＩＤＤ１２は、５８で示されるように、バッテリおよびレギュレータによって電力を供給される。ＩＤＤ１２を初期化するとき（例えば、電源を入れてＷＣ１２とペアリングを開始するとき）、ボーラスボタン（複数可）６４は、起動ボタン（複数可）として構成することができ、ユーザがアクティブにすると、ＩＤＤ１２を省電力シェルフモードから起動させる。
【００３４】
図２Ｂに示される例示の実施形態では、ＷＣ１４は、１）ＷＣメインプロセッサ（ＷＣＭＰ）３０、およびＷＣ通信プロセッサ（ＷＣＣＰ）３２を有するデュアルマイクロプロセッサコンポーネントとして実装される。ＷＣＭＰ３０は、タッチスクリーン２４を備えたＬＣＤディスプレイ、１つ以上のボタン２８、ＬＥＤインジケータ２６などのユーザインタフェース（ＵＩ）コンポーネントに接続されている。ＷＣＣＰ３２は、無線周波数（ＲＦ）コンポーネント３８（例えば、アンテナおよびマッチ回路）に接続され、主にＷＤ１４のＩＤＤ１２との無線通信を担当する。２つのプロセッサ３０、３２は、シリアルペリフェラルインターフェイス（ＳＰＩ）を介して互いに通信する。２つのプロセッサ３０、３２は、２つの割り込みピン、Ｍ＿ＲＥＱ＿ＩＮＴおよびＳ＿ＲＥＱ＿ＩＮＴを介して互いに割り込むこともできる。
【００３５】
引き続き図２Ｂを参照すると、ＷＣ１４は、電力用の交換可能なアルカリ電池３４を除き、現場で修理することができないように設計されている（すなわち、ユーザが検査、調整、交換、または保守する部品がない）。不揮発性メモリ（例えば、フラッシュメモリ）３６がＷＣに設けられ、送達日および時間および量などのＩＤＤ１２から受信した送達およびステータスデータを記憶する。
【００３６】
静電容量式タッチスクリーン２４を備えたＬＣＤは、ユーザに視覚的およびグラフィカルな出力（例えば、システム情報、指示、視覚的通知、ユーザ設定、データ出力など）をレンダリングすることにより、ユーザが入力（例えば、ＩＤＤのペアリング、設定および投与、ならびに構成パラメータなどのデバイス操作入力）を入力するための視覚的なインタフェースを提供するユーザの視覚的インタフェースとして機能する。静電容量式タッチスクリーン２４を備えたＷＣディスプレイは、その表示領域上の（少なくとも）シングルタッチジェスチャを検出する。例えば、タッチスクリーンは、ＵＩ画面およびアプリケーション内でのナビゲーションを可能にするユーザの触覚入力（タップ、スワイプ、およびボタンの押下）を認識するように構成されている。タッチスクリーン２４は、特定のユーザインタラクションを通じて特定のシステム機能（すなわち、ＩＤＤ１２の設定およびＷＣ１４とのペアリング、インスリン投与、ユーザへの投与履歴の提供、ならびにＩＤＤの無効化および別のＩＤＤへの置換など）の実行を支援する。ＷＣ１４は、ユーザによって起動されると、ＷＣ１４を省電力スリープモードから起動させるデバイス起動ボタンなどのボタン２８を含むこともできる。ＷＣ１４は、低バッテリ状態を示すためにＬＥＤ２６を有することもできる（例えば、残りの使用時間が１２時間以下のときに低バッテリ状態を示す）。
【００３７】
ＩＤＤ１２とのＷＣ１４無線周波数（ＲＦ）インタフェースは、例えば、ブルートゥース（Ｒ）低エネルギーまたはＢＬＥベースの通信プロトコルに基づいているが、他の無線通信プロトコルを使用することもできる。薬剤送達システム１０では、ＷＣ１４およびＩＤＤ１２は、２４００ＭＨｚから２４８０ＭＨｚのスペクトルのＩＳＭ帯域を利用して、最大１０フィートまたは約３メートルの距離内で無線通信する。ＷＣ１４は、ＩＤＤが戸外で身体に付着されている間、ＩＤＤ１２と通信する。ＷＣ１４は中央デバイスまたはマスターであり、ＩＤＤ１２は周辺デバイスまたはスレーブである。ＷＣＭＰ３０は、ＩＤＤ１２に情報を送信したり、ＩＤＤ１２から情報を取得したりしたい場合は常に、ＷＣＣＰ３２と対話することによりそれを行い、ＷＣＣＰ３２もまた、図３に示すようにそれぞれのＲＦ回路３８および５４を通じてＢＬＥリンクを介してＩＤＤ１２と通信する。
【００３８】
本発明の例示的な実施形態によれば、ＷＣ１４（例えば、そのＷＣＣＰ３２）およびＩＤＤ１２は、プロトコルおよび様々な動作に従って通信し、ＷＣ１４が意図しないＩＤＤ１２’と対になるリスクを緩和し、または、逆に、意図したＩＤＤ１２が意図しないＷＣ１４’とペアになることを緩和する。いずれの場合も、ポンプ機構５３の意図しない動作を引き起こす可能性があり、その結果、患者に有害なインスリンの過剰注入が生じる可能性がある。システム１０の例示的な態様によれば、ＩＤＤ１２の起動時（例えば、ペアリング前）の通信範囲が縮小され、意図しないＩＤＤ１２’などの意図しないデバイスがＷＣ１４によって拒否され、複数のＩＤＤ共存が検出された場合、ＩＤＣ１２がＷＣ１４によって検出された唯一のＩＤＤでない限り、ＷＣ１４がＩＤＤ１２とペアリングすることが防止される。以下により詳細に説明するように、システム１０における例示的な動作は、ＷＣ１４およびＩＤＤ１２の送信電力レベルを低減して、通信範囲を（例えば、ペアリング前に２０インチ以下に）制御し、信号強度インジケータ（例えば、最小および最大受信信号強度インジケータ（ＲＳＳＩ）しきい値）を使用して、意図しないＩＤＤ１２’を含む意図しないデバイスを拒否し、複数のＩＤＤの共存を検出するためのＷＣ１４の起動走査時間を調整し、複数のＩＤＤ１２が検出された場合に彼／彼女のＷＣ１４およびＩＤＤ１２と共に他の部屋または場所に移動してペアリングを再試行するようにユーザに指示し、およびそれがＷＣ１４によって検出された唯一のＩＤＤ１２である場合にのみ、ＷＣ１４がＩＤＤ１２とペアリングすることを可能にすることを含む。
【００３９】
ペアリング前のＩＤＤ１２のアドバタイジングおよびＷＣ１４の走査は、本発明の例示的な実施形態に従って図４に示されている。起動時かつペアリングする前に、１０６で示されるように２５０ｍｓ（＋／−１０％）ごとに、ＩＤＤ１２はＩＤＤスタートアップアドバタイジングデータパケット１００でアドバタイズし、ＷＣ１４からの起こり得る応答を３ｍｓ（＋／−１０％）待機する。ＷＣＭＰ３０の要求で、ＷＣＣＰ３２は、７４６ｍｓ（＋／−１０％）１０４ごとに約５０５ｍｓ（＋／−１０％）の走査ウィンドウ１０２でＩＤＤアドバタイジングの走査を開始することにより、通信を開始する。走査期間１０４の終わりに、ＷＣＣＰ３２は、図７および図８に関連して以下で説明するように共存チェックを実行する。走査期間１０４の終わりに、ＷＣＣＰ３２がトランスポート層タイムアウト期間内にアドバタイジングパケット１００を検出しなかった場合、ＷＣＣＰは走査を停止し、送信タイムアウトエラーコードとともにＮａｃｋ応答を送信する。以下に、図７および図８に関連して説明したように、Ｎａｃｋ応答を送信した後、アドバタイジングが検出されない場合、ＷＣＣＰ３２はスリープ状態になる。
【００４０】
ペアリング後のＩＤＤ１２のアドバタイジングおよびＷＣ１２の走査は、本発明の例示的な実施形態に従って図５に示されている。ペアリング後、ＩＤＤ１２がアクティブにポンピングされていない場合、ＩＤＤ１２は、選択された間隔１０８（例えば、１秒（＋／−１０％）ごと）で、ＩＤＤ定期的データパケット１００でアドバタイズする。各アドバタイズ１００の後、ＩＤＤ１２は、ＷＣ１４からの可能な応答に対して３０ｍｓ（＋／−１０％）待機する。ペアリングの後、ＷＣＭＰ３０の要求で、ＷＣＣＰ３２は７４６ｍｓ（＋／−１０％）ごとに５０５ｍｓ（＋／−１０％）の走査ウィンドウ１０２についてＩＤＤアドバタイズの走査を開始することにより、通信を開始する。
【００４１】
ポンピング中のＩＤＤ１２のアドバタイジングおよびＷＣ１４の走査は、本発明の例示的な実施形態に従って図６に示されている。ＩＤＤ１２がインスリンなどの薬剤を送達している場合、分配投与（ｄｉｓｐｅｎｓｅ）ストローク１１２の終わりに２秒間５００ｍｓごとにアドバタイズする。図６には示されていないが、ＩＤＤ吸引期間１１０と分配投与期間１１２との間の休止期間中、ＩＤＤ１２は可能であればアドバタイジングを試みる。ＩＤＤ１２がポンピングしている場合、ＷＣＭＰ３０の要求で、ＷＣＣＰ３２は、７４６ｍｓ（＋／−１０％）１０４ごとに５０５ｍｓ（＋／−１０％）の走査ウィンドウ１０２でＩＤＤアドバタイジングの走査を開始し、通信を開始する。
【００４２】
図７Ａおよび７Ｂを参照し、ＷＣ１４およびＩＤＤ１２について、特にＷＣＭＰ３０、ＷＣＣＰ３２、およびＩＤＤプロセッサ６０に関して動作が説明される。ＷＣＭＰ３０およびＷＣＣＰ３２間のＳＰＩインタフェースが示されている。ただし、上記で説明したように、ＷＣ１４はシングルプロセッサデバイスとして構成することができる。また、上述したように、ＷＣ１４とＩＤＤ６０との間にＢＬＥインタフェースまたは同様の無線インタフェース１２４が設けられている。参照しやすいように、図７Ａおよび７Ｂにおいて動作は１から３０の番号が付けられている。
【００４３】
ＷＣ１４とＩＤＤ１２とのペアリングを開始するために、ＩＤＤ１２は、図７Ａの動作１によって示されるように、（例えば、ユーザがボタン（複数可）６４を起動することにより）省電力シェルフモードから起動され得る。ＩＤＤ１２は、送信電力を低減し（動作２）、送信電力レベル０で最大１分＋／−１０％でＩＤＤスタートアップアドバタイジングデータのアドバタイジングを開始する（動作５）。ＩＤＤ１２は、ＩＤＤスタートアップアドバタイジングデータパケットを定期的に送信する（動作８）。ＷＣ１４は、ユーザがタッチスクリーン２４のスタートボタンまたは他のボタン２８などのボタンを作動させることに応じて、その節電スリープモード（例えば、動作３に示される）から起動し、ＷＣＰＭ３０がＷＣＣＰ３２に開始コマンドを送信するなどのスタートモードに入る（動作４）ことができる。ＷＣＰＣ３２は、開始コマンドを受信すると、図４に関連して上述したように、ＩＤＤスタートアップアドバタイジングデータの走査を開始する（動作６）。
【００４４】
引き続き図７Ａおよび動作９を参照すると、ＷＣ１４は、特定のタイプのデバイス１２がその近傍にあるかどうかを判定することができる。例えば、ＩＤＤ１２スタートアップアドバタイジングデータは、ＩＤＤ識別情報（例えば、製造業者および／またはモデルまたはその他の特性などのデバイスのタイプを識別する選択された動的および／または静的パラメータまたは値）を含むことができ、その結果、ＷＣ１４が指定されたＩＤＤ識別情報を持つデバイスまたはＩＤＤのみとペアリングし、指定されたＩＤＤ識別情報を有する他のデバイスとはペアリングしないように構成される。動作９を参照すると、ＷＣＣＰ３２は、ＩＤＤ１２スタートアップアドバタイジングデータが、例えばその特定の製造業者に関連するＩＤＤ識別情報を有しているかどうかを判定することができる。そうでない場合、ＷＣＣＰ３２は走査を続行する（動作７）。
【００４５】
図７Ａの動作１０を参照すると、ＷＣＣＰ３２が、指定されたＩＤＤ識別情報を有する近傍のデバイスからのＩＤＤスタートアップアドバタイジングデータを走査する場合、ＷＣＣＰ３２は、ＩＤＤスタートアップアドバタイジングデータに関連する符号強度情報が１つ以上のしきい値を満たしているかどうかの判定を開始する。例えば、ＷＣＣＰ３２は走査を停止し、受信されたパケットの受信信号強度インジケータ（ＲＳＳＩ）チェックを実行することができる。ＲＳＳＩ情報は、例えば、ＷＣ１４のＲＦ回路３８内のＲＦチップにより生成することができる。ＲＳＳＩが最小レベル（例えば、−６５ｄＢｍ＋／−１０％）未満である場合、ＷＣＣＰ３２は受信したアドバタイジングパケットを無視し、および走査プロセスを再試行する（動作７）。ＷＰ１４の近傍でアドバタイズするＩＤＤ１２をノイズまたはペアリングに関して意図しないデバイスとなるＷＣ１４から十分に離れたＩＤＤ１２と区別するために、最小レベルが選択される。
【００４６】
図７Ａの動作１１を参照すると、ＲＦジャムが発生した可能性がある場合など、ＲＳＳＩが最大レベル（例えば、−３ｄＢｍ＋／−１０％）を超える場合、動作１２で示されるようにＷＣＣＰ３２はＮａｃｋ応答（例えば、最大ＲＳＳＩ超過エラーコードの応答）をＷＣＭＰ３０へ送信する。次にＷＣＭＰ３０は、ユーザに別の場所に移動するようアドバイスするアラートを生成することができる（例えば、ＬＣＤタッチスクリーン２４を介して）（動作１３）。
【００４７】
走査期間の終わりに、ＷＣＣＰ３２が複数のＩＤＤ１２からのアドバタイジングパケットを検出した場合（動作１４）、ＷＣＣＰ３２は、ＷＣＭＰ３０にＮａｃｋ応答（例えば、共存検出エラーコードを有する応答）を送信する（動作１５）。次にＷＣＭＰ３０は、ユーザに別の場所に移動してペアリングを再試行するよう通知し、任意選択で別のＩＤＤが検出されたことを通知するアラートを生成する（例えば、ＬＣＤタッチスクリーン２４を介して）（動作１６）。
【００４８】
ＲＳＳＩおよび共存チェックに合格した場合、ＷＣＣＰ３２は、ＩＤＤスタートアップアドバタイジングデータ応答メッセージをＷＣＭＰ３０に送信することができる（動作１７）。応答メッセージを受信すると、ＷＣＭＰ３０は、（例えば、指定されたＩＤＤ識別情報を使用して）ＩＤＤスタートアップアドバタイジングデータを検証する（動作１８）。このＩＤＤ互換性チェックが成功した場合、ＷＣＭＰ３０はペアリングコマンドメッセージをＷＣＣＰ３２に送信する（動作１９）。ペアリングコマンドを受信すると、ＷＣＣＰ３２は、本発明の例示的な実施形態に従って、アウトオブバンド（ＯＯＢ）キー生成（動作２０）を実行する前に、ペアリングコマンドメッセージに対してＩＰＣ健全性チェックを実行することができる。
【００４９】
図７Ａの動作２１を参照すると、ＩＤＤ１２とＷＣ１４との間でペアリングプロセス（例えば、ブルートゥース（Ｒ）低エネルギーＯＯＢペアリング方法）が開始される。例えば、図７Ｂにおいて動作２２および２３に示すように、ＩＤＤ１２は、ペアリング要求を受信し、健全性チェックが失敗した場合にＩＤＤ１２に要求を無視させ、健全性チェックが成功した場合にＷＣＣＰ３２にペアリング応答を送信させる健全性チェックを実行することができる。ＩＤＤ１２およびＷＣＣＰ３２はそれぞれ、ペアリングアルゴリズム（動作２４）を実行することができる（例えば、ブルートゥース（Ｒ）低エネルギー（ＢＬＥ）ペアリング）。ペアリングキーは、ＩＤＤ１２とＷＣＣＰ３２で別々に生成することができるため、ペアリングキーの交換にエアインタフェースは必要ない。ＷＣＣＰ３２は、ペアリングキー情報を不揮発性メモリの場所に保存する。ＷＣＣＰ３２は、ＩＤＤに低レベルの確認パケットを送信することによりペアリングを確認する（動作２５）。ＷＣＣＰ３２の確認パケットを受信すると、ＩＤＤ１２はペアリングキー情報を保存する。ＷＣＣＰの確認パケットを受信すると、ＩＤＤは低レベルの確認パケットをＷＣＣＰ３２に返送してペアリングを確認する（動作２６）。したがって、ＷＣＣＰ１４およびＩＤＤ３２は、ペアリングキーの配布を容易にする（動作２７）。
【００５０】
引き続き図７Ｂを参照すると、ペアリングが完了すると（例えば、ＢＬＥ規格のセキュリティマネージャプロトコル（ＳＭＰ）ペアリングに従って）、ＷＣＣＰ３２は、ペアリングコマンドをＩＤＤ１２に送信する（例えば、一旦低レベルのペアリングが完了したらトランスポート層ペアリングを実行するため）（動作２８）。ＩＤＤの確認パケットを受信すると、ＷＣＣＰ３２は、ペアリング成功メッセージをＷＣＭＰ３０に送信する（動作２９）。ペアリング成功メッセージを受信すると、ＷＣＭＰ３０は、ペアリングキー情報を記録用に不揮発性メモリに保存し、ユーザインタフェースにペアリング成功を表示することができる（動作３０）。ペアリング後、ＩＤＤ送信電力レベルを設定して（例えば、１５に）通信範囲を拡大する（動作３１）。さらに、ペアリング後、ＷＣＣＰ３２の送信電力レベルも増加する。ＷＣ１４は、ペアリングされたＩＤＤ１２とのみ通信し、ＩＤＤ１２は、ペアリングされたＷＣ１４からのコマンドのみを受け入れる。このＷＣ１２とＩＤＤ１４の結合された通信関係は、ＩＤＤが非アクティブ化されるまで維持される。ＩＤＤの非アクティブ化後、ＷＣ１４は新しいＩＤＤ１２と自由にペアリングすることができる。ただし、任意の所与の時点で、ＷＣ１４は１つのＩＤＤ１２とのみペアリングすることができることが好ましい。
【００５１】
図８Ａおよび８ＢにおけるＷＣ１４およびＩＤＤ１２の動作は、図７Ａおよび７Ｂのものと同様である。ただし、共存チェック（動作１０）は、信号強度（ＲＳＳＩなど）のチェック（動作１３および１４）の前に発生する。言い換えれば、共存チェックと信号強度チェックの順序は交換可能である。また、デバイスチェック（動作９）は任意選択とすることができる。
【００５２】
本発明の一態様によれば、ＷＣＣＰ３２は、絶えず走査（例えば、図７Ａおよび図８Ａの動作７）する必要はなく、これはＷＣ１４の電力を節約する。言い換えれば、ＷＤＣＰ３２がＷＣ１４のペアリング範囲内のＩＤＤ１２からのＩＤＤスタートアップアドバタイジングデータパケット１００の検出を見逃さないことを保証するために、ＷＣＣＰによる走査は、ＩＤＤ１２による２つのアドバタイジング間隔１０６（例えば、２つの２５０のアドバタイジング間隔１０６）よりも長い選択された期間（例えば、図４に示す５０５ｍｓの走査ウィンドウ１０２）で走査が発生するようにインターリーブすることができる。その後、ＷＣＣＰは、次の走査間隔１０４内の時間の別の走査ウィンドウ１０２について再度走査する前に、走査間隔１０４内で選択された時間間隔（例えば、図４の２４１ｍｓ）の間、走査を停止する。
【００５３】
走査ウィンドウ１０２の間にＩＤＤスタートアップアドバタイジングデータパケット１００が検出された場合、ＷＣＣＰ３２は走査を停止し、図７Ａに関連して上述した様々なチェックの１つ以上を開始する。すなわち、デバイスチェック（動作９）、受信信号強度チェック（動作１０および１１）、および共存チェック（動作１４）である。動作１４で複数のデバイスが見つかった場合、または他のチェックに合格しなかった場合（すなわち、動作９、１０および１１）、ＷＣＣＰ３２は再び走査を開始する（動作７）。
【００５４】
走査ウィンドウ１０２の間にＩＤＤスタートアップアドバタイジングデータパケット１００が検出されない場合、ＷＣＣＰ３２は、選択された時間（例えば、１０秒）、一連の走査間隔１０４にわたって走査し、タイムアウトすることができる。タイムアウトすると、ＷＣＣＰ３２はＮａｃｋ信号をＷＣＭＰ３０に送信し、次に通信エラーと、ＷＣ１４に近い意図されたＩＤＤ１２である必要性と、ペアリングの再試行についてユーザに警告する。
【００５５】
本発明の一態様にしたがって、図９を参照し、次に、ＯＯＢキー生成を使用してセキュリティを強化するための図７Ｂおよび図８Ｂに示すＢＬＥ規格ペアリングの拡張（例えば、図７Ａおよび図８Ａの動作２０）について説明する。第１に、例えば、ＡＥＳ−１２８またはＳＨＡ−２５６などのセキュアハッシュアルゴリズム（Ｈ）または他のセキュアハッシュアルゴリズムが、ペアリングされるピアデバイスのそれぞれで使用される。第２に、ピアデバイスのハッシュ関数の入力は同一になるように構成され、その結果、各ピアデバイスでハッシュ関数の出力として同一のＯＯＢキーを生成することができる。各ピアデバイスでハッシュ関数への同じ入力を構築するために、ピアデバイス（例えばＩＤＤ１２）は、その固有のデータの一部を別のピアデバイス（例えば無線コントローラ１４）に送信して、例えば、ＭＡＣアドレスおよび／またはアドバタイジング１００を介した他の動的な固有のパラメータなどを共有する（すなわち、以下で共有データと呼ぶ）。さらに、潜在的にペアリングすることができるすべてのデバイス（例えば、ＩＤＤ１２、ＷＣ、またはスマートフォンアプリ１４）が資格証明書、例えば１２８ビットの秘密鍵を共有する。この共有データとセキュアハッシュ関数の事前定義された秘密鍵を入力として使用して、ピアデバイス１２、１４は共に、同一の１２８ビットのＯＯＢキー、すなわちペアリング用の認証データを生成する。ＭＡＣアドレスなどの動的パラメータは変形として構築することができ（例えば、ＩＤＤ１２の間で固有）、１２８ビットの秘密鍵が共有され、同一に保たれる（例えば、ＩＤＤ１２とＷＣまたはスマートフォンアプリ１４との間で同一）。したがって、ペアリングデバイスの様々なセットの各ペア１２、１４のＯＯＢキーは異なり、安全である。
【００５６】
図９に示されるように、スレーブデバイス（例えば、ＩＤＤ１２）およびマスターデバイス（例えば、無線コントローラ１４）は、両方とも、事前定義された秘密鍵（Ｃ）、およびセキュアハッシュ関数（Ｈ）を備える。例えば、マスターデバイスおよびスレーブデバイスの両方に、同一の１６バイトの秘密鍵Ｃ＝｛ｃ０、ｃ２、…ｃ１５｝がプログラムされている。秘密鍵Ｃおよびハッシュ関数Ｈは、例えば、製造時にＩＤＤおよびＷＣ１４に、またはキー生成に必要なこの情報を含む対応するアプリがインストールされたときにＩＤＤと共に動作するスマートフォン１４に提供することができる。スレーブデバイスは、固有の共有データ｛ｓ１、ｓ２、ｓ３、…、ｓｎ｝を準備する。１２０に示すように、各ＩＤＤ１２は、ペアリングを希望するＷＣ１４にアドバタイジングパケット１００を送信するように構成される。アドバタイジングパケット１００には、そのＩＤＤの固有の共有データ｛ｓ１、ｓ２、…、ｓｎ｝が含まれている。１１９に示すように、マスターデバイスは走査を開始し、スレーブデバイスは共有データ｛ｓ１、ｓ２、ｓ３、…、ｓｎ｝をアドバタイズする。マスターデバイスは、１２１に示すように、スレーブのアドバタイジングから共有データを読み出し、１２２で示されるようにＩＤＤとＷＣの両方が同じ入力Ｓ＝ｓ１||ｓ２||ｓ３||…、||ｓｎを計算するようにする。同じ入力（すなわち、共有データＳおよび所定のキーＣ）は、１２４で示されるように、ピアデバイスのそれぞれに用意される同じ選択されたセキュアハッシュアルゴリズムＨに与えられ、その結果、ＩＤＤ１２およびＷＣ１４は、１２６で示されるように、それぞれ同一のキーを生成する（すなわち、Ｋｍ＝Ｈ（Ｃ、Ｓ）およびＫｓ＝Ｈ（Ｃ、Ｓ）、したがって、Ｋｍ＝Ｋｓ）。したがって、キーを含むＯＯＢデータは、１２８で示されるように、それぞれＫｍおよびＫｓとＯＯＢペアリングを開始するためにピアデバイスのそれぞれに与えられる。
【００５７】
図９に関連して説明される、本発明の例示的な実施形態によるＯＯＢキー生成は、多くの利点を実現する。第１に、ＯＯＢキー生成方法を使用することで、中間者攻撃と盗聴が防止される。第二に、ＩＯ機能が不要であるため、認証データを入力するためのキーパッドおよび／またはディスプレイを必要としない、簡素化された低コストのＩＤＤ１２またはその他の医療デバイスが可能になる。したがって、どちらのピアデバイスでも、ＩＯ機能なしにＢＬＥの最も安全なペアリングオプション（すなわち、ＯＯＢペアリング）が実現される。本発明の例示的な実施形態に従って本明細書で説明するＯＯＢキー生成はまた、ＯＯＢキー生成アルゴリズムが動的および静的入力の両方に基づいており、したがってブルートフォース計算の難易度を高めるため、ブルートフォース計算を防止する。
【００５８】
本開示は、その適用において、以下の説明に記載されるかまたは図面に示される構成の詳細およびコンポーネントの配置に限定されないことを当業者は理解するであろう。本明細書の実施形態は、他の実施形態が可能であり、様々な方法で実施または実行することができる。また、本明細書で使用される語法および用語は説明を目的とするものであり、限定と見なされるべきではないことも理解されよう。本明細書における「含む」、「含む」または「有する」およびその変形の使用は、以降に記載される項目およびその同等物ならびに追加の項目を包含することを意味する。他に制限されない限り、本明細書の「接続される」、「結合される」、および「搭載される」という用語およびその変形は広く使用され、直接および間接の接続、結合、および搭載を包含する。さらに、「接続された」および「結合された」という用語、およびその変形は、物理的または機械的な接続または結合に限定されない。さらに、上に（ｕｐ）、下に（ｄｏｗｎ）、下部（ｂｏｔｔｏｍ）、上部（ｔｏｐ）などの用語は相対的であり、説明を助けるために使用されているが、限定するものではない。
【００５９】
本発明の例示された実施形態に従って使用される例示的なデバイス、システム、および方法のコンポーネントは、少なくとも部分的に、デジタル電子回路、アナログ電子回路、またはコンピュータハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせにおいて実装することができる。これらのコンポーネントは、プログラム可能なプロセッサ、コンピュータ、または複数のコンピュータなどのデータ処理装置による実行のために、またはこれらの動作を制御するために、例えば、情報担体、または機械可読記憶装置に具体的に具体化されたコンピュータプログラム、プログラムコード、またはコンピュータ命令などのコンピュータプログラム製品として実装される。
【００６０】
コンピュータプログラムは、コンパイルされたまたは解釈された言語を含む任意の形式のプログラミング言語で記述することができ、それはスタンドアロンプログラムとして、またはモジュール、コンポーネント、サブルーチン、またはコンピューティング環境における使用に適している他のユニットとして、任意の形式で実施することができる。コンピュータプログラムは、１つのコンピュータまたは１つのサイトの複数のコンピュータで実行するように活用することも、複数のサイトに分散して通信ネットワークで相互接続するように活用することもできる。また、本発明の例示的な実施形態を達成するための機能的プログラム、コード、およびコードセグメントは、本発明が関係するプログラマーの当業者によって本発明の範囲内であると容易に解釈され得る。本発明の例示的な実施形態に関連する方法ステップは、機能を実行するためにコンピュータプログラム、コード、または命令を実行する１つ以上のプログラム可能なプロセッサによって実行され得る（例えば、入力データの操作および／または出力の生成によって）。方法のステップはまた、例えばＦＰＧＡ（フィールドプログラマブルゲートアレイ）またはＡＳＩＣ（特定用途向け集積回路）などの専用ロジック回路によって実施することができ、本発明の例示的な実施形態の装置は、上記の専用ロジック回路として実装することができる。
【００６１】
本明細書に開示され実施形態に関連して説明される様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、ＡＳＩＣ、ＦＰＧＡまたは他のプログラマブルロジックデバイス、個別のゲートまたはトランジスタロジック、個別のハードウェアコンポーネント、または本明細書で説明する機能を実行するように設計されたそれらの任意の組み合わせで実装または実行され得る。汎用プロセッサはマイクロプロセッサでもよいが、代わりに、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンでもよい。プロセッサは、コンピューティングデバイスの組み合わせ、例えばＤＳＰとマイクロプロセッサの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアと組み合わせた１つ以上のマイクロプロセッサ、または他のそのような構成として実装することもできる。
【００６２】
コンピュータプログラムの実行に適したプロセッサは、例として、汎用マイクロプロセッサおよび専用マイクロプロセッサの両方、および任意の種類のデジタルコンピュータの任意の１つ以上のプロセッサを含む。一般に、プロセッサは、読み取り専用メモリもしくはランダムアクセスメモリ、またはその両方から命令およびデータを受け取る。コンピュータの重要な要素は、命令を実行するプロセッサ、ならびに命令およびデータを記憶する１つ以上のメモリデバイスである。一般に、コンピュータはまた、データを記憶するための１つ以上の大容量記憶装置（例えば、磁気、光磁気ディスクまたは光ディスク）を含むか、データを受信もしくは転送またはその両方を行うように動作可能に結合される。コンピュータプログラムの命令およびデータを具体化するのに適した情報担体には、例として、半導体メモリデバイス、例えば電気的にプログラム可能な読み取り専用メモリまたはＲＯＭ（ＥＰＲＯＭ）、電気的に消去可能なプログラム可能ＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリデバイス、データストレージディスク（例えば、磁気ディスク、内蔵ハードディスク、リムーバブルディスク、光磁気ディスク、ＣＤ−ＲＯＭおよびＤＶＤ−ＲＯＭディスク）を含む、あらゆる形態の不揮発性メモリが含まれる。プロセッサおよびメモリは、特殊用途ロジック回路で補完するか、または組み込むことができる。
【００６３】
当業者は、情報および信号が、様々な異なる技術および技法のいずれかを使用して表現され得ることを理解するであろう。例えば、上記の説明全体で参照されるデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場または粒子、光学場または粒子、またはそれらの任意の組み合わせで表現され得る。
【００６４】
上記の説明および図は、例としてのみ意図されており、添付の特許請求の範囲に記載されている場合を除き、いかなる方法でも本発明を限定することを意図していない。当業者は、上述した様々な例示的な実施形態の様々な要素の様々な技術的態様を、他の多くの方法で容易に組み合わせることができ、それらはすべて本発明の範囲内であると考えられることに特に留意されたい。
【図１】
2020522162.tif 000003
【図２Ａ】
2020522162.tif 000004
【図２Ｂ】
2020522162.tif 000005
【図３】
2020522162.tif 000006
【図４】
2020522162.tif 000007
【図５】
2020522162.tif 000008
【図６】
2020522162.tif 000009
【図７】
2020522162.tif 000010
【図７Ａ】
2020522162.tif 000011
【図７Ｂ】
2020522162.tif 000012
【図８】
2020522162.tif 000013
【図８Ａ】
2020522162.tif 000014
【図８Ｂ】
2020522162.tif 000015
【図９】
2020522162.tif 000016
【国際調査報告】
2020522162.tif 000017