特許 6282680 身元確認方法、同方法を用いるＩｏＴゲートウェイ装置、及び検証ゲートウェイ装置

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6282680

(24)【登録日】2018年2月2日

(45)【発行日】2018年2月21日

(54)【発明の名称】身元確認方法、同方法を用いるＩｏＴゲートウェイ装置、及び検証ゲートウェイ装置

(51)【国際特許分類】

   H04L 9/32 20060101AFI20180208BHJP

   H04W 12/06 20090101ALI20180208BHJP

   H04W 64/00 20090101ALI20180208BHJP

   G06F 21/44 20130101ALI20180208BHJP

【ＦＩ】

   H04L9/00 673B

   H04W12/06

   H04W64/00 110

   G06F21/44

【請求項の数】13

【外国語出願】

【全頁数】16

(21)【出願番号】特願2016-30739(P2016-30739)

(22)【出願日】2016年2月22日

(65)【公開番号】特開2017-46338(P2017-46338A)

(43)【公開日】2017年3月2日

【審査請求日】2016年2月22日

(31)【優先権主張番号】62/210,421

(32)【優先日】2015年8月26日

(33)【優先権主張国】US

(31)【優先権主張番号】14/957,602

(32)【優先日】2015年12月3日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】396008783

【氏名又は名称】大同股▲ふん▼有限公司

(73)【特許権者】

【識別番号】507369121

【氏名又は名称】大同大學

(74)【代理人】

【識別番号】100147485

【弁理士】

【氏名又は名称】杉村 憲司

(74)【代理人】

【識別番号】100161148

【弁理士】

【氏名又は名称】福尾 誠

(74)【代理人】

【識別番号】100134577

【弁理士】

【氏名又は名称】石川 雅章

(72)【発明者】

【氏名】鄭 福炯

(72)【発明者】

【氏名】張 伯仲

(72)【発明者】

【氏名】潘 泰吉

【審査官】 青木 重徳

(56)【参考文献】

【文献】 特開２０１６−０２５５９８（ＪＰ，Ａ）

【文献】 特開２０１１−０３００３８（ＪＰ，Ａ）

【文献】 特開２００６−０２３９３４（ＪＰ，Ａ）

【文献】 新たな価値を創造する先進的なサービスの実現に向けたＮＴＴサービスエボリューション研究所のＲ＆Ｄ展開，ＢＵＳＩＮＥＳＳ ＣＯＭＭＵＮＩＣＡＴＩＯＮ，日本，株式会社ビジネスコミュニケーション社，２０１３年 ６月 １日，第５０巻 第６号，ｐ．５０−５１

【文献】 蜂谷 達郎 ほか，空間依存情報を用いた場所ベース認証方式，マルチメディア，分散，協調とモバイル（ＤＩＣＯＭＯ２０１３）シンポジウム論文集 ［ＣＤ−ＲＯＭ］，日本，一般社団法人情報処理学会，２０１３年 ７月１０日，Ｖｏｌ．２０１３ Ｎｏ．２，ｐ．１４２１−１４２７

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ ９／３２

Ｇ０６Ｆ ２１／４４

Ｈ０４Ｗ １２／０６

Ｈ０４Ｗ ６４／００

(57)【特許請求の範囲】

【請求項1】

モノのインターネット（ＩｏＴ）ゲートウェイ装置に適合された身元確認方法であって、
少なくとも一つの正当なクライアント装置の正当なメディアアクセス制御（ＭＡＣ）アドレスのリスト及び正当な受信信号強度指示（ＲＳＳＩ）の範囲を含むルックアップテーブルを確立するステップと、
少なくとも一つのクライアント装置から送信される、該クライアント装置のＭＡＣアドレスを含む接続要求を受信するステップと、
前記接続要求に基づいて前記クライアント装置のＭＡＣアドレス及びＲＳＳＩ値を取得するステップと、
前記クライアント装置が正当なクライアント装置であるかどうかを決定するために、前記クライアント装置のＭＡＣアドレス及びＲＳＳＩ値を前記正当なＭＡＣアドレスのリスト及び前記正当なＲＳＳＩの範囲と比較するステップと、
を備え、
前記正当なクライアント装置の正当なＭＡＣアドレスのリスト及び正当な受信信号強度（ＲＳＳＩ）の範囲を含むルックアップテーブルを確立する前記ステップは、
正当であると決定されたクライアント装置のＭＡＣアドレスを前記正当なＭＡＣアドレスのリストに追加するステップと、
前記正当であると決定されたクライアント装置のＲＳＳＩ値に基づいてＲＳＳＩの範囲を計算するステップと、
前記計算したＲＳＳＩの範囲を前記正当であると決定されたクライアント装置のＭＡＣアドレスに対応する正当なＲＳＳＩの範囲として前記ルックアップテーブルに追加するステップと、を備える、身元確認方法。

【請求項2】

前記クライアント装置が正当なクライアント装置であるかどうかを決定するために、前記クライアント装置のＭＡＣアドレス及びＲＳＳＩ値を前記正当なＭＡＣアドレスのリスト及び前記正当なＲＳＳＩの範囲と比較する前記ステップは、
前記クライアント装置のＭＡＣアドレスが前記正当なＭＡＣアドレスのリストに記録された正当なＭＡＣアドレスであるかどうかを決定するステップと、
前記クライアント装置のＲＳＳＩ値が前記正当なＭＡＣアドレスに対応する正当なＲＳＳＩの範囲に入るかどうかを決定するステップと、
前記ＭＡＣアドレスが前記正当なＭＡＣアドレスであり且つ前記ＲＳＳＩ値が前記正当なＲＳＳＩの範囲に含まれると決定されたとき、前記クライアント装置は正当なクライアント装置であると決定するステップと、
を備える、請求項１記載の身元確認方法。

【請求項3】

プリセット期間内に前記ＩｏＴゲートウェイ装置により受信される前記接続要求の数が閾値を超えるかどうかを決定するステップと、
前記接続要求の数が閾値を超えるとき、パケットフィルタリング機構を活性化するステップと、
を更に備える、請求項１記載の身元確認方法。

【請求項4】

前記接続要求の数が閾値を超えるとき、パケットフィルタリング機構を活性化する前記ステップは、
前記ＩｏＴゲートウェイ装置がＭＡＣアドレス及びＲＳＳＩの範囲からなる新たな入力データを前記ルックアップテーブルに追加するのを中止するステップを備える、請求項３記載の身元確認方法。

【請求項5】

検証ゲートウェイ装置に更に適合された請求項３記載の身元確認方法であって、前記接続要求の数が閾値を超えるとき、パケットフィルタリング機構を活性化する前記ステップは、
前記クライアント装置を認証するために前記接続要求を前記検証ゲートウェイ装置で受信するステップと、
前記正当であると決定されたクライアント装置のＭＡＣアドレス及びＲＳＳＩ値を含むテーブル追加通知を前記ＩｏＴゲートウェイ装置へ送信するステップと、を備え、
前記ＩｏＴゲートウェイ装置は、前記パケットフィルタリング機構が活性化されるとき、前記テーブル追加通知から受信される前記ＭＡＣアドレス及びＲＳＳＩの範囲を前記ルックアップテーブルに追加することを単に許可するだけである、身元確認方法。

【請求項6】

前記接続要求の数が閾値を超えるとき、パケットフィルタリング機構を活性化する前記ステップは更に、
前記クライアント装置に再接続通知を送信するステップを備え、前記クライアント装置は前記再接続通知に応答して前記ＩｏＴゲートウェイ装置に再接続する、請求項５記載の身元確認方法。

【請求項7】

少なくとも一つのクライアント装置に無線接続サービスを提供するように適合されたＩｏＴゲートウェイ装置であって、
無線通信回路と、
複数のモジュールを格納するメモリ回路と、
前記無線通信回路及び前記メモリ回路に結合され、前記無線通信回路の動作を制御し、前記メモリ回路にアクセスして前記複数のモジュールを実行する処理装置と、
を備え、前記複数のモジュールは、
少なくとも一つの正当なクライアント装置の正当なＭＡＣアドレスのリスト及び正当なＲＳＳＩの範囲を含むルックアップテーブルを確立するルックアップテーブル確立モジュールと、
接続要求に基づいて前記クライアント装置のＭＡＣアドレス及びＲＳＳＩ値を取得する情報取得モジュールと、
前記クライアントが正当なクライアント装置であるかどうかを決定するために、前記接続要求を受信し、前記クライアント装置の前記ＭＡＣアドレス及び前記ＲＳＳＩ値を前記正当なＭＡＣアドレスのリスト及び前記正当なＲＳＳＩの範囲と比較する検証モジュールと、
を備え、
前記ルックアップテーブル確立モジュールは、正当であると決定されたクライアント装置のＭＡＣアドレスを前記正当なＭＡＣアドレスのリストに追加するとともに前記正当であると決定されたクライアント装置のＲＳＳＩの範囲を前記正当であると決定されたクライアント装置のＭＡＣアドレスに対応する正当なＲＳＳＩの範囲として前記ルックアップテーブルに追加し、前記ＲＳＳＩの範囲は前記正当であると決定されたクライアント装置のＲＳＳＩ値に基づいて前記情報取得モジュールによって計算される、ＩｏＴゲートウェイ装置。

【請求項8】

前記検証モジュールは、前記クライアント装置のＭＡＣアドレスが前記正当なＭＡＣアドレスのリストに記録された正当なＭＡＣアドレスであるかどうか及び前記クライアント装置のＲＳＳＩ値が前記正当なＭＡＣアドレスに対応する正当なＲＳＳＩの範囲内かどうかを決定し、前記検証モジュールは、前記ＭＡＣアドレスが前記正当なＭＡＣアドレスであり且つ前記ＲＳＳＩ値が前記正当なＲＳＳＩの範囲内であると決定されたとき、前記クライアント装置は正当なクライアント装置であると決定する、請求項７記載のＩｏＴゲートウェイ装置。

【請求項9】

前記検証モジュールは更に、前記接続要求の数がプリセット期間内に閾値を超えるかどうかを決定し、前記接続要求の数が閾値を超えるときパケットフィルタリング機構を活性化する、請求項７記載のＩｏＴゲートウェイ装置。

【請求項10】

前記パケットフィルタリング機構が活性化されるとき、前記検証モジュールは前記ルックアップテーブル確立モジュールが新たにＭＡＣアドレス及びＲＳＳＩの範囲を前記ルックアップテーブルに追加するのを中止する、請求項９記載のＩｏＴゲートウェイ装置。

【請求項11】

前記パケットフィルタリング機構が活性化されるとき、前記ルックアップテーブル確立モジュールは、検証ゲートウェイ装置から受信されるテーブル追加通知に基づいて前記クライアント装置のＭＡＣアドレス及びＲＳＳＩの範囲を追加するだけである、請求項９記載のＩｏＴゲートウェイ装置。

【請求項12】

ＩｏＴゲートウェイ装置のために少なくとも一つのクライアント装置を検証するように適合された検証ゲートウェイ装置であって、
無線通信回路と、
複数のモジュールを格納するメモリ回路と、
前記無線通信回路及び前記メモリ回路に結合され、前記無線通信回路の動作を制御し、前記メモリ回路にアクセスして前記複数のモジュールを実行する処理装置と、
を備え、前記複数のモジュールは、
前記クライアント装置の接続要求を受信し、前記クライアント装置を認証する認証モジュールと、
前記接続要求に基づいて前記クライアント装置のＭＡＣアドレス及びＲＳＳＩ値を取得する情報取得モジュールと、
前記クライアント装置が認証されたとき、認証されたクライアント装置のＭＡＣアドレス及びＲＳＳＩ値を含むテーブル追加通知を前記ＩｏＴゲートウェイ装置に送信する通知モジュールと、
を備え、
前記クライアント装置を検証することは、前記情報取得モジュールが取得する前記クライアント装置の前記ＭＡＣアドレスおよび前記ＲＳＳＩ値を前記ＩｏＴゲートウェイ装置のルックアップテーブルの正当なＭＡＣアドレスのリスト及び正当なＲＳＳＩの範囲と比較し、認証された前記クライアント装置が正当なクライアント装置であるかどうかを決定することである、検証ゲートウェイ装置。

【請求項13】

前記通知モジュールは更に前記クライアント装置に再接続通知を送信する、請求項１２記載の検証ゲートウェイ装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、無線通信技術に関し、特に身元確認方法、同方法を用いるＩｏＴゲートウェイ装置、及び検証ゲートウェイ装置に関する。

【背景技術】

【0002】

１９９９年に生まれたモノのインターネット（ＩｏＴ）の概念は、ＲＦＩＤ、赤外線、ＧＰＳ、レーザ走査及びその他の情報センシング装置をインターネットに無線接続し、情報の交換及び通信、インテリジェント識別、位置決定、追跡、監視及び知覚層まで延びる触手で得られる更なる情報の管理を通してより広い相互運用性を達成することにある。

【0003】

ＩｏＴ技術のアプリケーションが益々開発され、商業的に展開されるに伴い、無線ネットワークのセキュリティが重大な懸念になってきている。概して、無線データネットワークへのアクセスの制御は従来の有線ネットワークへのアクセスの制御よりずっと難しい。不正アクセスポイント（ＡＰ）又は不正クライアント装置は追跡が難しく所在確認が難しいハッカーにより展開され得る。加えて、不正クライアント装置はネットワークをサービス拒否攻撃で攻撃し、不正アクセスを得ることができる。

【発明の概要】

【発明が解決しようとする課題】

【0004】

ＩｏＴ技術においては、接続のセキュリティを高めるためにライアント装置の身元を確認し、ゲートウェイ装置が不正にアクセスするのを防止する方法が解決すべき重要な課題である。

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

【0005】

本発明はモノのインターネット（ＩｏＴ）ゲートウェイ装置に適合された身元確認方法を提供する。本方法は以下のステップ：少なくとも一つの正当なクライアント装置の正当なメディアアクセス制御（ＭＡＣ）アドレスのリスト及び正当な受信信号強度指示（ＲＳＳＩ）の範囲を含むルックアップテーブルを確立するステップと、少なくとも一つのクライアント装置から送信される、該クライアント装置のＭＡＣアドレスを含む接続要求を受信するステップと、前記接続要求に基づいて前記クライアント装置のＭＡＣアドレス及びＲＳＳＩ値を取得するステップと、前記クライアント装置が正当なクライアント装置であるかどうかを決定するために、前記クライアント装置のＭＡＣアドレス及びＳＳＩ値を前記正当なＭＡＣアドレスのリスト及び前記正当なＲＳＳＩの範囲と比較するステップを含む。

【0006】

本発明は、無線通信回路、メモリ回路、及び処理装置を含むＩｏＴゲートウェイ装置を提供する。メモリ回路は複数のモジュールを格納する。処理装置は無線通信回路及びメモリ回路に結合され、無線通信回路の動作を制御し、メモリ回路にアクセスし、前記複数のモジュールを実行する。前記複数のモジュールは、ルックアップテーブル確立モジュール、情報取得モジュール、及び検証モジュールを含む。ルックアップテーブル確立モジュールは、少なくとも一つの正当なクライアント装置の正当なＭＡＣアドレスのリスト及び正当なＲＳＳＩの範囲を含むルックアップテーブルを確立する。情報取得モジュールは、接続要求に基づいてクライアント装置のＭＡＣアドレス及びＲＳＳＩ値を取得する。検証モジュールは、接続要求を受信し、クライアント装置が正当なクライアント装置であるかどうかを決定するためにクライアント装置のＭＡＣアドレス及びＲＳＳＩ値を正当なＭＡＣアドレスのリスト及び正当なＲＳＳＩの範囲と比較する。

【0007】

本発明は、無線通信回路、メモリ回路、及び処理装置を含む検証ゲートウェイ装置を提供する。メモリ回路は複数のモジュールを含む。処理装置は無線通信回路及びメモリ回路に結合され、無線通信回路の動作を制御し、メモリ回路にアクセスし、前記複数のモジュールを実行する。前記複数のモジュールは、認証モジュール、情報取得モジュール、及び通知モジュールを含む。認証モジュールは、クライアント装置の接続要求を受信し、クライアント装置を認証する。情報取得モジュールは、接続要求に基づいてクライアント装置のＭＡＣアドレス及びＲＳＳＩ値を取得する。通知モジュールは、クライアント装置が認証されたとき、認証されたクライアント装置のＭＡＣアドレス及びＲＳＳＩ値を含むテーブル追加通知を送信する。

【発明の効果】

【0008】

以上の記載によれば、本発明の実施形態は身元確認方法、同方法を用いるＩｏＴゲートウェイ装置、及び検証ゲートウェイ装置を提供する。本発明の方法を適用すると、ＩｏＴゲートウェイ装置はクライアント装置を更にＲＳＳＩ値に基づいて検証することができる。よって、不正クライアント装置が正当／正規のＭＡＣアドレスを偽造してＩｏＴゲートウェイ装置にアクセスしようと試みても、ＩｏＴゲートウェイ装置は接続されるクライアント装置のＲＳＳＩ値を検証することによって不正クライアント装置をブロックすることができ、ＩｏＴシステムの接続セキュリティを高めることができる。

【図面の簡単な説明】

【0009】

【図1】本発明の一実施形態によるＩｏＴシステムの概略図である。

【図2】本発明の一実施形態による身元確認方法のフローチャートである。

【図3】図１に示すＩｏＴシステムに基づく本発明の一実施形態によるクライアント装置検証プロセスを示す概略的フローチャートである。

【図4】図１に示すＩｏＴシステムに基づく本発明の別の実施形態によるクライアント装置検証プロセスを示す概略的フローチャートである。

【図5】本発明の別の実施形態によるＩｏＴシステムの概略図である。

【図6】図５に示すＩｏＴシステムに基づく本発明の一実施形態によるクライアント装置検証プロセスを示す概略的フローチャートである。

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

【0010】

添付図面は、本発明の更なる理解を提供するために本明細書に組み込まれ、本明細書の一部を成している。添付図面は本発明の実施形態を図解し、本発明の原理の説明に役立つものである。

【0011】

これから本発明の好ましい実施形態が詳細に説明され、そのいくつかの例が添付図面に示されている。可能な限り、同一もしくは類似部分は図面及び明細書中で同じ参照番号で示されている。

【0012】

図１は、本発明の一実施形態によるＩｏＴシステムの概略図である。図１を参照すると、本実施形態のＩｏＴシステム１００は、ＩｏＴゲートウェイ装置１１０及び一つ又は複数のクライアント装置１２０＿１〜１２０＿ｎ（ここでｎは正の整数）を含む。

【0013】

ＩｏＴゲートウェイ装置１１０はクライアント装置１２０＿１〜１２０＿ｎに無線ネットワーク接続サービスを提供するよう構成されているため、クライアント装置１２０＿１〜１２０＿ｎはＩｏＴゲートウェイ装置１１０を介してインターネットに接続することができる。ＩｏＴのアプリケーションにおいて、クライアント装置１２０＿１〜１２０＿ｎは、一般的な電気機器、例えば空調機、冷蔵庫、自動車、又は携帯電話などに実装することができる。

【0014】

本実施形態では、ＩｏＴゲートウェイ装置１１０は、無線通信回路１１２、メモリ回路１１４、及び処理装置１１６を含む。通信回路１１２はクライアント装置１２０＿１〜１２０＿ｎへの無線接続のために処理装置１１６に結合される。通信回路１１２は、ワイヤレスフィデリティ（ＷｉＦｉ）プロトコルなどの無線通信プロトコルをサポートする無線トランシーバで実装することができる。

【0015】

メモリ回路１１４は処理装置１１６に結合される。メモリ回路１１４は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、フラッシュメモリ、又は任意の他の類似のコンポーネント又はそれらの組み合わせとすることができる。本実施形態では、メモリ回路１１４は複数のモジュールを格納するように構成され、そのモジュールはメモリ回路１４に格納された異なる機能を提供するプログラム又はアプリケーションとすることができる。

【0016】

処理装置１１６は、ゲートウェイ装置１１０の全動作を制御するコンピュータ能力を有するハードウェア（例えば、チップセット、プロセッサなど）である。模範的な実施形態では、処理装置１１６は、例えば中央処理装置（ＣＰＵ）又は任意の他のプログラマブルマイクロプロセッサ又はディジタル信号プロセッサ（ＤＳＰ）、プログラマブルコントローラ、特定用途向け集積回路（ＡＳＩＣ）、プログラマブル論理装置（ＰＬＤ）などである。処理装置１１６はメモリ回路１１４に格納されたモジュールにアクセスし、そのモジュールの機能を実行することができる。

【0017】

具体的には、ＩｏＴゲートウェイ装置１１０のメモリ回路１１４に格納されるモジュールは、ルックアップテーブル確立モジュールＬＥＭ、情報取得モジュールＩＩＯＭ、検証モジュールＶＭ、及び接続モジュールＣＭを含む。これらのモジュールの機能は身元確認方法の部分で後に説明される。

【0018】

クライアント装置１２０＿１〜１２０＿ｎの各々のハードウェア構成はＩｏＴゲートウェイ装置１１０と同様であり、無線通信回路、メモリ回路、及び処理装置を含む。クライアント装置１２０＿１〜１２０＿ｎの各々は、クラウド装置へのデータのアップロード又は制御コマンドの受信のためにＩｏＴゲートウェイ装置１１０を介してインターネットにアクセスすることができる。

【0019】

本実施形態のＩｏＴシステム１００の下では、ＩｏＴゲートウェイ装置１１０は、図２に示す方法を適用することによって、クライアント装置１２０＿１〜１２０＿ｎの身元を確認することができ、この方法のステップはメモリ回路１１４に格納されたモジュールにアクセスすることでＩｏＴゲートウェイ装置により実行される。図２は本発明の一実施形態による身元確認方法のフローチャートである。

【0020】

図１及び図２を参照すると、ステップＳ２１０において、ルックアップテーブルを確立するためにルックアップテーブル確立モジュールＬＥＭが実行され、このルックアップテーブルは少なくとも一つの正当なクライアント装置の正当なメディアアクセス制御（ＭＡＣ）アドレスのリスト及び正当な受信信号強度指示（ＲＳＳＩ）の範囲を含む。

【0021】

ステップＳ２２０において、少なくとも一つのクライアント装置１２０＿１〜１２０＿ｎから送信される接続要求を受信するために検証モジュールＶＭが実行され、この接続要求はクライアント装置のＭＡＣアドレスを含む。

【0022】

ステップＳ２３０において、接続要求に基づいてクライアント装置１２０＿１〜１２０＿ｎのＭＡＣアドレス及びＲＳＳＩ値を取得するために情報取得モジュールＩＩＯＭが実行される。

【0023】

検証すべきクライアント装置１２０＿１〜１２０＿ｎのＲＳＳＩ値が得られた後に、ステップＳ２４０において、クライアント装置１２０＿１〜１２０＿ｎのＭＡＣアドレス及びＲＳＳＩ値を正当なＭＡＣＣアドレスのリスト及び正当なＲＳＳＩの範囲と比較してクライアント装置１２０＿１〜１２０＿ｎが正当なクライアント装置であるかどうかを決定するために検証モジュールＶＭが実行される。

【0024】

より具体的には、ステップＳ２４０の間に、検証モジュールＶＭはクライアント装置１２０＿１〜１２０＿ｎのＭＡＣアドレスが正当なＭＡＣアドレスのリストに記録された正当なＭＡＣアドレスであるかどうかが決定される（ステップＳ２４２）。クライアント装置１２０＿１〜１２０＿ｎのＭＡＣアドレスがルックアップテーブルの正当なＭＡＣアドレスでない場合には、クライアント装置１２０＿１〜１２０＿ｎは不正なクライアント装置であると決定される（ステップＳ２４４）。逆に、クライアント装置１２０＿１〜１２０＿ｎのＭＡＣアドレスがルックアップテーブルの正当なＭＡＣアドレスのリストに記録されている場合には、クライアント装置１２０＿１〜１２０＿ｎのＭＡＣアドレスは正当なＭＡＣアドレスであると決定され、検証モジュールＶＭは更に、クライアント装置１２０＿１〜１２０＿ｎのＲＳＳＩ値が正当なＲＳＳＩの範囲に入るかどうかを決定する（ステップＳ２４６）。

【0025】

ステップＳ２４６において、クライアント装置１２０＿１〜１２０＿ｎのＲＳＳＩ値が正当なＲＳＳＩの範囲に入らない場合には、クライアント装置１２０＿１〜１２０＿ｎは不当なクライアント装置であると決定される（ステップＳ２４４）。逆に、クライアント装置１２０＿１〜１２０＿ｎのＲＳＳＩ値が特定の正当なＭＡＣアドレスに対応する正当なＲＳＳＩの範囲に入る場合には、そのＲＳＳＩ値は正当なＲＳＳＩ値であると決定され、クライアント装置１２０＿１〜１２０＿ｎは正当なクライアント装置であると決定される（ステップＳ２４８）。

【0026】

クライアント装置１２０＿１〜１２０＿ｎが正当なクライアント装置であると決定された場合には、クライアント装置１２０＿１〜１２０＿ｎのアクセス情報を認証し、アクセス情報が認証された後にクライアント装置１２０＿１〜１２０＿ｎの接続要求を許可／承認するために、接続モジュールＣＭを実行することができる。接続要求が許可／承認された後に、クライアント装置１２０＿１〜１２０＿ｎとＩｏＴゲートウェイ装置１１０との間の無線接続ＷＣが確立される。

【0027】

本実施形態では、無線接続ＷＣは、例えばＷＰＡ（Wi-Fi Protected Access）プロトコル又はＷＰＡ２（Wi-Fi Protected Access 2）プロトコルに基づいて確立されるＷｉＦｉ接続とすることができる。すなわち、ステップＳ２４８後にクライアント装置１２０＿１とゲートウェイ装置１１０との間で４ウェイハンドシェークを実行するステップを適用することができる。本発明はこの実施形態に限定されない。

【0028】

逆に、クライアント装置１２０＿１〜１２０＿ｎが不当なクライアント装置であると決定された場合には、接続モジュールＣＭはクライアント装置１２０＿１〜１２０＿ｎの接続要求を拒否することができる。

【0029】

言い換えれば、本実施形態の身元確認方法の実行中、クライアント装置１２０＿１〜１２０＿ｎは、そのＭＡＣアドレス及びＲＳＳＩ値が両方とも正当であるとき、正当なクライアント装置であると決定されるだけである。それゆえ、不正クライアント装置が正当／正規のＭＡＣアドレスを偽造してＩｏＴゲートウェイ装置１１０にアクセスしようと試みても、ＩｏＴゲートウェイ装置１１０はそのＲＳＳＩ値を検証することによって不正クライアント装置を不当なクライアント装置として識別し、ブロックすることができるため、ＩｏＴシステム１００の接続セキュリティを高めることができる。

【0030】

図３及び図４は、図１に示すＩｏＴシステムに基づく本発明の異なる実施形態によるクライアント装置検証プロセスを概略的に示し、上記の身元確認方法を更に進化させる。

【0031】

身元確認方法の説明のためにクライアント装置１２０とＩｏＴゲートウェイ装置１１０との間のインタラクションの一例が以下に示され、クライアント装置１２０は図１に示すクライアント装置１２０＿１〜１２０＿ｎのうちの任意の一つと解釈されたい。ここでは、クライアント装置１２０は正当なクライアント装置であり、そのＭＡＣアドレス及びＲＳＳＩ値はＩｏＴゲートウェイ装置１１０のルックアップテーブルに記録されているものと仮定する。

【0032】

更に、クライアント装置１２０はＩｏＴゲートウェイ装置１１０と特定の相対位置関係を有する特定の位置に位置しているため、ＩｏＴゲートウェイ装置１１０は接続ごとにクライアント装置１２０から受信される信号に基づいて概算ＲＳＳＩ値を得ることができるものと仮定する。

【0033】

図３を参照すると、クライアント装置１２０は手入力される又は自動的に取得されるアクセスパスワードでＩｏＴゲートウェイ装置１１０への接続を開始する（ステップＳ３０１）。ステップＳ３０１において、クライアント装置１２０はＭＡＣアドレスを含む接続要求ＲＥＱ＿ＨＳＫをＩｏＴゲートウェイ装置１１０へ送信する（ステップＳ３０２）。

【0034】

ＩｏＴゲートウェイ装置１１０から見ると、ステップＳ３０２後に、ＩｏＴゲートウェイ装置１１０はＭＡＣアドレスを含む接続要求ＲＥＱ＿ＨＳＫを受信することができ（ステップＳ３０３）、接続要求に基づいてクライアント装置１２０のＭＡＣアドレス及びＲＳＳＩ値を取得することができる（ステップＳ３０４）。例えば、ＩｏＴゲートウェイ装置１１０は接続要求のストリングから特定の部分を取得してＭＡＣアドレスを得ることができる。更に、クライアント装置１２０から受信される信号電力に基づいてＲＳＳＩ値を計算することができる。

【0035】

ＩｏＴゲートウェイ装置１１０がクライアント装置１２０のＭＡＣアドレス及びＲＳＳＩ値を取得した後に、ＩｏＴゲートウェイ装置１１０はクライアント装置１２０のＭＡＣアドレス及びＲＳＳＩ値が正当であるかどうかを決定する（ステップＳ３０５）。

【0036】

本実施形態では、”00:de:a2:de:ba:ff”のＭＡＣアドレスが正当なＭＡＣアドレスのリストに既に記録されているものと仮定する。正当なＲＳＳＩの範囲は“00:de:a2:de:ba:ff”のＭＡＣアドレスに対応して−７５ｄＢ~−７０ｄＢに設定される。従って、ステップＳ３０５において、ＩｏＴ装置１１０は、ステップＳ３０４で得られたＭＡＣアドレスが正当なＭＡＣアドレスのリストに記録された正当なＭＡＣアドレスであるかどうかを決定することができる。例えば、ステップＳ３０４で得られたＭＡＣアドレスが正当なＭＡＣアドレスのリストに記録されていない“00:df:ab:de:0a:ff”である場合には、ＩｏＴゲートウェイ装置１１０は、クライアント装置１２０は不当であると決定し、接続要求ＲＥＱ＿ＨＳＫを拒否することができる。

【0037】

逆に、ステップＳ３０４で得られたＭＡＣアドレスが正当なＭＡＣアドレスである“00:de:a2:de:ba:ff”である場合には、ＩｏＴゲートウェイ装置１１０は更に、ステップＳ３０４で得られたＲＳＳＩ値が正当なＲＳＳＩの範囲内に入る正当なＲＳＳＩ値であるかどうかを決定することができる。例えば、ステップＳ３０４で得られたＲＳＳＩ値が−７５ｄＢ~−７０ｄＢの範囲外の−４０ｄＢである場合には、ＩｏＴゲートウェイ装置１１０は、ＭＡＣアドレスが正当であっても（ＭＡＣアドレスはこの状態では偽造されているかもしれない）、クライアント装置１２０は不当であると決定し、接続要求ＲＥＱ＿ＨＳＫを拒否することができる。更に、ステップＳ３０４で得られたＲＳＳＩ値が−７５ｄＢ~−７０ｄＢの範囲内の−７２ｄＢである場合には、ＩｏＴゲートウェイ装置１１０は、クライアント装置１２０は正当であると決定することができる。

【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】

１００ ＩｏＴシステム
１１０ ＩｏＴゲートウェイ装置
１１２，１３２ 無線通信回路
１１４，１３４ メモリ回路
１１６，１３６ 処理装置
１２０，１２０＿１〜１２０＿ｎ クライアント装置
１３０ 検証ゲートウェイ装置
Ｓ２１０−Ｓ２４８，Ｓ３０１−Ｓ３０７，Ｓ４０１−Ｓ４２３，Ｓ５０１−Ｓ５１２，Ｓ６０１−Ｓ６１８ ステップ
ＡＭ 認証モジュール
ＣＭ 接続モジュール
ＩＩＯＭ，ＶＩＯＭ 情報取得モジュール
ＬＥＭ ルックアップテーブル確立モジュール
ＮＭ 通知モジュール
ＶＭ 検証モジュール
ＲＥＱ＿ＨＳＫ 接続要求
ＲＥＳ＿ＨＳＫ 接続応答

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】