JP7463095B2 - 通信装置、通信装置の制御方法及びプログラム - Google Patents

Description

本発明は、外部にデータを送信する通信装置に関するものである。

近年、ネットワークに求められるセキュリティや、機能性の複雑化に伴い、オフィスや商業施設などで複数のＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）を使い分ける構成が一般的になってきた。

これらのネットワークは、各ネットワークが分離されており、それぞれ独立でドメイン名を管理したりする。このようなネットワーク環境下において使用されるＭＦＰなどの通信装置に対しても、複数のネットワークに対応できることが求められてきている。

特許文献１には、クライアント通信端末が複数のドメイン名管理が行われているネットワークに接続された環境において、ドメイン名の名前解決を効率的に行う方法が開示されている。

特開２０１０－１９３０１５号公報

まず、一般的なＬＡＮインタフェースにおける名前解決の実現方法の一例をＬｉｎｕｘ（登録商標）システムの制御を例に説明する。Ｌｉｎｕｘシステムにおいて、ドメイン名の名前解決を行う場合は所定のファイルにＤＮＳサーバの記載を行ってＤＮＳサーバを指定する。具体的には、「／ｅｔｃ／ｒｅｓｏｌｖｅ．ｃｏｎｆ」に位置するファイルに対して、「ｎａｍｅｓｅｒｖｅｒ “ＤＮＳサーバのＩＰアドレス“」といった記載を行うことで利用するＤＮＳサーバを指定することができる。また、冗長化のため、ＤＮＳサーバを複数台指定することもできる。この場合「ｃｏｎｆ」ファイル内に同様の記載をＤＮＳサーバの数だけ記載すればよい。

しかしながら、ここで登録するＤＮＳサーバは、登録されたＤＮＳサーバから応答がない場合に代替で利用する冗長化のためのＤＮＳサーバである。そのため、ＤＮＳ名前解決を行った結果、該当する名前が見つからない場合（即ち、サーバへの通信は成功し、名前解決に失敗した場合）は、代替で利用するＤＮＳサーバへの問い合わせは行わない。すなわち、Ｌｉｎｕｘシステムなどの一般的なＤＮＳクライアントを利用する場合、それぞれのネットワークのＤＮＳ名前解決を実現することが困難であるという課題がある。

また、特許文献１には、複数のネットワークインタフェースを備え、一方が広域網、他方が閉域網に接続されている通信装置が記載されている。また、特許文献１の通信装置は、ネットワークインタフェース毎に名前解決に使用するＤＮＳサーバを管理する。通信装置は、広域網のＤＮＳサーバに問い合わせを試行し、ＩＰアドレスが取得できれば広域網であり、ＩＰアドレスが取得できなければ閉域網であると判断し、判断結果をネットワークリストに記憶し、当該ネットワークリストを用いて名前解決を実現する。

しかしながら、各ネットワークに送信するデータを確実に分離したい場合、特許文献１のように問い合わせを試行すること自体が許容されない場合がある。例えば、一方のネットワークが機密性の高いネットワークであり、当該ネットワークで管理されているドメイン名が他方のネットワーク上で傍受可能となること自体が許容されない場合がある。

本発明は上述の問題点の少なくとも１つを鑑みなされたものである。本発明の１つの側面としては、通信装置をＤＮＳキャッシュサーバとして機能させ、名前解決のＤＮＳサーバを適切に切り替える仕組みを提供することを目的の１つとする。また、本発明の別の側面としては、ＤＮＳキャッシュサーバに、ドメイン名と問合せ先のＤＮＳサーバの対応関係を登録し、当該ＤＮＳキャッシュサーバを活用して名前解決先のＤＮＳサーバを異ならせる仕組みを提供することを目的の１つとする。

上記の少なくとも１つの目的を達成するために本発明の通信端末は、複数の異なる通信インタフェースを介して外部にデータを送信可能な通信装置であって、ドメイン名と、当該ドメイン名に対応するドメインに属する外部装置との通信に利用すべき通信インタフェースの対応関係の登録を受け付ける受付手段と、前記登録された対応関係に基づいて、ドメイン名と、当該ドメイン名に対応するドメインに属する外部装置のホスト名の名前解決を転送すべきＤＮＳサーバの対応関係を示す設定を生成する生成手段と、ＤＮＳキャッシュサーバを起動する起動手段と、を有し、
前記起動手段によって起動された前記ＤＮＳキャッシュサーバは、前記生成手段で生成された設定に基づき動作し、前記通信装置が有するアプリケーションから名前解決を依頼されたＤＮＳクライアントは、前記起動手段で起動したＤＮＳキャッシュサーバに名前解決の依頼を送信し、前記ＤＮＳキャッシュサーバは、受信した前記名前解決の依頼に含まれるホスト名に基づいて、名前解決を依頼する外部のＤＮＳサーバを決定し、当該決定したＤＮＳサーバに名前解決を依頼することを特徴とする。

本発明の１つの側面によれば、通信装置をＤＮＳキャッシュサーバとして機能させることで、名前解決のＤＮＳサーバを適切に切り替えることができるようになる。また、本発明の１つの側面によれば、ＤＮＳキャッシュサーバに、ドメイン名と問合せ先のＤＮＳサーバの対応関係を登録し、当該ＤＮＳキャッシュサーバが当該対応関係を用いて名前解決先のＤＮＳサーバを適切に切り替えることができるようになる。

通信システムの一例を示す図である。 ＭＦＰ２００のハードウェア構成の一例を示す図である。 ＭＦＰ２００のソフトウェア構成の一例を示す図である。 ＭＦＰ２００の制御の一例を示すフローチャートである。 ＭＦＰ２００の制御の一例を示すフローチャートである。 ネットワークに関する設定画面の一例を示す図である。 設定値ＤＢの設定と生成される設定ファイルの一例を説明する図である。 第２の実施形態におけるＭＦＰ２００のソフトウェア構成の一例を示す図である。 第２の実施形態におけるＭＦＰ２００の制御の一例を示すフローチャートである。 第２の実施形態におけるネットワークに関する設定画面の一例を示す図である。 第３の実施形態におけるネットワークに関する設定画面の一例を示す図である。 第３の実施形態におけるＭＦＰ２００の制御の一例を示すフローチャートである。 第４の実施形態を説明する図である。 第４の実施形態におけるＭＦＰ２００の制御の一例を示すフローチャートである。

以下、本発明を実施するための実施形態について図面を用いて説明する。なお、以下の実施の形態は特許請求の範囲に係る発明を限定するものではなく、また、実施の形態で説明されている特徴の組み合わせのすべてが発明の解決手段に必須のものとは限らない。

＜第１の実施形態＞
まず、図１を用いて、本発明に係る通信システムの構成を説明する。本実施形態に係る通信システムには、ＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）２００、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバ１００、デバイス１２０がネットワーク３００を介して通信可能に接続されている。デバイス１２０には、ＤＮＳサーバ１００で管理されるホスト名が割り振られている。また、ＭＦＰ２００と、ＤＮＳサーバ１１０、デバイス１３０がネットワーク３１０を介して通信可能に接続されている。デバイス１３０には、ＤＮＳサーバ１１０で管理されるホスト名が割り振られている。

本実施形態では、ネットワーク３００とネットワー３１０は、独立した異なるネットワークである場合を想定している。すなわち、ＤＮＳサーバ１００にデバイス１３０のホスト名の解決を依頼しても、当該名前解決は行えない。逆に、ＤＮＳサーバ１１０にデバイス１２０のホスト名の解決を依頼しても当該名前解決は行えない。

ＭＦＰ２００は、通信端末の一例である。本実施形態では、一例として印刷機能やスキャン機能を有するＭＦＰを例示しているがこれに限定されず、ＩｏＴデバイスやパーソナルコンピューター、エッジサーバなどに適用することもできる。また、デバイス１２０やデバイス１３０は、例えばファイルサーバや、ＭＦＰ２００の情報を管理する情報管理サーバなどを想定している。しかしながらこれに限定されるものではなく、基幹業務システムのサーバやクラウドサーバなどであってもよい。

ＭＦＰ２００は、デバイス１２０や１３０にスキャンして得られた画像に基づくデータを送信したり、ＭＦＰ２００が収集したデータを送信したりすることができる。データを送信する際に、ＭＦＰ２００は、デバイス１２０や１３０のホスト名を指定した宛先を用いて送信を行う。この際の名前解決の方法については、後述する。

続けて、図２を用いて、ＭＦＰ２００について説明する。図２は、ＭＦＰ２００のハードウェア構成を示すブロック図である。ＭＦＰ２００はシート上の画像を読み取る読取機能、当該読み取った画像を外部の通信装置に送信可能なファイル送信機能などを有している。また、シートに画像を印刷する印刷機能も有する。

ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０２を含む制御部２０１は、ＭＦＰ２００全体の動作を制御する。ＣＰＵ２０２は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０４又はストレージ２０５に記憶された制御プログラムを読み出して、印刷制御や読取制御などの各種制御を行う。ＲＯＭ２０４は、ＣＰＵ２０２で実行可能な制御プログラムを格納する。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３は、ＣＰＵ２０２の主記憶メモリであり、ワークエリア又は各種制御プログラムを展開するための一時記憶領域として用いられる。ストレージ２０５は、印刷データ、画像データ、各種プログラム、及び各種設定情報を記憶する。このように、ＣＰＵ２０２、ＲＯＭ２０４、ＲＡＭ２０３等のハードウェアは、いわゆるコンピュータを構成している。

なお、本実施形態のＭＦＰ２００では、１つのＣＰＵ２０２が１つのメモリ（ＲＡＭ２０３）を用いて後述するフローチャートに示す各処理を実行するものとするが、他の様態であっても構わない。例えば複数のプロセッサ、メモリ、及びストレージを協働させて後述するフローチャートに示す各処理を実行することもできる。また、ハードウェア回路を用いて一部の処理を実行するようにしてもよい。

プリンタＩ／Ｆ２０６は、プリンタ２０７（プリンタエンジン）と制御部２０１とを接続する。プリンタ２０７は、プリンタＩ／Ｆ２０６を介して入力された印刷データに基づいて、不図示の給紙カセットから給紙されたシートに画像を印刷する。印刷の方式はトナーを紙に転写して定着させる電子写真方式であってもよいし、紙にインクを吐出して印刷するインクジェット方式であってもよい。また、プリンタ２０７は造形材料を用いて３次元形状の出力物を生成する３Ｄプリンタであってもよい。この場合、印刷データは３Ｄ形状を示す印刷データとなり、トナーやインク等の色材に代えて造形材やサポート材を用いて３次元形状の出力物を生成する。

スキャナＩ／Ｆ２０８は、スキャナ２０９と制御部２０１とを接続する。スキャナ２０９は、載置された原稿を読み取り、そして画像データを生成する。スキャナ２０９が生成した画像データは、プリンタ２０７で印刷されたり、ストレージ２０５に記憶されたり、ＦＡＸ Ｉ／Ｆ２１４や通信Ｉ／Ｆ２１２、２１３を介して外部装置に送信されたりする。

操作パネルＩ／Ｆ２１０は、操作パネル２１１と制御部２０１とを接続する。操作パネル２１１には、タッチパネル機能を有する液晶表示部や各種ハードキーなどが備えられ、情報を表示する表示部やユーザの指示を受け付ける受付部として機能する。ＣＰＵ２０２は、操作パネル２１１と協働して情報の表示制御やユーザ操作の受け付け制御を行う。

通信Ｉ／Ｆ２１２、２１３には、ネットワークケーブルが接続され、外部装置とネットワークを経由した通信を実行することができる。

通信Ｉ／Ｆ２１２は、ＭＦＰ２００が備える第１の通信インタフェースであり、ネットワーク３００に接続されている。通信Ｉ／Ｆ２１３は、ＭＦＰ２００が備える第２の通信インタフェースであり、ネットワーク３１０に接続されている。

本実施形態では、通信Ｉ／Ｆ２１２、２１３がイーサネット（登録商標）に準拠する有線通信を行う通信インタフェースである場合を想定しているがこれに限定されるものではない。例えば、一方がＩＥＥＥ８０２．１１シリーズに準拠する無線通信インタフェースであってもよい。また、両方が無線通信インタフェースであってもよい。また、ＣＤＭＡ等の３Ｇ回線、ＬＴＥなどの４Ｇ回線、５Ｇなどの移動体通信を行う通信インタフェースであってもよい。

ＦＡＸ Ｉ／Ｆ２１４には、電話回線ケーブルが接続され、ＰＴＳＮ（Ｐｕｂｌｉｃ Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｐｈｏｎｅ Ｎｅｔｗｏｒｋ）に接続される。

続けて、図３を用いて、ＭＦＰ２００のソフトウェア構成について説明する。送信アプリケーション１０１０ａはネットワーク３００のデバイス１２０や、ネットワーク３１０のデバイス１３０と通信を行うアプリケーションである。例えば、通信アプリケーションは、ＷｅｂＤＡＶなどのＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）ベースの通信でデバイスに対してデータを送信する送信アプリケーションである。送信アプリケーションは、スキャナ２０９で原稿を読み取って得られた画像に基づくファイルをユーザにより指定された送信宛先に送信することができる。送信宛先は図示省略の送信設定画面を介してユーザ操作により指定することができる。ユーザは、ファイルサーバのホスト名をＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）の形式で入力することで宛先を指定する。第１の実施形態において、送信アプリケーションがどちらのインタフェースを使用するかはあらかじめユーザ操作などに基づき設定されているものとする。送信設定画面を介して送信宛先が設定された後に、送信を開始するキーの選択を受け付けたことに従って、送信アプリケーション１０１０ａは原稿の読み取りをスキャナ２０９に依頼する。続けて送信アプリケーション１０１０ａは、原稿を読み取って得られた画像に基づくデータをユーザにより指定された送信宛先に送信する。なお、本実施形態では送信プロトコルの一例としてＷｅｂＤＡＶ（Ｗｅｂ－ｂａｓｅｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ａｕｔｈｏｒｉｎｇ ａｎｄ Ｖｅｒｓｉｏｎｉｎｇ）を例示したがこれに限定されるものではない。例えば、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＦＴＰＳ（ＦＴＰ Ｏｖｅｒ ＳＳＬ／ＴＬＳ）等の送信プロトコルを用いることもできる。

クラウドプリントアプリケーション１０１０ｂは特定のクラウドプリントサービスと通信するアプリケーションである。アプリケーション１０１０ｂは、特定のクラウドプリントサービス（クラウドサーバ）に対してジョブの問い合わせを行ったり、ＵＲＬ形式で指定されるジョブデータをクラウドサーバやクラウドストレージからダウンロードして印刷を行ったりする。これらの通信にもホスト名やＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｓｅ Ｌｏｃａｔｅｒ）で指定された宛先と通信を行うことになる。

また、デバイス管理アプリケーション１０１０ｃはネットワーク上のデバイス管理サーバにデバイスステータスを送信するアプリケーションである。例えば、印刷装置の消耗材（インク、トナー、造形材、サポート材）などの消耗材のステータスや、利用実績、エラー情報などの稼働情報を管理サーバに送信する。これらの管理サーバとの通信にもホスト名で指定された宛先と通信を行うことになる。

オペレーティングシステム１０２０はネットワーク通信を行うためのＴＣＰ／ＩＰプロトコルスタックや、名前解決を行うためのＯＳ標準ＤＮＳクライアント１０２１も含む。本実施形態では、ＤＮＳクライアント１０２１は、Ｌｉｎｕｘ（登録商標）システムにおける標準のＤＮＳクライアントである場合を想定している。これらのクライアントを用いてドメイン名の名前解決を行う場合、「／ｅｔｃ／ｒｅｓｏｌｖｅ．ｃｏｎｆ」に位置するファイルに対して、「ｎａｍｅｓｅｒｖｅｒ “ＤＮＳサーバのＩＰアドレス“」といった記載を行ってＤＮＳサーバを指定する。冗長化のため、利用するＤＮＳサーバを複数指定することもできる。ＤＮＳクライアント１０２１は指定されたＤＮＳサーバに対して名前解決を依頼する機能を備える。

しかしながら、ここで登録するＤＮＳサーバは、登録されたＤＮＳサーバから応答がない場合に代替で利用する冗長化のためのＤＮＳサーバである。そのため、ＤＮＳ名前解決を行った結果、該当する名前が見つからない場合（通信は成功した場合）は、代替で利用するＤＮＳサーバへの問い合わせは行わない。すなわち、ＬｉｎｕｘシステムのＤＮＳクライアントを利用する場合、それぞれのネットワークのＤＮＳ名前解決を実現すること困難であるという問題点がある。

本実施形態では、上述の問題点の少なくとも１つを鑑み、ＤＮＳキャッシュサーバを起動し、当該キャッシュサーバを用いて名前解決を行う仕組みについて説明する。

以下具体的な仕組みについて説明する。

設定値ＤＢ１０５０には通信Ｉ／Ｆに関する設定を含むＭＦＰ２００の動作設定が記憶される。通信Ｉ／Ｆに関する設定には、各通信インタフェースの有効／無効を示す設定や、ＤＮＳサーバのアドレスを自動取得するかどうかを示す設定を含む。また、後述するドメイン名リストも当該設定値ＤＢ１０５０に記憶される。

ネットワーク設定制御部１０４０は、設定画面を操作パネル２１１に表示し、管理者等のユーザから各種ネットワーク設定の変更を受け付けて設定値ＤＢ１０５０に格納する機能を有する。また、制御部１０４０は、ＤＮＳ設定制御部１０４０ａを有する。ＤＮＳ設定制御部１０４０ａは、設定値ＤＢ１０５０の値を参照し、ＤＮＳキャッシュサーバ１０３０およびＤＮＳクライアント１０２１の起動制御や動作設定制御を行う。

なお、設定制御部１０４０は、図示省略のＷｅｂサーバ機能と協働して、ネットワーク設定を確認、変更するためのＷｅｂページを提供することもできる。この場合、管理者等のユーザは、ＰＣなどのクライアントからＭＦＰ２００が提供するＷｅｂページにアクセスし、ネットワーク設定の変更を行うことができる。

ネットワーク設定の一例について図６を用いて説明する。本実施形態では、通信Ｉ／Ｆ２１２と通信Ｉ／Ｆ２１３の両方が有効の場合を例に説明する。複数の通信インタフェースが有効な場合、いずれか一方がプライマリネットワークとして機能する。なお、本実施形態において、プライマリネットワークとして機能する通信インタフェースは、経路が分からないパケットを転送するデフォルトゲートウェイが設定される。その他のインタフェースは同一ネットワークに属する通信装置と通信を行ったり、当該インタフェースに対してスタティックルートが事前設定された通信装置と通信を行ったりするサブネットワークとして機能する。本実施形態では、デフォルトゲートウェイとして機能する通信インタフェースと、サブネットワークとして機能する通信インタフェースの差異はデフォルトゲートウェイが設定できるかどうかである。しかしながらこれに限定されるものではない。サブネットワークとして機能する通信インタフェースはよりプライマリネットワークとして機能するネットワークインタフェースと比較して機能が限定されていてもよい。例えば、一部プロトコルの使用を制限したりしてもよい。

以降、説明のため、通信Ｉ／Ｆ２１２に対応する「ネットワーク１」がプライマリネットワークとして機能し、通信Ｉ／Ｆ２１３に対応する「ネットワーク２」がプライマリネットワークより優先順位が低いサブネットワークとして機能する場合を例に説明する。以降通信Ｉ／Ｆ２１２を単に「ネットワーク１」と呼び、通信Ｉ／Ｆ２１３を単に「ネットワーク２」とも呼ぶものとする。また、サブネットワークのことをセカンダリネットワークとも呼ぶ。

ネットワークの設定について図６を用いて説明する。図６（Ａ）、（Ｂ）は設定制御部１０４０が操作パネル２１１上に表示する設定画面の一例である。図６（Ａ）はプライマリネットワークとして機能する「ネットワーク１」の設定画面６００を示しており、セカンダリネットワークとして機能する「ネットワーク２」の設定画面６１０を示している。

ユーザは、画面６００を介して、ＤＮＳサーバに関する設定とネットワークの名称（愛称）の設定を行うことができる。キー６０１、６０２は、ＤＮＳサーバのＩＰアドレスを自動取得するかどうかを設定するための表示アイテムである。キー６０１、６０２はいずれか一方が有効にセットされ、他方は無効にセットされる。本実施形態ではキー６０１が有効に設定されている場合を例示している。

なお、本実施形態において、表示アイテムとは、ユーザ操作を受け付けるためのキー、ボタン、情報表示のためのラベル、表示領域、描画オブジェクトなどを含む表示オブジェクトの総称を意味する。以降、説明のため操作パネル２１１上に設定画面を表示する場合を例に説明するが、クライアント端末のＷｅｂブラウザから、ＭＦＰ２００が提供するＷｅｂページにアクセスすることで同様の設定を行うことができる。

領域６０３は、ネットワーク１に割り当てられたＤＮＳサーバの設定を表示する領域である。また領域６０３は、キー６０２が有効に設定され、ＤＮＳサーバのＩＰアドレスを自動取得する設定が無効に設定された場合に、当該領域はＤＮＳサーバのＩＰアドレスを手動設定する領域として機能する。この場合、ユーザは操作パネル２１１に表示される図示省略のソフトウェアキーボードを介してＩＰアドレスを入力することで、ＤＮＳサーバを手動設定することができる。

領域６０４は、ネットワークの名称を設定する領域である。管理者等のユーザは、当該領域に愛称を設定することで、設定画面やレポートプリントなどにおいて、複数のネットワークを容易に識別することが可能になる。ここでは、一例として「ＬＡＮ１」が設定されている場合を例示している。なお、紙面の都合上省略しているが、その他の設定として、プロキシサーバの設定、ＤＨＣＰサーバの設定、ＩＰアドレスの設定なども行えるものとする。制御部１０４０は、決定キーが選択されたことを検知すると、設定画面を介してなされた設定値に基づき、設定値ＤＢ１０５０の設定値を変更する。

図２の説明に戻り、ＤＮＳサーバ自動取得部１０７０はＤＮＳサーバの自動取得が有効に設定された場合、ネットワークからＤＮＳサーバの設定を取得する。自動取得部１０７０はＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）クライアントを含む。自動取得部１０７のＤＨＣＰクライアントは、ネットワーク上のＤＨＣＰサーバに対してＤＮＳサーバのアドレスを要求するＤＨＳＰオプションを含む要求を送信して、ＤＮＳサーバのＩＰアドレスを取得する。なお、プロトコルスタックとしてＩＰｖ６を採用する場合、ＲＳ（Ｒｏｕｔｅｒ Ｓｏｌｉｃｉｔａｔｉｏｎ）、ＲＡ（Ｒｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔ）のやり取りに基づきＤＮＳサーバのＩＰアドレスを取得することもできる。

図７は、設定値ＤＢに記憶される設定値と、後述する制御で生成される設定ファイルの一例を説明する図である。図７（Ａ）は設定値ＤＢに記憶される画面６００で手動設定されたＤＮＳサーバのＩＰアドレスや自動取得で取得されたＤＮＳサーバのＩＰアドレスを例示している。図７（Ｂ）は設定値ＤＢに記憶される、画面６１０を介して手動設定されたＤＮＳサーバのＩＰアドレスや自動取得で取得されたＤＮＳサーバのＩＰアドレスを例示している。これらの設定値は、後述するフローチャートで示す各処理で適宜参照される。

図２の説明に戻る。ＤＮＳキャッシュサーバ１０３０は、ＤＮＳクライアント１０２１から名前解決の問い合わせを受信し、そのホスト名、ドメイン名を管理するＤＮＳサーバに代理で問い合わせを行い、その結果をＤＮＳクライアント１０２１に応答するキャッシュサーバである。また、問い合わせ結果は一定期間キャッシュされる。サーバ１０３０は、一定期間内に同じホスト名の名前解決が依頼された場合、外部サーバへ新たに問い合わせを行わず、キャッシュした結果を返答する機能を有する。

また、制御部１０４０は、１つの通信インタフェースのみが有効化されている場合や、１つの通信インタフェースのみをデータ送信に使用する場合、プライマリネットワークとして機能するネットワーク１に割り当てられたＤＮＳサーバを問い合わせ先に指定する。即ち、図７（Ａ）に例示したＩＰアドレスを問い合わせ先に指定する。更に、制御部１０４０はハードウェアリソースやメモリリソースの浪費を抑制する目的でＤＮＳキャッシュサーバ１０３０を起動しないように制御する。

一方、ネットワーク設定制御部１０４０は、ネットワーク１とネットワーク２の両方が有効に設定され、両方の通信インタフェースをデータ送信に使用する場合、当該ＤＮＳキャッシュサーバ１０３０を起動するよう制御する。更に、制御部１０４０は、ＯＳ１０２０のＤＮＳクライアント１０２１の問い合わせ先をＤＮＳキャッシュサーバ１０３０に変更する。即ち、ＤＮＳクライアントの問い合わせ先をインターナルループバックのＩＰアドレスである１２７．０．０．１に設定する。この設定により、ＤＮＳキャッシュサーバ１０３０は、ＭＦＰ２００が備えるＤＮＳクライアント以外のＤＮＳクライアントからの名前解決の要求を無視又は破棄するよう動作する。

サーバ１０３０の実装はＢＩＮＤ（ｈｔｔｐｓ：／／ｗｗｗ．ｉｓｃ．ｏｒｇ／ｂｉｎｄ／）や、ＵＮＢＯＵＮＤ（ｈｔｔｐｓ：／／ｗｗｗ．ｎｌｎｅｔｌａｂｓ．ｎｌ／ｐｒｏｊｅｃｔｓ／ｕｎｂｏｕｎｄ／ａｂｏｕｔ／）を用いることができる。本実施形態では一例としてＤＮＳキャッシュサーバとしてＵＮＢＯＵＮＤを採用する場合を例に説明する。

また、本実施形態では、このＤＮＳキャッシュサーバ１０３０が、他のＤＮＳサーバに再帰問い合わせを行う際の転送条件を登録できることに着目する。当該転送条件を活用して、ＤＮＳサーバの問い合わせ先のネットワークを異ならせる。

まず、ネットワーク２のＤＮＳサーバに問い合わせを行いたいドメインを登録する方法について図６（Ｂ）の画面６１０を用いて説明する。

画面６１０は、サブネットワークとして機能するネットワーク２に関する設定を受け付ける設定画面である。表示アイテム６１１～６１３に示されるＤＮＳサーバに関する設定は画面６００と同様であるため省略する。画面６１０は、ネットワーク２上のＤＮＳサーバのＩＰアドレスが自動取得され、ネットワーク２で使用するＤＮＳサーバとして当該取得されたＩＰアドレスが設定されている場合を例示している。また領域６１８は、領域６０４と同様にネットワーク２の名称（愛称）を設定するための表示アイテムである。ここでは、「インターネット」といった名称が設定されている場合を例示している。

更に、ユーザは、サブネットワークであるネットワーク２の設定画面６１０を介して、ネットワーク２のＤＮＳサーバに名前解決を依頼すべきドメイン名を登録する設定を行うことができる。領域６１６は、登録されているドメイン名をユーザに提示するための表示アイテムである。ユーザは領域６１６に対するタッチ操作により、登録済みのドメイン名に対応する１つの行を選択することができる。

新規登録キー６１４はネットワーク２のＤＮＳサーバに名前解決を依頼すべきドメイン名を新たに登録する場合に使用する表示アイテムである。編集キー６１５は、領域６１６に対するタッチ操作により選択された、登録済みのドメイン名を編集する場合に使用する表示アイテムである。メッセージ６１７は、ユーザに機能を説明するための表示アイテムである。具体的にはネットワーク上のサーバのドメイン名を事前登録することで、ネットワーク２のＤＮＳサーバを用いた名前解決が可能となることをユーザに通知するメッセージが含まれる。更に、事前登録されていないドメインで管理されるホスト名の名前解決はネットワーク１（ＬＡＮ１）に依頼される旨、警告するメッセージが含まれる。当該メッセージを表示することで、ユーザに対して当該機能が何のための機能であるのか、設定をしないと何が起きるのかを分かりやすく、直感的に理解させることができる。決定キー６１９は、画面を介してなされた設定を設定値ＤＢ１０５０に適用する場合に使用するキーである。戻るキーは画面を介してなされた設定を破棄し、設定を終了する場合に使用するキーである。

新規登録キー６１４が選択されたことを検知した場合、設定制御部１０４０は、ドメイン名の入力を受け付けるテキストボックスを含む設定画面を表示する。ユーザは、当該テキストボックスにドメイン名の入力を行い、設定画面を介して当該ドメイン名を登録する操作を行う。当該登録する操作を検知したことに従って、設定制御部１０４０は、設定値ＤＢ１０５０に記憶される、ネットワーク２のＤＮＳサーバに名前解決を依頼すべきドメインの一覧を示すドメインリストを更新する。当該更新されたドメインリストは後述する設定処理のフローチャートにおいて適宜参照される。

具体的な制御について図４、図５のフローチャートを用いて説明する。図４、図５のフローチャートに示す各動作（ステップ）は、ＣＰＵ２０２がＲＯＭ２０４またはストレージ２０５に記憶された各制御モジュールを実現するためのプログラムをＲＡＭ２０３に呼び出し、実行することにより実現される。なお、データの送受信処理などは、各通信Ｉ／Ｆと協働して実現されるものとする。また、処理の主体を明確にしたいケースにおいては、ＣＰＵ２０２により実行されるソフトウェアモジュールを主語として説明する。

図４のフローチャートは、電源ＯＦＦ状態のＭＦＰ２００を起動する操作を受け付け、ＭＦＰ２００が電源ＯＦＦ状態から、スタンバイ状態に遷移する際に実行される起動処理を説明するフローチャートである。なお、起動処理においては、ネットワークに関する設定処理だけでなく、その他の起動処理（パネル２１１に表示する画面の準備や、各種ハードウェアの起動処理等）も並列又はシーケンシャルに行われるが、当該処理の説明は省略する。

ステップＳ４０１において、設定制御部１０４０は、設定値ＤＢ１０５０から、ＤＮＳサーバの情報及び各通信Ｉ／Ｆの有効／無効を示す設定情報を取得する。ＤＮＳサーバの情報は、インタフェースごとのＤＮＳサーバの設定や、サブネットワークに対応付けて記憶されたドメインリストを含む。

Ｓ４０２において、設定制御部１０４０は、Ｓ４０１で取得した設定情報に基づき、複数のネットワークＩ／Ｆを使用する設定がなされているか否かを判断する。複数のネットワークＩ／Ｆを使用する設定がなされていると判断した場合、処理をＳ４０３に進める。複数のネットワークＩ／Ｆを使用する設定がなされていないと判断した場合、処理をＳ４０４に進める。具体的には、設定制御部１０４０は、ネットワーク１／ネットワーク２のいずれか一方のみを有効にする設定がなされている場合、複数のネットワークＩ／Ｆを使用する設定がなされていないと判断する。設定制御部１０４０は、ネットワーク１、ネットワーク２の両方を有効にする設定がなされている場合、複数のネットワークＩ／Ｆを使用する設定がなされていると判断する。

続けて、Ｓ４０３において、設定制御部１０４０は、Ｓ４０１で取得したＤＮＳサーバの設定に基づき、ネットワーク２のＤＮＳサーバに名前解決を依頼すべきドメインが登録されているか否かを判断する。設定制御部１０４０は、ドメインリストに１以上のドメイン名が登録されている場合、ネットワーク２のＤＮＳサーバに名前解決を依頼すべきドメインが登録されていると判断し、処理をＳ４０５に進める。一方、ドメインリストに１以上のドメイン名が登録されていない場合、ネットワーク２のＤＮＳサーバに名前解決を依頼すべきドメインが登録されていないと判断し、処理をＳ４０４に進める。

Ｓ４０４において、設定制御部１０４０は、ＤＮＳクライアント１０２１の問い合わせ先となるＤＮＳサーバとしてプライマリネットワークに対応するＤＮＳサーバのＩＰアドレスを登録する。例えば、ＯＳ１０２０がＬｉｎｕｘの場合、設定制御部１０４０は「／ｅｔｃ／ｒｅｓｏｌｖｅ．ｃｏｎｆ」の設定ファイルを編集し、プライマリネットワークに対応するＤＮＳサーバのＩＰアドレスを問い合わせ先とする設定に変更する。続けて、設定制御部１０４０は、ＯＳ１０２０にＤＮＳクライアント１０２１を起動するよう依頼する。ＯＳ１０２０は、当該依頼に基づいて、ＤＮＳクライアント１０２１を起動する。起動したＤＮＳクライアント１０２１は、設定ファイルを参照し、名前解決依頼の問い合わせ先となるＤＮＳサーバを読み込む。Ｓ４０４の処理により、１つの通信インタフェースのみ使用する場合は、ＤＮＳキャッシュサーバを起動することなく、ＤＮＳクライアント１０２１に、有効な通信インタフェースが接続するネットワーク上のＤＮＳサーバを適切に設定できるようになる。また、複数の通信インタフェースを使用する場合であっても、サブネットワーク用のドメインリストが登録されていない場合は、ＤＮＳキャッシュサーバを起動せずに、プライマリネットワーク用のＤＮＳサーバをクライアントに適切に設定できるようになる。

一方、Ｓ４０５において、設定制御部１０４０は、ＤＮＳキャッシュサーバが使用する問い合わせ設定ファイルを作成する。具体的な処理について図５（Ａ）を用いて説明する。

ここでは、説明のため、ネットワーク１がプライマリネットワークとして機能する通信インタフェースであり、ネットワーク２がサブネットワークとして機能する通信インタフェースである場合を例に説明する。

Ｓ５０１において、設定制御部１０４０は、ネットワーク２のＤＮＳサーバ設定、及び、ドメインリストを取得する。取得が完了すると、ＣＰＵ２０２は、ドメインリストへのアクセスに用いる参照情報をドメインリストの先頭に設定する。Ｓ５０２において、設定制御部１０４０はドメインリスト内に存在する１つのドメイン名を対象として読み出し、当該ドメイン名に属するホスト名の名前解決依頼をネットワーク２のＤＮＳサーバに転送するルールを設定ファイルに追加する。

Ｓ５０３において、設定制御部１０４０は、ドメインリストの末尾に到達したか否かを判断する。ＣＰＵ２０２は、Ｓ５０２で行った読み出しの結果、ドメインリストの末尾に到達していると判断した場合、処理をＳ５０４に進める。一方、設定制御部１０４０は、ドメインリストの末尾に到達していない（即ち、ルールを追加する処理を行っていないドメイン名がリストにある）と判断した場合、Ｓ５０２で対象として読み出すべきリストを示す参照情報を更新し、処理をＳ５０２に進める。

Ｓ５０４において、設定制御部１０４０は、プライマリネットワークとして機能するネットワーク１のＤＮＳサーバ設定を取得する。

Ｓ５０５において、設定制御部１０４０は、追加したルールに合致しないドメインの名前解決の依頼を、ネットワーク１のＤＮＳサーバに転送するルールを追加し、ＤＮＳキャッシュサーバの設定ファイルを更新する。設定ファイルの更新が完了すると、処理をＳ４０６に進める。

図７（Ｃ）は、図５（Ａ）のフローチャートで設定される設定ファイルの具体例を説明するための図である。図７（Ｃ）は設定ファイルの一例である。図７（Ａ）、（Ｂ）は前述したように、各通信ネットワークに割り当てられたＤＮＳサーバのＩＰアドレスを示している。

図７では、ＤＮＳキャッシュサーバがＵＮＢＯＵＮＤである場合を例に説明する。この場合、ＤＮＳキャッシュサーバの設定ファイル（ｆｏｒｗａｒｄ－ｚｏｎｅ．ｃｏｎｆ）は図７（Ｃ）のような設定ファイルとなる。図７（Ｃ）の設定の定義について説明する。「ｆｏｒｗａｒｄ－ｚｏｎｅ」は転送先を指定することを示す文字列である。ＵＮＢＯＵＮＤではｆｏｒｗａｒｄ－ｚｏｎｅのｎａｍｅで指定されたドメインに属するホスト名の名前解決をクライアントから依頼された場合、ｆｏｒｗａｄ－ａｄｄｒで指定されたＤＮＳサーバへ名前解決を転送する。

また、ｆｏｒｗａｒｄ－ｚｏｎｅのｎａｍｅで”．”が指定されている設定は、既定のＤＮＳサーバに対して名前解決を依頼するための設定である。ＵＮＢＯＵＮＤでは、自己解決できないドメインに属するホスト名の名前解決をクライアントから依頼された場合、「．」に対応付けられているｆｏｒｗａｄ－ａｄｄｒで指定されたＤＮＳサーバに対して名前解決を転送する。

例えば、画面６１０で例示した「ｅｘａｍｐｌｅ．ｏｒｇ」と「ｔｅｓｔ．ｏｒｇ」がネットワーク２のＤＮＳサーバに問い合わせるべきドメイン名に指定されている場合、７１０に示す設定がＳ５０２～Ｓ５０３の処理によって生成される。７１０の設定は、画面６１０で設定されたドメインに属するホスト名の名前解決を図７（Ｂ）に示すＤＮＳサーバに転送するルールを示している。

また、Ｓ５０５の処理により、特定のドメインに属さないホスト名の名前解決はプライマリネットワークであるネットワーク１のＤＮＳサーバに転送する７２０の設定が生成される。

図４の説明に戻り、Ｓ４０６において、設定制御部１０４０は、ループバックアドレスである１２７．０．０．１からの名前解決の依頼のみを許可する設定でＤＮＳキャッシュサーバ１０３０を起動する。起動を指示されたＤＮＳキャッシュサーバ１０３０は、図５（Ａ）の処理で生成された設定ファイルを参照して、名前解決の転送先を判断する経路テーブルをＲＡＭ２０３に展開する。即ち、ＤＮＳキャッシュサーバ１０３０は起動時に設定ファイルに基づき動作設定を行う。起動したＤＮＳキャッシュサーバ１０３０は、当該動作設定に基づき問い合わせ先を異ならせる制御を行う。

Ｓ４０７において、設定制御部１０４０は、ＯＳ１０２０が提供するＤＮＳクライアント１０２１の問い合わせ先となるＤＮＳサーバとしてＤＮＳキャッシュサーバのＩＰアドレスを登録する。例えば、ＯＳ１０２０がＬｉｎｕｘの場合、設定制御部１０４０は「／ｅｔｃ／ｒｅｓｏｌｖｅ．ｃｏｎｆ」の設定ファイルを編集し、名前解決の依頼先をＤＮＳキャッシュサーバのＩＰアドレス（ループバックアドレス）設定に変更する。続けて、設定制御部１０４０は、ＯＳ１０２０にＤＮＳクライアント１０２１を起動するよう依頼する。ＯＳ１０２０は、当該依頼に基づいて、ＤＮＳクライアント１０２１を起動する。起動したＤＮＳクライアント１０２１は、変更された設定ファイルを参照し、名前解決依頼の問い合わせ先となるＤＮＳサーバとして内部のＤＮＳキャッシュサーバを使用すると決定する。

Ｓ４０４、Ｓ４０７のいずれか一方の処理が実行され、ＤＮＳに関する設定処理が完了するとともに、並列又はシーケンシャルに実行するその他の起動処理も完了すると、ＣＰＵ２０２は、一連の起動処理を完了する。起動処理が完了するとＭＦＰ２００はスタンバイ状態となり、前述した印刷機能、スキャン機能、管理機能、クラウドプリント機能を利用できる状態に遷移する。

続けて、図５（Ｂ）を用いてＤＮＳキャッシュサーバ１０３０による名前解決の制御を説明する。

図５（Ｂ）に示すフローチャートは、各アプリケーションから名前解決の依頼を受けたＯＳ１０２０のＤＮＳクライアント１０２１がＤＮＳキャッシュサーバ１０３０に名前解決を依頼する際に実行される。

Ｓ５１０において、サーバ１０３０は、ＤＮＳクライアントから受信した名前解決依頼に対応するキャッシュがあるかどうかを判断する。キャッシュがある場合、処理をＳ５１５に進め、キャッシュがない場合、処理をＳ５１１に進める。

Ｓ５１１において、サーバ１０３０は、受信した名前解決依頼に含まれるドメイン名が転送条件に合致するかどうかを判断する。サーバ１０３０は、ＲＡＭ２０３に展開された名前解決の転送先を判断する経路テーブルに基づき特定のＤＮＳサーバに転送すべき名前解決依頼であるかどうかを判断する。特定のＤＮＳサーバに転送すべき名前解決依頼であると判断した場合、処置をＳ５１２に進め、特定のＤＮＳサーバに転送すべき名前解決依頼でないと判断した場合、処理をＳ５１３に進める。具体的には、名前解決依頼のホスト名を構成する上位ドメインが図７の７１０に例示したドメイン名と合致する場合、特定のＤＮＳサーバに転送すべき名前解決依頼であると判断される。

Ｓ５１２において、サーバ１０３０は、通信Ｉ／Ｆと協働して転送条件に対応するＤＮＳサーバに名前解決を転送する。Ｓ５１３において、サーバ１０３０は、通信Ｉ／Ｆと協働して既定のＤＮＳサーバ（即ち、プライマリネットワークとして機能する通信インタフェースに割り当てられたＤＮＳサーバ）に名前解決を転送する。

Ｓ５１４において、サーバ１０３０は、転送した名前解決の結果をＤＮＳサーバから受信したか否かを判断する。結果を受信した場合、処理をＳ５１５に進め、受信していない場合、名前解決の結果を待つ。

Ｓ５１５において、サーバ１０３０は、ＤＮＳクライアント１０２１に名前解決の結果を通知する。また、サーバ１０３０は、当該結果をキャッシュとして登録する。なお、Ｓ５１０でキャッシュがあると判断された場合は、キャッシュに基づき名前解決の結果が通知される。この場合、キャッシュは登録されない。当該結果を受信したＤＮＳクライアント１０２１は、名前解決を依頼したアプリケーションに、名前解決の結果を通知する。アプリケーションは名前解決の結果得られたＩＰアドレスを用いて外部装置と通信を行う。

以上説明した通り、本実施形態では、設定ファイルを利用して、ＤＮＳキャッシュサーバに、ドメイン名と問合せ先のＤＮＳサーバの対応関係を登録する。その結果、当該ＤＮＳキャッシュサーバを活用して名前解決先のＤＮＳサーバを異ならせることができるようになる。

なお、本実施形態では、ＤＮＳキャッシュサーバ１０３０が名前解決の結果をキャッシュするよう構成したが、キャッシュを活用しないよう制御してもよい。この場合、ＤＮＳキャッシュサーバは、Ｓ５１０の処理と、Ｓ５１５のキャッシュ処理をスキップすればよい。

また、本実施形態では、ＭＦＰ２００が有する通信インタフェースが２つの場合を例示したが、ＭＦＰ２００が、３つ以上の通信インタフェースを有していてもよい。この場合、１つの通信インタフェースのみがプライマリネットワークとして機能し、その他の通信インタフェースはサブネットワークとして機能する。この場合、ＭＦＰ２００は、サブネットワークとして機能する各通信インタフェースに対応付けて、図６（Ｂ）で例示した名前解決と同様の設定を行う機能を提供する。更に、ＭＦＰ２００は、Ｓ５０１～Ｓ５０３の処理をサブネットワークとして機能する通信インタフェースの数だけ実行する。この処理により、３つ以上の通信インタフェースにおける名前解決を適切に行えるようになる。なお、プライマリネットワークとして機能する通信インタフェースは工場出荷時に決められていてもよいし、ユーザ操作によりいずれの通信インタフェースをプライマリネットワークとして機能させるかをＭＦＰ２００の動作設定として設定させるようにしてもよい。

＜第２の実施形態＞
第１の実施形態では、ネットワーク２のＤＮＳサーバに名前解決すべきドメイン名を登録するユーザ操作を受け付け、ドメインリストを更新する方法について説明した。

第２の実施形態では、第１の実施形態における処理に加えて、登録するユーザ操作を受け付けたタイミングで名前解決が行えるかどうかを確認する仕組みについて説明する。なお、第２の実施形態におけるハードウェア構成は第１の実施形態と同様であるため、説明を省略する。

第２の実施形態におけるソフトウェア構成を図８を用いて説明する。図２との差異は、ＤＮＳチェックアプリケーション１０１０ｄを追加している点である。

アプリケーション１０１０ｄは、指定したＤＮＳサーバに対して、指定したドメイン名の名前解決を依頼するアプリケーションである。アプリケーション１０１０ｄは、例えば、名前解決を依頼したいＤＮＳサーバ名をオプションとして指定したｎｓｌｏｏｋｕｐコマンドを用いて、ＯＳ１０２０にドメインの正引きを依頼する。ＯＳ１０２０は当該ＤＮＳサーバに名前解決を依頼する。

次に、図９、図１０を用いて具体的な制御について説明する。図９のフローチャートに示す各動作（ステップ）は、ＣＰＵ２０２がＲＯＭ２０４またはストレージ２０５に記憶された各制御モジュールを実現するためのプログラムをＲＡＭ２０３に呼び出し、実行することにより実現される。なお、データの送受信処理などは、各通信Ｉ／Ｆと協働して実現されるものとする。また、処理の主体を明確にしたいケースにおいては、ＣＰＵ２０２により実行されるソフトウェアモジュールを主語として説明する。

図１０は、第２の実施形態における設定画面の一例を示している。図１０（Ａ）に例示する画面１０８０は、第１の実施形態の画面６１０を介して編集キー６１５又は新規登録キー６１４が選択された場合に表示される画面の一例である。

テキストボックス１０８２はユーザがドメイン名を入力する場合に使用する表示アイテムである。設定制御部１０４０は、表示アイテム１０８２を選択する操作を検知すると、図示省略のソフトウェアキーボードを表示し、当該キーボードを介してドメイン名の入力を受け付ける。画面１０８０では、「ｈｏｇｅ．ｅｘａｍｐｌｅ０．ｊｐ」といったドメイン名の入力を受け付けた場合を例示している。

決定キー１０８３は、当該ドメイン名を登録する場合に使用するキーである。戻るキーは画面１０８０を介してなされた設定を破棄し、画面６１０に例示したネットワーク設定画面に戻る場合に使用するキーである。削除キー１０８４は編集画面に表示されるキーである。ユーザは削除キー１０８４を介して登録済みのドメインを削除することができる。なお、削除キー１０８４は新規登録画面には表示されない。

設定制御部１０４０は、ドメイン名の入力を受け付けた後に、決定キー１０８３が選択されたことを検知すると、図９のフローチャートに示す各処理を実行する。

Ｓ９０１において、設定制御部１０４０は、アプリケーション１０１０ｄに画面１０８０を介して入力されたドメイン名と、名前解決を行うべきＤＮＳサーバを示すＩＰアドレスをアプリケーション１０１０ｄに通知する。即ち、設定制御部１０４０は、アプリケーション１０１０ｄに名前解決を依頼する。ＤＮＳチェックアプリケーション１０１０ｄは、当該通知された情報に基づいて、ＯＳ１０２０にｎｓｌｏｏｋｕｐコマンドを用いた正引きを依頼する。ＯＳ１０２０は、ＤＮＳクライアント１０２１及び通信Ｉ／Ｆと協働して、オプションコマンドで指定されたＤＮＳサーバに対して名前解決を依頼する。指定された名前解決の結果はアプリケーション１０１０ｄに通知される。

Ｓ９０２において、設定制御部１０４０は、アプリケーション１０１０ｄから名前解決の結果を受信し、受信結果に基づきＩＰアドレスを取得できたか否かを判断する。ドメイン名に対応するＩＰアドレスを取得できた場合、処理をＳ９０３に進め、取得できなかった場合、処理をＳ９０４に進める。

Ｓ９０３において、設定制御部１０４０は、ＤＢ１０５０が記憶するドメインリストに名前解決でＩＰアドレスが取得できたドメイン名を追加する。

一方、Ｓ９０４において、設定制御部１０４０は、確認画面を表示する。図１０（Ｂ）の例示する画面１０９０は、確認画面の一例である。ポップアップ１０９１はユーザに情報を提示するポップアップに対応する表示アイテムを示している。ポップアップ１０９１には、名前解決に失敗したこと、及び、当該名前解決に失敗したドメイン名を本当に追加するかどうかをユーザに通知するメッセージが含まれている。追加キー１０９２は名前解決に失敗したドメイン名を追加する場合に使用するキーであり、キャンセルキー１０９３は、名前解決に失敗したドメイン名の追加をキャンセルする場合に使用するキーである。

図９の説明に戻り、Ｓ９０５では、設定制御部１０４０は、追加キー１０９２の選択を受け付けたか否かを判断する。追加キーの選択を受け付けた場合は処理をＳ９０３に進め、追加キーの選択を受け付けていない場合は、処理をＳ９０６に進める。

Ｓ９０６において、設定制御部１０４０は、キャンセルキー１０９３の選択を受け付けたか否かを判断する。キャンセルキーの選択を受け付けた場合は処理をＳ９０７に進め、キャンセルキーの選択を受け付けていない場合は、Ｓ９０５に戻り、ユーザによるキーの選択を待ち受ける。

Ｓ９０７において、設定制御部１０４０は、操作パネル２１１上に表示する画面を新規入力画面又は編集画面に切り替える。当該画面は例えば画面１０８０のように登録しなかったドメイン名をプリセットした画面である場合を想定している。しかしながらこれに限定されるものではない。ドメイン名のテキストボックスを空欄としてもよい。更には、画面１０８０のドメイン名のテキストボックスの色を薄いピンクなどに変更するとともに、ドメイン名を修正することを促すメッセージなどを表示してもよい。

以上説明した実施形態によれば、ドメイン名と問合せ先のＤＮＳサーバの対応関係を登録する際に、ドメイン名の入力ミスなどに起因して、名前解決が行えない組み合わせが登録されることを抑制することができる。また、現時点ではネットワークに参加していないドメイン名をＭＦＰに事前入力するケースなども鑑み、確認画面からユーザが追加を明示的に指示した場合は、当該名前解決を行えない組み合わせも登録を行える。従って、管理者等のユーザにより、入力ミスに基づく設定ミスを抑制しつつも、柔軟な事前登録処理を行えるようになる。

＜第３の実施形態＞
サブネットワークのＤＮＳサーバに問合せすべきドメイン名が多数ある場合、第１の実施形態で説明した１つのドメイン名を手作業で入力する事前登録処理だと手間がかかる。そこで、第３の実施形態では、第１の実施形態で説明した制御に加えて、ドメイン名を一括インポートする機能を提供する。

図１１に例示する画面１１００は、第３の実施形態におけるサブネットワークとして機能する通信インタフェースに関する設定画面である。当該画面１１００は、第１の実施形態における図６（Ｂ）の画面６１０に代えて表示される。

画面６１０との差異は、インポートキー１１０１が追加されている点である。ユーザはインポートキー１１０１を用いてドメイン名を列挙したファイル（例えば、ＣＳＶ（Ｃｏｍｍａ Ｓｅｐａｒａｔｅｄ Ｖａｌｕｅ）形式のファイル）を選択することができる。

次に、図１２を用いて具体的な制御について説明する。図１２のフローチャートに示す各動作（ステップ）は、ＣＰＵ２０２がＲＯＭ２０４またはストレージ２０５に記憶された各制御モジュールを実現するためのプログラムをＲＡＭ２０３に呼び出し、実行することにより実現される。なお、データの送受信処理などは、各通信Ｉ／Ｆと協働して実現されるものとする。また、処理の主体を明確にしたいケースにおいては、ＣＰＵ２０２により実行されるソフトウェアモジュールを主語として説明する。

Ｓ１２０１において、設定制御部１０４０は、ドメイン名を列挙したファイルを選択するユーザ操作を受け付けたか否かを判断する。例えば、ユーザはＰＣを用いてドメイン名を列挙したＣＳＶファイルを生成しておき、ＵＳＢメモリに当該ファイルを格納する。続けてユーザはＭＦＰ２００の図示省略のＵＳＢポートに、当該ファイルを格納したＵＳＢメモリを装着する。ＣＰＵ２０２は、装着されたＵＳＢメモリを外部ストレージとしてマウントする。続けて、設定制御部１０４０は、インポートキー１１０１が選択されたことを検知すると、マウントした外部ストレージからファイルを選択する選択画面を操作パネル２１１上に表示する。設定制御部１０４０は、当該選択画面を介してドメイン名を列挙したファイルが選択されると、選択するユーザ操作を受け付けたと判断する。ドメイン名を列挙したファイルを選択するユーザ操作を受け付けた場合、処理をＳ１２０２に進め、受け付けていない場合処理をＳ１２０３に進める。

Ｓ１２０２において、設定制御部１０４０は、ドメイン名を列挙したファイルを参照し、設定値ＤＢ１０５０のドメインリストを更新する。一方、Ｓ１２０３において、設定制御部１０４０は、編集、新規登録の操作を受け付けたか否かを判断する。編集又は新規登録の操作を受け付けた場合、処理をＳ１２０４に進め、編集又は新規登録の操作を受け付けていない場合、設定画面を介したユーザ操作を待ち受ける。

Ｓ１２０４において、設定制御部１０４０は、編集又は新規登録の操作に基づき設定値ＤＢ１０５０のドメインリストを更新する。Ｓ１２０２又はＳ１２０４のいずれか一方の処理が完了すると一連の処理を終了する。

この処理により、ドメイン名の一括インポートが可能となり、管理者の利便性をより高めることができる。更新されたドメインリストは、図５（Ａ）に示すフローチャートを実行する際に参照され、設定ファイルの生成制御に用いられる。

なお、本実施形態では、ＵＳＢメモリ経由でドメイン名を列挙したファイルを取得する場合を例示したがこれに限定されるものではない。例えば、クライアント端末のＷｅｂブラウザに対して図１１に対応するＷｅｂ画面を提供する場合は、以下の制御を行うようにすることができる。具体的には、Ｓ１２０１の処理に代えて、クライアントからドメイン名を列挙したファイルを受信したか否かを判定するよう制御する。

制御部１０４０は、図１１に対応するＷｅｂコンテンツとして、ファイルアップロードのためのフォーム部品を含むＷｅｂコンテンツを生成して、クライアントに当該生成したＷｅｂコンテンツを送信する。クライアント上では、当該フォーム部品を含むＷｅｂコンテンツに基づき、ファイルアップロードボタンを含むＷｅｂ画面が表示される。Ｗｅｂブラウザ上でファイルをアップロードするユーザ操作が行われると、クライアントのＷｅｂブラウザは、ファイルアップロードのＨＴＴＰリクエストをＭＦＰ２００に対して送信する。設定制御部１０４０は、当該ＨＴＴＰリクエストを受信した場合に、クライアントからドメイン名を列挙したファイルを受信したと判定する。続けて、Ｓ１２０２において、設定制御部１０４０は、受信したドメイン名を列挙したファイルを参照し、設定値ＤＢ１０５０のドメインリストを更新する。

更に、本実施形態では、一例として第１の実施形態の処理に加えてインポート機能の処理を更に実行する場合を例示したがこれに限定されるものではない。例えば、第２の実施形態にインポート機能を追加してもよい。この場合Ｓ１２０３とＳ１２０４の間に図９で説明したチェック処理を行うようにする。更に、ＭＦＰ２００は、ドメイン名を列挙したファイルに含まれる各ドメイン名に対して、図９で説明したチェック処理を行い、チェック結果に応じて適宜ドメインリストに追加するか否かを切り替えるようにする。この処理により、一括インポートを行う場合においても、管理者等による入力ミスに起因して意図しないドメイン名が事前登録されることを抑制できるようになる。

＜第４の実施形態＞
上述の実施形態では管理者等のユーザがドメイン名を入力する場合を例示した。第４の実施形態では、第１の実施形態の制御に加えて、管理者等のユーザがＭＦＰ２００の機能と、通信に使用すべき通信インタフェースを明示的に対応付けている場合の制御を考える。

図１３は第４の実施形態を説明するための図であり、図１３（Ａ）はＭＦＰ２００が提供する機能と、通信に使用すべきインタフェースの対応関係を設定する設定画面の一例である。ユーザは、当該画面を介して各機能が外部と通信する際に使用すべき通信インタフェースを事前登録することができる。例えば、デバイス管理アプリケーション１０１０ｃと管理サーバとより提供される機器管理機能を有効にする場合、サブネットワークであるネットワーク２経由で管理サーバと通信したい場合がある。この場合、管理者等のユーザは機器情報管理機能が使用すべき通信インタフェースとしてネットワーク２（インターネット）を設定する。また、所定のクラウドプリント機能においても同様に、サブネットワークであるネットワーク２経由でクラウドプリントサーバと通信したい場合がある。この場合、管理者等のユーザは所定の種類のクラウドプリント機能（例えば、クラウドプリントＡ）が使用すべき通信インタフェースとしてネットワーク２（インターネット）を設定する。図１３（Ａ）を介してなされた設定値は、機能別インタフェース設定として、設定値ＤＢ１０５０に格納される。

また、図１３（Ａ）に例示した各機能では、外部サーバやクラウドサーバに対するデータの送信やジョブの問い合わせ処理が発生する。図１３（Ｂ）は、設定値ＤＢ１０５０に記憶される各機能が通信する外部サーバのホスト名のリストを示している。例えば、機器情報管理機能では、「ｐｒｉｎｔｅｒ＿ｍａｉｎｅｎａｎｃｅ．ｅｘａｍｐｌｅ３．ｊｐ」といったホスト名で識別されるサーバと通信を行うことが予め決められている。また、クラウドプリントＡでは、「ｃｌｏｕｄｐｒｉｎｔｅｒａｂｃ．ｅｘａｍｐｌｅ４．ｊｐ」といったホスト名で識別されるサーバと通信を行うことが予め決められている。また、クラウドプリントＢでは、「ｃｌｏｕｄｐｒｉｎｔｅｒｄｅｆ．ｅｘａｍｐｌｅ５．ｊｐ」といったホスト名で識別されるサーバと通信を行うことが予め決められている。なお、本実施形態では、一例として１つの機能に１つのホスト名が対応付けられている場合を例示しているがこれに限定されるものではない。１つの機能が複数の外部装置と通信する場合は、１つの機能に複数のホスト名が対応付けられていてもよい。また、複数のホスト名で特定される各サーバは、異なるドメインに属していてもよい。

このように、ＭＦＰ２００の提供する機能によっては、通信先のホスト名や当該ホスト名で特定される外部サーバが属するドメインが事前に決まっている。この際に外部サーバのホスト名の名前解決も機能ごとに指定された通信インタフェースが参加するネットワーク上のＤＮＳサーバに依頼すると、事前登録の手間をより簡略化することができる。

第４の実施形態では、図１３で例示した設定に基づき、ホスト名の名前解決に使用すべきＤＮＳサーバを特定し、ドメイン名と問合せ先のＤＮＳサーバの対応関係を自動的に登録する仕組みについて説明する。具体的な制御について図１４と図１３（Ｃ）を用いて説明する。

図１４のフローチャートに示す各動作（ステップ）は、ＣＰＵ２０２がＲＯＭ２０４またはストレージ２０５に記憶された各制御モジュールを実現するためのプログラムをＲＡＭ２０３に呼び出し、実行することにより実現される。なお、データの送受信処理などは、各通信Ｉ／Ｆと協働して実現されるものとする。また、処理の主体を明確にしたいケースにおいては、ＣＰＵ２０２により実行されるソフトウェアモジュールを主語として説明する。図１４の処理は、図５（Ａ）のファイル生成処理に代えて実行されるフローチャートであり、図５（Ａ）との差異は、Ｓ１４０１の取得ステップの後に、追加ステップ（Ｓ１４１１）が新たに追加されている点である。

Ｓ１４０１において、設定制御部１０４０は、ネットワーク２のＤＮＳサーバ設定及び、ネットワーク２のＤＮＳサーバに名前解決を依頼すべきドメインリストを取得する。

続けて、Ｓ１４１１において、設定制御部１０４０は、機能別インタフェースの設定値を参照する。続けて、使用すべき通信インタフェースとして、ネットワーク２が指定されている機能を特定する。続けて、当該特定された機能に対応付けて記憶されているホスト名を設定値ＤＢ１０５０から取得する。当該ホスト名に対応するドメイン名を導出し、Ｓ１４０１で取得したドメインリストに追加する。例えば、図１３（Ａ）の設定がなされている場合、図１３（Ｂ）のホスト名に基づき、ドメインリストに「ｅｘａｍｐｌｅ４．ｊｐ」及び「ｅｘａｍｐｌｅ３．ｊｐ」を追加する。設定制御部１０４０は、追加が完了すると処理をＳ１４０２に進める。Ｓ１４０２～Ｓ１４０５の処理は、第１の実施形態におけるＳ５０２～Ｓ５０５の処理と同様のドメインリストに基づく転送ルールの生成処理を行う。図１３（Ｃ）はＳ１４０１、Ｓ１４１１、Ｓ１４０２～Ｓ１４０５の処理に基づき生成される設定ファイルの一例である。図７（Ｂ）で説明した設定ファイルの各記述と比較して、１３３０に示す設定が新たに追記されている。この設定がＤＮＳキャッシュサーバ１０３０に読みこまれることで、適切なＤＮＳサーバに名前解決依頼の転送を行えるようになる。

なお、Ｓ１４１１において、下位のドメイン名を特定せず、ＦＱＤＮ形式のホスト名をドメインリストに登録するように構成してもよい。

また、第４の実施形態では第１の実施形態に加えて設定に応じた自動登録を行う場合を例示したがこれに限定されるものではない。例えば、第３の実施形態のインポート機能を有するＭＦＰ２００に、自動登録の制御を組みわせることもできる。また、第２の実施形態のチェック処理を第４の実施形態に組み合わせることもできる。この場合、設定制御部１０４０は、図１３の画面を介してネットワーク２に対応するチェックボックスを選択する操作を受け付けたことに応じて、第２の実施形態の図９で説明したチェック処理を行えばよい。

＜変形例＞
本実施形態では、起動時に設定ファイルを生成する場合を例示したが設定ファイルの生成のタイミングはこれに限定されるものではない。例えば、設定制御部１０４０は、前述した画面６１０、画面１１００、画面１３００等の画面を介して設定の変更を決定する操作を受け付けた場合に、設定ファイルを生成するようにしてもよい。この場合、設定制御部１０４０は、ネットワーク設定の変更中であることを示す画面を操作パネル２１１に表示するとともに、設定ファイルを生成する。生成が完了すると、ＯＳ１０２０と協働して、ＤＮＳクライアント及びＤＮＳキャッシュサーバの再起動処理を行う。なお、再起動処理はＭＦＰ２００全体を再起動する処理であってもよい。この変形例によれば、起動時に都度ファイルを生成する演算コストを低減することができ、ＭＦＰ２００の起動に係る時間を短くすることができる。

＜その他の実施形態＞
本発明は、上述の各実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣやＦＰＧＡ）によっても実現可能である。

２００ ＭＦＰ
２０２ ＣＰＵ
２１２ 通信Ｉ／Ｆ
２１３ 通信Ｉ／Ｆ

Claims (15)

1. 複数の異なる通信インタフェースを介して外部にデータを送信可能な通信装置であって、
   ドメイン名と、当該ドメイン名に対応するドメインに属する外部装置との通信に利用すべき通信インタフェースの対応関係の登録を受け付ける受付手段と、
   前記登録された対応関係に基づいて、ドメイン名と、当該ドメイン名に対応するドメインに属する外部装置のホスト名の名前解決を転送すべきＤＮＳサーバの対応関係を示す設定を生成する生成手段と、
   ＤＮＳキャッシュサーバを起動する起動手段と、
   を有し、
   前記起動手段によって起動された前記ＤＮＳキャッシュサーバは、前記生成手段で生成された設定に基づき動作し、
   前記通信装置が有するアプリケーションから名前解決を依頼されたＤＮＳクライアントは、前記起動手段で起動したＤＮＳキャッシュサーバに名前解決の依頼を送信し、
   前記ＤＮＳキャッシュサーバは、受信した前記名前解決の依頼に含まれるホスト名に基づいて、名前解決を依頼する外部のＤＮＳサーバを決定し、当該決定したＤＮＳサーバに名前解決を依頼することを特徴とする通信装置。
2. 前記通信装置において、１つの通信インタフェースが有効化され、他の通信インタフェースが有効化されていない場合、前記起動手段は前記ＤＮＳキャッシュサーバを起動せず、
   前記ＤＮＳクライアントは、前記有効化された通信インタフェースに対して設定されたＤＮＳサーバに対して名前解決を依頼することを特徴とする請求項１に記載の通信装置。
3. 前記ＤＮＳキャッシュサーバは、インターナルループバックで送信された名前解決の依頼を処理するよう構成され、前記通信装置の外部からの名前解決の依頼は処理しないよう構成されることを特徴とする請求項１又は２に記載の通信装置。
4. 当該ドメイン名で特定される外部装置との通信に利用すべき通信インタフェースの対応関係の登録を受け付けた場合に、当該ドメイン名を前記通信インタフェースに対応付けられたＤＮＳサーバに当該ドメイン名を名前解決する依頼を送信し、名前解決が成功するか否かを判定する判定手段を更に有し、
   前記判定手段による名前解決が失敗したことに従って、前記対応関係を登録するか否かユーザに問い合わせる表示アイテムを表示する表示制御手段を更に有することを特徴とする請求項１乃至３のいずれか１項に記載の通信装置。
5. 前記受付手段は、第１の通信インタフェースに関する設定画面を介して、当該第１の通信インタフェースを介してネットワーク上の外部装置との通信に使用したいドメイン名の入力を受け付け、ドメイン名と、当該ドメイン名に対応するドメインに属する外部装置との通信に利用すべき通信インタフェースの対応関係の登録を受け付けることを特徴とする請求項１乃至４のいずれか１項に記載の通信装置。
6. 前記設定画面には、更にファイルを選択する表示アイテムが表示され、前記受付手段は、更に前記表示アイテムを介してドメイン名を列挙したファイルを選択するユーザ操作を受け付け、当該選択されたファイルに列挙されているドメイン名と、当該ドメイン名に対応するドメインに属する外部装置との通信に利用すべき通信インタフェースの対応関係の登録を受け付けることを特徴とする請求項５に記載の通信装置。
7. 原稿を読み取る読取手段を更に有することを特徴とする請求項１乃至６のいずれか１項に記載の通信装置。
8. 前記通信装置は、前記読取手段で原稿を読み取ることで得られた画像を外部装置に送信する送信アプリケーションを有しており、
   前記送信アプリケーションで使用する送信宛先としてホスト名が指定され、前記原稿を読み取ることで得られた画像に基づくデータの送信を開始するユーザ操作を受け付けた場合、前記送信アプリケーションは前記ＤＮＳクライアントに対して、当該ホスト名の名前解決を依頼することを特徴とする請求項７に記載の通信装置。
9. 前記通信装置は、所定の種類のクラウドプリントサービスから印刷データを取得して印刷するクラウドプリントアプリケーションを有しており、
   前記クラウドプリントアプリケーションが前記所定の種類のクラウドプリントサービスにジョブに関する問い合わせを行う場合に、前記クラウドプリントアプリケーションは前記ＤＮＳクライアントに対して、当該所定の種類のクラウドプリントサービスに対応するホスト名の名前解決を依頼することを特徴とする請求項１乃至８のいずれか１項に記載の通信装置。
10. 前記複数の異なる通信インタフェースは、プライマリネットワークとして機能する通信インタフェースと、セカンダリネットワークとして機能する通信インタフェースが少なくとも含まれており、
    前記所定の種類のクラウドプリントサービスに関する動作設定として当該クラウドプリントサービスとの通信に用いる通信ネットワークを設定する設定手段と、
    前記所定の種類のクラウドプリントサービスを使用する設定が有効に設定された場合であって、前記設定手段により当該クラウドプリントサービスとの通信に用いる通信ネットワークとして、セカンダリネットワークとして機能する通信インタフェースが設定された場合、前記生成手段は、前記所定の種類のクラウドプリントサービスに対応する１以上のドメイン名と、前記設定手段により設定されたセカンダリネットワークとして機能する通信インタフェースに対応するＤＮＳサーバとの対応関係を示す設定を更に生成することを特徴とする請求項９に記載の通信装置。
11. 前記通信装置は、前記通信装置の稼働情報を外部サーバに送信する管理アプリケーションを有しており、
    前記管理アプリケーションが前記外部サーバに稼働情報の送信を行う場合に、前記管理アプリケーションは前記ＤＮＳクライアントに対して、当該外部サーバに対応するホスト名の名前解決を依頼することを特徴とする請求項１乃至９のいずれか１項に記載の通信装置。
12. 前記複数の異なる通信インタフェースには、プライマリネットワークとして機能する通信インタフェースと、サブネットワークとして機能する通信インタフェースが少なくとも含まれており、
    前記管理アプリケーションの動作設定として稼働情報の送信に用いる通信ネットワークを設定する設定手段と、
    前記管理アプリケーションを使用する設定がなされた場合であって、前記設定手段により前記稼働情報の送信に用いる通信ネットワークとして、セカンダリネットワークとして機能する通信インタフェースが設定された場合、前記生成手段は、前記外部サーバに対応する１以上のドメイン名と、前記設定手段により設定されたセカンダリネットワークとして機能する通信インタフェースに対応するＤＮＳサーバとの対応関係を示す設定を更に生成することを特徴とする請求項１１に記載の通信装置。
13. 前記ＤＮＳキャッシュサーバは、外部のＤＮＳサーバによる名前解決が成功し、ＩＰアドレスが取得できた場合、当該名前解決の結果をキャッシュすることを特徴とする請求項１乃至１２のいずれか１項に記載の通信装置。
14. 複数の異なる通信インタフェースを介して外部にデータを送信可能な通信装置のコンピュータを、
    ドメイン名と、当該ドメイン名に対応するドメインに属する外部装置との通信に利用すべき通信インタフェースの対応関係の登録を受け付ける受付工程と、
    前記登録された対応関係に基づいて、ドメイン名と、当該ドメイン名に対応するドメインに属する外部装置のホスト名の名前解決を転送するＤＮＳサーバの対応関係を示す設定を生成する生成工程と、
    ＤＮＳキャッシュサーバを起動する起動工程と、
    として機能させるためのプログラムであって、
    前記起動工程で起動された前記ＤＮＳキャッシュサーバは、前記生成工程で生成された設定に基づき動作し、
    前記通信装置が有するアプリケーションから名前解決を依頼されたＤＮＳクライアントは、前記起動工程で起動した前記ＤＮＳキャッシュサーバに名前解決の依頼を送信し、
    前記ＤＮＳキャッシュサーバは、受信した前記名前解決の依頼に含まれるドメイン名に基づいて、名前解決を依頼する外部のＤＮＳサーバを決定し、当該決定したＤＮＳサーバに名前解決を依頼することを特徴とするプログラム。
15. 複数の異なる通信インタフェースを介して外部にデータを送信可能な通信装置の制御方法であって、
    ドメイン名と、当該ドメイン名に対応するドメインに属する外部装置との通信に利用すべき通信インタフェースの対応関係の登録を受け付ける受付工程と、
    前記登録された対応関係に基づいて、ドメイン名と、当該ドメイン名に対応するドメインに属する外部装置のホスト名の名前解決を転送すべきＤＮＳサーバの対応関係を示す設定を生成する生成工程と、
    ＤＮＳキャッシュサーバを起動する起動工程と、
    を有し、
    前記起動工程で起動された前記ＤＮＳキャッシュサーバは、前記生成工程で生成された設定に基づき動作し、
    前記通信装置が有するアプリケーションから名前解決を依頼されたＤＮＳクライアントは、前記起動工程で起動した前記ＤＮＳキャッシュサーバに名前解決の依頼を送信し、
    前記ＤＮＳキャッシュサーバは、受信した前記名前解決の依頼に含まれるドメイン名に基づいて、名前解決を依頼する外部のＤＮＳサーバを決定し、当該決定したＤＮＳサーバに名前解決を依頼することを特徴とする制御方法。

Images