特許7387570デバイス識別装置、デバイス識別方法及びコンピュータプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-11-17
(45)【発行日】2023-11-28
(54)【発明の名称】デバイス識別装置、デバイス識別方法及びコンピュータプログラム
(51)【国際特許分類】
H04L 43/04 20220101AFI20231120BHJP
G06F 13/00 20060101ALI20231120BHJP
【ＦＩ】
H04L43/04
G06F13/00
【請求項の数】
5
(21)【出願番号】P 2020164760
(22)【出願日】2020-09-30
(65)【公開番号】P2022056811
(43)【公開日】2022-04-11
【審査請求日】2022-07-25
(73)【特許権者】
【識別番号】000208891
【氏名又は名称】ＫＤＤＩ株式会社
(74)【代理人】
【識別番号】100165179
【弁理士】
【氏名又は名称】田▲崎▼ 聡
(74)【代理人】
【識別番号】100175824
【弁理士】
【氏名又は名称】小林 淳一
(74)【代理人】
【識別番号】100114937
【弁理士】
【氏名又は名称】松本 裕幸
(72)【発明者】
【氏名】奥井 宣広
(72)【発明者】
【氏名】中原 正隆
(72)【発明者】
【氏名】三宅 優
【審査官】速水 雄太
(56)【参考文献】
【文献】米国特許出願公開第２０２０／０１２７８９２（ＵＳ，Ａ１）
【文献】特開２０２０－１４０３４６（ＪＰ，Ａ）
【文献】特開２０２０－１３６７７９（ＪＰ，Ａ）
【文献】特開２０１５－０９７３３０（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｌ ４３／０４
Ｇ０６Ｆ １３／００
(57)【特許請求の範囲】
【請求項1】
デバイスの通信データから生成されたＩＰＦＩＸ（IP Flow Information Export）データを収集するＩＰＦＩＸデータ収集部と、前記ＩＰＦＩＸデータからパケット通信の特徴量を生成する特徴量生成部と、
前記特徴量に基づいた機械学習により生成されたデバイス種識別モデルを使用して、識別対象デバイスの前記特徴量からデバイス種を識別するデバイス識別部と、
を備え、
前記特徴量生成部は、デバイスが自動的に行う第１の通信と、デバイスがユーザの操作に応じて行う第２の通信とに分けて前記特徴量を生成し、
前記デバイス種識別モデルは、第１の通信と第２の通信とに分けて生成され、
前記デバイス識別部は、第１の通信のデバイス種識別モデルと、第２の通信のデバイス種識別モデルとを使用する、
デバイス識別装置。
【請求項2】
前記デバイスはＩｏＴデバイスである、請求項１に記載のデバイス識別装置。
【請求項3】
前記デバイス種識別モデルは、デバイス種の識別結果と、当該識別結果の確信度とを出力し、前記デバイス識別部は、さらに過去の識別結果の確信度に基づいてデバイス種の識別を行う、
請求項１に記載のデバイス識別装置。
【請求項4】
デバイスの通信データから生成されたＩＰＦＩＸ（IP Flow Information Export）データを収集するＩＰＦＩＸデータ収集ステップと、前記ＩＰＦＩＸデータからパケット通信の特徴量を生成する特徴量生成ステップと、
前記特徴量に基づいた機械学習により生成されたデバイス種識別モデルを使用して、識別対象デバイスの前記特徴量からデバイス種を識別するデバイス識別ステップと、
を含み、
前記特徴量生成ステップは、デバイスが自動的に行う第１の通信と、デバイスがユーザの操作に応じて行う第２の通信とに分けて前記特徴量を生成し、
前記デバイス種識別モデルは、第１の通信と第２の通信とに分けて生成され、
前記デバイス識別ステップは、第１の通信のデバイス種識別モデルと、第２の通信のデバイス種識別モデルとを使用する、
デバイス識別方法。
【請求項5】
コンピュータに、デバイスの通信データから生成されたＩＰＦＩＸ（IP Flow Information Export）データを収集するＩＰＦＩＸデータ収集ステップと、
前記ＩＰＦＩＸデータからパケット通信の特徴量を生成する特徴量生成ステップと、
前記特徴量に基づいた機械学習により生成されたデバイス種識別モデルを使用して、識別対象デバイスの前記特徴量からデバイス種を識別するデバイス識別ステップと、
を実行させるためのコンピュータプログラムであって、
前記特徴量生成ステップは、デバイスが自動的に行う第１の通信と、デバイスがユーザの操作に応じて行う第２の通信とに分けて前記特徴量を生成し、
前記デバイス種識別モデルは、第１の通信と第２の通信とに分けて生成され、
前記デバイス識別ステップは、第１の通信のデバイス種識別モデルと、第２の通信のデバイス種識別モデルとを使用する、
コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、デバイス識別装置、デバイス識別方法及びコンピュータプログラムに関する。
【背景技術】
【0002】
従来、通信ネットワークに接続された家電機器の種類を識別する技術として例えば特許文献１が知られている。特許文献１には、電化製品の種類を判別するため、電化製品であれば受信するとされる少なくとも二種類のパケットにより定められる定義ファイルを、当該パケットを構成する一のパケット毎に対応付けられた得点とともに、電化製品の種別を判別するための電化製品情報毎に記憶し、電化製品から受信したパケットと当該一のパケットを比較して定義ファイル毎に得点化を行い、得点が高い定義ファイルに対応する電化製品情報を当該パケットを受信した電化製品の電化製品情報とする、情報処理装置が記載されている。この特許文献１では、定義ファイルとして電化製品のＭＡＣアドレス（Media Access Control address）の情報（先頭２４ビットのベンダー識別子（ベンダーＩＤ）及び中盤８ビットの機種識別子（機種ＩＤ））を使用している。
【先行技術文献】
【特許文献】
【0003】
【文献】特許第４８５５４９９号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかし、上述した特許文献１の技術では、定義ファイルとして電化製品のＭＡＣアドレスの情報を使用するが、ＭＡＣアドレスは電化製品が備えるネットワークインターフェースに付与されるので、ＭＡＣアドレスのベンダーＩＤが必ずしも電化製品のデバイスベンダーを示すとは限らない。このため、異なるデバイスベンダーの電化製品でもＭＡＣアドレスの先頭部分が同一となる場合があるので、電化製品の種類の識別精度が低下する可能性がある。
【0005】
本発明は、このような事情を考慮してなされたものであり、その目的は、通信ネットワークに接続されたＩｏＴ（Internet of Things）デバイス等のデバイスの種類を効率的に且つ精度よく識別することを図ることにある。
【課題を解決するための手段】
【0006】
（１）本発明の一態様は、デバイスの通信データから生成されたＩＰＦＩＸ（IP Flow Information Export）データを収集するＩＰＦＩＸデータ収集部と、前記ＩＰＦＩＸデータからパケット通信の特徴量を生成する特徴量生成部と、前記特徴量に基づいた機械学習により生成されたデバイス種識別モデルを使用して、識別対象デバイスの前記特徴量からデバイス種を識別するデバイス識別部と、を備え、前記特徴量生成部は、デバイスが自動的に行う第１の通信と、デバイスがユーザの操作に応じて行う第２の通信とに分けて前記特徴量を生成し、前記デバイス種識別モデルは、第１の通信と第２の通信とに分けて生成され、前記デバイス識別部は、第１の通信のデバイス種識別モデルと、第２の通信のデバイス種識別モデルとを使用する、デバイス識別装置である。
（２）本発明の一態様は、前記デバイスはＩｏＴデバイスである、上記（１）のデバイス識別装置である。
（３）本発明の一態様は、前記デバイス種識別モデルは、デバイス種の識別結果と、当該識別結果の確信度とを出力し、前記デバイス識別部は、さらに過去の識別結果の確信度に基づいてデバイス種の識別を行う、上記（１）のデバイス識別装置である。
（２）本発明の一態様は、前記デバイスはＩｏＴデバイスである、上記（１）のデバイス識別装置である。
（３）本発明の一態様は、前記デバイス種識別モデルは、デバイス種の識別結果と、当該識別結果の確信度とを出力し、前記デバイス識別部は、さらに過去の識別結果の確信度に基づいてデバイス種の識別を行う、上記（１）のデバイス識別装置である。
【0007】
（４）本発明の一態様は、デバイスの通信データから生成されたＩＰＦＩＸ（IP Flow Information Export）データを収集するＩＰＦＩＸデータ収集ステップと、前記ＩＰＦＩＸデータからパケット通信の特徴量を生成する特徴量生成ステップと、前記特徴量に基づいた機械学習により生成されたデバイス種識別モデルを使用して、識別対象デバイスの前記特徴量からデバイス種を識別するデバイス識別ステップと、を含み、前記特徴量生成ステップは、デバイスが自動的に行う第１の通信と、デバイスがユーザの操作に応じて行う第２の通信とに分けて前記特徴量を生成し、前記デバイス種識別モデルは、第１の通信と第２の通信とに分けて生成され、前記デバイス識別ステップは、第１の通信のデバイス種識別モデルと、第２の通信のデバイス種識別モデルとを使用する、デバイス識別方法である。
【0008】
（５）本発明の一態様は、コンピュータに、デバイスの通信データから生成されたＩＰＦＩＸ（IP Flow Information Export）データを収集するＩＰＦＩＸデータ収集ステップと、前記ＩＰＦＩＸデータからパケット通信の特徴量を生成する特徴量生成ステップと、前記特徴量に基づいた機械学習により生成されたデバイス種識別モデルを使用して、識別対象デバイスの前記特徴量からデバイス種を識別するデバイス識別ステップと、を実行させるためのコンピュータプログラムであって、前記特徴量生成ステップは、デバイスが自動的に行う第１の通信と、デバイスがユーザの操作に応じて行う第２の通信とに分けて前記特徴量を生成し、前記デバイス種識別モデルは、第１の通信と第２の通信とに分けて生成され、前記デバイス識別ステップは、第１の通信のデバイス種識別モデルと、第２の通信のデバイス種識別モデルとを使用する、コンピュータプログラムである。
【発明の効果】
【0009】
本発明によれば、通信ネットワークに接続されたＩｏＴデバイス等のデバイスの種類を効率的に且つ精度よく識別することができるという効果が得られる。
【図面の簡単な説明】
【0010】
【図1】一実施形態に係る通信システム及びデバイス識別装置の構成例を示すブロック図である。
【図2】ＩＰＦＩＸデータの生成方法の説明図である。
【図3】ＩＰＦＩＸデータの生成方法の説明図である。
【図4】ＩＰＦＩＸデータの生成方法の説明図である。
【図5】ＩＰＦＩＸデータの生成方法の説明図である。
【図6】ＩＰＦＩＸデータの生成方法の説明図である。
【図7】定常通信によるサービスの例を示す図表である。
【図8】一実施形態に係る定常通信の特徴量を示す図表である。
【図9】一実施形態に係る特徴量とＩＰＦＩＸデータのフィールドの対応関係を示す図表である。
【図10】操作時通信によるサービスの例を示す図表である。
【図11】操作時通信に係るプロトコルの例を示す図表である。
【図12】一実施形態に係るデバイス識別方法の手順の例を示すフローチャートである。
【図13】一実施形態に係るデバイス識別装置の実施例１を示す説明図である。
【図14】一実施形態に係る特徴量データの例を示す図表である。
【図15】一実施形態に係るデバイス識別部の一実施例を示す説明図である。
【図16】一実施形態に係るデバイス識別装置の実施例２を示す説明図である。
【発明を実施するための形態】
【0011】
以下、図面を参照し、本発明の実施形態について説明する。
図１は、一実施形態に係る通信システム及びデバイス識別装置の構成例を示すブロック図である。図１に示す通信システム１において、デバイス識別装置１０は、インターネット等の通信ネットワークＮＷを介して、各ホーム（宅）３０－１，３０－２，３０－３，・・・のゲートウェイ（ＧＷ）３１と通信を行う。各ホーム３０－１，３０－２，３０－３，・・・には、ゲートウェイ３１とデバイスｄｅｖとが設けられている。以下、ホーム３０－１，３０－２，３０－３，・・・を特に区別しないときはホーム３０と称する。本実施形態に係るホーム３０は、デバイスｄｅｖが通信を行う拠点（デバイス通信拠点）の一例である。
図１は、一実施形態に係る通信システム及びデバイス識別装置の構成例を示すブロック図である。図１に示す通信システム１において、デバイス識別装置１０は、インターネット等の通信ネットワークＮＷを介して、各ホーム（宅）３０－１，３０－２，３０－３，・・・のゲートウェイ（ＧＷ）３１と通信を行う。各ホーム３０－１，３０－２，３０－３，・・・には、ゲートウェイ３１とデバイスｄｅｖとが設けられている。以下、ホーム３０－１，３０－２，３０－３，・・・を特に区別しないときはホーム３０と称する。本実施形態に係るホーム３０は、デバイスｄｅｖが通信を行う拠点（デバイス通信拠点）の一例である。
【0012】
デバイスｄｅｖは、ゲートウェイ３１を介して、例えばインターネットに接続されているサーバ等と通信を行う。デバイスｄｅｖは、例えばＩｏＴデバイスである。デバイスｄｅｖには複数の種類（デバイス種）が存在する。図１には、デバイス種として３つのデバイス種「Ａ種」，「Ｂ種」，「Ｃ種」が例示されている。例えば、デバイスｄｅｖ（Ａ種）は電力計等の計測センサーである。例えば、デバイスｄｅｖ（Ｂ種）はＷｅｂカメラである。例えば、デバイスｄｅｖ（Ｃ種）はエアコンやスマートスピーカー等の家電機器である。
【0013】
ゲートウェイ３１は、デバイスｄｅｖの通信の許可又は不許可を判断し、当該判断結果に応じてデバイスｄｅｖの通信を制御する。ゲートウェイ３１は、ＩＰＦＩＸ（IP Flow Information Export）変換部３２を備える。
【0014】
ＩＰＦＩＸ変換部３２は、自己のゲートウェイ３１の配下のデバイスｄｅｖが行う通信についてのＩＰＦＩＸデータを生成する。ＩＰＦＩＸ変換部３２は、自己のゲートウェイ３１を通過するデバイスｄｅｖの通信データからＩＰＦＩＸデータを生成する。ＩＰＦＩＸデータは、ＩＥＴＦ（Internet Engineering Task Force）のＲＦＣ（Request for Comments）７０１１で標準化されている。ＩＰＦＩＸデータは、パケット通信の流れを示すデータである。
【0015】
［ＩＰＦＩＸデータ］
本実施形態では、デバイスｄｅｖのデバイス種の識別にＩＰＦＩＸデータを利用する。以下にＩＰＦＩＸデータについて説明する。
本実施形態では、デバイスｄｅｖのデバイス種の識別にＩＰＦＩＸデータを利用する。以下にＩＰＦＩＸデータについて説明する。
【0016】
（ＩＰＦＩＸデータのフィールド）
ＩＰＦＩＸデータとして定義されているレコードの種類は約５００ある。以下にＩＰＦＩＸデータに使用されるフィールドの例を説明する。
ＩＰＦＩＸデータとして定義されているレコードの種類は約５００ある。以下にＩＰＦＩＸデータに使用されるフィールドの例を説明する。
【0017】
「sourceMacAddress / destinationMacAddress」フィールドは、送信元及び送信先のＭＡＣアドレスを示すフィールドである。
「sourceIPv4Address / sourceIPv6Address / destinationIPv4Address / destinationIPv6Address」フィールドは、送信元及び送信先のＩＰアドレスを示すフィールドである。
「octetTotalCount / packetTotalCount」フィールドは、通信方向のデータサイズ及びパケット数を示すフィールドである。
「reverseOctetTotalCount / reversePacketTotalCount」フィールドは、通信方向の逆方向のデータサイズ及びパケット数を示すフィールドである。
「protocolIdentifier」フィールドは、ＩＰ（Internet Protocol）に関係するプロトコルを示すフィールドである。「protocolIdentifier」フィールドの値として、「１：ICMP（IPv4）」、「６：TCP」、「１７：UDP」、「５８：ICMP（IPv6）」等があり、一般にこれらがＩｏＴデバイスでよく使用される。
「sourceTransportPort / destinationTransportPort」フィールドは、送信元及び送信先のポート番号に関する情報を示すフィールドである。
「flowStartMilliseconds / flowEndMilliseconds / flowDurationMilliseconds」フィールドは、ＩＰＦＩＸデータとして要約される通信データの開始時刻及び終了時刻を示すフィールドである。「DurationMilliseconds」は、「終了時刻－開始時刻」の値である。
「sourceIPv4Address / sourceIPv6Address / destinationIPv4Address / destinationIPv6Address」フィールドは、送信元及び送信先のＩＰアドレスを示すフィールドである。
「octetTotalCount / packetTotalCount」フィールドは、通信方向のデータサイズ及びパケット数を示すフィールドである。
「reverseOctetTotalCount / reversePacketTotalCount」フィールドは、通信方向の逆方向のデータサイズ及びパケット数を示すフィールドである。
「protocolIdentifier」フィールドは、ＩＰ（Internet Protocol）に関係するプロトコルを示すフィールドである。「protocolIdentifier」フィールドの値として、「１：ICMP（IPv4）」、「６：TCP」、「１７：UDP」、「５８：ICMP（IPv6）」等があり、一般にこれらがＩｏＴデバイスでよく使用される。
「sourceTransportPort / destinationTransportPort」フィールドは、送信元及び送信先のポート番号に関する情報を示すフィールドである。
「flowStartMilliseconds / flowEndMilliseconds / flowDurationMilliseconds」フィールドは、ＩＰＦＩＸデータとして要約される通信データの開始時刻及び終了時刻を示すフィールドである。「DurationMilliseconds」は、「終了時刻－開始時刻」の値である。
【0018】
（ＩＰＦＩＸデータのパラメータ）
ＩＰＦＩＸデータ、セッションごと及び一定時間ごとに通信データを要約したデータである。ＩＰＦＩＸデータによれば、パケットを記録する場合と比較して、記録するデータ量を大幅に削減することができる。図２－図６を参照してＩＰＦＩＸデータの生成方法の例を説明する。
ＩＰＦＩＸデータ、セッションごと及び一定時間ごとに通信データを要約したデータである。ＩＰＦＩＸデータによれば、パケットを記録する場合と比較して、記録するデータ量を大幅に削減することができる。図２－図６を参照してＩＰＦＩＸデータの生成方法の例を説明する。
【0019】
図２に示すＩＰＦＩＸデータの生成方法の例では、ノードＸとノードＹ間でやり取りされる４個の通信データが要約されて１個のＩＰＦＩＸデータ（ＩＰＦＩＸレコード）に変換される。通信データの要約の対象の期間に使用されるフィールドとして、図３及び図４に示される２つの例が挙げられる。
【0020】
図３の例では、「active timeout」フィールドにより通信データの要約の対象の期間が決まる。「active timeout」フィールドは、強制的にフローの終了とみなす時間を示すフィールドである。図３に例示されるように、通信データのやり取りが「active timeout」フィールドに示される時間を超えた場合に、強制的にフローの終了とみなされ、それまでにノードＸとノードＹ間でやり取りされた通信データが要約されて１個のＩＰＦＩＸデータに変換される。したがって、ノードＸとノードＹ間でやり取りされる通信データのうち、強制的にフローの終了とみなされた以降の通信データはＩＰＦＩＸデータに変換されない。
【0021】
図４の例では、「idle timeout」フィールドにより通信データの要約の対象の期間が決まる。「idle timeout」フィールドは、通信データが途切れたときに、タイムアウトとみなす時間を示すフィールドである。図４に例示されるように、通信データのやり取りが途絶えてから「idle timeout」フィールドに示される時間を超えた場合に、強制的にフローの終了とみなされ、それまでにノードＸとノードＹ間でやり取りされた通信データが要約されて１個のＩＰＦＩＸデータに変換される。
【0022】
なお、ＵＤＰ（User Datagram Protocol）のようにセッションを持たないプロトコルの場合には、図５に例示されるように、特定の条件において「idle timeout」フィールド又は「active timeout」フィールドにより通信データの要約の対象の期間が決まる。
【0023】
以上がＩＰＦＩＸデータについての説明である。
【0024】
本発明者は、上述したような特徴を持つＩＰＦＩＸデータを、通信ネットワークに接続されたＩｏＴデバイス等のデバイスのデバイス種の識別に利用することを着想した。この理由は、ＩＰＦＩＸデータによれば、パケット通信の流れを示すデータのデータ量を削減することができること、パケット通信の特徴量としてデバイス種の識別に役立つ特徴量を得やすいことなどである。
【0025】
図６は、本実施形態に係るＩＰＦＩＸデータによるパケット通信の特徴量を説明するための説明図である。以下、パケット通信の特徴量のことを単に特徴量と称する場合がある。
【0026】
図６において、「通信１」は、セッションを持つ通信であってデバイスが定常的に行う通信を示す。また、「通信２」は、セッションを持つ通信であってデバイスがユーザの操作に応じて行う通信を示す。また、「通信３」は、セッションを持たない通信であってデバイスがユーザの操作に応じて行う通信を示す。
【0027】
図６に示されるように、ＩＰＦＩＸレコードはセッションやその他の規則により通信パケットの情報が要約されて生成されるので、通信パケットと比較してデータ数が削減される。
【0028】
また、図６に示されるように、通信パケットのまま使用して単位時間ｔ１，ｔ２，・・・，ｔ１０ごとにパケット通信の特徴量を生成する場合、「通信２」及び「通信３」では、セッションや一連のパケットを途中でぶつ切りにして特徴量を生成することになる。「通信２」においては、単位時間ｔ１－ｔ３，ｔ７－ｔ１０にわたって通信パケットが生成されるが、各単位時間に含まれる通信パケットの数が異なるために、通信パケットのまま使用して特徴量を生成すると、特徴量として揺らぎが生じる。また「通信３」においては、単位時間ｔ１－ｔ７にわたって通信パケットが生成されるが、これらの通信パケットがたとえ同じ通信内容であっても単位時間ｔ７だけ通信パケット数が異なるために特徴量が異なる可能性がある。
【0029】
一方、ＩＰＦＩＸデータを使用してパケット通信の特徴量を生成する場合、「通信２」においては、単位時間ｔ３に１個のセッション「単位時間ｔ１－ｔ３」の通信パケットから１個のＩＰＦＩＸレコードが生成され、また単位時間ｔ１０に１個のセッション「単位時間ｔ７－ｔ１０」の通信パケットから１個のＩＰＦＩＸレコードが生成される。これら「通信２」の各単位時間ｔ３，ｔ１０のＩＰＦＩＸレコードはセッション単位で生成されるので、当該各ＩＰＦＩＸレコードからは「通信２」のセッションにおける類似する特徴量を得られる可能性が高い。また、「通信３」においては、単位時間ｔ７に単位時間ｔ１－ｔ７の通信パケットから１個のＩＰＦＩＸレコードが生成される。この「通信３」の単位時間ｔ７のＩＰＦＩＸレコードは、単位時間ｔ１－ｔ７の通信パケットの情報から生成されるので、当該ＩＰＦＩＸレコードからは他の通信とは異なる「通信３」の特徴量を得られる可能性が高い。
【0030】
上述したようにＩＰＦＩＸデータによれば、パケット通信の流れを示すデータのデータ量が削減されると共に、各パケット通信の特徴量を的確に得ることができる。パケット通信の流れを示すデータのデータ量が削減されることにより、パケット通信の特徴量を効率的に取得することができる。また、各パケット通信の的確な特徴量は、各パケット通信を行うデバイスのデバイス種の識別に役立つ特徴量であると言える。このことから本実施形態では、ＩＰＦＩＸデータを使用してパケット通信の特徴量を生成することにより、通信ネットワークに接続されたＩｏＴデバイス等のデバイスのデバイス種の識別を効率的に且つ精度よく行うことを図る。
【0031】
［デバイス識別装置］
本実施形態に係るデバイス識別装置１０を説明する。図１において、デバイス識別装置１０は、ＩＰＦＩＸデータ収集部１１と、特徴量生成部１２と、モデル学習部１３と、デバイス識別部１４とを備える。
本実施形態に係るデバイス識別装置１０を説明する。図１において、デバイス識別装置１０は、ＩＰＦＩＸデータ収集部１１と、特徴量生成部１２と、モデル学習部１３と、デバイス識別部１４とを備える。
【0032】
デバイス識別装置１０の各機能は、デバイス識別装置１０がＣＰＵ（Central Processing Unit：中央演算処理装置）及びメモリ等のコンピュータハードウェアを備え、ＣＰＵがメモリに格納されたコンピュータプログラムを実行することにより実現される。なお、デバイス識別装置１０として、汎用のコンピュータ装置を使用して構成してもよく、又は、専用のハードウェア装置として構成してもよい。例えば、デバイス識別装置１０は、インターネット等の通信ネットワークに接続されるサーバコンピュータを使用して構成されてもよい。また、デバイス識別装置１０の各機能はクラウドコンピューティングにより実現されてもよい。また、デバイス識別装置１０は、単独のコンピュータにより実現するものであってもよく、又はデバイス識別装置１０の機能を複数のコンピュータに分散させて実現するものであってもよい。
【0033】
各ホーム３０のゲートウェイ３１は、ＩＰＦＩＸ変換部３２が生成した自己の配下の各デバイスｄｅｖのＩＰＦＩＸデータをデバイス識別装置１０へ送信する。ＩＰＦＩＸデータ収集部１１は、各ホーム３０のゲートウェイ３１から各デバイスｄｅｖのＩＰＦＩＸデータを受信する。
【0034】
ＩＰＦＩＸデータ収集部１１は、各ホーム３０から受信したＩＰＦＩＸデータを、ＭＡＣアドレスごとに集約する。ＭＡＣアドレスは、ＩＰＦＩＸデータの「sourceMacAddress / destinationMacAddress」フィールドに示される。ＩＰＦＩＸデータ収集部１１は、ＭＡＣアドレスごとに集約したＩＰＦＩＸデータを一定期間保管する。
【0035】
特徴量生成部１２は、ＩＰＦＩＸデータ収集部１１から、ＭＡＣアドレスごとに集約されたＩＰＦＩＸデータを受け取る。特徴量生成部１２は、ＭＡＣアドレスごとに集約されたＩＰＦＩＸデータを使用して、パケット通信の特徴量を示す特徴量データを生成する。
【0036】
［特徴量］
本実施形態に係るパケット通信の特徴量を説明する。デバイスｄｅｖが行う通信には、大きく分類すると、デバイスが定常的に行う通信（定常通信）と、デバイスがユーザの操作に応じて行う通信（操作時通信）との２種類がある。
本実施形態に係るパケット通信の特徴量を説明する。デバイスｄｅｖが行う通信には、大きく分類すると、デバイスが定常的に行う通信（定常通信）と、デバイスがユーザの操作に応じて行う通信（操作時通信）との２種類がある。
【0037】
定常通信は、デバイスｄｅｖが例えばファームウェア等に設定されている情報に基づいて自動的に通信を行うものである。このため、定常通信では、デバイスｄｅｖに対するユーザの操作の有無とは無関係に一定の通信が行われる。
【0038】
操作時通信は、ユーザがデバイスｄｅｖに対して操作を行ったことにより発生する通信である。このため、操作時通信では、ユーザの操作により行われる通信の内容がデバイス種ごとに大きく異なる状況が発生し得る。
【0039】
そこで本実施形態では、上述した定常通信と操作時通信の各特徴に着目し、定常通信と操作時通信のそれぞれの通信の挙動のデバイス種ごとの違いが反映されるように、定常通信と操作時通信とに分けて特徴量データを生成する。
【0040】
（定常通信の特徴量）
デバイスｄｅｖが定常通信により行うサービスが図７に示される。各サービス「ＩＣＭＰ」、「ＩＧＭＰ」、「ＦＴＰ」、「Ｔｅｌｎｅｔ」、「ＤＮＳ，ｍＤＮＳ」、「ＳＳＤＰ」には、各特徴量番号（特徴量Ｎｏ．）が付与されている。サービスの判別は、ＩＰＦＩＸデータの「sourceTransportPort / destinationTransportPort」フィールド内の「destinationTransportPort」の値によって行われる。図７に示されるサービスでは、デバイス種ごとに通信の挙動が異なる。このため、特徴量生成部１２は、定常通信の特徴量として、図７に示される各サービス「ＩＣＭＰ」、「ＩＧＭＰ」、「ＦＴＰ」、「Ｔｅｌｎｅｔ」、「ＤＮＳ，ｍＤＮＳ」、「ＳＳＤＰ」について、単位時間における図８に示される情報「ＩＰＦＩＸレコード数」、「送信パケットサイズ」、「受信パケットサイズ」、「送信パケット数」、「受信パケット数」、「セッション継続時間」を特徴量データにする。特徴量生成部１２は、図８に示されるように各情報のバリエーションとして、「合計値」、「最小値」、「最大値」、「平均値」、「中央値」等を特徴量データに含める。
デバイスｄｅｖが定常通信により行うサービスが図７に示される。各サービス「ＩＣＭＰ」、「ＩＧＭＰ」、「ＦＴＰ」、「Ｔｅｌｎｅｔ」、「ＤＮＳ，ｍＤＮＳ」、「ＳＳＤＰ」には、各特徴量番号（特徴量Ｎｏ．）が付与されている。サービスの判別は、ＩＰＦＩＸデータの「sourceTransportPort / destinationTransportPort」フィールド内の「destinationTransportPort」の値によって行われる。図７に示されるサービスでは、デバイス種ごとに通信の挙動が異なる。このため、特徴量生成部１２は、定常通信の特徴量として、図７に示される各サービス「ＩＣＭＰ」、「ＩＧＭＰ」、「ＦＴＰ」、「Ｔｅｌｎｅｔ」、「ＤＮＳ，ｍＤＮＳ」、「ＳＳＤＰ」について、単位時間における図８に示される情報「ＩＰＦＩＸレコード数」、「送信パケットサイズ」、「受信パケットサイズ」、「送信パケット数」、「受信パケット数」、「セッション継続時間」を特徴量データにする。特徴量生成部１２は、図８に示されるように各情報のバリエーションとして、「合計値」、「最小値」、「最大値」、「平均値」、「中央値」等を特徴量データに含める。
【0041】
特徴量生成部１２は、図８に示される情報のうち「送信パケットサイズ」、「受信パケットサイズ」、「送信パケット数」、「受信パケット数」、「セッション継続時間」を、ＩＰＦＩＸデータにおいて図９に示される各フィールドの値から生成する。特徴量生成部１２は、「ＩＰＦＩＸレコード数」については、ＩＰＦＩＸデータから単位時間のＩＰＦＩＸレコード数を計数する。
【0042】
（操作時通信の特徴量）
デバイスｄｅｖが操作時通信により行うサービスが図１０に示される。各サービス「ＨＴＴＰ」、「ＨＴＴＰＳ」、「ＳＭＢ」には、各特徴量番号（特徴量Ｎｏ．）が付与されている。これらのサービスでは、ユーザがデバイスｄｅｖを操作したことによりデバイスｄｅｖが生成する通信データは、デバイスｄｅｖ上で動作するアプリケーションにより大きく異なる。このため、特徴量生成部１２は、操作時通信の特徴量として、図１０に示される各サービス「ＨＴＴＰ」、「ＨＴＴＰＳ」、「ＳＭＢ」について、単位時間における図８に示される情報「ＩＰＦＩＸレコード数」、「送信パケットサイズ」、「受信パケットサイズ」、「送信パケット数」、「受信パケット数」、「セッション継続時間」を特徴量データにする。特徴量生成部１２は、図８に示されるように各情報のバリエーションとして、「合計値」、「最小値」、「最大値」、「平均値」、「中央値」等を特徴量データに含める。
デバイスｄｅｖが操作時通信により行うサービスが図１０に示される。各サービス「ＨＴＴＰ」、「ＨＴＴＰＳ」、「ＳＭＢ」には、各特徴量番号（特徴量Ｎｏ．）が付与されている。これらのサービスでは、ユーザがデバイスｄｅｖを操作したことによりデバイスｄｅｖが生成する通信データは、デバイスｄｅｖ上で動作するアプリケーションにより大きく異なる。このため、特徴量生成部１２は、操作時通信の特徴量として、図１０に示される各サービス「ＨＴＴＰ」、「ＨＴＴＰＳ」、「ＳＭＢ」について、単位時間における図８に示される情報「ＩＰＦＩＸレコード数」、「送信パケットサイズ」、「受信パケットサイズ」、「送信パケット数」、「受信パケット数」、「セッション継続時間」を特徴量データにする。特徴量生成部１２は、図８に示されるように各情報のバリエーションとして、「合計値」、「最小値」、「最大値」、「平均値」、「中央値」等を特徴量データに含める。
【0043】
なお、操作時通信では、「Well-knownポート」以外のポートへの通信も多く、送信先のポート番号は各デバイス種で特定の範囲が使用されていることが多い。このため、「Well-knownポート」以外についてもポート番号を特定の範囲で区切って特徴量にすることが好ましい。
【0044】
また、操作時通信では、デバイス種によって使用されるプロトコルにも違いがある。例えば、ロボット掃除機等の家電機器に指示を送る場合にはＴＣＰ（Transmission Control Protocol）が使用されるが、Ｗｅｂカメラで撮像された映像を閲覧する場合にはＵＤＰが使用される。このため、特徴量生成部１２は、操作時通信の特徴量として、さらに図１１に示される各プロトコル「ＩＣＭＰ」、「ＩＧＭＰ」、「ＴＣＰ」、「ＵＤＰ」について、単位時間における図８に示される情報「ＩＰＦＩＸレコード数」、「送信パケットサイズ」、「受信パケットサイズ」、「送信パケット数」、「受信パケット数」、「セッション継続時間」を特徴量データにする。特徴量生成部１２は、図８に示されるように各情報のバリエーションとして、「合計値」、「最小値」、「最大値」、「平均値」、「中央値」等を特徴量データに含める。図１１に示されるように、各プロトコル「ＩＣＭＰ」、「ＩＧＭＰ」、「ＴＣＰ」、「ＵＤＰ」には、各特徴量番号（特徴量Ｎｏ．）が付与されている。プロトコルの判別は、ＩＰＦＩＸデータの「protocolIdentifier」フィールドの値によって行われる。
【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】
また、上述した各装置の機能を実現するためのコンピュータプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行するようにしてもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＤＶＤ（Digital Versatile Disc）等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＤＶＤ（Digital Versatile Disc）等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
【0074】
さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Dynamic Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。
【符号の説明】
【0075】
１…通信システム、１０…デバイス識別装置、１１…ＩＰＦＩＸデータ収集部、１２…特徴量生成部、１３…モデル学習部、１４…デバイス識別部、３０…ホーム、３１…ゲートウェイ、３２…ＩＰＦＩＸ変換部、ｄｅｖ…デバイス、ＮＷ…通信ネットワーク
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】