(57)【要約】【課題】プロセッサの消費電力を効率的に抑制することのできる通信装置を提供する。【解決手段】消費電力の少ないスリープ状態へと遷移可能な第１プロセッサとは別のネットワークを通じた情報取得にかかる処理を実行する第２プロセッサを備え、前記第２プロセッサは、前記第１プロセッサにおいて指定された前記ネットワークの接続先を示す第１情報に基づいて、前記接続先との間で通信を行うとともに、前記第１プロセッサを前記スリープ状態へと遷移させる通知を行うネットワーク処理部と、前記第１情報と関連付けられた第２情報を取得する情報取得部と、前記情報取得部が前記第１プロセッサにより指定された前記第１情報と関連付けられた全ての前記第２情報の取得を完了したことを契機に、前記第１プロセッサを前記スリープ状態から動作状態へと復帰させる起動制御部と、を備える。【選択図】図１
2014102710.tif 000002
【特許請求の範囲】
【請求項１】
消費電力の少ないスリープ状態へと遷移可能な第１プロセッサとは別のネットワークを通じた情報取得にかかる処理を実行する第２プロセッサを備え、
前記第２プロセッサは、
前記第１プロセッサにおいて指定された前記ネットワークの接続先を示す第１情報に基づいて、前記接続先との間で通信を行うとともに、前記第１プロセッサを前記スリープ状態へと遷移させる通知を行うネットワーク処理部と、
前記第１情報と関連付けられた第２情報を取得する情報取得部と、
前記情報取得部が前記第１プロセッサにより指定された前記第１情報と関連付けられた全ての前記第２情報の取得を完了したことを契機に、前記第１プロセッサを前記スリープ状態から動作状態へと復帰させる起動制御部と、
を備えることを特徴とする通信装置。
【請求項２】
前記第２プロセッサは、
前記第１情報に基づき、前記情報取得部が前記第２情報を取得するために要する取得時間を算出する時間算出部、
を更に備え、
前記起動制御部は、前記取得時間に基づき、前記第１プロセッサが前記スリープ状態である期間を定めるスリープ時間を設定し、前記第１プロセッサを前記スリープ状態へと遷移させる通知とともに前記第１プロセッサへと通知する
ことを特徴とする請求項１に記載の通信装置。
【請求項３】
前記第１プロセッサを更に備え、
前記第１プロセッサは、
前記ネットワークを通じて通信を行うアプリケーションから通知された前記第１情報を前記第２プロセッサに対して転送する転送部を備え、
前記ネットワーク処理部は、転送された前記第１情報に基づいて、前記接続先との間で通信を行うとともに、前記第１情報を受信した際に前記第１プロセッサを前記スリープ状態へと遷移させる通知を行う
ことを特徴とする請求項２に記載の通信装置。
【請求項４】
前記第１プロセッサは、
前記第１プロセッサを前記スリープ状態へと遷移させる通知を受信した際に前記第１プロセッサを前記スリープ状態へと遷移させるとともに、前記スリープ状態への遷移から前記スリープ時間経過後に、前記第１プロセッサを起動させるスリープ制御部、
を更に備える
ことを特徴とする請求項３に記載の通信装置。
【請求項５】
前記スリープ制御部は、通知された前記スリープ時間から、前記スリープ状態から前記動作状態へと前記第１プロセッサが遷移するために要する遷移時間以上の値を減算して、第２スリープ時間を算出し、前記スリープ状態への遷移から前記第２スリープ時間経過後には、前記スリープ状態より、前記動作状態への復帰に要する時間が少ない別のスリープ状態へと前記第１プロセッサを遷移させる
ことを特徴とする請求項４に記載の通信装置。
【請求項６】
前記起動制御部は、前記スリープ状態から前記動作状態へと前記第１プロセッサが遷移するために要する遷移時間以上の値を減算して、第２スリープ時間を算出して、前記スリープ時間、及び前記第２スリープ時間を前記第１プロセッサへと通知し、
前記スリープ制御部は、前記スリープ状態への遷移から前記第２スリープ時間経過後には、前記スリープ状態より、前記動作状態への復帰に要する時間が少ない別のスリープ状態へと前記第１プロセッサを遷移させる
ことを特徴とする請求項４に記載の通信装置。
【請求項７】
装置へと電力を供給する電源部を更に備え、
前記スリープ制御部は、前記電源部が発電する発電量、又は前記電源部に残存する蓄電量が多いほど、前記第２スリープ時間を短く算出する
ことを特徴とする請求項５に記載の通信装置。
【請求項８】
装置へと電力を供給する電源部を更に備え、
前記起動制御部は、前記電源部が発電する発電量、又は前記電源部に残存する蓄電量が多いほど、前記第２スリープ時間を短く算出する
ことを特徴とする請求項６に記載の通信装置。
【請求項９】
前記起動制御部は、前記第１情報と関連付けられた前記第２情報のうち、まだ取得が完了していない残存情報の取得に要すると予想される時間が、前記スリープ状態から前記動作状態へと前記第１プロセッサが遷移するために要する遷移時間よりも短くなった場合に、前記第１プロセッサを前記スリープ状態から動作状態へと復帰させる
ことを特徴とする請求項１に記載の通信装置。
【請求項１０】
消費電力の少ないスリープ状態へと遷移可能な第１プロセッサと、ネットワークを通じた情報取得にかかる処理を実行する第２プロセッサと、を備えた通信装置で実行される通信方法であって、
前記第１プロセッサが、アプリケーションから通知された情報を取得したい接続先を示す前記第１情報を前記第２プロセッサに対して、転送する転送ステップと、
前記第２プロセッサが、前記第１プロセッサにおいて指定された前記ネットワークの接続先を示す第１情報に基づいて、前記接続先との間で通信を行うとともに、前記第１プロセッサを前記スリープ状態へと遷移させる通知を行うネットワーク処理ステップと、
前記第２プロセッサが、前記第１情報と関連付けられた第２情報を取得する情報取得ステップと、
前記第２プロセッサが、前記情報取得部が前記第１プロセッサにより指定された前記第１情報と関連付けられた全ての前記第２情報の取得を完了したことを契機に、前記第１プロセッサを前記スリープ状態から動作状態へと復帰させる起動制御ステップと、
を含むことを特徴とする通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、通信装置、及びその方法に関する。
【背景技術】
【０００２】
従来、ネットワークを利用して通信を行う通信装置において、主たるプロセッサとは別に、通信に関する処理を専用に行う別のプロセッサを設ける技術が知られている。例えば、通信要求に基づいて、ネットワーク専用のプロセッサに対して割り当てる処理を特定し、該当する処理である場合にはその処理を専用プロセッサで実行し、それ以外の処理を主たるプロセッサにおいて実行する通信システムがある。このような通信装置にあっては、主たるプロセッサの演算負荷を低減し、また処理の高速化を図ることができる。
【０００３】
また、主たるプロセッサがネットワークを通じて取得要求した情報を、要求の事前に取得する技術が開示されている。例えば、ウェブページにデータの取得要求を出す情報端末と、ウェブサーバとの間を仲介するプロキシサーバを備えており、情報端末が要求すると判断した情報をプロキシサーバが事前に取得する技術がある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６―２９４０２７号公報
【特許文献２】特開２００５―５６０９６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記のように複数のプロセッサを設ける通信装置にあっては、プロセッサの数が多くなればなるほど、消費電力量も増大することとなる。そこで、各プロセッサが処理を実行していない際は、プロセッサの消費電力を抑制することが求められていた。
【０００６】
本発明の実施形態は、上記に鑑みてなされたものであって、プロセッサの消費電力を効率的に抑制することのできる通信装置を提供することにある。
【課題を解決するための手段】
【０００７】
上述した課題を解決し、目的を達成するために、本発明の実施形態は、消費電力の少ないスリープ状態へと遷移可能な第１プロセッサとは別のネットワークを通じた情報取得にかかる処理を実行する第２プロセッサを備え、前記第２プロセッサは、前記第１プロセッサにおいて指定された前記ネットワークの接続先を示す第１情報に基づいて、前記接続先との間で通信を行うとともに、前記第１プロセッサを前記スリープ状態へと遷移させる通知を行うネットワーク処理部と、前記第１情報と関連付けられた第２情報を取得する情報取得部と、前記情報取得部が前記第１プロセッサにより指定された前記第１情報と関連付けられた全ての前記第２情報の取得を完了したことを契機に、前記第１プロセッサを前記スリープ状態から動作状態へと復帰させる起動制御部と、を備えることを特徴とする。
【図面の簡単な説明】
【０００８】
【図１】図１は、第１の実施形態の通信装置の機能構成を示すブロック図。
【図２】図２は、第１の実施形態の通信装置の詳細な機能構成を示すブロック図。
【図３】図３は、第１の実施形態の通信装置における対応表のデータ構造を示す図。
【図４】図４は、第１の実施形態の第１プロセッサにおける処理の流れを示すフロー図。
【図５】図５は、第１の実施形態の第２プロセッサにおける処理の流れを示すフロー図。
【図６−１】図６−１は、第１の実施形態の情報取得処理の流れを示すフロー図。
【図６−２】図６−２は、第１の実施形態の情報取得処理の流れを示すフロー図。
【図７】図７は、第１の実施形態の第１プロセッサの電力状態遷移と消費電力の関係を示すタイミングチャート。
【図８】図８は、第２の実施形態の通信装置の詳細な機能構成を示すブロック図。
【図９】図９は、第２の実施形態の情報取得処理の流れを示すフロー図。
【図１０】図１０は、第２の実施形態の第１プロセッサの電力状態遷移と消費電力の関係を示すタイミングチャート。
【図１１】図１１は、第３の実施形態の第１プロセッサの電力状態遷移と消費電力の関係を示すタイミングチャート。
【図１２】図１２は、第３の実施形態の第１プロセッサの電力状態遷移と消費電力の関係を示すタイミングチャート。
【図１３】図１３は、第３の実施形態の通信装置の詳細な機能構成を示すブロック図。
【図１４】図１４は、第４の実施形態の通信装置の詳細な機能構成を示すブロック図。
【図１５】図１５は、第５の実施形態の復帰信号の送信タイミングを決定する処理の流れを示すフロー図。
【図１６】図１６は、実施形態の追加取得リストを説明する図。
【発明を実施するための形態】
【０００９】
以下に、本発明の第１の実施形態にかかる通信装置を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。なお、以下ではＨＴＴＰのプロトコルを用いてＷＥＢサーバ２００と通信する場合について記すが、通信プロトコルならびに通信相手を制限するものではない。
（第１実施形態）
【００１０】
図１は本実施形態における通信装置１００のハードウェア構成、及び機能ブロックを示す図である。図１に示されるように、通信装置１００は、第１プロセッサ１１０、第２プロセッサ１２０、及び記憶部１３０をハードウェアとして備えている。第１プロセッサ１１０は、主に通信装置１００の全体的な処理を行うプロセッサであり、ＣＰＵなどにより構成されている。第１プロセッサ１１０は、複数の電力状態を有しており、例えば通常の電力が供給される動作状態と、一部の電力供給が停止され省電力状態となっているスリープ状態とがある。第２プロセッサ１２０は、ネットワークを通じた情報通信に係る処理を行う専用のプロセッサである。記憶部１３０は、例えばハードディスクドライブやＳＳＤ（Solid  State  Drive）、ＮＡＮＤフラッシュ、ランダムアクセスメモリ（ＲＡＭ）などにより構成された記憶領域である。記憶部１３０は、その保存するデータの性質に合わせて第１記憶部１３１と、第２記憶部１３２を備えている。第１記憶部１３１は、主にＷＥＢサーバ２００から取得した情報など、ある程度データ容量のある情報を記憶し、読み書き可能な記憶領域である。第２記憶部１３２は、短期的かつ比較的少量の情報を保持する際に使用する。
【００１１】
第２プロセッサ１２０は、ネットワーク処理部１０１、情報取得部１０２、及び起動制御部１０５の各機能を実行する。これらの各部は通常は、例えばハードウェアなどの記憶部１３０に記憶されているが、ＣＰＵである第２プロセッサ１２０が読み出して、メモリ上に各機能が実行されることにより実現されている。なお、各部をソフトウェアではなくハードウェアによって実現してもよい。ネットワーク処理部１０１は、ＴＣＰ／ＩＰを始めとする通信プロトコルの処理を第１プロセッサ１１０に代わって実行する。ネットワーク処理部１０１は、第１プロセッサ１１０からの情報取得要求を受け付けると、情報取得部１０２に対して、要求を転送する。
【００１２】
情報取得部１０２は、ネットワーク処理部1０１からの情報取得要求を受け取り、ネットワークを介してＷＥＢサーバ２００に保存されているウェブページを取得し、解析し、必要であれば更なる情報を取得する。本実施形態においては、第１情報がＵＲＬに相当し、ＵＲＬで指定されるウェブページに含まれる画像データや、スクリプトなどの埋め込みオブジェクトが第２情報に相当する。情報取得部１０２は、ＷＥＢサーバ２００から取得した情報を第１記憶部１３１に記憶する。起動制御部１０５は、第１プロセッサ１１０の電力状態を制御する。
【００１３】
図２は第１プロセッサ１１０、及び第２プロセッサ１２０の各機能を詳細化したブロック図である。第１プロセッサ１１０上では、アプリケーション４００とカーネル４１０が動作している。カーネル４１０は内部に判断部４０２、対応表４０３、及び転送部４０４を備えている。アプリケーション４００とカーネル４１０内の各部は、一般的なアプリケーションと同様にソケット４０１を用いて接続されている。
【００１４】
アプリケーション４００は第１プロセッサ１１０の上で動作し、ネットワークを介して情報を取得する機能を備えたソフトウェアである。例えば、ウェブブラウザが相当する。カーネル４１０は、アプリケーション４００が動作するために必要な各種機能を提供するＯＳ（Operating  System）を構成するソフトウェアである。一般的にはネットワーク処理もカーネル４１０に実装されているが、本実施形態ではネットワーク処理部１０１に実装されている。ソケット４０１は、アプリケーション４００とカーネル４１０との間でデータや処理命令を送受信する。一般のソケット４０１は、アプリケーション４０１とＴＣＰ/IＰなどのネットワーク処理をつなぐが、本実施形態ではカーネル４１０内にネットワーク処理を持たないため、ネットワーク処理部１０１と通信するための各機能に接続する。
【００１５】
ある情報の取得状況は、例えば、最初の第１プロセッサ１１０からの情報取得要求に対する応答と共にネットワーク処理部１０１から第１プロセッサ１１０側に通知される。他にも第１プロセッサ１１０が動作状態にあるときに随時通知するようにしてもよい。いずれの方法であっても、この通知を受け取った転送部４０４は、ソケット４０１と関連づけて対応表４０３に保存する。その結果、判断部４０２が埋め込みオブジェクトに対する要求を受け取った場合には、対応表４０３のエントリを参照することで、対象となる埋め込みオブジェクトが第１記憶部１３１に蓄積済みであるか否かを把握できる。そして、判断部４０２がその状況に基づいて要求を情報取得部１０２に転送するか第１記憶部１３１から情報を取得するかを判断する。
【００１６】
図３に対応表４０３の一例を示す。この表は、４つの情報（第１プロセッサ１１０側の識別子、第２プロセッサ１２０側の識別子、状態、第２プロセッサ１２０側での処理）を保持している。以下、各エントリについて説明する。
【００１７】
エントリ１２０１は、各ＷＥＢサーバ２００との通信が確立済みの接続に関するエントリである。状態が「ＴＣＰ接続済み」となっており、既に通信が出来る状態であることを示す。また、第２プロセッサ１２０における処理が「第１記憶部１３１から取得」となっており、既に情報取得部１０２における処理が終了し、最初の情報取得要求に対する応答を第２プロセッサ１２０から第１プロセッサ１１０へと返信した状態である。
【００１８】
エントリ１２０２は、ＷＥＢサーバ２００との間で通信が確立済みの接続に関するもう一つの例である。状態はエントリ１２０１と同様に「ＴＣＰ接続済み」であるが、第２プロセッサ１２０での処理が「情報取得部１０２に転送」となっている。このエントリに対応する通信は、接続が確立された直後であり、今後発生する第１プロセッサ１１０からの最初の情報取得要求にしたがって事前一括取得の処理を行う必要があることを示している。
【００１９】
エントリ１２０３は、ＷＥＢサーバ２００との通信を確立準備中の例である。状態は「ＴＣＰ接続処理中」となっており、ＷＥＢサーバ２００との間のＴＣＰ接続を準備している段階であることを示している。この状態では第２プロセッサ１２０における処理は発生しないため、処理の欄は空欄としている。
【００２０】
エントリ１２０４は、第１プロセッサ１２０と第２プロセッサ１２０との間での通信に必要な接続を準備している段階の例である。第１プロセッサ１１０側では識別子が割り当てられており、第１プロセッサ１１０から識別子を第２プロセッサ１２０に転送し、識別子の割り当てを要求している状態のため、第２プロセッサ１２０側の識別子の欄も空欄となっている。
【００２１】
転送部４０４は、判断部４０２が行った判断結果に基づいて、ネットワーク処理部１０１との間で情報を転送する。転送の際にはソケット４０１を介して受け取った情報に対して適切な処理を行う。例えば、判断結果に由来するネットワーク処理部１０１における識別子などの付与、フォーマット（情報の表現方法）の変更、一度に送受信するデータサイズの変更などである。同様の処理はネットワーク処理部１０１から受信したデータに対しても行い、適切な形にしたうえでソケット４０１に返す。転送部４０４とネットワーク処理部１０１との間で交換する情報は、原則としてＴＣＰ／ＩＰヘッダを含まないデータの部分と、ネットワーク処理に必要なヘッダのみである。
【００２２】
以上で示した、第１プロセッサ１１０における各部位が行う詳細な処理の流れを図４を用いて説明する。図４は、第１プロセッサ１１０における通信処理の流れを示すフロー図である。図４に示されるように、まず通信のためのソケット４０１が生成されると、生成されたソケット４０１が新たなソケット４０１であるか否かが判定される（ステップＳ５０１）。新規のソケット４０１でないと判定された場合（ステップＳ５０１：Ｎｏ）、判断部４０２は、対応表４０３にソケット４０１から送られた識別子に基づき、対応するエントリがあるか否かを判定する（ステップＳ５０２）。
【００２３】
対応するエントリがないと判定された場合（ステップＳ５０２：Ｎｏ）、判断部４０２は、エラー応答通知を生成して、アプリケーション４００に送信し、処理を終了する（ステップＳ５１６）。一方、対応するエントリがあると判定された場合（ステップＳ５０２：Ｙｅｓ）、転送部４０４は、対応表４０３のエントリから情報を抽出する（ステップＳ５０３）。次いで、転送部４０４は、抽出した情報に基づいてネットワーク処理部１０１へと転送する（ステップＳ５０４）。転送部４０４は、変換した情報をネットワーク処理部１０１へと送信する（ステップＳ５０５）。送信後は、転送部４０４は、ネットワーク処理部１０１からの応答を受信するまで待機する（ステップＳ５０６）。なお、この際、ネットワーク処理部１０１からスリープ許可が受信された場合は、転送部４０４は、所定の時間までスリープ状態となってもよい。待機状態は、ネットワーク処理部１０１からの応答を受信するまで継続し（ステップＳ５０７：Ｎｏ）、応答を受信すると（ステップＳ５０７：Ｙｅｓ）、転送部４０４は、受信した応答をソケット４０１に対応した形に変換する（ステップＳ５０８）。そして、転送部４０４は、ソケット４０１に応答を送信し、処理を終了する（ステップＳ５０９）。
【００２４】
ステップＳ５０１へと戻り、ソケット４０１が新規のソケットであると判定された場合（ステップＳ５０１：Ｙｅｓ）、判断部４０２は、対応表４０３にエントリ追加のための領域を確保する（ステップＳ５１０）。次いで、転送部４０４は、ネットワーク処理部１０１に対して、ソケット４０１の作成要求を送信する（ステップＳ５１１）。送信後は、転送部４０４は、ネットワーク処理部１０１からの応答を受信するまで待機する（ステップＳ５１２）。待機状態は、ネットワーク処理部１０１からの応答を受信するまで継続し（ステップＳ５１２：Ｎｏ）、応答を受信すると（ステップＳ５１２：Ｙｅｓ）、転送部４０４は、通知された情報に基づいて対応表４０３を更新する（ステップＳ５１４）。そして、転送部４０４は、成功応答をソケット４０１からアプリケーション４００へと返信する（ステップＳ５１５）。
【００２５】
一般のネットワークアプリケーションではソケットＡＰＩと呼ばれる手段を使ってネットワークを介した情報のやり取りを行う。主なソケットＡＰＩとして外部との通信路を確立するconnect()、情報を送信するsend()、情報を受信するrecv()などがある。アプリケーション４００がconnect()を実行した際には、図４のステップＳ５１０〜Ｓ５１５の処理が実行される。send()やrecv()を実行した際にはステップＳ５０２〜Ｓ５０９の処理が実行される。
【００２６】
send()を実行した場合には第１プロセッサ１１０からネットワーク処理部１０１に情報を送信して、情報取得部１０２に渡したり、直接ＴＣＰ／ＩＰスタック４０６を用いてネットワークに送信したりする。この処理の判断は判断部４０２にて行う。recv()を実行した場合の判断は、同じソケット４０１を使ったsend()の実行が情報取得部１０２に渡された場合には情報取得部１０２から情報を読み込むものと判断される。この時、第１記憶部１３１に情報が蓄積されているかどうかは問題にならない。保存されている時には直ちに読み出されて処理が終了し、そうでない場合にはブロッキング・ノンブロッキングの別に従って情報が蓄積されるまで待機する、又は情報無しを示す応答が返され、直ちに処理を終了する。それ以外はＴＣＰ／ＩＰスタック１０６に渡して処理をする。
【００２７】
続いて、図２に戻り第２プロセッサ１２０側の機能構成について詳細に説明する。ネットワーク処理部１０１は処理部４０５とＴＣＰ／ＩＰスタック４０６を備えている。処理部４０５は第１プロセッサ１１０上で動作する転送部４０４との間で情報の送受信を行う。処理部４０５は、転送部４０４と同様に、受信した要求に付与されていた識別子情報に基づいて処理を決定する。例えば、第１記憶部１３１から対応するデータを取得したり、情報取得部１０２に要求を転送して取得要求のあった情報を一括取得する処理を実行させたり、ＴＣＰ／ＩＰスタック４０６に要求を転送して直接外部と通信をしたりする。
【００２８】
ＴＣＰ／ＩＰスタック４０６で行う通信を識別するための識別子は、処理部４０５と転送部４０４を介して対応表４０３のエントリとして保存されている。なお、本実施形態では対応表４０３を第１プロセッサ１１０の側にだけ持たせる方法で説明しているが、処理部４０５で持つようにしてもよいし、双方で分担して持たせるようにしてもよい。
【００２９】
以下、第２プロセッサ１２０側での各部の処理の流れを図５を用いて説明する。まず、第２プロセッサ１２０では、第１プロセッサ１１０から取得要求を受信するごとに以下の処理が行われる。取得要求を受信すると、処理部４０５は、受信した取得処理に含まれているヘッダ情報を参照して解析する（ステップＳ６０１）。処理部４０５は、ヘッダの内容からどのような処理を行うべきかを判定する（ステップＳ６０２）。
【００３０】
処理部４０５は、受信した要求が、第１記憶部１３１から対応するデータを取得するものだった場合、取得要求から対象とするＵＲＬを抽出する（ステップＳ６０３）。そして、処理部４０５は、抽出したＵＲＬをキーにして第１記憶部１３１を検索する（ステップＳ６０４）。処理部４０５は、検索に一致する蓄積情報が見つかるか否かを判定する（ステップＳ６０５）。一致する蓄積情報があった場合（ステップＳ６０５：Ｙｅｓ）、処理部４０５は、蓄積情報から該当する埋め込みオブジェクトを抽出する（ステップＳ６０５）。埋め込みオブジェクトは、あるＵＲＬで特定されるＨＴＭＬファイルに対して埋め込まれている画像ファイルなどである。そして、処理部４０５は、取得要求への応答を生成する（ステップＳ６０７）。
【００３１】
一方、一致する蓄積情報が見つからない場合は（ステップＳ６０５：Ｎｏ）、処理部４０５は、エラー応答を生成する（ステップＳ６０９）。そして、処理部４０５は、生成した各応答を転送部４０４へと送信し、処理を終了する（ステップＳ６０８）。生成された各応答は、トランスポート層とネットワーク層の処理から独立したものである。すなわち、ネットワーク処理が第２プロセッサ１２０で実施されている場合、実データと、第２プロセッサ１２０側で取得するデータのデータ容量や個別に取得する必要のあるデータの一覧を把握するために必要なヘッダ情報が応答として返される。
【００３２】
また、このとき必要なアプリケーション層のヘッダ情報（ＨＴＴＰヘッダなど）は処理部４０５が適切に生成してもよいし、情報取得部１０２がＷＥＢサーバ２００から取得した際のヘッダ情報をそのまま用いてもよい。また、その際に一部を改変して用いてもよい。
【００３３】
ステップＳ６０２の判定に戻り、処理部４０５で受信した要求が、ＴＣＰ／ＩＰスタック４０６を使用して直接通信を行うものだった場合、処理部４０５は、受信した要求からＴＣＰ／ＩＰスタックに通知するデータ部分を抽出する（ステップＳ６１０）。次いで処理部４０５は、抽出したデータ部分をＴＣＰ／ＩＰスタック４０６へと通知する（ステップＳ６１１）。ＴＣＰ／ＩＰスタック４０６は、対応するソケットを用いた処理を行う（ステップＳ６１２）。処理完了後、処理部４０５は、ＴＣＰ／ＩＰスタック４０６から処理結果を受け取り、それを適切な形式に変換し、最後に処理部４０５と転送部４０４との間での情報交換に必要なヘッダ情報を付加して応答として生成する（ステップＳ６１３）。
【００３４】
ステップＳ６０２の判定に戻り、処理部４０５で受信した要求が、情報取得部１０２にて処理する内容だった場合、処理部４０５は、受信した要求から取得すべきＵＲＬを抽出する（ステップＳ６１４）。次いで、処理部４０５は、抽出したＵＲＬを情報取得部１０２に通知する（ステップＳ６１５）。情報取得部１０２は、後述するプリフェッチ処理を実施する（ステップＳ６１６）。
【００３５】
プリフェッチ処理では実行して要求された情報を取得すると共に、埋め込みオブジェクトも収集して第１記憶部１３１に記憶する。埋め込みオブジェクトを蓄積する際には、例えばＵＲＬをキーとして、各オブジェクトともに記憶する。他にも、ＵＲＬに基づくハッシュ値をキーとして利用する方法などが考えられる。最終的に、収集可能な全ての埋め込みオブジェクトが集められたら処理部４０５に終了が通知される。
【００３６】
処理部４０５は、取得要求への応答を生成して（ステップＳ６１７）、転送部４０４を介してアプリケーション４００に応答を返す（ステップＳ６０８）。このとき処理部４０５が生成する応答は、ＨＴＴＰヘッダとデータで構成される。このＨＴＴＰヘッダは処理部４０５が適切に生成してもよいし、ＷＥＢサーバ２００から取得した際に通知されたＨＴＴＰヘッダを用いてもよい。
【００３７】
図６−１、６−２は本実施形態におけるプリフェッチ処理に関するフローチャートであり、第２プロセッサ１２０において実行される処理の流れを示す。さらにこのフローは例であり、各ステップの順番を入れ替えて同じ効果をもたらす場合には順番を入れ替えてもよい。
【００３８】
図６−１に示されるように、通信装置１００におけるウェブページの取得動作は第１プロセッサ１１０がＷＥＢサーバ２００に記憶されているＨＴＭＬ形式のファイルのＵＲＬを取得要求としてネットワーク処理部１０１に通知することにより開始される。それまで第２プロセッサ１２０は、待機し続ける（ステップＳ２０１）。この間、第２プロセッサ１２０は消費電力を減らすために低消費電力な状態であるスリープ状態に遷移していてもよい。なお、第１プロセッサ１１０が複数のＵＲＬを取得しようとする場合は、全てのＵＲＬの取得を完了するまで以降の処理が繰り返される。
【００３９】
第１プロセッサ１１０がネットワーク処理部１０１に取得要求を通知すると（ステップＳ２０２：Ｙｅｓ）、ネットワーク処理部１０１は、取得要求に含まれるＵＲＬによって特定される情報が第１記憶部１３１に記憶されているか否かを判定する（ステップＳ２２１）。ＵＲＬが第１記憶部１３１に記憶されていない場合（ステップｐＳ２２１：Ｎｏ）、ネットワーク処理部１０１は第１プロセッサ１１０に対してスリープ状態への遷移許可を通知する（ステップＳ２０３）。
【００４０】
以降の処理を実施中は、第１プロセッサ１１０はスリープ状態へと移行している状態である。スリープ状態への遷移許可を受けた第１プロセッサ１１０は、他に動作し続ける要因が存在しない場合、スリープ状態へと遷移する。
【００４１】
情報取得要求を受け取ったネットワーク処理部１０１は、要求がウェブページの取得要求であることを把握し、情報取得部１０２に通知する。情報取得部１０２は要求を解釈し、ＵＲＬで特定されるＷＥＢサーバ２００に要求を送信する（ステップＳ２０４）。その後、情報取得部１０２は、ＷＥＢサーバ２００からの応答が受信できるまで待機し続ける（ステップＳ２０５）。ＷＥＢサーバ２００から応答が受信できると（ステップＳ２０６：Ｙｅｓ）、情報取得部１０２は、取得した情報を第１記憶部１３１に保存する（ステップＳ２０７）。この際に取得される情報としては、例えばＨＭＴＬ形式のデータであり、ＨＴＭＬと対応付けられた画像ファイルやスタイルシートなどのオブジェクトのデータはこの時点では取得されていない。
【００４２】
その後、情報取得部１０２は、第１記憶部１３１に保存した情報を解析して埋め込まれたオブジェクトを特定する情報を抽出する（ステップＳ２０８）。ここで埋め込まれたオブジェクトとは、ＨＴＭＬファイルから参照される画像ファイル（＜ＩＭＧ＞タグで特定される）や、スクリプトファイル（＜ＳＣＲＩＰＴ＞タグで特定される）などである。
【００４３】
情報取得部１０２が抽出した情報は、新たな取得要求として「追加取得リスト」として第２記憶部１３２に保存される（ステップＳ２０９）。
【００４４】
図１５に追加取得リストの例を示す。この例は二つのリストが連結する形を取っているが、単独のリストとして構成してもよい。このリストは事前一括取得の対象となる情報が列挙されていればよい。
【００４５】
あるＷｅｂページ対する情報取得要求が発生して、情報取得部１０２による解析が完了すると「Ａ：初期状態」に示すようなリストが第２記憶部１３２上に生成される。情報取得部１０２はこのリストを使いながら各ＵＲＬにアクセスして情報を取得する。例えば、ＵＲＬ１１（１３０１）が取得できると取得リストは、「Ｂ：ＵＲＬ１１を取得した後」の状態になる。この図では１３０１を点線で表現しているが、実際にはリストから取り除かれるか、もしくはエントリに取得済みの印をつけるなどして、未取得の状態と区別できるようにする。
【００４６】
なお、複数のページに対して同時に要求が発生した場合には、「Ｃ：２つのページに対する要求が同時に発生した場合」のように複数のリストを連結する形で管理すればよい。
【００４７】
次いで、情報取得部１０２は、第２記憶部１３２に追加取得リストが記憶されているか否かを判定する（ステップＳ２１０）。第２記憶部１３２に追加取得リストにエントリがないと判定された場合（ステップＳ２１０：Ｎｏ）、第１プロセッサ１１０がスリープ状態である場合には、起動制御部１０５が第１プロセッサ１１０を動作状態へと遷移させてから（ステップＳ２２０）終了する。このとき動作状態へ遷移させる方法は、割り込み信号を有効にする、クロック信号の供給を再開する、電源をオンにする、などの方法が考えられる。この場合は、例えば第１プロセッサ１１０から通知された取得要求がＨＴＭＬファイルに対するものではなかった場合、すなわち画像ファイルであった場合など、ステップＳ２０８でＵＲＬが抽出されないため、追加取得リストのエントリが生成されない。
【００４８】
追加取得リストにエントリがあると判定された場合（ステップＳ２１０：ＹＥＳ）、情報取得部１０２はリストに従って各埋め込みオブジェクトを取得するための処理を実施する。情報取得部１０２はオブジェクトのＵＲＬで特定されるＷＥＢサーバ２００に要求を送信する（ステップＳ２１２）。その後、情報取得部１０２は、ＷＥＢサーバ２００からの応答が受信できるまで待機し続ける（ステップＳ２１３）。ＷＥＢサーバ２００から応答が受信できると（ステップＳ２１４：Ｙｅｓ）、情報取得部１０２は、取得した情報を第１記憶部１３１に保存する（ステップＳ２１５）。次いで、情報取得部１０２は、取得が完了した情報に対応するエントリを追加情報リストから削除して更新する（ステップＳ２１６）。
【００４９】
ここで情報取得部１０２は、取得したオブジェクトが解析対象だった場合、すなわちＨＴＭＬ形式のファイルであるかを判定する（ステップＳ２１７）。解析対象であると判定された場合（ステップＳ２１７：ＹＥＳ）、情報取得部１０２は、取得した情報を解析する（ステップＳ２１８）。そして、情報取得部１０２は、解析の結果得られたオブジェクトのＵＲＬを用いて追加取得リストを更新する（ステップＳ２１９）。そして、ステップＳ２１０へと戻り追加取得リストのエントリがなくなるまで処理を繰り返す。ここで解析対象か否かは、取得した情報がテキスト形式かどうか、事前に設定されたコンテントタイプに一致するか（ＨＴＴＰのＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダに記載の値が事前に設定された値と一致するか）に基づいて判断する。事前の設定とは、例えば、静的情報であるスタイルシートやスクリプトファイルは解析対象とするが、ＪＰＥＧ画像は対象としない、などである。なお、スクリプトを実行した結果として得られるＵＲＬは対象としない。一方、受信した情報が解析対象でないと判定された場合（ステップＳ２１７：Ｎｏ）、処理を繰りかえす。
【００５０】
一方、ステップＳ２２１へと戻りＵＲＬが第１記憶部１３１に含まれている場合（ステップＳ２２１：Ｙｅｓ）、図６−２で示されるように、ステップＳ３０６へと移行する。この場合は、第１プロセッサ１１０はスリープ状態には移行せず、通常状態のまま移行の処理は進行する。ステップ３０６以降の処理の際は、第１プロセッサ１１０は動作状態である。情報取得部１０２は、第１記憶部１３１から当該情報を読み出して（ステップＳ３０６）、応答を生成した後、第１プロセッサ１１０に通知する（ステップＳ３０７）。なお、第１記憶部１３１に保存してある事前に第２プロセッサ１２０によって取得された情報は、第１プロセッサ１１０に通知した後に削除してもよいし、そのまま残しておいてもよい。残しておく場合には通信プロトコルで定められた有効期限の管理方法（例えば、ＨＴＴＰ１．１で規定されるキャッシュの有効期間）に従って管理してもよいし、独自の方法で管理してもよい。
【００５１】
次に、第１プロセッサ１１０の状態遷移について図７を用いて説明する。図７に示されるように。第１プロセッサ１１０は、情報取得要求を第２プロセッサ１２０へと送ると、第２プロセッサ１２０からスリープ許可を受信する。したがって、第１プロセッサ１１０は、最初の情報取得要求を生成してからスリープ状態への遷移通知を受信するまで（Ｓ２０３まで）は動作状態である。そして、第１プロセッサ１１０は、ネットワーク処理部１０１からスリープ許可通知を受けると、スリープ状態へと遷移し、再びネットワーク処理部１０１から動作状態への復帰信号を受信するまで（ステップＳ２２０まで）、スリープ状態である。第１プロセッサ１１０は、復帰信号を受信すると、動作状態へと遷移し、第２プロセッサ１２０がＷｅｂサーバ２００から取得し、第１記憶部１３１に記憶した情報の取得を行う。なお、本実施形態では、第１プロセッサ１１０が複数のスリープ状態を備えており、スリープ時間が長く継続するほど消費電力がより少ないスリープ状態へと移行する。
【００５２】
このように本実施形態の通信装置１００においては、第1プロセッサ１１０が情報の取得要求を発行し、取得要求した情報に対応付けられた一連の第２情報を第２プロセッサ１２０で一括して取得する。その際、第１プロセッサ１１０をスリープ状態に遷移させることで、第１プロセッサ１１０の消費電力を削減できる。また、第２プロセッサ１２０がすべての第２情報の取得を完了した時点で第１プロセッサ１１０を動作状態へと復帰させることで、速やかに動作を再開することができる。
【００５３】
（第２の実施形態）
次に、本発明の通信装置を具体化した第２の実施形態について説明する。第１の実施形態では第１プロセッサがスリープ状態へと遷移する際に、第２プロセッサにおいて取得要求された情報、及びその情報に関連付けられた各オブジェクトの情報を取得する時間に基づいてスリープ時間が設定される点が異なる。以下、詳細について説明する。
【００５４】
図８に本実施形態の通信装置３００の機能ブロック図を示す。第１の実施形態で示した図２の通信装置１００と同じ構成については、同様の符号を付与しており、異なる構成についてのみ説明する。
【００５５】
図８に示されるように、第２プロセッサ７２０のネットワーク処理部７０１には、処理部７０５、及びスリープ時間算出部７０２が設けられている。また、スリープ時間算出部７０２は、情報取得部７０３が情報を事前に一括取得する際に、第１プロセッサ７１０がスリープ状態に滞在できる時間の目安を算出する。スリープ時間の算出に必要な情報は、情報取得部７０３、及び第２記憶部１３２から入手される。
【００５６】
処理部７０５は、スリープ時間算出部７０２が決定したスリープ時間を、第１プロセッサ７１０に通知する。転送部７０６は、ネットワーク処理部７０１から通知されたスリープ時間を抽出し、スリープ制御部７０７に通知する。なお、スリープ時間に関する情報は、アプリケーション７００に通知してアプリケーション側で状態遷移を促すようにしてもよい。スリープ制御部７０７は、処理部７０５、又はアプリケーション７００から通知されたスリープ時間を越えない範囲で第１プロセッサ７１０をスリープ状態にする。
【００５７】
図９は、第２プロセッサ７２０における情報取得にかかる処理の流れを示すフロー図である。本フローは、図３−１で示したフローチャートに対して新たにステップＳ８０８〜Ｓ８０９の処理を追加しており、他のステップは同じであるため、説明は省略する。スリープ時間算出部７０２は、第１記憶部１３１に記憶された情報に基づいて、スリープ時間を算出する（ステップＳ８０８）。
【００５８】
スリープ時間の算出方法については、以下に示す３つの方法がある。１つ目の方法は、過去にＷＥＢサーバ２００と通信した際の所要時間を使用する方法である。情報取得部７０３で情報取得を実行する際に指定されたＵＲＬに対して、そのＵＲＬに関連する埋め込みオブジェクトの取得に要した時間を当該ＵＲＬと対応付けて第１記憶部１３１に保存しておく。保存したＵＲＬに対するアクセスが発生した場合には、スリープ時間算出部７０２は、対応して保存されている値をスリープ時間として取得し、処理部７０５を通じて第１プロセッサ７１０に通知する。
【００５９】
この方法では、ＵＲＬにアクセスするのが初めてであった場合、スリープ時間を算出することができない。したがって、最初のアクセスでは事前に決めた固定値を使用したり、類似するＵＲＬ、例えば同じドメイン名を持つなどのＵＲＬに対応付けられた値を使用したりするようにしてもよい。また、最初のアクセスではスリープ時間の通知を行わずに、第２プロセッサ７２０での情報取得の完了通知で動作状態へと遷移させるようにしてもよい。
【００６０】
なお、上記説明ではＵＲＬごとに所要時間を記憶する方法を述べたが、複数のＵＲＬをグループに分けてまとめて記憶したり、全てのＵＲＬに対する所要時間を平均化した値を所要時間として記憶したりしてもよい。グループ分けの方法としては、同一サーバ、同一ドメイン、関連ドメインに基づく分け方や、情報を取得した時間や場所の情報に基づく分け方や、情報の取得に使用した通信方式やネットワークインタフェースに基づく分け方などが考えられる。また、複数の所要時間に対して平均値をとる、最小値をとる、最大値をとる、などの方法で値を決定する。
【００６１】
二つ目の方法は、取得したＨＴＭＬに含まれる埋め込みオブジェクトの数とネットワークの特性情報（例えば、ＲＴＴ（RoundTripTime）やスループット）を利用する方法である。埋め込みオブジェクトの数がＮ個でＲＴＴがｒ秒だった場合、その取得にはＮ×ｒ秒以上を要すると予想できる。同時に複数のオブジェクトを取得できる場合には、同時取得数ｐで割ってＮ／ｐ×ｒ秒以上を要すると考えられる。なお、ネットワークの特性情報は、情報取得部７０３においてＨＴＭＬの取得に要する時間から算出する。また、別途用意されたネットワーク管理サーバ等に問い合わせて取得する方法なども考えられる。
【００６２】
三つ目の方法は、埋め込みオブジェクトの平均サイズとスループットを踏まえて転送時間を算出し、スリープ時間に追加する。埋め込みオブジェクトの平均サイズをＳ（バイト）、スループットをＴ（ｂｐｓ）とすると、埋め込みオブジェクト１つあたりの転送時間はｒ＋Ｓ／Ｔ秒となる。全ての埋め込みオブジェクトを１つずつ取得する場合、Ｎ×(ｒ＋Ｓ／Ｔ)秒がスリープ時間となる。同時にｐ個ずつ取得する場合には、１つあたりのスループットが１／ｐとなることからＮ／ｐ×(ｒ＋ｐＳ／Ｔ)秒がスリープ時間となる。
【００６３】
これらの計算に必要な埋め込みオブジェクトの平均サイズは、事前に設定した固定的な値を使用する方法、実測値（取得するたびに更新する）を使用する方法、管理サーバなど第三者から通知される値を使用する方法、などが考えられる。これらの値を定める際には、ひとつ目の方法と同様に、グループに分けて管理してもよい。なお、平均サイズではなく最小サイズや最大サイズを使ってもよい。
【００６４】
さらに、これまでの３つの方法に対して固定的な値αを加減算した値を使用してもよい。これまでの方法はいずれも経験値や予測に基づく値であるため、実際に一括取得が完了する時間との間に乖離が生じる可能性がある。この乖離によって無駄な電力を消費したり、レスポンスが低下したりする恐れがある。これらを調整するため、何らかの固定値αを用いて値を調整してもよい。
【００６５】
スリープ時間算出部７０２は、以上のようにスリープ時間を算出する。次いで、処理部７０５は算出されたスリープ時間を第１プロセッサ７１０に通知する（ステップＳ８０９）。なお、スリープ時間は第１プロセッサ７１０をスリープ状態へと遷移させる許可の通知とともに送信される。この通知を受け、第１プロセッサ７１０のスリープ制御部７０７は、自身で動作するアプリケーション７００やカーネル４１０などの状況を鑑み、通知された時間の中で最適なスリープ状態を選択して、当該状態へと遷移させる。
【００６６】
また、スリープ時間の通知方法について述べる。スリープ時間の通知方法は２通りある。１つ目の方法では、スリープ時間はアプリケーション７００が発行した受信処理命令に対する応答として伝えられる。例えば、アプリケーション７００がｒｅｃｖ()システムコールを実行して最初のＨＴＭＬファイルに対する受信待ちを行っているとする。この場合、スリープ時間算出部７０２がスリープ時間の算出を完了したら、ｒｅｃｖ（）に対する応答としてスリープ時間の通知を行う。この通知は、通常のＨＴＴＰの応答と区別するため、適切なＨＴＴＰレスポンスコード・ヘッダを伴う形で送信する。例えば、レスポンスコード１０３を『スリープ応答』として使用することとし、スリープ時間を通知するレスポンスヘッダ『Ｘ−Ｓｌｅｅｐ−Ｔｉｍｅ：  １０』を追加する。
【００６７】
このような情報を伴ったＨＴＴＰ応答を受信したアプリケーション７００は、スリープ時間が含まれていることを検出し、スリープ制御部７０７に時間を通知する。なお、スリープ時間の算出と並行してＨＴＭＬファイルのダウンロードが完了してしまった場合には、ＨＴＭＬファイルを含む通常の応答にスリープ時間を通知するレスポンスヘッダを追加する形でもよい。
【００６８】
２つ目の方法では、転送部７０６と処理部７０５の間で交換する情報に付与するヘッダにおいて、スリープ時間を通知するための特別な情報であることを示すコード番号を付与する。転送部７０６は特別なコード番号を持ったメッセージを検出し、スリープ時間を抽出した後、スリープ制御部７０７へと通知する。
【００６９】
次いで、本実施形態の通信装置３００における第１プロセッサ７１０と商品電力の推移について図１０を用いて説明する。図１０に示されるように、第１プロセッサ７１０は、第２プロセッサ７２０からのスリープ状態への遷移許可を受け取るとスリープ状態へと遷移する。この際、スリープ制御部７０７は、スリープ許可とともに通知されたスリープ時間に基づいて、最初から深いスリープ状態へと遷移する。なお、スリープ時間が短すぎた場合には図１１のように実際の復帰信号と比較して早く復帰してしまい、無駄な電力消費が発生する可能性がある。
【００７０】
以上に示した本実施形態の通信装置３００にあっては、取得する情報に基づいて設定されたスリープ時間に従って第１プロセッサ７１０はスリープ状態となるため、適切なスリープ状態に速やかに遷移できるようになる。また、スリープ時間が経過することで、第１プロセッサ７１０は、動作状態へと復帰し、第２プロセッサ７２０からの情報取得の応答が通知されるタイミングにおいては、動作状態となっていることから、復帰にかかる処理のために、処理速度が低下する可能性も抑制することができるようになる。
【００７１】
（第３の実施形態）
続いて第３の実施形態について説明する。第３の実施形態においては、スリープ制御部７０７が第１プロセッサ７１０の状態を制御する際に、第２プロセッサ７２０から通知されたスリープ時間から一定量δだけ短い時間を深いスリープ状態とする。また、スリープ制御部７０７は、スリープ時間から一定量δだけ短い時間が経過した後の時間から復帰指示が通知されるまでの時間を浅いスリープ状態とする。浅いスリープ状態においては、深いスリープ状態よりも、動作状態へと復帰するために要する時間が短くなる。
【００７２】
既に述べた第２の実施形態では、全てのオブジェクトの受信が完了した時点で復帰指示が発行されるため、スリープ時間の経過前の応答の通知がされた場合、第１プロセッサ７１０が処理を再開するまでに時間がかかる可能性があった。本実施の形態では、情報の取得が完了する前に第１プロセッサ７１０を浅いスリープ状態へと遷移しておくようにする。
【００７３】
削減量δを算出する方法は、２通りの方法があり、以下にその詳細について説明する。まず、第１プロセッサ７１０単体で算出する方法について述べる。まず、スリープ制御部７０７はスリープ状態に遷移する前に通知されたスリープ時間を取得する。また、スリープ制御部７０７は起動制御部１０５からの通知によって復帰した時刻についても第１プロセッサ７１０に内蔵されている時計などから把握することができる。
【００７４】
よって、スリープ制御部７０７は、第１プロセッサ７１０が復帰した時点でこれら二つの情報から復帰タイミングの差異ΔＴを算出する。この値は情報の取得を繰り返すたびに算出され、過去の値に基づいて新たな値ΔＴ´が更新される。例えば、過去に発生した差異の平均値、最小値、最大値などである。最終的に求めたΔＴ´に対して一定の重み付けを行う関数ｆを用いてδ＝ｆ（ΔＴ´）を求める。関数ｆは、例えば０より大きな任意の値を掛ける、などの関数である。
【００７５】
また、削減量δを処理部７０５側で算出して求める方法も存在する。この場合、削減量δを求める方法は複数存在する。最も簡単な方法としては、事前に設定された固定値を用いる方法である。他の方法として、情報取得部７０３で測定されたＲＴＴの情報を用いて（平均ＲＴＴ）−（最小ＲＴＴ）を求めてそれを削減量とする方法、過去の取得で要した時間の情報を用いて（平均取得時間）−（最小取得時間）を求めてそれを削減量とする方法が考えられる。さらに、上記で求めた削減量δに対して、埋め込みオブジェクトの数ＮやサイズＳを考慮して重みづけを行う関数ｆ１（Ｎ，δ）や関数ｆ２（Ｓ，δ）を使って求めてもよい。重み付けの例としては、０〜１までの小数とＮ、Ｓのいずれかをδに掛けるなどが考えられる。
【００７６】
また、ネットワーク処理部７０１がスリープ時間と、削減量δとを別々に算出し、通知する方法のほか、スリープ時間自体を算出された数値に対して削減量δに相当する時間分、減算して通知する方法であってもよい。
【００７７】
本実施形態における第１プロセッサ７１０の状態と消費電力の関係を図１２に基づいて説明する。図１２に示されるように、第１プロセッサ７１０は、通知されたスリープ時間に対して削減量δ分短縮されたスリープ時間は深いスリープ状態となる。そして、第１プロセッサ７１０は、短縮されたスリープ時間が経過後は、元々通知されたスリープ時間が経過するまで浅いスリープ状態となる。そして、浅いスリープ状態が経過するか、又は第２プロセッサ７２０から復帰信号を受信するかした場合に、第１プロセッサ７１０は、動作状態へと復帰する。
【００７８】
本実施形態にあっては、通知されたスリープ時間より短い時間で第１プロセッサ７１０が浅いスリープ状態へと遷移することとしたため、第２プロセッサ７２０からの復帰信号がスリープ時間より早く受信された場合であっても、早期に動作状態へ復帰することができる。したがって、電力消費量の抑制と、処理の効率化の料率を図ることができるようになる。
【００７９】
（第４の実施形態）
次に、第４の実施形態について述べる。本実施形態においては、第３の実施形態で削減量δとして算出している値の算出方法を変更するものである。以降の説明では、第１プロセッサ９１０単体で削減量δを算出するケースについて述べるが、第３の実施形態で述べた各方法においても同様に適用することができる。
【００８０】
図１３に本実施形態の通信装置４５０の機能ブロック図を示す。通信装置４５０は、第３の実施形態の構成に加え、電源部９０１が新たに追加されている。電源部９０１は、バッテリーやキャパシタなどの蓄電部品もしくは太陽電池などの発電部品で構成され、本通信装置４５０に対して電力を供給する。電源部９０１は、その蓄電量（電池残量）や発電量の情報をスリープ制御部９０２に通知する。
【００８１】
スリープ制御部９０２は、削減量δを計算する際に、電源部９０１から現在の発電量を取得する。この発電量を正規化した値Ｐと復帰タイミングの差異ΔＴを用いて削減量δ´＝ｇ（ΔＴ，Ｐ）を算出する。ここで関数ｇ（）は、Ｐの値が大きいほど削減量δ´が大きく、Ｐの値が小さいほど削減量δ´が小さくなるように重みづけをする関数である。このよう削減量δ´を算出することで、発電量が大きい場合には応答性を重視して早めに浅いスリープ状態に復帰し、発電量が小さいときには省電力性を重視して浅いスリープ状態になる時間を短くする。
【００８２】
第３の実施形態の説明では、削減量δを第２プロセッサ９２０で算出する方法と削減量δを使わずに二段階で復帰する方法も述べた。これらの方法を用いる場合であっても、実際にスリープをするタイミングにおいて値Ｐを用いた補正を行うことで上記効果を得ることができる。例えば、通知されたδを用いる場合であれば、δ´＝ｇ１(δ，Ｐ)のような関数ｇ１（)で調整すればよい。関数ｇ１（)はＰの値が閾値より小さいときにδ´＜δとなるδ´を返し、Ｐが閾値より大きいときにδ´＞δとなるδ´を返す関数である。
【００８３】
以上に示した４の実施形態の通信装置４５０では、電池残量や発電量に基づいて第１プロセッサ９１０のスリープ状態からの復帰タイミングを変更することで、電力が不足しがちな状況においても省電力と応答性の両立を実現することができるようになる。
【００８４】
（第５の実施形態）
次に、本発明の第５の実施形態の通信装置５００について説明する。上記第１〜第４の実施形態においては、復帰信号を通知するタイミングは情報取得部による一括取得が完了した時としていた。このようにすることで、第１プロセッサが復帰するタイミングでは、要求された情報の取得処理が完了していることが確実となる。しかしながら、処理の再開までにタイムラグが発生してしまう。そこで、本実施形態では情報取得部の情報の取得状況に応じて復帰信号の通知タイミングを制御する機能を持たせる。
【００８５】
本実施形態の通信装置５００の機能ブロックを図１４に示す。図１４に示されるように、情報取得部１０００は実行部１００１とリスト監視部１００２とを備えている。また、第２記憶部１３２には追加取得リスト１０１０が保存されている。
【００８６】
実行部１００１はネットワーク処理部１０１から通知されたＵＲＬならびに追加取得リスト１０１０に格納されたＵＲＬを参照し、事前一括取得処理を実行する。取得した情報は第１記憶部１３１に蓄積される。実行部１００１は、１つの埋め込みオブジェクトを取得するたびに、リスト監視部１００２に対して取得通知を送信する。リスト監視部１００２は、取得通知を受信した際に追加取得リスト１０１０の残エントリ数を監視して、所定の条件が満たされた時に起動制御部１０５へ通知する。
【００８７】
以降、リスト監視部１００２の動作を詳細に述べる。図１５にリスト監視部１００２の動作フローチャートを示す。リスト監視部１００２の処理は、転送部４０４から事前に一括取得のきっかけとなるＵＲＬが通知されることを契機に開始される。また、第１プロセッサ１１０の状態遷移に要する時間Ｔｗａｋｅは既知であるとする。
【００８８】
はじめにリスト監視部１００２は、取得完了数ｎをゼロに、開始時刻Ｔ０を現在時刻Ｔで初期化する（ステップＳ１１０１）。その後、リスト監視部１００２は、実行部１００１から取得通知を受信するまで待機する（ステップＳ１１０２、Ｓ１１０３：ＮＯ）。
【００８９】
取得通知を受信すると（ステップＳ１１０３：ＹＥＳ）、リスト監視部１００２は取得完了数ｎをひとつ増やす（ステップＳ１１０４）。また、リスト監視部１００２は、残エントリ数Ｌを取得する（ステップＳ１１０５）。そして、リスト監視部１００２は、単位時間あたりの平均取得数Ｃｎを更新する（Ｃｎ＝（事前一括取得の実行時間）／（取得個数）＝（Ｔ−Ｔ０）／ｎ）（ステップＳ１１０６）。
【００９０】
その後、リスト監視部１００２は、状態遷移に必要な時間の中で完了する可能性があるエントリの個数であるＣｎ×Ｔｗａｋｅを求め、その数が残エントリ数Ｌ以上かどうかを判定する（ステップＳ１１０７）。残エントリ数Ｌ以上であると判定された場合（ステップＳ１１０７：ＹＥＳ）、リスト監視部１００２は、起動制御部１０５に対して復帰通知の発行を依頼する（ステップＳ１１０８）。残エントリ数Ｌよりも少ないと判定された場合には（ステップＳ１１０７：ＮＯ）、再び取得通知を受信するまで待機する（ステップＳ１１０２に戻る）。
【００９１】
なお、状態遷移に必要な時間の中で完了する可能性があるエントリの個数Ｃｎ×Ｔｗａｋｅと残エントリ数Ｌとを比較しているが、処理遅延などを考慮して前者の数に余裕を持たせてもよい。例えば残エントリ数Ｌに１加算した値と比較するようにしてもよい。
【００９２】
以上に示した第５の実施形態の通信装置５００では、復帰通知を送信するタイミングを変更することで、省電力を維持しながらも応答性を向上させることができる。
【００９３】
以上に示した各実施形態においては、第１情報としてＵＲＬを、第２情報としてＵＲＬによって特定されるＷｅｂページに関連付けられた埋め込みオブジェクトを選ぶ例を示したが、他の情報であってもよい。例えば、アプリケーションとして電子メーラーを用い、第１情報としてメールアドレスを用い、メールアドレスを用いてメールサーバから予めデータ量などを含むヘッダのみを取得し、ヘッダを取得するタイミングで第１プロセッサはスリープさせる。そして、メールの実データを第２情報として取得している間は、第１プロセッサはスリープ状態にしておき、全ての実データを取得後に復帰させるようにすることもできる。ヘッダのみを取得するには、例えばＰＯＰ３  ＳＴＡＴなどのコマンドによって取得することができる。
【００９４】
本発明の実施形態を説明したが、実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００９５】
１００  通信装置
１０１  ネットワーク処理部
１０２  情報取得部
１０５  起動制御部
１０６  ＴＣＰ／ＩＰスタック
１１０  第１プロセッサ
１２０  第１プロセッサ
１３０  記憶部
１３１  第１記憶部
１３２  第２記憶部
２００  サーバ
３００  通信装置
４００  アプリケーション
４０１  ソケット
４０２  判断部
４０３  対応表
４０４  転送部
４０５  処理部
４０６  ＴＣＰ／ＩＰスタック
４１０  カーネル
５００  通信装置
７００  アプリケーション
７０１  ネットワーク処理部
７０１  処理部
７０２  スリープ時間算出部
７０２  プロセッサスリープ時間算出部
７０３  情報取得部
７０５  処理部
７０６  転送部
７０７  スリープ制御部
７１０  第１プロセッサ
７２０  第２プロセッサ
９０１  電源部
９０２  スリープ制御部
９１０  第１プロセッサ
９２０  第２プロセッサ
１０００  情報取得部
１００１  実行部
１００２  リスト監視部
１０１０  追加取得リスト
【図１】
2014102710.tif 000003
【図２】
2014102710.tif 000004
【図３】
2014102710.tif 000005
【図４】
2014102710.tif 000006
【図５】
2014102710.tif 000007
【図６−１】
2014102710.tif 000008
【図６−２】
2014102710.tif 000009
【図７】
2014102710.tif 000010
【図８】
2014102710.tif 000011
【図９】
2014102710.tif 000012
【図１０】
2014102710.tif 000013
【図１１】
2014102710.tif 000014
【図１２】
2014102710.tif 000015
【図１３】
2014102710.tif 000016
【図１４】
2014102710.tif 000017
【図１５】
2014102710.tif 000018
【図１６】
2014102710.tif 000019