(57)【要約】【課題】  複数のインタフェースを有する通信端末におけるネットワーク接続性を向上させることを目的の１つとする。【解決手段】  複数の異なる通信インタフェースを介して外部にデータを送信可能なＭＦＰ２００は、名前解決のために、第１の通信インタフェースを経由してアクセス可能なＤＮＳサーバが指定されたＤＮＳクライアント１０２１と、名前解決のために、第２の通信インタフェースを経由してアクセス可能なＤＮＳサーバが指定された第２のＤＮＳクライアントと、ホスト名で指定された宛先にデータを送信する通信アプリケーションとを有する。また、通信アプリケーションは、第１の通信インタフェースを経由して宛先にデータを送信する場合と、第２の通信インタフェースを経由して宛先にデータを送信する場合とで、使用するＤＮＳクライアントを異ならせる。【選択図】  図５
2020167619.tif 000002
【特許請求の範囲】
【請求項１】
複数の異なる通信インタフェースを介して外部にデータを送信可能な通信装置であって、
名前解決のために、第１の通信インタフェースを経由してアクセス可能なＤＮＳサーバが指定された第１のＤＮＳクライアントと、
名前解決のために、第２の通信インタフェースを経由してアクセス可能なＤＮＳサーバが指定された第２のＤＮＳクライアントと、
ホスト名で指定された宛先にデータを送信する通信アプリケーションと、
を有し
前記通信アプリケーションは、前記第１の通信インタフェースを経由して前記ホスト名で指定された宛先にデータを送信する場合、前記第１のＤＮＳクライアントに前記ホスト名の名前解決を依頼し、前記第２の通信インタフェースを経由してデータを送信する場合、前記第２のＤＮＳクライアントに名前解決を依頼することを特徴とする通信端末。
【請求項２】
前記通信端末は、プロキシサーバを更に有し
前記第２のＤＮＳクライアントは、プロキシサーバの内部に設けられたＤＮＳクライアントであり、
前記通信アプリケーションは、前記第２の通信インタフェースを経由してデータを送信すると決定した場合、前記プロキシサーバに対して通信の代理を依頼し、
前記プロキシサーバは、前記依頼された通信を行う際に、前記第２のＤＮＳクライアントを用いて前記ホスト名の名前解決を行うことを特徴とする請求項１に記載の通信端末。
【請求項３】
前記通信端末は、スキャナを有し、原稿をスキャンして得られた画像を外部に送信する通信端末であることを特徴とする請求項１または２に記載の通信端末。
【請求項４】
前記プロキシサーバを経由しないホスト名を管理する管理手段を更に備え、
前記通信アプリケーションは、前記ホスト名が前記管理手段が管理するホスト名に一致していると判断したことに従って、前記ホスト名で指定された宛先に対して、前記第１の通信インタフェースを経由してデータを送信すると決定することを特徴とする請求項２に記載の通信端末。
【請求項５】
前記第２のＤＮＳクライアントは、
前記ホスト名の名前解決に失敗したことに従って、前記管理手段に前記ホスト名を登録する登録手段と、
前記ホスト名をリダイレクト先として指定した応答を前記通信アプリケーションに対して返答する返答手段と、
として更に機能することを特徴とする請求項４に記載の通信端末。
【請求項６】
複数の異なる通信インタフェースを介して外部にデータを送信可能な通信装置のコンピュータを、
名前解決のために、第１の通信インタフェースを経由してアクセス可能なＤＮＳサーバが指定された第１のＤＮＳクライアントと、
名前解決のために、第２の通信インタフェースを経由してアクセス可能なＤＮＳサーバが指定された第２のＤＮＳクライアントと、
ホスト名で指定された宛先にデータを送信する通信アプリケーションと、
として機能させるためのプログラムであって、
前記通信アプリケーションは、前記第１の通信インタフェースを経由して前記ホスト名で指定された宛先にデータを送信する場合、前記第１のＤＮＳクライアントに前記ホスト名の名前解決を依頼し、前記第２の通信インタフェースを経由してデータを送信する場合、前記第２のＤＮＳクライアントに名前解決を依頼することを特徴とするプログラム。
【請求項７】
複数の異なる通信インタフェースを介して外部にデータを送信可能な通信装置の制御方法であって、
第１の通信インタフェースを経由してアクセス可能なＤＮＳサーバを用いて名前解決を行う第１の解決工程と、
第２の通信インタフェースを経由してアクセス可能なＤＮＳサーバを用いて名前解決を行う第２の解決工程と、
ホスト名で指定された宛先に対してデータの送信を行う送信制御工程と、
を有し、
前記送信制御工程では、前記第１の通信インタフェースを経由して前記ホスト名で指定された宛先にデータを送信する場合、前記第１の解決工程に前記ホスト名の名前解決を依頼し、前記第２の通信インタフェースを経由してデータを送信する場合、前記第２の解決工程に名前解決を依頼することを特徴とする制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、外部にデータを送信する通信装置に関するものである。
【背景技術】
【０００２】
近年、ネットワークに求められるセキュリティや、機能性の複雑化に伴い、オフィスや商業施設などで複数のＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）を使い分ける構成が一般的になってきた。
【０００３】
これらのネットワークは、各ネットワークが分離されており、それぞれ独立でドメイン名を管理したりする。このようなネットワーク環境下において使用されるＭＦＰなどの通信装置に対しても、複数のネットワークに対応できることが求められてきている。
【０００４】
従来、複数のネットワークにおいて、独立に管理されているドメイン名の名前解決を行う場合、クライアント端末と独立にドメイン名管理されているネットワークの間にＤＮＳキャッシュサーバを設定する方法が知られている。複数のネットワークに接続可能なＤＮＳキャッシュサーバを設定することで、クライアント端末側はＮＷを意識することなく複数のネットワークの名前解決を実現できる（例えば、特許文献１）。
【０００５】
また、クライアント通信端末が複数のドメイン名管理が行われているネットワークに接続された環境において、ドメイン名の名前解決を効率的に行う手段が提案されている（特許文献２）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−２９７４９４号公報
【特許文献２】特開２０１０−１９３０１５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
特許文献１ではＤＮＳキャッシュサーバを設置し、ＤＮＳキャッシュサーバによって複数のＤＮＳサーバに問い合わせを行うことで複数のＤＮＳサーバによる名前解決を実現することが記載されている。
【０００８】
しかしながら、ネットワークを分離する目的で、それぞれのネットワークが独立でドメイン管理されている環境においては、それぞれのネットワークとの間にＤＮＳキャッシュサーバを設置することは現実的ではない。したがって、このような構成では、ネットワークの名前解決を実現することはできない。
【０００９】
一方、特許文献２では、複数のネットワークインタフェースを備え、一方が広域網、他方が閉域網に接続されている通信装置が記載されている。また、ネットワークインタフェース毎に名前解決に使用するＤＮＳサーバを管理する。通信装置は、広域網のＤＮＳサーバに問い合わせを試行し、ＩＰアドレスが取得できれば広域網であり、ＩＰアドレスが取得できなければ閉域網であると判断し、判断結果をネットワークリストに記憶する。当該ネットワークリストを用いて名前解決を実現する。一方で、ＬＡＮインタフェースにおいて、具体的にどのような仕組みでＤＮＳサーバを使い分けることができるのかは具体的に開示されていない。
【００１０】
一般的なＬＡＮインタフェースにおける名前解決の実現方法として一例としてＬｉｎｕｘ（登録商標）のシステムの仕様に例に挙げる。例えば、Ｌｉｎｕｘシステムにおいて、ドメイン名の名前解決を行う場合は所定のファイルにＤＮＳサーバの記載を行ってＤＮＳサーバを指定する。具体的には、「／ｅｔｃ／ｒｅｓｏｌｖｅ．ｃｏｎｆ」に位置するファイルに対して、「ｎａｍｅｓｅｒｖｅｒ  “ＤＮＳサーバのＩＰアドレス“」といった記載を行うことで利用するＤＮＳサーバを指定することができる。また、冗長化のため、ＤＮＳサーバが複数台指定することもできる。この場合「ｃｏｎｆ」ファイル内に同様の記載をＤＮＳサーバの数だけ記載すればよい。
【００１１】
しかしながら、ここで登録するＤＮＳサーバは、登録されたＤＮＳサーバから応答がない場合に代替で利用する冗長化のためのＤＮＳサーバである。そのため、ＤＮＳ名前解決を行った結果、該当する名前が見つからない場合（通信は成功した場合）は、代替で利用するＤＮＳサーバへの問い合わせは行わない。すなわち、Ｌｉｎｕｘシステムなどの一般的なＤＮＳクライアントを利用する場合、それぞれのネットワークのＤＮＳ名前解決を実現することが困難であるという課題がある。
【００１２】
本発明は上述の問題点の少なくとも１つを鑑みなされたものである。本発明の１つの側面としては、一般的なＤＮＳクライアントの仕組み（リソース）を活用しつつ、ネットワークインタフェースごとに、適切なＤＮＳサーバを用いて名前解決を行うための仕組みを提供することを目的の１つとする。また、本発明の別の側面としては、複数のインタフェースを有する通信端末におけるネットワーク接続性を向上させることを目的の１つとする。
【課題を解決するための手段】
【００１３】
上記の少なくとも１つの目的を達成するために本発明の通信端末は、複数の異なる通信インタフェースを介して外部にデータを送信可能な通信装置であって、名前解決のために、第１の通信インタフェースを経由してアクセス可能なＤＮＳサーバが指定された第１のＤＮＳクライアントと、名前解決のために、第２の通信インタフェースを経由してアクセス可能なＤＮＳサーバが指定された第２のＤＮＳクライアントと、ホスト名で指定された宛先にデータを送信する通信アプリケーションと、を有し前記通信アプリケーションは、前記第１の通信インタフェースを経由して前記ホスト名で指定された宛先にデータを送信する場合、前記第１のＤＮＳクライアントに前記ホスト名の名前解決を依頼し、前記第２の通信インタフェースを経由してデータを送信する場合、前記第２のＤＮＳクライアントに名前解決を依頼することを特徴とする。
【発明の効果】
【００１４】
本発明の１つの側面によれば、一般的なＤＮＳクライアントの仕組み（リソース）を活用しつつ、ネットワークインタフェースごとに、適切なＤＮＳサーバを用いて名前解決を行えるようになる。また、本発明の１つの側面によれば、複数のインタフェースを有する通信端末におけるネットワーク接続性を向上させることができる。
【図面の簡単な説明】
【００１５】
【図１】通信システムの一例を示す図である。
【図２】ＭＦＰ２００のハードウェア構成の一例を示す図である。
【図３】ＭＦＰ２００のソフトウェア構成の一例を示す図である。
【図４】ＭＦＰ２００の起動制御の一例を示すフローチャートである。
【図５】通信アプリケーションが実行する宛先制御の一例を示すフローチャートである。
【図６】通信アプリケーションに関連する設定画面の一例を示す図である。
【図７】ローカルプロキシサーバを用いた名前解決処理の一例を示すフローチャートである。
【図８】第２の実施形態における通信制御の一例を示すフローチャートである。
【図９】第２の実施形態における通信制御の一例を示すフローチャートである。
【図１０】第３の実施形態におけるソフトウェア構成の一例を示す図である。
【図１１】第３の実施形態における通信制御の一例を示すフローチャートである。
【図１２】第４の実施形態におけるソフトウェア構成の一例を示す図である。
【図１３】第４の実施形態における通信制御の一例を示すフローチャートである。
【発明を実施するための形態】
【００１６】
以下、本発明を実施するための実施形態について図面を用いて説明する。なお、以下の実施の形態は特許請求の範囲に係る発明を限定するものではなく、また、実施の形態で説明されている特徴の組み合わせのすべてが発明の解決手段に必須のものとは限らない。
【００１７】
＜第１の実施形態＞
まず、図１を用いて、本発明に係る通信システムの構成を説明する。本実施形態に係る通信システムには、ＭＦＰ（Ｍｕｌｔｉ  Ｆｕｎｃｔｉｏｎ  Ｐｅｒｉｐｈｅｒａｌ）２００、ＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）サーバ１００、デバイス１２０がネットワーク１を介して通信可能に接続されている。デバイス１２０には、ＤＮＳサーバ１００で管理されるホスト名が割り振られている。また、ＭＦＰ２００と、ＤＮＳサーバ１１０、デバイス１３０がネットワーク２を介して通信可能に接続されている。デバイス１３０には、ＤＮＳサーバ１１０で管理されるホスト名が割り振られている。
【００１８】
本実施形態では、ネットワーク１（３００）とネットワーク２（３１０）は、独立した異なるネットワークである場合を想定している。すなわち、ＤＮＳサーバ１００にデバイス１３０のホスト名の解決を依頼しても、当該名前解決は行えない。逆に、ＤＮＳサーバ１１０にデバイス１２０のホスト名の解決を依頼しても当該名前解決は行えない。
【００１９】
ＭＦＰ２００は、通信端末の一例である。本実施形態では、一例として印刷機能やスキャン機能を有するＭＦＰを例示しているがこれに限定されず、ＩｏＴデバイスやパーソナルコンピューター、エッジサーバなどに適用することもできる。また、デバイス１２０やデバイス１３０は、例えばファイルサーバや、ＭＦＰ２００の情報を管理する情報管理サーバなどを想定している。しかしながらこれに限定されるものではなく、基幹業務システムのサーバやクラウドサーバなどであってもよい。
【００２０】
ＭＦＰ２００は、デバイス１２０や１３０にスキャンして得られた画像に基づくデータを送信したり、ＭＦＰ２００が収集したデータを送信したりすることができる。データを送信する際に、ＭＦＰ２００は、デバイス１２０や１３０のホスト名を指定した宛先を用いて送信を行う。この際の名前解決の方法については、後述する。
【００２１】
続けて、図２を用いて、ＭＦＰ２００について説明する。図２は、ＭＦＰ２００のハードウェア構成を示すブロック図である。ＭＦＰ２００はシート上の画像を読み取る読取機能、当該読み取った画像を外部の通信装置に送信可能なファイル送信機能などを有している。また、シートに画像を印刷する印刷機能も有する。
【００２２】
ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２０２を含む制御部２０１は、ＭＦＰ２００全体の動作を制御する。ＣＰＵ２０２は、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）２０４又はＨＤＤ２０５に記憶された制御プログラムを読み出して、印刷制御や読取制御などの各種制御を行う。ＲＯＭ２０４は、ＣＰＵ２０２で実行可能な制御プログラムを格納する。ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）２０３は、ＣＰＵ２０２の主記憶メモリであり、ワークエリア又は各種制御プログラムを展開するための一時記憶領域として用いられる。ＨＤＤ２０５は、印刷データ、画像データ、各種プログラム、及び各種設定情報を記憶する。このように、ＣＰＵ２０２、ＲＯＭ２０４、ＲＡＭ２０３等のハードウェアは、いわゆるコンピュータを構成している。
【００２３】
なお、本実施形態のＭＦＰ２００では、１つのＣＰＵ２０２が１つのメモリ（ＲＡＭ２０３）を用いて後述するフローチャートに示す各処理を実行するものとするが、他の様態であっても構わない。例えば複数のプロセッサ、ＲＡＭ、ＲＯＭ、及びストレージを協働させて後述するフローチャートに示す各処理を実行することもできる。また、ハードウェア回路を用いて一部の処理を実行するようにしてもよい。
【００２４】
プリンタＩ／Ｆ２０６は、プリンタ２０７（プリンタエンジン）と制御部２０１とを接続する。プリンタ２０７は、プリンタＩ／Ｆ２０６を介して入力された印刷データに基づいて、不図示の給紙カセットから給紙されたシートに印刷処理を実行する。
【００２５】
スキャナＩ／Ｆ２０８は、スキャナ２０９と制御部２０１とを接続する。スキャナ２０９は、載置された原稿を読み取り、そして画像データを生成する。スキャナ２０９が生成した画像データは、プリンタ２０７で印刷されたり、ＨＤＤ２０５に記憶されたり、ＦＡＸ  Ｉ／Ｆ２１４や有線ＬＡＮ  Ｉ／Ｆ２１２、２１３を介して外部装置に送信されたりする。
【００２６】
操作パネルＩ／Ｆ２１０は、操作パネル２１１と制御部２０１とを接続する。操作パネル２１１には、タッチパネル機能を有する液晶表示部や各種ハードキーなどが備えられ、情報を表示する表示部やユーザの指示を受け付ける受付部として機能する。
【００２７】
有線ＬＡＮ  Ｉ／Ｆ２１２、２１３には、ネットワークケーブルが接続され、外部装置とネットワークを経由した通信を実行することができる。
【００２８】
有線ＬＡＮ  Ｉ／Ｆ２１２は、ＭＦＰ２００が備える第１の通信インタフェースであり、ネットワーク１に接続されている。有線ＬＡＮ  Ｉ／Ｆ２１２は、ＭＦＰ２００が備える第２の通信インタフェースであり、ネットワーク２に接続されている。
【００２９】
本実施形態では、有線ＬＡＮ  Ｉ／Ｆ２１２、２１３がイーサネット（登録商標）に準拠する有線通信を行う通信インタフェースである場合を想定しているがこれに限定されるものではない。例えば、一方がＩＥＥＥ８０２．１１シリーズに準拠する無線通信インタフェースであってもよい。また、両方が無線通信インタフェースであってもよい。
【００３０】
ＦＡＸ  Ｉ／Ｆ２１４には、電話回線ケーブルが接続され、アナログやＩＳＤＮ通信で電話回線網に接続される。
【００３１】
続けて、図３を用いて、ＭＦＰ２００のソフトウェア構成について説明する。
【００３２】
通信アプリケーション１０１０はネットワーク１（３００）のデバイス１２０とネットワーク２（３１０）のデバイス１３０と通信を行うアプリケーションである。例えば、通信アプリケーションは、ＷｅｂＤＡＶなどのＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）ベースの通信でデバイスに対してデータを送信する送信アプリケーションである。送信アプリケーションは、スキャナ２０９で原稿を読み取って得られた画像に基づくファイルを外部に送信することができる。なお、第１の実施形態において、通信アプリケーションがどちらのインタフェースを使用するかはあらかじめユーザ操作などに基づき設定されているものとする。
【００３３】
オペレーティングシステム１０２０はネットワーク通信を行うためのＴＣＰ／ＩＰプロトコルスタックや、ＤＮＳの名前解決を行うためのＯＳ標準ＤＮＳクライアント１０２１も含む。本実施形態では、ＤＮＳクライアント１０２１は、Ｌｉｎｕｘ（登録商標）システムにおける標準のＤＮＳクライアントである場合を想定している。これらのクライアントを用いてドメイン名の名前解決を行う場合、「／ｅｔｃ／ｒｅｓｏｌｖｅ．ｃｏｎｆ」に位置するファイルに対して、「ｎａｍｅｓｅｒｖｅｒ  “ＤＮＳサーバのＩＰアドレス“」といった記載を行ってＤＮＳサーバを指定する。冗長化のため、利用するＤＮＳサーバを複数指定することもできる。しかしながら、ここで登録するＤＮＳサーバは、登録されたＤＮＳサーバから応答がない場合に代替で利用する冗長化のためのＤＮＳサーバである。そのため、ＤＮＳ名前解決を行った結果、該当する名前が見つからない場合（通信は成功した場合）は、代替で利用するＤＮＳサーバへの問い合わせは行わない。すなわち、ＬｉｎｕｘシステムのＤＮＳクライアントを利用する場合、それぞれのネットワークのＤＮＳ名前解決を実現すること困難であるという問題点がある。
【００３４】
本実施形態では、上述の問題点の少なくとも１つを鑑み、ＭＦＰ２００内部に独立した内部ＤＮＳクライアントを備えるプロキシサーバ１０３０を用いて名前解決を行う仕組みについて説明する。具体的には、ネットワーク２に送信するＨＴＴＰ／ＨＴＴＰＳ通信をすべてプロキシサーバ経由の通信に割り当て、プロキシサーバ１０３０に代理で名前解決を行わせることで、ホスト名の名前解決を円滑に行えるようにする。なお、プロキシサーバがその他のプロトコルに対応している場合、そのほかの通信についてもプロキシサーバ１０３０経由で通信するようにしてもよい。以降、ＨＴＴＰ通信又はＨＴＴＰＳ（ＨＴＴＰ  ｏｖｅｒ  ＳＳＬ／ＴＬＳ）通信を行うことを、ＨＴＴＰ（Ｓ）と呼ぶものとする。
【００３５】
以下具体的な仕組みについて説明する。プロキシサーバ１０３０はＷｅｂサイトの閲覧の高速化や、アクセス可能なＷｅｂサイトの制御を行うために、Ｗｅｂサイトへの接続要求（ＨＴＴＰやＨＴＴＰＳ通信）を受信するとそのＷｅｂサイトに対して代理で接続して、通信を行う機能を提供する。本実施形態では、Ｓｑｕｉｄやｄｅｌｅｇａｔｅとソフトウェアモジュールでプロキシサーバを構築することを想定している。
【００３６】
プロキシサーバ１０３０はプロキシサーバ専用のＤＮＳクライアントであるプロキシサーバ内部ＤＮＳクライアント１０３１を備え、ＯＳ標準ＤＮＳクライアント１０２１とは別系で名前解決を行うことができる。
【００３７】
ＤＮＳ設定制御１０４０はＯＳ標準ＤＮＳクライアント１０２１とプロキシサーバ内部ＤＮＳクライアント１０３１に対して、クライアントが参照すべきＤＮＳサーバを設定する機能を提供する。具体的には、ＯＳ標準ＤＮＳクライアント１０２１にはネットワーク１（３００）のＤＮＳ名を管理するＤＮＳサーバ１００を通信先として割り当てる。一方、プロキシサーバ内部ＤＮＳクライアント１０３１には、ネットワーク２（３１０）のＤＮＳ名を管理するＤＮＳサーバ１１０を通信先として割り当てる。つまり、ＯＳ標準ＤＮＳクライアント１０２１はネットワーク１のＤＮＳ名前解決が可能となり、プロキシサーバ内部ＤＮＳクライアント１０３１はネットワーク２のＤＮＳ名前解決が可能となるように設定を行う。
【００３８】
設定値ＤＢ１０５０はＤＮＳ設定や通信アプリケーションの設定値を保管するデータベースである。
【００３９】
具体的な制御について図４、図５、図７のフローチャートを用いて説明する。図４、図５、図７のフローチャートに示す各動作（ステップ）は、ＣＰＵ２０２がＲＯＭ２０４またはＨＤＤ２０５に記憶された各制御モジュールを実現するためのプログラムをＲＡＭ２０３に呼び出し、実行することにより実現される。なお、データの送受信処理などは、各通信部Ｉ／Ｆと協働して実現されるものとする。また、処理の主体を明確にしたいケースにおいては、ＣＰＵ２０２により実行されるソフトウェアモジュールを主語として説明する。
【００４０】
図４はＭＦＰ２００が起動する際や、ＤＮＳ設定が変更された場合に実行されるＤＮＳ設定制御１０４０が主体となって実行する処理フローを示したものである。
【００４１】
Ｓ４０１において、ＤＮＳ設定制御１０４０は、ＤＮＳ設定処理を開始すると、ＯＳ標準ＤＮＳ１０２１に対して、ネットワーク１のＤＮＳサーバを設定する。ネットワーク１のＤＮＳサーバ情報は、設定値ＤＢ１０５０に保存された情報を利用される。
【００４２】
Ｓ４０２において、ＤＮＳ設定制御１０４０は、ＭＦＰ２００がネットワーク１以外に接続しているかを判断する。ネットワーク１（３００）以外に接続があると判断した場合、Ｓ４０３に進む。一方、ネットワーク１以外に接続がない（第１の通信インタフェースのみを使用する設定である）と判断した場合、一連のＤＮＳ設定処理を終了する。
【００４３】
Ｓ４０３において、ＤＮＳ設定制御１０４０は、プロキシサーバ１０３０を起動するととともに、ネットワーク２で利用するＤＮＳクライアントであるプロキシサーバ１０３０内部ＤＮＳクライアント１０３１にネットワーク２のＤＮＳサーバを設定する。ネットワーク２のＤＮＳサーバ情報は、設定値ＤＢ１０５０に保存された情報を利用する。以上で、ネットワーク１、ネットワーク２で利用するそれぞれのＤＮＳクライアントに対する設定は完了となりそれぞれのネットワークでのＤＮＳ名前解決が可能な状態に遷移する。
【００４４】
続いて、通信アプリケーション１０１０がホスト名を宛先として指定したＨＴＴＰ／ＨＴＴＰＳ通信を行う場合の処理について、図５のフローチャート及び図６の操作画面を用いて説明する。
【００４５】
図６は、操作パネル２１１に表示される、通信アプリケーションに関する設定画面の一例である。図６の設定画面を介して、ユーザは、通信アプリケーションが利用するインタフェースを設定することができる。「インタフェース１（ネットワーク１）」が選択されると、有線ＬＡＮ  Ｉ／Ｆ２１２を用いて通信する設定となる。また、「インタフェース２（ネットワーク２）」が選択されると、有線ＬＡＮ  Ｉ／Ｆ２１３を用いて通信する設定となる。当該設定は、前述の設定値ＤＢ１０５０に記憶される。通信アプリケーション１０１０は、当該設定に基づき出力先のインタフェースを決定する。
【００４６】
続いて、図５のフローチャートを用いて通信アプリケーションがホスト名を指定した外部宛先にデータをＨＴＴＰ又はＨＴＴＰＳ送信で送信する場合の制御について説明する。
【００４７】
Ｓ５００において、通信アプリケーション１０１０は、設定値ＤＢ１０５０を参照し、通信インタフェース選択状態を判断する。インタフェース１（Ｉ／Ｆ２１２）が指定されている場合は、処理をＳ５０１に進め、インタフェース２（Ｉ／Ｆ２１３）が指定されている場合は、処理をＳ５０５に進める。
【００４８】
Ｓ５０１において、通信アプリケーション１０１０は、ネットワーク１用のＯＳ標準ＤＮＳクライアント１０２１に対してＤＮＳ名前解決を依頼する。なお、通信宛先がＩＰアドレスで指定されている場合、Ｓ５０１〜Ｓ５０２の処理はスキップされ、直接Ｓ５０３の通信に進むものとする。
【００４９】
Ｓ５０２において、通信アプリケーション１０１０は、ＯＳ標準ＤＮＳクライアント１０２１に依頼したＤＮＳ名前解決の結果に基づき、名前解決に成功したかどうかを判断する。名前解決が成功した場合、処理をＳ５０３に進め、名前解決に失敗した場合、処理をＳ５０４に進める。なお、名前解決に成功すると、通信相手先のＩＰアドレスが得られる。
【００５０】
Ｓ５０３において、通信アプリケーション１０１０は、ＯＳ１０２０及びＬＡＮ  Ｉ／Ｆ２１２と協働して、指定された宛先に対するＨＴＴＰ（Ｓ）通信を実行する。実行が完了すると一例の処理を終了する。
【００５１】
Ｓ５０４において、通信アプリケーション１０１０はエラーを表示する。例えば、通信が行えなかったことを示すメッセージやエラー音などを出力する。
【００５２】
続けて、ネットワーク２（Ｉ／Ｆ２１３）が選択された場合の処理を説明する。Ｓ５０５において、通信アプリケーション１０１０は、ローカルプロキシサーバ１０３０に対して、ＨＴＴＰ（Ｓ）リクエストを転送する。Ｓ５０５の処理の詳細は、図７を用いて後述する。Ｓ５０６において、通信アプリケーション１０１０は、ローカルプロキシサーバからの応答を受信し、当該応答に基づき通信結果を表示する。
【００５３】
続けて、ＭＦＰ２００のローカルプロキシサーバ１０３０がＨＴＴＰ（Ｓ）リクエストを受信した時の転送処理について図７のフローチャートを用いて説明する。
【００５４】
Ｓ７００において、ローカルプロキシサーバ１０３０は通信アプリケーション１０１０から転送されたＨＴＴＰ（Ｓ）リクエストを受信し、ＤＮＳクライアント１０３１を用いて当該リクエストに含まれるＵＲＬを名前解決する。なお、内部ＤＮＳクライアント１０３１の問い合わせ先には、ＤＮＳサーバ１１０が指定されている。従って、当該ＵＲＬに対応するＩＰアドレスをＤＮＳサーバ１１０に問い合わせる。
【００５５】
Ｓ７０１において、ローカルプロキシサーバ１０３０は、ＤＮＳサーバからの応答に基づき宛先として指定されたＵＲＬ（即ちホスト名）の名前解決に成功したか否かを判断する。名前解決が成功した場合は処理をＳ７０２に進め、名前解決に失敗した場合は処理をＳ７０３に進める。
【００５６】
Ｓ７０２において、ローカルプロキシサーバ１０３０は、名前解決の結果得られた宛先に対してＨＴＴＰ（Ｓ）通信を行い、その応答結果を通信アプリケーション１０１０に応答し、一連の制御を終了する。Ｓ７０３において、ローカルプロキシサーバ１０３０は、ＨＴＴＰ（Ｓ）通信が行えなかったことを示すエラー情報を通信アプリケーション１０１０に対して応答し、一連の処理を終了する。
【００５７】
以上説明した通り、本実施形態では、ＬＡＮ  Ｉ／Ｆ２１３に接続されたネットワーク２に送信するＨＴＴＰ／ＨＴＴＰＳ通信をすべてプロキシサーバ経由で通信するよう制御する。その結果として、プロキシサーバ１０３０が内部に備えるＤＮＳクライアントに名前解決を行わせることができ、ホスト名の名前解決を円滑に行えるようになる。
【００５８】
＜第２の実施形態＞
第１の実施形態では、通信アプリケーション１０１０の設定として、いずれのＬＡＮ  Ｉ／Ｆを経由して通信するかをあらかじめ設定しておく場合について説明した。また、当該設定に基づき通信アプリケーション１０１０がプロキシサーバにＨＴＴＰ通信の転送を依頼するか、プロキシサーバを経由しない通信を試みるかを切り替える仕組みについて説明した。
【００５９】
第２の実施形態では、事前の設定が行われていない通信アプリケーションであっても適切に名前解決を行える仕組みを提供する。具体的には、ＬＡＮ  Ｉ／Ｆ２１３側で名前解決ができるかどうかを一旦試行し、できない場合は、プロキシサーバを利用しないホスト名を記載する除外リストに当該名前解決に失敗したホスト名を追加する。
【００６０】
なお、ハードウェア構成及びソフトウェア構成は第１の実施形態と同様であるため、説明を省略する。
【００６１】
具体的な制御について図８及び図９のフローチャートを用いて説明する。図８及び図９のフローチャートに示す各動作（ステップ）は、ＣＰＵ２０２がＲＯＭ２０４またはＨＤＤ２０５に記憶された各制御モジュールを実現するためのプログラムをＲＡＭ２０３に呼び出し、実行することにより実現される。なお、データの送受信処理などは、各通信部Ｉ／Ｆと協働して実現されるものとする。また、処理の主体を明確にしたいケースにおいては、ＣＰＵ２０２により実行されるソフトウェアモジュールを主語として説明する。
【００６２】
図８は、第１の実施形態の図５のフローチャートに代えて実行される通信アプリケーションの制御である。
【００６３】
Ｓ８００において、通信アプリケーション１０１０は、ローカルプロキシサーバ１０３０に対応する除外リストを設定値ＤＢ１０５０から取得する。
【００６４】
なお、除外リストは、ローカルプロキシサーバを利用せずに直接接続するホストの一覧が記載されている。なお、当該除外リストへの新規登録は、管理者などの権限を有するユーザによって行われる。また、後述する図９のフローチャートにおいて、通信に失敗した場合にも新規登録が行われる。
【００６５】
Ｓ８０１において、通信アプリケーション１０１０は、Ｓ８００で取得した除外リストに宛先ＵＲＬのホスト名が含まれているか否かを判断する。除外リストに当該宛先ＵＲＬのホスト名が含まれている場合、処理をＳ８０４に進め、除外リストに当該宛先ＵＲＬのホスト名が含まれていない場合、処理をＳ８０２に進める。Ｓ８０１の処理は、宛先ＵＲＬのホスト名が除外リスト内のホスト名に一致するかどうかを判断する処理である。
【００６６】
Ｓ８０２において、通信アプリケーション１０１０は、ローカルプロキシサーバ１０３０にＨＴＴＰ（Ｓ）リクエストを転送する。続けて、Ｓ８０３において、通信アプリケーション１０１０は、ローカルプロキシサーバ１０３０から通信結果を示す応答を受信する。
【００６７】
一方、Ｓ８０４において、通信アプリケーション１０１０は、ＯＳ標準ＤＮＳクライアント１０２１と協働して、宛先を示すホスト名の名前解決を行う。通信アプリケーション１０１０は、名前解決に成功すると処理をＳ８０５に進める。なお、名前解決に失敗した場合は、エラーを表示して一連の処理を終了するものとする。
【００６８】
Ｓ８０５において、通信アプリケーション１０１０は、Ｓ８０４で取得したＩＰアドレスに対してＨＴＴＰ（Ｓ）リクエストを送信する。
【００６９】
上述の処理について一例として除外リストに、「ｅｘａｍｐｌｅ．ｃｏｍ」というホスト名が設定されている場合を例に説明する。通信アプリケーション１０１０は「ｈｔｔｐ：／／  ｅｘａｍｐｌｅ．ｃｏｍ」に接続する場合は、除外リストに含まれている宛先であるため、ローカルプロキシサーバ１０３０を利用せず直接ＨＴＴＰ（Ｓ）通信を行う。また、通信アプリケーション１０１０は除外リストに記載されていない「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｎｅｔ」に接続する場合には、ローカルプロキシサーバ１０３０に対してＨＴＴＰ（Ｓ）の要求を送信する。
【００７０】
続けて、Ｓ８０６において、通信アプリケーション１０１０は、受信したＨＴＴＰ（Ｓ）の応答がリダイレクト応答であるか否かを判断する。受信したＨＴＴＰ（Ｓ）の応答がリダイレクト応答である場合は、処理をＳ８０７に進め、受信したＨＴＴＰ（Ｓ）の応答がリダイレクト応答でない場合は、一連の送信制御を終了する。
【００７１】
なお、リダイレクト応答とは、ＨＴＴＰのステータスコード３０１もしくは３０２を意味する。この場合、Ｓ８０７の処理に進みリダイレクト先ＵＲＬへのアクセスを試みる。
【００７２】
Ｓ８０７において、新たなＨＴＴＰ（Ｓ）リクエストの宛先として、受信したＨＴＴＰ応答のＬｏｃａｔｉｏｎヘッダに指定された宛先を設定する。設定が完了すると、Ｓ８００の処理に戻り、リダイレクト先の宛先ホスト名への通信を試みる。
【００７３】
次に、ローカルプロキシサーバ１０３０の制御について図９のフローチャートを用いて説明する。図９は、第１の実施形態における図７の制御に代えて実行される制御の一例である。
【００７４】
Ｓ９００において、ローカルプロキシサーバ１０３０は、内部ＤＮＳクライアント１０３１を用いて通信アプリケーションで指定された宛先（ホスト名）の名前解決を行う。
【００７５】
Ｓ９０１において、ローカルプロキシサーバ１０３０は、名前解決に成功したかどうかを判断する。名前解決に成功した場合は、処理をＳ９０２に進め、名前解決に失敗した場合は、処理をＳ９０３に進める。
【００７６】
Ｓ９０２において、名前解決の結果得られたＩＰアドレスを用いてＨＴＴＰ（Ｓ）通信を行い、その応答を通信アプリケーション１０１０に応答する。
【００７７】
Ｓ９０３において、ローカルプロキシサーバ１０３０は、自身が管理する除外リストに、名前解決に失敗したホスト名を新規登録する。
【００７８】
例えば、ローカルプロキシサーバが「ｈｔｔｐ：／／ｅｘａｍｐｌｅ２／ｔｅｓｔ」に対するリクエストを受信し、当該宛先の名前解決に失敗した場合、除外リストに「ｅｘａｍｐｌｅ２」を登録する。Ｓ９０３の処理により、次回以降に同じドメイン名が指定された場合は、ローカルプロキシサーバを経由しない通信を行えるようになる。
【００７９】
続けて、Ｓ９０４において、ローカルプロキシサーバ１０３０は、ＨＴＴＰ（Ｓ）のリダイレクト応答を作成し、通信アプリケーション１０１０に対して当該応答を返答する。送信が完了すると、一連の名前解決処理が完了する。
【００８０】
なお、このリダイレクト応答には、ＨＴＴＰレスポンスのステータスコードに、３０１もしくは３０２が設定され、リダイレクト先を示すＬｏｃａｔｉｏｎヘッダにＳ９０３で名前解決に失敗したホスト名が設定される。
【００８１】
例えば、「ｈｔｔｐ：／／ｅｘａｍｐｌｅ２／ｔｅｓｔ」に対するリクエストである場合、ローカルプロキシサーバは、ＨＴＴＰのステータスコードに３０１を設定する。更に、ＨＴＴＰヘッダに「Ｌｏｃａｔｉｏｎ  ：  ｈｔｔｐ：／／ｅｘａｍｐｌｅ２／ｔｅｓｔ」を設定した応答データを送信する。
【００８２】
以上説明したように、ローカルプロキシサーバが宛先のホスト名の名前解決を行えない場合、ローカルプロキシーの除外リストに宛先を登録する。したがって、次回以降のアクセスでは、当該宛先に関しては、ローカルプロキシサーバに対して要求が行われないようになる。
【００８３】
さらに、除外リストに新規登録した宛先に別のネットワークを介した接続を試行するため、リダイレクト処理を行う。この処理により、今度はＯＳ標準のＤＮＳクライアントを利用してネットワーク１上のＤＮＳサーバを用いた名前解決を行える。
【００８４】
従って、通信アプリケーション１０１０等に代表されるＭＦＰ２００の各アプリケーションは、通信インタフェースを意識することなく、適切なネットワークを利用して名前解決を行って、通信を行うことができるようになる。
【００８５】
＜第３の実施形態＞
第１及び第２の実施形態では、ローカルプロキシサーバ１０３０を用いることにより、ＨＴＴＰ又はＨＴＴＰＳなどのプロキシ経由の通信について適切に名前解決を行える仕組みについて説明した。
【００８６】
第３の実施形態では、ＤＮＳクライアントを複数用意して、プロキシサーバでは取り扱えない通信についても適切に名前解決を行えるようにする。
【００８７】
なお、ハードウェア構成は第１の実施形態と同様であるため、説明を省略する。図１０は、第３の実施形態におけるＭＦＰ２００のソフトウェア構成の一例である。
【００８８】
図２を用いて説明した第１の実施形態との差異は、ローカルプロキシサーバ１０３０に代えて、追加ＤＮＳクライアントを有する点である。
【００８９】
追加ＤＮＳクライアント１０３２はＯＳ標準ＤＮＳ１０２１と同様にＤＮＳ名前解決を行うＤＮＳクライアントである。
【００９０】
ＤＮＳ設定制御１０４０はＯＳ標準ＤＮＳクライアント１０２１と追加ＤＮＳクライアント１０３２に対して問い合わせを行うＤＮＳサーバの設定する機能を提供する。具体的には、ＯＳ標準ＤＮＳクライアント１０２１にはネットワーク１（３００）のＤＮＳ名を管理するＤＮＳサーバ１００を通信先として割り当てる。一方、追加ＤＮＳクライアント１０３２には、ネットワーク２（３１０）のＤＮＳ名を管理するＤＮＳサーバ１１０を通信先として割り当てる。
【００９１】
具体的な制御について図１１のフローチャートを用いて説明する。図１１のフローチャートに示す各動作（ステップ）は、ＣＰＵ２０２がＲＯＭ２０４またはＨＤＤ２０５に記憶された各制御モジュールを実現するためのプログラムをＲＡＭ２０３に呼び出し、実行することにより実現される。なお、データの送受信処理などは、各通信部Ｉ／Ｆと協働して実現されるものとする。また、処理の主体を明確にしたいケースにおいては、ＣＰＵ２０２により実行されるソフトウェアモジュールを主語として説明する。
【００９２】
図１１（Ａ）のフローチャートは、第１の実施形態における図４に代えて実行される処理を示すフローチャートであり、図１１（Ｂ）のフローチャートは第１の実施形態における図５に代えて実行される処理を示すフローチャートである。
【００９３】
まず、起動時の設定処理について図１１（Ａ）を用いて説明する。Ｓ１１００において、ＤＮＳ設定制御１０４０は、ＯＳ標準ＤＮＳ１０２１に対して、ネットワーク１のＤＮＳサーバを設定する。ネットワーク１のＤＮＳサーバ情報は、設定値ＤＢ１０５０に保存された情報が利用される。  Ｓ１１０１において、ＤＮＳ設定制御１０４０は、別のネットワーク（ネットワーク２）の接続が行われているか否かを判断する。別のネットワーク（ネットワーク２）への接続が行われている場合は、処理をＳ１１０２に進め、行われていない場合は、一連の処理を終了する。Ｓ１１０２において、ＤＮＳ設定制御１０４０は、追加ＤＮＳクライアント１０３２に対して、ネットワーク２のＤＮＳサーバを設定する。ネットワーク２のＤＮＳサーバ情報は、設定値ＤＢ１０５０に保存された情報が利用される。
【００９４】
続けて図１１（Ｂ）を用いて通信アプリケーションの制御について説明する。Ｓ１１１０において、通信アプリケーション１０１０は、設定値ＤＢ１０５０を参照し、通信インタフェース選択状態を判断する。ネットワーク１（Ｉ／Ｆ２１２）が指定されている場合は、処理をＳ１１１１に進め、ネットワーク２（Ｉ／Ｆ２１３）が指定されている場合は、処理をＳ１１１２に進める。
【００９５】
Ｓ１１１１において、通信アプリケーション１０１０は、ネットワーク１用のＯＳ標準ＤＮＳクライアント１０２１に対してＤＮＳ名前解決を依頼する。
【００９６】
一方、Ｓ１１１２において、通信アプリケーション１０１０は、ネットワーク２用の追加ＤＮＳクライアント１０３２に対してＤＮＳ名前解決を依頼する。
【００９７】
名前解決に成功した場合、通信アプリケーション１０１０は、当該名前解決の結果得られたＩＰアドレスに基づき相手先のデバイスと通信し、名前解決に失敗した場合、通信アプリケーション１０１０は、エラーを表示して一連の処理を終了する。
【００９８】
＜第４の実施形態＞
第３の実施形態では、複数のＤＮＳクライアントを起動しておき、通信アプリケーションがＤＮＳクライアントを使い分ける制御について説明した。第４の実施形態では、ＯＳ標準ＤＮＳクライアント１０２１の設定を再設定することで、１つのＤＮＳクライアントを用いて課題を解決する方法について説明する。
【００９９】
本実施形態のハードウェア構成は第３の実施形態と同様であるため説明を省略する。図１２は第３の実施形態におけるソフトウェア構成の一例である。図２を用いて説明した第１の実施形態との差異は、ローカルプロキシサーバ１０３０を有しない点である。
【０１００】
具体的な制御について図１３を用いて説明する。図１３は、第１の実施形態における５の処理に代えて実行されるフローチャートを示している。
【０１０１】
Ｓ１３００において、通信アプリケーション１０１０は、設定値ＤＢ１０５０を参照して、ＯＳ標準ＤＮＳクライアント１０２１に対して、ネットワーク１のＤＮＳサーバを設定する。例えば、ネットワーク１のＤＮＳサーバのＩＰアドレスが「１７２．２４．１．１」である場合、「／ｅｔｃ／ｒｅｓｏｌｖｅ．ｃｏｎｆ」に対して、「ｎａｍｅｓｅｒｖｅｒ  １７２．２４．１．１」といった記述を追加し、ＤＮＳクライアントをリスタートする。なお、ネットワーク２のＤＮＳサーバのＩＰアドレスがｃｏｎｆ内に記載されている場合、当該記載を消去する。
【０１０２】
続けてＳ１３０１において、通信アプリケーション１０１０は、ＤＮＳクライアント１０２１が動作中になるまで所定時間待ってから、ＤＮＳクライアント１０２１に名前解決を依頼する。
【０１０３】
Ｓ１３０２において、通信アプリケーション１０１０は、名前解決に成功したか否かを判断する。名前解決に成功した場合、通信アプリケーションは、その結果得られるＩＰアドレスに基づき通信を行って一連の処理を完了する。一方、名前解決に失敗した場合、処理をＳ１３０３に進める。
【０１０４】
Ｓ１３０３において、通信アプリケーション１０１０は、設定値ＤＢ１０５０内に別のネットワーク（ネットワーク２）のＤＮＳサーバ設定が存在するかを判断する。別のネットワーク（ネットワーク２）のＤＮＳサーバ設定が存在した場合は、処理をＳ１３０４に進める。一方、別のネットワーク（ネットワーク２）のＤＮＳサーバ設定が存在しない場合は、通信アプリケーション１０１０は、ユーザに対してエラーを通知して一連の処理を終了する。
【０１０５】
Ｓ１３０４において、通信アプリケーション１０１０は、ＯＳ標準ＤＮＳクライアント１０２１がアクセスするＤＮＳサーバの設定を書き換える。
【０１０６】
例えば、ネットワーク２のＤＮＳサーバが「１９２．１６８．１．１」である場合、ｃｏｎｄファイルか「ｎａｍｅｓｅｒｖｅｒ  １７２．２４．１．１」を削除する。また、「ｎａｍｅｓｅｒｖｅｒ  １９２．１６８．１．１」を新規に記載し、ＤＮＳクライアントをリスタートする。リスタートしてから所定時間が経過すると、処理をＳ１３０１に進め、名前解決処理をやり直す。以上説明した処理により、複数のネットワークでのＤＮＳ名前解決を実現できる。
【０１０７】
＜その他の実施形態＞
本発明は、上述の各実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣやＦＰＧＡ）によっても実現可能である。
【符号の説明】
【０１０８】
２００  ＭＦＰ
２０２  ＣＰＵ
２１２  ＬＡＮ  Ｉ／Ｆ
２１３  ＬＡＮ  Ｉ／Ｆ
【図１】
2020167619.tif 000003
【図２】
2020167619.tif 000004
【図３】
2020167619.tif 000005
【図４】
2020167619.tif 000006
【図５】
2020167619.tif 000007
【図６】
2020167619.tif 000008
【図７】
2020167619.tif 000009
【図８】
2020167619.tif 000010
【図９】
2020167619.tif 000011
【図１０】
2020167619.tif 000012
【図１１】
2020167619.tif 000013
【図１２】
2020167619.tif 000014
【図１３】
2020167619.tif 000015