携帯端末装置および通信切替方法
【課題】競合する通信を効率的に制御することのできる技術を提供する。
【解決手段】携帯端末装置１００において、通信部１０は、他の携帯端末装置と直接通信する第１通信モードまたは中継機器を介して外部ネットワークと接続する第２通信モードで無線通信を行う。通信制御部１６は、通信部１０の動作を制御する。ここで通信制御部１６は通信部１０の通信モードの切り替えを制御するものであり、第１通信モードから第２通信モードに切り替えるときは第１モードを終了することを通知する。
【解決手段】携帯端末装置１００において、通信部１０は、他の携帯端末装置と直接通信する第１通信モードまたは中継機器を介して外部ネットワークと接続する第２通信モードで無線通信を行う。通信制御部１６は、通信部１０の動作を制御する。ここで通信制御部１６は通信部１０の通信モードの切り替えを制御するものであり、第１通信モードから第２通信モードに切り替えるときは第１モードを終了することを通知する。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、携帯端末装置およびその携帯端末装置において異なる通信モードの切り替えを制御するための通信切替方法に関する。
【背景技術】
【０００２】
情報端末の小型化および軽量化が実現されたことにより、情報端末を持ち運ぶことが一般的になってきた。近年では、基地局やアクセスポイントなどのインフラを利用して、複数のユーザがゲームなどのアプリケーションを一緒に楽しむことも多く行われる。また一方で、オンデマンド型の通信として無線アドホックネットワークを構築する技術も広く用いられるようになってきている（特許文献１参照）。
【０００３】
アドホックネットワークでは、基地局やアクセスポイントが不要となるため、このようなインフラが存在しない場所でも簡易に無線ネットワークを構築することができる。アドホックネットワークでは、複数のユーザが携帯型ゲーム機を持ち寄って相互に無線通信することで、一緒にゲームを楽しむことも可能となる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】米国特許出願公開２００５／２５０４８７号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００５】
これらの無線通信は、例えばIEEE802.11通信技術を用いて実現される。情報端末には、このような通信技術を実装したひとつの通信モジュールが搭載されることが一般的である。このため、情報端末において通信モジュールを利用しうるアプリケーションが並列に実行される場合には、アプリケーション間で通信モジュールの使用が競合する可能性がある。このような理由から、競合する通信を効率的に制御することのできる技術が求められている。
【０００６】
本発明はこうした課題に鑑みてなされたものであり、その目的は、競合する通信を効率的に制御することのできる技術を提供することにある。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明のある態様は、携帯端末装置である。この装置は、他の携帯端末装置と直接通信する第１通信モードまたは中継機器を介して外部ネットワークと接続する第２通信モードで無線通信を行う通信部と、前記通信部の動作を制御する通信制御部とを含む。ここで前記通信制御部は前記通信部の通信モードの切り替えを制御するものであり、第１通信モードから第２通信モードに切り替えるときは第１モードを終了することを通知する。
【０００８】
本発明の別の態様は、携帯端末装置で実行される通信切替方法である。この方法は、他の携帯端末装置と直接通信する第１通信モードまたは中継機器を介して外部ネットワークと接続する第２通信モードで通信するステップと、第１通信モードから第２通信モードに切り替えるときは第１モードを終了することを通知するステップとを含む。
【０００９】
本発明のさらに別の態様も、携帯端末装置である。この装置は、携帯電話通信網を介して外部と通信する第１通信部と、前記携帯電話通信網通信部と比較して近距離での無線通信をするように構成された、中継機器を介して外部ネットワークと通信する第２通信部と、前記第１通信部と前記第２通信部との動作を制御する通信制御部とを含む。ここで前記通信制御部は、前記第１通信部と前記第２通信部とがともに通信可能な場合、前記第２通信部を使用する。
【００１０】
なお、以上の構成要素の任意の組み合わせ、本発明の表現を方法、装置、システム、コンピュータプログラム、データ構造、記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１１】
本発明によれば、競合する通信を効率的に制御することのできる技術を提供することができる。
【図面の簡単な説明】
【００１２】
【図１】実施の形態に係る携帯端末装置の接続状態を説明するための図である。
【図２】実施の形態に係る携帯端末装置の各機能を模式的に示す図である。
【図３】実施の形態に係る携帯端末装置における通信接続の種類を示す図である。
【図４】実施の形態に係る携帯端末装置の通信モードの遷移を示す状態遷移図である。
【図５】通信モードの切り替えをユーザに知らせる通知画面の一例を示す図である。
【図６】実施の形態に係るデータベースの内部構造を模式的に示す図である。
【図７】実施の形態に係る携帯端末装置の処理の流れを説明するフローチャートである。
【図８】常時接続の場合の通信モードの遷移を示す状態遷移図である。
【図９】別の実施の形態に係る携帯端末装置の通信接続を説明するための図である。
【発明を実施するための形態】
【００１３】
以下、図面を参照して本発明の実施の形態について説明する。
【００１４】
図１は、実施の形態に係る携帯端末装置１００の接続状態を説明するための図である。携帯端末装置１００ａおよび携帯端末装置１００ｂは、例えばIEEE802.11で標準化されている無線ＬＡＮ（Local Area Network）を用いて相互に直接通信したり、アクセスポイント２００等の中継機器を介してインターネット３００等の外部ネットワークと通信したりする。
【００１５】
複数の携帯端末装置１００ａ、１００ｂが、アクセスポイント２００を介さないで直接無線で通信する通信モードは「アドホックモード」と呼ばれている。また、携帯端末装置１００ａまたは携帯端末装置１００ｂが、アクセスポイント２００を介して外部ネットワークと無線で通信するモードは「インフラストラクチャモード」と呼ばれている。以下本明細書において、携帯端末装置１００ａと携帯端末装置１００ｂとは、区別の必要がない限り単に「携帯端末装置１００」と総称する。なお、図１に明示はしていないが、実施の形態に係る携帯端末装置１００においては、アドホックモードとインフラストラクチャモードとのふたつの通信モードで同時に通信することはできない。
【００１６】
図２は、実施の形態に係る携帯端末装置１００の各機能を模式的に示す図である。携帯端末装置１００は、通信部１０、表示部１４、通信制御部１６、およびアプリケーション実行部１８を含む。
【００１７】
図２は、実施の形態に係る携帯端末装置１００を実現するための機能構成を示しており、その他の構成は省略している。図２において、さまざまな処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、ＣＰＵ、メインメモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、メインメモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組み合わせによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。
【００１８】
携帯端末装置１００の各部は、図示しないオペレーティングシステムによって統括的に制御される。実施の形態に係る携帯端末装置１００において、オペレーティングシステムによる管理の下、複数のアプリケーションがアプリケーション実行部１８で並列に実行される。アプリケーションとしては、例えばゲーム３２、メーラ３４、ブラウザ３６等があげられる。
【００１９】
表示部１４は、アプリケーション実行部１８によるアプリケーションの実行結果を表示したり、通信制御部１６からユーザへの通知画面を表示したりする。表示部１４は、例えばＬＣＤ（Liquid Crystal Display）やＯＥＬ（Organic Electro- Luminescence）等の既知の技術を用いて実現できる。通信部１０は、無線ＬＡＮで通信するように構成されたハードウェアデバイスである。通信部１０は、通信モードとしてアドホックモードとインフラストラクチャモードとの両方に対応している。通信部１０は、例えばWi-Fi（登録商標）モジュール等の既存の無線通信モジュールを用いて実現できる。
【００２０】
実施の形態に係る携帯端末装置１００において、携帯端末装置１００の外部と通信をしようとするアプリケーションは、通信部１０を直接制御することはしない。その代わり、アプリケーションは、オペレーティングシステムが管理する通信制御部１６を介して外部と通信をする。このため、アプリケーションは、外部との通信の接続や通信の切断を管理する必要がなく、単に通信制御部１６に対してデータを送受信するだけでよい。この意味で、アプリケーションにとって通信制御部１６はデータ送受信のためのＡＰＩ（Application Programming Interface）として機能する。
【００２１】
例えば、電子メールの送受信をするためのクライアントアプリケーションであるメーラ３４は、通信部１０およびアクセスポイント２００を介して、外部ネットワーク上に存在するメールサーバ等と通信する。この場合、通信部１０は前述のインフラストラクチャモードで通信する。メーラ３４は、通信部１０とアクセスポイント２００との間の通信の接続や切断には関与せず、通信制御部１６に対してデータを送受信する。別の例として、複数のユーザが携帯端末装置１００を持ち寄って相互に直接通信し、対戦ゲーム等を実現するためのアプリケーションであるゲーム３２は、通信部１０を介して他の携帯端末装置１００と直接通信する。この場合、通信部１０は前述のアドホックモードで通信する。
【００２２】
ところで、通信部１０がいずれかの外部機器と通信を確立している間は、アプリケーションからデータの送受信がない場合でも、確立を維持するために外部機器と信号をやり取りする必要があり、電力を消費する。実施の形態に係る携帯端末装置１００は、ユーザが携帯して利用することができるように、図示しないバッテリから電源の供給を受けて駆動する。このため、バッテリを長持ちさせることを目的として、通信部１０は、アプリケーションが通信を必要とするときにのみ外部機器と接続する「間欠接続」を行う。
【００２３】
より具体的に、間欠接続とは、アプリケーションが通信を必要とするときにのみ通信を確立して通信し、アプリケーションが所定の時間（例えば２分間）通信しなくなると通信を切断するものであり、外部機器との通信が間欠的となる。仮に携帯端末装置１００の近傍にアクセスポイント２００が存在し、通信部１０がインフラストラクチャモードで常時接続できる状況であったとしても、上記の目的から間欠接続が採用される。通信制御部１６は、アプリケーションから通信の要求を取得すると、後述する４つの通信モードＡＰＩを用いて通信の接続および切断を制御する。
【００２４】
例として、インフラストラクチャモードによる通信を利用するメーラ３４について考える。簡単のため、携帯端末装置１００においてメーラ３４以外のアプリケーションは実行されていないものとする。メーラ３４を起動したユーザは、外部ネットワーク上のメールサーバにメールが届いているか否かの確認、およびメールが届いている場合にはそのメールをダウンロードするために、メーラ３４にメールの受信を指示する。ユーザからの指示を受け、メーラ３４は通信制御部１６に受信の要求をする。この結果、通信部１０は切断状態からインフラストラクチャモードによる通信状態となり、アクセスポイント２００を介してメールサーバと情報のやり取りをする。メールの確認およびダウンロードが終了した後所定の時間が経過すると、通信制御部１６は通信部１０を切断状態に戻す。
【００２５】
メーラ３４は、所定の時間間隔（例えば３０分間隔）で自動的にメールサーバ上のメールの有無およびメールのダウンロードを行うように設定される場合もある。このような場合、メーラ３４は所定の時間間隔毎に、ユーザからの明示的な指示を受けることなく、「バックグラウンドプロセス」として受信要求をする。以上のように、インフラストラクチャモードによる通信は、ユーザの明示的な指示を契機として開始する場合と、バックグラウンドで開始する場合との、ふたつの接続の契機が存在する。
【００２６】
インフラストラクチャモードによる通信の場合と同様に、アドホックモードによる通信も、ユーザの明示的な指示を契機として開始する場合と、バックグラウンドで開始する場合との、ふたつの接続の契機が存在する。前者の例は、ユーザがアプリケーションとしてゲーム３２を利用する場合である。ゲーム３２が、例えばあるユーザが近くにいる別のユーザが所持する携帯端末装置１００と通信しながら共同してひとつのゲームを楽しむものであるとする。ある携帯端末装置１００ａを持つユーザは、別のユーザの持つ携帯端末装置１００ｂと接続することを、携帯端末装置１００ａ上で実行されるゲーム３２に明示的に指示する。
【００２７】
これに対し、後者の例は、スリープ状態となっているふたつの異なる携帯端末装置１００同士がアドホックモードで通信可能な所定の範囲内にあるときに、両者がバックグラウンドで通信する場合である。この場合、近傍の携帯端末装置１００同士が自動的かつ瞬時にアドホックモードで通信を行う。例えば、この通信モードを利用するゲーム３２がメモリ上に常駐している携帯端末装置１００同士がアドホックモードで通信可能な距離に接近したときに、いずれの通信部１０も接続中でなければ、ゲーム３２に関連するデータを交換すること等に利用される。
【００２８】
図３は、実施の形態に係る携帯端末装置１００における通信接続の種類を示す図であり、以上説明した通信モードを表形式にまとめた図である。図３に示すように、本明細書において、ユーザからの指示を契機として他の携帯端末装置１００とアドホックモードで直接通信する通信モードを「第１通信モードＡ１」と呼ぶ。同様に、ユーザからの指示を契機としてアクセスポイント２００を介して外部ネットワークとインフラストラクチャモードで通信する通信モードを「第２通信モードＩ１」と呼ぶ。また、携帯端末装置１００で実行されるアプリケーションによって、バックグラウンドでアクセスポイント２００を介してインフラストラクチャモードの通信をする通信モードを「第３通信モードＩ２」と呼ぶ。
【００２９】
さらに、携帯端末装置１００で実行されるアプリケーションによって、バックグラウンドでアドホックモードの通信をする通信モードを「第４通信モードＡ２」と呼ぶ。図２における通信制御部１６は、これら４つの通信モードそれぞれによる通信の接続、データの送受信、および通信の切断を管理するＡＰＩ群である、第１通信モードＡＰＩ２０、第２通信モードＡＰＩ２２、第３通信モードＡＰＩ２４、および第４通信モードＡＰＩ２６を含む。
【００３０】
なお、便宜上、通信開始の契機が異なる場合は異なる通信モードとして説明するが、実際には通信開始の契機で場合分けすることなく、インフラストラクチャモードによる通信の管理およびアドホックモードによる通信の管理をそれぞれ行うふたつの通信モードＡＰＩを用意するだけでもよい。この場合、第１通信モードＡ１は「アドホック通信モードにおける第１接続モード」、第２通信モードＩ１は「インフラストラクチャ通信モードにおける第１接続モード」、第３通信モードＩ２は、「インフラストラクチャ通信モードにおける第２接続モード」、第４通信モードＡ２は「アドホック通信モードにおける第２接続モード」となる。
【００３１】
以上は、実施の形態に係る携帯端末装置１００において、メーラ３４等のアプリケーションが単独で実行される場合を想定して説明したが、前述したように、携帯端末装置１００上では複数のアプリケーションが同時に並列して実行されうる。通信部１０は、通信モードとしてアドホックモードとインフラストラクチャモードとの両方に対応する場合であっても、ふたつのモードで同時に通信をすることは困難である。このため、携帯端末装置１００において同時に実行されている複数のアプリケーションそれぞれが異なる通信モードを使用する場合、通信モードを切り替える必要があり、その場合ユーザに対して通信を切り替える旨か、少なくとも現在の通信モードが切断される旨の通知をした方が好ましい。
【００３２】
一方で、通信機能を利用するアプリケーションの数が多くなると、通信切替の度にその旨を通知するのは処理が煩雑となり、ユーザにとっても煩わしくなる恐れがある。そこで、通信制御部１６は、複数のアプリケーションの間で通信を制御する通信モード切替部２８および通信モードの切り替えに伴う通知をするか否かの基準を格納するデータベース３０も含む。
【００３３】
以下、通信モードの切替通知の基準を説明するが、まずその前提となる通信モードの遷移について述べる。
【００３４】
図４は、実施の形態に係る携帯端末装置１００の通信モードの遷移を示す状態遷移図である。図４において、第１通信モードをＡ１、第２通信モードをＩ１、第３通信モードをＩ２、および第４通信モードをＡ２と省略して記載している。また、上記の通信モードの他に、携帯端末装置１００に通信を切断している状態も取り得る。以下、携帯端末装置１００が通信を切断している状態を、便宜上「切断モード」と呼ぶ。
【００３５】
前述したように、携帯端末装置１００は間欠接続を採用する。第４通信モードＡ２は、この間欠接続の隙間を利用する通信モードである。したがって、第４通信モードＡ２は切断モードからのみ遷移可能であり、また第４通信モードＡ２は切断モードにのみ遷移する。第４通信モードＡ２は、第１通信モードＡ１、第２通信モードＩ１、および第３通信モードＩ２よりも、優先順位の低い通信モードといえる。
【００３６】
一方、第１通信モードＡ１、第２通信モードＩ１、第３通信モードＩ２、および切断モードは、互いにそれぞれのモードに遷移することができる。しかしながら、インフラストラクチャモードである第２通信モードＩ１および第３通信モードＩ２は、タイムシェアリングによって複数のアプリケーションが並列で通信部１０を利用できるが、アドホックモードである第１通信モードＡ１は、単独のアプリケーションが通信部１０を独占的に使用することになる。この意味で、第１通信モードＡ１は、第２通信モードＩ１および第３通信モードＩ２よりも優先順位の高い通信モードといえる。第２通信モードＩ１と第３通信モードＩ２とでは、ユーザの明示的な指示を契機とする第２通信モードＩ１の方が優先順位が高い。
【００３７】
以上より、第１通信モードＡ１、第２通信モードＩ１、第３通信モードをＩ２、および第４通信モードＡ２の優先順位は、以下のようになる。
第１通信モードＡ１＞第２通信モードＩ１＞第３通信モードＩ２＞第４通信モードＡ２
【００３８】
図４より、ある通信モードから別の通信モードへの遷移の仕方、すなわち通信モードの切替の種類は１４通りあることが分かる。この１４種類の通信モードの切り替えが発生する度にユーザにその旨を通知するのは、ユーザに煩雑さを感じさせる要因となりうるため好ましくない。そこで、通信モードの切り替えを通知するか否かについて、通信モードの優先順位を考慮して、以下の基準を定義する。
【００３９】
基準：ユーザの明示的な指示による通信モードから他の通信モードに切り替わるときは、現在の通信モードが終了する旨を通知する。
【００４０】
上記の基準は、ユーザの明示的な意思により開始された通信を切断することになる場合、その旨をユーザに確認することを意図したものである。例えば、第１通信モードＡ１を用いて他のユーザと対戦ゲームをしているユーザが、ブラウザ３６を用いてインターネット３００上に存在するウェブサイトの閲覧を望んだとする。ブラウザ３６は、ウェブサイトを閲覧するために第１通信モードＡ１から第２通信モードＩ１に切り替える必要があるが、そのためには対戦ゲームを中断しなくてはならない。
【００４１】
ユーザがウェブサイトの閲覧よりもゲームの続行を望むこともあるため、通信モード切替部２８は、アドホックモードを終了してインフラストラクチャモードに移行することをユーザに通知し、ユーザの意思を確認する。図５は、現在の通信モードが切断されることをユーザに知らせる通知画面の一例を示す図である。通信モードの移行を望むユーザは携帯端末装置１００の操作ボタンを押下することで、通信モードの切り替えを選択することができる。また、ゲームの続行を望むユーザは、通信モードの切り替えをキャンセルすることができる。このような通知画面の表示データは、データベース３０に格納されている。なお、現在の通信モードが切断される旨をユーザに通知することは、表示部１４に表示することに代えて、あるいはそれと併用して、警告音や読み上げ等の音声を用いて通知してもよい。
【００４２】
別の例として、第２通信モードＩ１を使用するブラウザ３６を用いてインターネット３００上のウェブサイトからコンテンツをダウンロードしている最中に、ユーザが第１通信モードＡ１を用いて他のユーザと対戦ゲームを開始しようとする場合を考える。この場合、通信モードの切替をユーザに知らせることにより、コンテンツのダウンロードを優先するかゲーム開始を優先するかの意思確認を行う。
【００４３】
これに対し、ユーザの明示的な指示による通信モードでない通信モードからユーザの明示的な指示による通信モードに移行するときは、特段の通知をしなくてもよい。例えば、メーラ３４が第３通信モードＩ２を用いてバックグラウンドでメールの有無を確認しているときに、ユーザが第１通信モードＡ１を用いて他のユーザと対戦ゲームを開始することを考える。通常、メーラ３４がバックグラウンドでメールの有無を確認していることをユーザは認識していない。このため、仮に通信モードの切断や切り替えが通知されると、ユーザは携帯端末装置１００がどのような通信をしているかがにわかには把握できず、困惑することもあり得る。そのようなことを防ぐため、ユーザの明示的な指示による通信モードでない通信モードからユーザの明示的な指示による通信モードに移行するときは、むしろ何も通知しない方が好ましい。
【００４４】
図６は、実施の形態に係るデータベース３０の内部構造を模式的に示す図であり、上述した通信モードの切替を通知するか否かの基準を表形式にまとめたものである。図６は、図４の場合と同様に、第１通信モードをＡ１、第２通信モードをＩ１、第３通信モードをＩ２、第４通信モードをＡ２、および切断モードを切断として省略して記載している。図６において、「Ｙｅｓ」は通信モードの切り替えを通知することを意味し、「Ｎｏ」は通信モードの切り替えを通知しないことを意味する。例えば、遷移前の通信モードが第２通信モードＩ１で、遷移後の通信モードが第１通信モードＡ１である場合、通信モードの切り替えを通知するので、「Ｙｅｓ」が格納されている。
【００４５】
通信モード切替部２８は、アプリケーションから通信モードの切替要求を取得した場合、データベース３０を参照して通信モードの切り替えを通知するか否かを判断する。その結果、通信モードの切り替えを通知する場合、通信モード切替部２８はデータベース３０から通知画面のデータを取得して表示部１４に出力する。通信モードの切り替えを通知しない場合、通信モード切替部２８は通信モードＡＰＩに通信部１０の通信モードを切り替えさせる。
【００４６】
図７は、実施の形態に係る携帯端末装置１００の各部の処理手順を時系列的に示すフローチャートである。図７に示すフローチャートにおいては、各部の処理手順を、ステップを意味するＳ（Ｓｔｅｐの頭文字）と数字との組み合わせによって表示する。また、Ｓと数字との組み合わせによって表示した処理で何らかの判断処理が実行され、その判断結果が肯定的であった場合は、Ｙ（Ｙｅｓの頭文字）を付加して、例えば、（Ｓ８のＹ）と表示し、逆にその判断結果が否定的であった場合は、Ｎ（Ｎｏの頭文字）を付加して、（Ｓ８のＮ）と表示する。本フローチャートにおける処理は、携帯端末装置１００が起動したときに開始する。
【００４７】
通信モード切替部２８は、アプリケーションから通信モードの切替の要求を取得する（Ｓ２）。通信モード切替部２８は、通信部１０の現在の通信モードを取得する（Ｓ４）。続いて、通信モード切替部２８は、現在の通信モードと切替後の通信モードとをもとにデータベース３０を参照し、現在の通信モードが切断されることを通知するか否かを判断する（Ｓ６）。
【００４８】
通知の必要がある場合（Ｓ８のＹ）、通信モード切替部２８はデータベース３０から通知画面のデータを読み出して表示部１４に出力し、ユーザの通信モード切り替えの意思を確認する（Ｓ１０）。その結果、ユーザに通信モード切り替えの意思がある場合（Ｓ１２のＹ）、通信モード切替部２８は切り替え後の通信モードＡＰＩを呼び出して通信モードの切り替えを実行する（Ｓ１４）。
【００４９】
通信モードの切り替えを通知するか否かの判断の結果、通信モード切断に伴う通知をする必要がない場合（Ｓ８のＮ）、通信モード切替部２８は切り替え後の通信モードＡＰＩを呼び出して通信モードの切り替えを実行する（Ｓ１４）。
【００５０】
通信モード切替部２８が通信モードの切り替えを実行するか、ユーザに通信モード切り替えの意思がない場合（Ｓ１２のＮ）、本フローチャートにおける処理は終了する。
【００５１】
以上の構成による動作は以下のとおりである。ユーザは、携帯端末装置１００を用いて複数のアプリケーションを並列で実行する。ユーザがあるアプリケーションを実行しようとするとき、そのアプリケーションが携帯端末装置１００における通信部１０の通信モードを切り替える必要がある場合、通信モード切替部２８は表示部１４にその旨を表示する。ユーザはその表示を見て最終的な意思確認を行う。
【００５２】
以上説明したとおり、実施の形態によれば、並列して実行される複数のアプリケーション間で競合する通信を効率的に制御することができる。
【００５３】
以上、本発明を実施の形態をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００５４】
上記の説明では、例えば、第２通信モードＩ１からより優先度の高い第１通信モードＡ１に通信が切り替わるときに、通信モード切替部２８が第２通信モードＩ１が終了する旨の通知をする場合について説明したが、上述の通信モードの優先順位にしたがって、優先順位の低い通信モードから優先順位の高い通信モードに切り替える場合には、通信モード切替部２８は何も通知しないようにしてもよい。
【００５５】
上記の説明では、インフラストラクチャモードは間欠接続であることを前提としたが、アプリケーションの種類によっては常時接続を必要とすることもあり得る。例えば、インフラストラクチャモードを利用したオンラインゲームのようなアプリケーションや、携帯端末装置１００を音楽サーバとして機能させるためのアプリケーションである。この場合、インフラストラクチャモードを常時接続としてもよい。図８は、常時接続の場合の通信モードの遷移を示す状態遷移図である。
【００５６】
間欠接続の場合の通信モードの遷移を示す状態遷移図である図４と比較すると、常時接続の場合は第４通信モードＡ２と切断モードがなく、第１通信モードＡ１、第２通信モードＩ１、および第３通信モードＩ２の３つのモードのみが取り得るモードである。第１通信モードＡ１、第２通信モードＩ１、および第３通信モードＩ２それぞれの間で通信モードを切り替えるときにその旨を通知するか否かは、間欠接続の場合と同じである。常時接続の状態遷移図は、間欠接続の状態遷移図のサブセットとして捉えることができる。したがって、常時接続の場合も図６に示すデータベースをそのまま利用することができる。
【００５７】
上記の説明では、通信モードの優先順位をもとに通信モードの切り替えを通知するか否かの基準を説明したが、通信モードの優先順位および通信モードの切り替えを通知するか否かの基準はアプリケーション毎に変更できるようにしてもよい。これは、例えばアプリケーションが、通信モード切替部２８を介して図６に示す表を表示部１４に提示し、ユーザに編集させる。その結果をデータベース３０にそのアプリケーションに対応づけて格納することで実現できる。
【００５８】
上記の説明では、無線ＬＡＮにおけるインフラストラクチャモードとアドホックモードとの間の通信を制御する場合について説明したが、携帯電話通信網と無線ＬＡＮとの通信を制御してもよい。以下この場合の実施の形態について説明するが、上述した実施の形態と共通する部分は適宜省略または簡略化して説明する。
【００５９】
図９は、別の実施の形態に係る携帯端末装置１００の無線ＬＡＮおよび携帯電話通信網の接続を説明するための図である。携帯端末装置１００の通信部１０は、Wi-Fi（登録商標）モジュールの他に、３Ｇ（3rd Generation）通信モジュール（図示せず）を含み、アドホックモードやインフラストラクチャモードによる通信時はWi-Fi（登録商標）モジュールを使用し、携帯電話通信網による通信は３Ｇ通信モジュールを利用する。携帯端末装置１００は、携帯電話通信網を利用する場合、３Ｇ通信モジュールを用いて基地局４００に接続し、基地局４００を経由してインターネット３００にアクセスする。
【００６０】
無線ＬＡＮを利用する場合と携帯電話通信網を利用する場合とでは、使用する通信モジュールが異なるため、両者を同時に使用することは理論的には可能である。しかしながら、前述したとおり、携帯端末装置１００は電池で駆動するため、両者を同時に使用することは消費電力が大きく現実的ではない。また、携帯端末装置１００は携帯しやすくするために小型化されており、両者を同時に使用することは発熱を抑えるのが困難となりうる。
【００６１】
そこで通信制御部１６は、携帯電話通信網と近距離無線通信である無線ＬＡＮとがともに通信可能な場合、無線ＬＡＮを使用するようにする。無線ＬＡＮによる通信は携帯電話通信網による通信と比較して安価かつ広帯域の場合が多く、ユーザにとっては通信コストおよび通信時間を抑制しうる点で有利である。
【００６２】
なお、携帯電話通信網と無線ＬＡＮとの通信の確立の制御のみならず、携帯電話通信網と近距離無線通信であるBluetooth（登録商標）等をはじめとする他の近距離無線通信との制御も同様に可能である。
【符号の説明】
【００６３】
１０ 通信部、 １４ 表示部、 １６ 通信制御部、 １８ アプリケーション実行部、 ２０ 第１通信モードＡＰＩ、 ２２ 第２通信モードＡＰＩ、 ２４ 第３通信モードＡＰＩ、 ２６ 第４通信モードＡＰＩ、 ２８ 通信モード切替部、 ３０ データベース、 ３２ ゲーム、 ３４ メーラ、 ３６ ブラウザ、 １００ 携帯端末装置、 ２００ アクセスポイント、 ３００ インターネット、 ４００ 基地局。
【技術分野】
【０００１】
この発明は、携帯端末装置およびその携帯端末装置において異なる通信モードの切り替えを制御するための通信切替方法に関する。
【背景技術】
【０００２】
情報端末の小型化および軽量化が実現されたことにより、情報端末を持ち運ぶことが一般的になってきた。近年では、基地局やアクセスポイントなどのインフラを利用して、複数のユーザがゲームなどのアプリケーションを一緒に楽しむことも多く行われる。また一方で、オンデマンド型の通信として無線アドホックネットワークを構築する技術も広く用いられるようになってきている（特許文献１参照）。
【０００３】
アドホックネットワークでは、基地局やアクセスポイントが不要となるため、このようなインフラが存在しない場所でも簡易に無線ネットワークを構築することができる。アドホックネットワークでは、複数のユーザが携帯型ゲーム機を持ち寄って相互に無線通信することで、一緒にゲームを楽しむことも可能となる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】米国特許出願公開２００５／２５０４８７号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００５】
これらの無線通信は、例えばIEEE802.11通信技術を用いて実現される。情報端末には、このような通信技術を実装したひとつの通信モジュールが搭載されることが一般的である。このため、情報端末において通信モジュールを利用しうるアプリケーションが並列に実行される場合には、アプリケーション間で通信モジュールの使用が競合する可能性がある。このような理由から、競合する通信を効率的に制御することのできる技術が求められている。
【０００６】
本発明はこうした課題に鑑みてなされたものであり、その目的は、競合する通信を効率的に制御することのできる技術を提供することにある。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明のある態様は、携帯端末装置である。この装置は、他の携帯端末装置と直接通信する第１通信モードまたは中継機器を介して外部ネットワークと接続する第２通信モードで無線通信を行う通信部と、前記通信部の動作を制御する通信制御部とを含む。ここで前記通信制御部は前記通信部の通信モードの切り替えを制御するものであり、第１通信モードから第２通信モードに切り替えるときは第１モードを終了することを通知する。
【０００８】
本発明の別の態様は、携帯端末装置で実行される通信切替方法である。この方法は、他の携帯端末装置と直接通信する第１通信モードまたは中継機器を介して外部ネットワークと接続する第２通信モードで通信するステップと、第１通信モードから第２通信モードに切り替えるときは第１モードを終了することを通知するステップとを含む。
【０００９】
本発明のさらに別の態様も、携帯端末装置である。この装置は、携帯電話通信網を介して外部と通信する第１通信部と、前記携帯電話通信網通信部と比較して近距離での無線通信をするように構成された、中継機器を介して外部ネットワークと通信する第２通信部と、前記第１通信部と前記第２通信部との動作を制御する通信制御部とを含む。ここで前記通信制御部は、前記第１通信部と前記第２通信部とがともに通信可能な場合、前記第２通信部を使用する。
【００１０】
なお、以上の構成要素の任意の組み合わせ、本発明の表現を方法、装置、システム、コンピュータプログラム、データ構造、記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１１】
本発明によれば、競合する通信を効率的に制御することのできる技術を提供することができる。
【図面の簡単な説明】
【００１２】
【図１】実施の形態に係る携帯端末装置の接続状態を説明するための図である。
【図２】実施の形態に係る携帯端末装置の各機能を模式的に示す図である。
【図３】実施の形態に係る携帯端末装置における通信接続の種類を示す図である。
【図４】実施の形態に係る携帯端末装置の通信モードの遷移を示す状態遷移図である。
【図５】通信モードの切り替えをユーザに知らせる通知画面の一例を示す図である。
【図６】実施の形態に係るデータベースの内部構造を模式的に示す図である。
【図７】実施の形態に係る携帯端末装置の処理の流れを説明するフローチャートである。
【図８】常時接続の場合の通信モードの遷移を示す状態遷移図である。
【図９】別の実施の形態に係る携帯端末装置の通信接続を説明するための図である。
【発明を実施するための形態】
【００１３】
以下、図面を参照して本発明の実施の形態について説明する。
【００１４】
図１は、実施の形態に係る携帯端末装置１００の接続状態を説明するための図である。携帯端末装置１００ａおよび携帯端末装置１００ｂは、例えばIEEE802.11で標準化されている無線ＬＡＮ（Local Area Network）を用いて相互に直接通信したり、アクセスポイント２００等の中継機器を介してインターネット３００等の外部ネットワークと通信したりする。
【００１５】
複数の携帯端末装置１００ａ、１００ｂが、アクセスポイント２００を介さないで直接無線で通信する通信モードは「アドホックモード」と呼ばれている。また、携帯端末装置１００ａまたは携帯端末装置１００ｂが、アクセスポイント２００を介して外部ネットワークと無線で通信するモードは「インフラストラクチャモード」と呼ばれている。以下本明細書において、携帯端末装置１００ａと携帯端末装置１００ｂとは、区別の必要がない限り単に「携帯端末装置１００」と総称する。なお、図１に明示はしていないが、実施の形態に係る携帯端末装置１００においては、アドホックモードとインフラストラクチャモードとのふたつの通信モードで同時に通信することはできない。
【００１６】
図２は、実施の形態に係る携帯端末装置１００の各機能を模式的に示す図である。携帯端末装置１００は、通信部１０、表示部１４、通信制御部１６、およびアプリケーション実行部１８を含む。
【００１７】
図２は、実施の形態に係る携帯端末装置１００を実現するための機能構成を示しており、その他の構成は省略している。図２において、さまざまな処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、ＣＰＵ、メインメモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、メインメモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組み合わせによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。
【００１８】
携帯端末装置１００の各部は、図示しないオペレーティングシステムによって統括的に制御される。実施の形態に係る携帯端末装置１００において、オペレーティングシステムによる管理の下、複数のアプリケーションがアプリケーション実行部１８で並列に実行される。アプリケーションとしては、例えばゲーム３２、メーラ３４、ブラウザ３６等があげられる。
【００１９】
表示部１４は、アプリケーション実行部１８によるアプリケーションの実行結果を表示したり、通信制御部１６からユーザへの通知画面を表示したりする。表示部１４は、例えばＬＣＤ（Liquid Crystal Display）やＯＥＬ（Organic Electro- Luminescence）等の既知の技術を用いて実現できる。通信部１０は、無線ＬＡＮで通信するように構成されたハードウェアデバイスである。通信部１０は、通信モードとしてアドホックモードとインフラストラクチャモードとの両方に対応している。通信部１０は、例えばWi-Fi（登録商標）モジュール等の既存の無線通信モジュールを用いて実現できる。
【００２０】
実施の形態に係る携帯端末装置１００において、携帯端末装置１００の外部と通信をしようとするアプリケーションは、通信部１０を直接制御することはしない。その代わり、アプリケーションは、オペレーティングシステムが管理する通信制御部１６を介して外部と通信をする。このため、アプリケーションは、外部との通信の接続や通信の切断を管理する必要がなく、単に通信制御部１６に対してデータを送受信するだけでよい。この意味で、アプリケーションにとって通信制御部１６はデータ送受信のためのＡＰＩ（Application Programming Interface）として機能する。
【００２１】
例えば、電子メールの送受信をするためのクライアントアプリケーションであるメーラ３４は、通信部１０およびアクセスポイント２００を介して、外部ネットワーク上に存在するメールサーバ等と通信する。この場合、通信部１０は前述のインフラストラクチャモードで通信する。メーラ３４は、通信部１０とアクセスポイント２００との間の通信の接続や切断には関与せず、通信制御部１６に対してデータを送受信する。別の例として、複数のユーザが携帯端末装置１００を持ち寄って相互に直接通信し、対戦ゲーム等を実現するためのアプリケーションであるゲーム３２は、通信部１０を介して他の携帯端末装置１００と直接通信する。この場合、通信部１０は前述のアドホックモードで通信する。
【００２２】
ところで、通信部１０がいずれかの外部機器と通信を確立している間は、アプリケーションからデータの送受信がない場合でも、確立を維持するために外部機器と信号をやり取りする必要があり、電力を消費する。実施の形態に係る携帯端末装置１００は、ユーザが携帯して利用することができるように、図示しないバッテリから電源の供給を受けて駆動する。このため、バッテリを長持ちさせることを目的として、通信部１０は、アプリケーションが通信を必要とするときにのみ外部機器と接続する「間欠接続」を行う。
【００２３】
より具体的に、間欠接続とは、アプリケーションが通信を必要とするときにのみ通信を確立して通信し、アプリケーションが所定の時間（例えば２分間）通信しなくなると通信を切断するものであり、外部機器との通信が間欠的となる。仮に携帯端末装置１００の近傍にアクセスポイント２００が存在し、通信部１０がインフラストラクチャモードで常時接続できる状況であったとしても、上記の目的から間欠接続が採用される。通信制御部１６は、アプリケーションから通信の要求を取得すると、後述する４つの通信モードＡＰＩを用いて通信の接続および切断を制御する。
【００２４】
例として、インフラストラクチャモードによる通信を利用するメーラ３４について考える。簡単のため、携帯端末装置１００においてメーラ３４以外のアプリケーションは実行されていないものとする。メーラ３４を起動したユーザは、外部ネットワーク上のメールサーバにメールが届いているか否かの確認、およびメールが届いている場合にはそのメールをダウンロードするために、メーラ３４にメールの受信を指示する。ユーザからの指示を受け、メーラ３４は通信制御部１６に受信の要求をする。この結果、通信部１０は切断状態からインフラストラクチャモードによる通信状態となり、アクセスポイント２００を介してメールサーバと情報のやり取りをする。メールの確認およびダウンロードが終了した後所定の時間が経過すると、通信制御部１６は通信部１０を切断状態に戻す。
【００２５】
メーラ３４は、所定の時間間隔（例えば３０分間隔）で自動的にメールサーバ上のメールの有無およびメールのダウンロードを行うように設定される場合もある。このような場合、メーラ３４は所定の時間間隔毎に、ユーザからの明示的な指示を受けることなく、「バックグラウンドプロセス」として受信要求をする。以上のように、インフラストラクチャモードによる通信は、ユーザの明示的な指示を契機として開始する場合と、バックグラウンドで開始する場合との、ふたつの接続の契機が存在する。
【００２６】
インフラストラクチャモードによる通信の場合と同様に、アドホックモードによる通信も、ユーザの明示的な指示を契機として開始する場合と、バックグラウンドで開始する場合との、ふたつの接続の契機が存在する。前者の例は、ユーザがアプリケーションとしてゲーム３２を利用する場合である。ゲーム３２が、例えばあるユーザが近くにいる別のユーザが所持する携帯端末装置１００と通信しながら共同してひとつのゲームを楽しむものであるとする。ある携帯端末装置１００ａを持つユーザは、別のユーザの持つ携帯端末装置１００ｂと接続することを、携帯端末装置１００ａ上で実行されるゲーム３２に明示的に指示する。
【００２７】
これに対し、後者の例は、スリープ状態となっているふたつの異なる携帯端末装置１００同士がアドホックモードで通信可能な所定の範囲内にあるときに、両者がバックグラウンドで通信する場合である。この場合、近傍の携帯端末装置１００同士が自動的かつ瞬時にアドホックモードで通信を行う。例えば、この通信モードを利用するゲーム３２がメモリ上に常駐している携帯端末装置１００同士がアドホックモードで通信可能な距離に接近したときに、いずれの通信部１０も接続中でなければ、ゲーム３２に関連するデータを交換すること等に利用される。
【００２８】
図３は、実施の形態に係る携帯端末装置１００における通信接続の種類を示す図であり、以上説明した通信モードを表形式にまとめた図である。図３に示すように、本明細書において、ユーザからの指示を契機として他の携帯端末装置１００とアドホックモードで直接通信する通信モードを「第１通信モードＡ１」と呼ぶ。同様に、ユーザからの指示を契機としてアクセスポイント２００を介して外部ネットワークとインフラストラクチャモードで通信する通信モードを「第２通信モードＩ１」と呼ぶ。また、携帯端末装置１００で実行されるアプリケーションによって、バックグラウンドでアクセスポイント２００を介してインフラストラクチャモードの通信をする通信モードを「第３通信モードＩ２」と呼ぶ。
【００２９】
さらに、携帯端末装置１００で実行されるアプリケーションによって、バックグラウンドでアドホックモードの通信をする通信モードを「第４通信モードＡ２」と呼ぶ。図２における通信制御部１６は、これら４つの通信モードそれぞれによる通信の接続、データの送受信、および通信の切断を管理するＡＰＩ群である、第１通信モードＡＰＩ２０、第２通信モードＡＰＩ２２、第３通信モードＡＰＩ２４、および第４通信モードＡＰＩ２６を含む。
【００３０】
なお、便宜上、通信開始の契機が異なる場合は異なる通信モードとして説明するが、実際には通信開始の契機で場合分けすることなく、インフラストラクチャモードによる通信の管理およびアドホックモードによる通信の管理をそれぞれ行うふたつの通信モードＡＰＩを用意するだけでもよい。この場合、第１通信モードＡ１は「アドホック通信モードにおける第１接続モード」、第２通信モードＩ１は「インフラストラクチャ通信モードにおける第１接続モード」、第３通信モードＩ２は、「インフラストラクチャ通信モードにおける第２接続モード」、第４通信モードＡ２は「アドホック通信モードにおける第２接続モード」となる。
【００３１】
以上は、実施の形態に係る携帯端末装置１００において、メーラ３４等のアプリケーションが単独で実行される場合を想定して説明したが、前述したように、携帯端末装置１００上では複数のアプリケーションが同時に並列して実行されうる。通信部１０は、通信モードとしてアドホックモードとインフラストラクチャモードとの両方に対応する場合であっても、ふたつのモードで同時に通信をすることは困難である。このため、携帯端末装置１００において同時に実行されている複数のアプリケーションそれぞれが異なる通信モードを使用する場合、通信モードを切り替える必要があり、その場合ユーザに対して通信を切り替える旨か、少なくとも現在の通信モードが切断される旨の通知をした方が好ましい。
【００３２】
一方で、通信機能を利用するアプリケーションの数が多くなると、通信切替の度にその旨を通知するのは処理が煩雑となり、ユーザにとっても煩わしくなる恐れがある。そこで、通信制御部１６は、複数のアプリケーションの間で通信を制御する通信モード切替部２８および通信モードの切り替えに伴う通知をするか否かの基準を格納するデータベース３０も含む。
【００３３】
以下、通信モードの切替通知の基準を説明するが、まずその前提となる通信モードの遷移について述べる。
【００３４】
図４は、実施の形態に係る携帯端末装置１００の通信モードの遷移を示す状態遷移図である。図４において、第１通信モードをＡ１、第２通信モードをＩ１、第３通信モードをＩ２、および第４通信モードをＡ２と省略して記載している。また、上記の通信モードの他に、携帯端末装置１００に通信を切断している状態も取り得る。以下、携帯端末装置１００が通信を切断している状態を、便宜上「切断モード」と呼ぶ。
【００３５】
前述したように、携帯端末装置１００は間欠接続を採用する。第４通信モードＡ２は、この間欠接続の隙間を利用する通信モードである。したがって、第４通信モードＡ２は切断モードからのみ遷移可能であり、また第４通信モードＡ２は切断モードにのみ遷移する。第４通信モードＡ２は、第１通信モードＡ１、第２通信モードＩ１、および第３通信モードＩ２よりも、優先順位の低い通信モードといえる。
【００３６】
一方、第１通信モードＡ１、第２通信モードＩ１、第３通信モードＩ２、および切断モードは、互いにそれぞれのモードに遷移することができる。しかしながら、インフラストラクチャモードである第２通信モードＩ１および第３通信モードＩ２は、タイムシェアリングによって複数のアプリケーションが並列で通信部１０を利用できるが、アドホックモードである第１通信モードＡ１は、単独のアプリケーションが通信部１０を独占的に使用することになる。この意味で、第１通信モードＡ１は、第２通信モードＩ１および第３通信モードＩ２よりも優先順位の高い通信モードといえる。第２通信モードＩ１と第３通信モードＩ２とでは、ユーザの明示的な指示を契機とする第２通信モードＩ１の方が優先順位が高い。
【００３７】
以上より、第１通信モードＡ１、第２通信モードＩ１、第３通信モードをＩ２、および第４通信モードＡ２の優先順位は、以下のようになる。
第１通信モードＡ１＞第２通信モードＩ１＞第３通信モードＩ２＞第４通信モードＡ２
【００３８】
図４より、ある通信モードから別の通信モードへの遷移の仕方、すなわち通信モードの切替の種類は１４通りあることが分かる。この１４種類の通信モードの切り替えが発生する度にユーザにその旨を通知するのは、ユーザに煩雑さを感じさせる要因となりうるため好ましくない。そこで、通信モードの切り替えを通知するか否かについて、通信モードの優先順位を考慮して、以下の基準を定義する。
【００３９】
基準：ユーザの明示的な指示による通信モードから他の通信モードに切り替わるときは、現在の通信モードが終了する旨を通知する。
【００４０】
上記の基準は、ユーザの明示的な意思により開始された通信を切断することになる場合、その旨をユーザに確認することを意図したものである。例えば、第１通信モードＡ１を用いて他のユーザと対戦ゲームをしているユーザが、ブラウザ３６を用いてインターネット３００上に存在するウェブサイトの閲覧を望んだとする。ブラウザ３６は、ウェブサイトを閲覧するために第１通信モードＡ１から第２通信モードＩ１に切り替える必要があるが、そのためには対戦ゲームを中断しなくてはならない。
【００４１】
ユーザがウェブサイトの閲覧よりもゲームの続行を望むこともあるため、通信モード切替部２８は、アドホックモードを終了してインフラストラクチャモードに移行することをユーザに通知し、ユーザの意思を確認する。図５は、現在の通信モードが切断されることをユーザに知らせる通知画面の一例を示す図である。通信モードの移行を望むユーザは携帯端末装置１００の操作ボタンを押下することで、通信モードの切り替えを選択することができる。また、ゲームの続行を望むユーザは、通信モードの切り替えをキャンセルすることができる。このような通知画面の表示データは、データベース３０に格納されている。なお、現在の通信モードが切断される旨をユーザに通知することは、表示部１４に表示することに代えて、あるいはそれと併用して、警告音や読み上げ等の音声を用いて通知してもよい。
【００４２】
別の例として、第２通信モードＩ１を使用するブラウザ３６を用いてインターネット３００上のウェブサイトからコンテンツをダウンロードしている最中に、ユーザが第１通信モードＡ１を用いて他のユーザと対戦ゲームを開始しようとする場合を考える。この場合、通信モードの切替をユーザに知らせることにより、コンテンツのダウンロードを優先するかゲーム開始を優先するかの意思確認を行う。
【００４３】
これに対し、ユーザの明示的な指示による通信モードでない通信モードからユーザの明示的な指示による通信モードに移行するときは、特段の通知をしなくてもよい。例えば、メーラ３４が第３通信モードＩ２を用いてバックグラウンドでメールの有無を確認しているときに、ユーザが第１通信モードＡ１を用いて他のユーザと対戦ゲームを開始することを考える。通常、メーラ３４がバックグラウンドでメールの有無を確認していることをユーザは認識していない。このため、仮に通信モードの切断や切り替えが通知されると、ユーザは携帯端末装置１００がどのような通信をしているかがにわかには把握できず、困惑することもあり得る。そのようなことを防ぐため、ユーザの明示的な指示による通信モードでない通信モードからユーザの明示的な指示による通信モードに移行するときは、むしろ何も通知しない方が好ましい。
【００４４】
図６は、実施の形態に係るデータベース３０の内部構造を模式的に示す図であり、上述した通信モードの切替を通知するか否かの基準を表形式にまとめたものである。図６は、図４の場合と同様に、第１通信モードをＡ１、第２通信モードをＩ１、第３通信モードをＩ２、第４通信モードをＡ２、および切断モードを切断として省略して記載している。図６において、「Ｙｅｓ」は通信モードの切り替えを通知することを意味し、「Ｎｏ」は通信モードの切り替えを通知しないことを意味する。例えば、遷移前の通信モードが第２通信モードＩ１で、遷移後の通信モードが第１通信モードＡ１である場合、通信モードの切り替えを通知するので、「Ｙｅｓ」が格納されている。
【００４５】
通信モード切替部２８は、アプリケーションから通信モードの切替要求を取得した場合、データベース３０を参照して通信モードの切り替えを通知するか否かを判断する。その結果、通信モードの切り替えを通知する場合、通信モード切替部２８はデータベース３０から通知画面のデータを取得して表示部１４に出力する。通信モードの切り替えを通知しない場合、通信モード切替部２８は通信モードＡＰＩに通信部１０の通信モードを切り替えさせる。
【００４６】
図７は、実施の形態に係る携帯端末装置１００の各部の処理手順を時系列的に示すフローチャートである。図７に示すフローチャートにおいては、各部の処理手順を、ステップを意味するＳ（Ｓｔｅｐの頭文字）と数字との組み合わせによって表示する。また、Ｓと数字との組み合わせによって表示した処理で何らかの判断処理が実行され、その判断結果が肯定的であった場合は、Ｙ（Ｙｅｓの頭文字）を付加して、例えば、（Ｓ８のＹ）と表示し、逆にその判断結果が否定的であった場合は、Ｎ（Ｎｏの頭文字）を付加して、（Ｓ８のＮ）と表示する。本フローチャートにおける処理は、携帯端末装置１００が起動したときに開始する。
【００４７】
通信モード切替部２８は、アプリケーションから通信モードの切替の要求を取得する（Ｓ２）。通信モード切替部２８は、通信部１０の現在の通信モードを取得する（Ｓ４）。続いて、通信モード切替部２８は、現在の通信モードと切替後の通信モードとをもとにデータベース３０を参照し、現在の通信モードが切断されることを通知するか否かを判断する（Ｓ６）。
【００４８】
通知の必要がある場合（Ｓ８のＹ）、通信モード切替部２８はデータベース３０から通知画面のデータを読み出して表示部１４に出力し、ユーザの通信モード切り替えの意思を確認する（Ｓ１０）。その結果、ユーザに通信モード切り替えの意思がある場合（Ｓ１２のＹ）、通信モード切替部２８は切り替え後の通信モードＡＰＩを呼び出して通信モードの切り替えを実行する（Ｓ１４）。
【００４９】
通信モードの切り替えを通知するか否かの判断の結果、通信モード切断に伴う通知をする必要がない場合（Ｓ８のＮ）、通信モード切替部２８は切り替え後の通信モードＡＰＩを呼び出して通信モードの切り替えを実行する（Ｓ１４）。
【００５０】
通信モード切替部２８が通信モードの切り替えを実行するか、ユーザに通信モード切り替えの意思がない場合（Ｓ１２のＮ）、本フローチャートにおける処理は終了する。
【００５１】
以上の構成による動作は以下のとおりである。ユーザは、携帯端末装置１００を用いて複数のアプリケーションを並列で実行する。ユーザがあるアプリケーションを実行しようとするとき、そのアプリケーションが携帯端末装置１００における通信部１０の通信モードを切り替える必要がある場合、通信モード切替部２８は表示部１４にその旨を表示する。ユーザはその表示を見て最終的な意思確認を行う。
【００５２】
以上説明したとおり、実施の形態によれば、並列して実行される複数のアプリケーション間で競合する通信を効率的に制御することができる。
【００５３】
以上、本発明を実施の形態をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００５４】
上記の説明では、例えば、第２通信モードＩ１からより優先度の高い第１通信モードＡ１に通信が切り替わるときに、通信モード切替部２８が第２通信モードＩ１が終了する旨の通知をする場合について説明したが、上述の通信モードの優先順位にしたがって、優先順位の低い通信モードから優先順位の高い通信モードに切り替える場合には、通信モード切替部２８は何も通知しないようにしてもよい。
【００５５】
上記の説明では、インフラストラクチャモードは間欠接続であることを前提としたが、アプリケーションの種類によっては常時接続を必要とすることもあり得る。例えば、インフラストラクチャモードを利用したオンラインゲームのようなアプリケーションや、携帯端末装置１００を音楽サーバとして機能させるためのアプリケーションである。この場合、インフラストラクチャモードを常時接続としてもよい。図８は、常時接続の場合の通信モードの遷移を示す状態遷移図である。
【００５６】
間欠接続の場合の通信モードの遷移を示す状態遷移図である図４と比較すると、常時接続の場合は第４通信モードＡ２と切断モードがなく、第１通信モードＡ１、第２通信モードＩ１、および第３通信モードＩ２の３つのモードのみが取り得るモードである。第１通信モードＡ１、第２通信モードＩ１、および第３通信モードＩ２それぞれの間で通信モードを切り替えるときにその旨を通知するか否かは、間欠接続の場合と同じである。常時接続の状態遷移図は、間欠接続の状態遷移図のサブセットとして捉えることができる。したがって、常時接続の場合も図６に示すデータベースをそのまま利用することができる。
【００５７】
上記の説明では、通信モードの優先順位をもとに通信モードの切り替えを通知するか否かの基準を説明したが、通信モードの優先順位および通信モードの切り替えを通知するか否かの基準はアプリケーション毎に変更できるようにしてもよい。これは、例えばアプリケーションが、通信モード切替部２８を介して図６に示す表を表示部１４に提示し、ユーザに編集させる。その結果をデータベース３０にそのアプリケーションに対応づけて格納することで実現できる。
【００５８】
上記の説明では、無線ＬＡＮにおけるインフラストラクチャモードとアドホックモードとの間の通信を制御する場合について説明したが、携帯電話通信網と無線ＬＡＮとの通信を制御してもよい。以下この場合の実施の形態について説明するが、上述した実施の形態と共通する部分は適宜省略または簡略化して説明する。
【００５９】
図９は、別の実施の形態に係る携帯端末装置１００の無線ＬＡＮおよび携帯電話通信網の接続を説明するための図である。携帯端末装置１００の通信部１０は、Wi-Fi（登録商標）モジュールの他に、３Ｇ（3rd Generation）通信モジュール（図示せず）を含み、アドホックモードやインフラストラクチャモードによる通信時はWi-Fi（登録商標）モジュールを使用し、携帯電話通信網による通信は３Ｇ通信モジュールを利用する。携帯端末装置１００は、携帯電話通信網を利用する場合、３Ｇ通信モジュールを用いて基地局４００に接続し、基地局４００を経由してインターネット３００にアクセスする。
【００６０】
無線ＬＡＮを利用する場合と携帯電話通信網を利用する場合とでは、使用する通信モジュールが異なるため、両者を同時に使用することは理論的には可能である。しかしながら、前述したとおり、携帯端末装置１００は電池で駆動するため、両者を同時に使用することは消費電力が大きく現実的ではない。また、携帯端末装置１００は携帯しやすくするために小型化されており、両者を同時に使用することは発熱を抑えるのが困難となりうる。
【００６１】
そこで通信制御部１６は、携帯電話通信網と近距離無線通信である無線ＬＡＮとがともに通信可能な場合、無線ＬＡＮを使用するようにする。無線ＬＡＮによる通信は携帯電話通信網による通信と比較して安価かつ広帯域の場合が多く、ユーザにとっては通信コストおよび通信時間を抑制しうる点で有利である。
【００６２】
なお、携帯電話通信網と無線ＬＡＮとの通信の確立の制御のみならず、携帯電話通信網と近距離無線通信であるBluetooth（登録商標）等をはじめとする他の近距離無線通信との制御も同様に可能である。
【符号の説明】
【００６３】
１０ 通信部、 １４ 表示部、 １６ 通信制御部、 １８ アプリケーション実行部、 ２０ 第１通信モードＡＰＩ、 ２２ 第２通信モードＡＰＩ、 ２４ 第３通信モードＡＰＩ、 ２６ 第４通信モードＡＰＩ、 ２８ 通信モード切替部、 ３０ データベース、 ３２ ゲーム、 ３４ メーラ、 ３６ ブラウザ、 １００ 携帯端末装置、 ２００ アクセスポイント、 ３００ インターネット、 ４００ 基地局。
【特許請求の範囲】
【請求項１】
携帯端末装置であって、
他の携帯端末装置と直接通信する第１通信モードまたは中継機器を介して外部ネットワークと接続する第２通信モードで無線通信を行う通信部と、
前記通信部の動作を制御する通信制御部とを含み、
前記通信制御部は前記通信部の通信モードの切り替えを制御するものであり、第１通信モードから第２通信モードに切り替えるときは第１通信モードを終了することを通知することを特徴とする携帯端末装置。
【請求項２】
前記第２通信モードは、
ユーザからの指示を契機として中継機器を介して外部ネットワークに接続する第１接続モードと、
前記携帯端末装置で実行されるソフトウェアによってバックグラウンドで中継機器を介して外部ネットワークに接続する第２接続モードとを含み、
前記通信制御部は、第２通信モードの第１接続モードから第１通信モードに切り替えるときは第２通信モードを終了することを通知し、第２通信モードの第２接続モードから第１通信モードに切り替えるときは第２通信モードを終了することを通知しないことを特徴とする請求項１に記載の携帯端末装置。
【請求項３】
前記通信制御部は、前記携帯端末装置で実行されるソフトウェアが通信する必要がある場合に前記第２通信モードの通信を確立し、前記ソフトウェアが所定の時間通信をしなくなると前記第２通信モードの通信を切断することを特徴とする請求項１または２に記載の携帯端末装置。
【請求項４】
前記第１通信モードはアドホックモードであり、
前記第２通信モードはインフラストラクチャモードであることを特徴とする請求項１から３のいずれかに記載の携帯端末装置。
【請求項５】
複数のアプリケーションソフトウェアを並列に実行するアプリケーション実行部をさらに含み、
前記通信制御部は、前記複数のアプリケーションソフトウェアそれぞれが使用する前記通信部の通信モードが異なる場合、前記通信部の通信モードの切り替えを制御することを特徴とする請求項１から４のいずれかに記載の携帯端末装置。
【請求項６】
携帯端末装置で実行される通信切替方法であって、
他の携帯端末装置と直接通信する第１通信モードまたは中継機器を介して外部ネットワークと接続する第２通信モードで通信するステップと、
第１通信モードから第２通信モードに切り替えるときは第１モードを終了することを通知するステップとを含むことを特徴とする通信切替方法。
【請求項７】
携帯端末装置で実行されるプログラムであって、
他の携帯端末装置と直接通信する第１通信モードまたは中継機器を介して外部ネットワークと接続する第２通信モードで通信する機能と、
第１通信モードから第２通信モードに切り替えるときは第１モードを終了することを通知する機能とを前記携帯端末装置に実現させることを特徴とするプログラム。
【請求項８】
携帯電話通信網を介して外部と通信する第１通信部と、
前記第１通信部と比較して近距離での無線通信をするように構成された、中継機器を介して外部ネットワークと通信する第２通信部と、
前記第１通信部と前記第２通信部との動作を制御する通信制御部とを含み、
前記通信制御部は、前記第１通信部と前記第２通信部とがともに通信可能な場合、前記第２通信部を使用することを特徴とする携帯端末装置。
【請求項１】
携帯端末装置であって、
他の携帯端末装置と直接通信する第１通信モードまたは中継機器を介して外部ネットワークと接続する第２通信モードで無線通信を行う通信部と、
前記通信部の動作を制御する通信制御部とを含み、
前記通信制御部は前記通信部の通信モードの切り替えを制御するものであり、第１通信モードから第２通信モードに切り替えるときは第１通信モードを終了することを通知することを特徴とする携帯端末装置。
【請求項２】
前記第２通信モードは、
ユーザからの指示を契機として中継機器を介して外部ネットワークに接続する第１接続モードと、
前記携帯端末装置で実行されるソフトウェアによってバックグラウンドで中継機器を介して外部ネットワークに接続する第２接続モードとを含み、
前記通信制御部は、第２通信モードの第１接続モードから第１通信モードに切り替えるときは第２通信モードを終了することを通知し、第２通信モードの第２接続モードから第１通信モードに切り替えるときは第２通信モードを終了することを通知しないことを特徴とする請求項１に記載の携帯端末装置。
【請求項３】
前記通信制御部は、前記携帯端末装置で実行されるソフトウェアが通信する必要がある場合に前記第２通信モードの通信を確立し、前記ソフトウェアが所定の時間通信をしなくなると前記第２通信モードの通信を切断することを特徴とする請求項１または２に記載の携帯端末装置。
【請求項４】
前記第１通信モードはアドホックモードであり、
前記第２通信モードはインフラストラクチャモードであることを特徴とする請求項１から３のいずれかに記載の携帯端末装置。
【請求項５】
複数のアプリケーションソフトウェアを並列に実行するアプリケーション実行部をさらに含み、
前記通信制御部は、前記複数のアプリケーションソフトウェアそれぞれが使用する前記通信部の通信モードが異なる場合、前記通信部の通信モードの切り替えを制御することを特徴とする請求項１から４のいずれかに記載の携帯端末装置。
【請求項６】
携帯端末装置で実行される通信切替方法であって、
他の携帯端末装置と直接通信する第１通信モードまたは中継機器を介して外部ネットワークと接続する第２通信モードで通信するステップと、
第１通信モードから第２通信モードに切り替えるときは第１モードを終了することを通知するステップとを含むことを特徴とする通信切替方法。
【請求項７】
携帯端末装置で実行されるプログラムであって、
他の携帯端末装置と直接通信する第１通信モードまたは中継機器を介して外部ネットワークと接続する第２通信モードで通信する機能と、
第１通信モードから第２通信モードに切り替えるときは第１モードを終了することを通知する機能とを前記携帯端末装置に実現させることを特徴とするプログラム。
【請求項８】
携帯電話通信網を介して外部と通信する第１通信部と、
前記第１通信部と比較して近距離での無線通信をするように構成された、中継機器を介して外部ネットワークと通信する第２通信部と、
前記第１通信部と前記第２通信部との動作を制御する通信制御部とを含み、
前記通信制御部は、前記第１通信部と前記第２通信部とがともに通信可能な場合、前記第２通信部を使用することを特徴とする携帯端末装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１２−１４７３１４（Ｐ２０１２−１４７３１４Ａ）
【公開日】平成２４年８月２日（２０１２．８．２）
【国際特許分類】
【出願番号】特願２０１１−４９５８（Ｐ２０１１−４９５８）
【出願日】平成２３年１月１３日（２０１１．１．１３）
【出願人】（３１００２１７６６）株式会社ソニー・コンピュータエンタテインメント (417)
【Ｆターム（参考）】
【公開日】平成２４年８月２日（２０１２．８．２）
【国際特許分類】
【出願日】平成２３年１月１３日（２０１１．１．１３）
【出願人】（３１００２１７６６）株式会社ソニー・コンピュータエンタテインメント (417)
【Ｆターム（参考）】
[ Back to top ]