JP2017139731A - 通信装置、ｄｎｓ処理方法、およびプログラム - Google Patents

Abstract

【課題】ユーザが意図しない通信の発生を低減できる通信装置、ＤＮＳ処理方法、およびプログラムを提供する。
【解決手段】ユーザの意図しないデータ通信が行われて、通信されるデータ量が意図せず増加することがあるので、データ通信可能な通信装置は、アプリケーションからネットワークへの接続要求を取得するステップと、前記接続要求元のアプリケーションのＩＤに応じて、前記接続要求に基づくＤＮＳ処理を制御するステップとを含む。
【選択図】図７

Description

本発明は、通信装置、ＤＮＳ処理方法、およびプログラムに関する。

従来、データ通信可能な携帯端末などの通信装置が知られている（例えば、特許文献１参照）。通信装置においては、通信装置上で稼働するアプリケーションによるデータ通信がデフォルトで許可される一方で、ユーザによって選択されたアプリケーションによるデータ通信のみが禁止されるという構成が採用されることがある。この場合、ユーザは、自らが把握できる範囲で、アプリケーションによるデータ通信を抑制できる。

特開２０１５−１６２７０１号公報

しかし、ユーザは、通信装置においてどのようなアプリケーションが稼働しているか完全に把握できるとは限らない。特に、通信装置のシステムのバックグラウンドで稼働するアプリケーションは、ユーザによって把握されない可能性が高い。よって、ユーザによって動作が把握されればデータ通信の禁止が選択されるような場合でも、ユーザによって動作が把握されないことによって、アプリケーションのデータ通信の禁止が選択されない場合がある。また、通信装置のシステムが行うデータ通信については、そもそも通信装置のシステム仕様として、ユーザが選択できないようになっている場合もある。これらの場合、ユーザの意図しないデータ通信が行われて、通信されるデータ量が意図せず増加することがある。

本発明は、ユーザが意図しない通信の発生を低減できる通信装置、ＤＮＳ処理方法、およびプログラムを提供することを目的とする。

本発明の一実施形態に係る通信装置は、
データ通信可能な通信装置であって、
アプリケーションからネットワークへの接続要求を取得すると、前記接続要求元の前記アプリケーションのＩＤに応じて、前記接続要求に基づくＤＮＳ処理を制御する。

また、本発明の一実施形態に係るＤＮＳ処理方法は、
データ通信可能な通信装置が実行するＤＮＳ処理方法であって、
アプリケーションからネットワークへの接続要求を取得するステップと、
前記接続要求元の前記アプリケーションのＩＤに応じて、前記接続要求に基づくＤＮＳ処理を制御するステップと、を含む。

また、本発明の一実施形態に係るプログラムは、
データ通信可能な通信装置に、
アプリケーションからネットワークへの接続要求を取得するステップと、
前記接続要求元の前記アプリケーションのＩＤに応じて、前記接続要求に基づくＤＮＳ処理を制御するステップと、を実行させる。

本発明の一実施形態に係る通信装置、ＤＮＳ処理方法、およびプログラムによれば、ユーザが意図しない通信の発生を低減できる。

第１実施形態に係る通信装置の概略構成例を示す機能ブロック図である。 第１実施形態に係る通信装置の一例の外観を示す図である。 第１実施形態に係るデータの流れの一例を示すブロック図である。 第１実施形態に係るフィルタリング処理のシーケンスを説明する図である。 アプリケーションからデータを送信するシーケンスの一例を説明する図である。 第１実施形態の比較例に係るフィルタリング処理のシーケンスを説明する図である。 第２実施形態に係るＤＮＳ処理のシーケンスを説明する図である。 第２実施形態の比較例に係るＤＮＳ処理のシーケンスを説明する図である。 第３実施形態に係るＤＮＳ処理のシーケンスを説明する図である。

（第１実施形態）
以下、一実施形態に係る通信装置について、図面を参照しながら詳細に説明する。本実施形態に係る通信装置は、携帯電話、またはスマートフォンなどの携帯機器とすることができる。しかしながら、本実施形態に係る通信装置は、携帯機器に限定されるものではなく、デスクトップＰＣ、ノートＰＣ、タブレット型ＰＣ、家電製品、産業用機器（ＦＡ機器）、専用端末など、データ通信を行う種々の電子機器とすることができる。

［装置構成］
図１は、本実施形態に係る通信装置１の概略構成例を示す機能ブロック図である。図１に示されるように、通信装置１は、制御部１０と、通信部１１と、記憶部１２と、表示部１３と、操作部１４とを備える。制御部１０は、通信部１１と、記憶部１２と、表示部１３と、操作部１４とに接続され、これらを制御する。

制御部１０は、オペレーティングシステム（以下、ＯＳともいう）、および、アプリケーションソフトウェア（以下、アプリケーションともいう）を実行可能なプロセッサまたはマイコンなどによって構成されうる。ＯＳは、例えばＡｎｄｒｏｉｄ（登録商標）である。アプリケーションについては後述する。

通信部１１は、セルラ通信、または無線ＬＡＮ通信などを行う通信インタフェースとして、Ｉ／Ｆ（インタフェース）デバイス１１１を備える。Ｉ／Ｆデバイス１１１は、モデム１１２と無線ＬＡＮデバイス１１３とを含む。通信部１１は、Ｉ／Ｆデバイス１１１を用いてインターネットなどのネットワーク側に接続され、ネットワーク側との間でデータ通信を行う。これによって、通信装置１はネットワーク側との間でデータ通信可能となる。通信部１１は、制御部１０に接続され、ネットワーク側へ出力するデータを制御部１０から取得する。制御部１０は、通信部１１に対して出力するデータをフィルタリング処理によって選択する。フィルタリング処理については後述する。また制御部１０は、ネットワーク側から受信したデータを通信部１１から取得する。

セルラ通信方式によってネットワーク側と接続される場合、一般的に、通信されるデータ（パケット）の量の増大に応じて通信料金が増大する従量課金制の料金体系が採用される。一方で、無線ＬＡＮ通信などの方式によってネットワーク側と接続される場合、一般的に、そのような料金体系ではない。

記憶部１２は、例えば半導体メモリなどによって構成されうる。記憶部１２には、各種情報およびデータ、ならびに、制御部１０が実行するＯＳおよびアプリケーションなどのプログラムが格納される。制御部１０は、記憶部１２に格納されたプログラムを実行する。制御部１０は、プログラムの実行によって生成されるデータを記憶部１２に格納する。また記憶部１２は、ワークメモリとしても機能しうる。

表示部１３は、制御部１０から取得した情報に基づき、文字、画像、操作用オブジェクト、ポインタなどを表示する。表示部１３は、例えば、液晶ディスプレイ、有機ＥＬディスプレイ、無機ＥＬディスプレイなどの表示デバイスであるが、これらに限られるものではない。

操作部１４は、テンキーなどの物理キー、タッチパッド、またはタッチパネルなどによって構成される。制御部１０は、操作部１４から取得した入力内容に応じて、表示部１３に表示されるポインタなどを移動させたり、操作用オブジェクトを選択したりする。

図２は、本実施形態に係る通信装置１の一例の外観を示す図である。図２に示す通り、本実施形態に係る通信装置１は、いわゆる折りたたみ式（フリップ型またはクラムシェル型など）のフィーチャーフォンである。通信装置１は、上部筐体２と下部筐体３とが、ヒンジ部４によって回動可能に接続される。上部筐体２は表示部１３を備え、下部筐体３は操作部１４を備える。操作部１４は、テンキーなどの物理キーの他、物理キーが設けられていない部位にタッチパッド１４１を備える。通信装置１は、例えば物理キーによって操作用のオブジェクトの選択操作を受け付け、またタッチパッド１４１によってポインタなどの移動操作を受け付ける。

［アプリケーション］
アプリケーションは、制御部１０で実行可能となるように通信装置１にインストールされ、記憶部１２に格納される。アプリケーションが通信装置１にインストールされる際、各アプリケーションに固有のユーザ識別子（以下、ＵＩＤともいう）が割り当てられる。アプリケーションは、制御部１０によって、ＯＳ上においてＵＩＤに対応づけられるプロセスとして実行される。

アプリケーションは、制御部１０で実行される際に、ファイルシステムなどのリソースに対してアクセスする。各アプリケーションが無制限にリソースにアクセスすると、各アプリケーションによるリソースの使用領域が重複することがあり、この場合アプリケーションが正常に実行されなくなることがある。そこで、ＯＳ上で実行されるプロセスに対応づけられるＵＩＤによってリソースに対するアクセスを制限し、アプリケーションによるリソース使用が互いに影響を及ぼさないようにする。つまり、各プロセスからアクセス可能なリソースは、同一のＵＩＤに対応づけられるプロセスのリソースに制限される。

各アプリケーションには、グループ識別子（以下、ＧＩＤまたはグループのＩＤともいう）がさらに割り当てられてもよい。ＧＩＤは、各アプリケーションに割り当てられる固有のＵＩＤが属するグループを特定するものである。一つのグループに一個のＵＩＤだけが属してもよいし、一つのグループに複数のＵＩＤが属してもよい。アプリケーションがＵＩＤに対応づけられるプロセスとして実行される際、このプロセスはＧＩＤにも対応づけられるようにしてもよい。また、各プロセスからアクセス可能なリソースは、同一のＵＩＤだけでなく同一のＧＩＤに対応づけられるプロセスのリソースにまで対象を広げて制限されるようにしてもよい。

アプリケーションは、フォアグラウンド（以下、ＦＧともいう）、または、バックグラウンド（以下、ＢＧともいう）で実行される。アプリケーションがＦＧで実行されている状態は、例えば、ユーザが確認可能なように実行状況が表示部１３に表示される、または、ユーザが操作部１４を用いて操作可能な状態である。アプリケーションがＢＧで実行されている状態は、例えば、実行状況が表示部１３に表示されず、ユーザが操作可能ではない状態、または、ユーザが意図せずに動作している状態である。

［データ通信の制御］
制御部１０によって実行されるアプリケーションは、通信部１１を用いて、インターネットなどのネットワーク側とのデータ通信を行う。上述の通り、アプリケーションはＯＳ上においてＵＩＤに対応づけられるプロセスとして実行される。そして、アプリケーションから送信されるデータにはＵＩＤが対応づけられる。制御部１０は、データに対応づけられたＵＩＤに基づいてデータの送信を許可するか禁止（制限）するか決定することによって、各アプリケーションから送信されるデータに係るデータ通信を許可するか禁止するか制御できる。以下、本実施形態に係る説明においては、データ通信は、原則的に通信部１１がネットワーク側との間で行うデータ通信のことを指すものとする。

図３は、本実施形態に係るデータの流れの一例を示すブロック図である。図３において、制御部１０と通信部１１とが端末側に設けられる。そして、通信部１１がネットワーク側と接続され、ネットワーク側との間でデータ通信を行う。

図３において、制御部１０は、アプリケーションＡ１６ａとアプリケーションＢ１６ｂとをＯＳ上におけるプロセスとして実行する。制御部１０によって実行されるアプリケーションは、必要に応じてネットワーク側とのデータ通信を要求する。例えば、アプリケーションＡ１６ａは、ネットワーク側へ向けてデータの送信を要求する。この場合、アプリケーションＡ１６ａからネットワーク側へ向けて送信するデータは、制御部１０で稼働するパケットフィルタ１５に入力される。また、アプリケーションＢ１６ｂからも同様に、アプリケーションＢ１６ｂからネットワーク側へ向けて送信するデータがパケットフィルタ１５に入力される。

パケットフィルタ１５は、制御部１０からネットワーク側へ向かうデータのフィルタリング処理を行う。フィルタリング処理は、設定されたフィルタリング条件に基づいて、アプリケーションから要求されたデータの送信を許可するか禁止するか決定する処理である。フィルタリング条件は、例えば、ｉｐ＿ｒｕｌｅまたはｉｐ＿ｒｏｕｔｅなどを含む。これらのフィルタリング条件は、記憶部１２に格納されており、パケットフィルタ１５によって参照される。以下、フィルタリング条件を設定する動作は、フィルタリング条件を記憶部１２に格納する動作を含むものとする。なお、フィルタリング条件は、記憶部１２に格納されずに制御部１０に保持されていてもよい。

ｉｐ＿ｒｕｌｅは、例えば、送信元がＸであるデータをネットワーク側へ送信してよいか決定するための条件を含む。ｉｐ＿ｒｏｕｔｅは、例えば、送信先としてＹが指定されたデータをネットワーク側へ送信するルート（中継ルータなど）を決定するための条件を含む。

図３において、アプリケーションＡ１６ａから送信されるデータの流れが実線の矢印で示され、アプリケーションＢ１６ｂから送信されるデータの流れが破線の矢印で示される。このうち、アプリケーションＡ１６ａから送信されるデータは、パケットフィルタ１５におけるフィルタリング処理によって送信が禁止されず、通信部１１に送られる。一方、アプリケーションＢ１６ｂから送信されるデータは、パケットフィルタ１５におけるフィルタリング処理によって送信が禁止され、通信部１１に送られない。この動作は、図３において破線の矢印がｒｅｊｅｃｔという記載に向けられることで示される。

パケットフィルタ１５を通過したデータ（図３の場合、実線の矢印で示されるアプリケーションＡ１６ａから送信されるデータ）は、通信部１１に入力される。通信部１１は、Ｉ／Ｆデバイス１１１を用いて、ネットワーク側へデータを送信する。通信部１１は、ネットワーク側へデータを送信するに際して、モデム１１２によるセルラ通信を用いるか、無線ＬＡＮデバイス１１３による無線ＬＡＮ通信を用いるか、または、他の通信方式を用いるか適宜決定しうる。

［フィルタリング処理］
アプリケーションから送信されるデータについてのデータ通信を許可するか禁止するかは、データ送信元のアプリケーションに割り当てられるＵＩＤに基づいて決定される。以下、ＵＩＤとしてＸが割り当てられるアプリケーション（以下、ＵＩＤがＸのアプリケーションともいう）から送信されるデータのことを、ＵＩＤがＸのデータともいう。また、ＵＩＤがＸのデータのフィルタリング処理を行うために用いられるフィルタリング条件を、ＵＩＤがＸのデータのフィルタリング条件ともいう。

パケットフィルタ１５は、例えば、ＵＩＤが１のアプリケーションから送信されるデータに係るデータ通信のみ許可するというフィルタリング条件を有する。また、フィルタリング条件は、複数の条件をあわせたものであってもよい。

ここで、本実施形態に係るフィルタリング処理が行われる場合のデータ通信のシーケンスを説明する。本実施形態に係るフィルタリング処理は、ＢＧ動作しているアプリケーションが送信するデータに係るデータ通信の許可または禁止を決定することを前提とする。以下の本実施形態に係るフィルタリング処理の説明は上記前提に基づく。

本実施形態に係るフィルタリング処理は、デフォルトでデータ通信を禁止するというフィルタリング条件（以下、デフォルト通信禁止条件ともいう）が設定されている。デフォルト通信禁止条件が設定されていることによって、他のフィルタリング条件がさらに設定されない限り、全てのデータ通信が禁止される。デフォルト通信禁止条件は、通信装置１の出荷時に設定されたり、通信装置１の初期化時に設定されたりする。すなわち、本実施形態において、「デフォルト」とは、所定のタイミング（例えば、通信装置１の出荷時、または通信装置１の初期化時など）で、標準の動作として予め設定されていることを意味するものとする。

本実施形態においては、必要なデータ通信を実行するために、デフォルト通信禁止条件に加えて、データ通信を許可するための条件（以下、通信許可条件ともいう）が設定されたフィルタリング条件が用いられる。この場合、通信許可条件は、デフォルト通信禁止条件に優先する。

図４は、本実施形態に係るフィルタリング処理のシーケンスを説明する図である。図４には、アプリケーションＡ１６ａ、アプリケーションＢ１６ｂ、フレームワーク、通信制御部、カーネル、およびモデム１１２のシーケンスが示されている。

モデム１１２は、上述の通り、セルラ通信を行う通信インタフェースとして機能するハードウェアである。図４においては、モデム１１２を用いたセルラ通信によるデータ通信について説明しているが、モデム１１２ではなく、無線ＬＡＮデバイス１１３などの他のＩ／Ｆデバイス１１１に置き換えて、他の通信方式によるデータ通信を行ってもよい。

カーネル、通信制御部、およびフレームワークはソフトウェアであり、制御部１０で実行される。図４において、通信制御部にはＵＩＤとして０が割り当てられる。

フレームワークは、ＯＳ上においてアプリケーションを動作させるための機能群を含むソフトウェアである。一般的に、フレームワークで準備された機能群を組み合わせることによって、各アプリケーションの機能が実現される。

カーネルは、ＯＳの中核をなすソフトウェアであり、アプリケーションなどのソフトウェアによる処理に基づき、通信部１１などのハードウェアにおける処理を管理して、ハードウェアの機能を利用できるようにする。

通信制御部は、ネットワーク関連の処理を行うデーモンプログラムであり、フレームワークとカーネルとの間をつなぐ処理をする。通信制御部は、特に、カーネルが通信部１１の機能を利用できるようにするためのデータを処理する。本実施形態において、通信制御部は、カーネルが通信部１１へのデータ出力を許可するか禁止するか決定するための条件をカーネルに出力する。

本実施形態において、フィルタリング処理はパケットフィルタ１５によって行われるものとして説明する。ここで、パケットフィルタ１５は仮想的な処理ユニットであり、実際のフィルタリング処理は、通信制御部とカーネルとによって行われる。

アプリケーションＡ１６ａおよびアプリケーションＢ１６ｂは、ＯＳ上において動作するプロセスである。図４において、アプリケーションＡ１６ａにはＵＩＤとして１が割り当てられ、アプリケーションＢ１６ｂにはＵＩＤとして２が割り当てられる。

以下、図４に示されるシーケンスを説明する。ＢＧ動作するアプリケーションがデータを送信する場合、デフォルトでセルラ通信によるデータ通信が禁止されている（ステップＳ１）。つまり、フィルタリング条件として、ＢＧ動作するアプリケーションから送信されるデータに係るデフォルト通信禁止条件が設定されている。図４において、デフォルト通信禁止条件が設定されていることは、カーネル、通信制御部、およびフレームワークによって認識されている。特に、カーネルは、デフォルト通信禁止条件が設定されていることを認識している場合、モデム１１２に対するデータの送信を行わない。

続いて、アプリケーションがＢＧで動作する場合のＵＩＤが１のデータに係るデータ通信の許可要求（以下、ＵＩＤが１のデータの通信許可要求ともいう）を、フレームワークが取得する（ステップＳ２）。続いて、フレームワークは、ＵＩＤが１のデータの通信許可要求を通信制御部に出力する（ステップＳ３）。

通信制御部は、ＵＩＤが１のデータの通信許可要求を取得する（ステップＳ４）。続いて通信制御部は、ＵＩＤが１のデータの通信許可要求をカーネルに出力する（ステップＳ５）。

カーネルは、ＵＩＤが１のデータの通信許可要求を取得する（ステップＳ６）。以上のステップＳ３〜Ｓ６の動作によって、カーネルにＵＩＤが１のデータの通信許可要求が伝達される。つまり、フィルタリング条件として、ＵＩＤが１のデータに係る通信許可条件が設定される。

続いて、アプリケーションＡ１６ａがＢＧ動作においてデータ通信を要求する場合（ステップＳ７）、カーネルは、ＵＩＤが１のデータに係る通信許可条件が設定されていることを認識しているので、データ通信を許可する（ステップＳ８）。そして、モデム１１２は、ＵＩＤが１のデータをネットワーク側へ送信するデータ通信を行う（ステップＳ９）。

一方、ＵＩＤとして２が割り当てられるアプリケーションＢ１６ｂがＢＧ動作においてデータ通信を要求する場合（ステップＳ１０）、カーネルは、ＵＩＤが２のデータに係る通信許可条件が設定されていないことを認識している。よって、カーネルは、デフォルト通信禁止条件に基づいて、データ通信を禁止する（ステップＳ１１）。

＜アプリケーションからのデータ送信シーケンス＞
図４のステップＳ７〜Ｓ９において、アプリケーションがデータ通信を要求してモデム１１２がデータ通信を行うことを説明した。以下、図５を用いて、これらのシーケンスをより具体的に説明する。図５には、アプリケーションＡ１６ａ、フレームワーク、カーネル、およびモデム１１２のシーケンスが示されている。アプリケーションＡ１６ａ、フレームワーク、カーネル、およびモデム１１２については、図４と同様であるため説明を省略する。

アプリケーションＡ１６ａは、ＦＧまたはＢＧのいずれで動作する場合であっても、アプリケーションＡ１６ａから送信されるデータ（ＵＩＤが１のデータ）に係るデータ通信の要求（以下、ＵＩＤが１のデータ通信要求ともいう）をアプリケーションＡ１６ａが動作しているＯＳ上のフレームワークに対して出力する（ステップＳ１０１）。

フレームワークは、ＵＩＤが１のデータ通信要求を取得する（ステップＳ１０２）。続いてフレームワークは、ＵＩＤが１のデータ通信要求をカーネルに出力する（ステップＳ１０３）。

カーネルは、ＵＩＤが１のデータ通信要求を取得する（ステップＳ１０４）。続いてカーネルは、モデム１１２に対してＵＩＤが１のデータ通信要求に基づいてデータを出力する（ステップＳ１０５）。そしてモデム１１２は、ＵＩＤが１のデータをネットワーク側へ送信するデータ通信を行う（ステップＳ１０６）。

以上説明してきた図５に示されるシーケンスの動作によって、アプリケーションから送信するデータが通信部１１に出力され、ネットワーク側へ送信される。

＜比較例＞
ここまで説明してきた本実施形態に係るフィルタリング処理によれば、デフォルト通信禁止条件に加えて、通信許可条件がユーザによって明示的に追加されるので、ユーザの意図しないデータ通信を禁止できる可能性が高くなる。以下、本実施形態の比較例に係るフィルタリング処理について説明する。比較例に係るフィルタリング処理で用いられるフィルタリング条件には、デフォルトで全てのデータに係るデータ通信を許可するという条件（以下、デフォルト通信許可条件ともいう）が設定される。このように全てのデータに係るデータ通信が許可された上で、ユーザによって指定されたＵＩＤのデータに係るデータ通信を禁止するという条件（以下、通信禁止条件ともいう）がさらに設定される。

図６は、比較例に係るフィルタリング処理のシーケンスを説明する図である。アプリケーションＡ１６ａ、アプリケーションＢ１６ｂ、フレームワーク、通信制御部、カーネル、およびモデム１１２については、図４および図５と同様であるため説明を省略する。

図６において、ＢＧ動作するアプリケーションがデータを送信する場合であっても、デフォルトでセルラ通信によるデータ通信が許可されている（ステップＳ２０１）。つまり、フィルタリング条件として、ＢＧ動作するアプリケーションから送信されるデータに係るデフォルト通信許可条件が設定されている。

続いて、アプリケーションＡ１６ａがＢＧ動作する場合におけるＵＩＤが１のデータに係るデータ通信の禁止要求（以下、ＵＩＤが１のデータの通信禁止要求ともいう）を、フレームワークが取得する（ステップＳ２０２）。この時点においては、アプリケーションＡ１６ａがＢＧ動作していないため、ＵＩＤが１のデータに係る通信禁止条件は設定されない。

続いて、アプリケーションＡ１６ａがＢＧ動作に移行した通知（以下、ＢＧ移行通知ともいう）をフレームワークが取得する（ステップＳ２０３）。通知を受けたフレームワークは、ＵＩＤが１のデータの通信禁止要求を通信制御部に出力する（ステップＳ２０４）。

通信制御部は、ＵＩＤが１のデータの通信禁止要求を取得する（ステップＳ２０５）。続いて通信制御部は、ＵＩＤが１のデータの通信禁止要求をカーネルに出力する（ステップＳ２０６）。

カーネルは、ＵＩＤが１のデータの通信禁止要求を取得する（ステップＳ２０７）。以上のステップＳ２０２〜Ｓ２０７の動作によって、カーネルにＵＩＤが１のデータの通信禁止要求が伝達される。つまり、フィルタリング条件として、ＵＩＤが１のデータに係る通信禁止条件が設定される。

続いて、アプリケーションＡ１６ａがＢＧ動作においてデータ通信を要求する場合（ステップＳ２０８）、カーネルは、ＵＩＤが１のデータに係る通信禁止条件が設定されていることを認識しているので、データ通信を禁止する（ステップＳ２０９）。

一方、ＵＩＤとして２が割り当てられるアプリケーションＢ１６ｂがＢＧ動作においてデータ通信を要求する場合（ステップＳ２１０）、カーネルは、ＵＩＤが２のデータに係る通信禁止条件が設定されていないことを認識している。よって、カーネルは、デフォルト通信許可条件に基づいて、データ通信を許可する（ステップＳ２１１）。そして、モデム１１２は、ＵＩＤが２のデータをネットワーク側へ送信するデータ通信を行う（ステップＳ２１２）。

以上、比較例に係るフィルタリング処理について説明してきた。比較例では、デフォルト通信許可条件が設定されているため、ユーザによって明示的に追加のフィルタリング条件が設定されていないアプリケーションＢ１６ｂのＢＧ動作におけるデータ通信は許可される。よって、ユーザがアプリケーションＢ１６ｂの動作を認識しない場合、ユーザが意図しないデータ通信が行われることがある。

一方、本実施形態においては、フィルタリング条件として、デフォルト通信禁止条件が設定される。その上で、ユーザが指定したＵＩＤのデータに係る通信許可条件がさらに設定される。この場合、デフォルトで全てのデータについてデータ通信が禁止されていることによって、ユーザが意図しないデータ通信を禁止できる可能性が高くなる。

以上、本実施形態およびその比較例に係るフィルタリング処理について説明してきた。本実施形態に係るフィルタリング処理においては、比較例に係るフィルタリング処理と異なり、デフォルトで全てのデータについてデータ通信が禁止されている。そして、ユーザによって明示的に、フィルタリング条件としてユーザが指定したＵＩＤのデータに係る通信許可条件が設定されることによって、ユーザが意図するデータ通信を可能としている。

以上のような構成をとる本実施形態に係るフィルタリング処理によれば、ユーザによって明示的にフィルタリング条件が設定されていないアプリケーションＢ１６ｂから送信されるデータに係るデータ通信を禁止できる。つまり、ユーザの意図しないデータ通信は禁止される可能性が高くなる。

本実施形態において、Ｉ／Ｆデバイス１１１としてモデム１１２を用いるセルラ通信方式によるデータ通信を禁止する方法について主に説明してきた。しかし、Ｉ／Ｆデバイス１１１はモデム１１２に限られず、無線ＬＡＮデバイス１１３などであってもよい。つまり、本実施形態に係る通信装置１のデータ通信の制御方法は、セルラ通信方式によるデータ通信に限られず、無線ＬＡＮ通信方式などの他の通信方式によるデータ通信においても適用されうる。

また本実施形態において、データ通信が許可されたデータを送信するために必要となる機能については、デフォルトでデータ通信を許可するようにしてもよい。デフォルトでデータ通信を許可される機能は、例えば、ＶＰＮ（Ｖｅｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）のトンネリング機能、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）の名前解決機能、またはテザリング機能などである。これらの機能に係るデータ通信は、ユーザが意図した場合に動作するものに限り、許可されてもよい。これらの機能に係るデータ通信を許可する条件は、デフォルト通信禁止条件に優先するフィルタリング条件として設定されてもよい。

また、本実施形態に係るフィルタリング処理は、ＢＧ動作しているアプリケーションのデータ通信について行われたが、これには限られず、ＦＧ動作しているアプリケーションのデータ通信について行われてもよい。つまり、本実施形態に係るフィルタリング処理は、ＦＧ動作しているアプリケーションが送信するデータに係るデータ通信の許可または禁止を決定してもよい。

（第２実施形態）
次に、本発明の第２実施形態に係る通信装置について説明する。上記の第１実施形態においては、アプリケーションのＩＤおよびフィルタリング条件に基づいてデータ通信を制御する構成について説明した。一方、第２実施形態に係る通信装置は、アプリケーションのＩＤおよびフィルタリング条件に基づいてＤＮＳ（Domain Name System）処理を制御する点で、第１実施形態と相違する。

第２実施形態に係る通信装置１は、第１実施形態と同様に、制御部１０と、通信部１１と、記憶部１２と、表示部１３と、操作部１４とを備える（図１参照）。以下の説明において、第１実施形態と同一の構成については、同一の符号を付し、説明は省略する。

まず、一般的なＤＮＳ処理（名前解決処理）の概略について説明する。例えばＯＳの提供者が提供するＯＳ（標準ＯＳ）がインストールされたスマートフォンなどの通信機器は、アプリケーションからネットワークへの接続要求（例えば、データ通信の要求）に応じてデータ通信を行うに際し、まずは当該接続要求に基づくＤＮＳ処理を実行する。具体的には、通信機器は、アプリケーションからネットワークへの接続要求を取得すると、ＤＮＳ処理を行うためのデータ、具体的にはアプリケーションからの要求に係るドメインを含むパケット（ＤＮＳ要求パケット）を、例えば外部のＤＮＳサーバへ送信する。続いて通信機器は、ＤＮＳサーバから応答データ、具体的にはアプリケーションからの要求に係るドメインに対応するＩＰアドレスを含むパケット（ＤＮＳ応答パケット）を取得する。このようにしてＤＮＳ処理が完了すると、通信機器は、取得されたＩＰアドレスに基づいてデータ通信を行う。以下、ＤＮＳ処理において通信機器とＤＮＳサーバとの間で行われる通信をＤＮＳデータ通信といい、ＤＮＳ処理の実行後に通信機器とネットワークとの間で行われるデータ通信と区別する。

＜第２実施形態に係るＤＮＳ処理＞
次に、図７を参照して、本実施形態に係る通信装置１において実行されるＤＮＳ処理について、具体的に説明する。ここで、本実施形態に係る通信装置１にインストールされたＯＳ（変更ＯＳ）は、上述した第１実施形態に係るＯＳに含まれる通信制御部およびカーネルそれぞれに、ＤＮＳ処理を制御するための特定のコード（特定コード）が追加されたＯＳである。あるいは、変更ＯＳは、第１実施形態に係るＯＳに含まれる通信制御部の一部のコードおよびカーネルの一部のコードそれぞれが、特定コードに修正されたＯＳであってもよい。あるいは、変更ＯＳは、標準ＯＳに対して、上述した特定コードの追加または修正が行われたＯＳであってもよい。

また、以下の説明おいて、アプリケーションがＦＧで動作するかＢＧで動作するかにかかわらずデフォルトで全てのアプリケーション（全てのＵＩＤおよびＧＩＤ）のセルラ通信によるデータ通信が禁止されており、例外としてデータ通信を許可するＩＤ（特定ＩＤ）が個別に追加設定される構成について例示する。例えば、特定ＩＤとして、通信制御部のＵＩＤ（ＵＩＤ＝０）を含むＤＮＳ処理に必要な全てのＵＩＤが予め設定されているが、特定ＩＤとして他のＵＩＤが追加で設定されてもよい。例えば、第１実施形態と同様に、通信装置１に対するユーザ入力に基づいて識別されたアプリケーションのＵＩＤが、特定ＩＤとして追加で設定されてもよい。

はじめに、アプリケーションＡ（ＵＩＤ＝１）は、ネットワークへの接続要求をフレームワークへ出力する（ステップＳ３００）。当該接続要求には、例えばアプリケーションＡのＵＩＤ（ＵＩＤ＝１）およびデータ通信先のドメインが含まれる。

次に、フレームワークは、ステップＳ３００でアプリケーションＡから出力された接続要求を取得すると（ステップＳ３０１）、ＤＮＳ処理要求を通信制御部へ出力する（ステップＳ３０２）。フレームワークから通信制御部へ出力される当該ＤＮＳ処理要求のＵＩＤは、アプリケーションＡのＵＩＤ（ＵＩＤ＝０）と同一である。

次に、通信制御部は、ステップＳ３０２でフレームワークから出力されたＤＮＳ処理要求（ＵＩＤ＝１）を取得する（ステップＳ３０３）。ＤＮＳ処理要求が取得されると、通信制御部は、カーネルへ出力するためのＤＮＳ処理要求のＵＩＤを、通信制御部のＵＩＤ（ＵＩＤ＝０）に定める。その後、上述のように通信制御部に追加された特定コード（第１特定コード）が実行される。

第１特定コードの実行によって、通信制御部は、カーネルへ出力するためのＤＮＳ処理要求のＵＩＤを、通信制御部のＵＩＤ（ＵＩＤ＝０）から、アプリケーションのＵＩＤ（ＵＩＤ＝１）に変更する（ステップＳ３０４）。すなわち、通信制御部に追加された第１特定コードの実行によって、カーネルへ出力するためのＤＮＳ処理要求のＵＩＤが、通信制御部のＵＩＤ（ＵＩＤ＝０）ではなく、アプリケーションＡのＵＩＤ（ＵＩＤ＝１）に定められる。そして、通信制御部は、第１特定コードの実行によってＵＩＤが変更（決定）されたＤＮＳ処理要求（ＵＩＤ＝１）を、カーネルへ出力する（ステップＳ３０５）。

次に、カーネルは、ステップＳ３０５で通信制御部から出力されたＤＮＳ処理要求（ＵＩＤ＝１）を取得する（ステップＳ３０６）。その後、上述のようにカーネルに追加された特定コード（第２特定コード）が実行される。

第２特定コードの実行によって、カーネルは、以下の動作を行う。はじめにカーネルは、通信制御部から取得されたＤＮＳ処理要求のＵＩＤ（ＵＩＤ＝１）が特定ＩＤであるか否かを判定する（ステップＳ３０７）。ＵＩＤが特定ＩＤではないと判定された場合（ステップＳ３０７−Ｎｏ）、カーネルは、ＤＮＳ処理を抑制（終了）して（ステップＳ３０８）、例えばエラーを返す。一方、ＵＩＤが特定ＩＤであると判定された場合（ステップＳ３０７−Ｙｅｓ）、カーネルは、ＤＮＳ処理要求をモデム１１２へ出力する（ステップＳ３０９）。

そして、モデム１１２は、ステップＳ３０９でカーネルから出力されたＤＮＳ処理要求を取得すると（ステップＳ３１０）、ＤＮＳデータ通信を行う（ステップＳ３１１）。具体的には、モデム１１２は、ＤＮＳ要求パケットをＤＮＳサーバへ出力し、ＤＮＳサーバからＤＮＳ応答パケットを取得する。このようにしてＤＮＳ処理（名前解決）が完了すると、通信装置１は、アプリケーションからの要求に応じたデータ通信を開始する。

このように、第２実施形態に係る通信装置１によれば、特定ＩＤと一致するアプリケーションに対しては、ＤＮＳデータ通信（およびデータ通信）が許可される。一方、特定ＩＤと一致しないアプリケーションに対しては、ＤＮＳ処理が抑制される。ＤＮＳ処理が抑制されることによって、ＤＮＳデータ通信（およびデータ通信）が発生しないため、例えば上述した第１実施形態と比較して、ＤＮＳデータ通信が発生しない分、ユーザが意図しない通信の発生がさらに低減可能である。また、特定ＩＤと一致しないアプリケーションに対しては、カーネルからモデム１１２へＤＮＳ処理要求が出力されない。このため、例えばモデム１１２がドーマント状態である場合に、モデム１１２を起動させるための電力が消費されることが抑制可能である。

＜比較例に係るＤＮＳ処理＞
次に、図８を参照して、第２実施形態の比較例に係るＤＮＳ処理について説明する。比較例に係る通信装置１が行うＤＮＳ処理においては、上述した変更ＯＳのうち、第１特定コードの実行が抑制される。

はじめに、アプリケーションＡ（ＵＩＤ＝１）は、ネットワークへの接続要求をフレームワークへ出力する（ステップＳ４００）。当該接続要求には、例えばアプリケーションＡのＵＩＤ（ＵＩＤ＝１）およびデータ通信先のドメインが含まれる。

次に、フレームワークは、ステップＳ４００でアプリケーションＡから出力された接続要求を取得すると（ステップＳ４０１）、ＤＮＳ処理要求を通信制御部へ出力する（ステップＳ４０２）。フレームワークから通信制御部へ出力される当該ＤＮＳ処理要求のＵＩＤは、アプリケーションＡのＵＩＤ（ＵＩＤ＝０）と同一である。

次に、通信制御部は、ステップＳ４０２でフレームワークから出力されたＤＮＳ処理要求（ＵＩＤ＝１）を取得する（ステップＳ４０３）。ＤＮＳ処理要求が取得されると、通信制御部は、カーネルへ出力するためのＤＮＳ処理要求のＵＩＤを、通信制御部のＵＩＤ（ＵＩＤ＝０）に定める。

上述したステップＳ４００−ステップＳ４０３は、第２実施形態に係るＤＮＳ処理におけるステップＳ３００−ステップＳ３０３とそれぞれ同一である。

続いて、第１特定コードが実行されることなく、すなわちカーネルへ出力するためのＤＮＳ処理要求のＵＩＤが変更されることなく、通信制御部は、ＤＮＳ処理要求（ＵＩＤ＝０）をカーネルへ出力する（ステップＳ４０４）。

次に、カーネルは、ステップＳ４０４で通信制御部から出力されたＤＮＳ処理要求（ＵＩＤ＝０）を取得する（ステップＳ４０５）。その後、上述のようにカーネルに追加された特定コード（第２特定コード）が実行される。ここでは、通信制御部は、取得されたＤＮＳ処理要求のＵＩＤ（ＵＩＤ＝０）が特定ＩＤであると判定する（ステップＳ４０６）。そして、カーネルは、ＤＮＳ処理要求をモデム１１２へ出力する（ステップＳ４０７）。

そして、モデム１１２は、ステップＳ４０７でカーネルから出力されたＤＮＳ処理要求を取得すると（ステップＳ４０８）、ＤＮＳデータ通信を行う（ステップＳ４０９）。

このように、比較例に係るＤＮＳ処理においては、上述した第１特定コードが実行されないため、データ通信を禁止すべきアプリケーションからの要求であっても、ＤＮＳデータ通信が発生してしまう。すなわち、比較例において、通信制御部からカーネルへ出力されるＤＮＳ処理要求のＵＩＤが通信制御部のＵＩＤ（ＵＩＤ＝０）と同一であるため、カーネルは、通信制御部から取得されたＤＮＳ処理要求に基づいてアプリケーションのＵＩＤを識別できず、アプリケーションのＵＩＤに応じたＤＮＳ処理の制御を実行できない。

しかしながら、比較例に係る通信装置１によれば、データ通信を禁止するアプリケーションからの要求に応じて、上述のようにＤＮＳデータ通信が発生してしまうものの、ＤＮＳ処理の完了後のデータ通信については、第１実施形態と同様に禁止される。したがって、第１実施形態と同様に、ユーザが意図しない通信の発生が低減可能である。

以上述べたように、第２実施形態に係る通信装置１は、アプリケーションからネットワークへの接続要求を取得すると、当該アプリケーションのＩＤ（例えば、ＵＩＤ）に応じて、当該接続要求に基づくＤＮＳ処理を制御する。かかる構成によって、例えばデータ通信を禁止するアプリケーションからの要求に対しては、データ通信に加えて、ＤＮＳデータ通信も禁止可能である。したがって、データ通信を禁止するアプリケーションからの要求に対して、データ通信およびＤＮＳデータ通信の双方が発生しないため、例えば第１実施形態と比較して、ユーザが意図しない通信の発生がさらに低減可能である。また、データ通信を禁止するアプリケーションに対しては、第２特定コードの実行によってカーネルがＤＮＳ処理を抑制するので、カーネルからモデム１１２へＤＮＳ処理要求が出力されない。このため、例えばモデム１１２がドーマント状態（休止状態）である場合に、モデム１１２をドーマント状態から復帰させるための電力が消費されることが抑制可能である。

（第３実施形態）
次に、本発明の第３実施形態に係る通信装置１について説明する。上記の第２実施形態においては、通信制御部およびカーネルにそれぞれ追加された特定コードの実行によってＤＮＳ処理を制御する構成について説明した。一方、第３実施形態に係る通信装置１は、フレームワークに追加された特定コードの実行によってＤＮＳ処理を制御する点で、第２実施形態と相違する。

第３実施形態に係る通信装置１は、第１実施形態および第２実施形態と同様に、制御部１０と、通信部１１と、記憶部１２と、表示部１３と、操作部１４とを備える（図１参照）。以下の説明において、第１実施形態および第２実施形態と同一の構成については、同一の符号を付し、説明は省略する。

＜第３実施形態に係るＤＮＳ処理＞
図９を参照して、本実施形態に係る通信装置１において実行されるＤＮＳ処理について、具体的に説明する。ここで、本実施形態に係る通信装置１にインストールされたＯＳ（変更ＯＳ）は、上述した第１実施形態に係るＯＳに含まれるフレームワークに、ＤＮＳ処理を制御するための特定コード（第３特定コード）が追加されたＯＳである。あるいは、変更ＯＳは、第１実施形態に係るＯＳに含まれるフレームワークの一部のコードが、第３特定コードに修正されたＯＳであってもよい。あるいは、変更ＯＳは、標準ＯＳに対して、上述した第３特定コードの追加または修正が行われたＯＳであってもよい。

また、以下の説明おいて、アプリケーションがＦＧで動作するかＢＧで動作するかにかかわらずデフォルトで全てのアプリケーション（全てのＵＩＤおよびＧＩＤ）のセルラ通信によるデータ通信が禁止されており、例外としてデータ通信を許可するＩＤ（特定ＩＤ）が個別に追加設定される構成について例示する。例えば、特定ＩＤとして、通信制御部のＵＩＤ（ＵＩＤ＝０）が予め設定されているが、特定ＩＤとして他のＵＩＤが追加で設定されてもよい。例えば、通信装置１に対するユーザ入力に基づいて識別されたアプリケーションのＵＩＤが、特定ＩＤとして追加で設定されてもよい。

はじめに、アプリケーションＡ（ＵＩＤ＝１）は、ネットワークへの接続要求をフレームワークへ出力する（ステップＳ５００）。当該接続要求には、例えばアプリケーションＡのＵＩＤ（ＵＩＤ＝１）およびデータ通信先のドメインが含まれる。

次に、フレームワークは、ステップＳ５００でアプリケーションＡから接続要求を取得する（ステップＳ５０１）。その後、上述のようにフレームワークに追加された第３特定コードが実行される。

第３特定コードの実行によって、フレームワークは、アプリケーションＡから取得された接続要求のＵＩＤが特定ＩＤであるか否かを判定する（ステップＳ５０２）。ＵＩＤが特定ＩＤではないと判定された場合（ステップＳ５０２−Ｎｏ）、フレームワークは、ＤＮＳ処理を抑制（終了）して（ステップＳ５０３）、例えばエラーを返す。一方、ＵＩＤが特定ＩＤであると判定された場合（ステップＳ５０２−Ｙｅｓ）、フレームワークは、ＤＮＳ処理要求（ＵＩＤ＝１）をモデム１１２へ出力する（ステップＳ５０４）。

ステップＳ５０４でフレームワークからＤＮＳ処理要求（ＵＩＤ＝１）が出力されると、通信制御部は、当該ＤＮＳ処理要求を取得する（ステップＳ５０５）。ＤＮＳ処理要求が取得されると、通信制御部は、カーネルへ出力するためのＤＮＳ処理要求のＵＩＤを、通信制御部のＵＩＤ（ＵＩＤ＝０）に定める。続いて、通信制御部は、ＤＮＳ処理要求（ＵＩＤ＝０）をカーネルへ出力する（ステップＳ５０６）。

次に、カーネルは、ステップＳ５０６で通信制御部から出力されたＤＮＳ処理要求（ＵＩＤ＝０）を取得すると（ステップＳ５０７）、ＤＮＳ処理要求をモデム１１２へ出力する（ステップＳ５０８）。

そして、モデム１１２は、ステップＳ５０８でカーネルから出力されたＤＮＳ処理要求を取得すると（ステップＳ５０９）、ＤＮＳデータ通信を行う（ステップＳ５１０）。

このように、第３実施形態に係る通信装置１によれば、特定ＩＤと一致するアプリケーションに対しては、ＤＮＳデータ通信（およびデータ通信）が許可される。一方、特定ＩＤと一致しないアプリケーションに対しては、ＤＮＳ処理が抑制される。ＤＮＳ処理が抑制されることによって、ＤＮＳデータ通信およびデータ通信が発生しないため、上述した第２実施形態と同様に、ユーザが意図しない通信の発生がさらに低減可能である。また、特定ＩＤと一致しないアプリケーションに対しては、カーネルからモデム１１２へＤＮＳ処理要求が出力されない。このため、第２実施形態と同様に、例えばモデム１１２がドーマント状態である場合に、モデム１１２を起動させるための電力が消費されることが抑制可能である。

本発明を諸図面や実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形や修正を行うことが容易であることに注意されたい。したがって、これらの変形や修正は本発明の範囲に含まれることに留意されたい。例えば、各構成部、各ステップなどに含まれる機能などは論理的に矛盾しないように再配置可能であり、複数の構成部やステップなどを１つに組み合わせたり、あるいは分割したりすることが可能である。また、本発明について装置を中心に説明してきたが、本発明は装置の各構成部が実行するステップを含む方法としても実現し得るものである。また、本発明について装置を中心に説明してきたが、本発明は装置が備えるプロセッサによって実行される方法、プログラム、またはプログラムを記録した記憶媒体としても実現し得るものであり、本発明の範囲にはこれらも包含されるものと理解されたい。

例えば、上述した実施形態において、ＵＩＤに基づいてＤＮＳ処理が制御される構成について説明したが、ＵＩＤに限られず、例えばＧＩＤに基づいてＤＮＳ処理が制御される構成であってもよい。

また、上述した第２実施形態および第３実施形態において、アプリケーションがＦＧで動作するかＢＧで動作するかにかかわらずデフォルトで全てのアプリケーション（全てのＵＩＤおよびＧＩＤ）のセルラ通信によるデータ通信が禁止されており、例外としてデータ通信を許可するＩＤ（特定ＩＤ）が個別に追加設定される構成について説明したが、ＵＩＤまたはＧＩＤを用いてアプリケーションのデータ通信を禁止する構成はこれに限られない。例えば、デフォルトで全てのアプリケーションのセルラ通信によるデータ通信が許可されており、例外としてデータ通信を禁止するＩＤが個別に追加設定される構成であってもよい。また例えば、アプリケーションがＦＧ（またはＢＧ）で動作する場合に限定して、上述のようにアプリケーションのセルラ通信を禁止または許可する構成であってもよい。具体的には、ＢＧ（またはＦＧ）で動作する全てのアプリケーションのセルラ通信をデフォルトで禁止（または許可）する構成であってもよい。

また、上述した第３実施形態において、フレームワークに第３特定コードを追加する構成について説明したが、通信制御部に特定コード（第４特定コード）が追加される構成であってもよい。かかる構成において、通信制御部は、アプリケーション（ＵＩＤ＝ｎ）からの接続要求に応じてフレームワークから出力されたＤＮＳ処理要求（ＵＩＤ＝ｎ）を取得する。その後、第４特定コードが実行される。第４特定コードの実行によって、通信制御部は、取得されたＤＮＳ処理要求のＵＩＤが特定ＩＤであるか否かを判定する。そして、通信制御部は、ＵＩＤが特定ＩＤではないと判定された場合にＤＮＳ処理を抑制し、ＵＩＤが特定ＩＤであると判定された場合にＤＮＳ処理要求をカーネルへ出力する。かかる構成によっても、第３実施形態と同様に、ユーザが意図しない通信の発生がさらに低減可能である。また、第３実施形態と同様に、モデム１１２がドーマント状態である場合に、モデム１１２を起動させるための電力が消費されることが抑制可能である。

上記の実施形態では、従量課金制ではない方式によるデータ通信の方式として無線ＬＡＮを例示したが、これに限定されず、従量課金制ではない方式は、Ｂｌｕｅｔｏｏｔｈ（登録商標）やＥｔｈｅｒｎｅｔ（登録商標）等のデータ通信方式であってもよい。

１ 通信装置
１０ 制御部
１１ 通信部
１１１ Ｉ／Ｆデバイス
１１２ モデム
１１３ 無線ＬＡＮデバイス
１２ 記憶部
１３ 表示部
１４ 操作部
１４１ タッチパッド
１５ パケットフィルタ
１６ａ、１６ｂ アプリケーション
１７ 接続機能部
１８ ＶＰＮデバイス

本発明の一実施形態に係る通信装置は、
データ通信可能な通信装置であって、
アプリケーションからネットワークへの接続要求を取得すると、前記接続要求元の前記アプリケーションのＩＤが、データ通信が許可された特定ＩＤであるか否かを判定し、
前記アプリケーションのＩＤが特定ＩＤではないと判定された場合に、前記接続要求に基づくＤＮＳデータ通信を抑制する。

また、本発明の一実施形態に係るＤＮＳ処理方法は、
データ通信可能な通信装置が実行するＤＮＳ処理方法であって、
アプリケーションからネットワークへの接続要求を取得するステップと、
前記接続要求元の前記アプリケーションのＩＤが、データ通信が許可された特定ＩＤであるか否かを判定するステップと、
前記アプリケーションのＩＤが特定ＩＤではないと判定された場合に、前記接続要求に基づくＤＮＳデータ通信を抑制するステップと、を含む。

また、本発明の一実施形態に係るプログラムは、
データ通信可能な通信装置に、
アプリケーションからネットワークへの接続要求を取得するステップと、
前記接続要求元の前記アプリケーションのＩＤが、データ通信が許可された特定ＩＤであるか否かを判定するステップと、
前記アプリケーションのＩＤが特定ＩＤではないと判定された場合に、前記接続要求に基づくＤＮＳデータ通信を抑制するステップと、を実行させる。

Claims (7)

1. データ通信可能な通信装置であって、
   アプリケーションからネットワークへの接続要求を取得すると、前記接続要求元の前記アプリケーションのＩＤに応じて、前記接続要求に基づくＤＮＳ処理を制御する、通信装置。
2. 請求項１に記載の通信装置であって、
   前記アプリケーションのＩＤが特定ＩＤであるか否かを判定し、
   前記アプリケーションのＩＤが特定ＩＤであると判定された場合に、ＤＮＳ処理を許可し、
   前記アプリケーションのＩＤが特定ＩＤではないと判定された場合に、ＤＮＳ処理を抑制する、通信装置。
3. 請求項２に記載の通信装置であって、
   前記通信装置に対するユーザ入力に基づいてＩＤを識別し、識別されたＩＤを特定ＩＤに定める、通信装置。
4. 請求項２または３に記載の通信装置であって、
   前記通信装置のＯＳに追加されたコードの実行によって、前記アプリケーションのＩＤが特定ＩＤであるか否かを判定する、通信装置。
5. 請求項４に記載の通信装置であって、
   前記アプリケーションから接続要求を取得すると、
   前記ＯＳに含まれる通信制御部に追加されたコードの実行によって、ＤＮＳ処理要求のＩＤを前記アプリケーションのＩＤに定めて、前記ＤＮＳ処理要求を前記ＯＳに含まれるカーネルへ出力し、
   前記カーネルに追加されたコードの実行によって、前記ＤＮＳ処理要求に基づき、前記アプリケーションのＩＤが特定ＩＤであるか否かを判定する、通信装置
6. データ通信可能な通信装置が実行するＤＮＳ処理方法であって、
   アプリケーションからネットワークへの接続要求を取得するステップと、
   前記接続要求元の前記アプリケーションのＩＤに応じて、前記接続要求に基づくＤＮＳ処理を制御するステップと、
   を含む、ＤＮＳ処理方法。
7. データ通信可能な通信装置に、
   アプリケーションからネットワークへの接続要求を取得するステップと、
   前記接続要求元の前記アプリケーションのＩＤに応じて、前記接続要求に基づくＤＮＳ処理を制御するステップと、
   を実行させる、プログラム。

Images