(57)【要約】【課題】通信機能部分の電力制御を適正化する（未使用状態では電源供給を停止する）ことにより、通信端末の一層の電力消費抑制を図る。【解決手段】通信端末１は、送信データなしの状態が一定時間続いた場合に通信デバイスを休止状態とする一方、休止状態中に送信データありの状態が検出された場合には通信デバイスを活動状態とする制御手段（中央制御部１１）を含む。通信が行われない期間（送信データなしの状態が一定時間続く期間）においては、通信端末１の通信機能部分（ワイヤレス通信ユニット９）の消費電力が抑えられるから、通信端末１それ自体のより一層の電力消費抑制を図ることができ、電池１４の消耗を回避することができる。【選択図】  図２
2004164566.tif 000002
【特許請求の範囲】
【請求項１】
通信を行うための内蔵又は外付けの通信デバイスに対し、電源を供給する電源供給手段と、
前記通信デバイスを動作させることによる送信データの有無を検知する検知手段と、
前記検知手段によって送信データ無しの状態が一定時間続いたことが検出された場合、前記電源供給手段に対して前記通信デバイスへの電源供給を停止させる供給停止手段と、
この第１の制御手段による電源供給の停止中に前記検知手段によって送信データ有りの状態が検出された場合、前記電源供給手段に対して前記通信デバイスへの供給再開手段と
を備えることを特徴とする通信端末の電力制御装置。
【請求項２】
前記通信端末は、少なくとも前記送信データに関わるアプリケーションプログラムと、このアプリケーションプログラムに関連して前記通信デバイスを動作制御するデバイスドライバとをさらに備え、
前記検知手段は、送信データの有無の検知として、前記アプリケーションプログラムの実行内容に基づく前記デバイスドライバへコールの有無を検知することを特徴とする請求項１記載の通信端末の電力制御装置。
【請求項３】
前記電源供給手段は電池を電源として供給し、この電池の残容量を検出する残容量検出手段と、
この残容量検出手段の検出値に基づいて、前記通信デバイスへの電力供給を制御する第１の供給制御手段と
をさらに備えることを特徴とする請求項１記載の電力制御装置。
【請求項４】
過去に行われたデータの送受信の時間的な統計を計算する計算手段と、
この計算手段による時間的な統計より次回の情報データの送受信までの時間を推定する推定手段とをさらに備え、
前記残容量検出手段は、前記推定手段による推定の結果、前記次回の情報データの送受信までの時間が予め設定した時間よりも長くなることが予測された場合に、前記通信デバイスへの電力供給を制御することを特徴とする請求項３記載の通信端末の電力制御装置。
【請求項５】
前記通信デバイスを介して通信相手を検索する検索手段と、
この検索手段によって通信相手が見つからなかったとき、前記通信デバイスへの電力供給を停止させるよう制御する第２の供給制御手段と
をさらに備えたことを特徴とする請求項１に記載の電力制御装置。
【請求項６】
前記通信デバイスに対する送信データの内容を解析するコマンド解析手段と、
この解析手段により前記送信データにデータの終了を示すコマンド、タグ、記号又はコードが含まれているか否かを判定する判定手段とをさらに備え、
前記検知手段はこの判定手段による判定結果に基づいて、送信データの有無の検知することを特徴とする請求項１記載の電力制御装置。
【請求項７】
前記通信端末は省電力モードと通常モードとを有し、
且つ、電池を電源として動作する通信端末において、省電力モードで無線接続状態にある通信端末がデータ送信を行う際に、省電力モードをオフにした通常モードに移行してデータ送受信を高速に行うことを特徴とする請求項１記載の通信端末の電力制御装置。
【請求項８】
送受信するデータのサイズが設定された基準値よりも大きい場合に、省電力モードをオフにした通常モードに移行してデータ送受信を高速に行うことを特徴とする請求項７記載の電力制御装置。
【請求項９】
動作状態と休止状態の二つの状態をとり得る通信デバイスと、
データ通信の相手先を特定するために用いられる論理アドレスと物理アドレスとの対応テーブルを管理する管理手段と、
前記通信デバイスが動作状態から休止状態に遷移する際に前記対応テーブルをクリアするクリア手段と
を備えたことを特徴とする通信端末の電力制御装置。
【請求項１０】
送信デバイスを介して送信される送信データの有無を検知し、該送信データのなしの状態が一定時間続いた場合には、前記通信デバイスへの電源供給を停止して該通信デバイスを休止状態とする一方、該休止状態中に送信データありの状態が検出された場合には、前記通信デバイスへの電源供給を再開して該通信デバイスを活動状態とする工程を含むことを特徴とする通信端末の電力制御方法。
【請求項１１】
動作状態と休止状態の二つの状態をとり得る通信デバイスが動作状態から休止状態に遷移する際に、データ通信の相手先を特定するために用いられる論理アドレスと物理アドレスとの対応テーブルをクリアする工程を含むことを特徴とする通信端末の電力制御方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、通信端末、詳細には、電池を電源として動作する、たとえば、携帯型のパーソナルコンピュータや携帯型情報端末等の電池寿命の向上に寄与する、通信端末の電力制御装置及び通信端末の電力制御方法に関する。
【０００２】
【従来の技術】
携帯型のパーソナルコンピュータや携帯型情報端末等（以下「通信端末」という）は、その携帯性を活かして、場所を問わずに各種のアプリケーションを使用することができる。
【０００３】
たとえば、多くの通信端末には、スケジュール管理、表計算、ワープロなどのスタンドアロン作業用アプリケーションが実装されており、加えて、ブラウザソフトや電子メールソフトなどのネットワーク端末用プログラムも実装されており、任意の場所で、スケジュールを確認したり、表計算や文書作成を行ったり、又は、インターネットに接続してホームページを閲覧したり、電子メールを送受信したり、あるいは、会社のネットワークなどに接続して資料を閲覧したりすることができる。
【０００４】
ところで、上記の通信端末は、電池を電源としており、通信端末の使用可能時間は、もっぱら電池の寿命に依存する。言うまでもなく、通信端末の使用可能時間はできるだけ長いことが望ましく、そのためには、大型（大容量）の電池を搭載するか、通信端末の電力消費を抑えるかの二つのアプローチがあるものの、電池の大型化は、通信端末のサイズアップや重量増加を招くから好ましくなく、結局、二つ目のアプローチ、すなわち、通信端末の電力消費の抑制が現実的な対策となる。
【０００５】
かかる対策としては、ｂｌｕｅｔｏｏｔｈのような特別な通信プロトコルを利用して、電力消費を抑制する手法が提案されている（例えば、特許文献１参照）。この手法は、ｂｌｕｅｔｏｏｔｈに特有の二つのリンク（ＡＣＬリンクとＳＣＯリンク）でデータ通信が行われているか否かを判定し、二つのリンクでデータ通信が行われていない場合に、物理リンクを切断して電力消費の低減を図るというものである。
【０００６】
【特許文献１】
特開２００２‐１５２３０９号公報
（第４頁左欄の段落番号〔００１８〕〜〔００２０〕、図２）
【０００７】
【発明が解決しようとする課題】
しかしながら、このような手法は、ｂｌｕｅｔｏｏｔｈといった特定の通信プロトコル、とりわけ、特定の無線通信環境下においてのみ有効な技術であり、一般的な無線通信環境下への応用は考え難いものである。
【０００８】
そこで本発明は、通信端末の通信機能部分の消費電力に着目し、無線通信環境の種類に依存されず、且つ、通信機能部分の電力制御を適正化する（未使用状態では電源供給を停止する）ことによって、より一層の電力消費抑制を図ることを目的とするものである。
【０００９】
【課題を解決するための手段】
（１）本発明に係る通信端末の電力制御装置は、通信を行うための内蔵又は外付けの通信デバイスに対し、電源を供給する電源供給手段と、前記通信デバイスを動作させることによる送信データの有無を検知する検知手段と、前記検知手段によって送信データ無しの状態が一定時間続いたことが検出された場合、前記電源供給手段に対して前記通信デバイスへの電源供給を停止させる供給停止手段と、この第１の制御手段による電源供給の停止中に前記検知手段によって送信データ有りの状態が検出された場合、前記電源供給手段に対して前記通信デバイスへの供給再開手段とを備えることを特徴とする。
この発明では、送信データなしの状態が一定時間続いた場合に通信デバイスが休止状態とされる一方、休止状態中に送信データありの状態が検出された場合に、通信デバイスが活動状態とされる。したがって、通信が行われない期間（送信データなしの状態が一定時間続く期間）においては、通信端末の通信機能部分の消費電力が抑えられるから、通信端末それ自体のより一層の電力消費抑制を図ることができ、電池の消耗を回避することができる。
（２）また、本発明の好ましい態様は、前記通信端末は、少なくとも前記送信データに関わるアプリケーションプログラムと、このアプリケーションプログラムに関連して前記通信デバイスを動作制御するデバイスドライバとをさらに備え、前記検知手段は、送信データの有無の検知として、前記アプリケーションプログラムの実行内容に基づく前記デバイスドライバへコールの有無を検知することを特徴とするものである。
この態様では、アプリケーションプログラムの実行内容に基づく前記デバイスドライバへコールの有無を検知することによって、通信デバイスに対する送信データの有無を検知するので、送信データの有無を検知するための改良をアプリケーションプログラムに施す必要がなく、通信のための様々なアプリケーションプログラムをそのまま利用することができ、普遍性を損なうことがない。
（３）また、本発明の好ましい他の態様は、前記電源供給手段は電池を電源として供給し、この電池の残容量を検出する残容量検出手段と、この残容量検出手段の検出値に基づいて、前記通信デバイスへの電力供給を制御する第１の供給制御手段とをさらに備えることを特徴とするものである。
この発明では、電池の残容量に基づいて通信デバイスへの電力供給をオンオフ制御するので、通信デバイスの電力消費を適正化することができる。
（４）また、この発明の好ましい態様は、過去に行われたデータの送受信の時間的な統計を計算する計算手段と、この計算手段による時間的な統計より次回の情報データの送受信までの時間を推定する推定手段とをさらに備え、前記残容量検出手段は、前記推定手段による推定の結果、前記次回の情報データの送受信までの時間が予め設定した時間よりも長くなることが予測された場合に、前記通信デバイスへの電力供給を制御することを特徴とするものである。
この態様では、過去に行われたデータの送受信の時間的な統計を計算し、その計算結果から推定された次回の情報データの送受信までの時間が予め設定した時間よりも長くなることが予測された場合に、前記通信デバイスへの電力供給を制御するので、特定の条件においてのみ、通信デバイスへの電力供給をオンオフ制御して通信デバイスの電力消費をより一層適正化することができる。
（５）また、この発明の他の好ましい態様は、前記通信デバイスを介して通信相手を検索する検索手段と、この検索手段によって通信相手が見つからなかったとき、前記通信デバイスへの電力供給を停止させるよう制御する第２の供給制御手段とをさらに備えたことを特徴とするものである。
この態様では、通信デバイスを介して通信相手を検索し、通信相手が見つからなかったときに通信デバイスへの電力供給を停止させるよう制御するので、通信相手がいない場合の無駄な電力消費を抑制できる。
（６）また、この発明の他の好ましい態様は、前記通信デバイスに対する送信データの内容を解析するコマンド解析手段と、この解析手段により前記送信データにデータの終了を示すコマンド、タグ、記号又はコードが含まれているか否かを判定する判定手段とをさらに備え、前記検知手段はこの判定手段による判定結果に基づいて、送信データの有無の検知することを特徴とするものである。
この態様では、実際の通信データに基づいて、送信データの有無を判定するので、より一層正確な電力供給制御を行うことができる。
（７）また、この発明の他の好ましい態様は、省電力モードと通常モードとを有し、且つ、電池を電源として動作する通信端末において、省電力モードで無線接続状態にある通信端末がデータ送信を行う際に、省電力モードをオフにした通常モードに移行してデータ送受信を高速に行うことを特徴とするものである。
この発明では、通信端末がデータ送信を行う際は、省電力モードから通常モードに切り換えて通信を行うので、通信の高速化を図ることができる。
（８）また、この発明の好ましい態様は、送受信するデータのサイズが設定された基準値よりも大きい場合に、省電力モードをオフにした通常モードに移行してデータ送受信を高速に行うことを特徴とするものである。
この態様では、送受信するデータのサイズに応じてモード切替を行うので、サイズが大きい場合は速度優先、サイズが小さい場合は省電力優先とすることができる。
（９）また、本発明に係る通信端末の電力制御装置は、動作状態と休止状態の二つの状態をとり得る通信デバイスと、データ通信の相手先を特定するために用いられる論理アドレスと物理アドレスとの対応テーブルを管理する管理手段と、前記通信デバイスが動作状態から休止状態に遷移する際に前記対応テーブルをクリアするクリア手段とを備えたことを特徴とするものである。
この発明では、通信デバイスが動作状態から休止状態に遷移する際に対応テーブル（データ通信の相手先を特定するために用いられる論理アドレスと物理アドレスとの対応テーブル）をクリアするので、通信アプリケーションは、この対応テーブルが再構成されるまでの間、通信要求を発行しない（通信要求を待機する）。このため、通信デバイスが休止状態から動作状態へと遷移する前にデータの送受信が開始されてしまうという不都合が無い。しかも、かかる作用にデバイスドライバは一切関与しない。したがって、これによれば、デバイスドライバに全く依存することなく、通信デバイスを休止状態から動作状態へと復帰させる際のデータの抜けを防止することができる。
【００１０】
【発明の実施の形態】
以下、本発明の実施の形態を、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｃｅ）などの持ち運び可能な通信端末への適用を例にして、図面を参照しながら説明する。なお、以下の説明における様々な細部の特定ないし実例および数値や文字列その他の記号の例示は、本発明の思想を明瞭にするための、あくまでも参考であって、それらのすべてまたは一部によって本発明の思想が限定されないことは明らかである。また、周知の手法、周知の手順、周知のアーキテクチャおよび周知の回路構成等（以下「周知事項」）についてはその細部にわたる説明を避けるが、これも説明を簡潔にするためであって、これら周知事項のすべてまたは一部を意図的に排除するものではない。かかる周知事項は本発明の出願時点で当業者の知り得るところであるので、以下の説明に当然含まれている。
【００１１】
＜第１の実施の形態＞
図１は、第１の実施の形態における通信端末の一例外観図である。この図において、発明の要旨に記載の「通信端末」に相当する通信端末１は、たとえば、手持ちに適した任意形状のボディ２の前面に、液晶ディスプレイ等のタッチパネル付き平面型表示部（以下、単に「表示部」という）３、カーソルキー４およびいくつか（図では便宜的に三個）のファンクションキー５〜７を配置すると共に、上面や側面等の外部スロット８に赤外線や無線などのワイヤレス通信ユニット（通信デバイス）９を装着して構成されている。なお、図では省略しているが、ボディ２の任意位置（たとえば側面等）に、通信端末１それ自体の電源供給をオンオフするための電源スイッチが設けられている。
【００１２】
図２は、通信端末１の概念的な内部ブロック図である。このブロック図は、ワイヤレス通信ユニット９、時計部１０、中央制御部（検知手段、供給停止手段、供給再開手段）１１、表示部３、入力部１２、メモリ部１３、電池（電源供給手段）１４および電源制御部（電源供給手段）１５などに分かれており、各部の機能は以下のとおりである。
【００１３】
ワイヤレス通信ユニット９は、外部の通信ネットワークに接続するためのハードウェア要素である。ここでは、説明の便宜上、着脱可能なＰＣＭＣＩＡ（Personal Computer Memory Card International Association）タイプの無線ＬＡＮ（Local Area Network）カードとするが、これに限定されない。他の形態、たとえば、ボードタイプや外付けタイプのものであってもよい。通信端末１の利用目的やその通信端末１の移動範囲などを考慮した適切な通信仕様のものであればよい。また、ワイヤレス通信ユニット９はイーサネット（登録商標）等の有線ユニットであってもよいが、以下の説明では無線を媒体とした通信ユニットとする。すなわち、ワイヤレス通信ユニット９は、アンテナ９ａと無線通信部９ｂとを含み、特に限定しないが、たとえば、ＩＥＥＥ８０２．１１規格のディジタル無線送受信機能（２．４ＧＨｚ帯、若しくは５ＧＨｚ帯の無線電波を使って１１Ｍｂｐｓ〜５０Ｍｂｐｓの速度でディジタルデータの送受信を行うもの）を通信端末１に提供するものとする。
【００１４】
ここで、ワイヤレス通信ユニット９を“無線”を媒体とした通信ユニットとする理由は、有線のものに比べて送信部分の電力消費が大きく、それだけ高い省電力効果が期待されるからであり、実施の形態のベストモードとして適していると思われるからである。したがって、発明の思想上、有線を媒体とした通信ユニットを排除しない。
【００１５】
時計部１０は、実際には、極短い周期（たとえば、数ミリ秒程度）で逐次にカウントアップするタイマ信号を発生する。この時計部１０はバッテリバックアップ（電源をオフにしている間にも電池１４から電力が供給されている）されており、電池１４の電圧が失われない限り、通信端末１の電源スイッチ（不図示）をオフにした後もそのカウントアップ動作を継続する。時計部１０で発生したタイマ信号は中央制御部１１に出力され、中央制御部１１において様々な目的に利用されるが、その代表的な用途の一つは現在日時の特定である。すなわち、中央制御部１１は過去に遡った所定日時（たとえば、西暦１０００年１月１日０時０分０秒）をスタートタイマ値とし、その日時からの累計タイマ値を現在日時として特定する。このような日時特定機能に注目した場合、時計部１０は、単に過去の所定日時からの累計タイマ値をカウントするものにすぎず、日時の特定はもっぱら中央制御部１１によって行われているが、本明細書中では説明の便宜上、日時特定のすべての機能を時計部１０に実装しているものとする。すなわち、時計部１０は、現在日時を特定し、その日時情報（年月日および時分秒）を中央制御部１１に出力するものとする。
【００１６】
中央制御部１１は、マイクロコンピュータチップ（ＣＰＵ）およびその周辺チップを実装した、いわゆるメインボードに相当するものである。この中央制御部１１は、不図示の電源スイッチがオンにされたときに、メモリ部１３のＰＲＯＭ１３ｂからＲＡＭ１３ａにオペレーティングシステム（ＯＳ）とアプリケーションプログラムをロードし、それらを実行することにより、以降、たとえば、スケジュール確認、表計算、文書作成、又は、インターネット上のホームページ閲覧、電子メールの送受信、あるいは、会社のネットワーク上の資料の閲覧などを可能とする。
【００１７】
入力部１２は、ボディ２の前面に設けられたカーソルキー４やファンクションキー５〜７からの操作信号を取り込み、それらを信号整形し、適宜のキーコードに変換して中央制御部１１に出力する。
【００１８】
メモリ部１３は、中央制御部１１のワークエリアとして動作する揮発性の記憶媒体（ＲＡＭ）１３ａと、ＯＳやそのＯＳ上で動作する様々なアプリケーションプログラムを不揮発的且つ書き換え可能に記憶する記憶媒体（ＰＲＯＭ）１３ｂとを備える。なお、図示の例では、ワークエリア（ＲＡＭ１３ａ）とプログラム記憶エリア（ＰＲＯＭ１３ｂ）とを別々に設けているが、これは、現在普及しているＰＤＡなどの通信端末のアーキテクチャに対応させているにすぎない。たとえば、半導体磁気メモリなどの新規デバイスは、不揮発性且つ書き換え可能で、しかもＲＡＭよりも高速性に優れると共に、大容量化も容易であるから、かかる新規デバイスを用いた場合は、ワークエリア（ＲＡＭ１３ａ）とプログラム記憶エリア（ＰＲＯＭ１３ｂ）とを分ける必要がない。すなわち、ワークエリアにプログラムを記憶し、そのまま任意のプログラムを実行することができる。しかも、パワーオンスタート又はクイックオンスタート（電源投入直後に直ちにプログラムを実行すること）を実現できる。また、図示の例では、プログラム記憶用の記憶媒体に半導体の不揮発性書き換え可能メモリ（ＰＲＯＭ）を使用しているが、これに限定されない。ハードディスクなどの大容量磁気記憶デバイス又はその他の不揮発性書き換え可能記憶デバイスであってもよい。
【００１９】
電池１４は、通信端末１の各部の動作に必要な電力を供給するものである。使い捨て型の一次電池であってもよいし、再利用（充電）可能な二次電池であってもよい。なお、図面では、電池１４の電源供給先を電源制御部１５のみとして描いているが、これは図示の都合である。実際には、不図示の電源スイッチを介して、中央制御部１１、表示部３、入力部１２及びメモリ部１３にも供給されている。この図面において読み取るべき重要な事項は、電池１４とワイヤレス通信ユニット９との間の電源供給経路中に電源制御部１５が挿入されている点にある。電源制御部１５の機能は後述する。
【００２０】
ここで、電池１４の出力電圧（一般に「端子電圧」という）は、未使用状態（一次電池の場合）や満充電状態（二次電池の場合）のときに最大値（最大定格値）を示し、使用時間の経過に伴って低下し、ついには最低電圧（通信端末１の動作に必要な最低電圧）を下回った時点で寿命が尽きる。寿命が尽きるまでの時間のことを便宜的に「連続使用可能時間」ということにすると、連続使用可能時間はできるだけ長いことが望ましい。寿命が尽きた電池１４は、一次電池であれば新品と交換し、又は、二次電池であれば充電を行うことによって、再び通信端末１の電源として使用できるようになるものの、電池の交換が煩わしく、又、少なくない充電待ち時間を我慢しなければならないなどの不便がある。連続使用可能時間を長くする（電池１４の消耗を抑制する）ことによってこの不便を克服できる。
【００２１】
電源制御部１５は、ワイヤレス通信ユニット９の電源制御（電源の供給、停止）を行うためのものである。すなわち、この電源制御部１５は、中央制御部１１から適宜に出力される制御信号に応答してワイヤレス通信ユニット９と電池１４との間の接続をオンオフ制御する。オンの場合はワイヤレス通信ユニット９に電池１４からの電力を供給し、オフの場合は電力の供給をストップする。少なくとも、オフ制御している間、ワイヤレス通信ユニット９の電力消費がゼロとなり、それだけ通信端末１の省電力化を図ることができ、電池１４の寿命（連続使用可能時間）を延ばし、上記の不便を克服できる。
【００２２】
次に、中央制御部１１における電力制御シーケンスについて、その詳細を説明する。先に説明したとおり、中央制御部１１は、マイクロコンピュータチップおよびその周辺チップを実装した、いわゆるメインボードに相当するものである。この中央制御部１１は、メモリ部１３に格納されているソフトウェアリソース（ＯＳやそのＯＳ上で動作するアプリケーションプログラム）と、中央制御部１１を含む各部のハードウェアリソースとの有機的結合によって様々な機能を実現する。
【００２３】
図３は、その機能の一例を示す模式図であり、いわゆるＯＳＩ（Open SystemsInterconnectionの略。開放型システム間相互接続）参照モデルを模したものである。モデル２０は、最下位層に物理層２１を配置し、その上に、ドライバ層２２、ネットワークインターフェース層２３、インターネット層２４、トランスポート層２５及びアプリケーション層２６を順次に積層した構造を有する。各層は、自層に隣接する層との間でのみデータの受け渡しを行うことができるように規定されている。
【００２４】
物理層２１には、物理的な通信回線、たとえば、第１の実施の形態の例によれば、ワイヤレス通信ユニット９の無線通信回線が実装されるとともに、ドライバ層２２には、そのワイヤレス通信ユニット９のデバイスドライバが実装される。また、ネットワークインターフェース層２３には、ワイヤレス通信ユニット９の通信プロトコル（ＩＥＥＥ８０２．１１規格のもの）が実装され、その上位のインターネット層２４やトランスポート層２５には、インターネット標準の各種プロトコル、すなわち、ＴＣＰ（Transmission Control Protocol）、ＵＤＰ（Transmission Control Protocol）、ＩＰ（Internet Protocol）及びＩＣＭＰ（Internet Control Message Protocol）など（以下、これらを総称してＴＣＰ／ＩＰという）が実装される。さらに、アプリケーション層２６には、ＴＣＰ／ＩＰを利用して間接的にネットワークインターフェース層２３及びドライバ層２２にアクセスすることにより、このネットワークインターフェース層２３及びドライバ層２２と物理層２１とを介して、たとえば、インターネットやイントラネット（自社内ネットワーク）などとの間でデータの送受信（アップロード／ダウンロードともいう）を行う、電子メールソフトやブラウザソフト等の各種アプリケーションプログラムが実装される。
【００２５】
ＴＣＰ／ＩＰ（正確にはＴＣＰ及びＵＤＰ）には、アプリケーションや上位のレイヤに対してデータを送受信するための“窓口”を提供する機能がある。この窓口は「ポート」と呼ばれており、ＲＦＣ（Request For Comment：インターネットに関する技術の標準を定める団体であるIETFが正式に発行する文書）１７００（ASSIGED NUMBER）によれば、用途別に２５６個のポートが定義されている。代表的なポート番号をいくつか挙げると、２５番はメール送信用のポート（いわゆるＳＭＴＰポート）、１１０番はメール受信用のポート（いわゆるＰＯＰポート）、８０番はウェブブラウジング用のポート（いわゆるＨＴＴＰポート）である。
【００２６】
かかるＯＳＩ参照モデル（モデル２０）の重要な点は、当該モデルに則って（又はその考え方に従って）システムを設計する限り、中間層をパスするデータの受け渡し、たとえば、アプリケーション層２６と物理層２１との間などの直接的なデータの受け渡しは絶対にあり得ないことである。つまり、すべてのダウンロードデータ及びアップロードデータは、使用するプロトコルに応じて、必ずトランスポート層２５やインターネット層２４、ネットワークインターフェース層２３及びドライバ層２２などの中間層を経由するようになっている。
【００２７】
本発明は、かかる点に注目してなされたものであり、アプリケーション層２６以外の中間層（以下の説明ではドライバ層２２）でデータ送受信の有無をモニタし、そのモニタ結果に応じて、物理層２１に実装された通信部（ワイヤレス通信ユニット９）の電源制御を行うというものである。これにより、第一には、データ送受信を行っていない期間のワイヤレス通信ユニット９の電力消費をゼロとして通信端末１の電池１４の延命化を図ることができ、第二には、アプリケーション層２６に実装された各種アプリケーションプログラムに何らの改良を加えることなく、上記の第一の効果を得ることができるという優れたメリットが得られる。
【００２８】
図４は、第１の実施の形態における通信端末１の要部ブロック図である。波線２７で囲まれた部分は、主としてＯＳやそのＯＳ上で動作するアプリケーションプログラムによって実現される機能部を示している。これらの機能部は、たとえば、アプリケーション部２８、トランスポート部２９、ネットワーク部３０、デバイスドライバ部３１、送信時間ファイル３２、電力制御ソフト３３、カードソケット管理モジュール３４などであり、これらは、前記モデル２０のアプリケーション層２６、トランスポート層２５、インターネット層２４、ネットワークインターフェース層２３及びドライバ層２２に実装されたものである。
【００２９】
この図において、アプリケーション部２８は、たとえば、電子メールソフトやブラウザソフトであり、アプリケーション部２８は、データのアップロードを行う際、トランスポート部２９及びネットワーク部３０を介してデバイスドライバ部３１に実装されている所定のデバイスドライバ（ワイヤレス通信ユニット９のデバイスドライバ）にアクセスし、当該デバイスドライバ経由でワイヤレス通信ユニット９を使用してデータの送信を行う。
【００３０】
デバイスドライバ部３１は、アプリケーション部２８からのアップロードデータ（送信データ）を受け取ると、データ送信を扱う所定の関数（以下「データ送信関数」という）をコールし、その関数にアップロードデータを渡してワイヤレス通信ユニット９から送信する。
【００３１】
このように、デバイスドライバ部３１では、アップロードデータが発生したときに必ずデータ送信関数をコールするので、第１の実施の形態では、まず、データ送信関数がコールされるたびにそのときの日時（時計部１０（図２参照）から取得した日時情報）を送信時間ファイル３２に上書き記録する。これにより、送信時間ファイル３２に、最後にアップロードが行われたときの日時を記録することができる。
【００３２】
送信時間ファイル３２に記録された日時情報は、バックグランドで実行される常駐型のソフトである電力制御ソフト３３によって定期的に参照される。電力制御ソフト３３は、送信時間ファイル３２に記録された日時情報と現在の日時との差、すなわち、最後にアップロードが行われたときからの経過時間を計算し、その経過時間が所定のしきい値以上であれば、電源制御部１５に対して、ワイヤレス通信ユニット９への電源供給を停止させ、ワイヤレス通信ユニット９をサスペンド（Ｓｕｓｐｅｎｄ）状態とするための制御信号を出力するとともに、サスペンド状態を示すイベント（サスペンドイベント）を発生して、カードソケット管理モジュール３４経由でデバイスドライバ部３１に通知する。
【００３３】
図５は、電力制御ソフト３３の動作を示すフローチャートである。このフローチャートでは、以上の説明と同様に、まず、送信時間ファイル３２に記録されている日時情報を読み込み（ステップＳ１１）、次いで、現在の日時と読み込んだ日時の差Ｘを演算する（ステップＳ１２）。差Ｘは、最後にアップロードが行われたときからの経過時間を表す。次に、差Ｘと所定のしきい値とを比較し（ステップＳ１３）、しきい値を越えていれば、ワイヤレス通信ユニット９をサスペンド（Ｓｕｓｐｅｎｄ）状態とするための制御信号を出力し（ステップＳ１４）、そうでなければ、ある時間待機（Ｓｌｅｅｐ）してから（ステップＳ１５）、再び以上のフローを繰り返す。
【００３４】
通常、ＯＳのカーネルとデバイスドライバの間では、ある変数のビット（ｂｉｔ）を利用したデータのフロー制御（以下、単に「フロー制御」という）が行われる。このビットがセット（値＝１）されているときはフロー制御はオフ（データの送信停止状態）であり、クリア（値＝０）されているときはフロー制御はオン（データ送信実行状態又はデータ送信可能状態）である。フロー制御がオフになる場合としては、たとえば、デバイスドライバ部３１内の送信用バッファ（送信用データを一時的に蓄えておく領域）が満杯状態になっているとき、又は、ワイヤレス通信ユニット９が非作動状態にあるときなどがある。公知の汎用ＯＳには、フロー制御を操作するための関数が用意されている。たとえば、リナックスＯＳ（Ｌｉｎｕｘ  ＯＳ）の場合、「ｓｔｏｐ」、「ｓｔａｒｔ」及び「ｗａｋｅ」の三つの関数が用意されている。ｓｔｏｐはフロー制御をオフにするためのもの、ｓｔａｒｔはフロー制御をオンにするためのもの、ｗａｋｅはフロー制御をオンにし、且つ、送信用バッファに蓄えられているデータを送信するためのものである。
【００３５】
一方、デバイスドライバ部３１でサスペンドイベントを受信した場合、先に説明したとおり、このイベントは、ワイヤレス通信ユニット９への電源供給停止を表すものであるため、デバイスドライバ部３１はそれ以降のデータ送信を行うことができない。このため、通常は、上記の関数のうちの「ｓｔｏｐ」を発行して、カーネルからデバイスドライバ部３１へのデータフロー（送信データの流れ）を停止させるが、第１の実施の形態においては、デバイスドライバ部３１で送信データの有無を検知するために、この関数（ｓｔｏｐ）を発行しない。したがって、第１の実施の形態においては、サスペンドイベントの受信以降もフロー制御はオンのままであり、データ送信可能状態を維持しているから、アプリケーション部２８から送信があった場合には、デバイスドライバ部３１において、必ず、「データ送信関数」がコールされる。
【００３６】
また、第１の実施の形態では、サスペンドイベントの発生を示すためのフラグ（ｆｌａｇ）を用意する。このフラグのセットは、サスペンドイベントの発生に応答して行われ、リセットは所定の条件を満たしたときにデバイスドライバ部３１で行われる。
【００３７】
今、アプリケーション部２８の、たとえば、ブラウザソフトからデータ送信が行われたと仮定する。ブラウザソフトからの送信データは、トランスポート部２９及びネットワーク部３０に実装されたＴＣＰやＩＰなどを経てドライバ部３１に伝えられ、データ送信関数がコールされる。
【００３８】
図６は、デバイスドライバ部３１における動作（データ送信関数がコールされたときの動作）を表すフローチャートである。このフローチャートでは、まず、そのときの日時を送信時間ファイル３２に記録し（ステップＳ２１）、次いで、フラグがセットされているか否かを判定する（ステップＳ２２）。セットされていない場合（リセット状態にある場合）は、ワイヤレス通信ユニット９が電源供給状態にあるため、通常処理を行い（ステップＳ２３）、一方、セットされていた場合は、まず、フロー制御をオフにし（ステップＳ２４）、それ以降の送信データをデバイスドライバ部３１で受け付けないようにするとともに、ワイヤレス通信ユニット９に電源を供給するための処理（カードソケット管理モジュール３４に対してレジューム；Ｒｅｓｕｍｅを発行）を実行（ステップＳ２５）した後、エラーを返して（ステップＳ２６）、データ送信関数を終了する。
【００３９】
その後、ワイヤレス通信ユニット９がレジュームされ、任意のアクセスポイントとの間で接続が確立すると、デバイスドライバ部３１に対して割り込みを発生する。デバイスドライバ部３１は、この割り込みを受けてフラグをチェックし、セットされていた場合はフラグをリセットする。
【００４０】
これらの処理により、エラーで返された送信データやそれ以降カーネルに蓄えられていた送信データがデバイスドライバ部３１経由でワイヤレス通信ユニット９に転送され、支障なくデータ送信が再開される。
【００４１】
図７は、従来例と第１の実施の形態とを対比するタイミングチャートである。従来例ではフロー制御のオンオフを行うだけで、ワイヤレス通信ユニット９の電力制御は行っていない。これに対して、第１の実施の形態では、デバイスドライバ部３１でデータ送信関数のコールを検出するまでの間、ワイヤレス通信ユニット９をサスペンド状態として電源供給をストップし、データ送信関数のコールを検出したときに、レジュームを発行してワイヤレス通信ユニット９への電源供給を再開し、任意のアクセスポイントとの間の接続が確立したときに、再送用のソフト割り込みを起動してデータ送信を開始する。したがって、少なくともワイヤレス通信ユニット９がサスペンド状態に制御されている間は、その電力消費をゼロとすることができ、通信端末１の電池１４の延命化を図ることができる。
【００４２】
次に、本発明の他の実施の形態について説明する。
＜第２の実施の形態＞
一般に、ＩＥＥＥ８０２．１１などの無線ＬＡＮ通信規格においては、省電力化のための動作モード（パワーセーブモード）が存在する。
図８は、アクセスポイント３５と、そのアクセスポイント３５のサービスエリア３６内に位置する任意数（図では二つ）の通信端末３７、３８を示す図である。各通信端末３７、３８は、パワーセーブモードで動作している場合、アクセスポイント３５との間のデータのやり取りに応じて、「休止状態（Ｄｏｓｅ）」、「受信可能状態（Ａｗａｋｅ」又は「送信状態（Ｔｒａｎｓｍｉｔ）」のいずれかの状態をとる。なお、通信端末３７、３８の内部構成については適宜に、図２を参照するものとする。
【００４３】
図９は、パワーセーブモードにおける状態遷移図、図１０は、パワーセーブモードで使用されるビーコンパケットのタイミングチャートである。図９に示すように、パワーセーブモードにある通信端末３７、３８の初期状態はＤｏｓｅである。通信端末３７、３８は、アクセスポイント３５から定期的に送信されるビーコンパケットを受け取るとＡｗａｋｅに遷移し、そのビーコンパケットのＴＩＭ（Ｔｒａｆｆｉｃ  Ｉｎｄｉｃａｔｉｏｎ  Ｍａｐ）情報に自己宛のデータが含まれているか否かを判定する。そして、含まれていなければＤｏｓｅに復帰し、含まれていればＴｒａｎｓｍｉｔに遷移して、以降のデータ送受信を可能とする。
【００４４】
このパワーセーブモードによれば、定期的に送られてくるビーコンパケットのＴＩＭ情報に自己宛のデータが含まれている場合にのみ、通信端末３７、３８を送信状態（Ｔｒａｎｓｍｉｔ）とするので、とりわけ電力消費の大きい無線送信部（図２のワイヤレス通信ユニット９参照）を間欠的に動作させることができ、それだけ通信端末３７、３８の電池の延命化を図ることができる。
【００４５】
しかしながら、上記のパワーセーブモードにあっては、アクセスポイント３５から定期的（所定のビーコンインターバル）に送られてくるビーコンパケットに応答して必ずＤｏｓｅからＡｗａｋｅへと遷移するため、通信端末３７、３８とアクセスポイント３５との間で実際のデータ転送を行う必要がない場合においても、必然的に無線通信部（図２のワイヤレス通信ユニット９参照）の少なくとも受信部は動作を継続していなければならず、その間、送信部が非作動であったとしても、ワイヤレス通信ユニット９の受信部やその周辺回路の電力消費を抑制できないという欠点があり、とくに、バッテリ（図２の電池１４参照）の残容量が少なくなった場合に不都合を来す（実際にデータを送受信する際に電池切れになってしまう）という問題点があった。
【００４６】
そこで、第２の実施の形態においては、電池の残容量をモニタし、その残容量に応じてワイヤレス通信ユニット９への電源供給をオンオフ制御することにより、上記の問題点の解消を図るものである。
【００４７】
（イ）たとえば、電池を電源とする通信端末において、通信端末の電源を入れる際に、電池の残容量（一般に残容量は電池の端子電圧で表されるため、以下「端子電圧」という）を計測し、その端子電圧が所定の基準値以下であった場合に、通信端末の無線通信部分（図２のワイヤレス通信ユニット９参照）を電源非供給状態とする。そして、無線通信を使用するアプリケーションの起動又は当該アプリケーションからの送信データの発生を検知して、上記無線通信部分の電源供給を開始する。これによれば、電池の残容量が少ない状態で、通信端末の残り動作時間が制限される場合において、実際にデータ送信が必要とされるときにのみ、上記無線通信部分の電源供給を開始することにより、電池の消耗を抑制し、通信端末の動作可能時間を長くすることができる。
【００４８】
（ロ）または、電池を電源とする通信端末において、通信端末の電源を入れる際に、無線通信の接続相手（図９のアクセスポイント３５参照）を検索し、接続相手が見つからなかった場合に、電池の端子電圧を計測し、その端子電圧が所定の基準値以下であった場合に、通信端末の無線通信部分（図２のワイヤレス通信ユニット９参照）を電源非供給状態とする。そして、無線通信を使用するアプリケーションの起動又は当該アプリケーションからの送信データの発生を検知して、上記無線通信部分の電源供給を開始すると共に、再度通信相手を検索してその相手との間でデータ送受信を行う。これによれば、電池の残容量が少ない状態で、通信端末の残り動作時間が制限される場合において、実際にデータ送信が必要とされるときにのみ、上記無線通信部分の電源供給を開始することにより、電池の消耗を抑制し、通信端末の動作可能時間を長くすることができる。
【００４９】
（ハ）または、電池を電源とする通信端末において、無線通信接続相手との間で一連のデータ送受信が終了した後、所定の時間を経過すると、切断処理を行った上で、通信端末の無線通信部分（図２のワイヤレス通信ユニット９参照）を電源非供給状態とする。そして、無線通信を使用するアプリケーションの起動又は当該アプリケーションからの送信データの発生を検知して、上記無線通信部分の電源供給を開始する。これによれば、電池の残容量が少ない状態で、通信端末の残り動作時間が制限される場合において、実際にデータ送信が必要とされるときにのみ、上記無線通信部分の電源供給を開始することにより、電池の消耗を抑制し、通信端末の動作可能時間を長くすることができる。
【００５０】
（ニ）または、省電力制御機能（パワーセーブモード）を有し、電池を電源とする通信端末において、無線通信を使用するアプリケーションの起動又は当該アプリケーションからの送信データの発生を検知して、パワーセーブモードから通常モードに移行し、データ送受信を完了した後、再びパワーセーブモードに復帰する。これによれば、待ち受け状態等のデータのやり取りが少ない場合はパワーセーブモードにして電力消費を抑える一方、データのやり取りが多くなった場合は通常モードに移行してデータ転送時間の短縮化を図ることができる。
【００５１】
第２の実施の形態において、電源制御部１５（図２参照）は、電池１４の端子電圧をモニタし、所定の基準値を下回ったときに中央制御部１１に対して警告信号を出力する。中央制御部１１は、この警告信号に応答して、上記の（１）〜（４）のそれぞれの思想に基づく処理を実行し、電源制御部１５を介してワイヤレス通信ユニット９の電源オンオフを制御する。
【００５２】
図１１は、電源制御部１５における電池１４の端子電圧モニタ特性図である。一般に電池１４の端子電圧は時間の経過に伴って低下する。その低下の傾向（低下の度合い又は線形的低下か非線形的低下かなど）は電池１４の仕組みや構造等に依存して様々であるが、たとえば、図示のとおり、最初は緩やかに低下し、後半は比較的急激に低下する傾向を示すものと仮定すると、かかる低下傾向を示す特性線Ａと所定の基準値との交点（黒丸Ｂ）は、電池１４の使用開始時間からの経過時間ｘ（すなわち、使用可能時間）を表す。電源制御部１５は、この経過時間ｘの時点で中央制御部１１に対して警告信号を出力する。
【００５３】
図１２は、第２の実施の形態における通信端末３７、３８の動作を示すフローチャートである。このフローチャートは、通信端末３７、３８の電源が入れられたときに実行される。このフローチャートでは、まず、電池１４の端子電圧をモニタし（ステップＳ３１）、端子電圧が所定の基準値を下回っているか否かを判定する（ステップＳ３２）。そして、下回っていなければ（図１１の経過時間ｘに達していなければ）、電源制御部１５を介してワイヤレス通信ユニット９に電源を供給し、ワイヤレス通信ユニット９の電源をオンにする（ステップＳ３３）。そして、接続相手との無線接続処理を実行し（ステップＳ３４）、接続相手の有無に応じて省電力モード（パワーセーブモード）にするか否かを判断して（ステップＳ３５）、パワーセーブモードにする場合は当該モードに移行（ステップＳ３６）した後、無線データの送受信を行い（ステップＳ３７）、送受信を完了すると、切断処理を行って（ステップＳ３８）フローチャートを終了する。
【００５４】
一方、上記のステップＳ３２で、端子電圧が所定の基準値を下回っていることを判定した場合、すなわち、図１１の経過時間ｘを過ぎている場合は、ワイヤレス通信ユニット９への電源供給を停止（ステップＳ３９）した後、無線通信を使用するアプリケーションの起動又は当該アプリケーションからの送信データの発生を検知したか否かを判定する（ステップＳ４０）。そして、その判定結果が“ＹＥＳ”であれば、ステップＳ３３を実行してワイヤレス通信ユニット９の電源をオンにし、判定結果が“ＮＯ”であればステップＳ３９（ワイヤレス通信ユニット９の電源をオフ）を繰り返す。
【００５５】
このフローチャートによれば、通信端末３７、３８の電池１４の端子電圧が所定の基準値を下回っている場合にワイヤレス通信ユニット９への電源供給を停止することができ、且つ、無線通信を使用するアプリケーションの起動又は当該アプリケーションからの送信データの発生を検知した場合に、ワイヤレス通信ユニット９への電源供給を再開することができる。したがって、電池１４の残容量が少ない場合に不要な電力消費（ワイヤレス通信ユニット９の消費電力）を抑えることができ、しかも、実際にデータ送信を行う場合には、ワイヤレス通信ユニット９への電源供給を再開して、そのデータ送信を支障なく行うことができる。
【００５６】
図１３は、第２の実施の形態の通信端末３７、３８の表示部（図１の表示部３参照）に表示可能な省電力設定画面及び省電力モード設定画面の一例レイアウト図である。省電力設定画面４０は、任意の文字列（図では“省電力モード設定”）を表示するタイトルバー４１と、その下のクライアントエリア４２とを有し、クライアントエリア４２に、電池残量表示部４３、動作モード表示部４４、ＯＫボタン４５、キャンセルボタン４６及び適用ボタン４７などの各コントロールを配置して構成されている。動作モード表示部４４は、「ノーマル」、「パワーセーブ」及び「ロングライフパワーセーブ」の択一的に選択可能な三つのモード選択表示部４４ａ〜４４ｃを含む。
【００５７】
ノーマルモードは省電力を考慮しない通常の動作モードである。パワーセーブモードは既存の省電力モードである。このモードでは、たとえば、表示部３のバックライトを消したり、ＣＰＵの動作クロックを落としたり、又は、ＩＥＥＥ８０２．１１で規定されたパワーセーブモードを採用したりして、必要最低限の省電力化を達成する。一方、ロングライフパワーセーブモードは、上記のパワーセーブモードに加えて、先に説明した第２の実施の形態の技術を適用するものであり、最大の省電力効果を発揮するというものである。ロングライフパワーセーブモードは、黒色背景の白抜き文字で表示されており、現在の選択モードであることを示している。なお、画面内の“３０％”は電池の残容量を示し、“０：３０”、“０：４５”、“１：００”は、各モードにおける推定残り時間（その電池残容量で使用可能な残り時間）を示している。たとえば、“０：３０”はノーマルモードで後３０分程度使用可能、“０：４５”はパワーセーブモードで後４５分程度使用可能、“１：００”はロングライフパワーセーブモードで後１時間程度使用可能であることを表している。
【００５８】
任意のモードをダブルクリックすることにより、そのモードの設定画面（省電力モード設定画面５０）を開くことができる。省電力モード設定画面５０は、任意の文字列（図では“省電力モード設定”）を表示するタイトルバー５１と、その下のクライアントエリア５２とを有し、クライアントエリア５２に、省電力モードに移行する際の電池残量設定部５３、省電力モード選択部５４、表示部３のバックライト照度レベル選択部５５、ＣＰＵ処理速度選択部４６、ＯＫボタン５７、キャンセルボタン５８及び適用ボタン５９などの各コントロールを配置して構成されている。図示の例では、電池残量設定部５３で“３０％”、省電力モード選択部５４で“ロングライフセーブ”、照度レベル選択部５５で“５”、ＣＰＵ処理速度選択部４６で“中速”が選択されているため、電池１４の残容量が３０％を切ったときに、モニタ照度レベルを５、ＣＰＵ処理速度を中速とする「ロングライフパワーセーブモード」が実行される。
【００５９】
なお、図１２のフローチャートでは、通信端末３７、３８の電源をオンにしたときに電池１４の端子電圧を検知する（ステップＳ３１）ようにしたが、これに限定されない。通信端末３７、３８の電源をオンにしている間、定期的に電池１４の端子電圧を検知するようにし、端子電圧が所定の基準値以下のときで、且つ、ブラウザソフト等の通信アプリケーションが起動されていなければ、ワイヤレス通信ユニット９の電源供給を停止するようにしてもよい。また、上記の「基準値」は、固定値であってもよく、あるいは、ワイヤレス通信ユニット９の使用状況に対応した可変値であってもよい。
【００６０】
＜第３の実施の形態＞
または、図１２のフローチャートを、図１４のように変更してもよい。すなわち、通信端末３７、３８の電源をオンにすると、まず、ワイヤレス通信ユニット９の電源もオンにし（ステップＳ４１）、無線接続相手の検索を開始する（ステップＳ４２）。そして、設定時間内に接続相手が見つかった場合（ステップＳ４２の“ＹＥＳ”）は、接続相手との接続処理により無線接続状態に移行して、データの送受信及び送受信後の切断処理を実行（ステップＳ４４〜ステップＳ４６）するが、接続相手が見つからなかった場合（ステップＳ４２の“ＮＯ”）は、電池１４の端子電圧をモニタし（ステップＳ４７）、端子電圧が所定の基準値を下回っているか否かを判定する（ステップＳ４８）。そして、下回っていなければ（図１１の経過時間ｘに達していなければ）、ステップＳ４３に復帰して接続相手の検索を行い、一方、端子電圧が所定の基準値を下回っていることを判定した場合、すなわち、図１１の経過時間ｘを過ぎている場合は、ワイヤレス通信ユニット９への電源供給を停止（ステップＳ４９）した後、無線通信を使用するアプリケーションの起動又は当該アプリケーションからの送信データの発生を検知したか否かを判定する（ステップＳ５０）。そして、その判定結果が“ＹＥＳ”であれば、ステップＳ４２に復帰して接続相手の検索を行い、判定結果が“ＮＯ”であればステップＳ４９（ワイヤレス通信ユニット９の電源をオフ）を繰り返す。
【００６１】
このフローチャートによれば、電池１４の端子電圧が基準値を下回らなければ、ワイヤレス通信ユニット９の電源をオンにしたまま無線接続信相手の検索を定期的に繰り返し、下回っていれば、ワイヤレス通信ユニット９の電源をオフにして、そのオフ状態を無線通信を使用するアプリケーションの起動又は当該アプリケーションからの送信データの発生を検知するまでの間継続するので、実際にデータの送受信を行っていないときの不要電力（ワイヤレス通信ユニット９の消費電力）を抑制することができ、しかも、データの送受信を行う際にはワイヤレス通信ユニット９の電源をオンにして、当該データの送受信を支障なく行うことができる。
【００６２】
このように、第３の実施の形態では、接続相手が一定時間の検索で見つからなかった場合で、且つ、電池１４の残容量が基準値以下の場合に、ワイヤレス通信ユニット９の電源をオフにして電池１４の消耗を抑えることができ、そして、通信処理を必要とした場合に、再びワイヤレス通信ユニット９の電源をオンにして支障なくデータの送受信を行うことができる。なお、第３の実施の形態では、一定の検索時間内に接続相手が見つからなかった場合に電池１４の残容量に応じてワイヤレス通信ユニット９の電源制御を行っているが、これに限らず、たとえば、接続相手が見つかった場合であっても、すぐにデータの送受信を行わない場合（必要でない場合）は、直ちに接続処理に入らず、電池１４の残容量に応じてワイヤレス通信ユニット９の電源制御を行うようにしてもよい。
【００６３】
または、図１４のフローチャートを、図１５のように変更してもよい。すなわち、通信端末３７、３８の電源をオンにすると、まず、ワイヤレス通信ユニット９の電源もオンにして（ステップＳ６０）、接続処理を実行する（ステップＳ６１）。次に、タイマを起動し（ステップＳ６２）、そのタイマ値が所定値になるまでの間に接続相手との間で実際にデータの送受信が行われるか否かを判定する（ステップＳ６３）。
【００６４】
ここで、“実際のデータ送受信”とは、ビーコンフレームのような制御データのやり取りを含まない、ブラウザソフトなどの通信アプリケーションによってやり取りされる情報データのみを意味する。このような情報データの送受信が設定時間内に行われなかった場合、無線切断処理を実行し（ステップＳ７０）、さらに、ワイヤレス通信ユニット９の電源供給を停止（ステップＳ７１）した後、無線通信を使用するアプリケーションの起動又は当該アプリケーションからの送信データの発生を検知したか否かを判定する（ステップＳ６９）。そして、その判定結果が“ＹＥＳ”であれば、ステップＳ６０に復帰してワイヤレス通信ユニット９の電源供給を再開し、判定結果が“ＮＯ”であればステップＳ７１（ワイヤレス通信ユニット９の電源をオフ）を繰り返す。
【００６５】
設定時間内に情報データの送受信が行われた場合（ステップＳ６３の“ＹＥＳ”）は、一連のデータ送受信（ステップＳ６４）が完了した時点でタイマを起動し（ステップＳ６５）、そのタイマ値が所定値になるまでの間に接続相手との間で再び実際にデータの送受信が行われるか否かを判定し（ステップＳ６６）、行われた場合は、ステップＳ６４以降の処理を繰り返し、設定時間内に情報データの送受信が行われなかった場合（ステップＳ６６の“ＮＯ”）は、無線切断処理（ステップＳ６７）を実行し、ワイヤレス通信ユニット９の電源供給を停止した後、ステップＳ６９を実行する。
【００６６】
このフローチャートによれば、無線通信接続相手との一連のデータ送受信完了時点でタイマを起動し、そのタイマ値が所定値に達するまでの間に、その接続相手との間で実際のデータ送受信が行われなかった場合は、ワイヤレス通信ユニット９の電源供給を停止するので、無用な電力消費を抑え、電池１４の消耗を抑制することができる。
【００６７】
なお、以上のフローチャートでは、ステップＳ６３やステップＳ６６における設定時間（タイマの判定値）を一定値としたが、これに限らず、たとえば、通信アプリケーション毎に定められた適切な値を選択的に使用するようにしてもよい。また、設定時間は、実際に行われた過去のデータ送受信の傾向（特に時間間隔）に基づいて可変的に設定されるものであってもよい。
【００６８】
または、図１５のフローチャートを、図１６のように変更してもよい。すなわち、通信端末３７、３８の電源オン直後は、パワーセーブモードを選択した状態でワイヤレス通信ユニット９を初期化する。初期化完了後、設定された接続先との間の無線接続処理を実行する。接続を完了した後は、定期的にビーコンパケットを受信する時を除き、電力をセーブするパワーセーブモードで同期維持する。このとき、単に情報データを受け取るだけである場合は、図１０の「フレーム蓄積あり」の情報を持ったビーコンパケットを受信したときに、受信可能なウィンドウを広げて受信すればよいが、しかし、ビーコンパケットの受信間隔がパワーセーブモードなしの時に比べて長く、送信、受信のプロセスが交互に続く場合は、パワーセーブモードなしのときに比べてデータ送受信にかかる時間が長くなってしまう。
【００６９】
そこで、使用者がデータ送信を行うときのように、通信アプリケーションからのアクションがあったときに、パワーセーブモードを一時的に解除する。パワーセーブモードを解除することにより、高速に情報データ送受信を行うことが可能になる。データ送受信が完了した後、タイマを起動して、一定時間内に再びデータ送受信が行われる場合には通常モードを維持する。一定時間通常モードを維持するのは、省電力モードの移行処理に費やされるタイムロスを減らすためである。一方、一定時間内に再びデータ送受信がなければ、パワーセーブモードに移行し、当該モードでの同期維持を続ける。そして、再び情報データを送信するときは、パワーセーブモードをオフにし、通常モードに移行して情報データの送信を行う。
【００７０】
このフローチャートによれば、無線アプリケーションにおいて、使用者によるデータ送信動作がないときは、通信データ量が少ないことから、パワーセーブモードでも通常モードと比べて使用者に対する影響（モードによる差）は少ない。しかし、使用者がデータを送信するときは送受するデータ量が増えるため、パワーセーブモードをオフにした通常モードにすることで、短時間にデータ送受を完了することができる。そして、再びパワーセーブモードにする、という制御を行うことにより、パワーセーブモードと通常モードの切替を簡単に且つ効率よく行うことができる。
【００７１】
なお、このフローチャートでは、パワーセーブモードから通常モードへの切り替えを、単純に使用者によるデータ送受信動作としたが、これに限らず、たとえば、無線パケットの情報データを読み取ってモード切替の判断を行ってもよい。又は、プロトコルによっては、多くのセッションが必要となることを利用し、セッション数に基づいてパワーセーブモードから通常モードへの切り替えを行ってもよい。
【００７２】
＜第４の実施の形態＞
上記の第１の実施の形態では、最後の送信要求の時点から所定の“タイムアウト時間”を経過すると、ワイヤレス通信ユニット９への電源供給を停止して省電力化を図っている。
詳しくは、「デバイスドライバ部３１がアプリケーション部２８からのアップロードデータを受け取ると、デバイスドライバ部３１がデータ送信関数をコールし、その関数にアップロードデータを渡すことによってデータを送信する」点に着目し、データ送信関数がコールされるたびにそのときの日時を送信時間ファイル３２に上書き記録すると共に、送信時間ファイル３２に記録された日時情報を、バックグランドで実行される常駐型のソフトである電力制御ソフト３３によって定期的に参照し、送信時間ファイル３２に記録された日時情報と現在の日時との差、すなわち、最後にアップロードが行われたときからの経過時間を計算し、その経過時間が所定のしきい値以上であれば、電源制御部１５に対して、ワイヤレス通信ユニット９への電源供給を停止させるようにして、通信端末１の電池１４の延命化を図るようにしている。
【００７３】
しかしながら、送受信相手はネットワーク上のウェブサーバやメールサーバなど多種多様であり、各サーバの負荷やネットワークトラフィック（輻輳）も一定ではないから、上記のタイムアウト時間はワーストケース（最も応答の遅いサーバ）を考慮して最大値に設定せざるを得ない。一方、そのようにすると、今度は、サーバの負荷が軽い場合やネットワークトラフィックが少ない場合に過剰なタイムアウト時間となってしまう。この過剰なタイムアウト時間を便宜的にＴａとし、実際のデータ交信時間をＴｂとすると、Ｔａ＞＞Ｔｂとなり、ＴａとＴｂの差に相当する時間だけワイヤレス通信ユニット９が無駄に動作することになるから、省電力効果を高めることができないという不都合がある。また、この不都合に対処するために、上記のタイムアウト時間（Ｔａ）を短目に設定（たとえば、Ｔａ＝Ｔｂ）すると、今度は応答の遅いサーバとの間でデータ交信を行うことができなくなるという不都合を招く。
【００７４】
このような不都合を一挙に解決する方法としては、たとえば、通信アプリケーションでデータ交信の終了報告イベントを発生できるようにしておき、このイベントに応答してワイヤレス通信ユニット９への電源供給を停止することも考えられるが、通信アプリケーションは多種多様であるから、その全ての通信アプリケーションに上記イベントの実装を強制しまたは推奨することは困難であり、現実的でない。
【００７５】
たとえば、パッケージソフトとして流通している通信アプリケーションはＯＳ製造元の認定を受けられるシステムになっているので、同認定基準に上記のイベント仕様を加えておけば一応の対策は可能である。しかし、認定を受けない通信アプリケーションも数多く存在するし、趣味で製作された通信アプリケーション（シェアウェアソフトやフリーソフトなど）も存在するから、これらの通信アプリケーションの全てに上記のイベント仕様を強制しまたは推奨することは実際上不可能といえるからである。
【００７６】
そこで、この第４の実施の形態においては、通信アプリケーションよりも下位レベルで通信を監視することによって、アプリケーションの種類に関わらず、そのアプリケーションの実際の通信終了を検出して、ワイヤレス通信ユニット９への電源供給を停止できるようにする。そして、これにより、最後の送信要求の時点からワイヤレス通信ユニット９への電源供給を停止する時点までの期間を最適化できるようにし、ワイヤレス通信ユニット９の無駄な動作時間を無くして、より一層の省電力効果を高めることを目的とする。
【００７７】
図１７は、第４の実施の形態における通信端末１の要部ブロック図である。波線２７ａで囲まれた部分は、主としてＯＳやそのＯＳ上で動作するアプリケーションプログラムによって実現される機能部を示している。これらの機能部は、前記の第１の実施の形態（図４参照）と同様の構成要素、すなわち、アプリケーション部２８、トランスポート部２９、ネットワーク部３０、デバイスドライバ部３１、送信時間ファイル３２、電力制御ソフト３３、カードソケット管理モジュール３４を含むと共に、さらにパケットモニタ部６０とタイマー管理ソフト６１を含む。これらは、前記モデル２０（図３参照）のアプリケーション層２６、トランスポート層２５、インターネット層２４、ネットワークインターフェース層２３及びドライバ層２２に実装されたものである。
【００７８】
この図において、アプリケーション部２８は、たとえば、電子メールソフトやブラウザソフトであり、アプリケーション部２８は、データのアップロードを行う際、トランスポート部２９及びネットワーク部３０を介してデバイスドライバ部３１に実装されている所定のデバイスドライバ（ワイヤレス通信ユニット９のデバイスドライバ）にアクセスし、当該デバイスドライバ経由でワイヤレス通信ユニット９を使用してデータの送信を行う。
【００７９】
デバイスドライバ部３１は、アプリケーション部２８からのアップロードデータ（送信データ）を受け取ると、データ送信を扱う所定の関数（以下「データ送信関数」という）をコールし、その関数にアップロードデータを渡してワイヤレス通信ユニット９から送信する。
【００８０】
このように、デバイスドライバ部３１では、アップロードデータが発生したときに必ずデータ送信関数をコールするので、第４の実施の形態では、まず、データ送信関数がコールされるたびにそのときの日時（時計部１０（図２参照）から取得した日時情報）を送信時間ファイル３２に上書き記録する。これにより、送信時間ファイル３２に、最後にアップロードが行われたときの日時を記録することができる。
【００８１】
パケットモニタ部６０は、ネットワーク部３０の送受信データ（パケット）を監視し、パケットのやり取りがある度にタイマー管理ソフト６１に対してイベントを通知する。このパケットモニタ部６０は、たとえば、キャプチャリングライブラリ（ｌｉｂｐｃａｐ）などを用いて容易に構成することができる。
【００８２】
タイマー管理ソフト６１は、パケットモニタ部６０からのイベントに応答してそのパケットを解析（使用ポートの特定、送受信パケットの区別及びパケットデータの分類など）し、その解析結果に従ってタイマーの初期値を可変的に設定すると共に、そのタイマーがタイムアウトしたときに電源制御部１５に対して、ワイヤレス通信ユニット９をサスペンド（Ｓｕｓｐｅｎｄ）状態とするための制御信号を出力するとともに、サスペンド状態を示すイベント（サスペンドイベント）を発生して、電力制御ソフト３３及びカードソケット管理モジュール３４経由でデバイスドライバ部３１に通知する。
【００８３】
一方、送信時間ファイル３２に記録された日時情報は、バックグランドで実行される常駐型のソフトである電力制御ソフト３３によって定期的に参照される。電力制御ソフト３３は、ワイヤレス通信ユニット９がサスペンド状態にあるとき、送信時間ファイル３２に記録された前回の日時情報と今回の日時情報とが一致していなければ、新たなアップロードデータが発生したと判断して、ワイヤレス通信ユニット９への電源供給を再開させ、ワイヤレス通信ユニット９をサスペンド状態から動作状態に復帰させるための制御信号を出力すると共に、通常動作への復帰イベントを発生して、カードソケット管理モジュール３４経由でデバイスドライバ部３１に通知する。
【００８４】
図１８は、タイマー管理ソフト６１と電力制御ソフト３３の動作を示すフローチャートである。このフローチャートでは、まず、通信デバイスが一時停止状態（ワイヤレス通信ユニット９がサスペンド状態）であるか否かを判定する（ステップＳ２１）。そして、一時停止状態であれば、次に、送信時間ファイル３２を読み込み（ステップＳ２２）、送信時間ファイル３２に記録されている前回値と今回値が一致しているか否かを判定し（ステップＳ２３）、前回値と今回値が一致している場合は新たなアップロードデータが発生していないと判断して、ある時間待機（Ｓｌｅｅｐ）してから（ステップＳ２５）、再び以上のフローを繰り返すが、一致していない場合は新たなアップロードデータが発生していると判断して、通信デバイス（ワイヤレス通信ユニット９）に電源を供給して通常動作に復帰させた後（ステップＳ２４）、ある時間待機（Ｓｌｅｅｐ）してから（ステップＳ２５）、再び以上のフローを繰り返す。
【００８５】
一方、ステップＳ２１で通信デバイスの一時停止状態を判定しなかった場合は、次に、タイマー管理ソフト６１で全てのタイマー値（後述）をチェックする（ステップＳ２６）。そして、タイマー値のいずれか一つでもタイムアウトになっていなければ（ステップＳ２７）、ある時間待機（Ｓｌｅｅｐ）してから（ステップＳ２５）、再び以上のフローを繰り返すが、全てのタイマー値がタイムアウトになっていれば（ステップＳ２７）、通信デバイス（ワイヤレス通信ユニット９）を一時停止（サスペンド）状態にした後（ステップＳ２８）、ある時間待機（Ｓｌｅｅｐ）してから（ステップＳ２５）、再び以上のフローを繰り返す。
【００８６】
ここで、ステップＳ２６におけるタイマー値は、次のフローによって適宜にその初期値が設定される。
図１９（ａ）は、パケットモニタ部６０及びタイマー管理ソフト６１の動作を示すフローチャートである。このフローチャートにおいて、パケットモニタ部６０はネットワーク部３０のデータパケットをモニタしてそれが送信パケットであるか受信パケットであるかを判定する（ステップＳ３０）。送・受信パケットの判断は、たとえば、パケットヘッダから発信元ＩＰアドレスを取り出し、その発信元ＩＰアドレスと自ＩＰアドレス（携帯端末１のＩＰアドレス）とを比較することによって行うことができる。両ＩＰアドレスが一致していれば、そのパケットは自機（携帯端末１）からの送信パケットであり、一致していなければ、他機（携帯端末１以外のたとえばサーバ等）からの受信パケットである。
【００８７】
送信パケットであると判断した場合は「送信データ処理」（ステップＳ３１）を実行し、受信パケットであると判断した場合は「受信データ処理」（ステップＳ３２）を実行する。
【００８８】
図１９（ｂ）は、送信データ処理のフローチャートである。このフローチャートでは、まず、パケットの使用ポート番号が「２５番」であるか又は「１１０番」であるかを判定する（ステップＳ３３）。先に説明したとおり、２５番はメール送信用のポートであり、１１０番はメール受信用のポートである。したがって、このステップＳ３３ではメールデータの送受信であるか否かを判定していることになる。ステップＳ３３の判定結果が“ＮＯ”のとき、つまり、メールデータ以外の送受信である場合は、「応答待ち用タイマー値」を発信元ポート番号の付いたタイマーにセットして同タイマーを起動する（ステップＳ３４）。応答待ち用タイマー値とは、相手側の忙しさ（サーバ等の処理負荷）やネットワークの混雑によって応答が遅れる場合でもその応答を支障無く受け取ることができる充分に長い時間のことをいう。
【００８９】
一方、ステップＳ３３の判定結果が“ＹＥＳ”のとき、つまり、メールデータの送受信である場合は、次に、メールクライアント側（送信側）が通信終了コマンド（“ＱＵＩＴ”）を発行したか否かを判定する（ステップＳ３５）。ＱＵＩＴが発行されていない場合は、まだ、メールデータの送信が継続中であると判断して、応答待ち用タイマー値を発信元ポート番号の付いたタイマーにセットして同タイマーを起動し（ステップＳ３４）、ＱＵＩＴが発行された場合は、メールデータの送信が完了したと判断して、「終了用タイマー値」を発信元ポート番号の付いたタイマーにセットして同タイマーを起動する（ステップＳ３６）。終了用タイマー値とは、上記の応答待ち用タイマー値よりも短い時間（数秒程度）であり、詳しくは、通信用のソフトウェアが連続的に送信要求を自動発行していたときなどにおいて、通信デバイスの一時停止／復旧が速度低下の原因とならないように通信終了後に所定時間待機してから通信デバイスの一時停止を行うためのものである。
【００９０】
この送信データ処理のフローチャートによれば、メールの送信を行っている間（ＱＵＩＴを検出していないとき）は、比較的長めのタイマー値（応答待ち用タイマー値）をセットする一方、メールの送信を完了したとき（ＱＵＩＴを検出したとき）は、比較的短めのタイマー値（終了用タイマー値）をセットすることができ、実際のメールデータの送信状態に対応してタイマー値を長短いずれかに切り換えることができる。したがって、少なくとも、メールの送信を完了したときには、短いタイマー値（終了タイマー値）を選択して、その終了タイマー値の時間（数秒程度）を経過した時点で、通信デバイス（ワイヤレス通信ユニット９）の電源供給を速やかに停止することができるから、通信デバイスの無駄な動作を無くして、より一層の省電力化を図ることができる。
【００９１】
図２０は、受信データ処理のフローチャートである。このフローチャートでは、まず、パケットの使用ポート番号が「２５番」であるか又は「１１０番」であるかを判定する（ステップＳ３７）。２５番はメール送信用のポートであり、１１０番はメール受信用のポートである。したがって、このステップＳ３７ではメールデータの送受信であるか否かを判定していることになる。ステップＳ３７の判定結果が“ＹＥＳ”のとき、つまり、メールデータの送受信である場合は、「継続用タイマー値」を発信元ポート番号の付いたタイマーにセットして同タイマーを起動する（ステップＳ３８）。継続用タイマー値とは、相手側の忙しさ（サーバ等の処理負荷）やネットワークの混雑によって応答が遅れる場合でもその応答を支障無く受け取ることができる充分に長い時間のことをいう。
【００９２】
一方、ステップＳ３７の判定結果が“ＮＯ”のとき、つまり、メールデータ以外の送受信である場合は、次に、パケットの使用ポート番号が「８０番」（ＨＴＴＰポート）であるか否かを判定する（ステップＳ３９）。ＨＴＴＰポートでなければ、「継続用タイマー値」を発信元ポート番号の付いたタイマーにセットして同タイマーを起動し（ステップＳ３８）、ＨＴＴＰポートであれば、ドキュメントのＣｏｎｔｅｎｔ−Ｔｙｐｅを調べて“ｈｔｍｌ／ｔｅｘｔ”であるか否かを判定する（ステップＳ４０）。
【００９３】
そして、“ｈｔｍｌ／ｔｅｘｔ”のドキュメントであれば、以降のパケットを逐次にモニタして、“ｈｔｍｌ／ｔｅｘｔ”に分類された受信側ポート番号を持つパケットにＨＴＭＬドキュメントの「終了タグ」（“＜／ＨＴＭＬ＞”）を発見するまでの間（ステップＳ４１、ステップＳ４２）、「継続用タイマー値」を発信元ポート番号の付いたタイマーにセットして同タイマーを起動するが（ステップＳ３８）、終了タグを発見した場合、つまり、ドキュメントの受信を完了した場合は、上記の継続用タイマー値よりも短い「終了用タイマー値」を発信元ポート番号の付いたタイマーにセットして同タイマーを起動する（ステップＳ４３）。
【００９４】
一方、“ｈｔｍｌ／ｔｅｘｔ”のドキュメントでない場合は、次に、イメージアプリケーション（画像データ）であるか否かを判定する（ステップＳ４４）。イメージアプリケーションでもない場合は、「継続用タイマー値」を発信元ポート番号の付いたタイマーにセットして同タイマーを起動する（ステップＳ３８）が、イメージアプリケーションである場合は、次に、画像データのサイズ情報（“ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ”）の有無を検索する（ステップＳ４５）。
【００９５】
そして、サイズ情報が見つからなければ、「継続用タイマー値」を発信元ポート番号の付いたタイマーにセットして同タイマーを起動し（ステップＳ３８）、サイズ情報が見つかった場合は、そのサイズ情報を保持すると共に、以降の同ポート番号のパケットが到着するたびにパケットサイズからペイロードサイズを計算し、その計算結果を保持しておいたサイズ情報から減算して残りｌｅｎｇｔｈを求め（ステップＳ４６）、その残りｌｅｎｇｔｈがゼロとなったとき（ステップＳ４７）、つまり、画像データの全てを受信したときに、上記の継続用タイマー値よりも短い「終了用タイマー値」を発信元ポート番号の付いたタイマーにセットして同タイマーを起動する（ステップＳ４３）。
【００９６】
この受信データ処理のフローチャートによれば、ドキュメントの終了タグ（“＜／ＨＴＭＬ＞”）を検出すると、直ちに継続用タイマー値よりも短い終了用タイマー値をセットすることができる。また、サイズ情報（“ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ”）を含む画像データを受け取るとき、その残りｌｅｎｇｔｈがゼロになったときも、直ちに継続用タイマー値よりも短い終了用タイマー値をセットすることができる。したがって、ドキュメントや画像データの受信を完了した時点で、通信デバイス（ワイヤレス通信ユニット９）の電源供給を速やかに停止することができ、通信デバイスの無駄な動作を無くして、より一層の省電力化を図ることができる。
【００９７】
なお、以上の説明では、特定のポート（ＳＭＴＰポートやＰＯＰポート及びＨＴＴＰポート）を例にしたが、これに限定されない。どのポートを使用するかは、もっぱらアプリケーションの種類や用途に依存する。また、送信データの完了判定を“ＱＵＩＴ”コマンドの有無で行ったり（図１９（ｂ）のステップＳ３５）、あるいは、受信データの完了判定を終了タグ（“＜／ＨＴＭＬ＞”）の有無で行ったり（図２０のステップＳ４１）しているが、これらも一例を示しているに過ぎない。これ以外のコマンドやタグの使用を排除するものではない。要は、送受信データの終了を示す特定のコマンド（又はタグ、記号あるいはそれらに相当する文字列ないしコード）であればよい。
【００９８】
＜第５の実施の形態＞
前記の各実施の形態におけるワイヤレス通信ユニット９は、動作状態（電源供給状態）と休止状態（電源非供給状態）の二つの状態をとり得る通信デバイスである。データの送受信が行われていないときに休止状態とすることにより、無駄な電力消費を抑えることができる。
【００９９】
ところで、このような通信デバイスにおいては、休止状態から動作状態へと遷移する前にデータの送受信が開始されてしまった場合、一部のデータが失われてしまう（パケットロスを生じる）ことがある。たとえば、Ｐ０、Ｐ１、Ｐ２、Ｐ３、・・・・のパケットを送信又は受信（以下、送信とする）する際に、仮に、通信デバイスが動作状態へと遷移する前にいくつかのパケット（便宜的にＰ０とＰ１とする）の送信が開始されてしまった場合、これらのパケット（Ｐ０とＰ１）は破棄されてしまいデータの抜けが生じる。実際にはデータの抜けが生じてもエラー訂正（再送要求）で処理されるため、データ伝送の不都合はないものの、再生パケットの分だけ通信速度の低下を来すという問題点を招く。
【０１００】
このような問題に対処するためには、たとえば、通信デバイスのデバイスドライバに「状態遷移」の通知機能を搭載しておき、実際のデータ送受信の開始をデバイスドライバからの状態遷移通知に応答させて行うようにしておけばよい。このようにすれば、通信デバイスが動作状態へと遷移する前にいくつかのパケットの送信が開始されてしまうという不都合を回避してデータの抜けを防止し、且つ、データ再送要求に伴う通信速度の低下問題も解決できる。
【０１０１】
しかしながら、このような対策は、通信デバイスのデバイスドライバに強く依存するものであり、とりわけ無線カードやＬＡＮカードのように交換可能な通信デバイスは、カード交換に伴ってデバイスドライバも入れ替えられるので、場合によっては、上記の通知機能を搭載しない別のデバイスドライバがインストールされる可能性を否定できず、この場合は、やはり、上記の問題点（データの抜け及びデータ再送に伴う通信速度の低下）を引き起こす。
【０１０２】
そこで、この第５の実施の形態では、通信デバイスを休止状態にする際に、ＡＲＰテーブルをクリアするという簡単な操作を行うことにより、デバイスドライバに依存することなく、次回の通信再開時におけるコマンド抜けを防止する。
【０１０３】
ここに、ＡＲＰとは、Address Resolution Protocol（アドレス解決プロトコル）の略である。アドレス解決プロトコルは、ＴＣＰ／ＩＰネットワークにおいて、論理アドレス（ＩＰアドレス）からイーサネット（登録商標）の物理アドレス（ＭＡＣアドレス）を求めるために使われる。
【０１０４】
図２１は、第５の実施の形態の動作を示すフローチャートである。このフローチャートでは、まず、送信時間ファイル３２（図４参照）を読み込み（ステップＳ５１）、次いで、通信デバイスが一時停止状態（ワイヤレス通信ユニット９がサスペンド状態）であるか否かを判定する（ステップＳ５２）。そして、一時停止状態であれば、次に、送信時間ファイル３２に記録されている前回値と今回値が一致しているか否かを判定し（ステップＳ５３）、前回値と今回値が一致している場合は新たなアップロードデータが発生していないと判断して、ある時間待機（Ｓｌｅｅｐ）してから（ステップＳ５４）、再び以上のフローを繰り返すが、一致していない場合は新たなアップロードデータが発生していると判断して、通信デバイス（ワイヤレス通信ユニット９）に電源を供給して通常動作に復帰させた後（ステップＳ５５）、ある時間待機（Ｓｌｅｅｐ）してから（ステップＳ５４）、再び以上のフローを繰り返す。
【０１０５】
一方、ステップＳ５２で通信デバイスの一時停止状態を判定しなかった場合は、次に、現在の日時と送信時間ファイル３２に記録されている日時の差Ｘを演算する（ステップＳ５６）。差Ｘは、最後にアップロードが行われたときからの経過時間を表す。次に、差Ｘと所定のしきい値とを比較し（ステップＳ５７）、しきい値を超えていなければ、ある時間待機（Ｓｌｅｅｐ）してから（ステップＳ５９）、再び以上のフローを繰り返すが、しきい値を越えていれば、ワイヤレス通信ユニット９をサスペンド（Ｓｕｓｐｅｎｄ）状態とするための制御信号を出力し（ステップＳ５８）、さらに、ＡＲＰテーブルをクリア（ステップＳ５９）した後、ある時間待機（Ｓｌｅｅｐ）してから（ステップＳ５９）、再び以上のフローを繰り返す。
【０１０６】
このフローチャートによれば、通信デバイスを休止状態にする際に同時にＡＲＰテーブルをクリアするようにしている。ＡＲＰテーブルは、既述のとおり、ＩＰアドレスとＭＡＣアドレスの対応表であり、この対応表がクリアされている場合、通信アプリケーションはデータの行き先（ＭＡＣアドレス）が分からないため、その間（ＡＲＰテーブルが再構成されるまでの間）、通信要求を発行しない（通信要求を待機する）仕組みになっている。
【０１０７】
すなわち、ＡＲＰテーブルをクリアしておけば、その後の通信デバイス復帰（動作状態への遷移）の際にＡＲＰテーブルが再構成されるまでの間、通信アプリケーションからの通信要求が待機させられたままとなるため、通信デバイスが休止状態から動作状態へと遷移する前にデータの送受信が開始されてしまうという不都合が無い。しかも、かかる作用にデバイスドライバは一切関与しない。
【０１０８】
したがって、この第５の実施の形態においては、デバイスドライバに全く依存することなく、通信デバイスを休止状態から動作状態へと復帰させる際のデータの抜けを防止することができる。
【０１０９】
【発明の効果】
本発明に係る通信端末の電力制御装置によれば、通信を行うための内蔵又は外付けの通信デバイスに対し、電源を供給する電源供給手段と、前記通信デバイスを動作させることによる送信データの有無を検知する検知手段と、前記検知手段によって送信データ無しの状態が一定時間続いたことが検出された場合、前記電源供給手段に対して前記通信デバイスへの電源供給を停止させる供給停止手段と、この第１の制御手段による電源供給の停止中に前記検知手段によって送信データ有りの状態が検出された場合、前記電源供給手段に対して前記通信デバイスへの供給再開手段とを備えることを特徴とするので、送信データなしの状態が一定時間続いた場合に通信デバイスが休止状態とされる一方、休止状態中に送信データありの状態が検出された場合に、通信デバイスが活動状態とされる。したがって、通信が行われない期間（送信データなしの状態が一定時間続く期間）においては、通信端末の通信機能部分の消費電力が抑えられるから、通信端末それ自体のより一層の電力消費抑制を図ることができ、電池の消耗を回避することができる。
また、本発明の好ましい態様によれば、前記通信端末は、少なくとも前記送信データに関わるアプリケーションプログラムと、このアプリケーションプログラムに関連して前記通信デバイスを動作制御するデバイスドライバとをさらに備え、前記検知手段は、送信データの有無の検知として、前記アプリケーションプログラムの実行内容に基づく前記デバイスドライバへコールの有無を検知することを特徴とするので、アプリケーションプログラムの実行内容に基づく前記デバイスドライバへコールの有無を検知することによって、通信デバイスに対する送信データの有無を検知することができ、送信データの有無を検知するための改良をアプリケーションプログラムに施す必要がなく、通信のための様々なアプリケーションプログラムをそのまま利用することができ、普遍性を損なうことがない。
また、本発明の好ましい他の態様によれば、前記電源供給手段は電池を電源として供給し、この電池の残容量を検出する残容量検出手段と、この残容量検出手段の検出値に基づいて、前記通信デバイスへの電力供給を制御する第１の供給制御手段とをさらに備えることを特徴とするので、通信デバイスの電力消費を適正化することができる。
また、この発明の好ましい態様によれば、過去に行われたデータの送受信の時間的な統計を計算する計算手段と、この計算手段による時間的な統計より次回の情報データの送受信までの時間を推定する推定手段とをさらに備え、前記残容量検出手段は、前記推定手段による推定の結果、前記次回の情報データの送受信までの時間が予め設定した時間よりも長くなることが予測された場合に、前記通信デバイスへの電力供給を制御することを特徴とするので、特定の条件においてのみ、通信デバイスへの電力供給をオンオフ制御して通信デバイスの電力消費をより一層適正化することができる。
また、この発明の他の好ましい態様によれば、前記通信デバイスを介して通信相手を検索する検索手段と、この検索手段によって通信相手が見つからなかったとき、前記通信デバイスへの電力供給を停止させるよう制御する第２の供給制御手段とをさらに備えたことを特徴とするので、通信相手がいない場合の無駄な電力消費を抑制できる。
また、この発明の他の好ましい態様によれば、前記通信デバイスに対する送信データの内容を解析するコマンド解析手段と、この解析手段により前記送信データにデータの終了を示すコマンド、タグ、記号又はコードが含まれているか否かを判定する判定手段とをさらに備え、前記検知手段はこの判定手段による判定結果に基づいて、送信データの有無の検知することを特徴とするので、実際の通信データに基づいて、送信データの有無を判定し、より一層正確な電力供給制御を行うことができる。
また、この発明の他の好ましい態様によれば、省電力モードと通常モードとを有し、且つ、電池を電源として動作する通信端末において、省電力モードで無線接続状態にある通信端末がデータ送信を行う際に、省電力モードをオフにした通常モードに移行してデータ送受信を高速に行うことを特徴とするので、通信端末がデータ送信を行う際は、省電力モードから通常モードに切り換えて通信を行うことができ、通信の高速化を図ることができる。
また、この発明の好ましい態様によれば、送受信するデータのサイズが設定された基準値よりも大きい場合に、省電力モードをオフにした通常モードに移行してデータ送受信を高速に行うことを特徴とするので、送受信するデータのが大きい場合は速度優先、サイズが小さい場合は省電力優先とすることができる。
また、本発明に係る通信端末の電力制御装置によれば、動作状態と休止状態の二つの状態をとり得る通信デバイスと、データ通信の相手先を特定するために用いられる論理アドレスと物理アドレスとの対応テーブルを管理する管理手段と、前記通信デバイスが動作状態から休止状態に遷移する際に前記対応テーブルをクリアするクリア手段とを備えたことを特徴とするので、通信アプリケーションは、対応テーブルが再構成されるまでの間、通信要求を発行しない（通信要求を待機する）。このため、通信デバイスが休止状態から動作状態へと遷移する前にデータの送受信が開始されてしまうという不都合が無い。しかも、かかる作用にデバイスドライバは一切関与しない。したがって、これによれば、デバイスドライバに全く依存することなく、通信デバイスを休止状態から動作状態へと復帰させる際のデータの抜けを防止することができる。
【図面の簡単な説明】
【図１】第１の実施の形態における通信端末の一例外観図である。
【図２】通信端末１の概念的な内部ブロック図である。
【図３】中央制御部１１を含む各部のハードウェアリソースとの有機的結合によって実現される様々な機能の一例を示す模式図である。
【図４】第１の実施の形態における通信端末１の要部ブロック図である。
【図５】電力制御ソフト３３の動作を示すフローチャートである。
【図６】デバイスドライバ部３１における動作（データ送信関数がコールされたときの動作）を表すフローチャートである。
【図７】従来例と第１の実施の形態とを対比するタイミングチャートである。
【図８】第２の実施の形態におけるアクセスポイント３５と、そのアクセスポイント３５のサービスエリア３６内に位置する二つの通信端末３７、３８を示す図である。
【図９】パワーセーブモードにおける状態遷移図である。
【図１０】パワーセーブモードで使用されるビーコンパケットのタイミングチャートである。
【図１１】電源制御部１５における電池１４の端子電圧モニタ特性図である。
【図１２】第２の実施の形態における通信端末３７、３８の動作を示すフローチャートである。
【図１３】第２の実施の形態の通信端末３７、３８の表示部（図１の表示部３参照）に表示可能な省電力設定画面及び省電力モード設定画面の一例レイアウト図である。
【図１４】第３の実施の形態における通信端末３７、３８の動作を示すフローチャートである。
【図１５】第３の実施の形態における通信端末３７、３８の動作を示す他のフローチャートである。
【図１６】第３の実施の形態における通信端末３７、３８の動作を示すさらに他のフローチャートである。
【図１７】第４の実施の形態における通信端末１の要部ブロック図である。
【図１８】第４の実施の形態におけるタイマー管理ソフト６１と電力制御ソフト３３の動作を示すフローチャートである。
【図１９】第４の実施の形態におけるパケットモニタ部６０及びタイマー管理ソフト６１の動作を示すフローチャート及び送信データ処理のフローチャートである。
【図２０】第４の実施の形態における受信データ処理のフローチャートである。
【図２１】第５の実施の形態の動作を示すフローチャートである。
【符号の説明】
１  通信端末
９  ワイヤレス通信ユニット（通信デバイス）
１１  中央制御部（検知手段、供給停止手段、供給再開手段）
１４  電池（電源供給手段）
１５  電源制御部（電源供給手段）
【図１】
2004164566.tif 000003
【図２】
2004164566.tif 000004
【図３】
2004164566.tif 000005
【図４】
2004164566.tif 000006
【図５】
2004164566.tif 000007
【図６】
2004164566.tif 000008
【図７】
2004164566.tif 000009
【図８】
2004164566.tif 000010
【図９】
2004164566.tif 000011
【図１０】
2004164566.tif 000012
【図１１】
2004164566.tif 000013
【図１２】
2004164566.tif 000014
【図１３】
2004164566.tif 000015
【図１４】
2004164566.tif 000016
【図１５】
2004164566.tif 000017
【図１６】
2004164566.tif 000018
【図１７】
2004164566.tif 000019
【図１８】
2004164566.tif 000020
【図１９】
2004164566.tif 000021
【図２０】
2004164566.tif 000022
【図２１】
2004164566.tif 000023