(57)【要約】【課題】通信端末装置上のアプリケーションの通信を適切に制御することを可能にする。【解決手段】端末装置１０は、アプリケーションの通信を収集し、第１の制御条件に基づいてアプリケーションの通信を制御する収集制御部１０２と、収集制御部が収集した通信を解析してアプリケーションが通信制御対象であるか否かを判定し、通信制御対象のアプリケーションの正常通信範囲に基づいて第１の制御条件を生成する解析部１０３と、アプリケーションの識別情報と、第１の制御条件とを含む第１の共有情報の少なくとも一部を、他の通信端末装置に送信する連携部１０４と、を有する。【選択図】図１
2020135655.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションの通信を収集し、第１の制御条件に基づいて前記アプリケーションの通信を制御する収集制御部と、
前記収集制御部が収集した通信を解析して前記アプリケーションが通信制御対象であるか否かを判定し、通信制御対象のアプリケーションの正常通信範囲に基づいて前記第１の制御条件を生成する解析部と、
前記アプリケーションの識別情報と、前記第１の制御条件とを含む第１の共有情報の少なくとも一部を、他の通信端末装置に送信する連携部と、
を有することを特徴とする通信端末装置。
【請求項２】
前記連携部は、前記他の通信端末装置との間の前記第１の共有情報の共有条件に応じて前記第１の共有情報の粒度を変更し、前記他の通信端末装置との間の前記第１の共有情報の共有条件に応じて前記第１の共有情報に含める情報を選別することを特徴とする請求項１に記載の通信端末装置。
【請求項３】
前記連携部は、他の通信端末装置において設定される、当該他の通信端末装置のアプリケーションの識別情報、該アプリケーションが通信制御対象であるか否かを示す情報、該アプリケーションの正常通信条件に対応する第２の制御条件、該アプリケーションに対する解析結果を含む第２の共有情報の、少なくとも一部を受信することを特徴とする請求項１または２に記載の通信端末装置。
【請求項４】
前記アプリケーションの情報、前記解析部による解析結果、または、前記アプリケーションに関する前記第２の共有情報をユーザに提示し、前記アプリケーションに対する通信制御対象の可否に関するユーザの回答を受信するユーザインタフェース部と、
前記解析部は、前記アプリケーションの情報、前記解析部による解析結果、前記連携部が受信した前記第２の共有情報、及び、前記ユーザの回答に基づいて、前記アプリケーションが通信制御対象であるか否かを判定することを特徴とする請求項３に記載の通信端末装置。
【請求項５】
前記解析部は、統計的手法或いは機械学習を用いて、前記通信制御対象のアプリケーションの通信パターンを集計し、通信パターンが収束しないアプリケーションを通信制御対象外のアプリケーションとして分類し、通信パターンが収束したアプリケーションを前記通信制御対象のアプリケーションとして分類して正常通信範囲を特定することを特徴とする請求項１〜４のいずれか一つに記載の通信端末装置。
【請求項６】
通信端末装置によって実行される通信制御方法であって、
アプリケーションの通信を収集し、第１の制御条件に基づいて前記アプリケーションの通信を制御する収集制御工程と、
前記収集制御工程において収集された通信を解析して前記アプリケーションが通信制御対象であるか否かを判定し、通信制御対象のアプリケーションの正常通信範囲に基づいて前記第１の制御条件を生成する解析工程と、
前記アプリケーションの識別情報と、前記第１の制御条件とを含む第１の共有情報の少なくとも一部を、他の通信端末装置に送信する連携工程と、
を含んだことを特徴とする通信制御方法。
【請求項７】
アプリケーションの通信を収集し、第１の制御条件に基づいて前記アプリケーションの通信を制御する収集制御ステップと、
前記収集制御ステップにおいて収集された通信を解析して前記アプリケーションが通信制御対象であるか否かを判定し、通信制御対象のアプリケーションの正常通信範囲に基づいて前記第１の制御条件を生成する解析ステップと、
前記アプリケーションの識別情報と、前記第１の制御条件とを含む第１の共有情報の少なくとも一部を、他の通信端末装置に送信する連携ステップと、
をコンピュータに実行させるための通信制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信端末装置、通信制御方法及び通信制御プログラムに関する。
【背景技術】
【０００２】
従来、通信のパケットを分析してシグネチャマッチングによって機器種別や機器名を特定するシステムや、ブラックリストによって通信を制御するファイアウォールなどのシステムが提供されている。これらのシステムは、シグネチャやブラックリストと言った、外部情報を基に処理を行っているものが多く、情報源の確保、迅速な対応、解析の安全性、低コストを満たすことができない場合がある。
【０００３】
そこで、ＩｏＴ（Internet  of  Things）デバイスなど、通信パターンが限定される機器に対象を絞り、その通信をネットワークのゲートウェイ（ＧＷ）で学習し、異常通信を特定する方法が提案されている（例えば、非特許文献１参照）。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】張一凡他、「非集中化IoTセキュリティ制御の検討」、信学技報ICSS2017-58(2018-03)
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、この方法は、ＧＷで実装されるため、制御対象が、Ｗｉ−ＦｉなどのＧＷと直接通信を行うＩｏＴデバイスに限定されてしまう。従って、この方法では、現在、市場の多くを占めるスマートフォン上のアプリケーション（以降、「アプリ」とする。）をＧＷとするＩｏＴデバイスを制御することができなかった。
【０００６】
また、スマートフォン上の各アプリの通信を制御する方法として、ＯＳ上のファイアウォールが考えられるものの、ファイアウォールは、既存の実装を用いるだけであるため、解析の安全性を満たすことが難しい。
【０００７】
そして、アプリ毎の通信を解析することによってフィルタ条件を生成する方法がある。しかしながら、スマートフォンのアプリは、既存のＩｏＴデバイスなどと異なり、通信先が限定されないものが多い。これは、アプリの広告やそれを支えるコンテンツデリバリーネットワークがあるためである。従って、学習期間の通信パターンを用いた通信フィルタでは、正常通信を異常と判断する過検知が多発する。
【０００８】
さらに、解析期間、環境、ユーザの操作に起因して、アプリの通信が変わるため、理想的な全通信パターン学習が困難であり、偏った制御条件が生成されるリスクが高い。この場合、制御条件が確定した後に、操作等によって未知の正常な通信が発生すると、正常にもかかわらず異常と判断される過検知が発生し、通信制御が実行される。このような過検知が多発すると、通信の承認やシステムに対する信頼性が低下し、運用での安全性低下と利便性の低下が懸念される。
【０００９】
開示の実施の形態は、上記に鑑みてなされたものであり、通信端末装置上のアプリケーションの通信を適切に制御することを目的とする。
【課題を解決するための手段】
【００１０】
上述した課題を解決し、目的を達成するために、本発明に係る通信端末装置は、アプリケーションの通信を収集し、第１の制御条件に基づいてアプリケーションの通信を制御する収集制御部と、収集制御部が収集した通信を解析してアプリケーションが通信制御対象であるか否かを判定し、通信制御対象のアプリケーションの正常通信範囲に基づいて第１の制御条件を生成する解析部と、アプリケーションの識別情報と、第１の制御条件とを含む第１の共有情報の少なくとも一部を、他の通信端末装置に送信する連携部と、を有することを特徴とする。
【発明の効果】
【００１１】
本発明によれば、通信端末装置上のアプリケーションの通信を適切に制御することを可能にする。
【図面の簡単な説明】
【００１２】
【図１】図１は、実施の形態に係る通信システムの構成の一例を示す図である。
【図２】図２は、制御対象情報の一例を示す図である。
【図３】図３は、制御条件の一例を示す図である。
【図４】図４は、共有情報の一例を示す図である。
【図５】図５は、実施の形態に係る通信システムにおける処理の流れの一例を示すフローチャートである。
【図６】図６は、実施の形態における通信制御対象の判定処理の処理手順を示すフローチャートである。
【図７】図７は、解析部が収集したアプリの情報を説明する図である。
【図８】図８は、解析部が収集した他の端末装置の共有情報をアプリの情報を説明する図である。
【図９】図９は、ユーザインタフェース部による出力画面の一例を示す図である。
【図１０】図１０は、実施の形態における正常通信の解析処理の処理手順を示すフローチャートである。
【図１１】図１１は、プログラムが実行されることにより、実施の形態の端末装置が実現されるコンピュータの一例を示す図である。
【発明を実施するための形態】
【００１３】
以下、図面を参照して、本発明の一実施の形態を詳細に説明する。なお、この実施の形態により本発明が限定されるものではない。また、図面の記載において、同一部分には同一の符号を付して示している。
【００１４】
［実施の形態］
本実施の形態では、端末装置上のアプリをＧＷとして接続したＩｏＴデバイスの通信を制御する。端末装置上には多種のアプリがあるため、本実施の形態では、全てのアプリの通信を検知対象とするのではなく、通信制御の対象となるアプリを分類し、分類したアプリの異常通信を検知する。また、本実施の形態では、通信制御の対象となるアプリについては、正常通信パターンの特定を行って異常通信の検知を行うとともに、他の端末装置との連携によって異常通信の検知精度を向上する。
【００１５】
［通信システムの構成の一例］
実施の形態に係る通信システムについて説明する。図１は、実施の形態に係る通信システム１の構成の一例を示す図である。実施の形態に係る通信システム１は、端末装置１０（通信端末装置）を有する。端末装置１０は、外部ネットワークＮＷ−Ａを介して他の端末装置１１Ａ，１１Ｂ，…及びサーバ２０と接続される。また、端末装置１０は、外部ネットワークＮＷ−Ａとは異なるネットワークＮＷ−Ｂを介して、ＩｏＴデバイス４０Ａ，４０Ｂ，…と接続される。
【００１６】
端末装置１０は、例えば、スマートフォンである。端末装置１０は、ネットワークＮＷ−Ｂを介して接続されるＩｏＴデバイス４０Ａ，４０Ｂと、外部ネットワークＮＷ−Ａを介した外部装置との通信を制御する。端末装置１０は、この端末装置１０上のアプリをＧＷとして接続したＩｏＴデバイス４０の通信を、所定の通信制御条件に従って制御する。
【００１７】
端末装置１０は、通信制御対象であるアプリを分類し、通信制御対象のアプリの正常通信範囲に対応する制御条件を特定し、特定した制御条件を適用してアプリの通信を制御する。アプリの通信を制御する処理には、アプリの異常を検知し、異常通信を発生させたアプリの通信を遮断したり、異常通信の発生をユーザやサーバ２０に通知したりする処理が含まれる。
【００１８】
また、端末装置１０は、上位装置（例えばサーバ２０）による制御を介さずに、自律的に他の端末装置１１Ａ，１１Ｂ，…との間で情報を共有する自律連携を行う。端末装置１０は、例えば、データベースやファイルアップロードによるサーバ経由での情報の共有の他に、ブロックチェーン等を利用したサーバレスでの情報の共有を行う。端末装置１０は、通信制御対象のアプリの情報、アプリの通信に対する制御条件、アプリの通信を解析する際の学習内容等を、他の端末装置１１Ａ，１１Ｂ，…と共有する。
【００１９】
端末装置１１Ａ，１１Ｂ，…は、端末装置１０と同様の機能及び構成を有する装置である。端末装置１１Ａ，１１Ｂ，…は、端末装置１０が制御するＩｏＴデバイス４０Ａ，４０Ｂ，…とは別のＩｏＴ機器を制御する。なお、図１には２つの端末装置１１Ａ，１１Ｂ，…を図示するが、外部ネットワークＮＷ−Ａを介して端末装置１０に接続される他の端末装置の数は特に限定されない。以下、端末装置１１Ａ，１１Ｂ，…各々を区別する必要がないときは、総括的に端末装置１１と表示する。
【００２０】
サーバ２０は、端末装置１０を提供するサービス提供者が管理する情報処理装置である。サーバ２０の構成は特に限定されない。サーバ２０は例えば、物理的に一つのサーバであっても、複数のサーバにまたがって仮想的に構築される仮想サーバであってもよい。
【００２１】
ＩｏＴデバイス４０Ａ，４０Ｂ，…は、端末装置１０の制御対象機器である。ＩｏＴデバイス４０Ａ，４０Ｂ，…は例えば、所定の空間及び位置に配置される温度センサ、照度センサ、人感センサ、開閉センサ等のセンサである。また、例えば、ＩｏＴデバイス４０Ａ，４０Ｂ，…は、ＩｏＴサービスにより消費電力量を制御される情報処理装置である。また、例えば、ＩｏＴデバイス４０Ａ，４０Ｂ，…は、所定空間の画像を撮影して端末装置１０に送信する撮像装置である。なお、図１にはＩｏＴデバイスを２つ図示するが、端末装置１０の配下に接続されるＩｏＴ機器の数は特に限定されない。以下、ＩｏＴデバイス４０Ａ，４０Ｂ，…各々を区別する必要がないときは、総括的にＩｏＴデバイス４０と表示する。
【００２２】
外部ネットワークＮＷ−Ａは、端末装置１０と外部装置とを通信可能に接続する通信網である。外部ネットワークＮＷ−Ａは例えば、インターネット、イントラネット、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）等である。外部ネットワークＮＷ−Ａは、有線ネットワークまたは無線ネットワークまたはその組み合わせであってよい。
【００２３】
ネットワークＮＷ−Ｂは、端末装置１０とＩｏＴデバイス４０Ａ，４０Ｂ，…とを通信可能に接続する通信網である。ネットワークＮＷ−Ｂの種類は特に限定されない。ネットワークＮＷ−Ｂは例えば、インターネット、イントラネット、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）等であってよく、有線ネットワーク、無線ネットワークまたはその組み合わせであってよい。
【００２４】
［端末装置１０の構成］
図１を参照し、さらに端末装置１０の構成及び機能の一例について説明する。端末装置１０は、制御部１００と記憶部２００とを備える。
【００２５】
制御部１００は、端末装置１０における通信制御処理を制御する。制御部１００としては、ＣＰＵ（Central  Processing  Unit）、ＭＰＵ（Micro  Processing  Unit）等の電子回路や、ＡＳＩＣ（Application  Specific  Integrated  Circuit）、ＦＰＧＡ（Field  Programmable  Gate  Array）等の集積回路を利用することができる。また、制御部１００は、端末装置１０における処理手順等を規定したプログラムや制御データを格納する記憶部を有する。制御部１００は、各種プログラムが動作することにより、各種の処理部として機能する。
【００２６】
記憶部２００は、各種のデータを記憶する記憶装置である。記憶部２００は、ＲＡＭ（Random  Access  Memory）、フラッシュメモリ、などのデータを書き換え可能な半導体メモリであってもよい。記憶部２００として使用される装置は特に限定されない。
【００２７】
［各種情報の説明］
まず、本実施の形態の通信システム１において使用する情報について説明する。「制御条件」とは、各アプリの正常通信範囲を示す情報である。正常通信範囲は、端末装置１０が各アプリの通信を、通信先数、パケットサイズなどの複数の観点から、統計解析または学習することによって、抽出される。本実施の形態では「制御条件」は、いわば通信についてのホワイトリストの役割を果たす。「制御条件」はフィルタ条件とも呼ぶことができる。
【００２８】
「制御条件」に合致しない通信を、以下「異常通信」と呼ぶ。また、「制御条件」に基づく通信制御が実行されていない場合の正常な通信を「定常通信」と呼ぶ。「定常通信」は、正常通信の条件である「正常通信条件」ともいえる。
【００２９】
例えば、解析（学習）対象であるアプリＤが「定常通信」を実行した所定期間中のアプリの通信先の数が「１」であった場合、制御条件は「アプリＤの通信先の数＝１」となる。この場合、端末装置１０による制御開始後にアプリＤが複数の通信先と通信しようとすると、端末装置１０は、アプリＤの「異常通信」が発生したと判定する。また、例えば、解析（学習）対象であるアプリＥが「定常通信」を実行した所定期間中のアプリＥの通信時間が、予め設定された設定時間のみであったとする。この場合、制御条件は、「アプリＥの通信時間＝設定時間」となる。この場合、通信システム１による制御開始後にアプリＥが設定時間外に通信しようとすると、端末装置１０は、アプリＥの「異常通信」が発生したと判定する。
【００３０】
［記憶部２００に記憶される情報］
記憶部２００は、制御対象情報記憶部２０１と、制御条件記憶部２０２と、共有情報記憶部２０３と、を有する。
【００３１】
制御対象情報記憶部２０１は、アプリの識別情報と、通信制御対象であるか否かのいずれかを示す情報とを対応付けた制御対象情報を記憶する。図２は、制御対象情報の一例を示す図である。
【００３２】
図２に示すように、制御対象情報は、アプリの名称及びバージョン情報と、通信制御対象の可否とが対応付けられている。「True」は、通信制御対象であることを示し、「False」は、通信制御対象外であることを示す。
【００３３】
例えば、アプリＡの場合、「A：v1.9」及び「A：v1.8」のいずれについても「True」であることが示される。また、アプリＣの場合、「C：v1」については「False」であることが示される。制御対象情報は、可視化のためにユーザインタフェース（ＵＩ）部１０５（後述）、通信制御のために収集制御部１０２（後述）、端末装置間の自律連携のために連携部１０４（後述）において使用される。
【００３４】
制御条件記憶部２０２は、各アプリの制御条件を記憶する。図３は、制御条件の一例を示す図である。図３に示すように、各制御条件には、アプリの名称及びバージョン情報が対応付けられている。
【００３５】
例えば、アプリＡの場合、「A：v1.9」及び「A：v1.8」のいずれについても、「packet  size｛10kB±20%｝、50kbyte/packet  ±50%、プロトコル＝｛HTTPS｝、Duration：｛曲線y=x2+Sx+2.5｝」が記憶される。これは、アプリＡの通信は、パケットサイズが１０ｋＢ±２０％のパケットが送信されている場合には、正常通信の範囲内とみなすことを示す。また、アプリＡの通信は、パケット各々が５０±５０％キロバイトの大きさである場合には、正常通信の範囲内とみなすことを示す。また、アプリＡの通信は、プロトコルとしてＨＴＴＰＳを使用している場合には正常通信の範囲内とみなすことを示す。
【００３６】
図３の例では、アプリＡの２つのバージョン「v1.9」，「v1.8」には同一の制御条件が対応付けて記憶されている。また、アプリＣ，Ｚは、制御対象ではないため、例えば、ユーザ操作に起因して通信パターンを定型化できないので、対象外とされる。制御条件は、可視化のためにＵＩ部１０５（後述）、通信制御のために収集制御部１０２（後述）、端末装置間の自律連携のために連携部１０４（後述）において使用される。
【００３７】
共有情報記憶部２０３は、端末装置１０が他の端末装置１１と共有する共有情報を記憶する。共有情報は、「Ｋｅｙ」として「アプリ名：バージョン」を含む。共有情報は、例えば、「Ｖａｌｕｅ」として「正常通信条件（≠正常通信の一覧）」を含む。
【００３８】
図４は、共有情報の一例を示す図である。図４は、本端末装置１０が、他の端末装置１１に提供する共有情報の一例を示すが、共有情報記憶部２０３は、他の端末装置１１から提供された共有情報も記憶する。図４に示すように、共有情報は、「アプリ名：バージョン」、「制御可否」、「定常通信（＝正常通信条件）」、「オプションフィールド」の項目を有する。
【００３９】
「制御可否」には、対応するアプリが、その端末装置において通信制御対象か否かが示される。「True」は、通信制御対象であることを示し、「False」は、通信制御対象外であることを示す。
【００４０】
「定常通信」には、提供元の端末装置１０における正常通信条件が示される。この「定常通信」の内容については、提供先の端末装置１１に応じて、共有する情報の粒度が変更される。例えば、セキュアなＭＳＳへの情報共有である場合、通信解析の再現に必要な情報をサービス約款などに従って「定常通信」の内容を最大限共有することによって、サービスの精度の向上を図ることができる。
【００４１】
また、サーバレスでの共有または公開システムへの共有である場合、統計の特徴量のみを「定常通信」の内容として共有し、具体的な通信先は秘匿される。例えば、図４の場合、アプリＡについては、具体的なプロトコルの名称を示さず、プロトコルの個数のみを示している。
【００４２】
「オプションフィールド」は、アプリ情報に基づく通信制御の困難さを示す値α、他の端末装置での学習結果の類似度に基づく通信制御の容易さを示す値β、ユーザの操作及び認識に基づく制御可否を示す値γの各係数の値を含む。「オプションフィールド」は、このアプリをＧＷとして接続するＩｏＴデバイス４０の機器情報を含む。「オプションフィールド」は、このアプリに対する解析期間を含む。図４の例では、アプリＡについては、「A：v1.9」及び「A：v1.8」のいずれについても、解析期間が「１日」であることが示される。
【００４３】
また、共有情報は、アプリ名：バージョンを検索キーとして、「正常通信条件」の他、解析結果、アプリの通信を解析する際の学習条件、アラートに対するユーザ判断をバリューに含んでもよい。
【００４４】
なお、制御対象情報、制御条件及び共有情報が記憶されるタイミングや態様は特に限定されない。また、記憶部２００は、ユーザが所定のアプリについて接続及び通信を拒否した場合にはその旨の情報を記憶する。また、記憶部２００は、図２〜図４に示す情報のほか、共有情報を他の端末装置１１から取得した場合に当該共有情報の送信元の端末装置１１を特定する情報を記憶してもよい。記憶部２００は、制御対象情報、及び制御条件を設定する際の端末装置１０，１１による学習期間の長さを、制御条件に対応付けて記憶してもよい。
【００４５】
［制御部１００の各部の機能及び構成の一例］
制御部１００は、通信部１０１、収集制御部１０２、解析部１０３、連携部１０４及びＵＩ部１０５を有する。通信部１０１、収集制御部１０２、解析部１０３、連携部１０４及びＵＩ部１０５は、通信解析アプリとして、端末装置１０にインストールされる。アプリの通信は、ＯＳの機能により設定はなく、通信解析アプリを経由して、アプリの情報も仲介される。
【００４６】
通信部１０１は、端末装置１０の外部ネットワークＮＷ−Ａを介した通信を実現する通信インタフェースである。端末装置１０上のネットワーク通信は、ＶＰＮやＰｒｏｘｙを介し、通信部１０１を経由する。通信部１０１は、外部ネットワークＮＷ−Ａから送信される情報を受信し、所定の設定に応じて、受信した情報を収集制御部１０２、解析部１０３、連携部１０４及びＵＩ部１０５の各機能部に送信する。また、通信部１０１は、所定の設定に応じて、収集制御部１０２、解析部１０３、連携部１０４及びＵＩ部１０５の各機能部から受信した情報を外部に送信する。
【００４７】
収集制御部１０２は、ネットワークＮＷ−Ｂを介してＩｏＴデバイス４０と行うアプリの通信に関する情報を収集する。収集制御部１０２は、記憶部２００に記憶されていないアプリが端末装置１０に追加されると、追加されたアプリについて所定期間にわたり定常通信を実行し、通信の情報を収集する。そして、収集制御部１０２は、収集した通信の情報を追加アプリの解析指示とともに解析部１０３に送る。
【００４８】
収集制御部１０２は、解析部１０３の処理結果に基づき設定される制御条件（第１の条件）に従い、アプリの通信を制御する。例えば、収集制御部１０２は、所定の制御条件に合致しないアプリの通信を遮断する。また、例えば、収集制御部１０２は、所定の制御条件に合致しないアプリの通信を検知し、ユーザにアラートを送信する。また、例えば、収集制御部１０２は、所定の制御条件に合致しない通信が発生した場合、当該通信を発生させたアプリの通信の再解析（再学習）を解析部１０３に指示する。このように、端末装置１０は、ユーザのアプリの導入障壁を下げるために、通信解析アプリが、他のアプリの通信を解析及び監視し、不正通信を検出及び制御する。
【００４９】
解析部１０３は、収集制御部１０２が収集したアプリの通信を、収集制御部１０２から受信する。解析部１０３は、受信した通信を解析して、この通信を行ったアプリが通信制御対象であるか否かを判定する。解析部１０３は、アプリケーションの情報、連携部１０４（後述）が受信した他の端末装置１１による共有情報、及び、アプリケーションに対する信制御対象の可否に関するユーザの回答に基づいて、アプリが通信制御対象であるか否かを判定する。また、解析部１０３は、ユーザ操作に応じて通信先が増えるアプリや、通信プロトコルが変わるアプリについては正常通信条件が生成できないため通信制御対象外とし、それ以外のアプリは通信制御対象とする。
【００５０】
そして、解析部１０３は、通信制御対象のアプリケーションの正常通信範囲に基づいて、解析対象のアプリに対する制御条件（第１の条件）を生成する。解析部１０３は、統計的手法或いは機械学習を用いて、通信制御対象のアプリの正常通信範囲を特定する。設定した制御条件、学習条件は、記憶部２００に記憶される。
【００５１】
解析部１０３は、収集制御部１０２からの指示に基づき、制御条件に合致しない通信を発生させたアプリの通信の再解析（再学習）を実行する。解析部１０３は、制御条件に合致しないアプリの通信を収集制御部１０２から受信し、再解析を実行して制御条件を設定する。なお、解析部１０３は、制御条件の設定、制御条件の再解析に際して、端末装置１０で生成された共有情報及び他の端末装置１１から取得した共有情報を参照することができる。解析部１０３が設定した制御条件は設定に応じて記憶部２００に記憶され、各機能部に送信される。
【００５２】
連携部１０４は、解析部１０３の解析結果に基づき設定されるアプリの制御条件を、他の端末装置１１と共有する。また、連携部１０４は、他の端末装置１１上で設定されたアプリの制御条件を、他の端末装置１１と共有する。すなわち、連携部１０４は、他の端末装置１１において設定される、当該他の端末装置１１のアプリケーションの識別情報、該アプリケーションが通信制御対象であるか否かを示す情報、該アプリケーションの正常通信条件に対応する制御条件（第２の制御条件）、該アプリケーションに対する解析結果を含む第２の共有情報の少なくとも一部を受信する。
【００５３】
ここで、共有とは、端末装置１０は、他の端末装置１１における制御対象の可否情報を含むアプリの情報やその制御条件等を参照でき、他の端末装置１１は、端末装置１０における制御対象の可否情報を含むアプリの情報やその制御条件等を参照できることを意味する。
【００５４】
なお、解析部１０３は、アプリの識別情報をキーとして、連携部１０４が他の端末装置１１から受信した共有情報から正常通信条件やオプションフィールドを参照することも可能である。解析部１０３は、求めた正常通信範囲、或いは、参照した他の端末装置１１における正常通信条件やオプションフィールドの内容をユーザに提示し、ユーザの回答を基に、解析対象のアプリに対する解析内容や制御条件を調整する。
【００５５】
連携部１０４は、自端末装置１０上で制御条件が設定されたアプリの識別情報及びその制御条件等の情報から共有情報を生成する。連携部１０４は、他の端末装置１１との間の共有情報の共有条件に応じて、共有条件の情報の粒度を変更する。また、連携部１０４は、端末装置１１との間の共有情報の共有条件に応じて、共有情報に含める情報を選別する。
【００５６】
例えば、連携部１０４は、ＤＢやファイルアップロードによるサーバ経由で情報の共有を行う。サーバ経由の共有は、ＭＳＳなどの運用や情報の訂正サポートが必要な場合に用いられる。そして、セキュアなＭＳＳへの情報共有である場合、通信解析の再現に必要な情報をサービス約款などに従って、制御条件の内容を最大限共有可能としてもよい。言い換えると、連携部１０４は、サービス提供者のセキュリティ条件に合わせて共有すべき情報の粒度を上げる。
【００５７】
また、連携部１０４は、ブロックチェーンなどのサーバレスでの共有または公開システムへの共有である場合、統計の特徴量のみを制御条件の内容として共有し、具体的な通信先は秘匿する。例えば、サーバレスの共有は、集中管理による制御（政府による通信規制等）を回避したい場合にも用いることを想定し、連携部１０４は、通信先アドレスなど機密性の高い情報を共有しない等の対策を組み込む。
【００５８】
そして、連携部１０４は共有情報の一部または全部を他の端末装置１１に送信する。連携部１０４はまた、他の端末装置１１から共有情報の一部または全部を受信する。なお、共有の態様は特に限定されない。例えば、端末装置１０上で共有情報の一部が特定されるごとに、他の端末装置１１に送信されるものとしてもよいし、他の端末装置１１からの要求に応じて送信するものとしてもよい。また、共有情報の全部を送信するものとしてもよく、一部を送信するものとしてもよい。
【００５９】
ＵＩ部１０５は、各種情報をユーザに提供し、ユーザからの入力を受信する。ＵＩ部１０５は、例えば、液晶画面、タッチパネル、スピーカ、マイクロフォン等を含んでもよい。
【００６０】
ＵＩ部１０５は、アプリの情報及びアプリに関する他の端末装置１１から提供された共有情報をユーザに提示し、解析対象のアプリに対する通信制御対象の可否に関するユーザの回答を受信する。例えば、ＵＩ部１０５は、解析部１０３による自装置のアプリの解析内容と、他の端末装置１１における該アプリの解析内容を比較できるようにユーザに表示する。
【００６１】
ＵＩ部１０５はまた、制御条件を逸脱する通信を発生させたアプリに関する情報をユーザに通知する。ＵＩ部１０５は、制御条件を逸脱する通信が発生した場合に、その旨の通知をユーザに送信するとともに、過検知であるか否かのユーザの確認を要求する画面を表示する。
【００６２】
［通信制御処理の流れ］
図５は、実施の形態に係る通信システム１における処理の流れの一例を示すフローチャートである。通信システム１においては、端末装置１０に新しいアプリが追加される（ステップＳ１）と、収集制御部１０２は、新しいアプリに定常通信を試行させ、通信仲介し、通信の情報を収集し（ステップＳ２）、解析部１０３に通信解析を依頼する。
【００６３】
解析部１０３は、追加されたアプリが通信制御対象であるか否かを判定する（ステップＳ３）。解析部１０３は、追加されたアプリについて、アプリの名称等のアプリの情報に基づき制御可否判断を行う。解析部１０３は、追加されたアプリについて、連携部１０４が取得する他の端末装置１１の共有情報の解析結果に基づき制御可否判断を行う。そして、解析部１０３は、追加されたアプリに対する、通信制御対象の可否に関するユーザの回答に基づき制御可否判断を行う。解析部１０３は、アプリの情報、共有情報及びユーザの回答結果を適用した所定の判定式を演算して判定を行う。
【００６４】
制御部１００は、追加されたアプリが、通信制御対象外、かつ、判定演算結果が一定値未満である場合（ステップＳ４：Ｙｅｓ）、追加されたアプリは、通信制御対象外であるとして処理を終了する。
【００６５】
また、解析部１０３は、追加されたアプリが、通信制御対象、または、判定演算結果が一定値以上である場合（ステップＳ４：Ｎｏ）、統計的手法または機械学習を用いて、通信制御対象のアプリケーションの正常通信範囲を特定する正常通信解析を行う（ステップＳ５）。解析部１０３は、統計的手法として、信頼区間、数え上げ、principal  component  analysis（ＰＣＡ）などを用いて通信のパターンを特定し、時間が増加してもパターンが増加しなくなった場合には、そのパターンを正常通信条件として定義する。
【００６６】
解析部１０３は、正常通信範囲を特定した場合（ステップＳ６：Ｙｅｓ）、正常通信範囲に基づいて該アプリの制御条件を生成する（ステップＳ７）。解析部１０３は、解析結果、正常通信範囲、制御条件を記憶部に出力する。
【００６７】
そして、解析部１０３は、生成した制御条件を、追加されたアプリに対する制御条件として、収集制御部１０２に設定する（ステップＳ８）。これによって、収集制御部１０２は、設定された制御条件に従い、追加されたアプリの通信を制御する。収集制御部１０２は、制御条件の生成と同じ手法を用いて通信を統計し、正常通信範囲外の通信があれば異常とみなす。例えば、収集制御部１０２は、所定の制御条件に合致しないアプリの通信を遮断する。
【００６８】
また、正常通信範囲が特定されなかった場合（ステップＳ６：Ｎｏ）またはステップＳ８処理後、連携部１０４は、解析部１０３が特定した正常通信条件を、他の端末装置１１に送信して共有する（ステップＳ９）。
【００６９】
そして、収集制御部１０２は、所定の制御条件に合致しないアプリの通信を検知した場合には、ユーザにアラートを表示して、制御条件と対処を可視化する（ステップＳ１０）。
【００７０】
［通信制御対象の判定］
次に、解析部１０３による通信制御対象の判定処理について説明する。図６は、実施の形態における通信制御対象の判定処理の処理手順を示すフローチャートである。
【００７１】
図６に示すように、解析部１０３は、収集制御部１０２が収集したアプリの通信を解析して、アプリの情報を収集する（ステップＳ２１）。
【００７２】
図７は、解析部１０３が収集したアプリの情報を説明する図である。図７に示すように、解析部１０３は、アプリの情報として、アプリの広告の有無、バックグラウンド通信の有無、通知の有無を配点対象の条件として収集し、条件に該当する場合にはそれぞれ配点を付して合計点を計算する。例えば、図７の例では、解析対象のアプリは、アプリの広告、バックグラウンド通信、通知のいずれもが「○」であるため、それぞれの条件に対応する配点が付された結果、合計点が２５点であると判定される。この合計点を基に、解析部１０３は、アプリ情報に基づく通信制御の困難さを示す係数αを導出する（ステップＳ２２）。
【００７３】
解析部１０３は、ステップＳ２１，２２と並列に、ステップＳ２３，２４を実行する。解析部１０３は、自律連携で、他の端末装置１１の共有情報を収集する（ステップＳ２３）。
【００７４】
図８は、解析部１０３が収集した他の端末装置１１の共有情報をアプリの情報を説明する図である。図８に示すように、解析部１０３は、共有情報として、解析対象のアプリをＧＷとする接続デバイスの識別情報、制御対象の可否、通常範囲での通信先を取得するとともに、他の端末装置１１における学習結果を取得する。そして、解析部１０３は、他の端末装置１１での学習結果の類似度に基づく通信制御の容易さを示す係数βを導出する（ステップＳ２４）。類似度は、ベクトル空間法等により０〜１の値を取る。
【００７５】
解析部１０３は、ＵＩ部１０５に、アプリの情報及びアプリに関する他の端末装置１１から提供された共有情報をユーザに提示させて、ユーザによる、解析対象のアプリの通信制御対象の可否に対する判定の入力を要求する（ステップＳ２５）。
【００７６】
図９は、ＵＩ部１０５による出力画面の一例を示す図である。図９に示すように、画面には、係数αによって判定されるアプリ上ホイに基づく判定難易度、係数βによって判定される自律連携での判定の他にユーザによる判定が表示する。この場合、備考に、通信制御対象の可否判定の根拠となる内容や、ユーザへの通信文が示される。ユーザは、解析対象のアプリを、通信制御対象とするか、或いは、通信制御対象外とするかを選択し、ＵＩ部１０５に回答を入力する。
【００７７】
解析部１０３は、ステップＳ２５処理後、一定時間が経過してもユーザ回答がない場合（ステップＳ２６：Ｙｅｓ）、ユーザの回答なしとして、ユーザの操作・認識に基づく通信制御対象の可否判定結果γとして、γ＝０．５を出力する（ステップＳ２７）。
【００７８】
また、解析部１０３は、一定期間経過前にユーザ回答があった場合（ステップＳ２６：Ｎｏ）、ユーザによる通信制御対象の可否判定情報を収取する（ステップＳ２８）。そして、解析部１０３は、回答結果に応じて、γの値を出力する（ステップＳ２９）。解析部１０３は、解析対象のアプリが、ユーザから通信制御対象であると判定された場合には、γ＝１を出力する。また、解析部１０３は、解析対象のアプリが、ユーザから通信制御対象でないと判定された場合には、γ＝０を出力する。
【００７９】
そして、ユーザが定義した判定式に、α、β、γの値を適用し（ステップＳ３０）、演算する。解析部１０３は、α、β、γに対して重み付けを行ってから、判定式に適用してもよい。α、β、γに対する重み付けや判定式は、オフィス利用、プライベート利用、利用ルールなど利用シーンで異なるため、サービス提供者が設定する。また、判定式は、アプリ情報収集での配点、自律連携での情報粒度、ユーザの回答率及び精度に応じて適宜修正される。例えば、判定式として、「（-0.01α+β）γ」が使用され、演算結果が一定値（例えば、０．３）以上であれば、通信制御対象であると判定される。
【００８０】
ステップＳ３０における演算結果が一定値以上である場合（ステップＳ３１：Ｙｅｓ）、解析部１０３は、解析対象のアプリを通信制御対象と判定する（ステップＳ３２）。また、ステップＳ３０における演算結果が一定値未満である場合（ステップＳ３１：Ｎｏ）、解析対象のアプリを通信制御対象外と判定する（ステップＳ３３）。解析部１０３は、判定式の演算結果とともに判定結果を出力する（ステップＳ３４）。
【００８１】
［正常通信の解析］
次に、制御部１００による正常通信の解析処理について説明する。図１０は、実施の形態における正常通信の解析処理の処理手順を示すフローチャートである。
【００８２】
図１０に示すように、解析部１０３は、アプリごとの通信に規則性（パターン）が有ることを前提として、アプリの通信パターンを解析する（ステップＳ４１）。ＩｏＴデバイス４０は、特定の通信パターンでのみ通信する場合が多いことが知られている。端末装置１０のアプリがＩｏＴのＧＷとなる場合では、アプリも通信パターンが絞り込めることが予想され、一般なアプリに対しても特定用途でのみ用いられるものはその通信パターンを基に異常通信の検知が可能と考える。特に遠隔攻撃などによって端末装置のアプリが不正に操作される場合、正常とは異なる通信パターンが発生する可能性が高い。
【００８３】
このため、解析部１０３は、ステップＳ４１において、通信先数、パケットサイズ、通信回数など複数の観点から、通信特性を集計して統計解析または機械学習を行い、アプリの通信パターンを解析する。
【００８４】
そして、解析部１０３は、解析した通信パターンが収束しているか否かを判定する（ステップＳ４２）。解析部１０３は、通信パターンの累積値の変化を、時間や通信量を変数として、曲線にフィッティングし、計算したパラメータを基にある時刻またはある通信量のときの収束率を計算する。そして、解析部１０３は、計算した収束率が所定値以上である場合に、通信パターンが収束したと判定する。また、解析部１０３は、計算した収束率が所定値未満である場合に、通信パターンが収束していないと判定する。端末装置１０は、通信パターンとして収束しないアプリについては、後述する処理によって通信制御対象外として分類することで、不要な統計や学習を防止し、その演算コストを削減する。
【００８５】
通信パターンが収束した場合には（ステップＳ４２：Ｙｅｓ）、解析部１０３は、特定済みのパターン数が所定数未満であるか、または、所定数以上であるかを判定する（ステップＳ４３）。特定済みのパターンとは、通信先、通信先数の数、通信の範囲（サイズ）、期間などの観点で特定されたパターンを示す。そして、ＣＰＵの負荷に応じて、ステップＳ４３における所定数が設定される。
【００８６】
解析部１０３は、特定済みのパターン数が所定値よりも少ないと判定した場合（ステップＳ４３：所定値未満）、このアプリを通信制御可能であるアプリとして分類し（ステップＳ４４）、通信パターンに基づくフィルタ条件（制御条件）を作成する（ステップＳ４５）。
【００８７】
連携部１０４は、通信制御対象外に分類されたアプリの情報、このアプリに関する解析部１０３による統計結果、機械学習結果、フィルタ条件などを基に自装置の共有情報を作成する。そして、連携部１０４は、セキュリティ条件に応じて共有条件を調整した後、アプリ情報自律連携のために、他の端末装置１１に共有情報を提供する（ステップＳ４６）。
【００８８】
収集制御部１０２は、フィルタ条件に従って、このアプリの通信を制御し（ステップＳ４７）、正常通信であるか否かを判定する（ステップＳ４８）。収集制御部１０２は、異常通信を検知した場合（ステップＳ４８：Ｎｏ）、ＵＩ部１０５から、この異常検知が過検知であるか否か確認をユーザに要求する画面を表示させて、過検知に関するユーザ確認結果を取得する（ステップＳ４９）。収集制御部１０２は、ユーザが過検知と確認した場合（ステップＳ５０：Ｙｅｓ）、解析期間を延長し（ステップＳ５１）、解析部１０３に、このアプリの通信の再解析を依頼する。
【００８９】
一方、収集制御部１０２は、ユーザが過検知でないと確認した場合（ステップＳ５０：Ｎｏ）、アプリの通信の遮断や異常通信の発生の通知を実行し、ステップＳ４７に戻る。また、収集制御部１０２は、正常通信である場合（ステップＳ４８：Ｙｅｓ）、ステップＳ４７に戻る。
【００９０】
また、解析部１０３は、特定済みのパターン数は所定数以上であると判定した場合（ステップＳ４３：所定数以上）、ＵＩ部１０５から、解析対象のアプリでは、性能に影響を与える旨及び通信パターンの特定不足によるリスクがある旨をユーザに提示する（ステップＳ５２）。そして、解析部１０３は、連携部１０４を介して、アプリ情報の自律連携のために、他の端末装置１１の共有情報を取得する（ステップＳ５３）。解析部１０３は、ユーザが、このアプリに関する他の端末装置１１の解析内容と、自装置における解析内容とを比較できるように、ＵＩ部１０５から、他の端末装置１１における解析条件や解析結果を表示させる。通信制御対象の可否結果を表示させる。
【００９１】
解析部１０３は、ＵＩ部１０５から、ユーザによる、解析対象のアプリに対する通信制御対象の可否のいずれかの入力を要求する画面を表示し、解析対象のアプリに対する通信制御対象の可否に関するユーザの確認結果を取得する（ステップＳ５４）。
【００９２】
解析部１０３は、ユーザが、解析対象のアプリを通信制御対象として許可した場合（ステップＳ５５：可）、このアプリの通信パターンに基づくフィルタ条件（制御条件）を作成する（ステップＳ４５）。
【００９３】
また、解析部１０３は、ユーザが、解析対象のアプリを通信制御対象として許可しなかった場合（ステップＳ５５：否）、このアプリを通信制御対象外のアプリと分類する（ステップＳ５６）。連携部１０４は、アプリ情報の自律連携のために、他の端末装置１１に、自装置において通信制御対象外に分類されたアプリに関する共有情報を作成し、他の端末装置１１に提供する（ステップＳ５７）。
【００９４】
これに対し、通信パターンが収束していない場合には（ステップＳ４２：Ｎｏ）、解析部１０３は、最長解析期間を超過しているか否かを判定する（ステップＳ５８）。最長解析期間を超過していない場合（ステップＳ５８：Ｎｏ）、解析部１０３は、解析期間を延長し（ステップＳ５１）、このアプリの通信の解析を継続する。
【００９５】
また、最長解析期間を超過している場合（ステップＳ５８：Ｙｅｓ）、解析部１０３は、解析対象のアプリを、通信制御対象外のアプリと分類する（ステップＳ５９）。そして、解析部１０３は、連携部１０４を介して、他の端末装置１１の共有情報を取得する（ステップＳ６０）。そして、解析部１０３は、他の端末装置１１の解析内容と自装置の解析内容との誤差をユーザに確認してもらうために、ＵＩ部１０５から、取得した供給情報を表示させる。例えば、ＵＩ部１０５は、解析対象のアプリの通信について、他の端末装置１１が解析を完了できたか否を示す情報、或いは、このアプリの通信に対する他の端末装置１１での解析期間などを表示する。このように、端末装置１０は、外部のホワイトリストをそのまま使用せず、ユーザによる確認が完了してから処理を進めるので、この端末装置１０に、より適切な制御条件を設定することができる。
【００９６】
解析部１０３は、ＵＩ部１０５から、ユーザによる、解析対象のアプリに対する通信制御対象の可否のいずれかの入力を要求する画面を表示し、解析対象のアプリに対する通信制御対象の可否に関するユーザの確認結果を取得する（ステップＳ６１）。
【００９７】
解析部１０３は、ユーザが、解析対象のアプリを通信制御対象として許可した場合（ステップＳ６２：可）、最長解析期間を延長し（ステップＳ６３）、ステップＳ５８に戻る。また、解析部１０３は、ユーザが、解析対象のアプリを通信制御対象として許可しなかった場合（ステップＳ６２：否）、このアプリを通信制御対象外のアプリと分類する（ステップＳ５６）。連携部１０４は、アプリ情報の自律連携のために、他の端末装置１１に、自装置において通信制御対象外に分類されたアプリに関する共有情報を作成し、他の端末装置１１に提供する（ステップＳ５７）。
【００９８】
［実施の形態の効果］
このように、実施の形態に係る端末装置１０は、アプリケーションの通信を収集し、第１の制御条件に基づいてアプリケーションの通信を制御する。端末装置１０は、収集した通信を解析してアプリが通信制御対象であるか否かを判定し、通信制御対象のアプリケーションの正常通信範囲に基づいて第１の制御条件を生成する。端末装置１０は、アプリの識別情報と、第１の制御条件とを含む第１の共有情報の少なくとも一部を、他の通信端末装置に送信する。
【００９９】
このため、実施の形態に係る端末装置１０は、外部情報に依存することなく、各アプリの通信状況に即した制御を実現することができる。従って、本実施の形態では、端末装置１０で実行されるアプリが不正に操作されるなどして、定常時と異なる通信を発生した場合であっても、その検知及び対処が可能になる。すなわち、本実施の形態によれば、端末装置１０上のアプリケーションの通信を適切に制御することを可能にする。そして、本実施の形態では、収集制御部１０２、解析部１０３、連携部１０４及びＵＩ部１０５は、通信解析アプリとして機能して、他のアプリの通信を解析及び監視し、不正通信を検出及び制御するため、ユーザによるアプリの導入障壁を下げることができる。
【０１００】
また、実施の形態に係る端末装置１０は、他の端末装置１１との間の共有情報の共有条件に応じて共有情報の粒度を変更する。また、連携部１０４は、他の通信端末装置との間の共有情報の共有条件に応じて共有情報に含める情報を選別する。すなわち、本実施の形態では、サービス提供者のセキュリティ条件に合わせて共有情報の粒度の調整や、機密性の高い情報を共有しないといった処理を行うことで、共有する情報の保護を行う。
【０１０１】
また、実施の形態に係る端末装置１０は、他の端末装置１１において設定される、当該他の通信端末装置のアプリケーションの識別情報、該アプリケーションが通信制御対象であるか否かを示す情報、該アプリケーションの正常通信条件に対応する第２の制御条件、該アプリケーションに対する解析結果を含む第２の共有情報の少なくとも一部を受信する。そして、実施の形態に係る端末装置１０は、ＵＩ部１０５を介して、アプリケーションの情報、解析部による解析結果、または、アプリケーションに関する第２の共有情報をユーザに提示し、アプリケーションに対する信制御対象の可否に関するユーザの回答を受信する。
【０１０２】
端末装置１０は、アプリケーションの情報、解析部による解析結果、連携部が受信した第２の共有情報、及び、ユーザの回答に基づいて、アプリケーションが通信制御対象であるか否かを判定する。
【０１０３】
従って、端末装置１０は、半自動的にアプリの通信制御の可否を分類する。端末装置１０によれば、ユーザは、自装置における解析内容と、他の端末装置１１における解析内容とを比較して、解析対象であるアプリに対する処理を決定することができる。
【０１０４】
また、端末装置１０によれば、アプリで発生する通信を可視化してユーザに提示するため、ユーザは、アプリの通信制御を確認することができる。特に、本実施の形態では、遠隔攻撃などによって端末装置のアプリが不正に操作される場合、正常とは異なる未知の通信パターンを可視化し、ユーザに提示した上で、ユーザの回答に従い適切に制御することが可能である。
【０１０５】
また、実施の形態に係る端末装置１０は、統計的手法或いは機械学習を用いて、通信制御対象のアプリケーションの通信パターンを集計し、通信パターンが収束しないアプリケーションを通信制御対象外のアプリケーションとして分類する。
【０１０６】
このように、端末装置１０は、ブラウザなどユーザの操作に応じて通信パターンが収束しないアプリを通信制御対象から外して、効率的な通信制御を実現する。また、端末装置１０は、通信パターンが収束したアプリケーションを通信制御対象のアプリケーションとして分類して正常通信範囲を特定する。このように、端末装置１０は、通信パターンが収束したアプリケーションについては、通信制御対象に分類して正常な通信パターンを特定し、正常通信範囲を適切に特定できるため、異常検知を行うための制御条件の精度も高めることができる。
【０１０７】
以上のように、実施の形態によれば、アプリで発生する通信の可視化と不正通信の制御とが可能となる。さらに、本実施の形態によれば、制御ロジックを他の端末装置１１との間で共有し合うことによって、検知及び制御の精度を向上することができる。
【０１０８】
［システム構成等］
図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部又は任意の一部が、ＣＰＵ及び当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【０１０９】
また、本実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行なうこともでき、あるいは、手動的に行なわれるものとして説明した処理の全部又は一部を公知の方法で自動的に行なうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【０１１０】
［プログラム］
図１１は、プログラムが実行されることにより、端末装置１０，１１が実現されるコンピュータの一例を示す図である。コンピュータ１０００は、例えば、メモリ１０１０、ＣＰＵ１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０、ネットワークインタフェース１０７０を有する。これらの各部は、バス１０８０によって接続される。
【０１１１】
メモリ１０１０は、ＲＯＭ１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic  Input  Output  System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１１００に挿入される。シリアルポートインタフェース１０５０は、例えばマウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、例えばディスプレイ１１３０に接続される。
【０１１２】
ハードディスクドライブ１０９０は、例えば、ＯＳ（Operating  System）１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、端末装置１０，１１の各処理を規定するプログラムは、コンピュータにより実行可能なコードが記述されたプログラムモジュール１０９３として実装される。プログラムモジュール１０９３は、例えばハードディスクドライブ１０９０に記憶される。例えば、端末装置１０，１１における機能構成と同様の処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０９０に記憶される。なお、ハードディスクドライブ１０９０は、ＳＳＤ（Solid  State  Drive）により代替されてもよい。
【０１１３】
また、上述した実施形態の処理で用いられる設定データは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して実行する。
【０１１４】
なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムモジュール１０９３及びプログラムデータ１０９４は、ネットワーク（ＬＡＮ、ＷＡＮ（Wide  Area  Network）等）を介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール１０９３及びプログラムデータ１０９４は、他のコンピュータから、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
【０１１５】
以上、本発明者によってなされた発明を適用した実施形態について説明したが、本実施形態による本発明の開示の一部をなす記述及び図面により本発明は限定されることはない。すなわち、本実施形態に基づいて当業者等によりなされる他の実施形態、実施例及び運用技術等は全て本発明の範疇に含まれる。
【符号の説明】
【０１１６】
１  通信システム
１０  端末装置
１１，１１Ａ，１１Ｂ  他の端末装置
１００  制御部
１０１  通信部
１０２  収集制御部
１０３  解析部
１０４  連携部
１０５  ユーザインタフェース（ＵＩ）部
２０  サーバ
４０，４０Ａ，４０Ｂ  ＩｏＴデバイス
ＮＷ−Ａ  外部ネットワーク
ＮＷ−Ｂ  ネットワーク
２００  記憶部
２０１  制御対象情報記憶部
２０２  制御条件記憶部
２０２  共有情報記憶部
【図１】
2020135655.tif 000003
【図２】
2020135655.tif 000004
【図３】
2020135655.tif 000005
【図４】
2020135655.tif 000006
【図５】
2020135655.tif 000007
【図６】
2020135655.tif 000008
【図７】
2020135655.tif 000009
【図８】
2020135655.tif 000010
【図９】
2020135655.tif 000011
【図１０】
2020135655.tif 000012
【図１１】
2020135655.tif 000013