JP5768017B2

JP5768017B2 - 通信端末、通信方法および通信プログラム

Info

Publication number: JP5768017B2
Application number: JP2012165123A
Authority: JP
Inventors: 瀬恒太郎伊
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2012-07-25
Filing date: 2012-07-25
Publication date: 2015-08-26
Anticipated expiration: 2032-07-25
Also published as: US20160112952A1; US20140029496A1; JP2014027422A; US9544851B2; US9253725B2

Description

本発明の実施形態は、通信端末、通信方法および通信プログラムに関する。

通信技術の発展に伴い、スマートフォンのような通信機能を有する端末が普及してきている。一方で、地球温暖化への懸念から、端末の消費電力削減に対する社会的な要請が高まっている。さらに、スマートフォンのようなバッテリにより駆動される端末においては、その駆動時間を長くするという利便性の観点からも、端末の消費電力削減に対するニーズがある。

この消費電力削減への要求に対して、ACPI（Advanced Configuration and Power Interface）という電源制御の枠組みが提案されている。これによれば、S3という状態が定義されている。S3は、“Suspend to RAM”と呼ばれる状態である。S3状態では、CPUのレジスタの値をメインメモリに書き出し、メインメモリを通電状態にしつつ、CPUやバスやバスデバイスの給電を絶つ。S3状態の端末は動作を行うことはできないが、S0状態（動作状態）よりも消費電力は少ない。さらにS3状態からS0状態に復帰した際には、S3状態に遷移する前の端末状態に復帰できる。このため、コールドブートよりも利便性が高い。

さらに他の従来技術として、非特許文献1を挙げることができる。ユーザがtelnetにてローカル端末からリモート端末にログオンし、リモート端末上で文章作成などの作業を行っているとする。この際に、ローカル端末がS0状態からS3状態に遷移すると、telnetセッションに関わるTCP(Transmission Control Protocol)コネクションがリモート端末により切断される。このため、ローカル端末がS3状態からS0状態に復帰した際には、リモート端末上の作成中の文章が失われる問題が発生し、さらに、ユーザがリモート端末に再ログオン操作をしなければいけない問題も発生する。上記非特許文献1はこれらの問題を解決しようとしたものである。すなわち、ローカル端末は、S3状態に移行した時に、TCP_SLEEPメッセージをリモート端末に送信することで、リモート端末がTCPコネクションを切断することを抑制する。

さらに他の従来技術として、特許文献1がある。これによると、無線LAN端末において、送受信パケットが一定時間無い場合に、接続中のアクセスポイントにデータを送信するために必要な情報を端末内部に保存し、通信回路の電源供給を停止する。送信パケット発生時には、通信回路に電源を供給し、保存していた情報を用いて接続手順を行わずに、以前接続していたアクセスポイントへパケットを送信する。このように、アクセスポイントとの接続手順を省くことで、通信部の電源供給後のパケット送信に要する遅延を削減している。

特開2006-5577号公報

"A "Green TCP/IP" to reduce electricity consumed by computers ", Liam Irish, Southeastcon '98. Proceedings. IEEE ,24-26 Apr 1998 (pp 302 - 305)

近年、Webサービスあるいはクラウドサービスと呼ばれるサービスが普及してきている。例えば、Google社のGmailのようなものを挙げることができる。Gmailでは、メールデータはサーバ上に存在し、これにWebブラウザからアクセスすることで、専用のメールアプリケーションを用いることなく、受信メールの一覧や、選択メールの内容を表示する。このようなサービスを想定した場合、ローカル端末は、必要なデータを受信する度に、TCPコネクションを切断し、ローカル端末の通信部分の給電を止めることが、消費電力の削減の観点からは望ましい。例えば、受信メール一覧データを取得した後はTCPコネクションを切断し、受信メール一覧画面を表示し、ユーザが受信メール一覧画面を閲覧している間は、通信部分の給電を止めるよう制御する。そして、ユーザが受信メール一覧画面を操作すると、通信部分の給電を行い、サーバへのTCPコネクションを設定し、その操作に応じた要求をサーバに送信し、その応答に含まれる応答をサーバから受信し、その応答に含まれるデータを用いて画面を表示する。

しかしながら、このように受信メールの一覧画面を表示しているブラウザを操作する度にTCPコネクションを設定しなおすと、コネクションセットアップによるオーバーヘッドと、スロースタートと呼ばれるフロー制御により、ブラウザ上で次の画面が表示されるまでの遅延が大きくなる。これにより、ユーザの利便性が低下する。この問題および解決法は、非特許文献1では述べられていない。さらに、非特許文献1では、省電状態（例えばS3）ではローカル端末全体が動作を止めるため、省電状態においてユーザは端末操作ができず、利便性を損なわれるという問題があった。

また、特許文献１では、無線LANアクセスポイントとのアソシエーションを切断しているため、サーバからTCPコネクションを切断する。よって、TCPコネクションを設定しなおすことに起因する問題を解決することはできない。

本発明の一側面は、通信端末における省電力とユーザの利便性の両立させることを目的とする。

本発明の一態様としての通信端末は、通信デバイスと、コネクション処理部と、通信管理部と、デバイス電源管理部とを備える。

前記通信デバイスは、ネットワークと通信する。

前記コネクション処理部は、前記ネットワーク上の第1通信端末とコネクションを設定する。

前記通信管理部は、前記コネクション上でのセッションの開始および終了を検出する。

前記デバイス電源管理部は、前記通信管理部の検出結果に応じて、前記通信デバイスへの給電を制御する。

本実施形態における全体構成を示す。本実施形態に係る通信端末のハードウエア構成例を示す。本実施形態に係る通信端末のソフトウエア構成を示す。本実施形態に係る通信端末と、ネットワーク上の通信端末間の通信シーケンス例を記す。 HTTPレベルの通信シーケンスを記す。受信メールの一覧画面の例を示す。 HTMLデータにより表示する画面の表示例を示す。通信デバイスのハードウエア構成例を示す。 HTTP処理部の動作を示す。 TCPヘッダの構成を示す。 WEBブラウザとメールソフトの二つのアプリケーションが実行されている場合のソフトウエア構成を示す。

以下、図面を参照しながら、本実施形態を説明する。

図1に本実施形態における全体構成を示す。

通信端末1と、第1の通信端末である通信端末2とが、ネットワーク3を介して接続されている。通信端末1は、無線LAN(例えばIEEE 802.11)にて、無線LANアクセスポイント4を介してネットワーク3に接続されている。通信端末2は10Gbイーサネットにて、ネットワーク3に接続されている。

通信端末1ではWebブラウザが実行されており、通信端末2ではHTTPサーバが動作している。通信端末2では、HTTPを用いたメールサービスが提供されており、通信端末1からこのメールサービスを利用している。

図4に通信端末1と通信端末2間の通信シーケンス例を記す。図4ではTCPパケットのシーケンスを記している。

まず初めに、通信端末1は、通信端末2に、宛先ポート番号80にて、TCPコネクションを設定する（S101）。この時のTCPコネクション設定手順は、次のとおりである。(1)TCPのSYNパケットを通信端末1から通信端末2に送信し、(2)これを受信した通信端末2がSYN ACKパケットを通信端末1に送信し、(3)このSYN ACKパケットを受信した通信端末1がACKパケットを通信端末2に送信する。

次に、通信端末1は、HTTPリクエストを通信端末2に送信する（S102）。このときHTTPリクエストは、複数のTCPパケットに分割されることがある。HTTPリクエストを受信した送信端末2は、HTTPレスポンスを送信端末1に送信する（S103）。HTTPレスポンスは、複数のTCPパケットに分割されることがある。図4中のACKはDATAを受信したことを示す送達確認パケットであり、受信済みデータを識別するセグメントサイズの情報（図10の確認応答番号）を有する。

図5にHTTPレベルの通信シーケンスを記す。図5において、実線矢印はTCPパケットの送受信を示し、点線矢印はHTTPレベルの情報の送受信を示す。

先に述べたように、それぞれのHTTPリクエストとHTTPレスポンスは、一つ以上のTCPパケットにて運ばれる。典型的には一つ目のHTTPセッション1のHTTPレスポンスでは、通信端末1はユーザ認証画面に対応するHTMLデータを受信する。通信端末1上で動作するWebブラウザにて受信したHTMLデータは、ユーザIDとパスワード入力画面として、ユーザに提示される。

ユーザがこの画面にてユーザIDとパスワードを入力し、送信ボタンを押下することで、HTTPセッション2が開始される。HTTPセッション2のHTTPリクエストには、ユーザID・パスワード・リクエストURL（HTTPリクエストが要求するURL）を含む。これを受信した通信端末2は、対応するユーザの受信メールの一覧を表示するためのHTMLデータと、ユーザを識別するユーザ識別情報とを含むHTTPレスポンスを、通信端末1に送信する。

さらに、ユーザが受信メール一覧画面上であるメールを選択することで、HTTPセッション3が開始される。HTTPセッション3のHTTPリクエストには、ユーザを識別するユーザ識別情報と、ユーザが選択したメールに対応するメール識別情報と、リクエストURLとを含む。これを受信した通信端末2は、ユーザ識別情報と、メール識別情報に対応するメールを表示するためのHTMLデータとを含むHTTPレスポンスを、通信端末1に送信する。

図6に、受信メールの一覧画面の例を示す。

通信端末1は、HTTPセッション2のHTTPレスポンスに含まれるHTMLデータを受信すると、これをWebブラウザを使って画面に表示する。図6はその表示例である。

この表示例では、画面は二つのフレームからなっている。左のフレーム51には受信ボタン61・作成ボタン62・受信箱ボタン63・送信済ボタン64が表示されている。右のフレーム52には、受信したそれぞれのメールに対する（件名、受信日時、送信者）のエントリが表示されている。右フレームのスクロールバー65を用いて画面スクロールすることで、画面に入りきれないエントリも表示することができる。

さて、図6のように2つのフレームの画面を表示するような複数のHTMLデータを取得するには、図5で説明したように一つのHTTPセッションではなく、HTMLデータ毎に一つのHTMLセッションを用いてデータを取得することが一般的である。しかしながら、図5では説明を簡易に行うため、受信メール一覧画面のHTMLデータが、一つのHTTPセッションで受信できる場合の例を元に説明を行っている。

たとえば図6の画面の場合は、まず一つ目のHTMLデータを取得し、このHTMLデータには、二つのフレームと、夫々に対応する埋め込みオブジェクトのURLとが記されている。Webブラウザは埋め込みオブジェクトのURLに対して、2つのHTTPセッションにて、図6の右画面と左画面のHTMLデータ（埋め込みオブジェクト）を受信することになる。もちろん、埋め込みオブジェクトはHTMLデータ以外に、画像データなど様々なものが可能である。

図6の受信メール一覧画面にて、ユーザが一番上のエントリを選択すると、通信端末1が、HTTPセッション3によりHTMLデータを受信する。このHTMLデータにより表示する画面の表示例を図7に示す。

図7の表示例では、画面は二つのフレームからなっている。左のフレーム71には、次のメールボタン81・前のメールボタン82・返信ボタン83・受信箱ボタン84・送信済ボタン85が表示されている。右のフレーム72には、ユーザが選択したメールに対応するメールの詳細が記されている。メール本文が長く画面に収まりきらない場合には、右フレームのスクロールバー86を用いて画面をスクロールすることで、画面外の部分を表示できる。

ユーザが図7のメール本文を読んでいる間は、通信端末1と通信端末2との間の通信は発生しない。画面データは全て取得済であるため、例えば、スクロールバーを操作しても通信が不要である。このため、ユーザがメールを読んでいる間（例えば3分）は、通信端末1の通信部の給電を停止することが可能である（図5のHTTPセッション3の後のD3状態）。D3状態は、通信部の給電を停止した状態である。このように通信が発生しない間、D3状態とすることで、通信回路における動作電力およびリーク電力を減らすことができ、通信端末1の消費電力を削減することができる。さらに、ユーザがメールを読んでいる間だけでなく、認証画面にユーザIDとパスワードを入力している間（HTTPセッション1とHTTPセッション2の間）と、受信メール一覧画面にて読むメールを探している間（HTTPセッション2とHTTPセッション3の間）にも、通信端末1をD3状態にできる。この様子が図5に示されている。

図2に通信端末1のハードウエア構成例を示す。

通信端末1は、CPU11と表示デバイス12とワーキングメモリ13と外部入力デバイス14と通信デバイス15とフラッシュメモリ16とバッテリ17とバッテリ管理部18と備える。

CPU11は、例えばインテル社Core i5のようなプロセッサである。

表示デバイス12は、例えばLCDディスプレイのように、画面表示信号を人間の見える形式で画面表示するものである。

ワーキングメモリ13は、DRAMのようなメモリであり、例えばLPDDRインタフェースにてCPU11と接続される。

外部入力デバイス14は、ボタンやタッチパネルやキーボードやマウスなどのような入力デバイスであり、例えばUSBインタフェースにてCPU11に接続される。

通信デバイス15は、例えば無線LAN（IEEE 802.11）規格に従って動作し、ネットワークとのパケット送受信を行うものである。通信デバイス15は、例えばPCI expressバスにてCPU11と接続される。通信デバイス１５は、ネットワークとの情報のやりとりを行う規格であれば、無線LANの他に有線の1Gイーサネットや、携帯電話網で用いられるセルラー通信規格（例えば、LTE(Long Term Evolution)）や、WiMAX, Bluetooth, Zigbee, Zwave、音声電話用通信規格など様々なものが適用できる。

フラッシュメモリ16は、例えばNANDフラッシュメモリ16であり、OSやWebブラウザなどのプログラムや、ユーザデータを保持するものである。フラッシュメモリ16は、例えばSATAインタフェースにてCPU11と接続される。フラッシュメモリ16は、データの保持ができれば、ハードディスクなどの他の媒体でも代替可能である。

バッテリ17は、リチウムイオン電池などの電気エネルギーを通信端末1に供給するものである。

バッテリ管理部18は、CPU11に対してバッテリ残量などのようなバッテリ状態を提供する。

図8に通信デバイス15のハードウエア構成例を示す。通信デバイス15は、内部インタフェース部81と状態保持部82と電源状態制御部83とパケット保持部84と外部インタフェース部85とを備える。

内部インタフェース部81は、例えばPCI-expressインタフェースであり、PCI-express規格に従ってCPU11との情報送受信を行う。また、通信デバイス15への給電は、内部インタフェース部81を介して行われる。

外部インタフェース部85は、通信路と信号を送受信する通信部を含む。外部インタフェース部85は、パケット保持部84に送信フレームが存在する場合に、これを通信路に電気信号あるいは電波信号として送信する。また、通信路から電気信号あるいは電波信号を受信して、これを受信フレームとしてパケット保持部84に送る。

外部インタフェース部85は、無線LAN用の場合には、IEEE802.11のMAC処理部と物理層処理部とを備える。MAC処理部は、物理層処理部を介して、プローブ要求を送信し、アクセスポイントからのプローブ応答を受信することでアクセスポイントを発見する。MAC処理部は、物理処理部に指定する無線チャンネルを変えながらプローブ要求送信とプローブ応答受信を繰り返すことで、様々な無線チャンネルにわたってアクセスポイントを発見することができる。

MAC処理部は、発見したアクセスポイントを、CPU11に内部インタフェース部81を介して伝える。CPU11からアクセスポイントのSSIDとBSSIDと無線チャンネルを含む接続要求を、内部インタフェースを介してMAC処理部は受信する。MAC処理部は、指定されたSSIDとBSSIDと無線チャンネルを用いて、物理層処理部と状態保持部82を介して、アクセスポイントへアソシエーション要求を送信し、アソシエーション応答を受信する。このアソシエーション要求とアソシエーション応答の送受信により、通信デバイス15とアクセスポイントとの間に、アソシエーションが設定される。アソシエーションが設定されると、MAC処理部は、そのSSIDとBSSIDと無線チャンネルを、状態保持部82に送る。状態保持部82は、MAC処理部から受けたこれらのデータを内部に保持する。

MAC処理部は、パケット保持部84に送信イーサフレームがあると、これにMACヘッダを付与して、IEEE802.11フレームを生成する。MAC処理部は、このフレームを、物理層処理部を介してアクセスポイントに送信する。また、MAC処理部は、物理層処理部を介してアクセスポイントからIEEE802.11フレームを受信すると、そのMACヘッダを外して、イーサフレームを抽出する。MAC処理部は、このイーサフレームをパケット保持部84に送る。パケット保持部84は、MAC処理部から受けたイーサフレームを一時保持する。

パケット保持部84は、ワーキングメモリ13から、CPU11と内部インタフェース部81を介して、送信パケット（無線LANの場合はイーサフレーム）を受信および保持する。外部インタフェース部85はこれをパケット保持部84から取り出し、通信路に送信する。また、通信路から外部インタフェース部85を介してパケットをパケット保持部84が受信すると、これを保持し、内部インタフェース部81とCPU11を介して、ワーキングメモリ13に送信する。このようにパケット保持部84は、ワーキングメモリ13と通信路との間でのパケットのやり取りの際に、パケットの一時保管を行うものであり、主として内部プロトコルと外部プロトコルのタイミングをとるために使われる。

状態保持部82は、CPU11からアクセスできるメモリ領域であり、例えば複数のレジスタ変数を保持する。通信デバイス15の設定情報を、CPU11からこの状態保持部82に設定することで、通信デバイス15の設定を変更することが可能である。また、通信状態に関わる情報を外部インタフェース部85に問い合わせるためにも使用する。以下に、レジスタ変数の例を示す。

電源状態制御部83は、状態保持部82のAレジスタの値に従い、通信デバイス15の電源状態を設定する。Aレジスタの値が0の場合はD0状態にし、1の場合はD1状態に、2の場合はD2状態に、3の場合はD3状態に設定する。

D0状態とは通信デバイス15が動作している状態であり、送信も受信も可能である。D0状態は、たとえば通信デバイスの第1電源状態に対応する。

D3状態とはD0状態に復帰するのに最低必要な機能を除いて、全ての給電を停止した状態である。D3状態では、送信も受信も不可である。具体例としては、外部インタフェース部85とパケット保持部84の給電を止める。状態保持部82は、Aレジスタ以外の読み書きを停止しつつ、すべてのレジスタの保持内容を保持する状態にする。内部インタフェース部81はAレジスタの読み書き以外の機能を停止する。D3状態は、たとえば通信デバイスの第2電源状態の一形態に対応する。第2電源状態の他の形態として、送信可能で受信不可、または、送信不可で受信可能な状態も可能である。第2電源状態は、第1電源状態よりも消費電力が低い。また、第2電源状態の他の形態としては、LTEなどのようにデータ（あるいは音声）通信チャネルを設定する通信デバイスの場合には、通信チャネルを切断し、通信チャネルでのデータ送信あるいは受信のどちらか一方あるいは両方の機能に関わる給電を止め、位置情報登録や呼び出し情報などの制御メッセージの送受信は可能である状態を、挙げることができる。もちろん制御メッセージの送受信に関わる機能への給電を止めた状態を第2電源状態とすることも可能である。

D1とD2は、D0とD3の中間の状態であり、P(Di)を各状態の消費電力とすると、P(D0)>P(D1)>P(D2)>P(D3)である。また、各状態からD0に復帰するのに要する時間をT(Di)で表すと、T(D1)<T(D2)<T(D3)である。

図3に通信端末1のソフトウエア構成を示す。本実施形態では、通信端末1は、図2のハードウエア上で、図3のソフトウエア（プログラム）が動作することで実現される。図3に示す各ブロックは、プログラムモジュールとして実現することができる。プログラムは、コンピュータ読取可能記録媒体（図2フラッシュメモリ１６）に格納されてもよい。当該記録媒体からプログラムがコンピュータによって読み出され、メモリ（図2ワーキングメモリ１３）に展開され、実行される。ただし、図3のソフトウエアの一部が、ハードウエアで実現されることも可能である。図3のソフトウエアは、大きくOSとアプリケーションソフトウエアに分けることができる。もちろん、この他に、OSとアプリケーションを分離しないソフトウエア構成も可能である。

OSは、TCP処理部(コネクション処理部)31とIP処理部32とデバイスドライバ33と通信管理部34とデバイス電源管理部35と端末電源管理部36とを備える。

TCP処理部31は、アプリケーションソフトウエアの要請によりTCPコネクションの設定・解放を行う。また、TCP処理部31は、アプリケーションソフトウエアから渡されたデータをTCPパケットの形式に変換して、IP処理部32とデバイスドライバ33を介して、通信端末2に送信する。通信端末2からACKパケットを受信しない場合には、TCPパケットの再送処理を行う。さらに、TCP処理部31は、通信端末2から受信したTCPパケットに対して、ACKパケットを通信端末2に送信する。また、TCP処理部31は、受信TCPパケットからデータを抽出し、アプリケーションソフトウエアに送信する。

IP処理部32は、TCP処理部31から受信したTCPパケットをIPパケットに変換して、デバイスドライバ33を介して通信端末2に送信する。さらに、IP処理部32は、通信端末2から受信したIPパケットからTCPパケットを抽出し、TCP処理部31に送信する。なお、図示しないがイーサ処理部が、IP処理部32とデバイスドライバ33との間に存在する。イーサ処理部は、IP処理部32から受信したIPパケットをイーサフレームに変換して、デバイスドライバ33に送信する。またイーサ処理部は、デバイスドライバ33から受信したイーサフレームからIPパケットを抽出し、IP処理部32に渡す。

デバイスドライバ33は、図2の通信デバイス15を制御するためのソフトウエアである。デバイスドライバ33は、指定されたメモリ番地にデータを読み書きすることで、通信デバイス15のレジスタにアクセスし、これにより通信デバイス15を制御する。さらに、イーサ処理部から受信したイーサフレームを、通信デバイス15に送る。また通信デバイス15により通信路からイーサフレームが受信された場合、通信デバイス15からCPU11に割り込みがかかることで、デバイスドライバ33が実行され、通信デバイス15からイーサフレームをデバイスドライバ33が受信する。この通信デバイス15とデバイスドライバ33とのイーサフレームのやり取りは、あらかじめ定められたメモリ番地にアクセスすることで行われる。本実施形態において通信端末1のCPU11は、メモリマップドIOを用いて、通信デバイス15やワーキングメモリ13などの周辺デバイスにアクセスすることを想定している。ただし、ポートマップドIOなど他のアクセス方法を用いることも可能である。

通信管理部34は、アプリケーションソフトウエアのHTTP処理部41から、通信アクティビティ情報（HTTPセッションを開始通知、HTTPセッション終了通知）を受信する。HTTPセッション終了通知を受信すると、デバイス電源管理部35に、通信デバイス15の電源状態設定要求（D3）を送信する。また、通信管理部34がHTTPセッション開始通知を受信すると、デバイス電源管理部35に通信デバイス15の電源状態設定要求(D0)を送信する。なお、“電源状態設定要求（X）”とは、通信デバイスを状態Xにすることを要求するものである。

デバイス電源管理部35は、受信した電源状態設定要求に従ってAレジスタにアクセスすることで、通信デバイス15の電源状態を制御する。電源状態設定要求の内容は、上記のように、通信管理部34によるセッションの開始または終了の検出結果に応じて決まる。したがって、デバイス電源管理部35は、セッションの開始および終了の検出結果に応じて、通信デバイスの給電を制御する。

なお、本実施形態では、通信デバイス15に対してのみ対応したデバイス電源管理部35が設けられるが、外部入力デバイス14やワーキングメモリ13やCPU11やそれらの接続インタフェース（PCI-Expressなど）など、すべてのコンポーネントに対応した電源管理部を設けることも可能である。この場合は、コンポーネント毎に、電源状態の管理を行うことができる。

端末電源管理部36は、デバイス電源管理部35を含むすべてのコンポーネントの電源状態を管理している。端末電源管理部36は、例えば通信端末1全体をスリープ状態に移行させ、スリープ状態から動作状態に復帰させる。

アプリケーションソフトウエアは、HTTP処理部41とアプリケーションデータ処理部42と外部入出力データ処理部43とを備える。

アプリケーションデータ処理部42は、HTTP処理部41から受信したアプリケーションデータを、そのアプリケーションソフトウエア固有の処理を行うものである。WEBブラウザの場合には、アプリケーションデータとしてHTMLデータを受信し、それを用いてレンダリング処理（画面の画素の色や輝度値を生成する処理）を行う。レンダリング処理で生成した画素データは、外部入出力データ処理部43に送る。ここで、アプリケーションデータはHTMLデータの他に、画像データや、動画データや、音データなど様々なものが考えられる。レンダリング処理を行うデータであれば、その種類は問わない。また、レンダリング処理とは画素データを生成するだけではなく、外部に対して情報を出力するためにその出力デバイスに応じた形式のデータを生成するあらゆる処理を含んでいる。たとえば、レンダリング処理部は、音データを生成する場合や、LEDなどを制御する場合も含む。

さらに、アプリケーションデータは、JavaScriptで書かれたプログラムであってもよい。その際には、アプリケーションデータ処理部42はそのプログラムを実行し、その結果に応じてレンダリング処理を行ったり、HTTP処理部41に新たなHTTP通信要求を行う。例えば、Google社のGoogle docsは、JavaScriptで書かれたプログラムで実現されており、アプリケーションデータ処理部42にてそのプログラムを実行することで、動作が行われる。アプリケーションデータ処理部42で処理するプログラムは、JavaScriptでの記述に限定される必要はなく、様々なプログラム言語で記述することが可能である。

アプリケーションデータ処理部42は、新たなアプリケーションデータを取得する必要が生じた場合には、そのURLを含むHTTP通信要求を送信する。たとえば、受信したアプリケーションデータに、埋め込みURLが記述されている場合や、プログラムを実行する過程で必要になった場合などがある。

さらに、外部入出力データ処理部43から外部イベントを受信すると、それに応じて新たに画素データ生成や、HTTP通信要求のHTTP処理部41への送信を行う。例えば、図7のスクロールバー位置のマウスドラッグイベントを、外部入出力データ処理部43を介して、アプリケーションデータ処理部42が受信すると、画面スクロールに対応する画素データを生成し、外部入出力データ処理部43へ送る。あるいは、図7の受信箱ボタン84のマウスクリックイベントを外部入出力データ処理部43を介して、アプリケーションデータ処理部42が受信すると、図6の受信メール一覧画面を取得するためのURLを含むHTTP通信要求を、HTTP処理部41へ送る。

外部入出力データ処理部43は、アプリケーションデータ処理部42から、画素データを受信すると、これを用いて画面表示を行う。例えば、図7のような画面表示を行う。また、マウスクリックなどの外部からのイベントを外部インタフェース部85が受信すると、これをアプリケーションデータ処理部42へ送る。

図9にHTTP処理部41の動作を示す。HTTP処理部41は、アプリケーションデータ処理部42からのHTTP通信要求を受信すると、通信管理部34へ、HTTPセッション開始通知（セッション識別情報、プロセス識別情報、コネクション識別情報）を送る（S301）。

セッション識別情報とは、アプリケーションソフトの中でHTTPセッションを一意に識別する情報であり、この情報があることにより一つのアプリケーションソフトで複数のHTTPセッションを利用することも可能となる。プロセス識別情報は、アプリケーションソフトのプロセスを識別する情報である（UNIXの場合）。このようにHTTPセッション開始通知が（セッション識別情報、プロセス識別情報）の組を有することで、通信端末1内でHTTPセッションを一意に識別することが可能となる。

さらに、コネクション識別情報は、HTTPセッションが使用するTCPコネクションを識別するための情報であり、例えばsocket()システムコールでOSが返すソケット番号を用いることができる。ただし、そのHTTPセッションが使用するTCPコネクションが未設定の場合は、無効な値例えば0を設定する。

次に、HTTP通信要求に含まれるURL内の宛先アドレスと、ポート番号に対するTCPコネクションの設定有無とを確認し（S302）、設定されていない場合にはTCPコネクションの設定を行う（S303）。

次に、TCPコネクションを用いてHTTPリクエストを送信し（S304）、それに対するHTTP応答を受信する（S305）。HTTP応答を受信すると、HTTPセッション終了通知（セッション識別情報、プロセス識別情報、コネクション識別情報）を、通信管理部34へ送る（S306）。この時、HTTPセッション終了通知のコネクション識別情報には、HTTPセッションに使用したTCPコネクションを識別する情報、例えばソケット番号を記す。

このように、本実施形態によれば、アプリケーションソフトウエアが通信を行っていない場合において、通信デバイス15の電源状態を動作状態（D0）よりも低消費電力な状態（D3）にすることにより、通信端末の消費電力を低減することが可能となる。さらに、通信が必要な際には、通信デバイス15の電源状態を直ちに通信動作可能な動作状態（D0）に復帰させることが可能であるため、通信に関して不要な遅延の発生を防ぐことができ、ユーザの利便性を損なわない。

（HTTP以外のプロトコルへの適用）
これまでは、アプリケーションソフトとしてWEBブラウザを想定していたが、他のアプリケーションソフトウエアや、HTTP以外のプロトコルを用いることも可能である。

例えば、アプリケーションソフトウエアがWEBブラウザではなくメールソフトである場合には、プロトコルとしてPOP3（メール受信）とSMTP（メール送信）を使用する。どちらのプロトコルもそれぞれTCPコネクションを使用する。POP3は、宛先ポート番号110のTCPコネクションを設定し、このTCPコネクション上で、以下のコマンドを利用してメールの受信を行う（<>はコマンドの引数である）。

USER <ユーザ名> ：ユーザ名
PASS <パスワード>：パスワード
LIST ：受信メール一覧要求
TOP <メッセージ番号> <行数>：後に続く数のメール内容要求
RETR<メッセージ番号>:メッセージ取得要求
DELE <メッセージ番号>：メール削除マーキング要求
QUIT ：アップデート（更新を反映）もしくはセッションクローズ要求の送信

具体的には、メールソフトは、TCPコネクション設定後、USERコマンドとPASSコマンドでユーザ認証を行う。認証後、LISTコマンドで受信メールの一覧（メッセージ番号とデータサイズ）を取得する。TOPコマンドでは、メッセージ番号でメールを指定し、さらに指定した行数だけデータを取得する。LISTコマンドで取得したメール一覧の各々のメールを指定したTOPコマンドを実行することで、図6と同様の受信メール一覧画面を表示することができる。ユーザが読むメールを探している間、TCPコネクションを設定したまま通信デバイス15の電源状態をD3にすることにより、通信端末の消費電力を削減することができる。ユーザが読むメールを選択すると、通信デバイス15の電源状態をD0にし、RETRコマンドをTCPコネクションを用いて送信することで、ユーザが選択したメールメッセージ全体を取得する。取得後、通信デバイス15の電源状態をD3に変更し、図7の画面を表示する。

この動作を図3を用いて説明する。HTTP処理部41の代わりに、SMTP処理部とPOP処理部が設けられる。SMTP処理部とPOP処理部のそれぞれが、通信管理部34に通信アクティビティ情報（（SMTPセッション開始通知、SMTPセッション終了通知）、（POPセッション開始通知、POPセッション終了通知））を送る。

通信管理部34は、アプリケーションソフトウエアからセッション開始要求を受信すると、デバイス電源管理部35に通信デバイス15の電源状態設定要求(D0)を送る。

また、通信管理部34は、受信済みのすべてのセッション開始要求に対するセッション終了要求を受信すると、デバイス電源管理部35に通信デバイス15の電源状態設定要求(D3)を送る。

（複数アプリケーション）
図3では、アプリケーションソフトウエアは一つのみ記しているが、複数のアプリケーションソフトウエアが実行されていてもかまわない。例えばアプリケーションソフトウエアとして、WEBブラウザとメールソフトの二つが実行されている場合を考える（図11）。図11では、WEBブラウザ47とメールソフト48以外にDHCPクライアント46もアプリケーションの例として描いている。

この場合、通信管理部34は、通信アクティビティ情報として(Web/POP/SMTP)セッション開始通知を受信し、通信デバイス15の電源状態がD0以外の場合に、電源状態設定要求(D0)を送る。通信アクティビティ情報として(Web/POP/SMTP)セッション終了通知を、WEBブラウザ47あるいはメーラ48から受信した際には、終了していないセッションが存在しない場合には（すなわちすべてのセッションが終了している場合は）、電源状態設定要求(D3)を送る。この終了していないセッションの有無は、通信アクティビティ情報に含まれる（セッション識別情報、プロセス識別情報）を用いて、セッション開始通知とセッション終了通知の対応をとることで、判断できる。

また、この例では、全てのTCPコネクションに対して、通信管理部34がそのアクティビティ情報からデバイス電源管理部35に電源状態設定要求を送っているが、一部のみのTCPコネクションを対象にして、そのアクティビティ情報からデバイス電源管理部34に電源状態設定要求を行うといった、変形も可能である。

図11では、DHCPクライアント46は、TCP処理部31ではなくUDP処理部45を介して通信する様子を示している。UDP処理部45ではTCP処理部31とは異なりコネクション型の通信を行わず、さらに通信管理部34はその通信アクティビティを管理していない。

また、図11では図3では省略したイーサ処理部44も記載している。イーサ処理部44では、IP処理部32から受信したIPパケットをイーサフレームの形式にカプセル化し、デバイスドライバ33に送信する。また、デバイスドライバ33からイーサフレームを受信すると、この中に含まれるIPパケットを抽出しIP処理部32に送信する。イーサ処理部44は、ARPテーブルを保持しており、イーサフレームの宛先アドレスをIPパケットのネクストホップノードのIPアドレスを基に検索する。ここでネクストホップノードとは、IPパケットの宛先アドレスが自端末と同一サブネット内に存在する場合にはその宛先ノードであり、そうでない場合には、このIPパケットを転送するルータである。ARPテーブルにIPアドレスに該当するエントリが存在しない場合には、ARP解決と呼ばれる手段を用いて宛先イーサアドレスを得る。このARP解決の手順は、まずネクストホップノードのIPアドレスを含むARP要求パケットを自端末がサブネット内にマルチキャストあるいはブロードキャストし、これを受け取ったネクストホップノードがそのイーサアドレスを記したARP応答パケットを送信する。自端末は、このARP応答パケットに記されているネクストホップノードのイーサアドレスを抽出し、宛先イーサアドレスとして使用する、さらにそのイーサアドレスをARPテーブルに登録する。

（ZEROWINDOWの送信）
これまでは、WEBブラウザやメールソフトのように、クライアントがサーバにリクエストを送信し、サーバがレスポンスをクライアントに送信するといういわゆるサーバクライアント型の通信を想定して、説明を行ってきたが、他の形態の通信も可能である。

例えばWebsocket(IETF RFC6455)を用いた場合のように、クライアントからのリクエストなしに、サーバからデータを送信する形態がある。この場合には、通信デバイス15の状態をD0からD3に変更する際に、設定中のTCPコネクションに対して受信不可通知を、通信端末1から通信端末2に送信することが望ましい。

TCPプロトコルでは、通信端末1がパケット受信できない時に、通信端末2がパケットを送信すると、通信端末2は送信パケットのロスを検出し、通信データ2のフロー制御機能が送信可能レートを低減させてしまう。そこで、D0からD3へ遷移する前に、受信不可通知を送信しておくことで、通信端末2の送信可能レートを高い値に維持できる。これにより、通信端末1からHTTPリクエストを送信した際には、通信端末2は高いレートでHTTPレスポンスを送信することが可能となる。つまり、通信端末1において、HTTPリクエスト送信からHTTPレスポンスを受信するまでの遅延の増加を防ぐことができ、よってユーザの利便性が損なわれることを防ぐことができる。

ここで、TCPプロトコルでは、受信側から送信側へ、受信可能なデータサイズを通知することになっている。それゆえ、受信可能なデータサイズがゼロである旨（TCP Zerowindow）を通知すると、通信端末2から通信端末1へのデータ通信を抑制することができる。このときのTCP Zerowindowの通知が、受信不可通知に相当する。

図10にTCPヘッダの構成を示す。TCP Zerowindowの通知は、図10の「16ビットウィンドウサイズ」がゼロの値を記したものである。発信元ポート番号と送信元ポート番号は、設定しているTCPコネクションに対応する値を記す。さらに、確認応答番号は既に抜けなく受信できているデータに対応する値を記す。ACKフラッグは立てておく（1にする）。

図3を用いて、上記の動作の説明を行う。通信管理部34は、デバイス電源管理部35に電源状態設定要求(D3)を送る前に、TCP処理部31にTCP Zerowindow通知の送信要求を送る。

これを受信したTCP処理部31は、自身が管理するTCPコネクション情報から設定中のTCPコネクションを抽出し、それぞれのTCPコネクションに対してTCP Zerowindow通知を送信する。この際、TCP処理部31は、TCP Zerowindow通知を、各コネクション毎に複数送信することで、TCP Zerowindow通知が相手通信端末に届く確率を向上することもできる。

その後、通信管理部34は、デバイス電源管理部に電源状態設定要求(D3)を送る。

通信管理部34は、いずれかのアプリケーションソフトウエアからセッション開始通知を受信すると、電源状態設定要求(D0)をデバイス電源管理部35に送る。この際、通信管理部34は、その旨をTCP処理部31に伝えることが望ましい。これを受信したTCP処理部31は、設定中のTCPコネクションに対して、受信可能状態であることを、相手通信端末に通知することが可能となる。

ここで受信可能状態の通知は、図10のウィンドウサイズが1以上のTCPパケットを送信することで実施できる。ただし、ウィンドウサイズは、受信可能なデータサイズに従って設定することが望ましい。これにより、相手通信端末において送信を抑制されていたパケットを、通信端末1は受信することが可能となる。通信端末１からのリクエストを伴わずにサーバからデータを送信するケースにおいて（例えば、websocketを用いたサーバからのイベント通知）、端末が通信可能状態の通知を行うまでは、イベント通知をサーバが行うことはなく、端末が受信可能状態の通知を行ったタイミングでのみ、イベント送信をサーバが行う。このように通信端末1は、自身の望むタイミングで受信を行うことができるため、通信端末1の消費電力を低減することが可能となる。特に、通信端末1の有する表示デバイスを、ユーザアクティビティの低下により、低消費電力状態（例えば、バックライトを消し、ディスプレイを非表示とした状態）にしている場合には、サーバからのイベント情報を受信する必要はなく、ユーザが通信端末1を操作した際にディスプレイを表示状態とし、同時に受信可能状態の通知を行うことが望ましい。

（D0状態への移行の遅延）
通信管理部34は、アプリケーションソフトウエアからセッション開始通知を受信した際に、別のセッション開始通知を受信するまで電源状態設定要求(D0)の送信を遅らせることも可能である。これにより、複数の通信セッションの開始タイミングを合わせることができ、通信デバイス15がD0状態である時間を減らすことができる。よって消費電力を削減することができる。

ここで、通信管理部34は、常に二つ目のセッション開始要求を待つのではなく、一つ目のセッション開始要求を受信後、あらかじめ定められた遅延許容時間だけ電源状態設定要求(D0)の送信を待つようにすることも可能である。

あるいは、この許容遅延時間をアプリケーションソフトウエアが設定してセッション開始要求に含め、通信管理部34は、この許容遅延時間だけ電源状態設定要求(D0)の送信を遅らせることも可能である。

さらに、この許容遅延時間を通信端末1が保持するバッテリ17の電気残量が少ないほど、大きな値にしてもよい。これにより、バッテリ残量の少ない時ほど消費電力を削減することが可能となる。

（タイマを用いたD0状態への移行）
通信管理部34は、電源状態設定要求(D3)を送信後、ある一定時間を経過した場合に、セッション開始要求の受信が無くても、電源状態設定要求(D0)を送ることが望ましい。たとえば一定の周期で、電源状態設定要求(D0)を送ることが望ましい。これにより、通信管理部が管理していない通信、たとえばUDPパケットやARP要求パケットなどの送信を、通信端末1が可能となる。D0への移行後、あらかじめ定められた時間が経過したら、電源状態設定要求(D3)を送って、D3に戻ることが望ましい。

さらに、Websocketを用いている場合には、通信デバイス15がD0状態になった際に、受信可能状態である旨を相手通信端末に通知し、相手端末からのパケットを受信することも可能となる。

また、通信デバイス15がD3状態である時に、通信管理部34が管理していない通信に関するパケットの送信要求が発生した場合は、次のようにすることが望ましい。すなわち、そのパケット送信要求の発生後、あらかじめ定められた時間を経過後には、セッション開始要求の受信が無くても通信管理部34は、電源状態設定要求(D0)にすることが望ましい。

このとき、これらのTCP以外のパケットの夫々に、異なる待ち時間が予め設定されていてもよい。この場合、パケット送信要求発生後、そのパケットに対応する待ち時間が経過したら、電源状態設定要求(D0)を送ることもできる。この場合、あらかじめ定められた時間がさらに経過したのちに、通信管理部34は、電源状態設定要求(D3)を送ることが望ましい。その際には、TCP Zerowindow通知も合わせて行うことが望ましい。

（ARPキャッシュのリフレッシュ）
イーサネットや無線LANを、通信デバイス15として用いているとする。この場合、通信端末1と同じサブネットに属するルータは、通信端末1のMACアドレスを用いて、通信端末1へのイーサフレームを通信端末1に送信する。

ルータは、通信端末1のIPアドレスを記したARP要求をサブネットに送信する。この要求に対し、通信端末1が、自身のMACアドレスを記したARP応答を返す。これにより、ルータは通信端末1のMACアドレスを知ることができる。

一度取得したMACアドレスは、一定時間ルータに保持され、その後破棄される。保持していた通信端末1のMACアドレスを破棄した後に、ルータが通信端末1宛のパケットを受信すると、通信端末1のMACアドレスを取得するため、ARP要求を再度送信する。

しかしながら、この際、通信端末1の通信デバイス15がD3状態であると、このARP要求に対して通信端末1は応答することができない。このため、ルータは通信端末1にパケットを転送することができず、その旨を例えばICMP No Rute Host メッセージでパケットの送信元に返す。ICMP No Route Hostメッセージが、通信端末1とTCPコネクションが設定されている相手通信端末に届くと、相手通信端末がTCPコネクションを破棄する可能性がある。そこで、通信端末1は、D3状態において、一定時間毎に、D0状態に遷移し、例えばARP Announcementメッセージ(RFC 3972)といった広告パケットを送信することが望ましい。ARP Announcementメッセージは、通信端末1のMACアドレス（通信デバイスのハードウェアアドレス）とIPアドレスを含む。これにより、ルータは通信端末1のMACアドレスを、通信端末1のIPアドレスと対応づけて、学習し、ARPテーブルを更新できる。したがって、ルータ内で通信端末1のMACアドレスが破棄されずに、維持され続ける。ARP Announcementメッセージの送信後、またはD0状態への遷移からあらかじめ定めた一定時間が経過したら、元のD3状態に戻ることが望ましい。ここでは広告パケットを送信するためにD0状態に遷移したが、広告パケットに対する応答が不要である場合は、少なくとも送信可能な状態（第3電源状態）に遷移すればよい。第3電源状態は受信可能でも受信不可でもよい。このARP Announcementメッセージの送信は、図11の例ではイーサ処理部44が行うことが望ましい。

（通信アクティビティの把握の仕方）
これまでは、通信管理部34は、アプリケーションソフトウエアから通信アクティビティ情報を受信していたが、この通信アクティビティ情報を、デバイスドライバ33あるいはIP処理部32あるいはTCP処理部31から受信するようにすることも可能である。この場合は、セッションリクエストとセッションレスポンスを解析する機能を、デバイスドライバ33あるいはIP処理部32あるいはTCP処理部31に搭載することで、通信管理部34はこれまでと同様の処理を行うことが可能となる。

あるいは、通信管理部34は、パケットの送受信の有無に基づき通信アクティビティ情報を推測してもよい。これによっても通信管理部34は、これまでと同様の処理を行うことも可能である。

（TCPコネクション以外のコネクション）
これまでは、TCPコネクションを例に説明を行ってきたが、TCPコネクション以外のコネクションを対象とすることも可能である。ここでコネクション型の通信とは、通信している送信端末と受信端末との間で、その通信に対する状態を保持している通信形態を指しており、コネクションを設定するとはその通信に対する状態を送受信端末に設定することを言う。TCPの場合、送受信端末間でSYN、SYSNACK,ACKのメッセージを交換するスリーウェイハンドシェークを行うことでその通信に対する状態を設定している。

他のコネクションとして、例えば、IPSEC（Security Architecture for Internet Protocol）通信のIPSECコネクションを挙げることができる。IPSEC通信においては、送受信端末間で、セキュリティアソシエーションと呼ぶ状態を保持する。これは、IPSEC通信がTCPと同様にコネクション型の通信を行っていることを意味する。このセキュリティアソシエーションの設定には、通常IKE(Internet Key Exchange)プロトコルを用いる。このプロトコルは、処理すべきメッセージ数が多く、また処理に公開鍵暗号処理を含む場合があるなど、処理負荷が高い。それゆえ、IPSECコネクション(セキュリティアソシエーション)の再設定には、設定処理遅延が大きく、また処理負荷による消費電力が大きい。

そこで、送受信パケットのない時にIPSECコネクション（セキュリティアソシエーション）を維持したまま、通信デバイス15をD3状態に移行し、通信時にのみD0に復帰させる。これにより、利便性維持と消費電力削減の両立を実現できる。

また、通信デバイス15がD3状態の際に、通信が無くてもセキュリティアソシエーションのソフト有効期限になった際には、通信デバイスをD0に復帰し、セキュリティアソシエーションの再交渉を相手端末と行ってコネクションを維持してもよい。その後、D3に遷移することが望ましい。

上述のIPSECコネクションの例では、IPSECのトランスポートモードを想定して説明を行ったが、IPSECのトンネルモードを対象とすることも可能である。その場合、トンネルで運ばれるパケットがTCPコネクションである場合には、IPSECトンネル（コネクション）とTCPコネクションの両方を維持したまま、通信デバイス15の状態をD0からD3に移行することが望ましい。もちろん、IPSECトンネルのセキュリティアソシエーションの再交渉のために、D3からD0に通信デバイス15の状態を変更させた場合には、TCPコネクションにもその旨を通知することが望ましい。これにより、相手端末からのTCPパケットを受信できる。

なお、上述したIPSECトンネルは一例であり、他のトンネルを対象とすることも可能である。具体的には、GRE( Generic Routing Encapsulation)トンネルや、L2TP(Layer 2 Tunneling Protocol)トンネル、あるいはPPTP(Point-to-Point Tunneling Protocol)など、他の様々なトンネルプロトコルが可能である。

また、SPDY（http://dev.chromium.org/spdy/spdy-whitepaper）と呼ばれるプロトコルにも本実施形態は適用可能である。SPDYでは、一本のTCPコネクション上で複数のHTTPセッションが動作する。すべてのHTTPセッションがHTTPレスポンスを受信し終えた場合に、TCPコネクションを設定したまま通信デバイス15をD0からD3へ状態遷移する。いずれかのHTTPセッションにおいてHTTP要求を出す際に、通信デバイス15をD0状態に復帰する。

また、TCP over TCP over GRE over IPSECなどのように、ある通信コネクションに属するパケットを別の通信コネクションにて伝送する形態においても、本発明を適用することが可能である。すなわち、全てあるいはあらかじめ指定されたコネクションの設定・切断を通信管理部３４が検出し、これに応じて電源状態設定要求を、デバイス電源管理部３５に送信してもよい。この場合、設定中の全てのコネクションに対して、受信不可状態の通知あるいは受信可能状態の通知のどちらか一方あるいは両方を送信することが望ましい。

（ユーザ操作アクティビティとの連携）
本実施形態にかかる状態制御を、ユーザによる操作情報と連携させることも可能である。例えば、図3においてOSが外部からのユーザイベントを受信した際には、通信デバイス15をD3状態からD0状態に移行することも可能である。

例えば、ユーザがある一定時間、通信端末1を操作しない場合には、バックライトを消すなどにより、通信端末1に具備する液晶ディスプレイを低消費電力状態に移行する。このとき、通信デバイス15をD3状態とする。そして、その後ユーザがタッチパネルにタッチするなどして液晶ディスプレイのバックライトを点灯し、画面をユーザに提示する際に、通信デバイス15をD0状態にする。

これにより、UDPやDHCPパケットなどを送受信することが可能となり、周囲のプリンタやUPnPデバイスの有無を、液晶ディスプレイに表示することが可能となる。ユーザに画面表示が行われていない時には、このようなデバイスやサービス発見の動作は不要である。このため、画面表示が行われていないときは、通信デバイス15をD3の状態とすることで、消費電力の低減を実現できる。また、ユーザに画面表示を行うタイミングで通信デバイス15をD0状態にすることで、ユーザに通信サービスを提供する待ち時間を減らすことができる。よって、ユーザ利便性と低消費電力の両立を実現できる。

上述の例では、タッチパネルの操作を外部イベントとして扱ったが、これ以外にも、通信デバイスとは別のセンサーで得られるセンシング情報を用いることが可能である。たとえば、ボタンの押下頻度や、照度センサーにより検出する周囲の明るさの変化や、マイクにより検出する音の大きさや、バッテリ残量などを用いることが可能である。

（省電状態の使い分け）
これまでは、主に通信デバイス15の状態を、D0とD3の2状態に分けて説明を行ってきた。ここでは、D3状態の他に省電状態として、D1,D2を含め3つの省電状態を有する場合を考える。D1,D2,D3は通信が不可能であり、D1,D2,D3の順で、消費電力が小さくなり、D0への復帰時間が長くなる。

このような場合は、以下の動作が可能である。例えば、上述のD3の代わりにD1状態を用いて、D0とD1状態を用いて上述の動作を行う。D1状態でいる時間が予め定められた時間以上の場合に、D1からD2状態に移行する。さらにD0に復帰することなく予め定められた時間が経過した後に、D2からD3状態に移行する。これにより、頻繁に通信を行う場合には、D0への復帰時間を短くし、ユーザの待ち時間を低減可能である。

（その他）
本実施形態では、IPv4通信を行う場合を例に説明を行っているが、これに限らず、IPv6やX.25など様々なパケット通信にも、本実施形態は適用可能である。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

また、本実施例で示した通信デバイスの状態の制御や通信不可状態・通信可能状態の通知を、常に行うのではなく、例えば、表示デバイスの非表示状態の場合にのみ行ったり、あるいは、アプリケーションからOSへの要求があった場合にのみ行ったり、予め設定されたアプリケーションが起動している場合にのみ行ったりするなど、様々な変形が考えられる。

Claims

ネットワークと通信する通信デバイスと、
前記ネットワーク上の第1通信端末とコネクションを設定するコネクション処理部と、前記コネクション上でのセッションの開始および終了を検出する通信管理部と、
前記通信管理部の検出結果に応じて、前記通信デバイスへの給電を制御するデバイス電源管理部と、
を備え、
前記デバイス電源管理部は、前記セッションの開始が検出されたとき、前記通信デバイスを送受信可能な第1電源状態に設定し、前記セッションの終了が検出されたとき、前記通信デバイスを送信不能および受信不能のうちの少なくとも一方の第2電源状態に設定し、
前記セッションの終了が検出されて、前記通信デバイスが前記第2電源状態に設定されても前記セッションで利用されていたコネクションの設定を維持し、新たなセッションの開始が検出され、前記通信デバイスが前記第1電源状態に設定された後、前記設定されているコネクションを利用して、前記新たなセッションに関する通信を行い、
前記デバイス電源管理部は、前記セッションの開始が検出された後、さらに遅延許容時間が経過した後に、前記通信デバイスを前記第1電源状態に設定し、
前記遅延許容時間は、バッテリの残量が少ないほど大きな値に設定される
通信端末。
前記第2電源状態は、前記通信デバイスが少なくとも受信不能な状態であり
前記コネクション処理部は、前記セッションの終了が検出されたとき、前記通信デバイスが前記第2電源状態に設定される前に、前記コネクションでの受信は不可との受信不可通知を前記第1通信端末に送る
請求項1に記載の通信端末。
前記デバイス電源管理部が、前記通信デバイスを第1電源状態に設定した際、前記コネクションでの受信は可能との受信可能通知を前記第1通信端末に送る
請求項2に記載の通信端末。
さらに、表示デバイスを有し、
前記デバイス電源管理部は、前記表示デバイスが表示状態でない場合に、前記通信デバイスへの給電制御を行う請求項1に記載の通信端末。
ネットワークと通信する通信デバイスと、
前記ネットワーク上の第1通信端末とコネクションを設定するコネクション処理部と、前記コネクション上でのセッションの開始および終了を検出する通信管理部と、前記通信管理部の検出結果に応じて、前記通信デバイスへの給電を制御するデバイス電源管理部と、
を備え、
前記デバイス電源管理部は、前記セッションの開始が検出されたとき、前記通信デバイスを送受信可能な第1電源状態に設定し、前記セッションの終了が検出されたとき、前記通信デバイスを送信不能および受信不能のうちの少なくとも一方の第2電源状態に設定し、
前記セッションの終了が検出されて、前記通信デバイスが前記第2電源状態に設定されても前記セッションで利用されていたコネクションの設定を維持し、新たなセッションの開始が検出され、前記通信デバイスが前記第1電源状態に設定された後、前記設定されているコネクションを利用して、前記新たなセッションに関する通信を行い、
前記コネクション処理部と異なるプロトコルを処理するプロトコル処理部をさらに備え、
前記デバイス電源管理部は、前記通信デバイスが前記第2電源状態に設定された後、一定の周期ごとに、前記通信デバイスを前記第1電源状態に遷移させ、
前記プロトコル処理部は、前記通信デバイスが前記第1電源状態に遷移させられた後、前記プロトコルのパケット通信を行い、
前記デバイス電源管理部は、前記パケット通信が終了したら、または前記第1電源状態への遷移から一定時間が経過したら、前記通信デバイスを前記第2電源状態に戻す
通信端末。
ネットワークと通信する通信デバイスと、
前記ネットワーク上の第1通信端末とコネクションを設定するコネクション処理部と、前記コネクション上でのセッションの開始および終了を検出する通信管理部と、前記通信管理部の検出結果に応じて、前記通信デバイスへの給電を制御するデバイス電源管理部と、
を備え、
前記デバイス電源管理部は、前記セッションの開始が検出されたとき、前記通信デバイスを送受信可能な第1電源状態に設定し、前記セッションの終了が検出されたとき、前記通信デバイスを送信不能および受信不能のうちの少なくとも一方の第2電源状態に設定し、
前記セッションの終了が検出されて、前記通信デバイスが前記第2電源状態に設定されても前記セッションで利用されていたコネクションの設定を維持し、新たなセッションの開始が検出され、前記通信デバイスが前記第1電源状態に設定された後、前記設定されているコネクションを利用して、前記新たなセッションに関する通信を行い、
前記コネクション処理部と異なるプロトコルを処理するプロトコル処理部をさらに備え、
前記デバイス電源管理部は、前記通信デバイスが前記第2電源状態に設定されているとき、前記プロトコル処理部によるパケット通信要求を検出したら、前記通信デバイスを前記第1電源状態に遷移させ、
前記プロトコル処理部は、前記通信デバイスが前記第1電源状態に遷移された後、前記パケット通信を行い、
前記デバイス電源管理部は、前記パケット通信の終了後、または前記第1電源状態への遷移から一定時間が経過したら、前記通信デバイスを前記第2電源状態に戻す
通信端末。
前記デバイス電源管理部は、前記パケット通信要求を検出後、さらにあらかじめ定めた時間が経過したら、前記通信デバイスを前記第1電源状態に遷移させる
請求項6に記載の通信端末。
前記第2電源状態は、前記通信デバイスが少なくとも送信不能な状態であり
前記デバイス電源管理部は、前記通信デバイスが前記第2電源状態に設定された後、一定の周期ごとに、前記通信デバイスを少なくとも送信可能な第3電源状態に遷移させ、
前記プロトコル処理部は、前記通信デバイスが前記第3電源状態に遷移させられた後、前記通信デバイスのハードウエアアドレスとIPアドレスとを含む広告パケットを送信し、前記デバイス電源管理部は、前記広告パケットの送信が終了したら、または前記第1電源状態への遷移から一定時間が経過したら、前記通信デバイスを前記第2電源状態に戻す
請求項5ないし7のいずれか一項に記載の通信端末。
前記コネクションは、TCP、IPSEC、L2TP、PPTPまたはSPDYによるコネクションである
請求項1ないし8のいずれか一項に記載の通信端末。
ネットワークと通信する通信デバイスを用いた通信方法であって、
前記ネットワーク上の第1通信端末とコネクションを設定するコネクション設定ステップと、
前記コネクション上でのセッションの開始および終了を検出する検出ステップと、
前記検出ステップの検出結果に応じて、前記通信デバイスへの給電を制御し、前記セッションの開始が検出されたとき、前記通信デバイスを送受信可能な第1電源状態に設定し、前記セッションの終了が検出されたとき、前記通信デバイスを送信不能および受信不能のうちの少なくとも一方の第2電源状態に設定するデバイス電源状態管理ステップと、
前記セッションの終了が検出されて、前記通信デバイスが前記第2電源状態に設定されても前記セッションで利用されていたコネクションの設定を維持し、新たなセッションの開始が検出され、前記通信デバイスが前記第1電源状態に設定された後、前記設定されているコネクションを利用して、前記新たなセッションに関する通信を行うステップと、を備え、
前記デバイス電源管理ステップは、前記セッションの開始が検出された後、さらに遅延許容時間が経過した後に、前記通信デバイスを前記第1電源状態に設定し、
前記遅延許容時間は、バッテリの残量が少ないほど大きな値に設定される
を備えた通信方法。
ネットワークと通信する通信デバイスを用いた通信プログラムであって、
前記ネットワーク上の第1通信端末とコネクションを設定するコネクション設定ステップと、
前記コネクション上でのセッションの開始および終了を検出する検出ステップと、
前記検出ステップの検出結果に応じて、前記通信デバイスへの給電を制御し、前記セッションの開始が検出されたとき、前記通信デバイスを送受信可能な第1電源状態に設定し、前記セッションの終了が検出されたとき、前記通信デバイスを送信不能および受信不能のうちの少なくとも一方の第2電源状態に設定するデバイス電源状態管理ステップと、
前記セッションの終了が検出されて、前記通信デバイスが前記第2電源状態に設定されても前記セッションで利用されていたコネクションの設定を維持し、新たなセッションの開始が検出され、前記通信デバイスが前記第1電源状態に設定された後、前記設定されているコネクションを利用して、前記新たなセッションに関する通信を行うステップと
をコンピュータに実行させ、
前記デバイス電源管理ステップは、前記セッションの開始が検出された後、さらに遅延許容時間が経過した後に、前記通信デバイスを前記第1電源状態に設定し、
前記遅延許容時間は、バッテリの残量が少ないほど大きな値に設定される
通信プログラム。
ネットワークと通信する通信デバイスと、
前記ネットワーク上の第1通信端末とコネクションを設定するコネクション処理部と、前記コネクション上でのセッションの開始および終了を検出する通信管理部と、
前記通信管理部の検出結果に応じて、前記通信デバイスへの給電を制御するデバイス電源管理部と、
を備え、
前記デバイス電源管理部は、前記セッションの開始が検出されたとき、前記通信デバイスを送受信可能な第1電源状態に設定し、前記セッションの終了が検出されたとき、前記通信デバイスを送信不能および受信不能のうちの少なくとも一方の第2電源状態に設定し、
前記デバイス電源管理部は、前記セッションの開始が検出された後、さらに遅延許容時間が経過した後に、前記通信デバイスを前記第1電源状態に設定し、
前記遅延許容時間は、バッテリの残量が少ないほど大きな値に設定される
通信端末。
ネットワークと通信する通信デバイスと、
前記ネットワーク上の第1通信端末とコネクションを設定するコネクション処理部と、前記コネクション上でのセッションの開始および終了を検出する通信管理部と、
前記通信管理部の検出結果に応じて、前記通信デバイスへの給電を制御するデバイス電源管理部と、
前記コネクション処理部と異なるプロトコルを処理するプロトコル処理部と、
を備え、
前記デバイス電源管理部は、前記セッションの開始が検出されたとき、前記通信デバイスを送受信可能な第1電源状態に設定し、前記セッションの終了が検出されたとき、前記通信デバイスを送信不能および受信不能のうちの少なくとも一方の第2電源状態に設定し、
前記デバイス電源管理部は、前記通信デバイスが前記第2電源状態に設定された後、一定の周期ごとに、前記通信デバイスを前記第1電源状態に遷移させ、
前記プロトコル処理部は、前記通信デバイスが前記第1電源状態に遷移させられた後、前記プロトコルのパケット通信を行い、
前記デバイス電源管理部は、前記パケット通信が終了したら、または前記第1電源状態への遷移から一定時間が経過したら、前記通信デバイスを前記第2電源状態に戻す
通信端末。
ネットワークと通信する通信デバイスと、
前記ネットワーク上の第1通信端末とコネクションを設定するコネクション処理部と、前記コネクション上でのセッションの開始および終了を検出する通信管理部と、
前記通信管理部の検出結果に応じて、前記通信デバイスへの給電を制御するデバイス電源管理部と、
前記コネクション処理部と異なるプロトコルを処理するプロトコル処理部と、
を備え、
前記デバイス電源管理部は、前記セッションの開始が検出されたとき、前記通信デバイスを送受信可能な第1電源状態に設定し、前記セッションの終了が検出されたとき、前記通信デバイスを送信不能および受信不能のうちの少なくとも一方の第2電源状態に設定し、
前記デバイス電源管理部は、前記通信デバイスが前記第2電源状態に設定されているとき、前記プロトコル処理部によるパケット通信要求を検出したら、前記通信デバイスを前記第1電源状態に遷移させ、
前記プロトコル処理部は、前記通信デバイスが前記第1電源状態に遷移された後、前記パケット通信を行い、
前記デバイス電源管理部は、前記パケット通信の終了後、または前記第1電源状態への遷移から一定時間が経過したら、前記通信デバイスを前記第2電源状態に戻す
通信端末。
ネットワークと通信する通信デバイスを用いた通信方法であって、
前記ネットワーク上の第1通信端末とコネクションを設定するコネクション設定ステップと、
前記コネクション上でのセッションの開始および終了を検出する検出ステップと、
前記検出ステップの検出結果に応じて、前記通信デバイスへの給電を制御し、前記セッションの開始が検出されたとき、前記通信デバイスを送受信可能な第1電源状態に設定し、前記セッションの終了が検出されたとき、前記通信デバイスを送信不能および受信不能のうちの少なくとも一方の第2電源状態に設定するデバイス電源状態管理ステップと、
前記セッションの開始が検出された後、さらに遅延許容時間が経過した後に、前記通信デバイスを前記第1電源状態に設定し、前記遅延許容時間は、バッテリの残量が少ないほど大きな値に設定されるステップと
を備えた通信方法。
ネットワークと通信する通信デバイスを用いた通信方法であって、
前記ネットワーク上の第1通信端末とコネクションを設定するコネクション設定ステップと、
前記コネクション上でのセッションの開始および終了を検出する検出ステップと、
前記検出ステップの検出結果に応じて、前記通信デバイスへの給電を制御するデバイス電源状態管理ステップと、
前記コネクション設定ステップと異なるプロトコルを処理するプロトコル処理ステップと、
を備え、
前記デバイス電源状態管理ステップは、前記セッションの開始が検出されたとき、前記通信デバイスを送受信可能な第1電源状態に設定し、前記セッションの終了が検出されたとき、前記通信デバイスを送信不能および受信不能のうちの少なくとも一方の第2電源状態に設定し、
前記デバイス電源状態管理ステップは、前記通信デバイスが前記第2電源状態に設定された後、一定の周期ごとに、前記通信デバイスを前記第1電源状態に遷移させ、
前記プロトコル処理ステップは、前記通信デバイスが前記第1電源状態に遷移させられた後、前記プロトコルのパケット通信を行い、
前記デバイス電源状態管理ステップは、前記パケット通信が終了したら、または前記第1電源状態への遷移から一定時間が経過したら、前記通信デバイスを前記第2電源状態に戻す
通信方法。
ネットワークと通信する通信デバイスを用いた通信方法であって、
前記ネットワーク上の第1通信端末とコネクションを設定するコネクション設定ステップと、
前記コネクション上でのセッションの開始および終了を検出する検出ステップと、
前記検出ステップの検出結果に応じて、前記通信デバイスへの給電を制御するデバイス電源状態管理ステップと、
前記コネクション設定ステップと異なるプロトコルを処理するプロトコル処理ステップと、
を備え、
前記デバイス電源状態管理ステップは、前記セッションの開始が検出されたとき、前記通信デバイスを送受信可能な第1電源状態に設定し、前記セッションの終了が検出されたとき、前記通信デバイスを送信不能および受信不能のうちの少なくとも一方の第2電源状態に設定し、
前記デバイス電源状態管理ステップは、前記通信デバイスが前記第2電源状態に設定されているとき、前記プロトコル処理ステップによるパケット通信要求を検出したら、前記通信デバイスを前記第1電源状態に遷移させ、
前記プロトコル処理ステップは、前記通信デバイスが前記第1電源状態に遷移された後、前記パケット通信を行い、
前記デバイス電源状態管理ステップは、前記パケット通信の終了後、または前記第1電源状態への遷移から一定時間が経過したら、前記通信デバイスを前記第2電源状態に戻す
通信方法。
ネットワークと通信する通信デバイスを用いた通信プログラムであって、
前記ネットワーク上の第1通信端末とコネクションを設定するコネクション設定ステップと、
前記コネクション上でのセッションの開始および終了を検出する検出ステップと、
前記検出ステップの検出結果に応じて、前記通信デバイスへの給電を制御し、前記セッションの開始が検出されたとき、前記通信デバイスを送受信可能な第1電源状態に設定し、前記セッションの終了が検出されたとき、前記通信デバイスを送信不能および受信不能のうちの少なくとも一方の第2電源状態に設定するデバイス電源状態管理ステップと、
前記セッションの開始が検出された後、さらに遅延許容時間が経過した後に、前記通信デバイスを前記第1電源状態に設定し、前記遅延許容時間は、バッテリの残量が少ないほど大きな値に設定されるステップと
をコンピュータに実行させるための通信プログラム。
ネットワークと通信する通信デバイスを用いた通信プログラムであって、
前記ネットワーク上の第1通信端末とコネクションを設定するコネクション設定ステップと、
前記コネクション上でのセッションの開始および終了を検出する検出ステップと、
前記検出ステップの検出結果に応じて、前記通信デバイスへの給電を制御するデバイス電源状態管理ステップと、
前記コネクション設定ステップと異なるプロトコルを処理するプロトコル処理ステップと、
をコンピュータに実行させ、
前記デバイス電源状態管理ステップは、前記セッションの開始が検出されたとき、前記通信デバイスを送受信可能な第1電源状態に設定し、前記セッションの終了が検出されたとき、前記通信デバイスを送信不能および受信不能のうちの少なくとも一方の第2電源状態に設定し、
前記デバイス電源状態管理ステップは、前記通信デバイスが前記第2電源状態に設定された後、一定の周期ごとに、前記通信デバイスを前記第1電源状態に遷移させ、
前記プロトコル処理ステップは、前記通信デバイスが前記第1電源状態に遷移させられた後、前記プロトコルのパケット通信を行い、
前記デバイス電源状態管理ステップは、前記パケット通信が終了したら、または前記第1電源状態への遷移から一定時間が経過したら、前記通信デバイスを前記第2電源状態に戻す
通信プログラム。
ネットワークと通信する通信デバイスを用いた通信プログラムであって、
前記ネットワーク上の第1通信端末とコネクションを設定するコネクション設定ステップと、
前記コネクション上でのセッションの開始および終了を検出する検出ステップと、
前記検出ステップの検出結果に応じて、前記通信デバイスへの給電を制御するデバイス電源状態管理ステップと、
前記コネクション設定ステップと異なるプロトコルを処理するプロトコル処理ステップと、
をコンピュータに実行させ、
前記デバイス電源状態管理ステップは、前記セッションの開始が検出されたとき、前記通信デバイスを送受信可能な第1電源状態に設定し、前記セッションの終了が検出されたとき、前記通信デバイスを送信不能および受信不能のうちの少なくとも一方の第2電源状態に設定し、
前記デバイス電源状態管理ステップは、前記通信デバイスが前記第2電源状態に設定されているとき、前記プロトコル処理ステップによるパケット通信要求を検出したら、前記通信デバイスを前記第1電源状態に遷移させ、
前記プロトコル処理ステップは、前記通信デバイスが前記第1電源状態に遷移された後、前記パケット通信を行い、
前記デバイス電源状態管理ステップは、前記パケット通信の終了後、または前記第1電源状態への遷移から一定時間が経過したら、前記通信デバイスを前記第2電源状態に戻す
通信プログラム。