携帯端末装置であって、他の携帯端末装置と直接通信する第1通信モードまたは中継機器を介して外部ネットワークと接続する第2通信モードで無線通信を行う通信部と、前記通信部の動作を制御する通信制御部とを含み、前記通信制御部は前記通信部の通信モードの切り替えを制御するものであり、第1通信モードから第2通信モードに切り替えるときは第1通信モードを終了することを通知することを特徴とする携帯端末装置。前記第2通信モードは、ユーザからの指示を契機として中継機器を介して外部ネットワークに接続する第1接続モードと、前記携帯端末装置で実行されるソフトウェアによってバックグラウンドで中継機器を介して外部ネットワークに接続する第2接続モードとを含み、前記通信制御部は、第2通信モードの第1接続モードから第1通信モードに切り替えるときは第2通信モードを終了することを通知し、第2通信モードの第2接続モードから第1通信モードに切り替えるときは第2通信モードを終了することを通知しないことを特徴とする請求項1に記載の携帯端末装置。前記通信制御部は、前記携帯端末装置で実行されるソフトウェアが通信する必要がある場合に前記第2通信モードの通信を確立し、前記ソフトウェアが所定の時間通信をしなくなると前記第2通信モードの通信を切断することを特徴とする請求項1または2に記載の携帯端末装置。前記第1通信モードはアドホックモードであり、前記第2通信モードはインフラストラクチャモードであることを特徴とする請求項1から3のいずれかに記載の携帯端末装置。複数のアプリケーションソフトウェアを並列に実行するアプリケーション実行部をさらに含み、前記通信制御部は、前記複数のアプリケーションソフトウェアそれぞれが使用する前記通信部の通信モードが異なる場合、前記通信部の通信モードの切り替えを制御することを特徴とする請求項1から4のいずれかに記載の携帯端末装置。携帯端末装置で実行される通信切替方法であって、他の携帯端末装置と直接通信する第1通信モードまたは中継機器を介して外部ネットワークと接続する第2通信モードで通信するステップと、第1通信モードから第2通信モードに切り替えるときは第1モードを終了することを通知するステップとを含むことを特徴とする通信切替方法。携帯端末装置で実行されるプログラムであって、他の携帯端末装置と直接通信する第1通信モードまたは中継機器を介して外部ネットワークと接続する第2通信モードで通信する機能と、第1通信モードから第2通信モードに切り替えるときは第1モードを終了することを通知する機能とを前記携帯端末装置に実現させることを特徴とするプログラム。携帯電話通信網を介して外部と通信する第1通信部と、前記第1通信部と比較して近距離での無線通信をするように構成された、中継機器を介して外部ネットワークと通信する第2通信部と、前記第1通信部と前記第2通信部との動作を制御する通信制御部とを含み、前記通信制御部は、前記第1通信部と前記第2通信部とがともに通信可能な場合、前記第2通信部を使用することを特徴とする携帯端末装置。これらの無線通信は、例えばIEEE80211通信技術を用いて実現される。情報端末には、このような通信技術を実装したひとつの通信モジュールが搭載されることが一般的である。このため、情報端末において通信モジュールを利用しうるアプリケーションが並列に実行される場合には、アプリケーション間で通信モジュールの使用が競合する可能性がある。このような理由から、競合する通信を効率的に制御することのできる技術が求められている。本発明はこうした課題に鑑みてなされたものであり、その目的は、競合する通信を効率的に制御することのできる技術を提供することにある。上記課題を解決するために、本発明のある態様は、携帯端末装置である。この装置は、他の携帯端末装置と直接通信する第1通信モードまたは中継機器を介して外部ネットワークと接続する第2通信モードで無線通信を行う通信部と、前記通信部の動作を制御する通信制御部とを含む。ここで前記通信制御部は前記通信部の通信モードの切り替えを制御するものであり、第1通信モードから第2通信モードに切り替えるときは第1モードを終了することを通知する。本発明の別の態様は、携帯端末装置で実行される通信切替方法である。この方法は、他の携帯端末装置と直接通信する第1通信モードまたは中継機器を介して外部ネットワークと接続する第2通信モードで通信するステップと、第1通信モードから第2通信モードに切り替えるときは第1モードを終了することを通知するステップとを含む。本発明のさらに別の態様も、携帯端末装置である。この装置は、携帯電話通信網を介して外部と通信する第1通信部と、前記携帯電話通信網通信部と比較して近距離での無線通信をするように構成された、中継機器を介して外部ネットワークと通信する第2通信部と、前記第1通信部と前記第2通信部との動作を制御する通信制御部とを含む。ここで前記通信制御部は、前記第1通信部と前記第2通信部とがともに通信可能な場合、前記第2通信部を使用する。なお、以上の構成要素の任意の組み合わせ、本発明の表現を方法、装置、システム、コンピュータプログラム、データ構造、記録媒体などの間で変換したものもまた、本発明の態様として有効である。本発明によれば、競合する通信を効率的に制御することのできる技術を提供することができる。以下、図面を参照して本発明の実施の形態について説明する。図1は、実施の形態に係る携帯端末装置100の接続状態を説明するための図である。携帯端末装置100aおよび携帯端末装置100bは、例えばIEEE80211で標準化されている無線LANLocalAreaNetworkを用いて相互に直接通信したり、アクセスポイント200等の中継機器を介してインターネット300等の外部ネットワークと通信したりする。複数の携帯端末装置100a、100bが、アクセスポイント200を介さないで直接無線で通信する通信モードはアドホックモードと呼ばれている。また、携帯端末装置100aまたは携帯端末装置100bが、アクセスポイント200を介して外部ネットワークと無線で通信するモードはインフラストラクチャモードと呼ばれている。以下本明細書において、携帯端末装置100aと携帯端末装置100bとは、区別の必要がない限り単に携帯端末装置100と総称する。なお、図1に明示はしていないが、実施の形態に係る携帯端末装置100においては、アドホックモードとインフラストラクチャモードとのふたつの通信モードで同時に通信することはできない。図2は、実施の形態に係る携帯端末装置100の各機能を模式的に示す図である。携帯端末装置100は、通信部10、表示部14、通信制御部16、およびアプリケーション実行部18を含む。図2は、実施の形態に係る携帯端末装置100を実現するための機能構成を示しており、その他の構成は省略している。図2において、さまざまな処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、CPU、メインメモリ、その他のLSIで構成することができ、ソフトウェア的には、メインメモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組み合わせによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。携帯端末装置100の各部は、図示しないオペレーティングシステムによって統括的に制御される。実施の形態に係る携帯端末装置100において、オペレーティングシステムによる管理の下、複数のアプリケーションがアプリケーション実行部18で並列に実行される。アプリケーションとしては、例えばゲーム32、メーラ34、ブラウザ36等があげられる。表示部14は、アプリケーション実行部18によるアプリケーションの実行結果を表示したり、通信制御部16からユーザへの通知画面を表示したりする。表示部14は、例えばLCDLiquidCrystalDisplayやOELOrganicElectroLuminescence等の既知の技術を用いて実現できる。通信部10は、無線LANで通信するように構成されたハードウェアデバイスである。通信部10は、通信モードとしてアドホックモードとインフラストラクチャモードとの両方に対応している。通信部10は、例えばWiFi登録商標モジュール等の既存の無線通信モジュールを用いて実現できる。実施の形態に係る携帯端末装置100において、携帯端末装置100の外部と通信をしようとするアプリケーションは、通信部10を直接制御することはしない。その代わり、アプリケーションは、オペレーティングシステムが管理する通信制御部16を介して外部と通信をする。このため、アプリケーションは、外部との通信の接続や通信の切断を管理する必要がなく、単に通信制御部16に対してデータを送受信するだけでよい。この意味で、アプリケーションにとって通信制御部16はデータ送受信のためのAPIApplicationProgrammingInterfaceとして機能する。例えば、電子メールの送受信をするためのクライアントアプリケーションであるメーラ34は、通信部10およびアクセスポイント200を介して、外部ネットワーク上に存在するメールサーバ等と通信する。この場合、通信部10は前述のインフラストラクチャモードで通信する。メーラ34は、通信部10とアクセスポイント200との間の通信の接続や切断には関与せず、通信制御部16に対してデータを送受信する。別の例として、複数のユーザが携帯端末装置100を持ち寄って相互に直接通信し、対戦ゲーム等を実現するためのアプリケーションであるゲーム32は、通信部10を介して他の携帯端末装置100と直接通信する。この場合、通信部10は前述のアドホックモードで通信する。ところで、通信部10がいずれかの外部機器と通信を確立している間は、アプリケーションからデータの送受信がない場合でも、確立を維持するために外部機器と信号をやり取りする必要があり、電力を消費する。実施の形態に係る携帯端末装置100は、ユーザが携帯して利用することができるように、図示しないバッテリから電源の供給を受けて駆動する。このため、バッテリを長持ちさせることを目的として、通信部10は、アプリケーションが通信を必要とするときにのみ外部機器と接続する間欠接続を行う。より具体的に、間欠接続とは、アプリケーションが通信を必要とするときにのみ通信を確立して通信し、アプリケーションが所定の時間例えば2分間通信しなくなると通信を切断するものであり、外部機器との通信が間欠的となる。仮に携帯端末装置100の近傍にアクセスポイント200が存在し、通信部10がインフラストラクチャモードで常時接続できる状況であったとしても、上記の目的から間欠接続が採用される。通信制御部16は、アプリケーションから通信の要求を取得すると、後述する4つの通信モードAPIを用いて通信の接続および切断を制御する。例として、インフラストラクチャモードによる通信を利用するメーラ34について考える。簡単のため、携帯端末装置100においてメーラ34以外のアプリケーションは実行されていないものとする。メーラ34を起動したユーザは、外部ネットワーク上のメールサーバにメールが届いているか否かの確認、およびメールが届いている場合にはそのメールをダウンロードするために、メーラ34にメールの受信を指示する。ユーザからの指示を受け、メーラ34は通信制御部16に受信の要求をする。この結果、通信部10は切断状態からインフラストラクチャモードによる通信状態となり、アクセスポイント200を介してメールサーバと情報のやり取りをする。メールの確認およびダウンロードが終了した後所定の時間が経過すると、通信制御部16は通信部10を切断状態に戻す。メーラ34は、所定の時間間隔例えば30分間隔で自動的にメールサーバ上のメールの有無およびメールのダウンロードを行うように設定される場合もある。このような場合、メーラ34は所定の時間間隔毎に、ユーザからの明示的な指示を受けることなく、バックグラウンドプロセスとして受信要求をする。以上のように、インフラストラクチャモードによる通信は、ユーザの明示的な指示を契機として開始する場合と、バックグラウンドで開始する場合との、ふたつの接続の契機が存在する。インフラストラクチャモードによる通信の場合と同様に、アドホックモードによる通信も、ユーザの明示的な指示を契機として開始する場合と、バックグラウンドで開始する場合との、ふたつの接続の契機が存在する。前者の例は、ユーザがアプリケーションとしてゲーム32を利用する場合である。ゲーム32が、例えばあるユーザが近くにいる別のユーザが所持する携帯端末装置100と通信しながら共同してひとつのゲームを楽しむものであるとする。ある携帯端末装置100aを持つユーザは、別のユーザの持つ携帯端末装置100bと接続することを、携帯端末装置100a上で実行されるゲーム32に明示的に指示する。これに対し、後者の例は、スリープ状態となっているふたつの異なる携帯端末装置100同士がアドホックモードで通信可能な所定の範囲内にあるときに、両者がバックグラウンドで通信する場合である。この場合、近傍の携帯端末装置100同士が自動的かつ瞬時にアドホックモードで通信を行う。例えば、この通信モードを利用するゲーム32がメモリ上に常駐している携帯端末装置100同士がアドホックモードで通信可能な距離に接近したときに、いずれの通信部10も接続中でなければ、ゲーム32に関連するデータを交換すること等に利用される。図3は、実施の形態に係る携帯端末装置100における通信接続の種類を示す図であり、以上説明した通信モードを表形式にまとめた図である。図3に示すように、本明細書において、ユーザからの指示を契機として他の携帯端末装置100とアドホックモードで直接通信する通信モードを第1通信モードA1と呼ぶ。同様に、ユーザからの指示を契機としてアクセスポイント200を介して外部ネットワークとインフラストラクチャモードで通信する通信モードを第2通信モードI1と呼ぶ。また、携帯端末装置100で実行されるアプリケーションによって、バックグラウンドでアクセスポイント200を介してインフラストラクチャモードの通信をする通信モードを第3通信モードI2と呼ぶ。さらに、携帯端末装置100で実行されるアプリケーションによって、バックグラウンドでアドホックモードの通信をする通信モードを第4通信モードA2と呼ぶ。図2における通信制御部16は、これら4つの通信モードそれぞれによる通信の接続、データの送受信、および通信の切断を管理するAPI群である、第1通信モードAPI20、第2通信モードAPI22、第3通信モードAPI24、および第4通信モードAPI26を含む。なお、便宜上、通信開始の契機が異なる場合は異なる通信モードとして説明するが、実際には通信開始の契機で場合分けすることなく、インフラストラクチャモードによる通信の管理およびアドホックモードによる通信の管理をそれぞれ行うふたつの通信モードAPIを用意するだけでもよい。この場合、第1通信モードA1はアドホック通信モードにおける第1接続モード、第2通信モードI1はインフラストラクチャ通信モードにおける第1接続モード、第3通信モードI2は、インフラストラクチャ通信モードにおける第2接続モード、第4通信モードA2はアドホック通信モードにおける第2接続モードとなる。以上は、実施の形態に係る携帯端末装置100において、メーラ34等のアプリケーションが単独で実行される場合を想定して説明したが、前述したように、携帯端末装置100上では複数のアプリケーションが同時に並列して実行されうる。通信部10は、通信モードとしてアドホックモードとインフラストラクチャモードとの両方に対応する場合であっても、ふたつのモードで同時に通信をすることは困難である。このため、携帯端末装置100において同時に実行されている複数のアプリケーションそれぞれが異なる通信モードを使用する場合、通信モードを切り替える必要があり、その場合ユーザに対して通信を切り替える旨か、少なくとも現在の通信モードが切断される旨の通知をした方が好ましい。一方で、通信機能を利用するアプリケーションの数が多くなると、通信切替の度にその旨を通知するのは処理が煩雑となり、ユーザにとっても煩わしくなる恐れがある。そこで、通信制御部16は、複数のアプリケーションの間で通信を制御する通信モード切替部28および通信モードの切り替えに伴う通知をするか否かの基準を格納するデータベース30も含む。以下、通信モードの切替通知の基準を説明するが、まずその前提となる通信モードの遷移について述べる。図4は、実施の形態に係る携帯端末装置100の通信モードの遷移を示す状態遷移図である。図4において、第1通信モードをA1、第2通信モードをI1、第3通信モードをI2、および第4通信モードをA2と省略して記載している。また、上記の通信モードの他に、携帯端末装置100に通信を切断している状態も取り得る。以下、携帯端末装置100が通信を切断している状態を、便宜上切断モードと呼ぶ。前述したように、携帯端末装置100は間欠接続を採用する。第4通信モードA2は、この間欠接続の隙間を利用する通信モードである。したがって、第4通信モードA2は切断モードからのみ遷移可能であり、また第4通信モードA2は切断モードにのみ遷移する。第4通信モードA2は、第1通信モードA1、第2通信モードI1、および第3通信モードI2よりも、優先順位の低い通信モードといえる。一方、第1通信モードA1、第2通信モードI1、第3通信モードI2、および切断モードは、互いにそれぞれのモードに遷移することができる。しかしながら、インフラストラクチャモードである第2通信モードI1および第3通信モードI2は、タイムシェアリングによって複数のアプリケーションが並列で通信部10を利用できるが、アドホックモードである第1通信モードA1は、単独のアプリケーションが通信部10を独占的に使用することになる。この意味で、第1通信モードA1は、第2通信モードI1および第3通信モードI2よりも優先順位の高い通信モードといえる。第2通信モードI1と第3通信モードI2とでは、ユーザの明示的な指示を契機とする第2通信モードI1の方が優先順位が高い。以上より、第1通信モードA1、第2通信モードI1、第3通信モードをI2、および第4通信モードA2の優先順位は、以下のようになる。第1通信モードA1>第2通信モードI1>第3通信モードI2>第4通信モードA2図4より、ある通信モードから別の通信モードへの遷移の仕方、すなわち通信モードの切替の種類は14通りあることが分かる。この14種類の通信モードの切り替えが発生する度にユーザにその旨を通知するのは、ユーザに煩雑さを感じさせる要因となりうるため好ましくない。そこで、通信モードの切り替えを通知するか否かについて、通信モードの優先順位を考慮して、以下の基準を定義する。基準:ユーザの明示的な指示による通信モードから他の通信モードに切り替わるときは、現在の通信モードが終了する旨を通知する。上記の基準は、ユーザの明示的な意思により開始された通信を切断することになる場合、その旨をユーザに確認することを意図したものである。例えば、第1通信モードA1を用いて他のユーザと対戦ゲームをしているユーザが、ブラウザ36を用いてインターネット300上に存在するウェブサイトの閲覧を望んだとする。ブラウザ36は、ウェブサイトを閲覧するために第1通信モードA1から第2通信モードI1に切り替える必要があるが、そのためには対戦ゲームを中断しなくてはならない。ユーザがウェブサイトの閲覧よりもゲームの続行を望むこともあるため、通信モード切替部28は、アドホックモードを終了してインフラストラクチャモードに移行することをユーザに通知し、ユーザの意思を確認する。図5は、現在の通信モードが切断されることをユーザに知らせる通知画面の一例を示す図である。通信モードの移行を望むユーザは携帯端末装置100の操作ボタンを押下することで、通信モードの切り替えを選択することができる。また、ゲームの続行を望むユーザは、通信モードの切り替えをキャンセルすることができる。このような通知画面の表示データは、データベース30に格納されている。なお、現在の通信モードが切断される旨をユーザに通知することは、表示部14に表示することに代えて、あるいはそれと併用して、警告音や読み上げ等の音声を用いて通知してもよい。別の例として、第2通信モードI1を使用するブラウザ36を用いてインターネット300上のウェブサイトからコンテンツをダウンロードしている最中に、ユーザが第1通信モードA1を用いて他のユーザと対戦ゲームを開始しようとする場合を考える。この場合、通信モードの切替をユーザに知らせることにより、コンテンツのダウンロードを優先するかゲーム開始を優先するかの意思確認を行う。これに対し、ユーザの明示的な指示による通信モードでない通信モードからユーザの明示的な指示による通信モードに移行するときは、特段の通知をしなくてもよい。例えば、メーラ34が第3通信モードI2を用いてバックグラウンドでメールの有無を確認しているときに、ユーザが第1通信モードA1を用いて他のユーザと対戦ゲームを開始することを考える。通常、メーラ34がバックグラウンドでメールの有無を確認していることをユーザは認識していない。このため、仮に通信モードの切断や切り替えが通知されると、ユーザは携帯端末装置100がどのような通信をしているかがにわかには把握できず、困惑することもあり得る。そのようなことを防ぐため、ユーザの明示的な指示による通信モードでない通信モードからユーザの明示的な指示による通信モードに移行するときは、むしろ何も通知しない方が好ましい。図6は、実施の形態に係るデータベース30の内部構造を模式的に示す図であり、上述した通信モードの切替を通知するか否かの基準を表形式にまとめたものである。図6は、図4の場合と同様に、第1通信モードをA1、第2通信モードをI1、第3通信モードをI2、第4通信モードをA2、および切断モードを切断として省略して記載している。図6において、Yesは通信モードの切り替えを通知することを意味し、Noは通信モードの切り替えを通知しないことを意味する。例えば、遷移前の通信モードが第2通信モードI1で、遷移後の通信モードが第1通信モードA1である場合、通信モードの切り替えを通知するので、Yesが格納されている。通信モード切替部28は、アプリケーションから通信モードの切替要求を取得した場合、データベース30を参照して通信モードの切り替えを通知するか否かを判断する。その結果、通信モードの切り替えを通知する場合、通信モード切替部28はデータベース30から通知画面のデータを取得して表示部14に出力する。通信モードの切り替えを通知しない場合、通信モード切替部28は通信モードAPIに通信部10の通信モードを切り替えさせる。図7は、実施の形態に係る携帯端末装置100の各部の処理手順を時系列的に示すフローチャートである。図7に示すフローチャートにおいては、各部の処理手順を、ステップを意味するSStepの頭文字と数字との組み合わせによって表示する。また、Sと数字との組み合わせによって表示した処理で何らかの判断処理が実行され、その判断結果が肯定的であった場合は、YYesの頭文字を付加して、例えば、S8のYと表示し、逆にその判断結果が否定的であった場合は、NNoの頭文字を付加して、S8のNと表示する。本フローチャートにおける処理は、携帯端末装置100が起動したときに開始する。通信モード切替部28は、アプリケーションから通信モードの切替の要求を取得するS2。通信モード切替部28は、通信部10の現在の通信モードを取得するS4。続いて、通信モード切替部28は、現在の通信モードと切替後の通信モードとをもとにデータベース30を参照し、現在の通信モードが切断されることを通知するか否かを判断するS6。通知の必要がある場合S8のY、通信モード切替部28はデータベース30から通知画面のデータを読み出して表示部14に出力し、ユーザの通信モード切り替えの意思を確認するS10。その結果、ユーザに通信モード切り替えの意思がある場合S12のY、通信モード切替部28は切り替え後の通信モードAPIを呼び出して通信モードの切り替えを実行するS14。通信モードの切り替えを通知するか否かの判断の結果、通信モード切断に伴う通知をする必要がない場合S8のN、通信モード切替部28は切り替え後の通信モードAPIを呼び出して通信モードの切り替えを実行するS14。通信モード切替部28が通信モードの切り替えを実行するか、ユーザに通信モード切り替えの意思がない場合S12のN、本フローチャートにおける処理は終了する。以上の構成による動作は以下のとおりである。ユーザは、携帯端末装置100を用いて複数のアプリケーションを並列で実行する。ユーザがあるアプリケーションを実行しようとするとき、そのアプリケーションが携帯端末装置100における通信部10の通信モードを切り替える必要がある場合、通信モード切替部28は表示部14にその旨を表示する。ユーザはその表示を見て最終的な意思確認を行う。以上説明したとおり、実施の形態によれば、並列して実行される複数のアプリケーション間で競合する通信を効率的に制御することができる。以上、本発明を実施の形態をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。上記の説明では、例えば、第2通信モードI1からより優先度の高い第1通信モードA1に通信が切り替わるときに、通信モード切替部28が第2通信モードI1が終了する旨の通知をする場合について説明したが、上述の通信モードの優先順位にしたがって、優先順位の低い通信モードから優先順位の高い通信モードに切り替える場合には、通信モード切替部28は何も通知しないようにしてもよい。上記の説明では、インフラストラクチャモードは間欠接続であることを前提としたが、アプリケーションの種類によっては常時接続を必要とすることもあり得る。例えば、インフラストラクチャモードを利用したオンラインゲームのようなアプリケーションや、携帯端末装置100を音楽サーバとして機能させるためのアプリケーションである。この場合、インフラストラクチャモードを常時接続としてもよい。図8は、常時接続の場合の通信モードの遷移を示す状態遷移図である。間欠接続の場合の通信モードの遷移を示す状態遷移図である図4と比較すると、常時接続の場合は第4通信モードA2と切断モードがなく、第1通信モードA1、第2通信モードI1、および第3通信モードI2の3つのモードのみが取り得るモードである。第1通信モードA1、第2通信モードI1、および第3通信モードI2それぞれの間で通信モードを切り替えるときにその旨を通知するか否かは、間欠接続の場合と同じである。常時接続の状態遷移図は、間欠接続の状態遷移図のサブセットとして捉えることができる。したがって、常時接続の場合も図6に示すデータベースをそのまま利用することができる。上記の説明では、通信モードの優先順位をもとに通信モードの切り替えを通知するか否かの基準を説明したが、通信モードの優先順位および通信モードの切り替えを通知するか否かの基準はアプリケーション毎に変更できるようにしてもよい。これは、例えばアプリケーションが、通信モード切替部28を介して図6に示す表を表示部14に提示し、ユーザに編集させる。その結果をデータベース30にそのアプリケーションに対応づけて格納することで実現できる。上記の説明では、無線LANにおけるインフラストラクチャモードとアドホックモードとの間の通信を制御する場合について説明したが、携帯電話通信網と無線LANとの通信を制御してもよい。以下この場合の実施の形態について説明するが、上述した実施の形態と共通する部分は適宜省略または簡略化して説明する。図9は、別の実施の形態に係る携帯端末装置100の無線LANおよび携帯電話通信網の接続を説明するための図である。携帯端末装置100の通信部10は、WiFi登録商標モジュールの他に、3G3rdGeneration通信モジュール図示せずを含み、アドホックモードやインフラストラクチャモードによる通信時はWiFi登録商標モジュールを使用し、携帯電話通信網による通信は3G通信モジュールを利用する。携帯端末装置100は、携帯電話通信網を利用する場合、3G通信モジュールを用いて基地局400に接続し、基地局400を経由してインターネット300にアクセスする。無線LANを利用する場合と携帯電話通信網を利用する場合とでは、使用する通信モジュールが異なるため、両者を同時に使用することは理論的には可能である。しかしながら、前述したとおり、携帯端末装置100は電池で駆動するため、両者を同時に使用することは消費電力が大きく現実的ではない。また、携帯端末装置100は携帯しやすくするために小型化されており、両者を同時に使用することは発熱を抑えるのが困難となりうる。そこで通信制御部16は、携帯電話通信網と近距離無線通信である無線LANとがともに通信可能な場合、無線LANを使用するようにする。無線LANによる通信は携帯電話通信網による通信と比較して安価かつ広帯域の場合が多く、ユーザにとっては通信コストおよび通信時間を抑制しうる点で有利である。なお、携帯電話通信網と無線LANとの通信の確立の制御のみならず、携帯電話通信網と近距離無線通信であるBluetooth登録商標等をはじめとする他の近距離無線通信との制御も同様に可能である。