(57)【要約】【課題】端末の再接続に伴う鍵交換を容易にする。【解決手段】自装置の入出力機能と端末の入出力機能との組み合わせに応じて端末と通信用の暗号鍵を交換する複数の方法の一つを選択する通信装置である。この通信装置は端末との接続実績を示す情報を記憶する記憶部と、接続対象の端末との接続実績を示す情報が前記記憶部に記憶されている場合に、前記接続対象の端末との暗号鍵の交換が自動的に実行される方法が前記複数の方法から選択される前記組み合わせとなる入出力機能を前記自装置の入出力機能として出力する制御部とを含む。【選択図】図３Ｂ
2018152775.tif 000002
【特許請求の範囲】
【請求項１】
自装置の入出力機能と端末の入出力機能との組み合わせに応じて端末と通信用の暗号鍵を交換する複数の方法の一つを選択する通信装置において、
端末との接続実績を示す情報を記憶する記憶部と、
接続対象の端末との接続実績を示す情報が前記記憶部に記憶されている場合に、前記接続対象の端末との暗号鍵の交換が自動的に実行される方法が前記複数の方法から選択される前記組み合わせとなる入出力機能を前記自装置の入出力機能として出力する制御部と
を含む通信装置。
【請求項２】
前記記憶部は前記接続実績のある端末の内部情報を記憶し、
前記接続対象の端末から取得された内部情報と一致する内部情報が前記記憶部に記憶されていない場合に前記制御部は前記接続対象の端末との切断処理を行う
請求項１に記載の通信装置。
【請求項３】
前記内部情報は前記端末の固有情報である
請求項２に記載の通信装置。
【請求項４】
前記内部情報は前記端末に関する属性名である
請求項２又は３に記載の通信装置。
【請求項５】
前記記憶部は前記接続実績のある端末にて計測されたデータの履歴を記憶し、
前記接続対象の端末から得られたデータの値が前記データの履歴から求まる変化の許容範囲外である場合に前記制御部は前記接続対象の端末との切断処理を行う
請求項１から４のいずれか１項に記載の通信装置。
【請求項６】
前記記憶部は前記接続実績のある端末に書き込まれたデータを記憶し、
前記接続実績のある端末に書き込まれたデータが前記接続対象の端末から得られない場合に前記制御部は前記接続対象の端末との切断処理を行う
請求項１から５のいずれか１項に記載の通信装置。
【請求項７】
前記制御部は前記接続対象の端末のアドレスがランダムアドレスである場合に前記接続対象の端末との暗号鍵の交換が自動的に実行される方法が前記複数の方法から選択される前記組み合わせとなる入出力機能を前記自装置の入出力機能として出力し、前記接続対象の端末のアドレスがランダムアドレスでない場合に前記接続対象の端末についての接続実績を示す情報が記憶されているか判定する
請求項１に記載の通信装置。
【請求項８】
前記制御部は、前記通信装置との通信可能範囲にあり、且つ同一のアドレスを有する接続対象の端末の数に応じて、接続対象の端末と接続実績のある端末とが同一かを判定する複数の方法から実行する方法の数を変更する
請求項１に記載の通信装置。
【請求項９】
端末と、
自装置の入出力機能と端末の入出力機能との組み合わせに応じて端末と通信用の暗号鍵を交換する複数の方法の一つを選択する通信装置とを含み、
前記通信装置は、
端末との接続実績を示す情報を記憶する記憶部と、
接続対象の端末との接続実績を示す情報が前記記憶部にある場合に、前記接続対象の端末との暗号鍵の交換が自動的に実行される方法を前記複数の方法から選択する前記組み合
わせとなる入出力機能を前記自装置の入出力機能として出力する制御部と
を含む通信システム。
【請求項１０】
自装置の入出力機能と端末の入出力機能との組み合わせに応じて端末と通信用の暗号鍵を交換する複数の方法の一つを選択する通信装置が、
端末との接続実績を示す情報を記憶し、
接続対象の端末との接続実績を示す情報が前記記憶部に記憶されている場合に、前記接続対象の端末との暗号鍵の交換が自動的に実行される方法が前記複数の方法から選択される前記組み合わせとなる入出力機能を前記自装置の入出力機能として出力する
ことを含む通信制御方法。
【請求項１１】
前記接続実績のある端末の内部情報を記憶し、
前記接続対象の端末から取得された内部情報と一致する内部情報が前記記憶部に記憶されていない場合に前記接続対象の端末との切断処理を行う
ことをさらに含む請求項１０に記載の通信制御方法。
【請求項１２】
自装置の入出力機能と端末の入出力機能との組み合わせに応じて端末と通信用の暗号鍵を交換する複数の方法の一つを選択する通信装置のコンピュータに、
端末との接続実績を示す情報を記憶し、
接続対象の端末との接続実績を示す情報が前記記憶部に記憶されている場合に、前記接続対象の端末との暗号鍵の交換が自動的に実行される方法が前記複数の方法から選択される前記組み合わせとなる入出力機能を前記自装置の入出力機能として出力する
処理を実行させるプログラム。
【請求項１３】
前記接続実績のある端末の内部情報を記憶し、
前記接続対象の端末から取得された内部情報と一致する内部情報が前記記憶部に記憶されていない場合に前記接続対象の端末との切断処理を行う
処理を前記コンピュータにさらに実行させる請求項１２に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置、通信システム、通信制御方法、及びプログラムに関する。
【背景技術】
【０００２】
近年、Internet of Things（ＩｏＴ）サービスが普及している。ＩｏＴサービスでは、大量の機器やセンサがインターネットに接続され、機器やセンサによって収集された大量をサービスが利用される。収集されたデータを用いて機器へのフィードバックがなされる場合もある。
【０００３】
ＩｏＴサービスにおいて使用される機器及びセンサ（ＩｏＴ機器）は、配線の困難な場所に設置されることが少なくない。この場合、端末はバッテリからの電力を受けて動作する。バッテリで動作する端末は、通信方法として、低消費電力の近距離無線通信の一つであるBluetooth（登録商標） Low Energy（ＢＬＥ）を利用する場合が増加している。
【０００４】
ＢＬＥを用いて通信する機器（「ＢＬＥデバイス」、或いは「デバイス」と称する）からの電波の到達距離には制限がある。また、ＢＬＥデバイスはInternet Protocol（ＩＰ
）通信を行うことができない。このため、ゲートウェイ（ＧＷ）と呼ばれる装置がＢＬＥデバイスを収容（ネットワーク的に接続）し、インターネット上のＩｏＴサービスとの通信を仲介する。
【０００５】
ＢＬＥでは、安全な通信を行うために、「ペアリング」と呼ばれる暗号鍵交換及びマスタ−スレーブ関係の確立手順が行われる。ペアリングによって、マスタ（親機：ＧＷ）とスレーブ（子機：デバイス）との間で暗号鍵を交換する。交換した暗号鍵を記憶しておき、再度の接続時に記憶した交換鍵を用いて手作業を不要とする方法は「ボンディング」と呼ばれる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特表２０１６−５０１６０９号公報
【特許文献２】国際公開第２００８／０６９２９９号
【特許文献３】特開２０１６−１２７３９７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ＢＬＥデバイスの中にはボンディング機能を有せず、ＧＷから切断された場合にＧＷとの再接続に伴うペアリングを人手で行うものがある。しかし、ＢＬＥデバイスの設置場所によっては人手によるペアリングが困難又は煩雑な場合があった。
【０００８】
本発明は、端末との再接続に伴う鍵交換を容易にすることが可能な通信装置技術を提供することを目的とする。
【課題を解決するための手段】
【０００９】
一つの態様は、自装置の入出力機能と端末の入出力機能との組み合わせに応じて端末と通信用の暗号鍵を交換する複数の方法の一つを選択する通信装置である。この通信装置は端末との接続実績を示す情報を記憶する記憶部と、接続対象の端末との接続実績を示す情報が前記記憶部に記憶されている場合に、前記接続対象の端末との暗号鍵の交換が自動的に実行される方法が前記複数の方法から選択される前記組み合わせとなる入出力機能を前
記自装置の入出力機能として出力する制御部とを含む。
【発明の効果】
【００１０】
一側面では、端末との再接続に伴う鍵交換を容易にすることができる。
【図面の簡単な説明】
【００１１】
【図１】図１はペアリング方法の選択方法の説明図である。
【図２】図２は実施形態１に係る通信システムの構成例を示す図である。
【図３Ａ】図３Ａは実施形態の動作例を説明するフローチャートである。
【図３Ｂ】図３Ｂは実施形態の動作例を説明するフローチャートである。
【図４】図４は接続実績管理テーブルＴ１のデータ構造例を示す。
【図５】図５はデバイス内部情報管理テーブルＴ２のデータ構造例を示す。
【図６】図６は乱数保存用属性管理テーブルＴ３のデータ構造例を示す。
【図７Ａ】図７Ａは同一性検証処理のサブルーチンの例を示すフローチャートである。
【図７Ｂ】図７Ｂは同一性検証処理のサブルーチンの例を示すフローチャートである。
【図８】図８はデバイス内部情報管理テーブルＴ４のデータ構造例を示す。
【図９】図９はＧＷに適用可能な情報処理装置（コンピュータ）のハードウェア構成例を示す。
【図１０】図１０は実施形態２における処理を示すフローチャートである。
【図１１】図１１は実施形態３における処理を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下、図面を参照して、実施形態について説明する。実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。
【００１３】
上述したように、ＢＬＥでは、安全な通信を行うために、ペアリングと呼ばれる暗号鍵交換及びマスタ−スレーブ関係の確立手順が行われる。ペアリングによって、マスタ（親機：ＧＷ）とスレーブ（子機：デバイス）との間で暗号鍵を交換する。ペアリングの方法には、例えば、Just Works、Passkey Entry、Numeric Comparison、Out-of-Band（ＯＯＢ：Bluetooth（登録商標） 以外の通信 (ＵＳＢやＮＦＣ)による確認）の４種類がある。
４つのペアリングの方法は、「端末と通信用の暗号鍵を交換する複数の方法」の一例であり、Just Worksは「暗号鍵の交換が自動的に実行される方法」の一例である。
【００１４】
Just Worksではペアリングにおいてユーザの操作及び作業は発生しない。Passkey Entryでは、ペアリング時にユーザが６桁の数字のパスキー（認証コード）を入力する作業が
発生する。Numeric Comparisonでは、ユーザが子機と親機との双方で同一の情報が表示されたことを確認した旨を入力する作業が発生する。Out-of-Bandでは、ユーザがデバイス
に貼付されたNear Field Communication（ＮＦＣ）などをＧＷに読み取らせる等の作業が発生する。
【００１５】
実施形態では、ＧＷに対するデバイスの接続時に、ＧＷが接続実績を参照して新規接続か再接続か（接続実績の有無）を判定し、再接続の場合（接続実績がある場合）に適切なペアリング方法が選択されるように、デバイスに提示する入出力機能（IO Capability）
情報を制御する。
【００１６】
ＢＬＥの仕様によれば、子機（デバイス）と親機（ＧＷ）との接続時に使用されるペアリング方法は、マスタ（親機）となるＧＷとスレーブ（子機）となるデバイスとのそれぞれの入出力機能（IO Capability）によって決定される。すなわち、ＧＷがデバイスにＧ
Ｗ自身の入出力機能のタイプを提示し、デバイスがデバイス自身のタイプを提示し、ＧＷがタイプの組み合わせによってペアリング方法を選択（決定）する。
【００１７】
図１はペアリング方法の選択方法の説明図である。図１には、デバイスの入出力機能とＧＷの入出力機能との対応関係によって決まるペアリング方法が表形式で示されている。上記対応関係は「自装置（通信装置）の入出力機能と端末の入出力機能との組み合わせ」の一例である。
【００１８】
入出力機能は、「DisplayOnly」（タイプ１と称する）、「DisplayYesNo」（タイプ２
と称する）、「KeyboardOnly」（タイプ３と称する）、及び「NoInputNoOutput」（タイ
プ４と称する）に分類される。タイプ１は入力機能を有せず、出力機能として数字を出力する。タイプ２は入力機能としてＹｅｓ／Ｎｏボタンまたはキーボードを有し、出力機能として数字を出力する。タイプ３では入力機能としてキーボードを有するが、出力機能を有しない。タイプ４は入力機能を有しないかＹｅｓ／Ｎｏボタンを有し、出力機能を有しない。
【００１９】
図１の表において、縦がデバイスの入出力機能（タイプ１〜４）を示し、横がＧＷの入出力機能（タイプ１〜４）を示す。例えば、デバイスがタイプ１でＧＷがタイプ１の場合、ペアリング方法としてJust Worksが選択される。デバイスがタイプ１でＧＷがタイプ３の場合、Passkey Entryが選択される。このように、デバイスのタイプとＧＷのタイプと
の組み合わせでペアリング方法が決定される。
【００２０】
実施形態では、デバイスが新規接続（すなわち、デバイスのＧＷへの最初の接続）の場合、通常のセキュアなペアリング方法が選択されるように、ＧＷは本来の入出力機能（ＧＷがサポートするタイプ）をデバイスに提示（出力）する。
【００２１】
これに対し、デバイスが再接続（すなわち、デバイスのＧＷへの再度の接続）の場合、ＧＷはＧＷの入出力機能（タイプ）としてタイプ４（NoInputNoOutput）をデバイスに提
示（出力）する。これによって、デバイスとＧＷとの再接続の場合には、ＧＷのタイプに関わらず、ペアリング方法として手動操作が不要なJust Worksが選択される。
【００２２】
但し、Just Worksに用いるペアリングでは、Bluetooth（登録商標） Device （ＢＤ）
アドレスと実際に接続されるデバイスとの対応関係が保証されない。このため、例えば、悪意を持つ第三者がＢＤアドレスが詐称された不正なデバイスを現場に持ち込み、その不正なデバイスをＧＷに接続する可能性がある。そこで、デバイスの再接続前にデバイスから取得した情報を利用して、再接続されたデバイスが元のデバイスと同一であることを検証する。検証方法として、例えば、以下の４通りの方法がある。
【００２３】
（方法１）デバイス識別情報による検証（静的特性）  
Bluetooth（登録商標）のDevice Information Serviceを用い、デバイスの固有情報の
提供をＧＷが受ける。固有情報は、例えば、ベンダＩＤ（メーカ名）、プロダクトＩＤ（モデル番号）、シリアル番号などである。再接続されたデバイスから提供された固有情報の値が、切断前に取得した固有情報の値と一致しない場合は、ＧＷは再接続されたデバイスを異なるデバイスとみなす。
【００２４】
（方法２）属性名による検証（静的特性）
ＢＬＥにおける属性名はUniversally Unique Identifier（ＵＵＩＤ）で表現される。
属性名（ＵＵＩＤ）は、デバイスベンダやデバイス製品毎に異なる。再接続されたデバイスの属性名が再接続前（切断前）に取得された属性情報と一致しない場合は、ＧＷは再接続されたデバイスを異なるデバイスとみなす。
【００２５】
（方法３）センサデータによる検証（動的属性）
最初の接続後、デバイスから取得される属性値（センサデータ）を監視し、連続的に変化する属性値（センサデータ）の単位時間当たりの変化量を計算する。属性値（センサデータ）は、例えば、クロック、温度、湿度、気圧、位置などを利用できるが、これら以外を適用し得る。例えば、ＧＷはデバイスとの切断から再接続までの時間を計測し、計測した時間内での属性値の変化量が上記で計算した単位時間当たりの変化量の範囲に収まらない場合に再接続されたデバイスを異なるデバイスとみなす。換言すれば、接続対象のデバイス（端末）から得られたデータの値が前記データの履歴から求まる変化の許容範囲外である場合に接続対象のデバイスとの切断処理を行う。デバイスが複数のセンサを含む場合、複数の属性値を組み合わせてもよい。
【００２６】
（方法４）書込み属性による検証（動的属性）
方法４は、属性値を書込み可能なデバイスに適用可能である。ＧＷはデバイスとの切断前にデバイスの属性値としての乱数をデバイスに書き込み、再接続後に属性値（乱数）が一致するか否かをチェックする。一致しない場合、再接続されたデバイスが異なるデバイスと見なされる。
【００２７】
方法１〜４の少なくとも一つを適用できる。例えば、方法１と方法２とを採用し、精度向上のため、さらに方法３と方法４の少なくとも一方を採用することが考えられる。ＧＷは方法１〜４の少なくとも一つを行い、再接続されたデバイスの同一性を検証する。ＧＷはデバイスが同一でないと判定する場合、デバイスとの接続を切断する。
【００２８】
ＢＤアドレスはＢＬＥの電波を観測することで第三者が知ることが可能である。しかし、上記した方法１〜４で使用される情報はデバイスの内部情報であり、暗号通信によりＧＷとデバイスとの間で送受信される。このような内部情報を第三者は知り得ない。第三者が不正なデバイスをＧＷに接続するのを抑止することができる。
【００２９】
＜実施形態の詳細＞
＜＜実施形態１＞＞
図２は実施形態に係る通信システムの構成例を示す図である。図２に示す通信システムは、ＧＷ１と、ＧＷ１に接続し、ＧＷ１とＢＬＥ通信（無線通信）を行うＢＬＥデバイス２（以下、「デバイス２」）とを含む。ＧＷ１は広域網を介してクラウド上のサーバ３と接続される。ＧＷ１は「通信装置」の一例であり、デバイス２は「端末」の一例である。
【００３０】
例えば、ＢＬＥデバイス２はセンサを含み、センサによって得られたデータ（センサデータ）はＢＬＥ通信によりＧＷ１へ送信される。ＧＷ１はセンサデータを広域網を介してサーバ３へ送る。サーバ３はアプリケーションプログラム（アプリ）を実行することによってセンサデータを収集する。アプリケーションは例えばＩｏＴサービスを提供するアプリケーションであり、ＢＬＥデバイス２はＩｏＴ機器として動作することができる。センサデータは蓄積され、所望の目的に使用される。場合によっては、センサデータに基づくデータが生成され、ＢＬＥデバイス２にフィードバックされる。
【００３１】
実施形態に係るデバイス２は、ボンディング機能を持たない。ボンディング機能は、ペアリングの際に交換した鍵情報を記憶しておき、再接続時には記憶しておいた鍵情報を利用した接続を行い、再接続時におけるユーザの手作業を回避する機能である。
【００３２】
ＧＷ１は、接続対象のデバイス２との接続が初回である場合には、ＧＷ１が有する入出力機能のタイプとデバイス２の入出力機能のタイプとの組み合わせに応じたペアリング方法でペアリングを行う。これに対し、ＧＷ１は、接続対象のデバイス２との接続が再接続
（２回目以降）である場合（接続対象のデバイス２との接続実績が記憶されている場合）には、デバイス２に提示するＧＷ１の入出力機能を操作する。
【００３３】
すなわち、ＧＷ１は、デバイス２と交換するＧＷ１の入出力機能としてタイプ４（NoInputNoOutput）を提示する。これによって、再接続時におけるペアリング方法として、人
手による操作が不要なJust Worksが選択される。さらに、ＧＷ１は、デバイス２の内部情報を利用して、デバイス２が再接続前のＢＬＥデバイスと同一であることを検証する。
【００３４】
通信部１１は、ＢＬＥの仕様に従ったデバイス２とのデータ通信処理を実行する。接続制御部１２は、ＢＬＥの仕様に従って、デバイス２の発見（スキャン）や接続処理などを実行する。実績管理部１３は、実際にＢＬＥ接続したデバイス２のＢＤアドレスを記憶し、接続されるデバイス２が以前に接続されたものか否か（新規接続か再接続か）を判定する。
【００３５】
ペアリング制御部１４は、デバイス２の接続実績に応じてペアリング方法を決定し、決定したペアリング方法を用いたペアリング処理を実行する。判定部１５は、デバイス２から取得されたデバイス２の内部情報を利用し、デバイス２の接続可否を判定する。内部情報管理部１６は、デバイス２の内部情報を記憶する。内部情報はデバイス２の再接続時の接続認可判定に使用される。データ処理部１７は、デバイス２から取得されたデータをサーバ３（アプリ）に送信したり、サーバ３（アプリ）からの制御命令をデバイス２に送信したりする。
【００３６】
＜動作例＞
デバイス２の接続時におけるデバイス２及びＧＷ１の動作例は以下の通りである。図３Ａ及び図３Ｂは実施形態の動作例を説明するフローチャートである。ＧＷ１に接続されていたデバイス２が再起動（リフレッシュ等を目的として一旦切断後に再接続）、あるいは新規にＧＷ２に接続する場合がある。これらの場合には、デバイス２は一定の時間間隔で、接続用のアドバタイズメッセージ（アドバタイズ情報）をブロードキャスト送信する（００１）。
【００３７】
ＧＷ１の接続制御部２は、アドバタイズ情報を受信し、アドバタイズ情報に含まれるデバイス２のＢＤアドレスを特定し、特定したＢＤアドレスを有するデバイス２を指定した接続要求をデバイス２向けに送信し、接続処理を開始する（００２）。
【００３８】
接続要求を受信したデバイス２は、接続要求で指定されたＢＤアドレスが自デバイスのＢＤデバイスであることを契機にＧＷ１との接続処理を行う（００３）。デバイス２とのリンク接続が確立すると、接続制御部１２は、実績管理部１３に、デバイス２が以前に接続したデバイスか否かを問い合わせる。
【００３９】
実績管理部１３は、接続実績管理テーブルを用いて各ＢＬＥデバイスの最終接続時刻を管理している。図４は接続実績管理テーブルＴ１（テーブルＴ１）のデータ構造例を示す。テーブルＴ１は、ＢＤアドレスに対応する最終接続時刻を記憶する。ＢＤアドレスはデバイス２の識別子である。最終接続時刻はデバイス２が最後にＧＷ１と接続した時刻を示す。
【００４０】
実績管理部１３は、テーブルＴ１を用いた検索を行い（００４）、テーブルＴ１にＢＤアドレスが登録されているか否かを以て、デバイス２の接続実績の有無を判定する（００５）。但し、最終接続時刻からの経過時間が閾値を超過する場合には、実績管理部１３は接続実績なしと判定しても良い。
【００４１】
実績管理部１３が「接続実績なし」と判定した場合、新規デバイスの接続処理が実行される。すなわち、接続制御部１２は、ＧＷ１が持っている本来の入出力機能（IO Capability）を示す情報（入出力機能情報）をデバイス２に送信する（００６）。入出力機能情
報を受信したデバイス２も、デバイス２が有するデバイス２の入出力機能情報をＧＷ１に送信する（００７）。
【００４２】
デバイス２の入出力機能情報はＧＷ１の接続制御部１２で受信される。接続制御部１２は、取得したデバイス２の入出力機能情報をペアリング制御部１４に渡す。ペアリング制御部１４は、ＧＷ１及びデバイス２の入出力機能情報（タイプの組み合わせ）に対応するペアリング方法を用いてペアリングを実行する（００８、００９）。このとき、デバイス２は新規接続であるので、ＧＷ１はＧＷ２の本来の入出力機能情報を利用し、例えば図１の表に従ってペアリング方法が決定される。或いは、図１の表を用いる以外の方法で、手作業を伴うPasskey Entry、Numeric Comparison、Out-of-Bandのいずれかが決定及び実行されても良い。
【００４３】
ペアリング制御部１４は、ペアリングにおいてデバイス２と暗号通信用の鍵情報を交換し、安全な通信方法を確保する。このとき、ペアリングに時間が掛かり過ぎた場合（所定時間内にペアリングが成功しない場合：０１０のＮＯ）には、タイムアウトが発生し、ペアリング失敗による切断処理がＧＷ１とデバイス２との間で実行される（０１１、０１１Ａ）。また、ペアリングの際の入力情報として不正な入力がなされた場合にも切断処理が実行される。
【００４４】
ペアリングが所定時間内に成功した場合には（０１０のＹＥＳ）、実績管理部１３はテーブルＴ１（図４）を更新する。すなわち、デバイスのＤＢアドレスと最終接続時刻をテーブルＴ１に記憶する（０１２）。
【００４５】
内部情報管理部１６は、デバイス２からDevice Information Serviceによる固有情報および属性名リストを、通信部１１経由でデバイス２から取得（受信）し、記憶する。内部情報管理部１６は、内部情報管理テーブルＴ２（テーブルＴ２）を用いてデバイス２の内部情報を管理する。
【００４６】
図５は内部情報管理テーブルＴ２（テーブルＴ２）のデータ構造例を示す。テーブルＴ２は各デバイス２のＢＤアドレスに対応するデバイス識別情報と属性名リストと乱数とを記憶するエントリによって形成される。ＢＤアドレスはデバイス２の識別子であり、デバイス識別情報はデバイス２の固有情報であり、ベンダＩＤ，プロダクトＩＤ，シリアル番号などを含む。属性名リストは、同一性の判定に利用可能な属性名のリストである。属性名としてＵＵＩＤを使用できる。乱数は同一性検証の方法４で使用される乱数である。
【００４７】
内部情報管理部１６はテーブルＴ２にデバイス２から得たデバイス識別情報及び属性名リストを記憶する。内部情報管理部１６は、さらに乱数保存用属性管理テーブルＴ３（テーブルＴ３）を管理する。
【００４８】
図６は乱数保存用属性管理テーブルＴ３（テーブルＴ３）のデータ構造例を示す。テーブルＴ３は、デバイス識別情報条件と利用可能属性名とが登録された１以上のエントリを有する。デバイス識別情報条件は対象デバイスを限定する、デバイス識別情報に関する条件である。利用可能属性名はデバイス２の外部から値を書き込んでも問題のない属性の名前（項目）を示す。デバイス識別情報がテーブルＴ３に登録されたベンダＩＤやプロダクトＩＤを有する場合に、対応する属性名に乱数を書き込むことが決定される。
【００４９】
内部情報管理部１６はデバイス識別情報がテーブルＴ３のデバイス識別情報条件にマッ
チ（合致）する場合に（０１４のＹＥＳ）、乱数を生成して、デバイス２の利用可能属性に対する書き込み処理を行う（０１５）。すなわち、乱数がデバイス２に属性情報として記憶される。乱数の値は、テーブルＴ２（図５）の対応するエントリ中の「乱数」にも書き込まれる。なお、テーブルＴ３の登録内容は事前に用意される。なお、デバイス２に対する乱数の書き込みは、ＧＷ１からデバイス２を再起動させる直前に行っても良い。
【００５０】
実績管理部１３が「接続実績あり」と判定した場合（００５のＹＥＳ）、接続制御部１２は、ＧＷ１の入出力機能（IO Capability）情報として、ＧＷ１の本来のタイプに関わ
らずタイプ４（NoInputNoOutput）をデバイス２に送信（出力）する（０１５Ａ）。デバ
イス２は、本来の（通常の）デバイス２の入出力機能（IO Capability）情報をＧＷ１に
送信する（０１６）。
【００５１】
ＧＷ１のペアリング制御部１４は、図１に示した表（タイプの組み合わせ）に従ってペアリング方法を選択する。このとき、ＧＷ１の入出力機能（IO Capability）はタイプ４
（NoInputNoOutput）である。このため、ペアリング制御部１４はペアリング方法としてJust Worksを選択し、Just Worksによるペアリングを実行する（０１７、０１８）。Just Worksは人手による再接続の操作を必要としない。このため、ＧＷ１とデバイス２との間
で自動的に鍵交換が行われる。
【００５２】
電波障害などで、鍵交換に失敗したと判定される場合には（０１９のＮＯ）、ペアリング失敗として切断処理を行う（０２０、０２０Ａ）。ペアリングに成功したと判定される場合には（０１９のＹＥＳ）、内部情報管理部１６が管理するデバイス２の内部情報を利用し、判定部１５が切断前のデバイス２と接続処理中のデバイス２の同一性を検証する（０２１）。
【００５３】
検証の結果においてデバイス２が一致しないと判定される場合には（０２２のＮＯ）、データ通信部１１がデバイス２との切断処理を行う（０２０、０２０Ａ）。これに対し、検証の結果においてデバイス２が同一と判定される場合には（０２２のＹＥＳ）、デバイス２との接続を維持し、実績管理部１３の接続実績情報を更新する（０２３）。
【００５４】
図７Ａ及び図７Ｂは同一性検証処理（０２１）のサブルーチンの例を示すフローチャートである。以下の通りである。最初に、判定部１５は上述した検証の方法１〜４のうちの方法４を実行する。すなわち、判定部１５はデバイス２がデバイス識別用の情報（実施形態では乱数）を書き込み可能な属性を有するか否かを判定する（０３１）。
【００５５】
デバイス２が書き込み可能な属性を有しないと判定される場合には（０３１のＹＥＳ）、判定部１５は方法４以外の検証方法を実行する。デバイス２が書き込み可能な属性を有すると判定される場合には（０３１のＮＯ）、判定部１５は書き込み可能属性の値をデバイス２から取得する（０３２）。
【００５６】
書き込み可能属性の値がデバイス２から取得されたと判定される場合（０３３のＹＥＳ）、判定部１５はデバイス２との切断前に記憶しておいた乱数値と書き込み可能属性の値とを比較して両者が一致するかを判定する（０３４）。
【００５７】
書き込み可能属性の値と乱数値とが一致すると判定される場合には（０３４のＹＥＳ）、判定部１５は検証結果として「同一」を返却してサブルーチンが終了し、処理が０２３に進む。これに対し、属性値の取得に失敗したと判定される場合（０３３のＮＯ）、あるいは属性値が一致しないと判定される場合には（０３４のＮＯ）、判定部１５は処理を０３６に進めて方法４以外の方法を実行する。
【００５８】
０３６では、判定部１５はデバイス２のDevice Information Serviceを利用し、デバイス２が記憶しているデバイス識別情報（固有情報：例えばベンダＩＤ、プロダクトＩＤ、シリアル番号の少なくとも一つ）を取得する。
【００５９】
固有情報が取得できたと判定される場合には（０３７のＹＥＳ）、判定部１５は内部情報管理部１６にて管理されている固有情報と比較し、両者が一致するかを判定する（０３８）。
【００６０】
固有情報が一致すると判定される場合には（０３８のＹＥＳ）、処理が０４０に進み、次の検証方法が実行される。これに対し、固有情報の取得が失敗したと判定される場合（０３７のＮＯ）、あるいは固有情報が一致しないと判定される場合には（０３８のＮＯ）、判定部１５はデバイス２が切断前のものと「不同一」との検証結果を返却する（０３９）。
【００６１】
０４０では、判定部１５は方法２を実行する。すなわち、判定部１５はデバイス２から各サービス・キャラクタリスティックの属性名（通常ＵＵＩＤで表現される）のリストを取得する（０４０）。
【００６２】
属性名のリストが取得できたと判定される場合には（０４１のＹＥＳ）、判定部１５は属性名を内部情報管理部１６が管理する情報と比較し、両者が一致するかを判定する（０４２）。一致すると判定される場合（０４２のＹＥＳ）、判定部は０４３に処理を進め、次の検証方法を実行する。
【００６３】
属性名の取得に失敗したと判定される場合（０４１のＮＯ）、あるいは取得された属性名が一致しないと判定される場合には（０４２のＮＯ）、デバイス２が切断前のものと不同一として扱われる（０３９）。なお、デバイス２のバッテリ消費量を削減するために、属性名の代わりに、サービス・キャラクタリスティックの名前（名前もＵＵＩＤで表現される）を利用することもできる。
【００６４】
０４３では、判定部１５は方法３を実行する。判定部１５は検証に利用可能なセンサデータをデバイス２から取得する。判定部１５は以前（切断前に）収集したセンサデータの履歴を読み出し、切断からの経過時間内で変化し得る値の範囲を推定し、取得されたセンサデータが上記推定範囲に収まっているかを判定する。換言すれば、最後に取得されたセンサデータと取得されたセンサデータとの差分が履歴から求まる所定の変化量の範囲に入っているかを判定する。
【００６５】
取得されたセンサデータが上記の範囲内に含まれていると判定される場合は（０４７のＹＥＳ）、判定部１５はデバイス２を同一として扱い（０３５）、そうでない場合は（０４７のＮＯ）、判定部１５はデバイス２を不同一として扱う（０３９）。
【００６６】
なお、方法３の検証に使用されるセンサデータの履歴情報は、サーバ３（アプリ）がデバイス２からセンサデータを取得する際、あるいはデバイス２がサーバ３（アプリ）にセンサデータを送信する際に取得される。すなわち、データ処理部１７がデータ通信部１１を介してセンサデータを取得し、内部情報管理部１６が管理するデバイス内部情報管理テーブルＴ４（テーブルＴ４）に記憶される。
【００６７】
図８はデバイス内部情報管理テーブルＴ４（テーブルＴ４）のデータ構造例を示す。テーブルＴ４は、センシング時刻，ＢＤアドレス及びセンサデータを記憶するエントリの集合で形成される。エントリの集合体が履歴を形成する。
【００６８】
図７Ａ及び図７Ｂを用いた処理の例では、方法１から方法４の全てを利用する場合について説明した。但し、方法１から方法４のうち実行する方法の数及び実行の順序は適宜設定可能である。例えば、ＢＬＥデバイスがアクチュエータ（何かを制御する機器）である場合、センシングを殆ど行わないことが考えられる。この場合、方法３を実施せず、方法１と方法２を行うことが考えらえる。また、現場に導入されたデバイス２の全てが書込み可能な属性を有する場合には方法１から方法４のうち方法４を実行しても良い。
【００６９】
＜＜ハードウェア構成＞＞
図９はＧＷ１に適用可能な情報処理装置（コンピュータ）４０のハードウェア構成例を示す図である。情報処理装置４０は、一例として、バスＢ１を介して相互に接続されたCentral Processing Unit（ＣＰＵ）４１と、主記憶装置４２と、補助記憶装置４３とをＵ
含む。さらに、情報処理装置４０は、ＢＬＥインタフェース（ＢＬＥ  ＩＦ）４４と、通信インタフェース（通信ＩＦ）４５と、入力装置４６と、出力装置４７とを含む。
【００７０】
主記憶装置４２はプログラムの展開領域、ＣＰＵ４１の作業領域、データやプログラムの記憶領域、通信データのバッファ領域などとして使用される。主記憶装置４２は、例えばRandom Access Memory（ＲＡＭ）、ＲＡＭとRead Only Memory（ＲＯＭ）との組み合わせで形成される。
【００７１】
補助記憶装置４３はデータやプログラムの記憶領域として使用される。補助記憶装置４３は、例えば、ハードディスクドライブ（ＨＤＤ）、Solid State Drive（ＳＳＤ）、フ
ラッシュメモリ、Electrically Erasable Programmable Read-Only Memory（ＥＥＰＲＯ
Ｍ）などの不揮発性記憶媒体で形成される。主記憶装置４２及び補助記憶装置４３のそれぞれは、「記憶装置」、「記憶媒体」、「メモリ」、「記憶部」の一例である。
【００７２】
ＢＬＥ  ＩＦ４４は、ＢＬＥをサポートする通信回路である。通信ＩＦ４５は通信処理を司る。通信ＩＦ４５には例えばNetwork Interface Card（ＮＩＣ）が使用される。入力装置４６は、例えば、キー、ボタン、ポインティングデバイス（マウスなど）、タッチパネル、音声入力装置（マイクロフォン）などである。出力装置４７は、例えばディスプレイである。出力装置４７は、プリンタ、スピーカ、ランプなどを含み得る。
【００７３】
ＣＰＵ４１は、主記憶装置４２及び補助記憶装置４３の少なくとも一方に記憶されたプログラムを主記憶装置４２にロードして実行する。プログラムの実行によって、情報処理装置４０はＧＷ１としての動作を行う。
【００７４】
主記憶装置４２及び補助記憶装置４３の少なくとも一方（図９では補助記憶装置４３を例示）は、上記した図３Ａ,図３Ｂ,図７Ａ及び図７Ｂに示した処理を実行するためのプログラム（接続制御プログラム）を記憶する。また、主記憶装置４２及び補助記憶装置４３の少なくとも一方（図９では補助記憶装置４３を例示）は、テーブルＴ１（図４）,テー
ブルＴ２（図５）,テーブルＴ３（図６）及びテーブルＴ４（図８）を記憶している。
【００７５】
ＣＰＵ４１は接続制御プログラムを実行することによって、図２に示した通信部１１，接続制御部１２，実績管理部１３，ペアリング制御部１４，判定部１５，内部情報管理部１６，及びデータ処理部１７として動作する。図３Ａ,図３Ｂ,図７Ａ及び図７Ｂに示すＧＷ１の処理の実行主体はＣＰＵ４１である。
【００７６】
ＣＰＵ４１は、「制御装置」、「制御部」、「コントローラ」の一例である。ＣＰＵ４１は、ＭＰＵ（Microprocessor）、プロセッサとも呼ばれる。ＣＰＵ４１は、単一のプロセッサに限定される訳ではなく、マルチプロセッサ構成であってもよい。また、単一のソケットで接続される単一のＣＰＵがマルチコア構成を有していても良い。ＣＰＵ４１で行
われる処理の少なくとも一部は、マルチコア又は複数のＣＰＵで実行されても良い。ＣＰＵ４１で行われる処理の少なくとも一部は、ＣＰＵ４１以外のプロセッサ、例えば、Digital Signal Processor(ＤＳＰ)、Graphics Processing Unit（ＧＰＵ）、数値演算プロセッサ、ベクトルプロセッサ、画像処理プロセッサ等の専用プロセッサで行われても良い。
【００７７】
また、ＣＰＵ４１によって行われる処理の少なくとも一部は、集積回路（ＩＣ）、その他のディジタル回路で行われても良い。また、集積回路やディジタル回路はアナログ回路を含んでいても良い。集積回路は、ＬＳＩ、Application Specific Integrated Circuit
（ＡＳＩＣ）、プログラマブルロジックデバイス（ＰＬＤ）を含む。ＰＬＤは、例えば、Field-Programmable Gate Array(ＦＰＧＡ)を含む。ＣＰＵ４１で行われる処理の少なく
とも一部は、プロセッサと集積回路との組み合わせにより実行されても良い。組み合わせは、例えば、マイクロコントローラ（ＭＣＵ）、ＳｏＣ（System-on-a-chip）、システムＬＳＩ、チップセットなどと呼ばれる。
【００７８】
デバイス２は、少なくともＣＰＵ４１，主記憶装置４２，補助記憶装置４３，ＢＬＥ  ＩＦ４４と同様のＣＰＵ，主記憶装置，補助記憶装置，ＢＬＥ  ＩＦを含む。さらに、デバイス２はセンサデータを得るためのセンサを含み得る。デバイス２のＣＰＵはＢＬＥ  ＩＦを用いてＧＷ１との接続及び切断処理の制御を行う。このとき、ＧＷ１からの要求に応じて入出力機能情報，デバイス識別情報，属性名のリストを送信する。また、デバイス２のＣＰＵはセンサなどを用いて取得したデータ（センサデータを含む）をＢＬＥ  ＩＦを用いてＧＷ１へ送信する処理や、サーバ３（アプリ）からのデータをＧＷ１を介して受信する処理などを行う。
【００７９】
＜＜実施形態１の効果＞＞
実施形態１に係るＧＷ１によれば、ＧＷ１がデバイス２との接続実績を示す情報を記憶する。ＧＷ１は接続対象のデバイス２が接続実績の情報が記憶されているデバイス２である場合（再接続の場合）に、人手による操作が不要な（自動的に実行される）ペアリング方法を自動的に選択して出力する。
【００８０】
これによって、デバイス２の再接続にあたって作業者がデバイス２の設置場所に赴いたり、デバイス２やＧＷ１に情報を入力したりする作業（手間）を回避することができる。すなわち、デバイス２の再接続に伴うペアリングを容易にすることができる。
【００８１】
また、ＧＷ１によれば、接続対象のデバイス１の内部情報を用いて接続対象のデバイス２が元々接続していたデバイス２と同一か否かを人手を介することなく検証可能である。これによって、接続対象のデバイス２が接続を意図しないデバイス（不正なデバイス）である場合に切断することができる。これによって通信の安全を確保し得る。
【００８２】
＜実施形態２＞
以下、実施形態２について説明する。実施形態２は実施形態１との共通点を有するので、主として相違点について説明し、共通点については説明を省略する。
【００８３】
ＢＬＥの仕様上、ＢＤアドレスとしてランダムアドレスが規定されており、再起動の度にＢＤアドレスが変更されるデバイスがあり得る。そのようなデバイスの場合、常に接続実績がないことになり、毎回人手による操作が必要なペアリングが要求される。実施形態２はＢＤアドレスとしてランダムアドレスが規定されたデバイス２に対する処理について説明する。
【００８４】
図１０は、実施形態２に係る処理例を示すフローチャートである。図１０の処理は、例えばＧＷ１のＣＰＵ４１によって実行される。図１０において、００１、００２及び００
３の処理は実施形態１と同じあるので説明を省略する。
【００８５】
１０１において、ＣＰＵ４１は、接続対象のデバイス２のＢＤアドレスを取得し（１０１）、取得したＢＤアドレスがランダムかどうかを判定する（１０２）。ＢＤアドレスがランダムアドレスでないと判定される場合（１０２のＮＯ）、ＣＰＵ４１は図３Ａに示した００４以降の処理を実行する（１０３）。これに対し、ＢＤアドレスがランダムアドレスであると判定される場合は（１０２のＹＥＳ）、ＧＷ１の入出力機能としてタイプ４を出力し、Just Worksを用いた暗号鍵の交換を実施する。さらに、ＣＰＵ４１は図３Ｂの０１５Ａ以降の処理を行い、同一性検証を実施する（１０４）。
【００８６】
ＣＰＵ４１は、同一性検証が成功したか否かの判定を行う（１０５）。同一性検証が失敗したと判定される場合（１０５のＮＯ）、ＣＰＵ４１はデバイス２との切断処理を行う（１０６）。その後、図３Ａの００６以降の処理を実行しても良い。
【００８７】
実施形態２では、接続対象のデバイス２（端末）の数に応じて、接続対象のデバイス２と接続実績のあるデバイス２とが同一かを判定する複数の方法から実行する方法の数を変更する。実施形態２によれば、ＢＤアドレスがランダムアドレスの場合には、タイプ４の選択によりJust Worksを用いた自動的なペアリングを行い作業の軽減を図る。また、同一性の検証を以て、意図しない（不正な）デバイス２との切断を行うことができる。
【００８８】
＜＜実施形態３＞＞
以下、実施形態３について説明する。実施形態３は実施形態１との共通点を有するので、主として相違点について説明し、共通点については説明を省略する。
【００８９】
実施形態１では、デバイス２を再接続する際に，基本的にデバイスの同一性を判定する４種類の方法をすべて実行することを想定していた。しかし、再接続処理の実行時にＧＷ１の周辺（ＧＷ１との通信可能範囲）に、切断したデバイス２と同じＢＤアドレスを持つデバイス２が１つだけ存在する場合，デバイス２の同一性検証を簡易化しても不正接続の可能性は少ない。また、簡易化によって、デバイスの再接続に要する通信を減らすことができ，デバイスのバッテリ消費も抑えることが可能である。
【００９０】
逆に同じＢＤアドレスを持つデバイス２が複数存在する場合は、不正なデバイス２を収容しないように，厳密に同一性を検証する必要がある．実施形態３では上記の状況を想定してなされたものである。
【００９１】
実施形態３は、実施形態１で説明したＧＷ１の構成（図２）を適用可能である。但し、しかし，接続制御部１２がデバイス２を発見する際に，周辺でアドバタイズメッセージをブロードキャストしているデバイス２の個数を記憶しておき、判定部１５に接続可否を問合せる際に、デバイス２の個数を通知する。さらに、判定部１５が実行する同一性検証の処理（方法）が周辺のデバイス２の数に応じたものとなる。
【００９２】
図１１は、実施形態３に係るＧＷ１のＣＰＵ４１（判定部１５）の処理例を示すフローチャートである。図１１の処理は、ＧＷ１の周辺に存在するデバイス２が１つか複数かで実施する同一性検証方法を変更する。
【００９３】
３０１では、ＣＰＵ４１は周辺のデバイス２の数が１つか否かを判定する。デバイス２の数が１であると判定する場合（３０１のＹＥＳ）、ＣＰＵ４１は方法１から４のうち、方法２を実行する（３０２）。これに対し、デバイスの数が複数と判定する場合（３０１のＮＯ）、ＣＰＵ４１は方法４，方法１，方法２，方法３の順でそれぞれの方法を実行する。但し、実行の順序は適宜変更可能である。
【００９４】
実施形態３によれば、同一のアドレスを有するデバイス２の数に応じて実行する同一性検証方法の数を変更することで、デバイスとの通信量を減らしデバイスの消費電力を削減できる。実施形態にて説明した構成は例示であり、適宜組み合わせることができる。
【符号の説明】
【００９５】
１・・・ゲートウェイ（ＧＷ）
２・・・ＢＬＥデバイス
４１・・・ＣＰＵ
４２・・・主記憶装置
４３・・・補助記憶装置
【図１】
2018152775.tif 000003
【図２】
2018152775.tif 000004
【図３Ａ】
2018152775.tif 000005
【図３Ｂ】
2018152775.tif 000006
【図４】
2018152775.tif 000007
【図５】
2018152775.tif 000008
【図６】
2018152775.tif 000009
【図７Ａ】
2018152775.tif 000010
【図７Ｂ】
2018152775.tif 000011
【図８】
2018152775.tif 000012
【図９】
2018152775.tif 000013
【図１０】
2018152775.tif 000014
【図１１】
2018152775.tif 000015