特表 2024-527058 デバイスのウェイクアップ

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

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

(11)【公表番号】

(43)【公表日】2024-07-19

(54)【発明の名称】デバイスのウェイクアップ

(51)【国際特許分類】

   H04W 12/04 20210101AFI20240711BHJP

   H04W 12/06 20210101ALI20240711BHJP

   H04W 4/20 20180101ALI20240711BHJP

   H04W 4/14 20090101ALI20240711BHJP

   H04W 52/02 20090101ALI20240711BHJP

【ＦＩ】

H04W12/04

H04W12/06

H04W4/20

H04W4/14

H04W52/02

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2024505013

(86)(22)【出願日】2022-07-25

(85)【翻訳文提出日】2024-03-07

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

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

(87)【国際公開日】2023-02-02

(31)【優先権主張番号】2110715.6

(32)【優先日】2021-07-26

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】524034202

【氏名又は名称】ボーダフォン・グローバル・エンタープライズ・リミテッド

【氏名又は名称原語表記】ＶＯＤＡＦＯＮＥ ＧＬＯＢＡＬ ＥＮＴＥＲＰＲＩＳＥ ＬＩＭＩＴＥＤ

(71)【出願人】

【識別番号】523382100

【氏名又は名称】ダブコ・リミテッド

【氏名又は名称原語表記】ＤＡＢＣＯ ＬＩＭＩＴＥＤ

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】ボーン，ソフィー・ニコール

(72)【発明者】

【氏名】スネイプ，ティモシー

(72)【発明者】

【氏名】トリッキー，ダニエル・ジョージ

【テーマコード（参考）】

5K067

【Ｆターム（参考）】

5K067AA30

5K067AA43

5K067DD11

5K067EE02

5K067EE16

5K067HH36

(57)【要約】

デバイスとサーバとの間で通信するための方法のための方法およびシステムであり、方法は、前記サーバがデバイスウェイクアップを開始するステップを含む。セキュリティクレデンシャル、またはセキュリティクレデンシャルを導出するために使用される情報を含む、汎用ブートストラップアーキテクチャ(GBA：generic bootstrapping architecture)プッシュ情報(GPI：GBA push information)を取得する。デバイスにデバイスウェイクアップメッセージを送信し、デバイスウェイクアップメッセージはGPIを含む。鍵を取得するためにGPI内でセキュリティクレデンシャルを認証する。取得された鍵を使用してデバイスとサーバとの間のセキュアな通信チャネルを確立し、セキュアな通信チャネルが証明書ベースのプロトコルを使用し、かつ取得された鍵が証明書認証の代わりに使用される。

【特許請求の範囲】

【請求項1】

デバイスとサーバとの間で通信するための方法であって、
前記サーバがデバイスウェイクアップを開始するステップと、
セキュリティクレデンシャル、または前記セキュリティクレデンシャルを導出するのに使用される情報を含む汎用ブートストラップアーキテクチャ(GBA：generic bootstrapping architecture)プッシュ情報(GPI：GBA push information)を取得するステップと、
前記デバイスにデバイスウェイクアップメッセージを送信するステップであって、前記デバイスウェイクアップメッセージが前記GPIを含む、ステップと、
鍵を取得するために前記GPI内で前記セキュリティクレデンシャルを認証するステップと、
前記取得された鍵を使用して前記デバイスと前記サーバとの間のセキュアな通信チャネルを確立するステップであって、前記セキュアな通信チャネルが証明書ベースのプロトコルを使用し、かつ前記取得された鍵が証明書認証の代わりに使用される、ステップと
を含む、方法。

【請求項2】

前記GPIが、ネットワークアプリケーション機能(NAF：network application function)から取得される、請求項１に記載の方法。

【請求項3】

前記サーバが、アプリケーションプログラミングインターフェース(API：application programming interface)命令を別個のデバイスに発行することによって、前記デバイスウェイクアップメッセージを開始する、請求項１または２に記載の方法。

【請求項4】

前記GPIが、前記サーバからの前記API命令の受信に応答して、前記別個のデバイスによって取得される、請求項３に記載の方法。

【請求項5】

前記ウェイクアップメッセージがSMSメッセージである、先行する請求項のいずれかに記載の方法。

【請求項6】

前記ウェイクアップメッセージの受信に応答して、前記デバイスが、前記セキュアな通信チャネルを確立する前に状態を変更するステップ
をさらに含む、先行する請求項のいずれかに記載の方法。

【請求項7】

前記デバイスが、第１の電力状態から第２の電力状態に状態を変更し、前記第１の電力状態の前記デバイスによって使用される電力が、前記第２の電力状態の前記デバイスによって使用される電力よりも小さい、請求項６に記載の方法。

【請求項8】

前記デバイスが、マシンツーマシン(M2M：machine to machine)デバイスである、先行する請求項のいずれかに記載の方法。

【請求項9】

前記確立されたセキュアな通信チャネルが、TLS、SSL、DTLS、QUIC、QUIC PSK、またはQUIC 0-RTTである、先行する請求項のいずれかに記載の方法。

【請求項10】

前記鍵を取得するために前記GPI内の前記セキュリティクレデンシャルを認証する前記ステップが、前記デバイスがブートストラップサーバ機能(BSF：bootstrapping server function)を用いて前記GPIを認証するステップと、認証成功時に前記BSFから前記鍵を受信するステップとをさらに含む、先行する請求項のいずれかに記載の方法。

【請求項11】

前記サーバが、デバイスマネージャ(DM：device manager)サーバである、先行する請求項のいずれかに記載の方法。

【請求項12】

前記ウェイクアップメッセージが、所定の間隔で、および／または以前に取得された鍵の有効期限が切れたときに開始される、先行する請求項のいずれかに記載の方法。

【請求項13】

前記サーバが、前記デバイスで生じた要求に応答して前記デバイスウェイクアップメッセージを開始する、先行する請求項のいずれかに記載の方法。

【請求項14】

前記デバイスが低電力状態にある場合に、前記サーバにウェイクミーアップメッセージを送信するステップであって、前記低電力状態が動作電力よりも低い電力にあることである、ステップをさらに含む、請求項１３に記載の方法。

【請求項15】

前記ウェイクアップメッセージが、ウェイクアップ遅延を示すデータを含む、先行する請求項のいずれかに記載の方法。

【請求項16】

前記デバイスが、前記ウェイクアップ遅延を示す前記データに基づく期間、前記サーバとの前記セキュアな通信チャネルの確立を遅延させるステップをさらに含む、請求項１５に記載の方法。

【請求項17】

前記ウェイクアップメッセージが、複数のウェイクアップタイプのうちのウェイクアップタイプを示すデータを含む、先行する請求項のいずれかに記載の方法。

【請求項18】

前記ウェイクアップメッセージ内の前記ウェイクアップタイプによって決定された手順に従って、前記デバイスと前記サーバとの間に前記セキュアな通信チャネルを確立するステップをさらに含む、請求項１７に記載の方法。

【請求項19】

前記デバイスと前記サーバとの間に前記セキュアな通信チャネルを確立する前記ステップが、前記デバイスの識別子を前記サーバに提供することをさらに含む、先行する請求項のいずれかに記載の方法。

【請求項20】

前記デバイスが所定の時間内に応答しない場合に、前記ウェイクアップメッセージが前記デバイスに再送信されるか、または新しいウェイクアップメッセージが前記デバイスに送信される、先行する請求項のいずれかに記載の方法。

【請求項21】

前記メッセージがタイムスタンプに関連付けられ、前記方法が、前記タイムスタンプから前記所定の時間内における前記セキュアな通信の前記確立の記録を前記サーバが有しない場合、前記ウェイクアップメッセージを再送信する、または新しいウェイクアップメッセージを前記デバイスに送信するようにトリガするステップをさらに含む、請求項２０に記載の方法。

【請求項22】

先行する請求項のいずれかに記載の方法のステップを実施するための手段を備えるシステム。

【請求項23】

サーバと、
１つ以上のデバイスと
を備える、請求項２２に記載のシステム。

【請求項24】

前記サーバから、前記デバイスウェイクアップメッセージを開始するためのコマンドを受信し、応答して前記デバイスに前記デバイスウェイクアップメッセージを送信するように構成されたアプリケーションプログラミングインターフェース(API：application programming interface)ハブ
をさらに備える、請求項２２または２３に記載のシステム。

【請求項25】

前記GPIを提供するように構成されたネットワークアプリケーション機能(NAF：network application function)
をさらに備える、請求項２２～２４のいずれかに記載のシステム。

【請求項26】

コンピュータによって実行されると、請求項１～２１のいずれに記載の方法のステップを前記コンピュータに実施させる命令を含むコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の分野
本発明は、サーバと通信するためにデバイスをウェイクアップさせるための方法およびシステムに関する。

【背景技術】

【0002】

本発明の背景
デバイス、特にマシンツーマシン(M2M：machine to machine)デバイスは、多くの異なる状況で使用され、様々な異なるアイテムおよびハードウェアに組み込まれ得る。通常、これらの管理対象デバイスは、コンピューティングリソースが低く、電力が制限され、機能が制限される。それにもかかわらず、デバイスマネージャまたは他のサーバとの通信を必要とする保守、制御、および他の対話を必要とする、そのようなデバイスの大規模なネットワークが開発され得る。

【0003】

デバイスの性質、ならびに電力およびコンピューティングの潜在能力の両方における限られたリソースのために、デバイスが必要とされるまで（例えば、読み取り値を提供するために、またはコマンドを受け入れるために必要とされるまで）、デバイスの電源をオフにし、電力を低減した状態または休止状態に保つことがしばしば必要である。デバイスは、特定の時間または断続的に電源をオンにするようにスケジュールされてもよい。しかしながら、そのようなデバイスから情報が必要とされる場合、または制御情報もしくは他の管理情報がそのようなスケジュールされた動作時間外に送信される必要がある場合、この手法には欠点がある。代替的に、管理対象デバイスとそれらのデバイスマネージャとの間の何らかの形態の通信を維持してもよいが、これには、特に管理対象デバイスの大規模ネットワークのために追加の電力および帯域幅が必要である。さらに、システムリソースおよび電力消費を制限しながら、デバイスとのセキュアな通信が必要とされる。

【0004】

したがって、これらの問題を克服する、デバイスと通信するための方法およびシステムが必要とされている。

【発明の概要】

【課題を解決するための手段】

【0005】

本発明の概要
マシンツーマシン(M2M)またはモノのインターネット(IoT：internet of things)デバイスなどのデバイスは、バッテリまたは他の長期電源を使用して電力が供給され得る。場合によっては、この電源は容易に交換または補充することができない場合がある。したがって、電力管理は、特に数年間にわたって設置されることが意図されたデバイスにとって重要である。これを達成するための１つの技術は、デバイスの電源をオフにするか、またはデバイスをある期間スリープさせ（例えば、低電力モードまたは１つ以上の通信インターフェースに電力を供給することを含まないモードにする）、デバイスを短いまたは断続的な期間だけ動作させる（または低電力モードよりも高い高電力モードにする）ことである。デバイスは、これを達成するためのタイマまたはスケジュールを含んでもよい。しかしながら、デバイスとの通信は、スリープするようにスケジュールされた時間中または低電力モードにあるときに必要とされる場合がある。さらに、デバイスがアウェイクまたは高電力モードにあるようにスケジュールされている場合、デバイスとの通信は必要とされない場合がある。この場合、デバイスをウェイクアップさせることは、単に電力および他のシステムリソースを浪費する場合がある。

【0006】

したがって、通信が必要なときにデバイスをウェイクアップする必要があり、電力要件を低く保ちながら、そのような通信を保護する必要がある。例えば、これらの通信は、センサデータなどのデータをデバイスからサーバに提供することであってもよい。そのような場合、ウェイクアップ条件またはメッセージが開始され得る。デバイスとの通信を保護する必要があるため、デバイスにセキュリティクレデンシャルを提供する必要もある。しかしながら、TLS、DTLS、SSLなどの好ましいセキュリティプロトコルは、通常、認証局(CA：certificated authority)を必要とし、CAとの通信は、独自の電力および帯域幅要件を有するさらなるメッセージングおよび通信（例えば、証明書を交換する）を必要とする。

【0007】

セキュリティクレデンシャルを別々に送信するのではなく、ウェイクアップメッセージは二重の目的を有することができ、すなわち、デバイスをウェイクアップさせることもでき、汎用ブートストラップアーキテクチャ(GBA：generic bootstrapping architecture)プッシュ情報(GPI：GBA push information)の形態でセキュリティクレデンシャルを含むこともできる。ウェイクアップメッセージ自体が保護されている必要はない（ただし、場合によっては独自のセキュリティを有してもよい）。ウェイクアップメッセージは、通常はCAを伴うセキュリティプロトコルを使用してデバイスとサーバとの間の通信チャネルを保護することができるようにGPIを含むが、セキュリティクレデンシャルはウェイクアップメッセージ内のGPIの一部として送信されるので、認証にはCAまたは証明書交換は必要ない。また、デバイスを用いるよりも、（例えば、鍵を提供するために）サーバに鍵資料を伝送する方が簡単である。さらに、デバイスは、低電力およびリソースのデバイスに最適化することができるGBAを処理できるだけでよく、セキュリティ証明書を処理または記憶することができる必要はない。

【0008】

GPI内のセキュリティクレデンシャルが認証または検証され、これにより鍵（例えばKs_NAF）がもたらされる。次いで、鍵は、デバイスとサーバとの間の通信を保護するために使用される。好ましくは、デバイスは、SIM、USIMまたはUICCを含む。このようにGBAを使用すると、証明書（またはそれらの認証）が不要であり、鍵をSIMまたはUICC上のデータから導出できるという利点がある。好ましくは、SIMまたはUICCは、クレデンシャルおよび／またはクレデンシャルの導出を管理するためのデバイス上のハードウェアトークンとして使用される。いくつかの例示的な実装形態では、セキュアな通信チャネルは、TLSまたは他の証明書ベースのプロトコルを使用して保護されてもよい。したがって、そのようなプロトコルは、認証なしでセットアップすることができる。

【0009】

ウェイクアップメッセージは、好ましくはSMSの形態であるが、GPIは他の方法で配布され得るため、他の形態を取ってもよい。SMS自体は、保護されていなくても、保護されていてもよい。保護されていないSMSを使用すると、処理のオーバーヘッドが減少するが、セキュアな通信チャネルはGBAによって既に保護されており、保護されていないSMSはGPI（およびセキュリティクレデンシャル）を転送するためにのみ使用されるので、セキュアな通信チャネルのセキュリティは低下しない。

【0010】

第１の態様によれば、デバイスとサーバとの間で通信するための方法であって、
サーバがデバイスウェイクアップを開始するステップと、
セキュリティクレデンシャル、またはセキュリティクレデンシャルを導出するのに使用される情報を含む汎用ブートストラップアーキテクチャ(GBA：generic bootstrapping architecture)プッシュ情報(GPI：GBA push information)を取得するステップと、
デバイスにデバイスウェイクアップメッセージを送信するステップであって、デバイスウェイクアップメッセージがGPIを含む、ステップと、
鍵を取得するためにGPI内でセキュリティクレデンシャルを認証するステップと、
取得された鍵を使用してデバイスとサーバとの間のセキュアな通信チャネルを確立するステップであって、セキュアな通信チャネルが証明書ベースのプロトコルを使用し、かつ取得された鍵が証明書認証の代わりに使用される、ステップと
を含む、方法が提供される。したがって、証明書メッセージングおよび関連するオーバーヘッドを必要とせずに、良好なセキュリティを維持することができる。

【0011】

好ましくは、GPIは、ネットワークアプリケーション機能(NAF：network application function)から取得してもよい。したがって、この方法は、既存のGBAインフラストラクチャで使用することができるが、他のメカニズムを使用することもできる。

【0012】

任意選択的に、サーバは、アプリケーションプログラミングインターフェース(API：application programming interface)命令、または呼び出しを別個のデバイスに発行することによって、デバイスウェイクアップメッセージを開始してもよい。この別個のデバイスは、例えば、APIハブであってもよい。次いで、APIハブは、他の電気通信インフラストラクチャとの対話を管理することができる。

【0013】

有利には、GPIは、サーバからのAPI命令の受信に応答して、別個のデバイスによって取得されてもよい。例えば、別個のデバイスがAPI命令を受信すると、それはネットワークアプリケーション機能(NAF)と対話してGPIデータを取得してもよく、またはそれ自体でNAFステップを行ってもよい。

【0014】

GPIデータを作成するために使用されるどのようなプロセスであっても、デバイスへの伝送のためにウェイクアップメッセージに組み込まれてもよい。

【0015】

好ましくは、ウェイクアップメッセージはSMSメッセージであってもよい。しかしながら、ウェイクアップメッセージは、異なるフォーマット（例えば、固定回線、通話など）で（例えば、異なる通信チャネルタイプを介して）送信および受信することができる。

【0016】

任意選択的に、方法は、
ウェイクアップメッセージの受信に応答して、デバイスが、セキュアな通信チャネルを確立する前に状態を変更するステップ
をさらに含んでもよい。

【0017】

好ましくは、デバイスは、第１の電力状態から第２の電力状態に状態を変更してもよく、第１の電力状態のデバイスによって使用される電力は、第２の電力状態のデバイスによって使用される電力よりも小さい。したがって、これにより、バッテリ電力を維持し、デバイスの寿命を延ばすことができる。

【0018】

任意選択的に、デバイスは、マシンツーマシン(M2M)デバイスであってもよい。デバイスは、モノのインターネット(IoT)デバイスであってもよい。

【0019】

データのGPIブロックを含むウェイクアップメッセージを受信すると、デバイスは、受信したGPIデータブロックを使用してGAAサーバ機能認証を行い、認証結果としてKs_NAF鍵（または他の鍵）を導出してもよい。

【0020】

次いで、デバイスは、導出されたKs_NAF鍵をTLS機能への入力として使用してもよく、これを使用して、サーバ（例えば、アプリケーションサーバ）とのセキュアなクライアント接続を開始してもよい。

【0021】

任意選択的に、確立されたセキュアな通信チャネルは、TLS、SSL、DTLS、QUIC、QUIC PSK、またはQUIC 0－RTTであってもよい。認証局を必要とせずに、他の証明書ベースのプロトコルを使用してもよい。

【0022】

好ましくは、鍵を取得するためにGPI内のセキュリティクレデンシャルを認証するステップは、デバイスがブートストラップサーバ機能(BSF：bootstrapping server function)を用いてGPIを認証するステップと、認証成功時にBSFから鍵を受信するステップとをさらに含んでもよい。したがって、既存のGBAインフラストラクチャを利用することができる。

【0023】

任意選択的に、サーバは、デバイスマネージャ(DM：device manager)サーバであってもよい。しかしながら、サーバは、他の形態を取り、他の機能を行うことができる。

【0024】

任意選択的に、ウェイクアップメッセージは、所定の間隔で、および／または以前に取得された鍵の有効期限が切れたときに開始されてもよい。ウェイクアップメッセージを開始するために異なるメカニズムを使用することができる。これらは、スケジュールして、またはアドホックで行うことができる。

【0025】

任意選択的に、サーバは、デバイスで生じた要求に応答してデバイスウェイクアップメッセージを開始する。したがって、デバイスのいくつかの構成要素または態様は、残りの構成要素（例えば、通信インターフェース）がいつどのように電力が供給されて起動されるかを制御することができる。

【0026】

任意選択的に、方法は、デバイスが低電力状態にある場合に、サーバにウェイクミーアップメッセージを送信するステップであって、低電力状態が動作電力よりも低い電力にあることである、ステップをさらに含んでもよい。このさらなるメッセージまたは信号は、例えば、ウェイクアップメッセージ（例えば、SMS）と同じ通信タイプおよびチャネルを介して、または異なるメッセージタイプとして送信されてもよい。

【0027】

任意選択的に、デバイスがそれ自体のウェイクアップを開始する例示的な実装形態では、ウェイクミーアップメッセージ（または別の形態の要求）を送信することによって、ウェイクミーアップメッセージは、データなし（または非常に少ないデータ）の伝送でアプリケーションサーバに通信されてもよい。この場合、関連するプロトコルは、開始デバイスとアプリケーションサーバとの間に確立されるデータ接続を要求してもよく、接続が確立されると、（例えば、直ちに、または短時間の後に）デバイスによって閉じられ、すべてのリソースが解放されてもよい。この動作モードでは、通信構成要素は、呼び出し側デバイスのアイデンティティをサーバ、アプリケーションサーバ（またはAPIサーバ）に通信してもよく、次いで、この識別情報を使用して、NAFサーバなどを介してGPIデータを取得してもよい。

【0028】

任意選択的に、デバイスへのウェイクアップメッセージおよび／またはデバイスからのウェイクアップメッセージは、ウェイクアップ遅延を示すデータを含んでもよい。したがって、これは、デバイスがいつどのようにしてウェイクアップするか、および／またはサーバとの通信を再開するかに対するさらなる制御を提供する。

【0029】

有利には、方法は、デバイスが、ウェイクアップ遅延を示すデータに基づく期間、サーバとのセキュアな通信チャネルの確立を遅延させるステップをさらに含んでもよい。遅延は、他のメカニズムを使用して達成されてもよい。

【0030】

任意選択的に、ウェイクアップメッセージは、複数のウェイクアップタイプのうちのウェイクアップタイプを示すデータを含んでもよい。

【0031】

任意選択的に、方法は、ウェイクアップメッセージ内のウェイクアップタイプによって決定された手順に従って、デバイスとサーバとの間にセキュアな通信チャネルを確立するステップをさらに含んでもよい。様々なタイプは、例えば、直ちにウェイクアップすること、遅延後にウェイクアップすること、および指定された時間にウェイクアップすることを含んでもよい。

【0032】

任意選択的に、デバイスとサーバとの間にセキュアな通信チャネルを確立するステップは、デバイスの識別子をサーバに提供することをさらに含んでもよい。例えば、これは、IMSI、IMEI、または他の識別子であってもよい。

【0033】

任意選択的に、デバイスが所定の時間内に応答しない場合に、ウェイクアップメッセージはデバイスに再送信されてもよく、または新しいウェイクアップメッセージがデバイスに送信される。これにより、信頼性が向上する場合がある。

【0034】

任意選択的に、メッセージはタイムスタンプに関連付けられてもよく、方法は、タイムスタンプから所定の時間内におけるセキュアな通信の確立の記録をサーバが有しない場合、ウェイクアップメッセージを再送信する、または新しいウェイクアップメッセージをデバイスに送信するようにトリガするステップをさらに含んでもよい。そのようなタイムスタンプは、メッセージ自体のタイムスタンプ（例えば、SMS）またはメッセージ内のタイムスタンプデータであってもよい。

【0035】

第２の態様によれば、上述の方法のステップを実施するための手段を備えるシステムが提供される。

【0036】

好ましくは、システムは、サーバと、
１つ以上のデバイスと
を備える。例えば、デバイスのグループに関連付けられた、または負荷分散および冗長性を提供するための複数のサーバも存在してもよい。

【0037】

好ましくは、システムは、
サーバから、デバイスウェイクアップメッセージを開始するためのコマンドを受信し、応答してデバイスにデバイスウェイクアップメッセージを送信するように構成されたアプリケーションプログラミングインターフェース(API：application programming interface)ハブ
をさらに備えてもよい。

【0038】

有利には、システムは、
GPIを提供するように構成されたネットワークアプリケーション機能(NAF：network application function)
をさらに備えてもよい。GPIは、例えば、NAFから直接、またはサーバもしくはAPIハブなどの中間ソースもしくはプロバイダを介して提供されてもよい。

【0039】

第３の態様によれば、プログラムがコンピュータによって実行されると、上述の方法のステップをコンピュータに実施させる命令を含むコンピュータプログラムが提供される。

【0040】

上述の方法は、コンピュータを動作させるためのプログラム命令を含むコンピュータプログラムとして実装されてもよい。コンピュータプログラムは、コンピュータ可読媒体に記憶されてもよい。

【0041】

コンピュータシステムは、中央処理装置(CPU：central processing unit)などのプロセッサを含んでもよい。プロセッサは、ソフトウェアプログラムの形態のロジックを実行してもよい。コンピュータシステムは、揮発性および不揮発性記憶媒体を含むメモリを含んでもよい。ロジックまたはプログラム命令を記憶するためにコンピュータ可読媒体が含まれてもよい。システムの異なる部分は、ネットワーク（例えば、無線ネットワークおよび有線ネットワーク）を使用して接続されてもよい。コンピュータシステムは、１つ以上のインターフェースを含んでもよい。コンピュータシステムは、例えば、UNIX（登録商標）、Windows(登録商標)(RTM)またはLinux（登録商標）などの適切なオペレーティングシステムを含んでもよい。

【0042】

上記の任意の特徴は、本発明の任意の特定の態様または実施形態で使用され得ることに留意されたい。

【0043】

図面の簡単な説明
本発明は、いくつかの方法で実施されてもよく、ここで、添付の図面を参照して、単なる例として実施形態を説明する。

【図面の簡単な説明】

【0044】

【図1】サーバからデバイスにウェイクアップメッセージを送信するためのプロセスの高レベルシーケンス図である。

【図2】例示的なデバイス管理システムの概略図である。

【図3】デバイスとサーバとの間で通信するための例示的な方法のフローチャートである。

【図4】デバイスにウェイクアップメッセージを送信するための方法の例示的な実装形態のシーケンス図である。

【図5】デバイスにウェイクアップメッセージを送信するための代替の例示的な方法のシーケンス図である。

【図6】デバイスにウェイクアップメッセージを送信するための代替の例示的な方法のシーケンス図である。

【図7】デバイスにウェイクアップメッセージを送信するための代替の例示的な方法のシーケンス図である。

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

【0045】

図面は簡略化のために示されており、必ずしも縮尺通りに描かれていないことに留意されたい。同様の特徴には同じ参照番号が付されている。

【0046】

好ましい実施形態の詳細な説明
汎用ブートストラップアーキテクチャ(GBA)プッシュ情報(GPI)は、任意の適切な手段を使用して配布することができる。GPIは、鍵を導出するために使用され得るセキュリティクレデンシャルを含むことができる。ネットワークアプリケーション機能(NAF)は、そのようなGPIをデバイスに提供することができる。汎用認証アーキテクチャ(GAA：Generic authentication architecture)は、認証結果（例えば、鍵または他の暗号資料）をもたらすGPIの認証を可能にする。以下の例示的な実装形態では、SMSを使用してGPIをデバイスに配布するが、他の技術（例えば、WiFi、固定電話回線など）を使用することができることに留意されたい。

【0047】

さらに、これらの例示的な実装形態に記載されたデバイスは、マシンツーマシン(M2M)デバイスまたはモノのインターネット(IoT)デバイスであるが、他のデバイスタイプが記載された技術およびシステムと共に使用されてもよい。これらのデバイスは、通常、低いコンピューティングリソースおよび電力リソースを有するが、収集して伝送するデータを保護する必要がある。例えば、これらのデータは、ユーティリティデータ使用データまたはインフラストラクチャセンサデータを含む場合がある。したがって、デバイスからこれらのデータを伝送するためにセキュアな通信プロトコルが必要である。さらに、電力要件および帯域幅使用量を低レベルに保つために、そのようなデバイス（典型的にはバッテリ式であり、交換可能または再充電可能であってもなくてもよい）を低電力モードまたはスリープモードにすることができる。低電力モードは、さらなる通信インターフェースに電力が供給されて使用されているときに、高電力モードよりも少ない電力を使用する。しかしながら、低電力モードおよび高電力モードは、他の構成要素ならびに通信インターフェースに影響を及ぼす場合がある。タイマおよびスケジュールは、デバイスが定期的にウェイクアップするようにデバイスに組み込まれてもよい。しかしながら、これらのスケジュール外で、そのようなデバイスと通信する（または、他の理由でそれらをより高い電力モードにする）必要があることができる。例えば、ファームウェア更新が必要とされ得るか、またはデバイスとの通信の即時もしくは少なくともより迅速な再開を必要とする瞬間的なデータが収集される必要があり得る。したがって、ウェイクアップスケジュールに加えて、またはその代わりに、デバイスは、デバイスを低電力モードから高電力モードおよび／またはサーバもしくは他のエンティティとの通信が行われることを可能にするモードに切り替えるウェイクアップメッセージを受信することができる。

【0048】

図１は、デバイス２０をウェイクアップさせるための高レベルの方法のシーケンス図を示す。この図はアプリケーションサーバ４０を示しているが、任意のサーバタイプを使用または組み込んでもよい。アプリケーションサーバ４０は、APIハブ６０へのアプリケーションプログラミングインターフェース(API)呼び出しを呼び出すことによってデバイスウェイクアップメッセージを開始する。ここでも、サーバ内またはそれの外部のいずれかで、他のメカニズムを使用してウェイクアップメッセージを開始してもよい。APIハブ６０は、電気通信インフラストラクチャ（この図には示されていない）を使用してSMSを生成することによってAPI呼び出しに応答する。デバイス２０は、低電力状態であってもSMSを受信することを可能にするUICCまたはSIMおよび電気通信構成要素を含む。SMSは、単一のデバイス（すなわち、その携帯電話番号に基づく）に向けられてもよいし、複数のSMSが、デバイスのウェイクアップグループに同時に、またはデバイスの特定のネットワーク内のすべてのデバイスに送信されてもよい。

【0049】

SMSの受信に応答して、デバイス２０は、アプリケーションサーバ４０とのクライアント接続を開始する。これは、アクセスポイント名(APN：access point name)または他の電気通信インフラストラクチャによるものであってもよい。したがって、デバイス２０とアプリケーションサーバ４０との間のデータ通信が開始されてもよい。したがって、ウェイクアップメッセージは、デバイス２０に状態を変更させ、ウェイクアップさせることは、低電力、スリープ、または休止状態（ウェイクアップメッセージを監視すること、またはウェイクアップメッセージを受信する能力を含む、最小限の、またはより少ないプロセスが実施される状態）よりも多くのオンボードプロセスを実施することを伴うことができる。ウェイクアップメッセージを搬送する通信チャネルは、特定の用途に応じて保護されていても、保護されていなくてもよい。

【0050】

図２は、例示的なウェイクアップ手順を実装するためのシステム１０の概略図を示す。デバイス２０はUICCまたはSIM３０を含み、サーバ４０は通信インターフェース５０を含む。この図では、サーバ４０からAPI呼び出しを受信し、デバイス２０に送信されるSMSを開始するAPIハブ６０が示されている。しかしながら、この例示的な実装形態では、APIハブ６０は、例えば、GBA NAFサーバまたはNAFプッシュサーバ７０からGPI（セキュリティクレデンシャルまたはそのようなセキュリティクレデンシャルを導出するための情報を含む）を取得する。したがって、APIハブ６０は、その後デバイス２０に送信されるSMSにGPIを組み込むことができる。GPIは、デバイス２０とアプリケーションサーバ４０との間の通信を保護するために直接的または間接的に使用されるセキュリティクレデンシャルを含む。これは、デバイス２０が汎用認証アーキテクチャ(GAA)サーバ８０を用いてGPIを認証することによって達成される。この認証は、デバイス２０とサーバ４０との間の通信を保護するために使用される鍵９０がもたらされる。

【0051】

デバイス２０とサーバ４０との間の通信を保護するために使用される特定のセキュリティプロトコルは、デバイス２０とサーバ４０とが互いに認証して共有鍵９０を取得するために、そうでなければ証明書のセキュリティシステムおよび認証局(CA)を使用するセキュリティプロトコルである。しかしながら、セキュリティクレデンシャルは既にGPI内に含まれており、NAF７０（またはその他）を使用してデバイス２０およびサーバ４０の両方に利用可能であるので、CAまたは証明書処理は必要とされない。

【0052】

この図から分かるように、NAF７０はまた、サーバ４０とセキュリティクレデンシャルを共有する。代替的に、鍵９０は、APIハブ６０または他の場所のいずれかからサーバ４０と直接共有されてもよい。したがって、サーバ４０は、GPIまたはセキュリティクレデンシャルを処理する（または受信する）必要がない。いずれの場合も、CAまたは証明書プロセスは必要ない。

【0053】

図３は、デバイス２０とサーバ４０との間で通信するための方法１００のフローチャートを示す。ステップ１１０で、ウェイクアップメッセージが開始される。これは、サーバ４０によって直接行われても、またはサーバ４０にプロセスを開始させる別のエンティティによって行われてもよい。いくつかの例示的な実装形態では、開始はデバイス２０自体から生じてもよい。この場合、デバイス２０がスリープモードにある状態でデバイス２０内で実施されるプロセスが、この開始をトリガしてもよい。デバイス２０を内部でウェイクアップさせることは、デバイス２０がサーバ４０との通信を保護するために鍵９０を受信または取得するのを待つ間、リソースを浪費する場合がある。したがって、記載されたウェイクアップ手順は、デバイス２０自体から生じる場合でも利点を保持する。

【0054】

ステップ１２０において、GPIが取得される。これは、NAF７０または別のエンティティからのものであってもよい。GPIは、ステップ１３０でデバイスに送信されるウェイクアップメッセージに組み込まれる。クレデンシャルはステップ１４０で認証される。これは、デバイス２０および／またはサーバ４０によるものであってもよい。例示的な実装形態では、この認証は、GBAを使用して、および／またはデバイス２０内のSIMもしくはUICC３０を使用することによって達成されてもよい。この認証の結果は、鍵９０または鍵９０を導出するための資料（例えば、そのUICCまたはSIM３０を使用する）である。

【0055】

鍵９０は、ステップ１５０において、デバイス２０とサーバ４０との間の通信を保護するために使用される。方法１００は、ウェイクアップメッセージが送信されるたびに異なる鍵９０と共に使用することができ、または必要に応じて鍵９０は頻繁に変更されてもよい（例えば、ウェイクアップメッセージは、ウェイクアップメッセージが送信される場合にのみ、または毎回GPI内にセキュリティクレデンシャルを含むことができる）。したがって、異なる鍵を（例えば定期的または常に）使用するセキュリティの向上は、（少なくともデバイス２０の）必要なコンピューティング、帯域幅、または電力リソースを大幅に増加させることはない。

【0056】

前述したように、異なる証明書ベースのセキュリティプロトコルを使用して、デバイス２０とサーバ４０との間の通信を保護してもよい。図４、図５、図６、および図７は、異なるセキュリティプロトコルの使用の特定の例示的な実装形態、ならびにこれらのセキュリティプロトコルおよび保護された通信をセットアップするために使用される特定の代替方法ステップを示す。

【0057】

図４は、デバイス２０とサーバ４０との間でトランスポート層セキュリティ(TLS：transport layer security)セキュリティプロトコル通信がどのようにセットアップされるかを示す。この図は、このプロセスの一部として使用され得る様々な例示的なステップを含むシーケンス図を示す。図３を参照して説明した方法と同様に、アプリケーションサーバ４０は、APIハブ６０へのAPI呼び出しを使用して、ウェイクアッププロシージャを開始する（または外部要求に応答してデバイスまたはデバイスのグループをウェイクアップする）か、またはウェイクアップメッセージを作成する。ここでも、APIハブ６０は、NAFプッシュサーバ７０からGPIを要求し、次いでこの要求に応答してGPIがAPIハブ６０に返される。この例示的な実装形態では、APIハブ６０はまた、GPIのそれ自体の認証を（例えば、GAA８０またはその他を用いて）行うことができるようにGPIをアプリケーションサーバ４０に返し、その結果、Ks_NAF鍵がサーバ４０に利用可能になる。SMS（セキュリティクレデンシャルを有するGPIを含む）がデバイス２０に送信される。

【0058】

上述したように、GAAサーバ８０は、GPIおよびセキュリティクレデンシャルを認証するためにデバイス２０（いくつかの例示的な実装形態では、サーバ４０）によって使用される。この例示的な実装形態では、この認証の結果は、サーバ４０に利用可能である同じKs_NAF鍵である（それに転送されるか、または認証結果として導出される）。

【0059】

デバイス２０およびサーバ４０は、ここで、CAを使用する必要なしに互いにTLS接続を作成するために使用できる鍵９０を所有している。デバイス２０は、Ks_NAFを使用してクライアントのTLS接続コンテキストを作成することによってこれを行う。サーバ４０は、NAFプッシュサーバ７０においてAPIハブ６０を介してKs_NAFを検証する。NAFプッシュサーバ７０は、再度APIハブ６０を介してアプリケーションサーバ４０に検証結果を返す。

【0060】

TLS接続コンテキストが確立され、アプリケーションサーバ４０からデバイス２０へのTLSハンドシェイクが完了する。これにより、デバイス２０とアプリケーションサーバ４０との間でTLS保護ソケット接続が達成される。

【0061】

鍵(Ks_NAF)９０がAPIハブ６０または他の場所のいずれかからサーバ４０に直接提供されると、Ks_NAFを検証して検証結果を返すための、APIハブ６０を介したサーバ４０とNAFプッシュサーバ７０との間の図４に示す４つのステップは、もはや必要ではなくなる。これにより、方法の効率がさらに向上する。この代替案は、図４、図５、図６、および図７のいずれかに関して説明した例を含む任意のセキュリティプロトコル実装に使用することができる。サーバ４０が事前共有鍵(PSK：pre-shared key)に提供されてもよく、したがってさらなる鍵を安全に受信することができるので、この例示的な実装形態ではセキュリティを維持することができる。

【0062】

図５は、図４を参照して説明した方法と同様の方法のシーケンス図を示す。しかしながら、TLS接続が確立される代わりに、DTLS接続が確立される。図５から分かるように、ウェイクアップメッセージおよび封入されたGPIがIoTデバイス２０に送信された後に、DTLS接続コンテキストが確立され、DTLSハンドシェイクが完了する。これらの同じステップの説明は、TLS接続およびコンテキストではなくDTLSを使用することを除いて、図４を参照して説明したものと同じであるため、繰り返さない。図５から分かるように、アプリケーションサーバ４０およびデバイス２０は、セキュアな方法で任意の通信を完了するためのDTLSユーザデータグラムプロトコル(UDP：user datagram protocol)ソケット接続を達成する。DTLSは通常CAを必要とするが、ここでも、CAは必要とされない。

【0063】

図６は、方法１００の代替の例示的な実装形態を示し、図４および図５を参照して説明されているが、IoT（または他の）デバイス２０とアプリケーションサーバ４０との間にクイックUDPインターネット接続(QUIC：Quick UDP Internet Connections)プロトコルセッションが確立される結果となる。ここでも、この図は、デバイス２０がGAAサーバ２００を使用してSMS内で受信されたGPIを認証する点まで、図４および図５を参照して説明したものと同じステップを含む。シーケンスのこの段階で、デバイスは、Ks_NAFをゼロラウンドトリップタイム(0-RTT：zero round trip time)鍵として使用してQUICセッションを開始する。この方法を使用して、デバイスは、QUICセッションを介したデータの送信を直ちに開始することができる。これは、事前にサーバ４０からの返信を必要とせずに、デバイス２０およびアプリケーションサーバ４０の両方が鍵を知っているためである。

【0064】

双方向QUICセッションが確立され、ハンドシェイクが完了する。これにより、例えばデバイス２０とサーバ４０との間の多重化および暗号化されたQUIC接続がもたらされる。

【0065】

図７は、図６を参照して説明した方法と同様の方法のシーケンス図を示す。しかしながら、この例示的な実装形態では、QUICセッションはPSKを使用して実装される。ここでも、IoTデバイス２０がGAAサーバ２００を使用してGPIを認証し、Ks_NAFを取得する方法の時点まで、図４、図５、および図６を参照して説明したのと同じ方法ステップが実施される。プロセスのこの時点で、デバイス２０は、PSKとしてKs_NAFを使用してQUICセッションを初期化する。双方向QUICセッションが確立され、ハンドシェイクが完了し、その結果、デバイス２０とアプリケーションサーバとの間で多重化および暗号化されたQUIC接続が達成される。

【0066】

デバイス２０にプロビジョニングされるUICCまたはSIMが、セキュリティクレデンシャルおよびセキュリティクレデンシャルの導出を管理するためのハードウェアトークンとして使用されてもよい。デバイス２０とサーバ４０との間のセキュアな通信のために（暗号チャレンジを提示する）鍵を提供する必要はない。この方法は、低いオーバーヘッドでセキュアな通信を必要とし、モバイルエッジコンピューティング(MEC：mobile edge computing)に特に適している任意の用途で使用することができる。

【0067】

クライアント主導の手法に対する記載されたシステムおよび方法のさらなる利点は、以下を含む。

【0068】

１．デバイス２０は、UaまたはUbフローをサポートする必要がなく、デバイスソリューションの複雑さおよびデュアルAPNの必要性を低減する。

【0069】

２．デバイス２０は、GAAサーバをサポートする必要がなく、いくつかのGAAタイプの機能を依然として必要とするが、これらははるかに単純である。

【0070】

３．アプリケーションフローは、SSLライブラリ機能に組み込むことができ、すなわち、デバイスがGPIパケットを有すると、そのパケットをTLSハンドシェイク（または他の証明書ベースのセキュリティプロトコル）へのパラメータとして使用することができ、必要なのはデバイスコーディングの観点からである。SSLライブラリはまた、GBAフローのために追加されたサポートを有してもよい。

【0071】

４．ユーザ（例えば、商業的エンティティ）には、デバイス２０およびアプリケーションサーバ４０の両方に配備される拡張SSLライブラリ機能を提供してもよい。

【0072】

５．デバイス２０は、サーバ４０と証明書を交換する必要も、CAチェーンをウォークする必要もない。これにより、伝送されるデータの量および必要な電力バジェットが低減される。

【0073】

６．システムおよび方法は、TLS１．３または他のセキュリティプロトコルをサポートすることができる。

【0074】

７．システムおよび方法は、UDPおよびTCP／IPトランスポートプロトコルをサポートすることができる。

【0075】

GPIは、デバイス２０内のSIM、UICC、またはUSIMがKsを生成し、GAAサーバ８０が対応するKs_NAFを生成するのに十分な情報を含む。これは、通常のGBAに使用されるのと同じ鍵導出と同様である。

【0076】

コンピュータシステムおよびアーキテクチャは、中央処理装置（CPU）などのプロセッサを含んでもよい。プロセッサは、ソフトウェアプログラムの形態のロジックを実行してもよい。コンピュータシステムは、揮発性および不揮発性記憶媒体を含むメモリを含んでもよい。ロジックまたはプログラム命令を記憶するためにコンピュータ可読媒体が含まれてもよい。システムの異なる部分は、ネットワーク（例えば、無線ネットワークおよび有線ネットワーク）を使用して接続されてもよい。コンピュータシステムは、１つ以上のインターフェースを含んでもよい。コンピュータシステムは、例えば、UNIX、Windows（RTM）またはLinuxなどの適切なオペレーティングシステムを含んでもよい。

【0077】

当業者には理解されるように、上記の実施形態の詳細は、添付の特許請求の範囲によって定義される本発明の範囲から逸脱することなく変更されてもよい。

【0078】

例えば、デバイスまたはクライアントは、それ自体でウェイクアップ要求をプロンプトまたは発行してもよい。サーバ４０は、セキュアな通信チャネルのセットアップの一部としてTLS（または任意の他の）ハンドシェイクを受け入れることに進む前に、検証要求を実施してもよい。さらに、図４および図５に示すAPIハブ６０（または他の方法）を介してNAFプッシュサーバ７０を用いて新しいKs_NAFを検証するステップを実施するサーバ４０と同様に、サーバ４０は、以前に獲得したKs_NAFの有効期限が切れたか、切れようとしているか、または失効したかどうかを問い合わせてもよい。そのような状況が発生した（すなわち、新しいKs_NAFが必要であると決定された）場合、サーバ４０をトリガして、NAFプッシュサーバ４０から新しいKs_NAFを取得することができる（または、より単純に、新しいKs_NAFをトリガして、応答としてサーバ４０に送信することができる）。

【0079】

GAAサーバ（または構成要素）は、デバイス２０のSIM、UICC、またはUSIM内（またはモデム内）に実装されてもよく、その結果、デバイスにインストールする必要があるコードが少なくなる。

【0080】

TLS（およびDTLS）プロセス内で、サーバ４０は、Ks_NAFをNAFプッシュサーバ７０と連携して使用して、着信接続を認証し、サーバ４０上の鍵を導出してもよい。

【0081】

他の方法を使用して、デバイス２０とのセキュアな通信を達成するために鍵９０をサーバ４０に提供してもよい。例えば、NAFプッシュサーバ７０は、ウェイクアップが最初にトリガされたときにGPIをサーバ４０に返すことができ、代替的に、デバイス２０からのリターン経路によってサーバ４０にGPIを供給することができる。

【0082】

opensslドライバライブラリは、例えば拡張として実装されるNAFプッシュサーバ７０機能を実装してもよく、opensslドライバライブラリはまた、opensslコード内のGAAサーバ機能を含むことができる。

【0083】

１つのデバイスおよび単一のサーバが図に示されているが、ネットワークまたはデバイスのグループ、ならびに２つ以上のサーバまたはアプリケーションサーバが、記載されたシステムおよび方法と共に使用されてもよい。デバイスのグループは、例えば、１つ以上のサーバによって管理されても、または１つ以上のサーバと通信してもよい。

【0084】

デバイスウェイクアップに続いて、他のアクションを行ってもよい。例えば、センサまたは他のデータは、セキュアな通信チャネルを介して伝送されてもよい。ファームウェア更新は、セキュアな通信チャネルまたは他のデバイス管理アクションを介して行われてもよい。これらは、デバイス動作に関する決定（例えば、バッテリレベル、信号レベル、デバイスの健全性など）を含んでもよい。

【0085】

ウェイクアップメッセージを説明してきたが、これは、特定のインターフェース（例えば、SMS）を介して受信されたメッセージの形態を取ってもよく、特定のメッセージタイプまたは他の属性を有してもよく、ウェイクアップメッセージである明示的な指定または名前を含むことができるが、必ずしも含まなくてもよい。

【0086】

ウェイクアップメッセージは、デバイス自体によって開始されてもよい。この場合、デバイスは「ウェイクミーアップメッセージ」を発行してもよい。これは、特定の低電力モードまたは他の場合、例えば、データまたは他の通信をアクティブに送信するときよりも少ないリソースを使用するときに、デバイスと共に送信することができる。サーバは、どの特定のデバイスがウェイクアップされることを要求しているか（例えば、それをよりアクティブにし、有用なデータを再び伝送させる）を様々な方法で決定することができる。例えば、デバイスを決定するために使用される情報は、そのSIMまたはUICCのIMSIであってもよい。

【0087】

この情報は、ウェイクミーアップ要求内でデバイスから明示的に送信されてもよい。代替的に、この情報は間接的に推測することができる。例えば、デバイス（またはIMSI）は、アクセスポイント名(APN)接続がセットアップされ、その後、サーバ、アプリケーション、またはアプリケーションサーバに間接的に通信された場合に決定されてもよい。

【0088】

これは、データ伝送を必要とせずに、APN接続を開閉するときのデバイス上のデータ通信およびアクティビティ（または電力使用量）を低減するという利点を有する。デバイスがデータ接続を開くと、デバイスのアイデンティティを有するRadiusサーバに要求が送信されてもよい。Radius（または他の）サーバは、接続を認証し、接続が使用できるいくつかのリソース（例えば、IPアドレスなど）を割り当てる。その後、Radiusサーバは、特定のIMSIを有するデバイスが「ウェイクミーアップ」プロセスの実行を要求したことをNAFまたはAPI機能に通信することができる。

【0089】

上記の実施形態の特徴に対する多くの組み合わせ、修正、または代替は、当業者には容易に明らかであり、本発明の一部を形成することを意図している。１つの実施形態または例に具体的に関連して説明された特徴のいずれも、適切な変更を行うことによって任意の他の実施形態で使用されてもよい。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【国際調査報告】