特表 2023-538809 医療用モニタリングシステムにおけるセキュア通信

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2023-09-12

(54)【発明の名称】医療用モニタリングシステムにおけるセキュア通信

(51)【国際特許分類】

   H04L 9/36 20060101AFI20230905BHJP

   H04L 9/32 20060101ALI20230905BHJP

   H04L 9/14 20060101ALI20230905BHJP

【ＦＩ】

H04L9/36

H04L9/32 200E

H04L9/14

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023502952

(86)(22)【出願日】2021-08-31

(85)【翻訳文提出日】2023-01-16

(86)【国際出願番号】 US2021048512

(87)【国際公開番号】W WO2022047411

(87)【国際公開日】2022-03-03

(31)【優先権主張番号】63/072,647

(32)【優先日】2020-08-31

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＢＬＵＥＴＯＯＴＨ

(71)【出願人】

【識別番号】500211047

【氏名又は名称】アボット ダイアベティス ケア インコーポレイテッド

【氏名又は名称原語表記】ＡＢＢＯＴＴ ＤＩＡＢＥＴＥＳ ＣＡＲＥ ＩＮＣ．

(74)【代理人】

【識別番号】100094569

【弁理士】

【氏名又は名称】田中 伸一郎

(74)【代理人】

【識別番号】100103610

【弁理士】

【氏名又は名称】▲吉▼田 和彦

(74)【代理人】

【識別番号】100109070

【弁理士】

【氏名又は名称】須田 洋之

(74)【代理人】

【識別番号】100067013

【弁理士】

【氏名又は名称】大塚 文昭

(74)【代理人】

【識別番号】100109335

【弁理士】

【氏名又は名称】上杉 浩

(74)【代理人】

【識別番号】100120525

【弁理士】

【氏名又は名称】近藤 直樹

(74)【代理人】

【識別番号】100139712

【弁理士】

【氏名又は名称】那須 威夫

(74)【代理人】

【識別番号】100122563

【弁理士】

【氏名又は名称】越柴 絵里

(72)【発明者】

【氏名】フア シュアンドン

(72)【発明者】

【氏名】リーノ カート イー

(72)【発明者】

【氏名】リー トニー エス

(72)【発明者】

【氏名】オウ－ウィング ケヴィン エム

(72)【発明者】

【氏名】チャン ダニー

(72)【発明者】

【氏名】フアン ヴィクター パイシ

(57)【要約】

一実施形態において、医療センサとコンピュータデバイスとの間のセキュアな通信のための方法は、医療センサによって、コンピュータデバイスから認証要求を受信するステップを含む。本方法は、認証要求において提供された値に基づいて、コンピュータデバイスのためのチャレンジレスポンスメッセージを生成するステップを含む。本方法は、コンピュータデバイスから、応答したチャレンジレスポンスメッセージを受信するステップを含む。本方法は、応答したチャレンジレスポンスメッセージが期待値を含み且つ期待フォーマットに対応することを検証するステップを含む。本方法は、応答したチャレンジレスポンスメッセージを検証するステップに応答して、センサシークレット値をコンピュータデバイスに送信するステップを含む。
【選択図】 図１

【特許請求の範囲】

【請求項1】

医療センサとコンピュータデバイスとの間のセキュアな通信のための方法であって、
前記医療センサによって、前記コンピュータデバイスから認証要求を受信するステップと、
前記認証要求において提供された値に基づいて、前記コンピュータデバイスのためのチャレンジレスポンスメッセージを生成するステップと、
前記コンピュータデバイスから、応答したチャレンジレスポンスメッセージを受信するステップと、
前記応答したチャレンジレスポンスメッセージが期待値を含み且つ期待フォーマットに対応することを検証するステップと、
前記応答したチャレンジレスポンスメッセージを検証するステップに応答して、センサシークレット値を前記コンピュータデバイスに送信するステップと、
を含む、方法。

【請求項2】

前記センサシークレット値は、前記医療センサに固有のデータと、１又は２以上のランダム値とを含む、請求項１に記載の方法。

【請求項3】

前記１又は２以上のランダム値は、前記医療センサに提供された予め定義された値、医療センサの通信モジュールによって生成された値、又はユーザインタラクションに応答して生成された値に基づくものである、請求項２に記載の方法。

【請求項4】

前記医療センサによって、患者からセンサ情報を収集するステップと、
前記センサシークレット値から導出される暗号鍵を使用して、前記センサ情報を暗号化するステップと、
を更に含む、請求項１～３の何れかに記載の方法。

【請求項5】

前記暗号化されたセンサ情報を、近距離通信プロトコルを使用して前記コンピュータデバイスに送信するステップを更に含む、請求項４に記載の方法。

【請求項6】

前記センサ情報は、前記患者に関する医療データを含む、請求項４又は５に記載の方法。

【請求項7】

前記医療データは、体温、心拍数、血糖値、又は動作の測定値を含む、請求項６に記載の方法。

【請求項8】

前記センサ情報を暗号化するステップは、前記暗号鍵に基づく電力効率の良いストリーム暗号又はブロック暗号で前記センサ情報を符号化することを含む、請求項４から７の何れかに記載の方法。

【請求項9】

前記医療センサによって、近距離通信プロトコルを介して前記コンピュータデバイスからアクティベーション信号を受信するステップと、
前記アクティベーション信号に応答して、前記コンピュータデバイスに関連付けられた１又は２以上の認証値を検証するステップと、
前記コンピュータデバイスに関連付けられた前記認証値を正常に検証すると、前記医療センサによって患者からセンサ情報を収集するステップと、
を更に含む、請求項１～８の何れかに記載の方法。

【請求項10】

前記アクティベーション信号は更に、前記医療センサの通信モジュールのうちの１又は２以上に無線電力を供給する、請求項９に記載の方法。

【請求項11】

前記医療センサは、前記近距離通信プロトコルを介して受信した情報を使用して、前記患者からの追加の検証を必要とせずに、第２の近距離通信プロトコルを介して前記コンピュータデバイスとの接続を確立する、請求項９に記載の方法。

【請求項12】

前記近距離通信プロトコルは近距離通信を含み、前記第２の近距離通信プロトコルはＢｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙを含む、請求項１１に記載の方法。

【請求項13】

方法であって、
第１のコンピュータデバイスによって、医療センサからセンサシークレット値を受信するステップと、
前記第１のコンピュータデバイスによって、前記医療センサから、前記センサシークレット値から導出される第１の鍵に基づいて暗号化されていない医療測定値に対する第１の暗号化操作を使用して作成された暗号化された医療測定値のセットを受け取るステップであって、前記第１の暗号化操作は、暗号化されていない医療データに対して加算－回転－ＸＯＲ演算を実施することを含む、ステップと、
前記第１のコンピュータデバイスによって、前記センサシークレット値に基づいて前記第１の鍵を導出するステップと；
前記第１のコンピュータデバイスによって、前記第１の暗号化操作により導出された前記第１の鍵を用いて、前記医療測定値のセットを復号化するステップと、
を含む、方法。

【請求項14】

前記加算－回転－ＸＯＲ演算は、
前記暗号化されていない医療測定値を一連のデータブロックにセグメント化するステップと、
前記各データブロックを２以上のワードにセグメント化するステップと、
前記各データブロックについて、
前記データブロックの前記２以上のワードのうちの第１のワードのビットを第１の固定量だけ回転させるステップと、
前記データブロックの前記２以上のワードのうちの第２のワードを追加するステップと、
前記第１のワードへの前記第１の鍵のビット単位のＸＯＲ演算を実施するステップと、
前記第２のワードのビットを第２の固定量だけ回転させるステップと、
前記第２のワードへの前記第１のワードのビット単位のＸＯＲ演算を実施するステップと、
を含む、請求項１３に記載の方法。

【請求項15】

第２の鍵及び第２の暗号関数を用いて前記復号された医療測定値を暗号化するステップとであって、前記第２の鍵は、前記第１のコンピュータデバイスに固有の情報と前記第１のコンピュータデバイスによって生成されたランダム値とを含む、ステップと、
前記暗号化された医療測定値を第２のコンピュータデバイスに送信するステップと、
を更に含む、請求項１３又は１４に記載の方法。

【請求項16】

前記第２の暗号関数は、前記第１の暗号関数と異なり、前記第１の暗号関数よりも計算が複雑な暗号関数である、請求項１５に記載の方法。

【請求項17】

前記暗号化された医療測定値は、有線又は無線通信を介して前記第２のコンピュータデバイスに送信される、請求項１５又は１６に記載の方法。

【請求項18】

前記暗号化された医療測定値は、パケットレベル符号化コンピュータプロトコルを使用して送信される、請求項１５～１７の何れかに記載の方法。

【請求項19】

前記第２のコンピュータデバイスによって、前記暗号化された医療測定値を復号化するステップと、
第３の鍵に基づいて第３の暗号関数で前記医療測定値を暗号化した後に、前記復号された医療測定値を第３のコンピュータデバイスに送信するステップであって、前記第１の鍵、前記第２の鍵、及び前記第３の鍵は全て異なり且つ全て異なるルート値から導出され、前記第１の暗号関数、前記第２の暗号関数、及び前記第３の暗号関数が全て異なる、ステップと、
を含む、請求項１５～１８の何れかに記載の方法。

【請求項20】

前記センサシークレット値は、前記医療センサに関連付けられた固有値と、前記医療センサによって生成されるランダム値とを含む、請求項１３～１９の何れかに記載の方法。

【請求項21】

医療センサとコンピュータデバイスとの間のセキュアな通信のための方法であって、
前記医療センサによって、近距離通信プロトコルを介して前記コンピュータデバイスからアクティベーション信号を受信するステップと、
前記アクティベーション信号に応答して、前記コンピュータデバイスに関連付けられた１又は２以上の認証値を検証するステップと、
前記コンピュータデバイスに関連付けられた認証値を正常に検証すると、前記医療センサによって患者からセンサ情報を収集するステップと、
を含む、方法。

【請求項22】

前記アクティベーション信号は更に、前記医療センサの１又は２以上の通信モジュールに無線電力を供給する、請求項２１に記載の方法。

【請求項23】

前記医療センサは、前記近距離通信プロトコルを介して受信した情報を使用して、前記患者からの追加の検証を必要とせずに、第２の近距離通信プロトコルを介して前記コンピュータデバイスとの接続を確立する、請求項２１に記載の方法。

【請求項24】

前記近距離通信プロトコルは近距離通信を含み、前記第２の近距離通信プロトコルはＢｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙを含む、請求項２３に記載の方法。

【請求項25】

コンピュータデバイスとのセキュアな通信を提供するように配置された医療センサであって、
前記コンピュータデバイスから認証要求を受信する手段と、
認証要求において提供された値に基づいて、前記コンピュータデバイスのためのチャレンジレスポンスメッセージを生成する手段と、
前記コンピュータデバイスから、応答したチャレンジレスポンスメッセージを受信する手段と、
前記応答したチャレンジレスポンスメッセージが期待値を含み且つ期待フォーマットに対応することを検証する手段と、
前記応答したチャレンジレスポンスメッセージを検証することに応答して、センサシークレット値を前記コンピュータデバイスに送信する手段と、
を備える、医療センサ。

【請求項26】

請求項２～１２の何れかに記載の方法を実施する手段を更に備える、請求項２５に記載の医療センサ。

【請求項27】

第１のコンピュータデバイスであって、
医療センサからセンサシークレット値を受信する手段と、
前記医療センサから、前記センサシークレット値から導出される第１の鍵に基づいて、暗号化されていない医療測定値に対する第１の暗号化操作を使用して作成された暗号化された医療測定値のセットを受信する手段であって、前記第１の暗号化操作は、暗号化されていない医療データに対して加算－回転－ＸＯＲ演算を実施することを含む、手段と、
前記センサシークレット値に基づいて前記第１の鍵を導出する手段と、
前記第１の暗号化操作により導出された前記第１の鍵を用いて、前記医療測定値のセットを復号化する手段と、
を備える、第１のコンピュータデバイス。

【請求項28】

請求項１４～２０の何れかに記載の方法を実施する手段を更に備える、請求項２７に記載の第１のコンピュータデバイス。

【請求項29】

コンピュータデバイスとのセキュアな通信を提供するように配置された医療センサであって、
近距離通信プロトコルを介して前記コンピュータデバイスからアクティベーション信号を受信する手段と、
前記アクティベーション信号に応答して、前記コンピュータデバイスに関連付けられた１又は２以上の認証値を検証する手段と、
前記コンピュータデバイスに関連付けられた認証値を正常に検証すると、患者からセンサ情報を収集する手段と、
を備える、医療センサ。

【請求項30】

請求項２２～２４の何れかに記載の方法を実施する手段を更に備える、請求項２９に記載の医療センサ。

【請求項31】

コンピュータデバイス又は医療センサによって実行されたとき、前記コンピュータデバイス又は前記医療センサに請求項１～２０の何れかに記載の方法のステップを実行させる命令を含むコンピュータプログラム、コンピュータプログラム製品、又はコンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

（優先権）
本出願は、米国特許法１１９条（ｅ）に基づき、２０２０年８月３１日に出願された米国仮特許出願第６３／０７２，６４７号の利益を主張し、当該仮出願は、引用により本明細書に組み込まれる。

【0002】

（技術分野）
開示された主題は、計算能力又はリソースが少ない医療デバイスと、限定ではないがパーソナルコンピュータデバイス、インタフェースデバイス、リモートサーバ、又は他の医療デバイスを含む他のデバイスとの間のデータのセキュアな交換に関する。

【背景技術】

【0003】

特定の医療デバイスは、他のコンピュータデバイスとの間でデータを無線で送受信することができる。これらの医療デバイスの一部は、強力なプロセッサを備え、無停電電源を使用して動作するが、他の医療デバイスは、僅かな電力で効率的に動作するように設計されている。低消費電力の医療デバイスはまた、これらの医療デバイスが通信している相手のデバイスよりも計算能力又はリソースが低いことがある。場合によっては、低消費電力デバイスは、例えば患者の個人的な医療情報を含む機密データを送受信する可能性がある。例えば、暗号化又は復号化プロセスを実行する低電力医療デバイスの低い能力を含むことができる、このような低電力医療デバイスに特有の少ない計算能力又はリソースを使用して、機密データを傍受及び改竄から保護することが難しい可能性がある。

【0004】

アクティブ医療センサは、無線通信機能を組み込むことができる医療デバイスの一例である。医療センサは、ユーザに関するプライベートな医療情報を収集することができる。医療センサは、データを収集した後、データ収集及び分析のため医療情報をより強力なデバイスに転送することができる。このような特徴は、医療用デバイスが他のコンピュータデバイスとデータを通信することを含むことができる。加えて又は代替的に、幾つかのセンサは、患者から取り外した後又は患者に接続されたままの状態で、データ転送を促進するために他のデバイスと物理的に接続することができ、これにより患者の自由な移動を制限することが可能である。無線通信は、他のデバイスとの物理的な接続を伴わない通信を可能にするため、より好都合とすることができる。このようなデータ通信の課題は、サードパーティーによる傍受を防止することである。関連の医療デバイスの場合、データのセキュリティが望ましいとすることができ、ここで傍受されたデータは、患者の健康状態や病歴及び他の機密情報を含む可能性がある。更に、傍受されたデータ又はデバイスの動作の改竄又は他の変更により、誤った医療情報がユーザに提供されることにつながる可能性がある。

【0005】

医療センサは、使い捨てで低コストであるように設計することができ、このような医療センサは、他のデバイスと比較して、無線通信を保護するためのデータセキュリティアルゴリズムを実行する際の電力又は計算能力が低い可能性がある。従って、セキュアな無線通信を提供し、このような医療デバイスから他のデバイスへのデータの転送を容易にするために、計算能力又はリソースが少ない低電力医療デバイスによって実施できる方法及びシステムに対する機会が存在する。

【発明の概要】

【0006】

開示された主題の目的及び利点は、開示された主題の実施によって習得されるのと同様に、以下の説明に記載されこれから明らかになるであろう。開示された主題の追加の利点は、本明細書及び特許請求の範囲において特に指摘された方法及びシステムによって、並びに図面から実現及び達成されるであろう。

【0007】

これらの利点及び他の利点を達成するため、開示された主題の目的によれば、具現化され広範囲に記載されるように、開示された主題は、医療センサによって使用するためのセキュアな通信プロトコルのためのシステム及び方法を含む。例示的な方法は、医療センサによってコンピュータデバイスからアクティベーション信号を受信するステップを含むことができる。医療センサは、アクティベーション信号に応答して、コンピュータデバイスに関連付けられた１又は２以上の認証値を検証することができる。正常な認証に応答して、医療センサは、患者からセンサ情報を収集し始めることができる。本明細書で具現化されるように、センサ情報は、患者に関する医療データを含むことができる。本明細書で具現化されるように、医療センサは、医療センサの１又は２以上の通信モジュールに無線電力を供給することができる近距離通信プロトコルを介してアクティベーション信号を受信することができる。本明細書に具現化されるように、医療センサは、近距離通信プロトコルを介して受信した情報を使用して、限定ではないが患者を含むユーザからの追加の検証を必要とせずに、第２の近距離通信プロトコルを介してコンピュータデバイスとの接続を確立することが可能である。本明細書で具現化されるように、近距離通信プロトコルは、近距離通信（ＮＦＣ）を含むことができ、第２の近距離通信は、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ（ＢＬＥ）を含むことができる。本明細書で具現化されるように、医療センサは、コンピュータデバイスよりも強力でない計算リソースを含むことができる。

【0008】

開示された主題の他の態様によれば、システム及び方法は、医療センサによって、コンピュータデバイスから認証要求を受信するステップを含むことができる。医療センサは、認証要求に含まれる情報を使用して、コンピュータデバイスのためのチャレンジレスポンスメッセージを生成することができる。医療センサは、応答したチャレンジレスポンスメッセージをコンピュータデバイスから受信し、更に、応答したチャレンジレスポンスメッセージが期待フォーマット及び値に対応することを検証することができる。医療センサは、その後、センサシークレットをコンピュータデバイスに送信することができる。本明細書で具現化されるように、センサシークレットは、医療センサに固有のデータ及びランダム値を含むことができる。本明細書で具現化されるように、ランダム値は、センサに提供される予め定義された値、医療センサの通信モジュールによって生成される値、又はユーザインタラクションに応答して生成される値に基づくことができる。医療センサは、第１の暗号関数を用いてセンサシークレットから導出された暗号鍵を用いて１又は２以上の医療測定値を暗号化し、暗号化された医療測定値をコンピュータデバイスに送信することができる。本明細書で具現化されるように、暗号鍵は、特殊な低電力ストリーム暗号又はブロック暗号と共に使用することができる。第１の暗号関数は、医療測定値に対して加算－回転－ＸＯＲ操作を実行することを含むことができる。本明細書で具現化されるように、加算－回転－ＸＯＲ演算は、暗号化されていない医療測定値を一連のデータブロックにセグメント化するステップと、各データブロックを２以上のワードにセグメント化するステップと、各データブロックに対して一連の追加の操作を実施するステップとを含むことができる。追加操作は、ブロックの２以上のワードのうちの第１のワードのビットを第１の固定量だけ回転させるステップと、ブロックの２以上のワードのうちの第２のワードを追加するステップと、第１のワードへの第１の鍵のビット単位のＸＯＲ演算を実施するステップと、第２のワードのビットを第２の固定量だけ回転させるステップと、第２のワードへの第１のワードのビット単位のＸＯＲ演算を実施するステップと、を含むことができる。本明細書で具現化されるように、医療測定値は、体温、心拍数、血糖値、動作、及び他の医療測定値を含むことができる。

【0009】

開示された主題の他の態様によれば、システム及び方法は、医療センサから第１のコンピュータデバイスによって、センサシークレット及び第１の暗号化アルゴリズムから導出される第１の鍵を使用して暗号化された医療測定値のセットを受信するステップを含むことができる。第１の暗号化アルゴリズムは、医療測定値に対して加算－回転－ＸＯＲ演算を実施するステップを含むことができる。センサシークレットは、医療センサに関連付けられた固有値及び医療センサによって生成されるランダム値を含むことができる。本方法は、コンピュータデバイスによって、センサシークレットに基づいて第１の鍵を導出するステップを含むことができる。本方法は、導出された第１の鍵を用いて、コンピュータデバイスによって、医療測定値のセットを復号化するステップを含むことができる。本方法は、第２の鍵及び第２の暗号化アルゴリズムを使用して、復号された医療測定値を暗号化するステップを含むことができる。第２の鍵は、コンピュータデバイスに固有の情報及びコンピュータデバイスによって生成されたランダム値を含むことができる。第２の暗号化アルゴリズムは、異なるものとすることができ、本明細書で具現化するように、第１の暗号化アルゴリズムよりも計算が複雑な暗号化アルゴリズムとすることができる。本方法は、暗号化された医療測定値を第２のコンピュータデバイスに送信するステップを含むことができる。本明細書で具現化されるように、暗号化された医療測定値は、有線又は無線通信を介して第２のコンピュータデバイスに送信することができる。暗号化された医療測定値は、パケットレベル符号化コンピュータプロトコルを使用して送信することができる。本明細書で具現化されるように、本方法は、第２のコンピュータデバイスが暗号化医学測定値を復号し、第３の鍵及び第３の暗号化アルゴリズムで医学測定値を暗号化した後、第３のコンピュータデバイスに伝送するステップを含むことができ、ここで、第１の鍵、第２の鍵、及び第３の鍵が全て異なり、異なるルート値から導出され、第１の暗号化アルゴリズム、第２の暗号化アルゴリズム、及び第３の暗号化アルゴリズムが全て異なる。本明細書で具現化されるように、医療センサは、第１のコンピュータデバイスよりも強力でない計算リソースを含むことができる。第１のコンピュータデバイスは、第２のコンピュータデバイスよりも強力でない計算リソースを含むことができる。

【0010】

上述の一般的な説明と以下の詳細な説明の両方は例示的なものであり、開示された主題の更なる説明を提供することを意図していることを理解されたい。

【0011】

本明細書に組み込まれ、本明細書の一部を構成する添付の図面は、開示された主題の方法及びシステムを例示し、更なる理解を提供するために含まれるものである。説明と共に、図面は、開示された主題の原理を説明する。

【0012】

本明細書に記載された主題の詳細は、その構造及び動作の両方に関して、同様の参照数字が同様の部品を指す添付図面を調べることによって明らかになることができる。

【図面の簡単な説明】

【0013】

【図1】本明細書に記載された技術を具現化することができる例示的な低電力医療モニタリングシステムの動作環境を示す図である。

【図2】開示された主題の例示的な実施形態による例示的なセンサを示すブロック図である。

【図3】開示された主題の例示的な実施形態による、センサと通信するための例示的な専用データ受信デバイスを示すブロック図である。

【図4】開示された主題の例示的な実施形態によるメッセージペイロードの例示的な構造を示す図である。

【図5】低電力医療モニタリングシステムの例示的な動作フロー及びデータライフサイクルを示す図である。

【図6】開示された主題によるメッセージング応答状態マシンの例を示す図である。

【図7A】開示された主題による相互認証スキームの例を説明する図である。

【図7B】開示された主題による相互認証スキームの例を説明する図である。

【図7C】開示された主題による相互認証スキームの例を説明する図である。

【図7D】開示された主題による相互認証スキームの例を説明する図である。

【図8】開示された主題による２つのデバイス間のデータのセキュアな交換のための例示的なデータフローを示す図である。

【図9】開示された主題による２つのデバイス間のデータのセキュアな交換のための例示的なデータフローを示す図である。

【発明を実施するための形態】

【0014】

ここで、その１つ又はそれ以上の実施例が添付図面に例示されている本開示の実施形態について詳細に説明する。開示された主題の構造及び対応する動作方法は、システムの詳細な説明と合わせて説明する。

【0015】

本明細書に提示されたシステム及び方法は、医療モニタリングシステムにおけるセキュアな通信のために使用することができる。開示された主題の例示として、限定ではないが、本明細書では、医療センサなどの医療デバイスを使用するセキュア通信を参照する。本明細書で使用される場合、「医療センサ」は、例示の目的であって限定ではないが、体温センサ、血圧センサ、脈拍又は心拍センサ、グルコースレベルセンサ、分析物センサ、身体活動センサ、体動センサ、又は医療目的に有用な他の任意のセンサなど、医療目的に有用なユーザからセンサ情報を受信できる任意のデバイスを指すことができる。開示された主題の目的及び利点は、以下の説明に記載されこれから明らかになるであろう。開示された主題の追加の利点は、添付図面からと同様に、本明細書及び請求項において特に指摘される方法、装置、及びデバイスによって実現及び達成されることになる。

【0016】

一実施形態では、医療センサとコンピュータデバイスとの間のセキュア通信のための方法は、医療センサによって、コンピュータデバイスから認証要求を受信するステップを含む。本方法は、認証要求において提供された値に基づいて、コンピュータデバイスのためのチャレンジレスポンスメッセージを生成するステップを含む。本方法は、コンピュータデバイスから、応答したチャレンジレスポンスメッセージを受信するステップを含む。本方法は、応答したチャレンジレスポンスメッセージが期待値を含み、期待フォーマットに対応することを検証するステップを含む。本方法は、応答するチャレンジレスポンスメッセージを検証することに応答して、センサシークレット値をコンピュータデバイスに送信するステップを含む。

【0017】

開示された主題によれば、限定ではなく例示の目的で、医療センサとコンピュータデバイスとの間のセキュアな通信のための方法。例示的な方法は、医療センサによってコンピュータデバイスからアクティベーション信号を受信するステップを含むことができる。医療センサは、アクティベーション信号に応答して、コンピュータデバイスに関連付けられた１又は２以上の認証値を検証することができる。正常な認証に応答して、医療センサは、患者からセンサ情報を収集し始めることができる。本明細書で具現化されるように、センサ情報は、患者に関する医療データを含むことができる。本明細書で具現化されるように、医療センサは、医療センサの１又は２以上の通信モジュールに無線電力を供給することができる近距離通信プロトコルを介してアクティベーション信号を受信することができる。本明細書に具現化されるように、医療センサは、近距離通信プロトコルを介して受信した情報を使用して、患者に限定されないユーザからの追加の検証を必要とせずに、第２の近距離通信プロトコルを介してコンピュータデバイスとの接続を確立することが可能である。本明細書で具現化されるように、近距離通信プロトコルは、近距離通信（ＮＦＣ）を含むことができ、第２の近距離通信は、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ（ＢＬＥ）を含むことができる。本明細書で具現化されるように、医療センサは、コンピュータデバイスよりも強力でない計算リソースを含むことができる。

【0018】

開示された主題の他の態様によれば、システム及び方法は、医療センサによって、コンピュータデバイスから認証要求を受信するステップを含むことができる。医療センサは、認証要求に含まれる情報を使用して、コンピュータデバイスのためのチャレンジレスポンスメッセージを生成することができる。本明細書で具現化されるように、チャレンジレスポンスメッセージは、合意された暗号化スキームに従って暗号化することができる。医療センサは、応答したチャレンジレスポンスメッセージをコンピュータデバイスから受信することができ、応答したチャレンジレスポンスメッセージが期待フォーマット及び値に対応することを更に検証することができる。医療センサは、その後、センサシークレットをコンピュータデバイスに送信することができる。センサシークレットは、合意された暗号化スキームに従って暗号化されることも可能である。本明細書で具現化されるように、センサシークレットは、医療センサに固有のデータ及びランダム値を含むことができる。本明細書で具現化されるように、ランダム値は、センサに提供される予め定義された値、医療センサの通信モジュールによって生成される値、又はユーザインタラクションに応答して生成される値に基づいていることができる。医療センサは、センサシークレットから導出される暗号鍵を用いて１又は２以上の医療測定値を暗号化し、暗号化された医療測定値をコンピュータデバイスに送信することができる。本明細書で具現化されるように、暗号鍵は、特殊な低電力ストリーム暗号又はブロック暗号と共に使用することができる。本明細書で具現化されるように、医療測定値は、体温、心拍数、血糖値、動作、及び他の医療測定値を含むことができる。

【0019】

開示された主題の他の態様によれば、システム及び方法は、医療センサから第１のコンピュータデバイスによって、センサシークレット及び第１の暗号化アルゴリズムから導出される第１の鍵を使用して暗号化された医療測定値のセットを受信するステップを含むことができる。センサシークレットは、医療センサに関連付けられた固有値及び医療センサによって生成されたランダム値を含むことができる。本方法は、コンピュータデバイスによって、センサシークレットに基づいて第１の鍵を導出するステップを含むことができる。本方法は、導出された第１の鍵を用いて、コンピュータデバイスによって、医療測定値のセットを復号化するステップを含むことができる。本方法は、第２の鍵及び第２の暗号化アルゴリズムを使用して、復号された医療測定値を暗号化するステップを含むことができる。第２の鍵は、コンピュータデバイスに固有の情報及びコンピュータデバイスによって生成されたランダム値を含むことができる。第２の暗号化アルゴリズムは、異なるものとすることができ、本明細書で具現化するように、第１の暗号化アルゴリズムよりも計算上複雑な暗号化アルゴリズムとすることができる。本方法は、暗号化された医療測定値を第２のコンピュータデバイスに送信するステップを含むことができる。本明細書で具現化されるように、暗号化された医療測定値は、有線又は無線通信を介して第２のコンピュータデバイスに送信することができる。暗号化された医療測定値は、パケットレベル符号化コンピュータプロトコルを使用して送信することができる。本明細書で具現化されるように、本方法は、第３の鍵及び第３の暗号化アルゴリズムで医学測定値を暗号化した後、第２のコンピュータデバイスが暗号化医学測定値を復号し、第３のコンピュータデバイスに伝送するステップを含むことができ、ここで、第１の鍵、第２の鍵、及び第３の鍵が全て異なり、異なるルート値から導出され、第１の暗号化アルゴリズム、第２の暗号化アルゴリズム、及び第３の暗号化アルゴリズムが全て異なる。本明細書で具現化されるように、医療センサは、第１のコンピュータデバイスよりも強力でない計算リソースを含むことができる。第１のコンピュータデバイスは、第２のコンピュータデバイスよりも強力でない計算リソースを含むことができる。

【0020】

限定ではなく例示の目的で、図１に示されるような開示された主題と共に使用するための医療モニタリングシステム１００の例示的な実施形態が参照される。図１は、本明細書に記載された技術を具現化することができる低電力医療モニタリングシステム１００の動作環境を示す図である。低電力医療モニタリングシステム１００は、人間又は動物の身体に関する医療統計のモニタリングを提供するように設計された構成要素のシステムを含むことができ、又は様々な構成要素の構成に基づいて他の医療動作を提供することができる。例えば、低電力医療モニタリングシステム１００は、ユーザに連続的なグルコースモニタリングを提供することができ、又は薬物及び他の医薬品の送達を提供することができる。本明細書で具現化されるように、システムは、ユーザによって着用されるか、又は情報が収集される身体に取り付けられるセンサとも呼ばれる低電力医療デバイス１１０を含むことができる。本明細書で具現化するように、センサ１１０は、本明細書で更に論じるように、使いやすさを改善し、改竄のリスクを低減するために、密封された使い捨てデバイスとすることができる。低電力医療モニタリングシステム１００は、センサ１１０からの医療データを含むデータの取得及び配信を容易にするために、本明細書で説明するように構成された専用の読取デバイス１２０を更に含むことができる。本明細書で具現化されるように、低電力医療モニタリングシステム１００は、追加的又は代替的に、サードパーティーにライセンスされたソフトウェアライブラリ又はアプリケーションを含み、通信リンクを介してセンサ１１０と通信することができる携帯電話、タブレット、パーソナルコンピュータデバイス、又は他の同様のコンピュータデバイスなどの多目的ハードウェアデバイス１３０に組み込まれることができる。ソフトウェアライブラリを具現化し実行する多目的デバイス１３０は、センサ１１０と通信するためのデータ受信デバイスを形成すると言うことができる。本明細書で使用される場合、専用データ受信デバイス１２０は、低電力医療モニタリングシステム１００内のセンサ１１０と通信するために特別に製造されたハードウェアデバイスを指し、一方、多目的データ受信デバイス１３０は、ソフトウェアライブラリを組み込むか、アプリケーションを実行している適切に構成されたハードウェアデバイスを指す。本明細書で使用されるように、データ通信デバイスは、専用データ受信デバイス１２０又は多目的データ受信デバイス１３０を等しく指す。本明細書で論じたセキュリティアーキテクチャ及び設計原理は、低電力医療デバイス１１０、好適に構成された専用データ受信デバイス１２０又は多目的データ受信デバイス１３０、及び本明細書に記載したものと同様の他の構成要素を含む任意の適切に構成されたシステムに同様に適用できることを理解されたい。低電力医療デバイス１１０の役割は、低電力医療デバイス１１０に具現化される医療用ハードウェアの性質によって定義することができる。

【0021】

一般的に且つ高レベルでは、低電力医療モニタリングシステム１００は、様々な追加要素のうち、それぞれのデバイス識別子、デバイス及びその製造者によって維持される秘密鍵、及び真のランダム値に基づいて認証及び暗号鍵を生成するための最小計算多要素（ＭＣＭＦ）スキームをサポートする。この技術を使用すると、低電力医療モニタリングシステム１００の様々なデバイスは、認証及び計算機能を実行するために最小限の計算リソースを費やす。更に、ＭＣＭＦ方式は、低電力医療モニタリングシステムのどのデバイスも、インターネットなどの広域ネットワークにアクセスできることを必要としない。従って、本開示の技術は、データ処理負荷及び電力要件を実質的に増大させることなく、低電力医療コンピュータデバイス間のセキュアな通信を可能にする。更に、開示されたセキュリティアーキテクチャ及び操作は、構成要素低電力医療モニタリングシステムを計算するコストを低減するので、アーキテクチャは、特定の自動注射器、体内注射器、及びセンサなどの低コスト又は使い捨てが義務付けられているものを含む様々な医療デバイス（例えば、センサ１１０の代わりに）との使用に適することが可能である。本開示を通じて、低電力医療デバイス１１０は、簡略化のためにセンサと呼ばれることができる。

【0022】

本明細書で具現化されるように、センサ１１０は、所定のアクティブ使用寿命（例えば、１日、１４日、３０日など）を有する小型で個別にパッケージされた使い捨てデバイスを含むことができる。センサ１１０は、患者の身体の皮膚に適用され、センサ寿命の期間にわたって付着したままであることができる。本明細書で具現化されるように、センサ１１０は、選択的に除去され、再適用されたときに機能的なままであるように設計することができる。

【0023】

限定ではなく例示の目的で、図２に示すような開示された主題と共に使用するためのセンサ１１０の例示的な実施形態が参照される。図２は、本明細書に記載されたセキュリティアーキテクチャ及び通信スキームと互換性のある例示的な実施形態による例示的なセンサ１１０のブロック図である。本明細書で具現化されるように、センサ１１０は、通信モジュール２４０と通信可能に結合された特定用途向け集積回路（「ＡＳＩＣ」）２００を含むことができる。限定ではなく、例証として、例示的な通信モジュール２４０は、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ－Ｅｎｅｒｇｙ （「ＢＬＥ」） チップセット、近距離通信 （「ＮＦＣ」） チップセット、又はＩＥＥＥ ８０２．１５ プロトコルによるパーソナルエリアネットワーク、ＩＥＥＥ ８０２．１１ プロトコル、赤外線データ協会規格 （ＩｒＤＡ） による赤外線通信などのような、同様の近距離通信スキームと共に使用する他のチップセットなどを含むことができる。通信モジュール２４０は、専用データ受信デバイス１２０又は多目的データ受信デバイス１３０の同様の能力を有する通信モジュールとの相互作用を介して、データ及びコマンドの送受信を実施することができる。本明細書で具現化するように、特定の通信チップセットをＡＳＩＣ２００に埋め込むことができる（例えば、ＮＦＣアンテナのループ）。本明細書で具現化するように、センサ１１０が電力効率に優れ、低コストで、場合によっては使い捨てになるように設計されているので、ＡＳＩＣ２００は、マイクロコントローラコア２１０、オンボードメモリ２２０、及び記憶メモリ２３０を含むことができる。ストレージメモリ２３０は、本明細書に開示される認証及び暗号化セキュリティアーキテクチャにおいて使用されるデータを格納することができる。データは、本明細書の実施例に記載されているようなものを含む様々な要素及び用途を有することができる。ＡＳＩＣ２００は、オンボードバッテリなどの電力モジュール２５０から、又はＮＦＣパルスから電力を受け取ることができる。電力モジュール２５０は、比較的小さな電荷のみを保存することができる。本明細書で具現化されるように、センサ１１０は、所定の寿命を有し、広域ネットワーク通信能力を有しない使い捨てデバイスとすることができる。本明細書で具現化されるように、通信モジュール２４０は、バッテリ電力下で通信を提供することができる。本開示は、センサ１１０及びＡＳＩＣ２００の例示的な構成に関して説明されているが、他の好適な構成が想定される。一例として、センサ１１０の処理ハードウェアは、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの別のタイプの特殊目的プロセッサとして実装することができる。本明細書で具現化されるように、センサ１１０の処理ハードウェアは、センサ１１０の機能を実行するためにソフトウェアによって一時的に構成される汎用処理デバイス（例えば、ＣＰＵ）又は別のプログラマブルプロセッサを含むことができる。より一般的には、処理ハードウェア３０は、ハードウェア、ファームウェア、ソフトウェア、又はハードウェア、ファームウェア、及びソフトウェアの適切な組み合わせを用いて実装することができる。例示であって限定するものではないが、センサ１１０の処理ハードウェアは、計算能力、電力容量、メモリ容量、ネットワーク接続の利用可能性などを含む１又は２以上の要因によって定義することができる。

【0024】

その医療機能性を実行するために、センサ１００は、その機能に適した医療用ハードウェア２６０を更に含むことができる。本明細書で具現化されるように、医療用ハードウェア２６０は、例えば、薬物又は他の医薬品を自己投与するために患者に処方される自動注射器を含むことができる。従って、医療用ハードウェア２６０は、薬剤を皮下投与するために注射器の針又はプランジャを駆動する機構を含むことができる。注射器は、薬物で予め充填されることができ、トリガーイベントに応答して動作することができる。例えば、機構は、針を患者の中に駆動し、プランジャを前進させて、針を介して薬剤を皮下に送達することができる。

【0025】

本明細書で具現化されるように、低電力医療デバイス１１０は、患者の身体組織（例えば、皮膚、器官、筋肉など）に取り付け可能なオンボディ注射器として構成することができ、制御又は選択された時間期間にわたって固定又は患者が選択した量の薬剤の皮下注射を自動的に送達することが可能である。このような実施形態では、医療用ハードウェア２６０又は低電力医療デバイスは、例えば、医療用ハードウェア２６０を患者の身体組織に一時的に取り付けるための接着剤又は他の手段、薬剤又は医薬を格納するための一次容器、一次容器から薬剤を排出するためにプランジャを駆動するか又はその解放を可能にするように構成された駆動機構、トロカール（例えば、固体コア針）、トロカールの周りに配置された可撓性カニューレ、トロカール及び／又は可撓性カニューレを患者に挿入し、任意に可撓性カニューレを患者内に残してトロカールを引き込むように構成された挿入機構、デバイスの起動時に一次容器と可撓性カニューレとの間の流体連通を確立するように構成された流体経路コネクタ、並びにデバイスを起動するように構成された作動デバイス（例えば、ユーザ変位可能ボタン）である。本明細書で具現化されるように、体内注射器は、予め充填され、及び／又は予め装填されることが可能である。

【0026】

機械的構成要素に加えて、医療用ハードウェア２６０は、電気的及び／又は電子的構成要素を含むことができる。例えば、電子スイッチは、機構に結合することができる。低電力医療デバイス１１０は、認証された通信を確立し、暗号化された信号を受信し、本開示の技術を使用して信号を復号し、信号がスイッチを操作するコマンドを含むことを決定し、スイッチに針を駆動させることが可能である。従って、本明細書に具現化された低電力コンピュータデバイスは、リモートコマンドに応答して医療用ハードウェア２６０を使用して医療機能を実行するように構成することができる。

【0027】

本明細書で具現化されるように、医療用ハードウェア２６０は、針又はプランジャによって移動した距離を示すデジタル信号を生成するための移動センサとアナログ－デジタル変換器とを含むことができる。薬を送達する際に、低電力医療デバイス１１０は、センサから測定値を取得し、本開示の技術を使用して測定値を暗号化し、測定値を相手デバイス１４にセキュアに報告することができる。加えて、又は代替的に、低電力医療デバイス１１０は、医薬品が送達された時間、送達された医薬品の量、医薬品を送達する間に遭遇した任意の問題など、他の測定値又はパラメータを報告することが可能である。低電力医療デバイス１１０は、医療ハードウェア２６０の動作に関連付けられたデータを遠隔デバイスに提供するように構成することができる。

【0028】

本明細書で具現化されるように、低電力医療デバイス１１０は、専用データ受信デバイス１２０又は多目的データ受信デバイス１３０から暗号化データを受信するステップと、専用データ受信デバイス１２０又は多目的データ受信デバイス１３０に暗号化データを送信することの両方を実施するように構成することができる。医療用ハードウェア２６０は、１又は２以上の医療機能の任意の適切な組み合わせを実装するように構成され、１又は２以上の感知構成要素を含むことができる。このような感知構成要素は、低電力医療デバイス１１０の動作状態（例えば、未包装／投与準備完了、無菌バリア除去、患者の体組織との接触、カニューレ及び／又は針の挿入、薬物送達開始、操作部又はボタン変位、薬物送達完了、プランジャ位置、流路閉塞など）、低電力医療デバイス１１０又はそこに含まれる薬物の状態（例えば、温度、衝撃又は振動暴露、光暴露、薬剤色、薬剤濁度、薬剤粘度、地理的位置、空間的方向、時間情報、周囲気圧など）、及び／又は患者に関する生理情報（例えば、体温、血圧、脈又は心拍、グルコースレベル、身体活動又は動作、指紋検出など）を検出するように構成することができる。

【0029】

図１を更に参照すると、センサ１１０のＡＳＩＣ２００は、ストレージメモリ２３０内に保持されたデータを用いて認証鍵及び暗号鍵を動的に生成するように構成することができる。ＡＳＩＣ２００は、受信したデータを用いて認証手順（例えば、ハンドシェイク、相互認証など）を実行し、通信モジュール２４０を介して専用データ受信デバイス１２０又は多目的データ受信デバイス１３０に機密データを送信する前に、生成された鍵を機密データに適用するように更に構成することができる。生成された鍵は、センサ１１０に固有のもの、デバイスのペアに固有のもの（例えば、特定のセンサ－リーダーのペアに固有のもの）、センサ１１０と専用データ受信デバイス１２０との間の通信セッションに固有のもの、通信セッション中に送信されるメッセージに固有のもの、又はメッセージ内に含まれるデータのブロックに固有のものとすることができる。センサ１１０のＡＳＩＣ２００によって実装される技術は、本明細書においてより詳細に議論される。

【0030】

限定ではなく例示の目的で、図３に示すような開示された主題と共に使用するための専用データ受信デバイス１２０の例示的な実施形態が参照される。図３は、例示的な実施形態に関して本明細書で説明されるセキュリティ及びコンピュータアーキテクチャと互換性のある例示的な専用データ受信デバイス１２０を示す。本明細書で具現化されるように、専用データ受信デバイス１２０は、小型フォームファクタのデバイスを含むことができる。専用データ受信デバイス１２０は、任意選択で、センサ１１０ほどメモリ又は処理能力に制約を受けないことができ、本明細書に具現化されるように、専用データ受信デバイス１２０は、動作ソフトウェア記憶及びデータ記憶のための十分なメモリ、並びに本明細書に記載されるようにセンサ１１０と通信するためのソフトウェア実行のための十分なＲＡＭを含むことができる。図３に図示されるように、リーダー１３０は、マイクロコントローラ３１０、メモリ３２０、及びストレージ３３０を含むＡＳＩＣ３００を含み、通信モジュール３４０と通信可能に結合される。本明細書で具現化されるように、ＡＳＩＣ３００は、センサ１１０のＡＳＩＣ２００と同一にすることができる。代替的に、ＡＳＩＣ３００は、追加のコンピュータパワー及び機能を含むように構成することができる。専用データ受信デバイス１２０の構成要素のための電力は、電力モジュール３５０によって供給することができ、本明細書で具現化されるように、充電式電池を含むことができ、持続的な動作及び継続的な使用を可能にする。

【0031】

専用データ受信デバイス１２０は、センサ１１０と無線で結合し、又はセンサ１１０を走査し、そこからデータ、例えば、機密医療データを取得するように構成することができる。本明細書で具現化されるように、専用データ受信デバイス１２０は、センサ１１０の医療用ハードウェア２６０と同様の、又はそこから拡張された医療用ハードウェア３６０を更に含むことができる。限定ではなく、例証として、センサ１１０の医療用ハードウェア２６０が連続グルコースモニタリングのために構成される実施形態では、専用データ受信デバイス１２０の医療用ハードウェア３６０は、血糖試験ストリップとの使用のために互換性のある血糖計で構成することができ、従ってセンサ１１０の血糖モニタリングを拡大するものである。本明細書で具現化するように、専用データ受信デバイス１２０は、本明細書で説明するように、センサ１１０に関して、通信モジュール３４０の特定のモジュール（例えば、ＢＬＥモジュール３４１又はＮＦＣモジュール３４２）を介してＮＦＣスキャナ及びＢＬＥエンドポイントとして動作するように構成することができる。本明細書で具現化するように、専用データ受信デバイス１２０は、通信モジュール３４０のユニバーサルシリアルバス（ＵＳＢ）３４５を介してと通信するように構成することができる。本明細書で具現化するように、専用データ受信デバイス１２０の搭載ストレージ３３０は、センサ１１０から受信した医療データを長期間にわたって保存することが可能である。更に、本明細書で具現化するように、多目的データ受信デバイス１３０又はユーザコンピュータデバイス１４０は、広域ネットワークを介して遠隔クラウドサーバ１５０と通信するように構成することができる。本明細書で具現化するように、センサ１１０は、専用データ受信デバイス１２０又は多目的データ受信デバイス１３０に機密データを提供することができる。専用データ受信デバイス１２０は、敏感なデータをユーザコンピュータデバイス１４０に送信することができる。ユーザコンピュータデバイス１４０（又は多目的データ受信デバイス１３０）は、今度は、処理及び分析のために、そのデータをリモートクラウドサーバ１５０に送信することができる。クラウドサーバ１５０と通信する際に、多目的データ受信デバイス１３０及びユーザコンピュータデバイス１４０は、ユーザによって入力され、それぞれのデバイスに格納された認証クレデンシャルに従って、固有のユーザトークンを生成することができる。認証クレデンシャルは、リモートクラウドサーバ１５０へのセキュアな接続を確立するために使用することができ、更に、適宜、リムーブクラウドサーバ１５０に提供される任意の機密データを暗号化するために使用することができる。本明細書で具現化されるように、多目的データ受信デバイス１３０及びユーザコンピュータデバイス１４０は、任意選択で、処理能力の使用においてそれほど制限されないことができ、従って、標準のデータ暗号化及び送信技術は、リモートクラウドサーバ１５０に送信される際に使用することができる。

【0032】

データ受信デバイス（例えば、専用データ受信デバイス１２０又は多目的データ受信デバイス１３０）によるセンサ１１０の起動が成功すると、センサ１１０は、医療データを収集し、そのデータをデータ受信デバイスで利用できるように構成されることが可能である。一例として、データ受信デバイスは、ＮＦＣインタフェースを介してセンサ１１０とペアリングし、センサ１１０に近距離電力を提供し、前記ＮＦＣインタフェースを介してセンサ１１０と通信可能に結合することができる。別の例として、センサ１１０は、対応する通信モジュールを介してデータ受信デバイスと対になり、医療モニタリング及びアラーム機能に使用される医療データを送信することができる。専用データ受信デバイス１２０からのデータは、専用データ受信デバイス１２０のＵＳＢインタフェース３４５を介して、例えば、ユーザコンピュータデバイス（「ＰＣ」）１４０にアップロードすることができる。ユーザコンピュータデバイス１４０は、更に、クラウドサーバ１５０にデータを送信することができる。ＵＳＢ接続は、各プラグイベントにおいて認証することができる。認証は、図４に関して本明細書で説明した３パス相互認証と同様に、異なる鍵を有する３パス設計を使用することができる。ＵＳＢシステムは、暗号化及び認証のための様々な異なる鍵のセットをサポートすることができる。鍵は、異なる役割（臨床、製造者、ユーザなど）と一致させることができる。セキュリティ情報を漏らす可能性のある機密コマンドは、認証された追加の鍵セットを使用して認証された暗号化をトリガーすることができる。

【0033】

本開示を通じて使用されるように、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ（「ＢＬＥ」）は、エンドユーザにとってＢｌｕｅｔｏｏｔｈデバイスのパーリングを簡単にするために最適化された近距離通信プロトコルを指す。本明細書で説明するように、センサ１１０上でのＢＬＥの使用は、オプションとして、セキュリティのためにＢｌｕｅｔｏｏｔｈの標準ＢＬＥ実装に頼らず、代わりに、相互認証及び暗号化を確立するために１又は２以上のブロック暗号を使用するアプリケーション層暗号化を使用することが可能である。アプリケーション層に実装された非標準の暗号化設計の使用は、幾つかの利点を有する。このアプローチの１つの利点は、ユーザが、ＮＦＣスキャンだけで、セキュリティピンの入力やデータ受信デバイスとセンサ１１０との間のＢＬＥペアリングの確認などの追加の入力を実施することなく、センサ１１０と専用データ受信デバイス１２０のペアリングを完了できることである。別の利点は、このアプローチが、ペアリングプロセスをサポートするために使用される情報が、より長距離のＢＬＥチャネル上ではなく、近距離のバックアップ近距離通信リンク（例えば、ＮＦＣ）を介して共有されるので、少なくとも部分的に、センサ１１０のすぐ近くにないデバイスが不注意又は故意にペアリングすることを可能にする可能性を軽減することである。更に、ＢＬＥペアリング及びボンディングスキームが関与しないので、センサ１１０のペアリングは、チップベンダーによる実装の問題又はＢＬＥ仕様の脆弱性を回避することができる。

【0034】

センサ１１０によって収集され、センサ１１０とデータ受信デバイスとの間で交換されるデータは、ユーザに関する医療情報に関連付けられたため、データは非常に機密性が高く、保護されることが有益である。患者に関連付けられた医療データは、少なくとも部分的には、この情報が健康モニタリングや投薬の決定を含む様々な目的のために使用され得るので、機密性の高いデータである。患者データに加えて、低電力医療モニタリングシステム１００は、リバースエンジニアリングのための外部当事者による努力に対してセキュリティハードニングを実施することができる。本明細書で説明するセキュリティアーキテクチャは、デバイス間の通信の保護、構成要素及びアプリケーション内の知的財産の保護、並びに秘密及び一次キーイング材料の保護を含むが、これらに限定されない、本明細書で説明する制御機能の様々な組み合わせを含むことができる。本明細書で具現化するように、暗号化及び認証は、保護機能を提供するための主要な技術制御のうちの２つとして使用することができる。本明細書で具現化するように、低電力医療モニタリングシステム１００の様々な構成要素は、この通信及び関連データの機密性、完全性及び可用性（「ＣＩＡ」）を保護するように設計されたセキュリティインタフェースに準拠して構成することができる。これらのＣＩＡの懸念に対処するために、以下のセキュリティ機能を、低電力医療モニタリングシステム１００のハードウェア及びソフトウェアの設計に組み込むことができる。

【0035】

本明細書で具現化するように、データの機密性を促進するために、任意の２つのデバイス（例えば、センサ１１０及び専用データ受信デバイス１２０）間の通信接続は、何れかのデバイスによって機密データを送信する前に相互に認証することができる。通信接続は、デバイス固有又はセッション固有の暗号鍵を使用して暗号化することができる。本明細書で具現化するように、暗号化パラメータは、通信のデータブロックごとに変更するように構成することができる。

【0036】

本明細書で具現化するように、データの完全性を保証するために、任意の２つのデバイス（例えば、センサ１１０及び専用データ受信デバイス１２０）間の暗号化通信は、通信に組み込まれた伝送完全性チェックで検証することができる。本明細書で具現化するように、通信を暗号化するために使用することができるセッション鍵情報は、デバイスがそれぞれ認証された後に、２つのデバイス間で交換することができる。センサ１１０と専用データ受信デバイス１２０（又は多目的データ受信デバイス１３０上で実行するアプリケーション）との間の暗号化通信は、例として、また限定ではなく、非安全エラー検出コード、最小距離コーディング、反復コード、パリティビット、チェックサム、巡回冗長検査、暗号ハッシュ関数、エラー訂正コード、及びデジタルメッセージ内のエラーの存在を検出するための他の適切な方法を含むエラー検出コード又はエラー訂正コードによって検証することが可能である。

【0037】

本明細書で具現化されるように、最小距離符号化は、検出可能なエラーの数に関する厳密な保証を提供するランダムエラー修正符号を含む。最小距離符号化は、値と表現との間のハミング距離を最小化する、受信した値を表現するためのコードワードを選択することを含む。最小距離符号化、又は最近傍符号化は、標準的なアレイを使用して支援することができる。最小距離符号化は、エラーが発生する確率が与えられたシンボルの位置に依存せず、エラーが独立したイベントとみなすことができる場合に有用であると考えられる。これらの仮定は、２値対称チャネルを介した送信に特に適用することができる。

【0038】

更に又は代替的に、本明細書で具現化されるように、繰り返し符号は、通信メッセージがエラーフリーで受信されることを保証するために、チャネルにわたってビットを繰り返す符号化スキームに関連付けられた。送信されるデータのストリームが与えられると、データは、ビットのブロックに分割される。各ブロックは、任意の所定回数が送信され及び再送信される。繰り返されるブロックの何れかの伝送が異なれば、エラーが検出される。

【0039】

加えて、又は更なる代替案として、本明細書で具現化されるように、チェックサムは、固定ワード長のメッセージコードワードのモジュラー算術和に基づくメッセージに対する値である。チェックサムは、メッセージ全体又はメッセージのブロックから指示することができる。チェックサムは、対象となるメッセージの僅かな変更に対して著しく異なるチェックサム値（又はハッシュ値）を出力するように構成されたチェックサム関数又は暗号化ハッシュ関数を使用して生成される。パリティビットは、送信時にビット群に付加されるビットで、結果的に特定のビットの計数値が偶数又は奇数であることを保証するためのものである。例えば、パリティビットは、値０を持つビットの数が奇数であることを保証するために使用することができる。そして、パリティビットは、単一エラー又は繰り返される一定数のエラーを検出することができる。パリティビットは、チェックサムの特殊なケースと考えることができる。

【0040】

本明細書で具現化されるように、個々のデバイス及び低電力医療モニタリングシステム１００の侵害のリスクを更に低減するために、ルート鍵（例えば、デバイス固有鍵又はセッション固有鍵を生成するために用いられる鍵）は、オプションとして、センサ１１０に保存されず、専用のデータ受信デバイス１２０（これは、必要に応じて鍵を復号化するための追加の処理能力を有することができる）上のストレージで暗号化することができる。本明細書で具現化するように、ルート鍵は、サードパーティーがルート鍵に容易にアクセスすることを防止するために難読化された方法で保存することができる。また、ルート鍵は、ストレージのどこに格納されるかに基づいて、異なる暗号化状態で格納することができる。一例として、ルート鍵は、（例えば、他の読み取り及び書き込みロック機構のために）サードパーティーがアクセスできないメモリ内の領域に暗号化されていない状態で格納することができる。

【0041】

本明細書で具現化されるように、データの利用可能性を促進するために、センサ１１０の動作は、通信インタフェース（例えば、ＢＬＥ及びＮＦＣ）を介してメモリ２２０への書き込み機能へのアクセスを制限することによって、センサ１１０を使い捨てとして設計できるサービス寿命中に、改竄から保護することができる。メモリ２２０の読み取り機能へのアクセスも、特に、読み取り機能が、安全又は敏感と指定されたメモリ２２０の特定の領域にアクセスしようとする場合に、強制することができる。更に、センサ１１０は、センサ１１０がペアリングされた専用データ受信デバイス１２０から切断された状態になったときのみ、アドバタイズして接続可能状態になるように構成することができる。センサ１１０は、更に、通信インタフェース上の特定のサービス拒否攻撃から保護するために、指定された時間内に認証を完了しない通信接続要求を遮断することができる。更に、本明細書に記載される一般的な認証及び暗号化設計は、センサ１１０のデータが単一のデバイスに永久に束縛されることなく他の「信頼できる」データ受信デバイスに利用可能にされ得る相互運用可能な使用をサポートすることが可能である。

【0042】

本明細書で具現化されるように、機密データ、例えば医療データ又は後述するセキュリティパラメータを含む低電力医療モニタリングシステム１００における通信は、認証を伴う。このような通信に関連付けられたコマンドは、チャレンジ－レスポンス機構を実装する３ウェイハンドシェイクとして、動作ごとに再認証される。例えば、及び本明細書で具現化するように、チャレンジの要求を送信することができ、チャレンジパラメータを含む応答が返される。次のリクエストは、第１パーティーのチャレンジパラメータを組み込んだ認証トークンの形式であり、第２パーティーのチャレンジパラメータを提示する。

【0043】

認証方式において、センサ１１０とデータ受信デバイスとの間の相互認証は、センサ１１０に格納され、データ受信デバイスによって受信された個人化値から導出され得るデバイス固有の暗号鍵によって保護することができる。更に、相互認証は、センサ１１０とデータ受信デバイスとの間の事前共有されたデバイス固有鍵によって保護することができる。認証に成功すると、センサ１１０は、ランダムに生成されたセンサ固有鍵を送信することができる。センサ固有鍵は、ストリーム暗号又はブロック暗号の基本鍵として使用することができる。本明細書で具現化されるように、暗号への入力は、暗号化ブロックごとに変更することができる。

【0044】

専用データ受信デバイス１２０とユーザコンピュータデバイス１４０との間の相互認証は、有線又は他の無線通信を介して発生することができる。専用データ受信デバイス１２０とユーザコンピュータデバイス１４０上で実行される専用アプリケーションとの間の通信は、相互に認証することができる。認証用及び通信交換用の暗号鍵は、専用データ受信デバイス１２０及びアプリケーション暗号化ライブラリに組み込まれたルート鍵から導出することができる。

【0045】

センサ１１０とデータ受信デバイスとの間のメッセージペイロードは、デバイス固有の鍵で暗号化することができる。デバイス固有鍵は、単一のデバイス固有鍵の侵害が、悪意のあるパーティーにそのデバイスからのメッセージペイロードの復号化を可能にするが、他のデバイスからのメッセージペイロードの復号化に使用できないので、メッセージ内容の意味のある改竄又は傍受の任意の試みを困難にすることが可能である。本明細書で具現化するように、暗号化の実装は、効率のために、ブロック暗号のカウンタモードをストリーム暗号として使用することができる。このようなモードでは、メッセージ内の単一ビットフリップは、単一ビットメッセージの破損をもたらす。カウンタモード及びストリーム暗号を使用するこのような破損は、適切な長さのエラー検出コードによるメッセージ伝送の完全性の検証によって緩和することができる。

【0046】

限定ではなく例示の目的で、図４に示すような開示された主題と共に使用するためのメッセージペイロードの構造の例示的な実施形態が参照される。図４は、例示的な実施形態によるメッセージペイロードの構造の一例を示す。図４に示す例では、エラー検出コードは、平文コマンドコード４２０及び暗号化ペイロード４３０を含むメッセージ４１０の全体にわたって計算される。通信ブロック４００に付加されたエラー検出ブロック４４０は、メッセージ４１０の完全性を保証するために使用することができる。

【0047】

センサ動作は、２つの相補的なアプローチによって、通信モジュール２４０を介して使用耐用年数の間、改竄から保護することができる。第１に、通信インタフェース（例えば、ＮＦＣ）を介してセンサ１１０のメモリ２２０（ソフトウェアを含む）に書き込む能力は、製造時に無効化することができる。デバッグ及び再プログラミングのためのＡＳＩＣ上のポートは、センサ１１０のアクティベーションセキュリティ状態に基づいて選択的に非アクティベーションすることができる。加えて又は代替的に、及び本明細書で具現化されるように、センサ１１０は、他の通信インタフェース（例えば、ＢＬＥ）を介して書き込み機能をサポートする能力なしで構成することができる。

【0048】

本明細書で具現化するように、センサ１１０、専用データ受信デバイス１２０、及び多目的データ受信デバイス１３０はそれぞれ、通信セッションを介して交換されるデータの機密性を確保し、関連デバイスが信頼できるエンドポイントを見つけて接続を確立することを容易にするために、様々なセキュリティ慣行を採用することが可能である。一例として、センサ１１０は、ペアリングされた専用データ受信デバイス１２０から切断された状態になると、例えばＢＬＥインタフェースを介して、接続可能状態を広告し、入るように構成することができる。センサ１１０は、一定期間ごとに所定の時間だけ、例えば２分ごとに２秒間だけ、接続可能状態に入ることができる。センサ１１０は、更に、要求者が所定の期間内（例えば、４秒以内）に通信インタフェース上で独自のログイン手順を完了できない場合、接続要求を拒否し、遮断することができる。これらの特性は、特定のサービス拒否攻撃から、特にＢＬＥインタフェースに対するサービス拒否攻撃から保護する。本明細書で具現化するように、センサ１１０に接続するために使用される識別子は、１又は２以上のデータ受信デバイスに接続するように単一のセンサ１１０を追跡する能力を低減するために、変更可能であり得る。センサ１１０又はデータ受信デバイスの接続識別子は、一例としてのみ、一意又は半固有のデバイス識別子、デバイスの通信モジュールのメディアアクセス制御アドレス、特定の通信プロトコル（例えば、ＢＬＵＥＴＯＯＴＨアドレスなど）用に構成されたデバイスアドレス、インターネットプロトコルアドレス、低電力医療モニタリングシステムによってデバイスに割り当てられた識別子、放送するデバイスの種類に対する普遍的に同意した識別子、等を含むことができる。センサ１１０は、センサ１１０の起動と第１専用データ受信デバイス１２０とのペアリングとの間で識別子を変更することができる。センサ１１０がそのアクティブな使用タイムライン中に第１の専用データ受信デバイス１２０から切断する場合、センサ１１０は、切断時又は第２の専用データ受信デバイス１２０との新しい接続要求の受信時に、接続識別子を変更することができる。

【0049】

加えて又は代替的に、接続識別子は、接続タイプに従って、又は通信プロトコルの暗号化機能に基づいて変更され、多目的データ受信デバイス１３０又は専用データ受信デバイス１２０によってサポートすることができる。本明細書で具現化するように、接続識別子の表現は、接続識別子がデバイスによって（例えば、センサ１１０又はデータ受信デバイスによって）ブロードキャストされる前に、１又は２以上の暗号機能を用いて変更することができる。デバイスは、接続識別子がブロードキャストデバイスに一意に関連付けられるリスクを低減するために、接続識別子をマスクしてセキュアにするために、幾つかの機能が同時に実行されるプライバシーモードで動作することができる。このような機能の１つは、放送前に接続識別子のアスペクトをランダム化することを含むことができる。また、接続識別子は、合意された暗号関数と公開鍵で暗号化することができる。そして、対応する秘密鍵又は共有秘密鍵を有し、使用された暗号関数の種類を知り、ランダム化効果を決定論的に解除できるデバイスのみが、特定のデバイスを識別することができるようになる。本明細書で具現化するように、これらのレベルの暗号セキュリティは、通信プロトコルのアプリケーション層又はより高いインフラ層で実行することができる。

【0050】

本明細書で具現化されるように、センサは、データ受信デバイスに関連付けられた暗号鍵及び認証鍵を格納することによって長期接続ペアの確立をサポートし、又はデータ受信デバイスがセンサ１１０に対する暗号鍵及び認証鍵を長期間にわたって格納することをサポートすることができる。例えば、センサ１１０又はデータ受信デバイスは、相手方によって使用される暗号鍵及び認証鍵と関連して、交換の相手方の接続識別子を関連付けることができる。そうすることで、センサ１１０は、少なくとも部分的には、センサ１１０がそのデータ受信デバイスとの新しい認証ペアリングを確立することを回避し、本明細書に記載される暗号化通信プロトコルを介して情報を交換することに直接進むことができるので、データ受信デバイスとの接続をより迅速に確立することができる。接続が正常に確立された後、２つのデバイスは、新しい接続を確立するために接続識別子及び他の情報を放送することを控えることができ、サードパーティーが通信を聞く機会を減らすために、合意されたチャネルホッピング方式を用いて通信することができる。別の例として、センサ１１０は、利用可能な接続ポイントを走査し、センサ１１０が以前に認証された交換を確立したデバイスなど、既に接続したことのあるデバイスとの接続を好むように構成することができる。このプロセスは、他の信頼できるデータ受信デバイスが通信範囲内にあるときに、悪意のあるサードパーティーが認証交換を横取りする機会を減少させることができる。

【0051】

加えて又は代替的に、センサ１１０及びデータ受信デバイスは、既知の信頼できるデバイスのためのホワイトリストの使用をサポートすることができる。例えば、データ受信デバイスの使用寿命にわたって複数のセンサ１１０を使用することを想定しているユーザは、複数のセンサに関連付けられた接続識別子を登録することができ、あるいは、接続識別子の範囲を登録することができる。同様に、センサ１１０は、信頼できる接続識別子又は接続識別子の範囲（例えば、特定のユーザに属する専用のデータ受信デバイス１２０又は多目的データ受信デバイス１３０に関連付けられた保護された値）を用いて構成することができる。このように、接続を確立するとき、センサ１１０及びデータ受信デバイスは、利用可能な接続ポイントに関連付けられた接続識別子を、ホワイトリストに格納された接続識別子と比較することができる。ホワイトリストは、排他的な範囲を表すことができ、これは、ホワイトリストに含まれる以外の接続識別子が使用されないことを意味する。あるいは、ホワイトリストは、ホワイトリストが最初に検索されるが、他のデバイスが依然として使用され得る、好ましい範囲を表することができる。本明細書で具現化するように、センサ１１０及びデータ受信デバイスは、上述の何れかのショートカット手順を介して受け入れられたデバイスのアイデンティティを確認し、不正な識別子及び認証アドレスを提供する疑いがあるデバイスとの将来の接続を切断し拒否できるように構成することができる。

【0052】

センサ１１０と互換性のある特定のコマンドは、コマンドを実行する前に使用されるセキュリティのレベルに少なくとも部分的に基づいて参照することができる。例えば、ある種のコマンドは、「オープン」又は「非認証」コマンドと呼ぶことができる。このようなコマンドは、例えば、センサ１１０のバッテリ状態表示の取り出し、又は認証を開始するための情報の取り出しなど、センサ１１０への変更又は機密医療情報の取り出しを生じないコマンドを含むことができる。他のコマンドは、「認証された」コマンドと呼ぶことができる。このようなコマンドは、敏感なデータの収集をもたらすコマンドを含むことができる。本明細書で具現化されるように、センサ１１０とデータ受信デバイスとの間の通信経路は、認証されたコマンドごとに再認証することができる。本明細書で具現化するように、低電力医療モニタリングシステム１００は、複数のデータ受信デバイスを有するユーザが、排他的バインディングを確立する代わりにデータ受信デバイスの何れかを利用できるように、いわゆる「フェールオープン」システムとして設計することができる。例えば、排他的バインディングは、ユーザが例えば第１のデータ受信デバイスでアクティベーション及び認証し、その後、ペアリングされていない第２のデータ受信デバイスを使用して医療データを受信することを排除することになる。このようなユースケースは、サードパーティーの多目的データ受信デバイス１３０をサポートするために望ましい。

【0053】

次に、低電力医療モニタリングシステム１００の高レベルセキュリティアーキテクチャを、図５を参照して説明する。図５は、開示された主題と共に使用するための低電力医療モニタリングシステム１００の動作フロー及びデータライフサイクル５００の例示的な実施形態を示す。ステップ５１０において、製造者１６０は、各デバイスの暗号鍵を生成するために使用することができる情報を選択する。本明細書で具現化するように、情報は、必要に応じてデバイス、セッション、又はデータ伝送に固有の暗号化値を生成するためにデバイス固有の情報及び動作データ（例えば、エントロピーベースのランダム値）と組み合わせて使用することができるセンサ１１０及びオプションとして専用データ受信デバイス１２０のためのセキュアなルート鍵を含むことができる。ステップ５２０において、製造業者は、各センサ１１０に固有の識別子（"ＵＩＤ"）を付与することができる。製造業者は、更に、製造業者の識別子、通信モジュール及び製造業者の識別子、又はセンサ若しくはセンサ構成要素のための任意の他の適切な識別情報などの他の識別情報を各センサ１１０に付与することができる。例えば、各センサ１１０のＵＩＤは、ＡＳＩＣベンダーによってセンサ１１０に具現された各ＡＳＩＣ２００に割り当てられたシリアル番号から、通信モジュールベンダーによってセンサ１１０に具現された通信モジュール２４０に割り当てられたシリアル番号から、センサメーカーによって生成されたランダム値から等、センサ固有のデータから導き出すことが可能である。加えて又は代替的に、ＵＩＤは、センサ１１０又はその構成要素のロット番号、センサ１１０又はその主要構成要素の製造日、日付又は時間、センサ又はその主要構成要素の製造場所、工程又はライン、及びセンサがいつ、どのように製造されたかを識別するために使用できる他の情報を含む製造値からも導出することができる。ＵＩＤは、各センサ１１０に固有でもある暗号鍵と幾つかの生成されたランダム値を伴うことができる。ステップ５３０において、製造業者は、各専用データ受信デバイス１２０に、例えば、通信を容易にする目的でデータ暗号鍵を導出するために使用することができるルート鍵を含むデータを提供することができる。

【0054】

ステップ５４０において、センサ１１０は、患者又はユーザ１４０（例えば、人間又は動物の身体）からなど、医療データを収集することができる。例えば、センサ１１０は、適切に構成された専用のデータ受信デバイス１２０による起動時に、所定の間隔でデータを収集することができる。ステップ５５０において、センサ１１０は、その通信モジュール２４０を介して（例えば、ＮＦＣ、ＢＬＥなどを介して）通信インタフェースを介して医療データを専用データ受信デバイス１２０に送信することができる。医療データに加えて、センサ１１０は、選択されたプロトコルに沿った交換を促進するために、追加の情報を送信することができる。例えば、センサ１１０から専用データ受信デバイス１２０へのメッセージペイロードは、製造者固有値、製造者識別値、センサの識別値、送信電力レベル値などを含むことができる。本明細書で具現化するように、電力レベル値は、選択された通信インタフェースによって確立された範囲上で（例えば、０～２０の範囲上で）定義することができる。パワーレベル値は、専用データ受信デバイス１２０が、センサ１１０にデータを再放送するように要求するため、又は高いパワーレベルで将来のデータ伝送を実施するために使用することができる。例えば、センサ１１０は、通信の完全性を確保することが困難な専用データ受信デバイス１２０からの距離にあることが可能である。専用データ受信デバイス１２０は、送信を無傷で配信することを保証するために、センサ１１０の通信モデル２４０により多くの電力を流用させるための指示をセンサ１１０に送ることができる。

【0055】

ステップ５６０で、センサ１１０は、任意選択で、その通信モジュール２４０を介して（例えば、ＮＦＣ、ＢＬＥなどを介して）通信インタフェースを介して多目的データ受信デバイス１３０に医療データを送信することができる。ステップ５７０において、専用データ受信デバイス１２０は、ユーザコンピュータデバイス１４０（例えば、患者のパーソナルコンピュータ）上で実行される専用アプリケーションに通信可能に結合することができる。専用アプリケーションとの通信を通じて、専用データ受信デバイス１２０は、センサ１１０から取得された医療データを通信することができる。本明細書で具現化するように、専用データ受信デバイス１２０は、専用データ受信デバイス１２０のＡＳＩＣ２００の内部プログラムフラッシュがデバッグ及びプログラミングポートでロックされた状態で出荷され、大量消去を行わないアクセスを防止したファームウェアロック状態でエンドユーザに提供することが可能である。本明細書で具現化するように、センサ１１０又は専用データ受信デバイス１２０は、アクセス不能なデータの回復又は特定のエラーの原因の特定などの診断目的のために、製造業者１６０（又は信頼できるサードパーティー）に返却することが可能である。

【0056】

ステップ５８０において、多目的データ受信デバイス１３０又はユーザコンピュータデバイス１４０は、本明細書において具現化されるように、医療データをクラウドサーバ１５０に通信することができる。本明細書で説明するように、多目的データ受信デバイス１３０又はユーザコンピュータデバイス１４０は、任意選択で、コンピュータ処理能力の使用においてそれほど制限されず、従って、クラウドサーバ１５０にデータを送信する際に標準のデータセキュリティアプローチに従事することができる。多目的データ受信デバイス１３０又はユーザコンピュータデバイス１４０とクラウドサーバ１５０との間の通信交換は、送信されたデータの交換及び確認を含むことができる。一例として、クラウドサーバ１５０は、クラウドサーバ１５０に提供されたデータから追加情報を生成し、デバイスのユーザ（例えば、患者１４０）が追加情報を見ることができるように、その追加情報をユーザコンピュータデバイス１４０又は多目的データ受信デバイス１３０に提供することが可能である。本明細書で具現化するように、データがクラウドサーバ１５０にアップロードされる前に、患者１４０の個人識別情報をデータから削除し、暗号化し、又は他の方法で不明瞭にして、アップロード前にデータを匿名化することができる。クラウドサーバ１５０は、他の情報、例えば、クラウドサーバ１５０に接続するために使用される認証トークン、又は多目的データ受信デバイス１３０の識別情報、若しくはユーザコンピュータデバイス１４０に関連付けられた情報を使用して、（必要に応じて）そのデータを患者１４０に関連付け戻すことができる。あるいは、データを不可逆的に患者１４０と関連付け解除して、データのプライバシーを確実に維持しつつ、例えばデータを処理するために使用される技術の精度をモニタリング又は改善するために、データを研究に使用することを可能にすることができる。更に、データは、データが別のデータセットの重複でないことを保証するために、以前に受信したデータと比較することができる。例えば、患者１４０は、多目的データ受信デバイス１３０とユーザコンピュータデバイス１４０の両方を使用してデータをアップロードすることができ、これは、患者１４０のために二重にカウントされるべきではない。

【0057】

図５に関して説明したデータライフサイクルは、機密データ、例えばセキュリティパラメータ（本明細書において更に詳細に説明する）又は患者データが、悪意のあるサードパーティーにさらされる危険性があるか、又は悪意のあるサードパーティーからの潜在的な攻撃にさらされる可能性がある領域を示している。例えば、暗号鍵は、製造プロセスで使用するために埋め込まれ、セキュリティパラメータは、センサ１１０及び読取デバイス１２０に配信される。センサ１１０と多目的データ受信デバイス１３０、センサ１１０と専用データ受信デバイス１２０、又は専用データ受信デバイス１２０とユーザコンピュータデバイス１４０上で実行される専用アプリケーションとの間で、通信リンク（例えば、ＮＦＣ、ＢＬＥ、ＵＳＢなど）を介して交換される医療データは、製造業者１６０の制御から遠隔で交換されるので、例えば、認証及び暗号化を通じて通信が保護される必要がある。センサ１１０及び専用データ受信デバイス１２０のログ、例えば、製造業者１６０への返却時に関連デバイスから取得されるものは、最小限の医学的に敏感なデータを有するが、製造業者固有のインタフェースを再有効化して当該ログを取得すると、セキュリティパラメータ及び製造業者固有のコマンドが露出する可能性がある。従って、本明細書で具現化されるように、製造業者固有のインタフェースは、別々の製造業者固有のプロセスを介して（例えば、製造業者固有のデバイス固有鍵又はセッション固有鍵を使用して）認証される。

【0058】

本明細書で説明するセキュリティアーキテクチャは、セキュリティ関連の決定を導くための幾つかの設計原則を具現化する。一例として、認証又は暗号化で使用することができ、平文として伝送されるパラメータは、セキュリティパラメータとして使用する前に変換される。デバイス識別と認証シーケンスの一部として、ＵＩＤ、ソフトウェアバージョン、ランダムに生成されたチャレンジ、ノンス値などのセンサのプロパティは、プレーンテキストとして送信され、従って直接観察可能である危険性がありる。本明細書では、これらのパラメータは、暗号化又は他のセキュリティ機能の入力として使用する前に、暗号化されていない変換又は代数的操作など、何らかの方法で処理される。

【0059】

通信伝送の完全性は、オンチップのハードウェア機能を用いて積極的に管理される。暗号化は、改竄されない方法でデータを送信するセキュアな手段を提供するが、暗号化及び復号化には計算機コストがかかる。また、伝送の失敗を攻撃と区別することができない。前述したように、高速でハードウェアベースの誤り検出符号を伝送の完全性のために使用することができる。一例として、本明細書で具現化するように、メッセージの長さに対して適切なサイズの誤り検出コード（例えば、１６ビットＣＲＣ）が使用され得るが、本開示は他の適切なハードウェアベースの誤り検出コードを予期している。追加のセキュリティを含む機能は、暗号化に依存する。

【0060】

チャレンジパラメータの順序は、リプレイ攻撃の成功の可能性を減少させるために、送信者１１０とデータ受信デバイスとの間で（例えば、データ受信デバイスからセンサ１１０へ、又はその逆）変化する。暗号ブロック境界と偶然に一致するパラメータを使用する抽象的なリスクは、チャレンジと対になった偶然の値が同じ暗号文を生成する状況を作り出すことができる。認証された交換は、このリスクを、ランダムなチャレンジ Ａ とランダムなチャレンジ Ｂ が等しく、且つ一致したパラメータが等価であるという、２６４ 分の １ の確率の稀なケースに減らすために、リターントークンのチャレンジパラメータの順序を変える （例えば、逆、変換など） ことで、リスクを減らす。チャレンジは単一の交換に使用することができ、ノンスは単一のメッセージに使用することができる。暗号文の衝突のリスクを更に減らすために、相互認証トークンで使用されるチャレンジは破棄され、新しい認証された交換ごとに再生成されることができ、ノンス値はメッセージごとに変更されることができる。既知の平文攻撃に関連付けられたリスクに対処するために、カウンタモード暗号への入力として使用される値は、予測可能性を減らすために非ゼロ値で始まる。

【0061】

センサ１１０は、製造中に例示的なセキュリティパラメータ（「ＳＰ」）及び鍵を受け取ることができる。センサ１１０は、本明細書で具現化されるように、組織的一意識別子（「ＯＵＩ」）、製造者識別コード、又は他の類似の情報を含むことができる静的な一意ＩＤ（「ＵＩＤ」）を提供することができる。ＵＩＤは、追跡され、一意であることが検証することができる。ＵＩＤは、非可変ハードウェアコード化された値であり得る。製造者中、センサ１１０は、本明細書において更に詳細に説明される認証形成値（ＡＦＶ）、暗号化形成値（ＥＦＶ）、又は一意認証値（ＵＡＶ）を含むがこれらに限定されない、個人化値（「ＰＶ」）及び暗号鍵を更に受け取ることが可能である。本明細書で具現化するように、個人設定値はノンスｓの開始材料として使用でき、ノンスｓは認証及びデータ暗号化の間に使用される暗号の入力として使用でき、一方、形成値は個人設定値、他の鍵情報、及び出力の間の関係を更に難読化するために使用されるランダム値を含むことができる。Ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ Ｖａｌｕｅは、センサ１１０又はデータ受信デバイスが、接続識別情報（本明細書に記載された情報を含むがこれに限定されない）を非匿名化し、匿名化又は署名された接続識別情報を解決して認証交換を識別及び開始する目的で特定のデバイスを参照するために使用できるＩｄｅｎｔｉｔｙ Ｒｅｓｏｌｖｉｎｇ Ｋｅｙ（「ＩＲＫ」）などの鍵を含むことができる。ＡＦＶ及びＥＦＶは、製造者１６０によって生成され、センサ１１０に格納されるランダム値であり得る。ＡＦＶは、認証中に使用される様々な暗号への入力として使用することができ、一方、ＥＦＶは、暗号化中に使用することができる。本明細書で具現化するように、ＡＦＶ及びＥＦＶは、異なる値又は一致する値であり得る。ＵＡＶは、例えば、ＡＳＩＣ２００及び通信モジュール２４０などのセンサの様々な構成要素から導出される、センサ１１０の固有情報から導出される値であり得る。

【0062】

本明細書で具現化されるように、センサ１１０は、鍵を独立して導出又は展開するように構成することができる。従って、センサ１１０は、拡張された鍵スケジュールの形態で暗号鍵を受信することができる。製造時に、鍵値（例えば、ルート鍵、デバイス固有情報、秘密センサ値など）を生成するための全ての入力が知られているので、鍵は、センサ１１０のプロビジョニングの前に拡張することができる。例えば、センサ１１０は、データ受信デバイスとの認証シーケンスの終結時に、又は、データ受信デバイスへの終結ステップの一部として、機密データをデータ受信デバイスに送信する前に、センサ固有の鍵を実装するために用いられるランダムシークレットを受け取ることが可能である。製造者１６０の監督下にないセンサ１１０は、潜在的な攻撃の対象となり得るため、特定の鍵の値はセンサ１１０に保存されない。例えば、通信認証値を導出するために使用される鍵、又はセンサ固有な認証値は、任意に、センサ１１０上に恒久的に格納されないことができるが、代わりに、センサ１１０上に格納された値からライブで且つ必要に応じて決定される。更に、制限されたコマンドを認証するために使用されるセンサ固有な鍵は、センサ１１０以外の場所に格納されることもでき、又は、妥協の影響を低減するフォーマットで格納されることも可能である。本明細書で具現化されるように、無関係なセンサ固有キーイングシークレット（例えば、「ＳＳ」）は、デバイス固有値、製造関連値、ランダム値関数、及び他の調整関数に基づいてセンサ１１０製造中にランダムに生成される。ＳＳの生成に使用される値は、秘密の一意性を作り出すために使用される。ランダムバリュー関数は、ＳＳ、ルート鍵、派生鍵の関係を不明瞭にする。この秘密は、運用時に、データ受信デバイスで利用可能なルート鍵と組み合わせて、データ受信デバイスとの通信に利用することができる。ルート鍵は、そのセンサ１１０に固有のセンサ暗号鍵（「ＳＥＫ」）を導出し、センサ１１０とデータ受信デバイスとの間のデータ通信を暗号化するために、データ受信デバイスによって保存することができる。

【0063】

ＳＰは、セキュリティアーキテクチャにおける制御のための入力である。例えば、ＳＰは暗号関数の入力として使用され、暗号の出力に影響を与える。明確にするために、暗号はデータに適用される。特に、データは ＳＰ として使用されない。低電力医療モニタリングシステム１００で使用可能な例示的なＳＰが本明細書で説明される。ＳＰの導関数値は、簡潔さのために記載されていないが、適切な場合には採用されることが理解されるべきである。システムアーキテクチャは、デバイス認証、デバイス間通信の暗号化、ソフトウェア及びファームウェアの更新など、セキュリティ上重要なプロセスの間に、様々な保存及び生成されたセキュリティ鍵の使用を企図する。前述したように、低電力医療モニタリングシステム１００のセンサ１１０は、電力効率及び演算効率を考慮して設計されているため、センサ１１０は、セキュリティ鍵と相関する特定の値を保存することができる。認証及び暗号化を可能にするために、値（ＳＰなど）は、データ受信デバイスによって使用され、適切なセッション又はデバイス固有のセキュリティ鍵を生成することができる。本明細書で具現化するように、鍵構造は、認証及び暗号化のために派生鍵を優先し、各派生鍵を単一の目的又は活動のために使用することによって、暗号の危険に対抗するために利用することができる。本明細書で具現化するように、派生鍵は、各デバイス（例えば、センサ１１０、専用データ受信デバイス１２０、多目的データ受信デバイス１３０）に固有であり、更に、各目的（例えば、２つのデバイス間の特定の通信セッション、又は通信セッション中の特定の交換）に固有であるように構成することができる。従って、単一の派生鍵（認証又は暗号化に使用される鍵など）の妥協は、単一のセンサ１１０の単一の機能の妥協に分離される。単一の鍵の妥協は、暗号システム全体に重大な弱点を導入しない。

【0064】

認証鍵、暗号鍵、及びルート鍵（単一のデバイス固有の暗号鍵又は単一の目的のエフェメラル暗号鍵の鍵導出に使用できる）を一般に生成する際に、鍵が安全で、改竄できない、そして必要な場合には真にランダムな方法で生成されることを保証するためにセキュリティ慣行が守られる。実際には、鍵は、例えば、微細なユーザインタラクション（例えば、マウスの動き）、システム割り込み、ネットワーク割り込み、プロセステーブルイベント、及び他のシステムエントロピー収集技術などの真のランダム動作を通じて収集したシステムエントロピーを部分的に使用して生成することが可能である。

【0065】

本明細書で具現化される低電力医療モニタリングシステム１００のためのセキュリティアーキテクチャにおける、鍵の例示的な使用及び鍵間の関係を含むが、これらに限定されない例示的な鍵が本明細書に記載される。本明細書で使用され説明される鍵は例示的であり、排他的ではなく、特定の医療モニタリングシステム１００の設計要件及び用途に基づいて、追加の又は代替の鍵が適切に使用することができる。例えば、そして本明細書で具現化されるように、ＳＥＫがセンサ１１０と多目的データ受信デバイス１３０との間の通信を暗号化するために使用されると説明されるところ、同様の鍵が、専用データ受信デバイス１２０とユーザコンピュータデバイス１４０との間の通信を暗号化するために使用することができる。

【0066】

ＳＥＫは一意であることができるが、一意でないＳＥＫの影響は、少なくとも部分的には認証の冗長性によって、全体的なセキュリティアーキテクチャにおいて最小とみなすことができる。例えば、２人のユーザが、ＳＥＫの同じ値（ｎビット鍵の場合、１：２ｎの確率を表す）、暗号に使用されるデータノンスの一致する値（ｎバイトノンスの場合、１：２ｎの確率を表す）、及び通信インタフェース結合識別子の一致する値を有するセンサ１１０を有する場合、センサ１１０は、ハードウェアアドレスが一致する場合には、ハードウェアハンドシェイクレベルでアクティブに結合されている起動データ受信デバイスとのみ通信するよう構成することができる。

【0067】

本明細書で具現化されるように、真のランダム性は、セキュリティアーキテクチャ全体にわたって組み込まれ得る。ランダム性は、製造業者１６０、センサ１１０、専用データ受信デバイス１２０、多目的データ受信デバイス１３０、及びユーザコンピュータデバイス１４０を含む、システム内の異なるエンティティによって導出することができる。ランダム・ビット・ジェネレータ（「ＲＢＧ」）は、完全に予測不可能な（例えば、真のランダムな）出力を作成する。予測不可能な出力は、鍵又は他の暗号パラメータの生成を駆動するために使用され、外部のパーティーが、利用可能になる前にビットをアルゴリズム的に予測できないことを保証する。

【0068】

本明細書で具現化されるように、製造業者１６０によって提供されるエントロピーは、専有ソフトウェアとオープンで監査可能なソフトウェアとの組み合わせを通じて、センサ１１０に提供される。センサ１１０に提供されるランダム値は、通信リンクのための認証ノンス入力、及び鍵導出関数への入力として使用されるランダム材料を含むが、これらに限定されない様々な目的のために使用される。セキュリティアーキテクチャにおいて、ＵＡＶ及びＡＦＶは、ノンス構築のための初期値として使用することができ、そのランダムな性質によって、出力をより予測不可能なものにすることができる。更に、本明細書で具現化されるように、一旦センサ１１０がユーザによって起動されると、ノンス値はユーザとの対話から追加のエントロピーを獲得し、製造値の有意性はユーザとの対話のエントロピーに追い越される。例えば、エントロピーは、相互作用の時間、専用データ受信デバイス１２０又は多目的データ受信デバイス１３０との相互作用間の時間期間、通信モジュール２４０等を介して、予測不可能な変数を通じて導入することができる。例えば、センサ１１０が真のランダム値をサポートする通信チップセットを含む場合、センサ１１０は、チップセットからエントロピーを収集することができる。本明細書で具現するように、センサ１１０のマイクロコントローラ２１０からランダム値を生成するための呼び出しは、チップセットベンダー提供のプログラミングインタフェース（「ＡＰＩ」）を通じて履行することができる。

【0069】

センサ１１０と同様に、専用データ受信デバイス１２０は、真のランダム値を使用することができ、その様々なセンサを介してエントロピーを収集することができる。一例として、専用データ受信デバイス１２０は、センサ１１０の通信チップセット２４０とは別の、真のランダム能力をサポートする通信チップセット３４０を含むことができる。本明細書で具現化するように、専用データ受信デバイス１２０は、トゥルーランダム能力からのエントロピーがライブエントロピーソースとして使用され、ランダムエントロピーソース（又はそこから導出される値）を入力として使用してＰＲＮＧによって条件付けされるＲＢＧアーキテクチャを実装することができる。専用データ受信デバイス１２０内のソフトウェアライブラリ及びアプリケーションは、トゥルーランダム能力からランダムデータを取得し、それらの値をＰＲＮＧとして利用可能な暗号のシードとして不揮発性メモリに格納することが可能である。更に、ソフトウェアライブラリを組み込んだサードパーティーアプリケーションは、ターゲットプラットフォームの組み込みオペレーティング環境を通じて、追加のエントロピー機能を提供することができる。

【0070】

本明細書で具現化されるように、低電力医療モニタリングシステム１００は、鍵の妥協及び搾取の可能性を更に低減するために、定期的な鍵ローテーションを採用することができる。低電力医療モニタリングシステム１００によって採用される鍵ローテーション戦略は、フィールドに配置された又は分散されたデバイスの後方互換性を確保するように設計することができる 。一例として、低電力医療モニタリングシステム１００は、下流デバイス（例えば、現場にある、又は実行可能な更新を提供できないデバイス）のために、上流デバイスによって使用される複数の世代の鍵と互換性があるように設計された鍵を採用することが可能である。上流デバイスは、下流の依存デバイスと相対的に定義することができ、セキュリティアーキテクチャの下でデバイスを新しい鍵で更新することが容易であることに基づいて定義することができる。一例として、専用アプリケーションを実行するユーザコンピュータデバイス１４０は、多目的データ受信デバイス１３０又は専用データ受信デバイス１２０の上流とみなすことができ、これは順次センサ１１０の上流とみなされる。別の例として、ルート鍵のローテーションは製造業者１６０から始めることができる。センサ１１０の新しい鍵世代の製造中、製造業者１６０は、新しい鍵世代を新しく製造されたセンサ１１０に伝搬させることができる。製造業者１６０はまた、データ受信デバイスが、特定のセンサ１１０の認証鍵を導出する際にどのルート鍵を使用するかを決定するために、センサ１１０によって返されたセキュリティバージョンを識別することを可能にする更新をデータ受信デバイスにプッシュすることができる。更なる代替案として、鍵ローテーションは、デバイスが何らかの時間又はイベント駆動機能に従って使用される鍵を調整するように構成される、合意されたスケジュールに基づいて行うことができる。トリガーイベントの発生後、全ての認証デバイスは、デバイス用に予めプログラムされた別の世代の鍵に切り替えるように構成される。トリガーイベントは、全ての関連デバイスに普遍的であることができ（例えば、月、日、又は週単位で鍵を切り替える）、個々のデバイスに固有であることができ（例えば、２４時間のアクティブ使用の後にセンサ用の鍵を切り替える）、又はデバイスの任意の細分化に適用されることが可能である。

【0071】

本明細書で具現化されるように、本明細書で説明される暗号化方式は、例えば、暗号性能に関連付けられた幾つかの機能を含むことができる。これらの機能の１つのクラスは、同じ鍵がアウトバウンドデータの暗号化及びインバウンドデータの復号化に使用され得るように、対称暗号関数を含む。このような機能には、ブロック暗号やその関連機能が含まれることがある。ブロック暗号は、ストリーム暗号のように１ビットずつ暗号化するのではなく、既知の鍵を用いて決定論的アルゴリズムを適用し、値のブロックを暗号化する暗号関数である。ブロック暗号は、低電力医療モニタリングシステム１００のシステムアーキテクチャにおいて特に有用であり得るが、それは、前述したように、センサ１１０（及びより少ない程度に、専用データ受信デバイス１２０）は、コストを制御し、サイズを小さくし、バッテリ寿命を維持するために選択された設計オプションに少なくとも部分的に起因して、利用可能な計算パワーをより少なく有し得るからである。しかしながら、ストリーム暗号アルゴリズムは、このシステムアーキテクチャの電力及びコンピュータリソースの制限を考慮するために適切な修正を行って、本明細書に開示される技術に従って使用することができる。使用することができる暗号化アルゴリズムは、任意の適切な暗号技術を含む。

【0072】

一例として、低電力医療モニタリングシステム１００は、暗号のための第１の軽量ブロック暗号又はストリーム暗号をサポートすることができる。別の例として、低電力医療モニタリングシステム１００は、暗号のための追加の、より暗号的に複雑な、ブロック暗号又はストリーム暗号を更にサポートすることができる。特定の実施形態において、第１の軽量ブロック暗号又はストリーム暗号は、電力及びコンピュータ可能性へのアクセスが少ないデバイスに対して優先的に使用することができ、一方、第２のブロック暗号又はストリーム暗号は、電力及びコンピュータリソースに対する制約が少ないデバイスによって使用するための、より暗号的に複雑なブロック暗号又はストリーム暗号であり得る。第１のブロック暗号又はストリーム暗号は、生成及び送信されるデータの量が比較的少なく、第２のブロック暗号又はストリーム暗号のより複雑な暗号が不適当又は非実用的である実装のために選択することができる。従って、第１のブロック暗号又はストリーム暗号は、第２のブロック暗号又はストリーム暗号と比較して、軽量ブロック暗号又は軽量ストリーム暗号と称することができる。低電力医療モニタリングシステム１００は、適宜、追加のブロック暗号及びストリーム暗号の使用をサポートすることができる。ブロック暗号及びストリーム暗号の各々は、ソフトウェアモジュール又は専用のハードウェアモジュールによって実行することができる。

【0073】

一例として、軽量ブロック暗号は、加算－回転－ＸＯＲ（「ＡＲＸ」）フレームワークを採用することができる。この例では、スケジュール鍵は使用されない。暗号化されるデータと鍵が与えられ、それぞれが少なくとも４つのブロックに分割されると、アルゴリズムは、データの各ブロックと鍵の対応するブロックとのｘｏｒを開始する。アルゴリズムは、予め決められた数の置換関数のラウンドを経て進むが、ラウンド数は安全性と性能のバランスを考慮して選択される。置換関数の各ラウンドは、順番に実行される以下の操作：データの第２のブロックをデータの第１のブロックに加える；第２のブロックを所定量回転させる；データの第１のブロックをデータの第２のブロックにｘｏｒする；データの第１のブロックを所定量回転させる；データの第４のブロックをデータの第３のブロックに加える；データの第３のブロックを所定量回転させる；データの第３のブロックをデータの第４のブロックにｘｏｒする；データの第１のブロックにデータの第４のブロックを加える；データの第４のブロックを所定量回転させる；データの第１のブロックをデータの第４のブロックにｘｏｒする；データの第２のブロックをデータの第３のブロックに加える；データの第２のブロックを所定量回転させる；データの第３のブロックをデータの第２のブロックにｘｏｒする；データの第３のブロックを所定量回転させる、を含むことができる。最終ステップとして、所定数のラウンドの後、アルゴリズムは、現在の状態のデータの各ブロックを、鍵の対応するブロックと再びｘｏｒする。

【0074】

別の例として、軽量ブロック暗号は、ＡＲＸアルゴリズムを採用することができる。２つのワードと鍵に分割された暗号で使用されるブロックが与えられると、アルゴリズムは所定のラウンド数だけ進行することができる。各ラウンドの間、ブロックの第１のワードのビットは第１の所定量だけ回転され、ブロックの第２のワードはブロックの第１のワードに追加され、鍵はブロックの第１のワードにｘｏｒされ、ブロックの第２のワードのビットは第２の所定量だけ回転され、ブロックの第１のワードはブロックの第２のワードにｘｏｒされる。本明細書で具現化されるように、各ラウンドに使用される鍵は、利用可能なコンピュータリソースに応じてオンデマンドで計算されるか、又は予めキャッシュすることができる。

【0075】

別の例として、軽量ストリーム暗号は、ｘｏｒ、３２ビット加算、及び定距離回転を利用することができる。この暗号は、正方行列として配置された１６個のワードを含む内部状態によって表現することができる。このワードは、４つの所定のワード、８つの鍵のワード、２つのストリーム位置のワード、２つのノンスのワードからなる。この暗号は、内部スレートの行又は列に対する操作によってラウンドが交互になり、１ラウンドあたり４回の４分の１ラウンド操作を実施することによって動作する。１ラウンドに４回行われる演算は、４つのワードを入力として受け取り、入力されたワードに対して一連のｘｏｒ、加算、回転の演算を実施する。第１の例では、１／４ラウンド演算は、第１のワードと４つのワードの加算を所定量だけ回転させて第２のワードとｘｏｒし、第１のワードと第２のワードの加算を所定量だけ回転させて第３のワードとｘｏｒし、第２のワードと第３のワードの加算を所定量だけ回転させて第４のワードとｘｏｒし、第３のワードと第４のワードの加算を所定量だけ回転させて最初のワードとｘｏｒするというパターンで実行される。所定量は、各操作ごとに異なることができる。設定されたラウンド数の後、混合配列は、初期鍵の回復を防ぐために、元の内部スレートに追加される。ストリーム暗号の変形として、内部スレートと４分の１ラウンド演算のバリエーションを変更することができる。１／４ラウンド演算は、４つの入力ワードを受け取るように変更することができ、次のようなパターンで行われます：２番目のワードが１番目のワードに追加され、結果の１番目のワードが４番目のワードとｘｏｒされ、その結果が所定量回転される。このパターンを、所定の回転の値を変えて繰り返す。１／４ラウンドごとに各ワードは２回更新される。更に、ストリーム暗号は、１／４ラウンドが列と行の代わりに列と対角線上で動作するように修正することができる。

【0076】

例として、より暗号的に複雑なブロック暗号は、展開、鍵混合、置換及び並べ替えからなる所定数のラウンドを採用することができる。ラウンドのメインセットに先立ち、ブロックを２つの半部分に分割し、それぞれの半部分を交互に処理して、暗号化と復号化における対称性を容易にすることができる。拡張時には、ブロックが、４つの入力ビットのコピーと、入力ビットの両側からの直接隣接ビットのコピーを含む操作ビットのセットを含むように、現在のハーフブロックは、ハーフブロックのビットの半部分を複製することによって拡張される。混合ステップでは、サブ鍵は、ｘｏｒ（排他的論理和）演算を用いて拡張されたハーフブロックと結合される。サブ鍵は、主暗号鍵に基づく鍵スケジュールに従って決定される。サブ鍵のミックス後、ブロックは幾つかの置換ボックスに分割される。各置換ボックスは、ルックアップテーブルによって提供される非線形変換に従って入力ビットのカウントを減少させる。置換ステップから出力されたビットは、予め決められた並べ替えに従って並べ替えられる。鍵スケジュールを形成するための操作は、鍵のビットのサブセットを取り出し、サブセットを分割し、ビット単位の回転を所定量だけ実行し、２つの半部分を再結合してサブ鍵を形成することを含むことができる。

【0077】

別の例として、より暗号学的に複雑なブロック暗号は、置換－置換ネットワークに基づくことができる。この暗号は、所定の鍵スケジュールを用いて暗号マスター鍵からラウンド鍵を導出する鍵拡張ステップと、ブロックの各バイトをラウンド鍵のバイトでｘｏｒする初期鍵追加ステップなどの演算を含むことができる。演算は、ルックアップテーブルに従って非線形置換ステップで各バイトを別のバイトに置換するステップ、選択されたバイトをシフト量を段階的に変化させてあるステップ数だけ循環的にシフトするステップ、バイトの細分化を反転線形変換でミックスするステップ、ラウンド鍵を結果のブロックにｘｏｒするステップのうちの１又は２以上が行われる所定の数のラウンドを含むことができる。

【0078】

別の例として、より暗号学的に複雑なストリーム暗号は、ビットの擬似ランダムストリーム、すなわち鍵ストリームを生成し、これをｘｏｒを用いて暗号化されるデータと結合することができる。鍵ストリームは、鍵スケジューリングアルゴリズムを用いて生成される。鍵スケジューリングアルゴリズムでは、内部配列が所定の長さのＩＤ並べ替えで初期化される。所定の長さに等しいラウンド数の間、内部値の現在値、ラウンド数に対応する内部配列の位置に格納されている値、及びラウンド数と鍵の長さのモジュロを実行することによって決定される鍵の位置の値を加算することによって、内部値が導出される。そして、この演算の結果と最大ラウンド数のモジュロを内部値に設定する。ラウンドを終了するには、ラウンド番号と内部値でインデックスされた位置の内部配列の値を交換する。鍵スケジュールアルゴリズムが終了すると、擬似乱数生成アルゴリズムが内部配列の状態を変更し、鍵束の１バイトを出力する。暗号化されたデータは、鍵ストリームの出力バイトと暗号化されるデータのバイトをｘｏｒｉｎｇすることで実現される。擬似乱数生成アルゴリズムの各反復において、第１の内部値がインクリメントされる。第２の内部値には、第１の内部値の位置の内部配列の値によってインクリメントされた値が割り当てられる。第１の内部値と第２の内部値でインデックスされる位置の内部配列の値が交換される。そして、第１の内部値と第２の内部値を加算した位置の内部配列の値が鍵ストリームの値として出力される。内部配列のインデックスに値が使用されるインデックスアウトオブバウンズエラーを防ぐために、値と内部配列の長さとの間でモジュロを実行することができる。

【0079】

更に、ブロック暗号又はストリーム暗号の実装は、既知の弱点又は攻撃ベクトルに基づいて選択することができる。一例として、悪意のあるサードパーティーに関する最悪のシナリオを評価する方法として、暗号に対する既知の攻撃を評価し、センサ１１０の全アクティブ使用寿命の間など、生成されるデータの量と比較することができる。上述したように、幾つかの鍵はデバイス固有値から派生しており、そのため、単一の鍵又は暗号を含むことで潜在的な影響を低減することができる。更に、サプライチェーンレベルの攻撃、例えばルート鍵の値を知るために必要な妥協された値の量は、このような攻撃の実用性を著しく制限する。本明細書で説明するように、センサ１１０は、ＳＥＫのためにランダムに生成された鍵を使用し、ＳＥＫに対する鍵回復の試みは、長期的な価値をほとんど持たない。

【0080】

本明細書で具現化するように、暗号の特定の実装、例えば、ブロックサイズ及び鍵サイズの選択は、通信モジュール（例えば、通信モジュール２４０及び通信モジュール３４０）がサポートする様々な通信インタフェースを介して送信されるデータブロックのサイズに基づいて行われ得る。例えば、本明細書で具現するように、ＮＦＣ又はＢＬＥを介して伝送されるデータブロックは、８バイト境界で整列されることができ、６４ビット暗号ブロックサイズが選択することができる。本明細書で具現化されるように、暗号の特定の実装は、所望の暗号化強度に基づいて行われ、選択暗号ブロックサイズの変更をもたらすことができる。より強力な暗号は、典型的には、より多くの計算オーバーヘッドを含み、例えば、相互認証交換の間、データを復号化するための追加の時間を課す。更に、暗号ブロックサイズは、センサ１１０のＡＳＩＣ２００のマイクロコントローラ２１０の計算アーキテクチャと、センサ１１０とデータ受信デバイスとの間で使用される通信プロトコルとに基づいて選択することができる。本明細書で具現化されるように、鍵サイズは、使用されるコンピュータプラットフォームの特定のメモリ制約に基づいて選択することができる。

【0081】

本明細書で具現化されるように、センサ１１０は、認証のために別個のセンサ認証鍵（「ＳＡＫ」）を使用することができる。説明されるように、ＳＡＫは、セキュリティチャレンジで構成される認証交換を保護するために使用される。ＳＡＫは、データ受信デバイスに利用可能なルート鍵と、センサ固有のセキュリティパラメータとから導出されるセンサ固有の鍵である。ルート鍵は、専用データ受信デバイス１２０又は多目的データ受信デバイス１３０によって保存され、センサ認証中に使用することができる。各ＳＡＫは、各認証交換のためにデータ受信デバイスによって導出することができる。ＳＰは、各ＳＡＫを導出するために鍵導出機能によって使用される前に、通信中に変換の対象となる。暗号文の出力（ＳＡＫ）やＳＰがどのように変換されて鍵導出機能で使用されるかを知らなければ、攻撃者は平文の入力を欠き、ルート鍵を攻撃できないため、このセキュリティアーキテクチャでは安全性が確保される。暗号化交換の際、最初の暗号化ブロックには送信者が生成した乱数値と、変換されたセキュリティチャレンジが含まれる。乱数値と暗号化されていない変換の両方にアクセスできなければ、攻撃者はＳＡＫを攻撃するために平文入力を採取する機会を与えられないため、このセキュリティアーキテクチャの下での安全性が確保される。

【0082】

本明細書で具現化されるように、センサ１１０は、データ受信デバイスからの要求に対して、平文応答又は暗号化応答の何れかで応答するように構成することができる。プレーンテキスト応答を引き出す応答は、認証を伴わないコマンドを含む。限定ではなく一例として、非認証コマンドは、センサ１１０がセンサＵＩＤとソフトウェアバージョンを返すセンサ情報検索（ＳＩＲ）コマンドを含むことができる。暗号化された応答は、例えば、センサ固有の導出鍵ＳＡＫ又はセンサ固有のランダム鍵ＳＥＫによって保護される。認証交換はＳＡＫで保護され、メモリブロックの読み取りなどの通信リンク上のデータ通信はＳＥＫで保護されることが可能である。

【0083】

認証されたコマンドは、コマンド要求が指定されたフォーマットに従うことを含むことができ、フォーマットのための値は、以前の交換から同期される。この方法は、サードパーティーからのランダムなプロービングの影響を軽減するために使用することができる。認証されたコマンドの形式は、製造者又はサービスプロバイダのみが利用可能な専有情報として保持することができる。認証されたコマンド要求を発行する前に、データ受信デバイス及びセンサ１１０は、最初に交換チャレンジ（例えば、送信者チャレンジレスポンス（ＳＣＲ）及び受信者チャレンジレスポンス（ＲＣＲ））に対する値を同期させ、初期ノンスを同期させることができる。同期化は、セキュリティチャレンジメッセージの交換を完了することによって達成することができる。

【0084】

本明細書で具現化されるように、チャレンジランダム値（例えば、ＳＣＲ及びＲＣＲ）は、例えば、センサ１１０又はデータ受信デバイスの通信モジュールによって提供される真のランダム値発生器関数から供給することができる。セキュリティチャレンジは、固有のペイロードとして交換され、認証されたコマンドを送信又は検証するときに認証パラメータとして後で使用するために永続的なメモリに保存されることが可能である。ノンスは、センサ１１０に保存されたＡＦＶ及び他の内部状態変数から導出することができる。

【0085】

これらのセキュリティ交換値を検証することに加えて、リプレイ攻撃及び信号漏洩などの攻撃に対して低電力医療モニタリングシステム１００を堅固にするために、追加のセキュリティ機能を実行することができる。一例として、認証されたコマンドを実行する前に、センサ１１０は、ＳＣＲ及びＲＣＲの値が現在の交換に対して有効であることを検証するように構成することができる。認証されたコマンドが正常に完了すると、リプレイ攻撃を防ぐために、センサ１１０は、認証されたコマンドカウンタを増加させ、ＳＣＲ及びＲＣＲの状態を現在の交換関連で無効とすることができる。別の例として、データ受信デバイスがセキュリティチャレンジレスポンスの後に不適切な認証トークンを送信する場合、信号漏れを回避するために、センサ１１０は有効な応答を提供しないように構成することができる。

【0086】

限定ではなく例示の目的で、図６に示されるような開示された主題と共に使用するためのセンサ１１０のメッセージング応答状態マシン６００の例示的な実施形態を参照することがなされる。図６は、センサ１１０のメッセージング応答状態マシン６００を示す。状態マシン６００は、３つの状態、すなわち、センサ１１０がプログラムすることができる開放プログラム可能状態（ＯＰＥＮ ６１０）及び２つの通常状態（ＳＴＡＮＤＡＲＤ ６２０、ＡＵＴＨ ６３０）を反映している。本明細書で具現化されるように、状態ＯＰＥＮ６１０において、センサ１１０は、プログラムされ、再プログラムされ、個人化されることが可能であることである。例えば、デバッグ及び再プログラムのためのセンサ１１０のＡＳＩＣ２００上のポートが、イネーブルにすることができる。センサ１１０が遠隔／非製造者使用のために提供される前に、センサ１１０は、暗号化初期化コマンド６４０を受信すると、第１の通常状態ＳＴＡＮＤＡＲＤ６２０に遷移させることができる。

【0087】

２つの通常状態ＳＴＡＮＤＡＲＤ６２０のうちの第１の状態において、センサ１１０は、全てのサポートされた標準メッセージ６６０及びセキュリティチャレンジメッセージ６５０に応答するように構成することができる。有効なコマンドを受信すると、センサ１１０は、図示のようにＳＴＡＮＤＡＲＤ ６２０に戻るように遷移する。この状態でセンサ１１０が認証されたコマンド６６５を受信すると、センサ１１０は、決定論的な値で応答するか、全く応答しないことができる。センサ１１０がセキュリティチャレンジメッセージ６５０を受信した場合、センサ１１０は、要求をサービスし、上述のように認証のネゴシエーションに成功すると、ＡＵＴＨ６３０と示された状態に遷移することができる。

【0088】

本明細書で具現化されるように、ＡＵＴＨ状態６３０は、センサ１１０が認証されたコマンド６７０の要求を受信し応答することに加えて、ＳＴＡＮＤＡＲＤ状態６２０で利用できる全ての標準コマンド６６０を受信し応答することによって特徴付けることができる。センサ１１０が適切に認証されたコマンドを受信する場合、センサは、コマンドをサービスし、ＳＴＡＮＤＡＲＤ状態６２０に戻るように遷移することができる。

【0089】

一例の認証されたコマンドは、相互認証コマンドであり得る。本明細書で具現化されるように、通信モジュール－インタフェース境界における相互認証機能は、構成要素間のデータパスの完全性を検証することができる。本明細書で具現化するように、相互認証は、チャレンジ－レスポンスを介して秘密鍵の確立を検証するために、オンラインの信頼できるサードパーティーを伴わない２つのエンティティの互いに対する認証のためのメカニズムに基づくことが可能である。

【0090】

一例として、限定するものではないが、相互認証機能は、センサ１１０及びデータ受信デバイスが認証される２パス認証を実装することができる。センサ１１０は、認証要求を送信することによって、又は、データ受信デバイスに第１のトークンを生成して送信することによって、シーケンスを開始することができる。第１のトークンは、以前に確立された暗号方式（例えば、事前共有鍵及び暗号関数）に従って暗号化することができる。第１のトークンは、時変値又はシーケンシャル値、送信側に対応する識別子、識別定数値、及びテキストフィールドを含むことができる。データ受信デバイスは、第１のトークンを受信すると、暗号化された部分を復号化することによってトークンを検証し、含まれる全ての値の正確性と期待値をチェックする。次に、データ受信デバイスは、第２のトークンを生成し、センサ１１０に第２に送信する。第２のトークンもまた、以前に確立された暗号化スキームに従って暗号化することができる。第２のトークンは、順次次の時間変動値又は順次値と、センサ１１０に対応する識別子と、データ受信デバイスに対応する識別子と、識別定数値と、テキストフィールドとを含むことができる。第２のトークンを受信すると、センサ１１０は、任意の暗号化された部分を復号化することによってトークンを検証し、任意の返された値を期待される送信値と比較することによって、全ての含まれる値の正確さと期待値をチェックする。トークンに含まれる値の順序は、選択された暗号アルゴリズムに関係なく、メッセージが無関係に見えるように、トークンの中で変化させることができる。

【0091】

限定ではなく例示の目的で、図７Ａに示されるような開示された主題と共に使用するための相互認証スキームの例示的な実施形態が参照される。図７Ａに関して、２パス相互認証スキームが説明される。相互認証スキームにおいて、認証要求７３１は、オプションで、要求側７２０（例えば、センサ１１０）と受信側７１０（例えば、データ受信デバイス）との間で交換することができる。要求側当事者７２０は、ステップ７３２において、第１のトークンＴｏｋｅｎＢＡを生成し、送信することができる。本明細書で説明するように、ＴｏｋｅｎＢＡは、時間変動値又はシーケンシャル値、要求側当事者７２０に対応する識別子、識別定数値、及びテキストフィールドを含むことができる。時変値は、例えば、トークンの生成に関連付けられたタイムスタンプ、又は認証要求の開始に関連付けられたタイムスタンプを含むことができる。連続値は、例えば、合意されたノンス関数を使用して生成されたノンスとすることができる。時間変動値及びシーケンシャル値は、トークンが不正なエンティティによってある時点で再使用されていないことを検証するために使用することができる。また、要求側当事者７２０に対応する識別子は、認可された当事者が要求側当事者７２０になりすまそうとしていないことを検証するために使用することができる。トークンを受信した後、受信側当事者７１０は、期待される鍵に従ってＴｏｋｅｎＢＡを復号し、トークンの内容を検証し、例えば、時間変動値が正確であること、及び識別子が適切なエンティティに対応することを検証することができる。期待される鍵は、例えば、事前共有された秘密値から導出される鍵であってもよいし、２つの当事者の識別情報に基づいて確立される鍵であってもよい。期待値の検証時に、受信側パーティー７１０は、第２のトークンＴｏｋｅｎＡＢを送信するように生成する。本明細書で説明するように、ＴｏｋｅｎＡＢはＴｏｋｅｎＢＡと同様であり、事前時間変動値、連続値に基づく次の値、要求側当事者７２０に対応する識別子、受信側当事者７１０に対応する識別子、識別定数値、及びテキストフィールドを含むことができる。これらの値は、要求側当事者７２０の利益のために同様の機能を果たす。一例として、要求側当事者７２０と受信側当事者７１０の両方に対する識別値を含めることで、要求側当事者７２０が交換を検証しながらその復号化プロセスを検証することを可能にすることができる。受信側当事者７１０は、ＴｏｋｅｎＡＢを暗号化し、ステップ７３３で、トークンを要求側当事者７３３に送信することができる。次に、要求側パーティー７３３は、合意された暗号方式を使用してトークンを復号化し、そこに含まれる情報を検証することができる。この相互認証プロセスを通じて、要求側当事者７２０及び受信側当事者７１０は、暗号化スキームが相互に受け入れ可能であり、通信の当事者が期待通りであることを検証することができる。

【0092】

別の例として、限定するものではないが、相互認証機能は、チャレンジ－レスポンスシーケンスにおけるランダム値のチェックに基づく３パス認証を実装することができる。チャレンジ－レスポンスシーケンスにおいて、データ受信デバイスは、チャレンジパラメータの要求をセンサ１１０に送信することによって、シーケンスを開始することができる。センサ１１０は、要求されたパラメータで応答することができる。次に、データ受信デバイスは、第１の認証トークンをセンサ１１０に提示することができる。センサ１１０は、第２の認証トークンを用いて応答することができる。本明細書で具現化されるように、セキュリティチャレンジメッセージに含まれる変数の長さ、例えば、ＳＣＲ及びＲＣＲは、可変であり得、発見の予測可能性を低減するために、暗号化ブロック境界と整合するか否かを選択することが可能である。更に、セキュリティチャレンジメッセージに含まれるパラメータＳＣＲ及びＲＣＲの順序は、選択された暗号アルゴリズムに関係なくメッセージが無関係に見えるように、認証トークンにおいて変化させることができる。

【0093】

限定ではなく例示の目的で、図７Ｂに示されるような開示された主題と共に使用するための相互認証スキームの例示的な実施形態が参照される。図７Ｂに関して、３パス相互認証スキームが説明される。３パス相互認証スキームでは、認証要求７４０が要求側当事者７２０（例えば、センサ１１０）によって開始されると、受信側当事者７１０（例えば、データ受信デバイス）は、図７Ｂに示すように平文チャレンジパラメータ７４１（Ｔｅｘｔで連結されたＲＡ）を返す。要求側パーティー７２０は、追加のチャレンジパラメータを発信し、チャレンジの表現と共にそれらのパラメータを暗号化されたトークン７４２（ＴｏｋｅｎＢＡ）に埋め込むことができる。受信側当事者７１０は、トークン７４２の内容を検証し、暗号文の可能な再生に対処するためにトークン内容を再順序付けした、要求側当事者７２０によって提供されたチャレンジパラメータの少なくとも表現を組み込んだ別のトークン７４３（ＴｏｋｅｎＡＢ）を返送することが可能である。本明細書で具現化されるように、暗号化されたトークンＴｏｋｅｎＡＢ ７４３は、チャレンジパラメータ間にコマンド固有のデータを含むことができる。このパラメータの交換によって、データ受信デバイスは、チャレンジパラメータＳＣＲを暗号化し、センサ１１０に幾つかの情報を示し、センサ１１０は、データ受信デバイスが認証され得ることを検証することを可能にする。この情報は、データ受信デバイスが事前共有秘密、ルート鍵…、及びＵＡＶなどのセンサ固有のパラメータからＳＡＫを正常に導出することができることを含む。この情報は、データ受信デバイスが、チャレンジパラメータＳＣＲをＲＣＲを有するメッセージに組み込むことによって、秘密メッセージプロトコルを正常に実装することができることも含む。この情報は、データ受信デバイスが、派生鍵ＳＡＫで暗号化し、同期されたノンス値を適用できることも含むことができる。

【0094】

認証トークンＴｏｋｅｎＢＡを受信して検証すると、受信側７１０（例えば、センサ１１０）は、パラメータＲＣＲを返す。その際、センサ１１０は、送信側当事者７２０（例えば、データ受信デバイス）に対して幾つかの情報を示し、そこからデータ受信デバイスは、センサ１１０が認証され得ることを検証することができる。この情報は、センサ１１０がＳＡＫの知識を有することを含む。この情報は、センサ１１０が認証トークンを復号して、ＳＡＫ及び同期されたノンスを用いてＲＣＲを回復することができることを含む。また、この情報は、センサ１１０が、メッセージプロトコルを実装し、予め定義された関数からの値の進行から導出される提供された同期ノンスに対して適切に導かれた後続ノンスと共にＳＡＫによって保護された新しいメッセージでＲＣＲを返すことができることを含んでいる。

【0095】

別の例として、限定するものではないが、相互認証機能は、センサ１１０及びデータ受信デバイスが、信頼できるサードパーティーの使用によって認証される４パス認証を実装することができる。４パス認証の間、データ受信デバイスは、第１のトークンを生成し、信頼できるサードパーティーに送信することによって認証を開始することができる。加えて、又は代替的に、認証は、センサ１１０がデータ受信デバイスに認証要求を送信し、データ受信デバイスが信頼できるサードパーティーにトークンを生成して送信することをトリガーすることから開始することができる。第１のトークンは、時間変動値、データ受信デバイスに対応する識別子、及びテキストフィールドを含むことができる。第１のトークンを受信すると、信頼されるサードパーティーは、データ受信デバイス及びセンサ１１０によって使用されるランダム鍵を生成し、応答するトークンを生成してデータ受信デバイスに送信する。応答するトークンは、２つの部分を含む。第１の部分は、第１の識別定数、時間変動パラメータ又はランダム値（第１の部分を第２の部分から区別するために使用される）、データ受信デバイスから受信した時間変動パラメータ、ランダム鍵、センサ１１０の識別子、及びテキストを含む。第２の部分は、第２の識別定数、別の時間変動パラメータ又はランダム値、ランダム鍵、データ受信デバイスの識別子、及びテキストを含む。応答するトークンの各部分は、２つの当事者間で事前に確立された暗号方式（例えば、事前共有鍵及び暗号関数）に従って暗号化することができる。第１の部分は、データ受信デバイスと信頼できるサードパーティーとの間で共有される鍵を使用して暗号化することができる。第２の部分は、信頼されるサードパーティーとセンサ１１０との間で共有される鍵を用いて暗号化することができる。

【0096】

データ受信デバイスは、応答するトークンを受信すると、データ受信デバイスと信頼できるサードパーティーとの間で共有される鍵を用いて任意の暗号化された部分を復号し、第１の部分の予想される時間変動パラメータ又はランダム値を確認する。データ受信デバイスは、センサ１１０の識別子の正しさを確認し、信頼されるサードパーティーに送信された時間変動パラメータを確認する。次に、データ受信デバイスは、応答済みトークンの復号化された部分からランダム鍵を取得し、トークンの第２の部分を抽出し、それを用いて、センサ１１０に送信するトークンを構築する。センサ１１０のためのトークンは、抽出された第２の部分と、別の時間変動値、データ受信デバイスの識別子、及びテキストを含む付加的な部分とを含む。そして、データ受信デバイスは、トークンをセンサ１１０に送信する。受信すると、センサ１１０は、データ受信デバイスの識別子と時間変動値のその値の正しさを確認する。センサは、信頼できるサードパーティーによって提供されたランダム鍵を含む第２の部分を復号化する。次に、センサ１１０は、信頼できるサードパーティーによって提供されるランダム鍵を用いて、データ受信デバイスのためのメッセージを暗号化して送信する。メッセージは、時間変動パラメータの最終的な順次次の値を含む。データ受信デバイスは、受信時に、信頼できるサードパーティーからのランダム鍵を用いてメッセージを復号化した後、メッセージの値が正しいことを検証する。前述と同様に、トークンに含まれる値の順序は、選択された暗号アルゴリズムに関係なく、メッセージが無関係に見えるように、トークンで変化させることができる。

【0097】

限定ではなく例示の目的で、図７Ｃに示されるような開示された主題と共に使用するための相互認証スキームの例示的な実施形態が参照される。図７Ｃに関して、４パス相互認証スキームが説明される。４パス相互認証スキームでは、認証要求７６０が要求側７２０（例えば、センサ１１０）によって開始されると、受信側７１０（例えば、データ受信デバイス）は、ステップ７６１において、信頼されるサードパーティー７１５（例えば、低電力医療モニタリングシステム１００に関連付けられたリモートクラウドサーバ１５０）に要求を送信する。要求は、少なくとも、時間的に変化する、反復不可能な値（ＴＶＡ）、要求側当事者７２０の識別子（ＩＢ）、及びテキストを含む。ＴＶＡは任意にランダム値とすることができる。このとき、リクエストは暗号化される必要はない。ステップ７６２で、信頼されるサードパーティーは、応答するトークンＴｏｋｅｎＰＡを生成し、送信する。ＴｏｋｅｎＰＡは、要求側当事者７２０と受信側当事者７１０との間の通信に使用するためのランダムな鍵を共有するために使用される。ＴｏｋｅｎＰＡは、それぞれが別個の鍵を使用して暗号化される２つの部分を含むことを特徴とする。第１の暗号化された部分は、信頼できるサードパーティー７１５と受信側パーティー７１０との間で共有される鍵を使用して暗号化される。第２の暗号化された部分は、信頼されたサードパーティー７１５と要求側当事者７２０（例えば、センサ１１０）との間で共有される鍵を用いて暗号化される。第１の部分は、ランダムな鍵、受信側パーティー７１０によって送信された時間変動する繰り返し不可能な値、要求側パーティー７２０の識別子、及びテキストを含む。第２の部分は、別の時間変動値、ランダム鍵、及び受信側パーティー７１０の識別子を含む。信頼されるサードパーティーは、ステップ７６２において、このトークンを受信側当事者７１０に送信する。

【0098】

受信側パーティー７１０は、ＴｏｋｅｎＰＡの最初の部分を復号化し、その内容を確認する。受信側パーティー７１０は、メッセージが鍵要求メッセージに対する以前の応答の繰り返しでないことを検証するために、時間変動値が受信側パーティー７１０によって送信されたものと一致することを検証することができる。また、受信側パーティー７１０は、要求側パーティー７２０のＩＤが正しいことを検証することができる。次に、受信側パーティー７１０は、要求側パーティー７２０に送信するためのＴｏｋｅｎＡＢを構築することができる。トークンＡＢは、トークンＰＡの暗号化された第２の部分（受信側パーティー７１０は、信頼されるサードパーティーと要求側パーティー７２０との間で共有される鍵にアクセスできないため、依然として暗号化されている）、及び信頼されるサードパーティーによって提供されるランダム鍵を使用して暗号化される別の部分を含む。この別の部分は、要求側の復号の正確さを確認するために使用される時間変動値を少なくとも含む。ステップ７６３で、受信側パーティー７１０は、このＴｏｋｅｎＡＢを要求側パーティー７２０に送信する。要求側当事者７２０は、トークンを受信し、まず、信頼できるサードパーティー７１５と要求側当事者７２０との間で共有される鍵を用いて暗号化された部分を復号化する。要求側７２０は、例えば、時変値の確認や、受信側７１０の身元が正しいことの確認など、暗号化された部分の情報を確認する。そして、要求側当事者７２０は、ランダム鍵を取得し、ランダム鍵を用いて暗号化されたＴｏｋｅｎＡＢの部分を復号化することができる。要求側パーティー７２０は、そこに含まれる時変値を確認する。

【0099】

次に、要求側パーティー７２０は、ステップ７６４で、ランダム鍵を使用して暗号化され、受信側パーティー７１０に送信されるトークンＴｏｋｅｎＢＡを生成する。ＴｏｋｅｎＢＡは、受信側パーティー７１０が、要求側パーティー７２０がランダム鍵を使用してメッセージを暗号化及び復号化する能力があることを確認できるように、少なくとも時間変動値及び他の情報を含むことができる。本明細書で具現化されるように、時間変動値は、適宜、ランダム値（例えば、ＲＣＲ、ＳＣＲ）を含むことができる。更に、トークン内の値の配置は、メッセージを傍受して解釈しようとする悪意のあるサードパーティーの難易度を更に高め、暗号文の再生に対処するために、事前に確立されたスキームに従って変化させることができる。

【0100】

別の例として、限定するものではないが、相互認証機能は、センサ１１０及びデータ受信デバイスが信頼できるサードパーティーの使用によって認証される５パス認証を実装することができる。５パス認証は、３パス認証と４パス認証のハイブリッドを含むことができる。特に、センサ１１０は、交換を開始し、ランダム値をデータ受信デバイスに送信することができる。このメッセージは、認証要求として解釈され得るか、又は、例えば、使用されるべきマルチパス認証のタイプが決定される、別の認証要求に従うことができる。データ受信デバイスは、ランダム値及び追加のランダム値を、信頼されるサードパーティーへのメッセージに含めることができる。信頼されるサードパーティーは、ランダム値に基づいて暗号鍵を生成し、それをデータ受信デバイスに提供することができる。データ受信デバイスは、暗号鍵を用いて暗号化されたメッセージでセンサ１１０に暗号鍵を提供することができる。データ受信デバイスは、データ受信デバイスによって生成された追加のランダム値を提供することもでき、そこからセンサ１１０が暗号鍵を導出することができる。また、センサ１１０は、データ受信デバイスに対して、暗号鍵を適切に受信したことを検証するための確認メッセージを送信することができる。

【0101】

限定ではなく例示の目的で、図７Ｄに示されるような開示された主題と共に使用するための相互認証スキームの例示的な実施形態が参照される。図７Ｄに関して、５パス相互認証スキームが説明される。５パス相互認証スキームでは、認証は、ステップ７７１において、要求側当事者７２０（例えば、センサ１１０において）が、受信側当事者（例えば、データ受信デバイス）にランダム値ＲＢを含むメッセージを送信することによって開始される。ランダム値は、本明細書で具現化されるように、平文チャレンジパラメータの形態をとり得る。他の相互認証スキームと同様に、認証は、オプションとして、要求側当事者７２０がエクスプレス認証要求を送信することから開始することができる。認証要求は、使用される認証スランダム鍵ムのタイプを識別するために使用することができ、これは、ランダム値ＲＢなどの追加の情報を受信側パーティー７１０に提供しなければならないかどうかを要求側パーティー７２０に通知することができる。

【0102】

受信側パーティー７１０は、ランダム値ＲＢを受信し、信頼できるサードパーティー７１５に対する要求を生成する。リクエストは、少なくとも新しいランダム値ＲＡ、ランダム値ＲＢ、要求側当事者７２０の識別子ＩＢ、及び任意選択でテキストを含むことができる。ステップ７７２で、受信側パーティー７１０は、このメッセージを信頼できるサードパーティー７１５に送信する。本明細書で具現化されるように、要求は、例えば、信頼されるサードパーティー７１５と受信側当事者７１０との間で共有されるランダム鍵を使用して、暗号化された方式で送信することができ、又は値の何れも機密であると予想されるため、任意選択的に平文で送信することができる。信頼されるサードパーティー７１５は、メッセージを受信し、トークンＴｏｋｅｎＰＡを生成することができる。ＴｏｋｅｎＰＡは、ランダム値ＲＡ及びＲＢに基づいて、要求側当事者７２０と受信側当事者７１０との間の通信に使用するためのランダム鍵を共有するために使用される。ＴｏｋｅｎＰＡは、それぞれが別個の鍵を用いて暗号化された２つの部分を含むことを特徴とする。第１の暗号化された部分は、信頼できるサードパーティー機関７１５と受信側当事者７１０との間で共有される鍵を用いて暗号化される。鍵は、漏洩した鍵のリスクを減少させるために、ランダム値ＲＡから導出することができる。第２の暗号化された部分は、信頼されるサードパーティー７１５と要求側７２０（例えば、センサ１１０）との間で共有される鍵を使用して暗号化される。鍵は、鍵が漏洩するリスクを減少させるために、ランダム値ＲＢから導出することができる。第１の部分は、ランダム鍵、ランダム値ＲＡ、要求側当事者７２０の識別子、及びテキストを含む。第２の部分は、ランダム値ＲＢ、ランダム鍵、及び受信側当事者７１０の識別子を含む。信頼されるサードパーティーは、ステップ７７３において、このトークンを受信側当事者７１０に送信する。

【0103】

受信側パーティー７１０は、ＴｏｋｅｎＰＡを受信すると、ＴｏｋｅｎＰＡの最初の部分を復号化し、その内容を確認する。受信側パーティー７１０は、メッセージが鍵要求メッセージに対する以前の応答の繰り返しでないことを保証するために、ランダム値ＲＡが正しいことを検証することができる。また、受信側パーティー７１０は、要求側パーティー７２０の身元が正しいことを検証することができる。次に、受信側パーティー７１０は、要求側パーティー７２０に送信するＴｏｋｅｎＡＢを構築することができる。トークンＡＢは、トークンＰＡの暗号化された第２の部分（受信側パーティー７１０は、信頼されるサードパーティーと要求側パーティー７２０との間で共有される鍵にアクセスできないため、依然として暗号化されている）、及び信頼されるサードパーティーによって提供されるランダム鍵を使用して暗号化される別の部分を含む。この別の部分は、要求側の復号の正確さを確認するために使用できる新しいランダム値（例えば、新しいチャレンジレスポンスパラメータ）と、ランダム鍵が現在の通信セッションに使用されることを検証するためのチャレンジパラメータとして要求側当事者７２０によって使用できるランダム値ＲＢとを少なくとも含む。ステップ７７４で、受信側パーティー７１０は、このＴｏｋｅｎＡＢを要求側パーティー７２０に送信する。要求側パーティー７２０は、トークンを受信し、まず、信頼できるサードパーティー７１５と要求側パーティー７２０との間で共有される鍵を用いて暗号化された部分を復号化する。要求側７２０は、例えば、乱数値ＲＢを確認し、受信側７１０の身元が正しいことを検証することによって、暗号化された部分の情報を確認する。そして、要求側当事者７２０は、ランダム鍵を取得し、ランダム鍵を用いて暗号化されたＴｏｋｅｎＡＢの部分を復号化することができる。要求者７２０は、そこに含まれる乱数値ＲＢも検証する。

【0104】

次に、要求側７２０は、ステップ７７５において、ランダム鍵を使用して暗号化され、受信側７１０に送信されるトークンＴｏｋｅｎＢＡを生成する。ＴｏｋｅｎＢＡは、少なくともＴｏｋｅｎＡＢで提供される新しいランダム値及び他の情報を含み、受信側パーティー７１０が、要求側パーティー７２０がランダム鍵を使用してメッセージを暗号化及び復号化する能力があることを確認できるようにすることができる。そして、新しいランダム値は、本明細書で説明するチャレンジ・レスポンス・トークンとして機能する。更に、トークン内の値の配置は、メッセージを傍受して解釈しようとする悪意のあるサードパーティーの難易度を更に高め、暗号文の再生に対処するために、事前に確立されたスキームに従って変化させることができる。

【0105】

本明細書で具現化されるように、認証されたコマンドは、上記のような相互認証交換の関連で発生する可能性がある。センサ１１０からのセキュリティチャレンジを完了した後、データ受信デバイスは、認証されたコマンドを発行するか、又は平文でのオペコードの形態で認証されたメッセージを送信し、その後、暗号化されたペイロードを送信することができる。暗号化されたペイロードのためのプロトコルは、コマンド又はペイロードの値に応じて変化する可能性がある。一例として、ペイロードの１つの形式において、暗号化されたペイロードは、ＲＣＲ、コマンドオプコード、及び鍵ＳＡＫと同期されたノンスから導出される後続のノンスで暗号化されたＳＣＲを含むことができる。ＳＣＲは、先行する相互認証交換から取得することができ、各コマンド要求に対して再生成することができる。ＲＣＲは、認証を完了するために、新たに生成され、応答でデータ受信デバイスに返すことができる。センサ１１０が、認証されたコマンドが正確なメッセージングプロトコルに従わないと判断した場合、認証されたコマンドは失敗することができる。特に、センサ１１０は、信号の漏洩を避けるために、任意に要求を確認しないことができる。認証されたコマンドに対する応答は、ＳＣＲとＲＣＲとの間のデータの指定されたコレクションを含み得、ペイロードは、鍵ＳＡＫと、認証されたコマンドと共に送信されたノンスの適切な後続ノンスとで暗号化されている。

【0106】

本明細書で具現化されるように、製造中、センサ１１０は、通信インタフェース（例えば、センサ１１０のＡＳＩＣ２００に組み込まれたＮＦＣインタフェース）を介して暗号化初期化コマンドメッセージを受信することによって、製造後の状態に設定されることが可能である。暗号化初期化コマンドは、センサ１１０に暗号化を適用させ、暗号化状態を不揮発性メモリにコミットさせる。この動作は、デバッグ及び再プログラミングのためにＡＳＩＣ２００上のポートを無効にするＡＳＩＣコマンドをトリガーすることもでき、更に汎用入力／出力（ＧＰＩＯ）ピンの再マッピングをトリガーすることもできる。

【0107】

本明細書で具現化されるように、専用データ受信デバイス１２０は、同様に、専用データ受信デバイス１２０のＡＳＩＣ２００の内部プログラムフラッシュがデバッグ及びプログラミングポートをロックした状態で出荷され、大量消去を行わないアクセスを防止したファームウェアロック状態でエンドユーザに提供することが可能である。このように、実行可能なイメージ（長期保存された機密データを含む）を改竄や閲覧から保護することができる。

【0108】

ＮＦＣ Ｉｎｉｔｉａｔｉｏｎ認証コマンドは、データ受信デバイスがセンサ１１０にＮＦＣスキャンで電力を供給し、センサアクティベーションコマンドとして機能するときに送信することができる。このイベントは、例えば、データ受信デバイスによってセンサ１１０が起動されるときに発生する可能性がある。スキャンデータは、セッション鍵（例えば、ＳＥＫ）により保護することができる。ＮＦＣ開始コマンドを開始するために、チャレンジ認証が成功すると、センサ１１０はセンサシークレット（ＳＳ）をデータ受信デバイスに送信することができる。データ受信デバイスは、ＳＳを使用してセッション鍵（ＳＥＫ）を導出することができる。その後、ＳＥＫは、センサ１１０及びデータ受信デバイスによって、適切なノンス及び例えばカウンタとしてのブロック番号を有する暗号の鍵として使用することができる。このアーキテクチャの下では、認証されたセンサ１１０及びデータ受信デバイスのみが、ＳＥＫの知識を提供されることが望ましい。

【0109】

追加の認証されたコマンドは、センサ１１０に追加の機能を実行させるために使用することができる。一例として、認証された要求情報コマンドは、ＳＥＫを導出するためにデータ受信デバイスによって使用されるパラメータを決定して返すようにセンサ１１０にさせるための認証されたコマンドであり得る。

【0110】

別の例として、通信初期化認証コマンドは、通信モジュール２４０の１又は２以上の機能に関連付けられたセンサ１１０の構成要素を有効にさせるために使用することができる。一例として、セキュリティ及びバッテリ寿命を維持するために、センサ１１０は、オプションとして、特定の通信機能（例えば、ＢＬＥ）を有効にした状態でユーザに配信されないようにすることができる。通信機能は、適宜、センサ１１０が起動されると有効にすることができる。一例として、ＢＬＥ通信は、センサ１１０が専用のデータ受信デバイス１２０又はデータ受信デバイスによってアクティベーションされると、利用可能になることができる。通信初期化コマンドは、センサアクティベーションコマンドとは別に発行することができ、又はセンサ１１０がセンサアクティベーションコマンドを受信することによって自動的にトリガーすることができる。通信初期化コマンドは、接続セッション中に後で使用するためのハードウェアアドレス及びバインディングＩＤ（「ＢＩＤ」）を返すことができる。

【0111】

限定ではなく例示の目的で、図８に示すような開示された主題と共に使用するためのメッセージシーケンス図８００の例示的な実施形態が参照される。図８は、一対のデバイス、特にセンサ１１０とデータ受信デバイス８０１との間のデータの例示的な交換を示すメッセージシーケンス図８００を示す。データ受信デバイス８０１は、本明細書で具現化するように、専用のデータ受信デバイス１２０又は多目的データ受信デバイス１３０とすることができる。ステップ８０５において、データ受信デバイス８０１は、例えば、センサ１１０と互換性のある近距離通信プロトコルを介して、センサ１１０にセンサアクティベーションコマンド８０５を送信することができる。センサ１１０は、ステップ８０５の前に、主に休止状態であり、完全なアクティベーションが必要とされるまでそのバッテリを保存することができる。ステップ８１０中のアクティベーション後、センサ１１０は、センサ１１０の医療用ハードウェア２６０に適切なように、データを収集するか、又は他の動作を実行することができる。ステップ８１０は、データの交換中に一度だけ発生するように示されているが、本明細書で具現化するように、ステップ８１０は、センサ１１０によって医療用ハードウェア８６０に適切なように連続的に実行することができる。

【0112】

ステップ８１０が最初に発生した後のある時点で、ステップ８１５において、データ受信デバイス８０１は、認証要求コマンド８１５を開始することができる。認証要求コマンド８１５に応答して、センサ１１０とデータ受信デバイス８０１の両方は、相互認証プロセス８２０に従事することができる。例えば、センサ１１０及びデータ受信デバイス８０１は、図７Ａ～７Ｄに関して例示され、本明細書で説明されるような相互認証プロセスを実行することができる。相互認証プロセス８２０は、センサ１１０及びデータ受信デバイス８０１が、他のデバイスが本明細書に記載されるセキュリティフレームワークを遵守する能力が十分にあることを検証することを可能にするチャレンジパラメータを含む、データの転送を含むことができる。例えば、相互認証プロセスは、データ受信デバイス８０１が、センサ１１０によってデータ受信デバイス８０１に提供されるセンサ固有な値及びランダム値に基づいてセンサ固有な認証鍵（例えば、ＳＡＫ）を導出することを含むことができる。

【0113】

成功した相互認証プロセス８２０に続いて、ステップ８２５で、センサ１１０は、データ受信デバイス８０１にセンサシークレット８２５（例えば、ＳＳ）を提供することができる。センサシークレットは、同様に、センサ固有値を含み、製造中に生成されたランダム値から導出することができる。センサシークレットは、サードパーティーがシークレットにアクセスするのを防ぐために、送信前又は送信中に暗号化することができる。本明細書で具現化されるように、センサの秘密を導出するために使用される値は、センサがセンサ１１０とデータ受信デバイス８０１との間の通信セッションに固有であるように、普遍的に固有であることができる。本明細書で具現化するように、センサシークレット８２５は、相互認証プロセス８２０によって又はそれに応答して生成された鍵のうちの１又は２以上を介して暗号化することができる。ステップ８３０において、データ受信デバイス８０１は、センサシークレットからセンサ固有暗号鍵（例えば、ＳＥＫ）を導出することができる。本明細書で具現化されるように、センサ固有暗号鍵は、更に、セッション固有であることができる。このように、センサ固有暗号鍵は、センサ１１０又はデータ受信デバイス８０１の間で伝送されることなく各デバイスによって決定され、ルート鍵、通信プロトコル、及び秘密情報にアクセスできるデバイスのみが、センサ固有暗号鍵によって暗号化されたデータを復号化することができるようにすることができる。

【0114】

ステップ８３５において、センサ１１０は、ペイロードに含まれるデータを暗号化することができる。適切な場合、データは、生体データ又は医薬品の配送試行の結果を含む、機密性の高い医療データを含むことができる。ステップ８４０で、センサ１１０は、センサ１１０とデータ受信デバイス８０１の適切な通信モデルの間に確立された通信リンクを用いて、暗号化されたペイロード８４０をデータ受信デバイス８０１に送信することができる。ステップ８４５で、データ受信デバイス８０１は、ステップ８３０の間に導出されたセンサ固有の暗号鍵を用いてペイロードを復号化することができる。ステップ８４５に続いて、センサ１１０は、追加の（新たに収集されたものを含む）データを配信することができ、データ受信デバイス８０１は、受信されたデータを適切に処理することができる。本明細書で具現化されるように、データ受信デバイス８０１は、ステップ８３０の間に導出されたセンサ固有の暗号鍵を用いて暗号化されたデータをセンサ１１０に更に送信することができる。センサ１１０は、ＡＳＩＣ２００のストレージ２３０に格納されたセンサ固有の暗号鍵を使用してデータを復号化することができる。

【0115】

本明細書で説明する実施形態は、適切な場合、図８の方法の１又は２以上のステップを繰り返すことができる。本開示は、図８の方法の特定のステップが特定の順序で発生するものとして説明及び図示するが、本開示は、図８の方法の任意の好適なステップが任意の好適な順序で発生することを企図するものである。更に、本開示は、図８の方法の特定のステップを含む機密医療データを暗号化して送信するための例示的な方法を説明及び図示するが、本開示は、適切な場合、図８の方法のステップの全て、幾つか、又はどれも含むことができる任意の適切なステップを含む機密医療データを暗号化して送信する任意の適切な方法を想定している。更に、本開示は、図８の方法の特定のステップを実施する特定の構成要素、デバイス、又はシステムを説明及び図示するが、本開示は、図８の方法の任意の適切なステップを実施する任意の適切な構成要素、デバイス、又はシステムの任意の適切な組み合わせを企図するものである。

【0116】

本明細書で具現化されるように、専用データ受信デバイス１２０は、ユーザコンピュータデバイス１４０、特にユーザコンピュータデバイス１４０上で実行される専用アプリケーションからの要求に対して、平文応答又は暗号化応答の何れかで応答するように構成することができる。プレーンテキスト応答を引き出す応答は、認証を伴わないコマンドを含む。限定ではなく、例証として、非認証コマンドは、暗号化接続を確立するために、専用データ受信デバイス１２０又は専用データ受信デバイス１２０のユーザを識別するために使用できる値を要求するコマンドを含むことができる。一例として、専用データ受信デバイス１２０は、ユーザコンピュータデバイス１４０からのこのようなコマンドに、リーダーＵＩＤ、ソフトウェアバージョン、ファームウェアバージョン、ユーザ個人化値、トークン化ユーザ識別などの情報を応答することができる。暗号化された応答は、例えば、ＳＡＫ又はＳＥＫに相当するリーダー固有の派生鍵又はリーダー固有のランダム鍵によって保護することができる。専用データ受信デバイス１２０は、認証ノンスを単調増加ではなく、予測不可能なシーケンス、例えば、関数へのアクセスを持たないものには予測不可能なシーケンスに変換する変換関数を使用することも可能である。本明細書で具現化するように、リーダーは、センサで使用される鍵とは異なる鍵を採用することができ、これは、悪意のある行為者がセンサ固有の鍵を取得し、その鍵を使用して専用データ受信デバイス１２０とユーザコンピュータデバイス１４０との間の交換を検証する攻撃を実施する、妥協又は特定の攻撃のリスクを低減することが可能である。

【0117】

本明細書で論じたように、センサ１１０は、処理能力、バッテリ供給、及びストレージが制限されたデバイスとすることができる。センサ１１０によって使用される暗号化技術（例えば、暗号アルゴリズム又はアルゴリズムの実装の選択）は、これらの制限に少なくとも部分的に基づいて選択することができる。専用データ受信デバイス１２０は、このような性質の制約がより少ない、より強力なデバイスとすることができる。従って、専用データ受信デバイス１２０は、暗号アルゴリズム及び実装など、より高度で計算量の多い暗号化技術を採用することができる。例えば、センサ１１０が軽量のブロック暗号を実装する場合、専用データ受信デバイス１２０は、より複雑な暗号を実装することができる。従って、専用データ受信デバイス１２０とユーザコンピュータデバイス１４０との間の通信は、使用される暗号化の高度なレベルに基づいて、より安全であると考えることができる。これは、専用データ受信デバイス１２０が、センサ１１０が記憶及び送信することが可能であるよりも、より大量の機密医療データをユーザコンピュータデバイス１４０に記憶及び送信することができるので、送信データの量に一致する。これはまた、データがセンサ１１０から遠く離れて送信され、傍受又は暴露のリスクが高くなるため、敏感な医療データでより大きなレベルの暗号化を強制する利点を提供する。

【0118】

本明細書で具現化されるように、認証されたコマンドは、コマンド要求が指定されたフォーマットに従うことを含み得、ここで、フォーマットのための値は、以前の交換から同期される。従って、専用データ受信デバイス１２０とユーザコンピュータデバイス１４０との間のインタフェースは、センサ１１０と専用データ受信デバイス１２０との間のインタフェースについて説明したのと同様の手順に従うことができる。この手順は、サードパーティーからのランダム化されたプロービングの試みの影響を低減するために使用することができる。認証されたコマンドフォーマットは、製造者１６０又はサービスプロバイダにのみ利用可能な専有情報として保持することができる。本明細書で具現化するように、認証されたコマンドフォーマットは、有線又は無線通信リンク上でセキュアにデータを伝送するためのセキュリティプロトコルに準拠する、又はこれに基づくことができる。本明細書で具現化するように、認証されたコマンド要求を発行する前に、専用データ受信デバイス１２０及びユーザコンピュータデバイス１４０は、最初に、交換チャレンジのための値を同期させ、初期ノンスを同期させることができる。

【0119】

本明細書で具現化するように、チャレンジランダム値は、例えば、専用データ受信デバイス１２０又はユーザコンピュータデバイス１４０の通信モジュール又はインタフェースによって提供される真のランダム値生成機能から供給することができる。ユーザコンピュータデバイス１４０は、更に、広域ネットワークに接続して、セキュリティプロバイダから真のランダム値を取得することができる。本明細書で具現化するように、セキュリティチャレンジは、固有のペイロードとして交換することができ、認証されたコマンドを送信又は検証するときに認証パラメータとして後で使用するために永続的なメモリに保存されることが可能である。

【0120】

認証スキームは、専用データ受信デバイス１２０とユーザコンピュータデバイス１４０との間の特定の通信リンクによってサポートされるセキュリティ機能を利用することができる。一例として、専用データ受信デバイス１２０及びユーザコンピュータデバイス１４０は、有線接続（例えば、ＵＳＢ）又は無線接続（例えば、Ｂｌｕｅｔｏｏｔｈ、ＮＦＣ、Ｗｉ－Ｆｉなど）を介して接続することができる。本明細書で具現化するように、これらの接続は、特定のデバイスドライバに関連付けられた特定のデバイスインタフェースと関連付けることができる。これらのデバイスドライバは、信頼できるサードパーティーによって管理され得るか、又は、専用データ受信デバイス１２０及びユーザコンピュータデバイス１４０上で実行される専有アプリケーションの製造業者及びプロバイダによって管理することができる。本明細書で具現化するように、ユーザコンピュータデバイス１４０及び専用データ受信デバイス１２０によって使用される暗号鍵は、デバイスドライバへの更新によって供給され得るか、又はデバイスドライバに更新された情報から導出することができる。更新された鍵は、確保されたデバイスの更新を通じて、ユーザコンピュータデバイス１４０から専用データ受信デバイス１２０に伝搬することができる。鍵は、このようなプログラムの更新を通じて頻繁に更新され、既存の鍵を使用することによる妥協のリスクを低減することができる。

【0121】

前述したように、多目的データ受信デバイス１３０又はユーザコンピュータデバイス１４０は、リモートクラウドサーバ１５０と通信することができる。デバイスは、機密性の高い医療データ、医療データに関する統計分析、警告及び推奨、デバイスソフトウェア及びファームウェアの更新、セキュリティアーキテクチャに関する更新（例えば、様々なデバイスによって使用及びサポートされる認証鍵の更新）を含むが、これらに限定されない様々なタイプの情報を交換することが可能である。簡略化のため、以下の議論は、ユーザコンピュータデバイス１４０、又はユーザコンピュータデバイス１４０上で実行される独自のアプリケーションが、リモートクラウドサーバ１５０とデータを交換することに言及する。ユーザコンピュータデバイス１４０の機能を説明する実施形態は、多目的データ受信デバイス１３０と共に使用するために適合させることができることを理解されたい。更に、本明細書に具現化されるように、リモートクラウドサーバ１５０への機密データのアップロードは、ユーザによって管理及び制御することができる。例えば、ユーザは、分析のためにリモートクラウドサーバ１５０に送信されるデータの量及び性質を制限するために、プライバシー設定を設定することができる。更に、ユーザコンピュータデバイス１４０は、広域ネットワークにアクセスすることなく、リモートクラウドサーバ１５０の高度な分析機能の一部又は全部を実行するように構成することができる。ユーザは、リモートクラウドサーバ１５０へのアクセスを回避しながら、リモートクラウドサーバ１５０と関わることを選択したユーザと同じレベルの分析及びデータ収集にアクセスすることが可能である。

【0122】

リモートクラウドサーバインタフェースの一般的な特性は、セキュリティアーキテクチャに関して本明細書に記載される他のデバイスインタフェースと広く類似する可能性がある。一例として、ユーザコンピュータデバイス１４０は、リモートクラウドサーバ１５０からの要求に対して、平文応答又は暗号化応答の何れかで応答するように構成することができる。関連して、リモートクラウドサーバ１５０とユーザコンピュータデバイス１４０との間の通信は、双方向であり得る。プレーンテキスト応答を含む通信は、認証を伴わないコマンドを含むことができる。限定ではなく、例証として、非認証コマンドは、暗号化接続を確立するために、ユーザコンピュータデバイス１２０又はそのユーザを識別するために使用することができる値を要求するコマンドを含むことができる。暗号化された応答は、例えば、ＳＡＫ又は固有のランダム鍵と同等のユーザ又はユーザコンピュータデバイスに関連付けられた固有の鍵によって保護することができる。ユーザコンピュータデバイス１４０は、センサ又はリーダーで使用される鍵とは異なる鍵を採用することもでき、これによって、悪意のある行為者が例えばセンサ固有の鍵を取得し、その鍵を使用して専用データ受信デバイス１２０とユーザコンピュータデバイス１４０間の交換を検証しようとする妥協又は特定の攻撃のリスクを低減することが可能である。

【0123】

センサ１１０及び専用データ受信デバイス１２０と比較して、多目的データ受信デバイス１３０及びユーザコンピュータデバイス１４０は、利用可能な処理能力、バッテリ供給、及びストレージに対する比較的な制約を有しないことが可能である。従って、多目的データ受信デバイス１３０及びユーザコンピュータデバイス１４０は、複雑な暗号アルゴリズム及び実装など、著しく複雑な暗号化及び認証技術を採用するように構成することができる。従って、多目的データ受信デバイス１３０とリモートクラウドサーバ１５０、又はユーザコンピュータデバイス１４０とリモートクラウドサーバ１５０との間の通信は、使用される暗号化の高度なレベルに基づいて、より安全であると考えることができる。更に、ユーザコンピュータデバイス１４０は、多くの点で患者１７０の機密医療データのリポジトリとして機能し、患者１７０について収集された大量の（場合によっては全てを含む）機密医療データを送信できるため、これは送信されるデータの量及び性質に合致する。これはまた、データがセンサ１１０及びデータ受信デバイスから遠く離れて送信され、傍受又は暴露のリスクが高くなるため、機密医療データでより大きなレベルの暗号化を強制する利点を提供する。保管中及び転送中の機密医療データを保護するために、独自の暗号化アルゴリズム及び業界標準の暗号化アーキテクチャをミックスして、暗号化の幾つかの段階を使用することができる。一例として、機密医療データは、多目的データ受信デバイス１３０とリモートクラウドサーバ１５０、又はユーザコンピュータデバイス１４０とリモートクラウドサーバ１５０との間の伝送前又は伝送中に、相互に合意した暗号鍵（例えば、本明細書に記載の相互認証スキームを使用して決定）を使用して暗号化することが可能である。暗号化されたペイロードのパケットは、ＨＴＴＰＳ、ＳＦＴＰ、ＦＴＰＳ、ＳＳＬ、ＳＳＨなどを含むがこれらに限定されない、セキュアな転送プロトコルを介して更に配信されることが可能である。保護された転送プロトコルを介して接続を確立するための認証情報は、本明細書に記載されるものと同様のセッション、デバイス、又は－ユーザ固有の鍵に更に基づくことができる。

【0124】

本明細書で具現化されるように、ユーザコンピュータデバイス１４０とクラウドサーバ１５０との間の通信リンクは、特定のデバイスドライバに関連付けられた特定のデバイスインタフェースと関連付けることができる。これらのデバイスドライバは、信頼できるサードパーティーによって管理され得るか、又は低電力医療モニタリングシステム１００の製造業者及びプロバイダによって管理することができる。一例として、プロバイダは、通信リンクの確立を容易にするために、セキュリティで保護されたドライバを生成することができる。保護されたドライバは、リモートクラウドサーバ１５０が、適切なソフトウェアバージョンレベルに更新されたドライバ（及び暗号鍵）を有するユーザコンピュータデバイス１４０としか通信できないように、ソフトウェア及びバージョンの更新に結び付けられることができる。このようにして、低電力医療モニタリングシステムは、時間の経過と共に発見され、又は侵害された可能性がある鍵が、システム全体を侵害するために使用されないことを保証することができる。更新された鍵は、リモートクラウドサーバ１５０から、又は専有アプリケーションのプロバイダから、セキュアなデバイス更新を通じてユーザコンピュータデバイス１４０に伝搬されることが可能である。鍵は、このようなプログラムの更新を通じて頻繁に更新され、既存の鍵を使用することによる侵害のリスクを低減することができる。

【0125】

本明細書で具現化されるように、ユーザコンピュータデバイス１４０又は多目的データ受信デバイス１３０は、センサ１１０又は専用データ受信デバイス１２０との保護された通信を介して受信したデータが、ユーザコンピュータデバイス１４０又は多目的データ受信デバイス１３０上で復号されないパススルー方式で動作するように構成することができる。一例として、多目的データ受信デバイス１３０は、広域ネットワークに接続する能力を持たないセンサ１１０がリモートクラウドサーバ１５０にデータを送信するための方法としてのみ機能することができる。多目的データ受信デバイス１３０は、機密医療データを暗号化するために使用される鍵さえも知らずに動作することができる。このような場合、鍵（例えば、ＳＥＫ）は、センサ１１０及びリモートクラウドサーバ１５０によって知ることができ、一方、別の鍵（例えば、ＳＡＫ）は、多目的データ受信デバイス１３０がセンサ１１０と通信できることを検証するために使用され、センサ１１０に代わってリモートクラウドサーバ１５０と通信することも可能である。

【0126】

限定ではなく例示の目的で、図９に示すような開示された主題と共に使用するためのメッセージシーケンス図９００の例示的な実施形態が参照される。図９は、一対のデバイス、特にユーザコンピュータデバイス１４０とリモートクラウドサーバ１５０との間のデータの例示的な交換を示すメッセージシーケンス図９００を示す。本明細書で具現化するように、多目的データ受信デバイス１３０は、本明細書で説明するように、ユーザコンピュータデバイス１５０上で実行する専有アプリケーションの機能の多く又は全てを実行するように構成することができる。従って、図９は、多目的データ受信デバイス１３０とクラウドサーバ１５０との間で交換されるデータのメッセージシーケンス図を説明するためにも役立ち得る。

【0127】

ステップ９０５で、ユーザコンピュータデバイス１４０は、リモートクラウドサーバ１５０との接続を開始しようとすることができる。ユーザコンピュータデバイス１４０は、要求を送信し、リモートクラウドサーバ１５０から、接続が利用可能であること、又は予備接続が正常に確立されたことを示す確認応答を受信することができる。本明細書で具現化するように、この接続は、１又は２以上の従来からセキュアな通信プロトコル（例えば、ＨＴＴＰＳ、ＴＬＳ／ＳＳＬ、ＳＦＴＰなど）を使用して行うことができ、又は安全ではないがより効率的な通信プロトコルを使用して行うことができる。ユーザコンピュータデバイス１４０によって収集された機密医療データに対するセキュリティ強化の要望に鑑みて、ユーザコンピュータデバイス１４０及びリモートクラウドサーバ１５０は、機密データを適切に保護、暗号化、及び送信するための一連のステップを実施することが可能である。本明細書で具現化するように、ユーザコンピュータデバイス１４０がリモートクラウド１５０との接続を確立できない場合、接続を確立しようとする試みを一定の間隔で続けることができる（例えば、１秒ごと、１０秒ごと、６０秒ごとなど）。接続の確立を試みている間、ユーザコンピュータデバイス１４０は、より長期の保存のために収集されたデータを確保することができる。例えば、ユーザコンピュータデバイス１４０は、データを高度に粒状レベルで保持し、データがリモートクラウドデバイス１５０にアップロードされたことが確認できるまで、粒状バックアップなしでデータの破壊又はデータの要約を避けるように指示することができる。ユーザコンピュータデバイス１４０は、ストレージ容量がフル稼働に近づいていることをユーザに警告し、ユーザコンピュータデバイス１４０が接続が可能であることを確認しようとする間、追加のストレージ能力を提供することをユーザに潜在的に奨励することができる。

【0128】

ステップ９１０において、ユーザコンピュータデバイス１４０がリモートクラウドサーバ１５０への接続を確認できると、ユーザコンピュータデバイス９１０は、リモートクラウドサーバ１５０によって配信されるべきデバイス更新を確認するように構成することができる。例えば、リモートクラウドサーバ１５０は、ユーザコンピュータデバイス１４０がリモートクラウドサーバにデータをアップロードすることができる前に、ユーザコンピュータデバイス１４０にセキュリティアップデートを配信することができる。リモートクラウドサーバ１５０は、低電力医療モニタリングシステム１００内の他のデバイスに提供されるべきデバイスアップデート（例えば、ソフトウェアアップデート、ファームウェアアップデート）を更に提供することができる。例えば、リモートクラウドサーバ１５０は、過去にユーザコンピュータデバイス１４０が通信可能な専用のデータ受信デバイス１２０にインストールされるべきデバイスアップデートを渡すことができる。

【0129】

ステップ９１５において、リモートクラウドサーバ１５０は、任意の適切なデバイスアップデートを配信することができる。ユーザコンピュータデバイス１４０は、例えば、製造者が提供する認証及び完全性チェック鍵でデバイスアップデートの完全性を検証した後、必要に応じてそれらのアップデートをインストールすることができる。

【0130】

デバイスアップデートのチェックに加えて、ユーザコンピュータデバイス１４０は、他の通知及びアップデートについてリモートクラウドサーバ１５０に要求するように構成することができる。一例として、ユーザコンピュータデバイス１４０は、ユーザに対するメッセージのためにリモートクラウドサーバ１５０にチェックインすることができる。メッセージは、例えば、リモートクラウドサーバ１５０によって処理される機密医療データに関する更新、本明細書に記載されるようにリモートクラウドサーバ１５０によって実行されるデータマイニングからの結果を要約した更新、低電力医療モニタリングシステムに関するニュース及び製品情報等を含むことができる。リモートクラウドサーバ１５０は、通知をユーザコンピュータデバイス１４０に配信して、ユーザに表示させることができる。

【0131】

ステップ９２０において、ユーザコンピュータデバイス１４０は、データのためのアップロード先を決定することができる。一例として、低電力医療モニタリングシステム１００は、例えば、患者又はユーザコンピュータデバイス１４０のアイデンティティ、患者又はユーザコンピュータデバイス１４０の位置、データの意図された使用などに応じて、データをアップロードすることができる様々な宛先を提供することができる。一例として、患者は、特定の地理的位置があるリモートクラウドサーバ１５０のみを機密医療データに使用できることを義務付けるデータプライバシー制御を有する司法管轄区域にいることが可能である。ユーザコンピュータデバイス１４０（又は任意にリモートクラウドサーバ１５０）は、どの宛先がデータにとって適切であるかを決定することができる。別の例として、ユーザコンピュータデバイス１４０（又は任意選択でリモートクラウドサーバ１５０）は、機密医療データのより高速で安定したアップロードを提供する可能性が高いリモートクラウドサーバ１５０を決定することができる。更に別の例として、低電力医療モニタリングシステム１００は、個別の個人医療データに加え、大規模な公共データの収集をサポートするリモートクラウドサーバを含むことができる。低電力医療モニタリングシステム１００は、公衆衛生の取り組みをサポートするため、ユーザにアプリケーションサポートを提供するため（例えば、デバイスとのエラーを特定し決定するため）、患者のための大規模分析を提供するため等に、このような収集を提供することができる。

【0132】

アップロード先の選択に基づいて、ユーザコンピュータデバイス１４０は、送信されるデータの性質を決定し、データを非特定化又は匿名化することができるステップ９２５を実行することができる。アップロードに含まれるべきデータは、ライブで収集されたデータ（例えば、センサ１１０から最近受信したデータ）を含むことができ、患者１４０に関連付けられた履歴データを含むことができる。一例として、ユーザコンピュータデバイス１４０は、患者について収集されたデータが新鮮且つ正確であることを保証するために、継続的に又は短期間にわたってデータを収集するように構成することができる。しかしながら、ユーザコンピュータデバイス１４０は、そのデータをリモートクラウドサーバ１５０にアップロードする前に、そのデータをより大きな塊にパッケージ化するように構成することができる。例えば、血糖値モニタリングに関連付けられた個々の測定値は、比較的小さくすることができる。接続を確立し維持するための手順中に交換されるデータの量は、個々の測定値のサイズよりも大きくなり得る。従って、ユーザコンピュータデバイス１４０が各測定値を到着したときにアップロードすることは、非効率的であり得る。ユーザコンピュータデバイス１４０は、ターゲットペイロードのサイズ（例えば、ファイルサイズ、測定値の数など）、測定値に関連付けられた時間（例えば、ターゲット期間をカバーする）、データが最後にアップロードされてからの時間などに基づいて、送信のためにデータをパッケージ化することが可能である。

【0133】

例えば、ユーザコンピュータデバイス１４０は、データが収集された患者のあらゆる個人識別情報をデータから取り除くことができる。ユーザコンピュータデバイス１４０は、特定の個人を決定するために使用できる情報（例えば、データを収集するために使用された特定の専用データ受信デバイス１２０のアイデンティティ）も除去することができる。データを匿名化することによって、低電力医療モニタリングシステムは、患者のプライバシー及び機密性の取り組みを支援する一方で、研究及び公衆衛生の決定のためにこのような匿名データに依存するプログラムを支援していると理解することができる。データを非特定化した後、ユーザコンピュータデバイス１４０は、確立された接続を使用して、収集されたデータをリモートクラウドサーバ１５０に単にアップロードすることができる。

【0134】

本明細書で具現化されるように、ユーザコンピュータデバイス１４０は、セキュリティアーキテクチャの下で実行する方法として、メッセージフロー９００で概説されるプロセスに従い続けることができる。更に、ユーザコンピュータデバイス１４０によって実行されるものとして説明したが、データがユーザコンピュータデバイス１４０に送信される前に、専用データ受信デバイス１２０又は多目的データ受信デバイス１３０などの低電力医療モニタリングシステムの他のデバイスによって、又はデータがユーザコンピュータデバイス１４０によって送信された後にリモートクラウドサーバ１５０によって機密医療データが非特定化することができる。

【0135】

ステップ９３０において、ユーザコンピュータデバイス１４０及びリモートクラウドサーバ１５０は、相互認証交換、例えば、本明細書で説明する相互認証交換を実行して、デバイスが同じルート鍵及び他のセキュリティ鍵情報にアクセス及び処理できることを検証する可能性がある。本明細書で具現化するように、この交換に使用されるルート鍵及びデバイス固有鍵は、センサ１１０と多目的データ受信デバイス１３０又は専用データ受信デバイス１２０とユーザコンピュータデバイス１４０などの間の交換に使用されるルート鍵及びデバイス固有鍵と異なることができる。ステップ９３５において、ユーザコンピュータデバイス１４０は、デバイス秘密９３５をリモートクラウドサーバ１５０に送信することができ、デバイス秘密は、機密医療データを含むペイロードを送信する間に用いられる暗号の基礎を形成するデバイス固有の暗号鍵を導出するために用いられる情報の一部を形成することができる。本明細書で具現化するように、デバイスシークレットは、９３５で送信される特定のデバイスシークレットがユーザコンピュータデバイス１４０とリモートクラウドサーバ１５０との間の通信セッションに固有であることを保証するランダム値を含むことができる。デバイスシークレットは、サードパーティーがシークレットにアクセスすることを防止するために、送信前又は送信中に暗号化することができる。ステップ９４０において、リモートクラウドサーバ１５０及びユーザコンピュータデバイス１４０は、デバイス固有暗号鍵を導出することができる。

【0136】

本明細書で具現化されるように、デバイス固有の暗号鍵を決定するための本明細書に記載される相互認証プロセス又は手順は、ユーザコンピュータデバイス１４０及びリモートクラウドサーバ１５０の両方が、特定の認証又は暗号鍵とそれを導出したデバイスとの間の固有の対応付けを確立することも可能にすることができる。例えば、ユーザコンピュータデバイス１４０及びリモートクラウドサーバ１５０はそれぞれ、通信のある後の時点で、デバイス固有の暗号鍵を使用して暗号化されたデータ（又は他のデバイスによって送信されたデータ）が正しいデバイスによって暗号化されたことを検証できるように、他のデバイスとの通信に使用された鍵をそのデバイスに関連付けることができる。そうすることで、本明細書に記載のセキュリティプロトコルは、サードパーティーがデータ送信に関わる認証情報を取得し、その認証情報をサードパーティーに関連付けられたものであるかのように使用しようとする、いわゆる「マンインザミドル攻撃」を回避するために使用することができる。例えば、相互認証中に使用された認証鍵又はデバイス固有の暗号鍵を使用して「証明書ピン留め」を実行することによって、ユーザコンピュータデバイス１４０及びリモートクラウドサーバ１５０はそれぞれ、２つのデバイス間で送信されたデータパケットを他の当事者が傍受していないことを独立して検証することができる。

【0137】

ステップ９４５で、ユーザコンピュータデバイス１４０は、デバイス固有の暗号鍵を使用して、機密医療データ（例えば、患者の個人識別情報を含む医療データ）を含むペイロードを暗号化することができる。先に説明したように、ユーザコンピュータデバイス１４０は、より大きなコンピュータパワーのストアにアクセスできるので、ユーザコンピュータデバイス１４０は、低電力医療デバイスモニタリングシステム内のあまり強力でないデバイスによって使用できる暗号化暗号よりも複雑な暗号化暗号を使用することができる。

【0138】

低電力医療デバイスモニタリングシステム１００の通常の動作の間、個々の測定値は、データがセンサ１１０から専用データ受信デバイス１２０へ、ユーザコンピュータデバイス１４０からリモートクラウドサーバ１５０へ送信される際に、複数の暗号化及び復号化のラウンドを受けることができ、それぞれのステップは、異なる鍵を使用し、ますます複雑なレベルの暗号化を使用することが可能である。例えば、センサ１１０から専用データ受信デバイス１２０に測定値を送信するとき、測定値は、センサ固有の鍵に基づく軽量暗号を使用して暗号化することができる。その後、専用データ受信デバイス１２０は、測定値を復号化し、再パッケージ化し、ユーザコンピュータデバイス１４０に送信する前に、読者固有の鍵に基づくより複雑な暗号を使用して再暗号化することができる。同様に、ユーザコンピュータデバイス１４０は、測定値を復号化し、再パッケージ化し、リモートクラウドサーバに送信される前に、デバイス固有の鍵に基づく更に複雑な暗号を使用して再暗号化することができる。各段階で、読書は暗号化及び復号化されるため、デバイスの複雑さ（及び耐久性レベル）間で暗号鍵を共有する必要はない。このように、例えばセンサ固有の鍵が漏洩しても、ユーザコンピュータデバイスの鍵など、他の鍵は影響を受けずに済む。また、それぞれのデバイスがより多くの利用可能なコンピュータリソースとパワーを持つことになるため、より複雑な暗号を使用することができる。本明細書で説明したように、特定の段階において、任意に、データを復号化及び再暗号化せず、別のレベルのデバイスに通過させることができる。

【0139】

ステップ９５０において、ユーザコンピュータデバイス１４０は、ペイロードを複数の送信パケットにセグメント化することができる。ユーザコンピュータデバイス１４０は、オプションとして、デバイス固有の暗号鍵を使用してペイロードを暗号化する前に、ペイロードをセグメント化することができる。従って、ユーザコンピュータデバイス１４０は、デバイス固有の暗号鍵を使用してペイロードセグメントの各々を暗号化することができる。本明細書で具現化されるように、ユーザコンピュータデバイス１４０が、送信前にペイロードをパケットにセグメント化することは有利であり得る。ペイロードをパケット化することは、システムが、ペイロードの残りの全体を送信することなく、送信中に失われたデータをより容易に回復できるため、リモートクラウドサーバ１５０との通信の安定性を向上させることができる。このようなプロトコルは、個々のパケットがリモートクラウドサーバ１５０によって受信されたことを検証するための追加の完全性チェックを含むことができる。更に、図示されていないが、リモートクラウドサーバ１５０は、ユーザコンピュータデバイス１４０が必要に応じて効率的に再送信手順を開始できるように、受信されたパケットの定期的な確認応答を送信することができる。更に、ユーザコンピュータデバイス１４０は、送信しなければならないデータのファイルサイズを最小化するために、ペイロードのデータに任意の適切な圧縮技術を適用することができる。

【0140】

ステップ９５５で、ユーザコンピュータデバイス１４０は、暗号化されたペイロードをリモートコンピュータデバイス１４０に送信する。本明細書で説明したように、ユーザコンピュータデバイス１４０は、送信の開始前にペイロードに適用されるブロック暗号に加えて、ペイロードに個々のパケット保護を提供する任意の適切な通信プロトコル（例えば、ＨＴＴＰＳ、ＳＦＴＰ、ＦＴＰＳ、ＳＳＬなど）の何れかを使用してデータを送信することが可能である。このような保護を提供する通信プロトコルを使用することによって、ユーザコンピュータデバイス１４０は、データの性質がサードパーティーから更に不明瞭になるため、データの保護を更にサポートすることができる。本明細書で具現化するように、ユーザコンピュータデバイス１４０及びリモートクラウドサーバ１５０は、代替的に、デバイス固有の暗号鍵に基づく暗号の使用を見送り、代わりに、個々のパケットレベルの保護を提供する選択されたプロトコルに依存することが可能である。

【0141】

ステップ９６０において、リモートクラウドサーバ１５０は、受信したデータパケットからペイロード９６０を受信し、再構成する。リモートクラウドサーバ１５０は、送信中に失われた任意のパケットを識別し、それらをユーザコンピュータデバイス１４０によって再送信することを要求することができる。ペイロード９６０を再構成することは、パケットの集合体からペイロードを再組み立てすることを含むことができる。ステップ９６５において、リモートクラウドサーバ１５０は、デバイス固有の暗号鍵を使用してペイロードを復号化することができる。リモートクラウドサーバ１５０は、例えば、チェックサム又は他のエラー検出コードの使用を通じて、ペイロードのコンテンツの正常な受信を確認することができる。ステップ９７０で、リモートクラウドサーバ１５０は、ペイロードの確認応答をユーザコンピュータデバイス１４０に送信することができる。確認応答は、機密医療データが受信されたことを示すメッセージを含むことができる。本明細書で具現化するように、確認応答は、パケットレベルの暗号化を提供する通信プロトコルを使用して暗号化され、配信されることも可能である。代替的に、確認応答は、任意選択的に機密データを含まないことができるので、確認応答を暗号化せずに又は平文で送信することができる。

【0142】

本明細書で説明する実施形態は、適切な場合、図９の方法の１又は２以上のステップを繰り返すことができる。本開示は、図９の方法の特定のステップを特定の順序で発生するものとして説明及び図示するが、本開示は、図９の方法の任意の適切なステップが任意の適切な順序で発生することを企図するものである。更に、本開示は、図９の方法の特定のステップを含む機密医療データを暗号化して送信するための例示的な方法を説明及び図示するが、本開示は、適切な場合、図９の方法のステップの全て、幾つか、又はどれも含むことができる任意の適切なステップを含む機密医療データを暗号化して送信する任意の適切な方法を想定している。更に、本開示は、図９の方法の特定のステップを実施する特定の構成要素、デバイス、又はシステムを説明及び図示するが、本開示は、図９の方法の任意の適切なステップを実施する任意の適切な構成要素、デバイス、又はシステムの任意の適切な組み合わせを企図するものである。

【0143】

本明細書で説明するように、低電力医療モニタリングシステム１００における機密医療データの送信及び保存をセキュアにするために、処理能力に関する制限が比較的少ないセンサ１１０から更に下流のデバイスによって、より複雑な暗号化機能を採用することができる。例えば、機密医療データは、センサ１１０と専用データ受信デバイス１２０との間の伝送の前及び伝送中に、第１の暗号関数を用いて、第１の暗号鍵に基づいて、センサ１１０によって暗号化することができる。第１の暗号関数は、本明細書に記載されるような軽量暗号関数（例えば、軽量ブロック暗号又は軽量ストリーム暗号）であることができる。次に、機密医療データがユーザコンピュータデバイス１４０に送信される場合、機密医療データは、第２の暗号関数を使用して、第２の暗号鍵に基づいて、ユーザコンピュータデバイス１４０との送信前及び送信中に暗号化することができる。第２の暗号関数は、第１の暗号関数よりも複雑な暗号関数であることができる。第２の暗号鍵は、第１の暗号鍵とは異なるものとすることができる。

【0144】

別の例として、機密医療データは、センサ１１０と多目的データ受信デバイス１３０との間の送信前及び送信中に、第１の暗号関数を用いて、第１の暗号鍵に基づいて、センサ１１０によって暗号化することができる。第１の暗号関数は、本明細書に記載されるような軽量暗号関数（例えば、軽量ブロック暗号又は軽量ストリーム暗号）であることができる。機密医療データが多目的データ受信デバイス１３０によってユーザコンピュータデバイス１４０又はリモートクラウドサーバ１５０に送信される場合、機密医療データは、第２の暗号関数を使用して、第２の暗号鍵に基づいて、送信前及び送信中に暗号化することができる。第２の暗号関数は、本明細書に記載されるように、第１の暗号関数よりも複雑な暗号関数とすることができる。第２の暗号鍵は、第１の暗号鍵とは異なるものとすることができる。加えて、又は代替的に、機密医療データの伝送は、伝送のために選択された通信媒体及びプロトコルに適切な、パケットレベルの暗号化又は他のアプリケーションレベル、トランスポートレベル、又はネットワークレベルの暗号化で暗号化することができる。

【0145】

加えて又は代替的に、本明細書で具現化されるように、ユーザコンピュータデバイス１４０は、データをリモートクラウドサーバ１４０に伝送する際に、更に複雑な暗号化スキームを使用することができる。一例として、敏感な医療データは、センサ１１０と専用データ受信デバイス１２０又は多目的データ受信デバイス１４０との間の送信前及び送信中に、第１の暗号関数を用いて、第１の暗号鍵に基づいて、センサ１１０によって暗号化することができる。第１の暗号関数は、本明細書で説明するような軽量暗号関数（例えば、軽量ブロック暗号又は軽量ストリーム暗号）であってもよい。次に、専用データ受信デバイス１２０又は多目的データ受信デバイス１３０によって機密医療データがユーザコンピュータデバイス１４０に送信されるとき、機密医療データは、第２の暗号関数を用いて、第２の暗号鍵に基づいて、送信前及び送信中に暗号化することができる。第２の暗号関数は、第１の暗号関数よりも複雑な暗号関数とすることができる。第２の暗号鍵は、第１の暗号鍵とは異なるものとすることができる。機密医療データがユーザコンピュータデバイス１４０からリモートクラウドサーバ１５０に送信される場合、機密医療データは、送信前及び送信中に、第３の暗号関数を使用して、第３の暗号鍵に基づき暗号化することができる。第３の暗号関数は、第１の暗号関数及び第２の暗号関数の両方よりも複雑な暗号関数とすることができる。第３の暗号鍵は、第１の暗号鍵及び第２の暗号鍵の何れとも異なるものとすることができる。加えて、又は代替的に、ユーザコンピュータデバイス１４０からリモートクラウドサーバ１５０への機密医療データの伝送は、伝送のために選択された通信媒体及びプロトコルに適切なパケットレベルの暗号化又は他のアプリケーションレベル、輸送レベル、若しくはネットワークレベルの暗号化で暗号化することができる。

【0146】

以下は、ユーザコンピュータデバイス１４０とリモートクラウドサーバとの間で送信することができる要求及び含まれるデータの例である。本明細書で具現化するように、リクエストの結果及び仕様は、ＪＳＯＮ又はＸＭＬフォーマットでフォーマットされ得るが、しかしながら、任意の適切なデータパッケージング方法が使用され得ることが理解されるべきである。

【0147】

本明細書で説明するように、リモートクラウドサーバ１５０と最初に接続すると、ユーザコンピュータデバイス１４０は、リモートクラウドサーバ１５０のＵｐｄａｔｅＣｈｅｃｋ関数を呼び出すことができる。ＵｐｄａｔｅＣｈｅｃｋ関数は、リモートクラウドサーバ１５０に、使用中の現在のソフトウェア又はファームウェアのバージョンを確認させ、現在のバージョンをユーザコンピュータデバイス（又は低電力医療モニタリングシステム１５０内の他のデバイス）によって使用されるバージョンと比較させることができる。ＵｐｄａｔｅＣｈｅｃｋ関数呼び出しは、収集した値を、リモートクラウドサーバ１５０に関連付けられた適切な更新比較モジュールに渡すことができる。ＵｐｄａｔｅＣｈｅｃｋ機能呼び出しは、限定ではなく例として、アプリケーション識別子及びバージョン番号、オペレーティングシステム識別子及びバージョン番号、専用データ受信デバイス１２０、多目的データ受信デバイス１３０、又はユーザコンピュータデバイス１４０に対応する識別子、専用データ受信デバイス１２０、多目的データ受信デバイス１３０、又はユーザコンピュータデバイス１４０の動作環境に関する記述子、並びにセキュリティトークン又はセキュリティ鍵といった値を含むことができる。

【0148】

本明細書で説明するように、ユーザコンピュータデバイス１４０は、匿名化又は非特定化データをデータマイニングリモートクラウドサーバ１５０に送信するように決定することができる。データマイニングサーバは、低電力モニタリングシステムプロバイダ又は様々な他のソースのための大規模分析の目的のためにデータを収集することができる。データを非特定化した後、ユーザコンピュータデバイス１４０は、リモートクラウドサーバ１５０のＭｉｎｉｎｇＤａｔａＵｐｌｏａｄ関数を呼び出すことができる。ＭｉｎｉｎｇＤａｔａＵｐｌｏａｄ機能は、リモートクラウドサーバ１５０に、データマイニングの目的で使用するために、非特定化データを受信し処理させることができる。ＭｉｎｉｎｇＤａｔａＵｐｌｏａｄ機能呼び出しは、例として、限定するものではないが、リセットからの時間、ファームウェア又はソフトウェアバージョン、センサ１１０の寿命カウント、又はニックネームを含むセンサ１１０に関連付けられたデバイス設定などの値、測定された分析物値を含む測定ログ、食品ログエントリ。初期化、起動、リセット、又は時間変化からの時間、測定識別子、測定タイムスタンプ、分析物の値、分析物に関連付けられた傾向値及び方向、及び測定値が実行可能かどうかの表示などの分析物の測定に関連付けられた予定及び非予定エントリに関連付けられた記録。

【0149】

本明細書で具現化するように、スケジュールされた分析物エントリは、１分、５分、若しくは１５分間隔、又は任意の他の適切な間隔などの所定の間隔で取られた分析物測定に対応するタイムスタンプ値を含むことができる。加えて又は代替的に、予定外の分析物エントリは、ユーザによるセンサの走査、ユーザによる専用データ受信デバイス１２０又は多目的データ受信デバイス１３０の閲覧、又はセンサによって決定される状態などの入力又は条件に応答して取られた分析物測定値に対応するタイムスタンプ値を含むことができる。

【0150】

ユーザコンピュータデバイス１４０は、更に、リモートクラウドサーバ１５０のＵｎｅｎｃｒｙｐｔｅｄＤａｔａＵｐｌｏａｄ関数を呼び出すことができる。ＵｎｅｎｃｒｙｐｔｅｄＤａｔａＵｐｌｏａｄ関数は、非機密データを含むペイロードをリモートクラウドサーバ１５０に配信することができる。ＵｎｅｎｒｙｐｔｅｄＤａｔａＵｐｌｏａｄ関数呼び出しは、例として、限定するものではないが、測定された分析物又は役割に対応するデバイスドメイン、接続ゲートウェイ識別、ユーザトークン、関数全てに含まれるコンテンツの種類の識別、提供されたコンテンツの長さの通知及び／又は予想されるコンテンツなどの値を含むことができる。

【0151】

ＧｅｔＶｅｒｓｉｏｎの呼び出しは、ＵｓｅｒＴｏｋｅｎを含むことができる。ＵｓｅｒＴｏｋｅｎは、任意の適切な符号化技術（例えば、Ｂａｓｅ６４ＵＲＬ）を使用して符号化することができる。ＵｓｅｒＴｏｋｅｎは、ヘッダ部分とペイロード部分とを含むことができる。ヘッダ部は、ペイロードのエンコードに使用されたアルゴリズムを特定するために復号化することができる。受信側（例えば、リモートクラウドサーバ１５０）は、識別されたアルゴリズムを使用してトークンのペイロード部分をデコードして、センサ１１０又はユーザのトークン識別、センサ１１０又はユーザのユーザ識別情報、例えば分析物の名前、場所、及び好ましい単位を含むがこれらに限定されない値を決定することが可能である。

【0152】

ユーザコンピュータデバイス１４０は、更に、リモートクラウドサーバ１５０のＥｎｃｒｙｐｔｅｄＤａｔａＵｐｌｏａｄ関数を呼び出すことができる。ＥｎｃｒｙｐｔｅｄＤａｔａＵｐｌｏａｄ関数は、機密データを含むペイロードをリモートクラウドサーバ１５０に配信することができる。本明細書で具現化するように、ペイロードは、ＭｉｎｉｎｇＤａｔａＵｐｌｏａｄ関数から返されたペイロードデータの何れか又は全てを、ユーザによって使用される特定のセンサを含むがこれに限定されないユーザに関する個人データと共に含むことができる。このように、機密データを含むデバイスデータは、本明細書で説明する手順に従って暗号化することができる。ＥｎｃｒｙｐｔｅｄＤａｔａＵｐｌｏａｄ関数コールは、データ抽出タイムスタンプ、符号化データ、デバイス識別子、アプリケーションバージョン、起動時間、初期化時間、及びオペレーティングシステム識別情報を含む診断情報、ドライブ識別、ドライバ鍵、ゲートウェイ及び／又は接続情報、デバイスグループ識別子、センサ時間、デバイスシリアル番号、及びタイムスタンプ不一致チェックを含むが、それだけに限らない値を含めることができる。

【0153】

ユーザコンピュータデバイス１４０は、更に、リモートクラウドサーバ１５０のＲｅｔｒｉｅｖｅＤａｔａ機能を呼び出すことができる。ＲｅｔｒｉｅｖｅＤａｔａ関数は、デバイス又は患者を識別するための情報を送信することができる。その代わりに、ユーザコンピュータデバイス１４０は、リモートクラウドサーバ１５０によって格納されたデータに関する履歴情報を受信することができる。本明細書で具現化されるように、ＲｅｔｒｉｅｖｅＤａｔａ関数は、第２のユーザコンピュータデバイスで閲覧されるために第１のユーザコンピュータデバイスからアップロードされた情報を取得するために使用することができる。リトリーブデータ機能呼び出し及び戻り情報は、デバイス識別子、デバイスタイプ識別子、デバイスに関連付けられた診断情報、データ抽出時間、デバイス動作環境データ、ユーザのためにデータをアップロードする最近のデバイスの識別、アップロード開始時間、接続及び／又はゲートウェイ識別子、ユーザ識別子、アップロード識別子、及びアップロードデータの各量子のためのアップロード経路を含むが、これだけに限らないデータを含むことができる。

【0154】

ＲｅｔｒｉｅｖｅＤａｔａ関数に応答して、リモートクラウドサーバ１５０は、デバイス使用履歴及び／又はデバイスによって測定された若しくはデバイス上に保存されたデータに関連付けられた追加データと共に、センサと相互作用したデバイスのリストを含むペイロードを配信する可能性がある。デバイス及びデータのリストは、データレコードの作成データ、デバイスに関連付けられた識別、ニックネーム、シリアル番号又はタイプ、デバイスからアップロードされたデータのアップロード日、データに関連付けられたタイムスタンプ、データに関連付けられた分析物測定カウント、食品入力ログ、それぞれのデバイスに関連付けられた予定及び非スケジュールデータ収集イベントに関連付けられたカウント、ユーザ識別子、及びデバイス又はユーザに関連付けられたシリアル番号などの情報を含み得るが、これだけに限定されるものではない。

【0155】

ユーザコンピュータデバイス１４０は、更に、リモートクラウドサーバ１５０のＧｅｔＡｎａｌｙｔｅＨｉｓｔｏｒｙ関数を呼び出すことができる。ＧｅｔＡｎａｌｙｔｅＨｉｓｔｏｒｙ関数は、リモートクラウドサーバ１５０によって格納されたデータを取得することができる。ＧｅｔＡｎａｌｙｔｅＨｉｓｔｏｒｙ関数は、ユーザコンピュータデバイス１４０上で閲覧されるように、格納された情報を提供することができる。リモートクラウドサーバ１５０によって返されるデータは、例示であって限定するものではないが、分析物データを提供したデバイスの識別子、デバイス及び／又はデバイスの種類のうちの１又は２以上による最後のアップロードのデータ、生の分析物測定値、平均分析物測定値、ある期間にわたって記録したテストイベントの数、を含むことができる。分析物の測定値の期間にわたる範囲、分析物の測定値の期間にわたる極値及び他の統計的尺度（四分位値測定を含む）、データ収集開始日、データ収集終了日、データ収集時間範囲、及び分析物が閾値以上又は以下であったイベントのカウントである。

【0156】

以下に記載され特許請求される特定の実施形態に加えて、開示された主題は、以下に特許請求される従属的特徴、及び上記及び添付図に開示されるものの他の何れかの可能な組み合わせを有する他の実施形態にも向けられる。このように、本明細書に開示された特定の特徴は、開示された主題の範囲内で他の様態で互いに組み合わせることが可能であり、開示された主題は、他の何れかの可能な組み合わせを有する他の実施形態にも特に向けられると認識されるようになる。従って、開示された主題の特定の実施形態の上述の説明は、例示及び説明の目的で提示されている。開示された主題の特定の実施形態の上述の説明は、網羅的であることを意図しておらず、又は開示された主題を開示されたこれらの実施形態に限定することを意図していない。

【0157】

開示された主題の技術的思想又は範囲から逸脱することなく、開示された主題の方法及びシステムにおいて様々な修正及び変形形態を実施できることは、当業者であれば理解されるであろう。従って、開示された主題は、添付の特許請求の範囲及びその均等物の範囲内にある変更及び変形を含むことが意図される。

【0158】

本明細書で開示される実施形態は、以下を含む。
Ａ． 医療センサとコンピュータデバイスとの間のセキュアな通信のための方法であって、医療センサによって、コンピュータデバイスから認証要求を受信するステップと、認証要求において提供された値に基づいて、コンピュータデバイスのためのチャレンジレスポンスメッセージを生成するステップと、コンピュータデバイスから、応答したチャレンジレスポンスメッセージを受信するステップと、応答したチャレンジレスポンスメッセージが期待値を含み且つ期待フォーマットに対応することを検証するステップと、応答したチャレンジレスポンスメッセージを検証することに応答して、センサシークレット値をコンピュータデバイスに送信するステップと、を含む方法。

【0159】

Ｂ． 方法であって、第１のコンピュータデバイスによって、医療センサからセンサシークレット値を受信するステップと、第１のコンピュータデバイスによって、医療センサから、センサシークレット値から導出される第１の鍵に基づいて暗号化されていない医療測定値に対する第１の暗号化操作を使用して作成された暗号化された医療測定値のセットを受信するステップであって、暗号化操作は、暗号化されていない医療データに対して加算－回転－ＸＯＲ演算を実施することを含む、ステップと、第１のコンピュータデバイスによって、センサシークレット値に基づいて第１の鍵を導出するステップと、第１のコンピュータデバイスによって、暗号化操作により導出された第１の鍵を用いて医療測定値のセットを復号化するステップと、を含む、方法。

【0160】

Ｃ． 医療センサとコンピュータデバイスとの間のセキュアな通信のための方法であって、医療センサによって、近距離通信プロトコルを介してコンピュータデバイスからアクティベーション信号を受信するステップと、アクティベーション信号に応答して、コンピュータデバイスに関連付けられた１又は２以上の認証値を検証するステップと、コンピュータデバイスに関連付けられた認証値を正常に検証すると、医療センサによって患者からセンサ情報を収集するステップと、を含む、方法。

【0161】

Ｄ． コンピュータデバイスとのセキュアな通信を提供するように配置された医療センサであって、コンピュータデバイスから認証要求を受信する手段と、認証要求において提供された値に基づいて、コンピュータデバイスのためのチャレンジレスポンスメッセージを生成する手段と、コンピュータデバイスから、応答したチャレンジレスポンスメッセージを受け取るための手段と、応答したチャレンジレスポンスメッセージが期待値を含み且つ期待フォーマットに対応することを検証する手段と、応答したチャレンジレスポンスメッセージを検証したことに応答して、センサシークレット値をコンピュータデバイスに送信する手段と、を含む、医療センサ。

【0162】

Ｅ． 第１のコンピュータデバイスであって、医療センサからセンサシークレット値を受信する手段と、医療センサから、センサシークレット値から導出される第１の鍵に基づいて、暗号化されていない医療測定値に対する第１の暗号化操作を使用して作成された暗号化された医療測定値のセットを受信する手段であって、暗号化操作は、暗号化されていない医療データに対して加算－回転－ＸＯＲ演算を実施することを含み手段と、センサシークレット値に基づいて第１の鍵を導出する手段と、暗号化操作により導出された第１の鍵を用いて医療測定値のセットを復号化する手段と、を備える、第１のコンピュータデバイス。

【0163】

Ｆ． コンピュータデバイスとのセキュアな通信を提供するように配置された医療センサであって、近距離通信プロトコルを介してコンピュータデバイスからアクティベーション信号を受信する手段と、アクティベーション信号に応答して、コンピュータデバイスに関連付けられた１又は２以上の認証値を検証する手段と、コンピュータデバイスに関連付けられた認証値を正常に検証すると、患者からセンサ情報を収集する手段と、を備える、医療センサ。

【0164】

Ｇ． コンピュータデバイス又は医療センサによって実行されたとき、コンピュータデバイス又は医療センサに、実施形態Ａ、Ｂ、又はＣの何れかの方法のステップを実行させる命令を含む、コンピュータプログラム、コンピュータプログラム製品、又はコンピュータ可読媒体。

【0165】

実施形態Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、及びＧの各々は、任意の組み合わせで、以下の追加の要素のうちの１又は２以上を有することができる。要素１：センサシークレット値は、医療センサに固有のデータと１又は２以上のランダム値とを含む。要素２：１又は２以上のランダム値は、医療センサに提供された予め定義された値、医療センサの通信モジュールによって生成された値、又はユーザインタラクションに応答して生成された値に基づいている。要素３：医療センサによって、患者からセンサ情報を収集するステップと、センサシークレット値から導出される暗号鍵を使用してセンサ情報を暗号化するステップと、を更に含む。要素４：近距離通信プロトコルを使用して、暗号化されたセンサ情報をコンピュータデバイスに送信するステップを更に含む。要素５：センサ情報は、患者に関する医療データを含む。要素６：医療データは、体温、心拍数、血糖値、又は動作の測定値を含む。要素７：センサ情報を暗号化するステップは、暗号鍵に基づく電力効率の良いストリーム暗号又はブロック暗号でセンサ情報を符号化することを含む。要素８：医療センサによって、近距離通信プロトコルを介してコンピュータデバイスからアクティベーション信号を受信するステップと、アクティベーション信号に応答して、コンピュータデバイスに関連付けられた１又は２以上の認証値を検証するステップと、コンピュータデバイスに関連付けられた認証値を正常に検証すると、医療センサによって患者からセンサ情報を収集するステップと、を更に含む。要素９：アクティベーション信号は更に、医療センサの通信モジュールのうちの１又は２以上に無線電力を供給する。要素１０：医療センサは、近距離通信プロトコルを介して受信した情報を使用して、患者からの追加の検証を必要とせずに、第２の近距離通信プロトコルを介してコンピュータデバイスとの接続を確立する。要素１１：近距離通信プロトコルは近距離通信を含み、第２の近距離通信プロトコルは、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙを含む。

【0166】

要素１２：上記加算－回転－ＸＯＲ演算は、暗号化されていない医療測定値を一連のデータブロックにセグメント化するステップと、各データブロックを２以上のワードにセグメント化するステップと、各データブロックについて、データブロックの２以上のワードのうちの第１のワードのビットを第１の固定量だけ回転させるステップと、ブロックの２以上のワードのうちの第２のワードを追加するステップと、第１のワードへの第１の鍵のビット単位のＸＯＲ演算を実施するステップと、第２のワードのビットを第２の固定量だけ回転させるステップと、第２のワードへの第１のワードのビット単位のＸＯＲ演算を実施するステップと、を含む。要素１３：第２の鍵及び第２の暗号関数を用いて復号された医療測定値を暗号化するステップであって、第２の鍵が、第１のコンピュータデバイスに固有の情報と第１のコンピュータデバイスによって生成されたランダム値とを含む、ステップと、暗号化された医療測定値を第２のコンピュータデバイスに送信するステップと、を更に含む。要素１４：第２の暗号関数は、第１の暗号関数と異なり、第１の暗号関数よりも計算が複雑な暗号関数である。要素１５：第２の暗号関数は、第１の暗号関数と異なり、第１の暗号関数よりも計算が複雑な暗号関数である。要素１５：暗号化された医療測定値は、有線又は無線通信を介して第２のコンピュータデバイスに送信される。要素１６：暗号化された医療測定値は、パケットレベル符号化コンピュータプロトコルを使用して送信される。要素１７：第２のコンピュータデバイスによって、暗号化された医療測定値を復号化するステップと、第３の鍵に基づいて第３の暗号関数で医療測定値を暗号化した後に、復号された医療測定値を第３のコンピュータデバイスに送信するステップを更に含み、第１の鍵、第２の鍵、及び第３の鍵は全て異なり且つ全て異なるルート値から導出され、第１の暗号関数、第２の暗号関数及び第３の暗号関数が全て異なる。要素１８：上記センサシークレット値は、上記医療センサに関連付けられた固有値と、上記医療センサによって生成されたランダム値とを含む。

【0167】

要素１９：アクティベーション信号は更に、医療センサの１又は２以上の通信モジュールに無線電力を供給する。要素２０：医療センサは、近距離通信プロトコルを介して受信した情報を使用して、患者からの追加の検証を必要とせずに、第２の近距離通信プロトコルを介してコンピュータデバイスとの接続を確立する。要素２１：近距離通信プロトコルが近距離通信を含み、第２の近距離通信プロトコルがＢｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙを含む。

【0168】

要素２２：要素１～１１の何れかに記載の方法を実施する手段を更に備える。

【0169】

要素２３：要素１２～１８の何れかに記載の方法を実施する手段を更に備える。

【0170】

要素２４：要素１９～２１の何れかに記載の方法を実施する手段を更に備える。

【0171】

非限定的な例として、実施形態Ａに適用可能な例示的な追加又は組み合わせは、要素１と要素２～１１の何れか；要素２と要素１及び３～１１の何れか；要素３と要素１～２及び４～１１の何れか；要素４と要素１～３及び５～１１の何れか；要素５と要素１～４及び６～１１の何れか；要素６と要素１～５及び７～１１の何れか；要素７と要素１～６及び８～１１の何れか；要素８と要素１～７及び９～１１の何れか；要素９と要素１～８及び１０～１１の何れか；要素１０と要素１～９及び１１の何れか；要素１１と要素１～１０の何れかを含む。

【0172】

非限定的な例として、実施形態Ｂに適用可能な例示的な追加又は組み合わせは、要素１２と要素１３～１８の何れか；要素１３と要素１２及び１４～１８の何れか；要素１４と要素１２～１３及び１５～１８の何れか；要素１５と要素１２～１４及び１６～１８の何れか；要素１６と要素１２～１５及び１７～１８の何れか；要素１７と要素１２～１６及び１８の何れか；要素１８と要素１２～１７の何れかを含む。

【0173】

非限定的な例として、実施形態Ｃに適用可能な例示的な追加又は組み合わせは、要素１９と要素２０～２１の何れか；要素２０と要素１９及び２１の何れか；要素２１と要素１９～２０の何れかを含む。

【0174】

非限定的な例として、実施形態Ｄに適用可能な例示的な追加又は組み合わせは、要素２２を含む。

【0175】

非限定的な例として、実施形態Ｅに適用可能な例示的な追加又は組み合わせは、要素２３を含む。

【0176】

非限定的な例として、実施形態Ｆに適用可能な例示的な追加又は組み合わせは、要素２４を含む。

【0177】

追加的又は代替的に、実施形態Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、及びＧに適用可能な要素及び組み合わせの何れかは、実施形態Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、及びＧに適用可能な他の要素及び組み合わせの何れかに適用可能である。

【符号の説明】

【0178】

１１０ センサ
１２０ 専用のデータ受信デバイス
１３０ 多目的データ受信デバイス／アプリケーション
１４０ ユーザデバイス
１５０ リモートクラウドサーバ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7A】

【図7B】

【図7C】

【図7D】

【図8】

【図9】

【国際調査報告】