JP2014075122A - 処理装置およびその方法 - Google Patents

Abstract

【課題】装置の消費電力を低減する。
【解決手段】本発明の一態様としての処理装置は、処理部と、通知部とを備える。前記処理部は、要求元から第１情報の取得要求を受信し、前記第１情報の取得先から前記第１情報を取得する必要があるか否かを、あらかじめ決められた条件に基づき判定する。 前記通知部は、前記処理部が前記第１情報を取得する必要があると判定した場合に、前記要求元に低消費電力状態への遷移指示を含む第１応答を通知する。
【選択図】図１

Description

本発明の実施形態は、処理装置およびその方法に関する。

ネットワーク上で公開されている種々の情報を一時的に蓄積し、端末装置からの要求に対して代理応答するキャッシュプロキシの技術が普及している。例えば、端末装置で動作するWebブラウザがWebサーバから情報を取得する際に、まずキャッシュプロキシにアクセスして、キャッシュプロキシから情報の取得を試みる。キャッシュプロキシが情報を保持していれば、Webサーバから直接取得するよりも早く情報を取得できる。キャッシュプロキシが情報を保持していなければ、キャッシュプロキシが端末装置に代わってWebサーバにアクセスし、情報を取得する。キャッシュプロキシは、取得した情報を蓄積した上で、応答として端末装置に返す。このようなWebページに対するキャッシュプロキシは、複数の端末装置から発生した同じ情報取得要求に対して、速やかに情報を提供する機能を提供する。

さらに、キャッシュプロキシが蓄積する情報を端末装置からの要求に先立ち集めておく技術が知られている。この技術を用いることで情報を速やかに取得できる場合が増え、キャッシュプロキシの効果を増進されることが可能である。

ところが上記の技術を用いたとしても、キャッシュプロキシが全ての情報を事前に蓄積することは不可能である。キャッシュプロキシが情報を保持していない場合には、端末装置は取得するまで待ち時間が生じてしまう。

特開2005-266929号公報 特開平第11-219313号公報

本発明の一側面は、要求元が情報を取得するまでの待ち時間を有効に活用し、装置の消費電力を削減することを目的とする。

本発明の一態様としての処理装置は、処理部と、通知部とを備える。

前記処理部は、要求元から第１情報の取得要求を受信し、前記第１情報の取得先から前記第１情報を取得する必要があるか否かを、あらかじめ決められた条件に基づき判定する。

前記通知部は、前記処理部が前記第１情報を取得する必要があると判定した場合に、前記要求元に低消費電力状態への遷移指示を含む第１応答を通知する。

第１の実施形態に係る通信装置の機能ブロック図を示す。 図１の通信装置の動作フローチャートを示す。 通信装置が受信する要求とその応答の例を示す。 第２の実施形態に係る通信装置の機能ブロック図を示す。 第２の実施形態の動作シーケンスを示す。 スリープ・リダイレクト応答に対する端末装置の動作シーケンスを示す。 リダイレクト応答に対してスリープ時間を追加した例を示す。 第３の実施形態における通信装置の機能ブロック図を示す。 第３の実施形態の動作シーケンスを示す。 図９Ａに続くシーケンスを示す。 抽出する対象となるタグの一例を示す。 第４の実施形態における通信装置の機能ブロック図を示す。 応答生成部が生成する応答の例を示す。 第５の実施形態における端末装置の機能ブロック図を示す。 第６の実施形態における端末装置とサーバ装置の機能ブロック図を示す。 サーバ装置の動作シーケンスを示す。 通信情報保持部に保持されている情報の例を示す。 第６の実施形態の変形例における端末装置とサーバ装置の機能ブロック図を示す。 第１の実施形態の通信装置のハードウェア構成例を示す。 図１８の構成の変形例を示す。 第２の実施形態の通信装置のハードウェア構成例を示す。 第５の実施形態の端末装置のハードウェア構成例を示す。 図２１の構成の変形例を示す。 図２１の構成の別の変形例を示す。 第８の実施形態に係るシステムを示す。 代理取得装置と状態制御装置の構成例を示す。

以下、本発明の実施の形態について、図面を参照しながら説明する。尚、各図において同一箇所には同一の符号を付すとともに、重複した説明は省略する。

＜第１の実施形態＞
《第１の実施形態：構成要素の説明》
図１に本発明の第１の実施形態に係る通信装置１００の構成を示す。なお、通信装置１００の構成要素は本発明の実施に対して必要な構成要素に限定して記載しており、他の構成要素を搭載していても良い。また、同図には本装置を使用するネットワーク構成の代表例を含む。

通信装置１００は、情報取得要求を発する端末装置１１０とサーバ装置１１１の間に設置される。図１では通信装置１００とサーバ装置１１１とはネットワーク１１２を介して接続しているが、必ずしもこの限りではない。

通信装置１００の構成は次の通りである。

要求処理部１０１は、端末装置１１０から情報取得要求を受信する受信機能、要求された情報をサーバ装置から取得する必要があるかをあらかじめ定めた条件に基づき判断する処理機能、取得する必要がある場合には当該情報をサーバ装置１１１から取得する取得機能、取得する必要がある場合に後述するスリープ応答を返す通知機能、サーバ装置１１１から情報を取得する際に必要となる通信処理機能、取得した情報を端末装置１１０に応答として返す出力機能を具備する。要求された情報をサーバ装置から取得する必要があるかを判定する条件としては、一例として、要求された情報が取得済みであるか否か、すなわち後述する情報保持部１０２に蓄積されているか否かがある。蓄積されていない場合は取得する必要があり、蓄積されている場合は取得する必要がないと判断する。要求処理部１０１は、蓄積されていると判断した場合（情報を取得する必要がないと判断した場合）に当該蓄積済みの情報を端末装置１１０へ応答として返す出力機能を備える。また、他の条件の例として、当該情報を取得済みであるものの、当該取得済みの情報が有効期限切れであるか否か、あるいは、取得してから一定時間以上経過しているか否か等がある。有効期限が切れているまたは一定期間以上経過している場合は、当該情報が更新されている可能性があるとして、当該情報を取得する必要があり、そうでない場合は、取得する必要がないと判断する。また、さらに別の条件の例として、当該要求された情報を端末装置１１０に送信することが許容されているか否かもある。たとえば端末装置またはユーザごとにセキュリティ基準が設定されており、要求された情報がセキュリティ基準を満たすかを当該情報の取得要求（URI等）から判断し、満たさない場合には要求された情報をユーザに送信する必要はないとして、端末装置に要求された情報は送信できない旨の通知を返しても良い。この場合、当該要求された情報を蓄積済みでなくても、サーバ装置から取得する必要はないと判断してもよいし、別のユーザから要求される可能性が高いとして事前に取得して蓄積しても良い。これらはあくまで一例であり、本実施形態はこれに限定されない。以下の説明では、要求された情報が情報保持部１０２に取得済みであるか否かにより、当該情報を取得する必要があるかを判断する場合を想定する。要求処理部１０１は、例えば、プロセッサ上で動作するソフトウェアや１つ以上の機能を実現する専用回路で実現される。

情報保持部１０２は、要求取得部１０１がサーバ装置１１１から取得した情報を蓄積する。情報保持部１０２は、例えばハードディスクやＳＳＤなどで実現される。

情報確認部１０３は、情報保持部１０２に、要求された情報が蓄えられているかどうか、蓄えられた情報が有効な情報かどうかを確認する。ここで情報が有効とは、事前にサーバ装置１１１が各情報に対して設定した有効期限を経過していない状態、もしくは本装置１００が設定した有効期限が経過していない状態を指す。なお、この機能は必ずしも搭載している必要は無く、有効期限以外の方法で管理しても良い。たとえば情報の蓄積を開始してから一定期間を経過したものは無効であると判断してもよい。情報確認部１０３は、例えば、プロセッサや専用回路で実現され、その際、要求処理部１０１と合わせて実現してもよい。

通信情報保持部１０４は、本装置１００とサーバ装置１１１との間のネットワーク１１２や通信に関する情報を保存する。例えば、揮発性メモリ、ハードディスクやＳＳＤといった記憶媒体で実現される。

スリープ時間算出部１０６は、通信情報保持部１０４に保存された情報を使って、端末装置１１０を通常動作時よりも消費電力が低い任意の状態（以下、この状態をスリープ状態という）に遷移させてもよい時間（スリープ時間）を特定するための特定情報を算出する。特定情報として、たとえばスリープ時間そのものを算出してもよいし、後述するように端末１１０に送信する情報のサイズ等でもよい（この場合、サイズを受信した端末１１０が自らスリープ時間を決定する）。ここではスリープ時間を算出するとして説明を続ける。スリープ時間算出部１０６は、例えば、プロセッサや専用回路で実現され、他の要求処理部１０１や情報確認部１０３と一緒に実現してもよい。なお、スリープ状態は、本実施の形態では、通常よりも消費電力が低いという特徴を具備し、具体的な実現手段として、端末装置１１０内の一部の構成要素、または当該一部の構成要素の中のさらに一部の回路への電力供給を停止する、動作周波数を下げる、ネットワークから情報を受信できない状態にするなどが考えられる。

応答生成部１０５は要求処理部１０１からの指示に基づいて、端末装置１１０に返す応答を生成する。その応答にはスリープ時間算出部１０６にて生成したスリープ時間が含まれる。応答生成部１０５は、例えば、プロセッサや専用回路で実現され、他の要求処理部１０１や情報確認部１０３と一緒に実現してもよい。応答にはスリープ時間そのものを含めずに、スリープ時間の識別情報を含めても良い。この場合、端末１１０では、識別情報からスリープ時間を導出可能なルックアップテーブルまたは関数を保持しているものとする。このような識別情報も、端末装置１１０をスリープ状態に遷移させる時間を特定するための特定情報の一例に相当する。

《第１の実施形態：動作シーケンスの説明》
図２に本通信装置１００の動作フローチャートを示す。通常、本通信装置１００は、端末装置１１０から、情報の取得要求を待ち受けている（Ｓ２０１）。所定のタイミングで要求の受信状況を確認し、要求を受信していなければ引き続き待ち受ける（Ｓ２０２-ＮＯ）。要求を受信していた場合（Ｓ２０２-ＹＥＳ）、受信した要求を解析する（Ｓ２０３）。ここまでの一連の処理はすべて要求処理部１０１にて行う。

要求処理部１０１は解析結果を情報確認部１０３に通知し、情報確認部１０３は情報保持部１０２を参照して当該情報を保持しているかどうかを確認する（Ｓ２０４）。確認の結果、情報を保持している場合には（Ｓ２０５-ＹＥＳ）、その旨を要求処理部１０１に返す。要求処理部１０１は要求された情報を情報保持部１０２から取り出し、その情報と共に応答生成部１０５に「情報応答」（ここでは「要求された情報を含む応答メッセージ」と定義する）の生成を依頼する。応答生成部１０５は情報応答を生成し、要求処理部１０１に返す（Ｓ２０６）。要求処理部１０１は、受け取った応答を端末装置１１０に送り返す。

情報保持部１０２が情報を保持していなかった場合（Ｓ２０５-ＮＯ）、要求処理部１０１は応答生成部１０５に「スリープ応答」（情報を保持していない時にスリープ時間を通知するための応答）の生成を依頼する。それを受け、応答生成部１０５はスリープ時間の算出をスリープ時間算出部１０６に依頼する。スリープ時間算出部１０６は、通信情報保持部１０４に蓄積されている情報からスリープ時間を算出する（Ｓ2０８）。なお、算出の方法については後述する。

応答生成部１０５は算出されたスリープ時間を受け取るとスリープ応答を生成し（Ｓ２０９）、生成した応答を要求処理部１０１に返す。要求処理部１０１は受けとったスリープ応答を端末装置１１０に返す（Ｓ２１０）。

このスリープ応答を受け取った端末装置１１０は、同応答に含まれる所定時間、スリープ状態に遷移して良い。当然、前記所定時間が経過したらネットワークを介して情報を受信できる状態に復帰すると仮定する。

なお、本実施形態ではスリープ時間を算出し、スリープ時間をスリープ応答に含めたが、スリープ時間を算出せずに、スリープ応答には、単にスリープ指示（スリープ状態への遷移指示）を含めるだけでもよい。この場合、端末装置１１０は、スリープ指示を検出すると、任意の方法でスリープする時間を決定し、スリープしてもよい。たとえば、事前に定めた一定時間、スリープしてもよいし、ランダムに決定した時間、スリープしてもよいし、取得要求した情報のサイズを取得可能なときは当該サイズに基づきスリープする時間を決定してもよい。あるいは、端末装置１１０の起動は、通信装置１００からの起動指示で行っても良い。たとえば通信装置１００で上記のようにスリープ時間を算出し、スリープ指示を含むスリープ応答を端末装置１１０に送信後、スリープ時間が経過したら、起動指示を端末装置１１０に送信してもよい。

要求処理部１０１はスリープ応答を送信した後、当該要求に指定される情報をサーバ装置１１１から取得する（Ｓ２１１）。この時、通信に関する情報（詳細はスリープ時間算出方法に関連して後述する）を記録しておく。正常に取得できた場合には、通信情報保持部１０４に保持されている通信情報を更新する（Ｓ２１２）。また、サーバ装置１１１から取得した情報を情報保持部１０２に保持しておく（Ｓ２１３）。取得処理が完了すると、通信処理部１０１は応答生成部１０５を用いて情報応答を生成して端末装置１１０に返す（Ｓ２０６〜Ｓ２０７）。

以上が、通信装置１００の基本動作である。

《第１の実施形態に対してＨＴＴＰを使った具体例》
続いて通信装置１００が受信する要求とその応答について、ＨＴＴＰを例にして述べる。

図３‐（Ａ）は端末装置１１０が送信する要求の例である。この要求に対して、サーバ装置１１１が送信する情報は概ね図３（Ｂ）か図３（Ｃ）のいずれかである。図３（Ｂ） は情報が存在する場合であり、図３（Ｃ）は情報が存在しない場合である。本通信装置１００が端末装置１１０およびサーバ装置１１１との間で透過的に処理を行う場合には、これらの形式に従う要求と応答とを扱う。

一方、端末装置１１０とサーバ装置１１１との間に明示的なＨＴＴＰプロキシを設置す
る場合には、端末装置１１０は図３（Ｄ）のような要求を送信する。これに対して、先ほどと同様に、図３（Ｂ）または（Ｃ）の応答をＨＴＴＰプロキシから受け取る。本通信装置１００が明示的なＨＴＴＰプロキシとして機能する場合には、この形式の要求と応答を扱う。通信装置１００はどちらの形式であっても適用可能である。

以下、本通信装置１００は前記説明の透過的もしくは明示的なＨＴＴＰプロキシとして機能する。そして、前記応答メッセージに加え、『スリープ応答』を扱う。スリープ応答の例を図３（Ｅ）に示す。スリープ応答は、その旨を示す専用のコード番号（この例では１０３）が割り当てられ、ＨＴＴＰヘッダにスリープ時間（Sleep-Timeヘッダ、時間はT1）が含まれる点が特徴である。さらに、スリープ応答を受信した端末装置１１０がスリープ状態に遷移した際に通信が切断される可能性を考慮し、本スリープ応答と後続の情報応答とを対応づける識別情報を付加してもよい。

また、図３（Ｂ）の形式の応答は、通信装置１００が情報を保持している場合（Ｓ２０５-ＹＥＳ）に返す『情報応答』として扱う。これにも、先に述べたスリープ応答と情報応答とを関連づける識別情報を付加してもよい。

《第１の実施形態に対してＨＴＴＰを使った具体例: Ｓ２０３〜Ｓ２０４の処理》
続いて、ステップＳ２０３の要求解析について述べる。本通信装置１００が端末装置１１０からの要求を受信すると、その対象を特定する。すなわち、図３（Ａ）の形式であれば“GET / HTTP/1.1”から”/”で囲まれた部分を取り出し、“Host: www.example.com”から“www.example.com”を取り出す。その後、両者を組み合わせて要求先のURLを特定（“http://www.example.com/”）する。図３（Ｄ）の形式であれば、“GET http://www.example.com/ HTTP/1.1”から“http://www.example.com/”を取り出す。

Ｓ２０４では前記方法により特定したURLで決定される情報が情報保持部１０２にあるか否かを確認する処理である。情報保持部１０２はデータベースとして機能しており、URLもしくはURLから導出できる値をキーとして検索をすることで判定する。情報保持部１０２における情報の管理方法については、任意の形式を用いてよい。

《第１の実施形態に対してＨＴＴＰを使った具体例: Ｓ２１１の処理》
取得するべき情報を特定した本通信装置１００は、その情報を情報保持部１０２に保持していない場合に、ステップＳ２１１において、サーバ装置１１１からその情報を取得する。この処理は通常のＨＴＴＰプロキシとして実行するものと同一である。

《第１の実施形態に対してＨＴＴＰを使った具体例: 通信情報保持部の例》
続いて、ステップＳ２０８にて行うスリープ時間算出の際に使用する通信情報保持部１０４について述べる。

通信情報保持部１０４は情報をサーバ装置１１１から取得する際に要した通信時間、取得した情報のサイズ、取得時のスループットやRTTなどの通信情報を保存するデータベースである。これは一例であり、その他の通信情報を保持していてもよい。これら通信情報は適切な粒度で保持する。例えばURLごと、URLによって特定されるサーバ装置１１１ごと、同一ネットワークごとなどの形に整理したうえで保持してもよい。加えて、要求されている情報の種類を加味して分類しても良い。すなわち、「サーバ装置Ａから取得するテキストデータ」と「サーバ装置Ａから取得するJPEG画像データ」のように整理しても良い。

先に述べたとおり、これらの情報はサーバ装置１１１から取得した際に適切に更新される（ステップＳ２１２）。その際、最新の通信に関する値だけを保持しても良いし、過去の通信結果を考慮した値（例えば単純な平均値や、新しい通信情報ほど割合が高くなるように重み付けした値など）であってもよい。

加えて、スループットやＲＴＴは任意の方法で取得してよい。既に述べたように各通信における転送サイズと転送時間とからスループットを独自に求めても良いし、スループット測定用のパケットを対象となるサーバ装置１１１との間で交換してスループットを計測しても良い。同様にＲＴＴについても、ＴＣＰの輻輳制御アルゴリズムにてＲＴＴを管理している場合にはその値を使用しても良いし、ＲＴＴ測定用に時刻情報を含むパケット（例えばICMP Echo Request/Reply）をサーバ装置１１１との間で投げ合うようにしても良い。

《第１の実施形態に対してＨＴＴＰを使った具体例: Ｓ２０８の処理》
スリープ時間算出部１０６は、前述の方法により通信情報保持部１０４に蓄積された通信情報を利用して、サーバ装置１１１から情報を取得するのに要する時間を算出する。ここでは、その算出方法について述べる。

第１の方法は、蓄積された通信情報を用いない例外的な方法である。何らかの固定的な値が通信情報保持部に保持されており、その値に基づいてどのような要求に対しても固定的なスリープ時間を返す。この固定値は、例えば通信装置１００の使用者が任意に決定しても良いし、周辺の通信装置が動作する間隔にあわせて設定しても良い。例えば、通信処理部１０１が通信処理の発生する間隔を検出し、その値を設定することで実現できる。

第２の方法は、保持されているRTTをスリープ時間として返す方法である。この方法では、最初の応答パケットが戻るまでの時間だけがスリープ時間となる。

第３の方法は、情報の想定サイズとスループットを用いる方法である。情報の想定サイズとは、過去に取得した情報から得た平均サイズ、もしくは設計時に決めた典型的なサイズである。これを対象とするサーバ装置１１１までのスループットで割ることで、転送に必要な時間を算出する。この値をスリープ時間とする。なお、スループットは過去の情報取得により記録された値（転送時間と転送サイズから算出）を使用すればよい。なお、情報の想定サイズとしてサーバ装置１１１から通知された値を用いてもよい。例えば、取得する情報が非常に大きいと事前に予想される場合に、応答を返す前にＨＴＴＰヘッダ部分を処理し、その中に含まれる長さ情報（Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダ）を使うようにしてもよい。

第４の方法は、あらかじめ保持した通信時間をそのままスリープ時間とする方法である。通信時間は取得する情報のサイズや通信路の品質に大きく依存する。そのため、この方法を採用する場合には、スリープ時間はサーバごとや情報の種類ごとのように細かく蓄積していることが好ましい。

ここでは４つの方法を述べたが、必ずしもこれらの方法に限定されない。類似する情報並びに算出方法を用いるものであれば、本発明の範囲は逸脱しない。

《第１の実施形態：その他の補足事項》
先の説明にて透過的なＨＴＴＰプロキシと明示的なＨＴＴＰプロキシがあることを述べたが、両者の違いのひとつは、送受信するメッセージに本通信装置１００のＩＰアドレスを用いるか否かである。透過的なＨＴＴＰプロキシでは通信装置１００のＩＰアドレスは用いない。そのため、新たに追加したスリープ応答を返す際にも、サーバ装置１１１のＩＰアドレスを装って応答を返してもよい。一方、明示的なＨＴＴＰプロキシとして動作する場合には、本通信装置１００のＩＰアドレスを用いて応答を返す。

また、本実施形態の説明においてＨＴＴＰを使った実現方法を例に述べた。しかし、使用する通信プロトコルはＨＴＴＰに限定されない。例えば、ＦＴＰやＳＩＰなど他の通信プロトコルを使っても良い。加えて、情報を取得する通信プロトコルとスリープ応答の送信に使用する通信プロトコルとは必ずしも同じである必要は無い。例えば、ＨＴＴＰで情報を取得し、ＩＣＭＰでスリープ応答を伝えるようにすることも可能である。ＩＣＭＰを使う場合には新たなＩＣＭＰタイプ・コードを定義すればよい。

また本実施形態では、端末装置１１０から取得要求された情報が情報保持部１０２に保持されていない場合は、当該情報を取得する必要があるとして、当該情報をサーバ装置１１１から取得するとともに、スリープ応答を端末装置に通知した。別の例として、前述したように、当該情報が情報保持部１０２に保持されているものの、有効期限が過ぎている場合、または取得後一定期間が経過しているなど、当該情報がサーバ装置１１１で更新されている可能性があると判断される場合は、当該情報を取得する必要があるとして、当該情報をサーバ装置１１１から取得するとともに、スリープ応答を端末装置に通知してもよい。また、要求された情報が端末装置１１０に返すことが許容されていない場合は、当該情報が蓄積されていなくても、当該情報を取得する必要がないと判断してもよい。このように、本実施形態では、端末装置から取得要求された情報をサーバ装置から取得する必要があるか否かをあらかじめ定められた条件に基づき判定し、取得する必要がある場合は、当該情報をサーバ装置１１１から取得するとともに、スリープ応答を端末装置に通知する。

以上が、本通信装置１００の第１の実施形態である。

＜第２の実施形態＞
《第２の実施形態：構成要素の説明》
続いて、第２の実施形態について述べる。第２の実施形態は、第１の実施形態で示した機能に加え、端末装置１１０に対して特定の情報へのアクセスを促す応答を送信する機能を具備する。本実施形態における通信装置４００の機能ブロック図を図４に示す。なお、図1と同じ機能を備える要素には同一番号を付し、説明は省略する。

新たに追加された情報変換部４０３は、サーバ装置１１１より取得した情報を端末装置１１０に適した形式へと変換する機能を備える。ここで『適した』とは、表示サイズを小さくしたり、一部の情報を圧縮などの操作により、端末装置１１０が表示できるもしくは処理できるデータ量もしくはデータ形式になっていることを指す。変換した情報は他の情報と同様に情報保持部４０２に蓄えられる。なお、情報変換部４０３は、格納された情報（変換した情報）を区別するためのキーも生成する。キーは情報のURLと端末装置１１０ の情報（ＩＰアドレスやポート番号、使用する通信プロトコル、さらに端末装置の画面サイズなども使用できる）、変換条件から導出するものとし、オリジナルのキー（変換前の情報のキー）とは異なるようにする。生成したキーは情報保持部４０２で使うとともに、スリープ応答に含めるため要求処理部４０１にも伝えられる。なお、オリジナルのキーと生成したキー、さらに端末装置１１０に関連した情報とを関連付け、適切な形で保持する記憶部（図示せず）を備えていても良い。

情報保持部４０２はオリジナルの情報に加えて、情報変換部４０３で変換された情報を合わせて保存することを特徴とする。

要求処理部４０１は、第１の実施形態における要求処理部１０１の機能に加え、端末装置１１０の種類（たとえば端末装置１１０がスマートフォン等の所定の移動体端末に該当するか否か）を判断して、情報変換の要否を決定する機能を備える。情報変換が必要と判断された場合には、情報変換部４０３に対して指示を出す。この指示には、変換後の情報を特徴づけるパラメータ（例えば画像サイズ、情報分割の要否、情報分割時に１回の取得要求に対して送信するデータサイズ、など）を含んでもよい。また、変換が必要と判断した場合には、応答生成部４０５に対してスリープ応答の生成を指示する際に、変換後の情報を参照するような応答を生成するように指示を出す。

《第２の実施形態：動作シーケンスの説明》
図５に本実施形態の動作シーケンスを示す。ただし、第１の実施形態と共通の部分については省略すると共に、処理内容が変わらないステップには同じ番号を付している。

通信装置４００が要求された情報を保持していない場合（ステップＳ２０５−ＮＯ）、端末装置１１０の特徴を推定する処理を行う（Ｓ５００）。この処理は、ＨＴＴＰを例にすればヘッダ中に含まれるＵｓｅｒ−Ａｇｅｎｔの情報を用いればよい。

推定に基づいて、変換が必要か否かを判断する（ステップＳ５０１）。この判断条件は静的に記憶部（図示せず）に保存されているものとする。変換が不要と判断された場合（Ｓ５０１−ＮＯ）、第１の実施形態と同じ処理を行って終了する。変換が必要と判断された場合（Ｓ５０１−ＹＥＳ）は、変換に必要な各種処理を実施する。

最初に要求処理部４０１から情報変換部４０３に対して、新たなキーの生成を要求する。情報変換部４０３は対象の情報を特定するURLと端末装置１１０の情報と変換条件（変換方法）とに基づいて、変換後の情報を特定する新たなキーを生成する（ステップＳ５０２）。生成したキーは要求処理部４０１に返す。要求処理部４０１は通知されたキーとともに応答生成部４０５に対して『スリープ・リダイレクト応答』を生成するように指示を出す。応答生成部４０５はスリープ時間算出部１０６を用いてスリープ時間を求め（Ｓ２０８）、その情報を用いてスリープ・リダイレクト応答を生成する（Ｓ５０４）。生成したスリープ・リダイレクト応答は要求処理部４０１に返され、要求処理部４０１から端末装置１１０に送信される（ステップＳ５０５）。

スリープ・リダイレクト応答を送信した後、第１の実施形態と同様にしてサーバ装置１１１から情報を取得する。情報取得後、変換が不要と判断されている場合には（Ｓ５０６−ＮＯ）、第１の実施形態と同様に応答を返して終了する（Ｓ２０６、Ｓ２０７）。一方、変換が必要と判断されている場合には（Ｓ５０６−ＹＥＳ）、要求処理部４０１は情報変換部４０３に変換の指示を出して受信した情報を変換する指示を出す。情報変換部４０３はステップＳ５０２で参照した変換条件に基づいて変換する（Ｓ５０７）。変換した情報は、オリジナルの情報と共に情報保持部４０２に保存される（ステップＳ５０８）。その後、第１の実施形態とは異なり、動作を終了する。スリープ・リダイレクト応答を送信した場合、同応答で通知した情報に対する取得要求を端末装置１１０から新たに受信することを想定している。そのため、オリジナルの情報や変換した情報を直接送信する必要がない。スリープ・リダイレクト応答に対する端末装置１１０の動作シーケンスを図６に示す。スリープ・リダイレクト応答を受信した（Ｓ５１０）端末装置１１０は、当該応答に含まれる時間だけスリープし（Ｓ５１１）、その後、起動して、変換された情報への取得要求を通信装置４００に送信する（Ｓ５１２）。

《第２の実施形態：スリープ・リダイレクト応答の説明》
本実施形態にて使用する『スリープ・リダイレクト応答』について、ＨＴＴＰを使用する場合を例にして説明する。スリープ・リダイレクト応答は、ＨＴＴＰのリダイレクト応答（ステータスコード：３０３）に対して、図３（Ｅ）のようなスリープ時間を追加したものである。図７にこの一例を示す。

《第２の実施形態：その他の補足事項》
本実施形態の説明において、情報保持部４０２はオリジナルの情報と端末装置１１０向けに変換された情報の両方を保存するとした。しかし、情報保持に必要なサイズを考慮してどちらか一方の情報だけを保持するようにしても良い。例えば、オリジナルだけを情報保持部に蓄積し、応答生成の際に毎回変換処理を行うようにしてもよい。逆に、変換された情報だけを保持し、後続する情報取得要求には無条件に変換された情報を返すようにしても良い。なお、変換された情報だけ格納し、送信時に逆変換（たとえば元のサイズに戻す。画質は低下する可能性もある）することも可能である。

本実施形態の説明においては、スリープ・リダイレクト応答を生成し、必ず新しい情報取得要求を受信するものとして説明した。しかし、再要求にかかるコスト（時間や電力等）を鑑み、再要求することなく直接変換された情報を応答として送信するように実装しても良い。その場合、ステップＳ５０８の後に応答生成(ステップＳ２０６)と送信処理（ステップＳ２０７）が続くことになる。

本実施形態の説明においては、端末装置１１０が要求する全ての情報を変換する場合について述べた。しかし、一部の情報は変換せず、一部の情報を変換するように実現してもよい。例えば、ＨＴＭＬファイルは変換することなく、画像ファイルのみを変換するような処理を行ってもよい。ＨＴＭＬファイルを変換しない場合、ＨＴＭＬファイルにはスリープ応答を返しておき、個々の画像ファイルが要求された時に変換後の画像ファイルを返すようにすればよい。また、ＨＴＭＬファイルを変換する場合にも、同ファイルに記載された画像ファイルに対するＵＲＬを、変換後の画像を取得するように書き換えるという方法も可能である。

＜第３の実施形態＞
続いて第３の実施形態について述べる。本実施形態は第１もしくは第２の実施形態に対して、ウェブページの構成要素を事前に取得するプリフェッチ機能を追加するものである。なお、ここで述べるプリフェッチ機能とは、最初に要求したHTMLファイルから参照されている埋め込みオブジェクト（画像ファイル、スクリプトファイル、スタイルシートなど）を事前に取得する機能を指す。無条件に情報を取得するわけではない。

《第３の実施形態：構成要素の説明》
本実施形態における通信装置８００の機能ブロック図を図８に示す。第２の実施形態に比べ、プリフェッチ部８０２が追加されている。プリフェッチ部８０２は端末装置１１０に代わって情報取得要求を生成する。その際生成する要求は、要求処理部８０１にて受け付けた要求に基づいてサーバ装置１１１から取得した情報から再帰的に要求される情報に対する要求である。

例えばＨＴＴＰを用いてウェブページを要求する場合を考える。ウェブページはその構成と文字情報を提供するＨＴＭＬファイル、ページのデザインに関する情報を提供するスタイルシート、スクリプトファイル、画像ファイルなどで構成されている。端末装置１１０はこれらのファイルをすべて取得しなければウェブページを正確に表示できない。通常、端末装置１１０は最初にＨＴＭＬファイルを取得し、その内容を解析して初めてスタイルシートやスクリプトファイル、画像ファイルが参照されていることを把握する。このため、多数の取得要求が順次生成され、通信効率が悪くなってしまう。

本プリフェッチ部８０２は、要求処理部８０１にて受信した要求がＨＴＭＬファイルに対するものだった場合に機能する。当該ＨＴＭＬファイルを要求処理部８０１から受け取り、同ファイルを解析する。そして参照されている他のファイルを特定し、端末装置１１０の要求とは独立に、順次それらのファイルに対する取得要求を生成する。取得要求は要求処理部８０１を介してサーバ装置１１１に送信され、第１もしくは第２の実施形態と同様にして処理される。

《第３の実施形態：動作シーケンスの説明》
図９Ａおよび図９Ｂに本実施形態の動作シーケンスを示す。この図は第１の実施形態に対して機能を追加したものであるが、第２の実施形態に対しても同様に追加できる。なお、これまでと同じ機能を実現するものについては同じ番号を付している。

情報保持部４０３が要求された情報を保持していない場合（Ｓ２０５-ＮＯ）、
ステップＳ９０１において、サーバ装置１１１から取得する情報が再帰的な情報取得が必要なものであるかどうかを判断する。例えば、取得要求された情報が、ＨＴＭＬファイルかどうかを判断する（先に述べたようにＨＴＭＬファイルに含まれる画像等のファイルを再帰的に取得する必要がある）。

再帰的な取得が不要と判断した場合（Ｓ９０１-ＮＯ）かつプリフェッチ部からの要求ではない場合（Ｓ９１０−ＮＯ）に限り、第１の実施形態と同様の処理を行う（Ｓ２０８〜Ｓ２１０）。その後、第１の実施形態と同様に、要求された情報を取得する（Ｓ２１１〜Ｓ２１３）。また、再帰的な取得が必要な場合（Ｓ９０１−ＹＥＳ）またはプリフェッチ部からの要求である場合（Ｓ９１０のＹＥＳ）も、第１の実施形態と同様に、要求された情報を取得する（Ｓ２１１〜Ｓ２１３）。Ｓ９０１−ＹＥＳの場合（再帰的な取得が必要な場合）としては、たとえば取得要求がＨＴＭＬファイルにかかるものである場合が挙げられる。また、Ｓ９１０−ＹＥＳの場合（プリフェッチ部からの要求である場合）としては、本フローが、再帰的に取得される情報に対する取得要求がプリフェッチ部から受信された場合がある。

情報を取得した後は、再帰的な取得の要不要で処理が異なる。再帰的な取得の処理が不要の場合（Ｓ９０２-ＮＯ）には、当該要求がプリフェッチ部８０２により発せられたかを確認する（Ｓ９０８）。プリフェッチ部８０２からではない場合（Ｓ９０８-ＮＯ）、第１の実施形態と同様にして応答を返し（Ｓ２０６、Ｓ２０７）、処理を終了する。一方、プリフェッチ部８０２からの要求だった場合（Ｓ９０８-ＹＥＳ）、情報そのものを返す必要が無いので、取得が完了した旨をプリフェッチ部８０２に通知し（Ｓ９０９）、処理を終了する。

再帰的な情報取得が必要と判断した場合（Ｓ９０２-ＹＥＳ）、要求処理部８０１はＳ２１１により取得した情報（第１の情報）をプリフェッチ部８０２に通知する。プリフェッチ部８０２は第１の情報を解析して、再帰的に取得すべき情報（第２の情報）を抽出する（Ｓ９０３）。その後、抽出した第２の情報を要求処理部８０１に返す。

要求処理部８０１はプリフェッチ部８０２から受け取った第２の情報を応答生成部８０３に通知し、スリープ応答の生成を依頼する。応答生成部８０３は通知された第２の情報をスリープ時間算出部８０４に通知し、スリープ時間の算出を依頼する。スリープ時間算出部８０４は通知された第２の情報（複数の場合にはすべての情報）を取得する際の合計取得時間を算出し、応答生成部８０３に返す（Ｓ９０４）。

応答生成部８０３は受け取ったスリープ時間を用いてスリープ応答を生成し、要求処理部８０１に返す（Ｓ９０５）。要求処理部８０１は受け取ったスリープ応答を端末装置１１０に送信する（Ｓ９０６）。その後、第２の情報に対するプリフェッチ処理を実行する（Ｓ９０７）。なお、本通信装置が複数の処理を並行して実行できる場合、スリープ応答に関する処理（Ｓ９０４〜Ｓ９０６）とプリフェッチ処理とは並行して実行してもよい。プリフェッチ処理の詳細については後述する。

プリフェッチ処理が完了したら、後処理を実行する。最初に要求された第１の情報に対する情報応答を生成し（Ｓ２０６）、端末装置１１０に向けて送信する（Ｓ２０７）。なお、第２の情報については、端末装置１１０からの第２の情報の取得要求を受けて、送信する（Ｓ２０１〜Ｓ２０５のＹＥＳ、Ｓ９０８のＮＯ、Ｓ２０６、Ｓ２０７）。

なお、上記フローの変形例として、ステップＳ９０１がＹＥＳのときにステップＳ２０ ８〜Ｓ２１０と同様の処理を実行してスリープ応答（たとえば第１の情報を取得するのに要する時間に基づいたスリープ時間を含める）を返すようにしてもよい。これにより、第２の情報を取得する間のみならず、第１の情報を取得する間も、端末をスリープ状態にして、さらなる低消費電力化を図ることができる。

《第３の実施形態：プリフェッチ処理の説明》
続いて本実施形態のプリフェッチ処理（Ｓ９０７）について詳細に述べる。ここでは理解を助けるためウェブページを例に説明するが、再帰的に情報を取得する必要がある他の形式でも同様に扱うことができる。他の形式として、例えば、取得すべき情報のＵＲＬが１つ以上記載されたテキストファイル、ＲＳＳなどの更新情報を記載したファイルやそれに基づくウェブサービス、などがある。

端末装置１１０からウェブページを取得する要求を受け付けた場合、第１の情報はＨＴＭＬファイルとなる。ＨＴＭＬファイルには多数のタグが含まれており、その中には外部のファイル（スタイルシート、スクリプトファイル、画像ファイルなど）を参照するタグがある。ステップＳ９０３ではこれらのタグに含まれるＵＲＬを抽出し、適切にリスト化しておく。抽出する対象となるタグの一例として図１０を挙げる。

プリフェッチ部は抽出したＵＲＬのリストに対して、事前に定められた基準に従って、取得要求を生成し、要求処理部８０１に通知する。要求処理部８０１は端末装置１１０からの取得要求と同様に、前記要求を処理する。すなわち、情報保持部４０２に適切に情報が蓄積されていく。ただし、ステップＳ９１０の分岐やステップＳ９０８の分岐にある通り、プリフェッチ部８０４からの要求であればスリープ応答（スリープ・リダイレクト応答）や情報応答は送信しない。また、要求を生成する前に情報確認部１０３を介して情報保持部４０２への蓄積状態を確認し、既に蓄積されていれば取得要求を生成しないようにしてもよい。

抽出した全てのＵＲＬに対して情報を取得・蓄積したらプリッフェッチ処理は終了となる。

《第３の実施形態：プリフェッチする順序》
抽出した第２の情報に対してプリフェッチを実行する順序は、例えば以下の方法が適用できる。他の方法を用いたとしても本発明の範囲は逸脱しない。また、これらの方法は情報を提供するサーバ装置１１１ごとやＵＲＬごとに変更してもよい。これらを実現するために必要な条件は、図示しない記憶部に適切に保存されているものとする。

・ 抽出元の情報に出現した順
・ 情報の種類ごとに事前に決められた順（例：スタイルシート→スクリプトファイル→画像ファイル→動画ファイル）
・ 情報の推定ファイルサイズが小さい順（推定ファイルサイズとは、過去の取得情報等に基づいて情報の種類ごとに決めたサイズ。過去に取得した情報のサイズは、図示しない記憶部に適切に保存されているものとする。）

《第３の実施形態：プリフェッチを実行する場合のスリープ時間算出方法》
本実施形態はスリープ時間の算出方法が第１もしくは第２の実施形態と異なる。第１・第２の実施形態では１つの情報を取得するために必要なおおよその時間をスリープ時間として算出していた。本実施の形態では、プリフェッチを行うため、再帰取得が必要な全情報の取得に要する時間をスリープ時間とみなして算出する。

基本的な算出方法は第１の実施形態で述べた方法に準じ、取得すべき情報の数だけ足し合わせる。ただし、プリフェッチ部８０２が複数の情報を同時に取得する場合には単純に足すことができない。例えば、第１の実施形態で述べた第１の方法（固定値を使用する方法）に対しては、取得する情報の総数に応じていくつかのスリープ時間を定義するようにしてもよい。また、
｛Σ（各情報に対する固定値）｝÷（並列度）＋α
としても良い。第１の実施形態で述べた第２の方法（RTTを使用する方法）に対しては、
（RTT×取得する情報の数）÷（並列度）＋α
とする方法が考えられる。（第１の実施形態で述べた）第３の方法（想定サイズとスループットを使用する方法）に対しては、スループットが一定であることを考慮して、
Σ（各情報に対する想定サイズ）÷｛（スループット）÷（並列度）｝＋α
とすればよい。第１の実施形態で述べた第４の方法（保持されている通信時間をそのままスリープ時間とする方法）に対しては、既に並列度を考慮した通信時間が蓄積されていると考えられるので、単純に足し算すればよい。

《第３の実施形態：第２の実施形態と組み合わせる場合》
先の説明では第１の実施形態と組み合わせる場合について述べたが、第２の実施形態と組み合わせることも可能である。その場合、図９ＢのＳ２１１で取得した情報を適宜変換する処理を追加すると共に、Ｓ９０４〜Ｓ９０６で生成する応答をスリープ・リダイレクト応答にすればよい。また、プリフェッチ部８０２により取得する第２の情報についても適宜変換処理を実行したうえで、情報保持部４０２に蓄積すればよい。

《第３の実施形態：その他の補足》
これまでの説明では全ての情報を取得するまでの時間をスリープ時間として算出するとした。しかし、全ての情報を取得すると非常に長い時間を要する場合（例えば動画ファイル等が含まれると考えらえる場合）や、情報保持部１３０７の記憶容量が不足すると考えられる場合（情報保持部１３０７の容量が限定的な実装の場合）には、全ての情報を取得するまでの時間とは異なる値をスリープ時間として用いてもよい。すなわち、事前に決められた上限時間や、想定されるスループットで利用可能な記憶領域のサイズ（情報保持部の空き領域サイズ、またはフレームの送受信等の通信処理で使用するバッファの残量）に相当するデータを受信した場合に必要となる時間などである。

なお、このようなスリープ時間を通知した場合、本通信装置８００は一部の情報を含む情報応答を端末装置１１０に送信し、後続の情報応答があることを示せばよい。例えば、各データ転送の間でＴＣＰ接続を切ることなく保持し続けて転送だけを一時的に停止する方法や、細かな単位になるようにＨＴＴＰの応答を分割するなどの方法が考えられる。また、各情報応答に対してスリープ時間に関する情報を追加し、端末装置１１０が情報取得ごとにスリープ状態に遷移するのを促してもよい。

＜第４の実施形態＞
これまでの実施形態では、スリープ応答やスリープ・リダイレクト応答にスリープ可能な時間を含めてきた。本実施形態では総データサイズを返すようにする。この応答を受信した端末装置１１０４では、受信したデータサイズに基づき、スリープ時間を決定する。たとえば、データサイズとスリープ時間との対応を保持した関数またはテーブルを用意しておき、このテーブルと、受信したデータサイズとからスリープ時間を決定してもよい。当該テーブルは、通信装置からもらうようにしてもよいし、ユーザが登録してもよい。または、端末装置自身の過去の通信から、データサイズと、当該データサイズのデータ受信に要した時間とを記録しておき、この記録をもとにスリープ時間を算出してもよい。

《第４の実施形態：構成要素の説明》
本実施形態を実現する通信装置１１００の構成を図１１に示す。変更点は要求処理部１１０１、応答生成部１１０２、通信情報保持部１１０３である。

要求処理部１１０１の変更点は、スリープ応答もしくはスリープ・リダイレクト応答に総データサイズを含む形式の応答を送信することである。また、総データサイズの算出に過去の情報を利用する場合には、通信で取得した情報のデータサイズを逐次記録する機能が必要である。

応答生成部１１０２の変更点は、スリープ時間に代わり、総データサイズを含む応答を生成することである。データサイズに関する情報は、要求処理部１１０１から通知される第２の情報（プリフェッチすべき情報）のリストを用いて通信情報保持部１１０３から取得する。

通信情報保持部１１０３は、データサイズに関する情報を保持することが必須となる。この情報は第１の実施形態などで述べているとおり、通信を行うたびに更新してもよいし、設計時に決めた値を固定的に使用してもよい。

《第４の実施形態：構成要素の説明》
本応答生成部１１０２が生成する応答の例を図１２に示す。図１２上は変換機能を利用しない場合（第１の実施形態＋プリフェッチ機能に相当）であり、図１２下は変換機能を利用する場合（第２の実施形態＋プリフェッチ機能に相当）である。どちらの場合も、“Ｔｏｔａｌ−Ｌｅｎｇｔｈ”というヘッダが追加され、その値としてＳが設定されている。先に述べたとおり、
Ｓ＝ΣＳｉ （Ｓｉは各第２の情報のサイズ）
である。

＜第５の実施形態＞
第５の実施形態では、これまでに述べてきた通信装置の機能を端末装置内に組み込んだ形態を示す。なお、ここでは第３の実施形態で示した通信装置の機能を端末装置に組み込む場合を説明するが、他の実施形態であっても同様に組み込める。

《第５の実施形態：構成要素の説明》
図１３に本実施形態における端末装置１３００の構成を示す。本端末装置は大きく４つの部分で構成される。演算部１３０１、記憶部１５０２、ネットワークインタフェース１３０３、その他のデバイス１３０４である。

演算部１３０１は、端末装置を司るＯＳやアプリケーションソフトウェア（例えばウェブブラウザ）などが動作するプロセッサである。記憶部１３０２は演算部１３０１が使用する情報やプログラムなどを格納するメモリ並びに大容量記憶装置である。ネットワークインタフェース１３０３は第３の実施形態の通信装置の要素と同様の要素を搭載したネットワークインタフェースである。その他デバイス１３０４はこの図に含まれないその他のデバイスであり、例えばディスプレイコントローラやＵＳＢコントローラなどである。演算部１３０１は、記憶部１３０２からプログラムを読み出して実行することにより、ネットワークインタフェースの制御を含む、端末全体の制御を行う。

ネットワークインタフェース１３０３の内部構造ならびに動作は第３の実施形態に準ずる。ただし、以下の点が異なる。

第１の変更点は、端末装置１１０からネットワークを介して取得要求を受信していたのに対して、本実施形態では演算部から直接指示されることである。演算部１３０１からの指示は、一般に、演算部１３０１がネットワークインタフェース１３０３のデバイスドライバに指示を出し、同デバイスドライバが適切な形に変換してネットワークインタフェース１３０３に指示を出す形で実現される。

第２の変更点は、要求処理部１３０５からの応答をネットワーク経由で送信せず、内部バス等を介して送信することである。この対象はスリープ応答、スリープ・リダイレクト応答、情報応答のいずれもが対象である。

上記第２の変更点について補足する。これまで述べた他の実施形態では、スリープ時間を情報応答と同じ通信プロトコルを使って送信するケースを中心とした。しかし、本実施形態では演算部１３０１とネットワークインタフェース部１３０３が内部バス等で接続しているため、スリープ時間はレジスタを用いて通知し、情報応答は内部バスを用いて返すなどの方法が可能である（従来の方法でも可能である）。レジスタはたとえば要求処理部１３０５に組み込むことができる。この方法を取る場合、スリープ通知は通信プロトコルの動作とは独立に通知することができる。よって、一度スリープ時間を通知した後にもその時間を更新することが可能である。例えばネットワークの状態が変化し、ネットワークインタフェース１３０３による情報取得に時間を要したとしても、都度最適なスリープ時間に更新することができる。演算部１３０１は一時的に動作状態になるがレジスタの値を確認し、再びスリープ状態に遷移することができる。ここでは演算部１３０１がスリープ状態に遷移する場合を示したが、記憶部１３０２、その他のデバイス１３０４がスリープ状態に遷移してもよい。

第３の変更点は、要求処理部１３０５からの応答が存在することを、割り込み信号線やレジスタ等を介して演算部１３０１に通知することである。

上記第３の変更点について補足する。第３の実施形態における補足で述べたように、全情報の取得に非常に長い時間を要する場合や利用できる情報取得部１３０７のサイズが少ない場合には、それを考慮したスリープ時間を含むスリープ応答を演算部１３０１に返すことができる。また、一部の情報を取得した段階で、情報応答を返すことができる。この際、演算部１３０１に対してネットワークインタフェース１３０３から割り込み処理を要求する方法や、通知したスリープ時間で起動した演算部１３０１がネットワークインタフェース部１３０３の特定レジスタの状態をポーリングする方法等によって、情報応答を返せる状態になったことを検出することができる。

《第５の実施形態：その他の説明》
本実施形態の動作シーケンス等は第３の実施形態に準じるため省略する。

また、本実施形態ではスリープ・リダイレクト応答が必ずしも必要ない。内部バスで直結しているため、アプリケーションに対して動作の変更を外部から指示することなく、変換後のデータを直接利用すればよい。その場合、スリープ・リダイレクト応答によるスリープ時間の通知についてはレジスタ等を用いて行えばよい。

＜第６の実施形態＞
第６の実施形態では、第５の実施形態で端末装置内に組み込んだ機能の一部をサーバ装置側で実行する場合について述べる。

《第６の実施形態：構成要素の説明》
図１４に本実施形態における端末装置１４００とサーバ装置１４１０を示す。なお、サーバ装置１４１０は本実施形態に直接関与しない部分は省略している。

端末装置１４００は、応答の生成にかかわる部分が削除されたことを除き、第５の実施形態と同じである（サーバ装置が登場する関係で番号は振りなおしている）。サーバ装置１４１０の構成は次の通りである。

記憶部１４１５はサーバ装置１４１０が保有する情報を保持する大容量記憶装置である。

通信処理部１４１１は、端末装置１４００との間の通信処理を行う。すなわち、情報の取得要求を受信し、その内容に適した情報が記憶部１４１５に保持されていれば、それを応答として送り返す。

応答生成部１４１２は、端末装置に送信する応答を生成する。生成に必要な情報は記憶部１４１５またはスリープ時間算出部１４１３から取得する。

スリープ時間算出部１４１３は、要求を送信した端末装置１４００がスリープできると思われる時間を算出し、応答生成部１４１２に通知する。スリープ時間の算出方法については後述する。

通信情報保持部１４１３は、スリープ時間の算出に必要な各種通信情報を保持する。例えば、過去に端末装置１４００と行った通信から算出したRTTやスループット等である。ただし、第１の実施形態にて述べたように、通信情報保持部に保持する情報はネットワーク毎にまとめて平均値を記録するなどしてもよい。スループットについては、要求された情報のサイズとそれを端末装置に送信するのに要した時間からサーバ装置１４１０側で算出する。

なお本実施形態ではサーバ装置１４１０は、記憶部１４１５に情報を大量に蓄積して、端末装置から要求された情報を記憶部１４１５から読み出して返すサーバ機能（Webサーバ等）を備えているとしたが、通信処理部、スリープ時間算出部、応答生成部および通信情報保持部を格納した、Webサーバ等とは独立した別個のサーバを実現することも可能である。この場合、当該別個のサーバは、端末装置からの取得要求を１次受けし、当該取得要求にかかる情報をWebサーバ等のサーバ装置から取得し、内部の情報保持部に蓄積し、端末装置に返す。別個のサーバは、サーバ装置と端末装置とのそれぞれの通信特性等を考慮して、スリープ時間を算出する。

《第６の実施形態：動作シーケンス》
端末装置１４００の動作については、第５の実施形態とほぼ同様である。ただし、スリープ時間の算出は端末装置１４００では行わない。本実施形態では、スリープ時間はサーバ装置１４１０からの応答に含まれている。演算部１４０１は、受信した応答を直接解釈してスリープ時間を把握してスリープ状態へと遷移するように制御する。もしくは、演算部１４０１は、要求処理部１４０９が応答から抽出したスリープ時間をレジスタ経由で入手してスリープ状態へと遷移するように制御する。それ以外の部分については、第５の実施形態と同じである。

続いて、サーバ装置１４１０の動作を述べる。そのシーケンスを図１５に示す。サーバ装置１４１０は端末装置１４００から取得要求を受信するまで待機する（Ｓ１５０１）。取得要求を受信すると（Ｓ１５０２−ＹＥＳ）、通信処理部１４１１にてその要求を解析し（Ｓ１５０３）、適切な応答の生成を応答生成部１４１２に依頼する。スリープ時間算出部１４１３がスリープ時間を算出し（Ｓ１５０４）、応答生成部１４１２はスリープ時間算出部１４１３からスリープ時間を受け取ると共に、記憶部１４１５から要求された情報を取り出す（Ｓ１５０５）。そして、応答生成部１４１２は、応答を生成して通信処理部１４１１に返す。通信処理部１４１１は生成された応答を端末装置１４００に返す。たとえばスリープ時間を含む応答と、情報を含む応答を端末装置４００に返す。端末装置１４００ではたとえば演算部１４０１がスリープ時間だけスリープ状態に遷移し、その間、ネットワークインタフェース１４０３が、サーバ装置１４１０からの情報を含む応答を受信し、情報を情報保持部１４０６に蓄積する。

通信情報保持部１４１４に保持されている情報の例を図１６に示す。列Ｓ１６０１はHTMLファイルを要求された場合の例であり、総サイズが３００KBであることを示している。この３００KBはHTMLファイルから静的に参照されている情報の総サイズである。例えば、HTMLファイルから参照されるJavaScriptファイルに記載されたスクリプトを、端末装置１４００が実行することで参照されるファイルの情報は含まれない。これはスクリプトを実行するタイミングまでファイルの要否が分からないからである。一方、列Ｓ１６０２はサーバ側で動的に実行されるスクリプトに対する例である。総サイズ７５６KBは、スクリプトから必ず参照される情報の総サイズである。HTMLファイルの場合と同様に端末装置１４００側で実行するまで要否が分からないファイルは、このサイズには含まれない。

図１７に本実施形態の変形例にかかる端末装置１７００とサーバ装置１７１２を示す。なお、サーバ装置１７１２は本実施形態に直接関与しない部分は省略している。図１４と異なり、スリープ時間算出部１７１０が、サーバ装置１７１２ではなく、端末装置１７００のネットワークインタフェース１７０３内に設けられている。また通信情報保持部が、サーバ装置１７１２だけでなく、端末装置１７００のネットワークインタフェース１７０ ３にも設けられている。本変形例では、スリープ時間の算出を、サーバ装置１７１２ではなく、端末装置１７００で行う点が、図１４の構成と大きく異なる。以下、変更部分についてのみ説明する。

応答生成部１７１４は、通信情報保持部１７１５に格納された情報を用いて、スリープ応答を作成する。たとえば、取得要求された情報のサイズを通信情報保持部１７１５から取得して、スリープ応答に含める。端末装置１７００の通信情報保持部１７１１は、スリープ時間の算出に必要な情報を保持する。たとえばサイズとスリープ時間との対応テーブルでもよいし、過去に行った通信から算出した通信特性情報でもよい。スリープ時間算出部１７１０は、通信情報保持部１７１１に格納された情報と、スリープ応答に含まれるサイズ情報に基づきスリープ時間を算出する。要求処理部１７０５は、スリープ時間をレジスタ経由または内部バス上のメッセージ交換で、演算部１４０１に通知する。

＜第７の実施形態：第１〜第６の実施形態の具体的なハードウェア構成＞
図１８は、第１の実施形態の通信装置のハードウェア構成例を示す。

図１の情報確認部１０３、要求処理部１０１、応答生成部１０５およびスリープ時間算出部１０６は演算部１８０１としてまとめられ、たとえばＣＰＵ上のソフトウェアとして表現される。情報保持部１０２および通信情報保持部１０４は、メモリ１８０２ａやディスク１８０２ｂ等の記憶装置として実現される。ネットワークＩ／Ｆ１は端末装置１１ ０側のネットワークインタフェースであり、ネットワークＩ／Ｆ２はサーバ装置１１１側のネットワークインタフェースである。

図１９は、図１８の構成の変形例を示す。ネットワークＩ／Ｆ１およびネットワークＩ／Ｆ２を１つのネットワークＩ／Ｆ１８０５にまとめたものである。端末装置１００とサーバ装置１１１は同じネットワークに接続されている場合の構成である。

図２０は、第２の実施形態の通信装置のハードウェア構成例を示す。

図４の情報処確認部１０３、要求処理部４０１、応答生成部４０５およびスリープ時間算出部１０６は演算部１８１１としてまとめられ、たとえばＣＰＵ上のソフトウェアとして表現される。情報変換部４０３は、単独の専用回路である演算部１８１９として構成される。図１８のように情報変換部４０３も演算部１８１１にまとめて構成してもよい。情報保持部４０２および通信情報保持部１０４は、メモリ１８１２ａやディスク１８１２ｂ 等の記憶装置として実現される。ネットワークＩ／Ｆ１８１５は、端末装置１１０およびサーバ装置１１１が接続されるネットワークとのインタフェースである。

第３および第４実施形態の通信装置（図８、図１１）も、図１８〜図２０と同様にして構成できる。プリフェッチ部は演算部１８０１または演算部１８１１にまとめてもよいし、演算部１８１９のように単独の演算回路として構成してもよい。

図２１は、第５の実施形態の端末装置のハードウェア構成例を示す。

図１３に示したネットワークインタフェース１３０３内の構成を、図１と同様の物理構成とすることができる。要求処理部１３０５、情報確認部１３０６、情報変換部１３０８、応答生成部１３０９、スリープ時間算出部１３１０およびプリフェッチ部１３１２を演算部１８３１としてまとめて、たとえばＣＰＵ上のソフトウェアとして表現される。ネットワークＩ／Ｆ１８３５はサーバ装置１１１側のネットワーク１１２に接続され、内部バスＩ／Ｆ１８３６は内部バスに接続されている。情報保持部１３０７および通信情報保持部１３１１は、メモリ１８３７ａや不揮発性メモリ１８３７ｂ等の記憶装置として表現される。

図２２は、図２１の構成の変形例を示す。演算部１８３１からプリフェッチ部１３１２の機能を分離させて、単独の回路（演算部）１８４５として構成した例を示す。プリフェッチ部１３１２以外の部分は、演算部１８４１とする。このようにネットワークインタフェース１３０３内の機能を複数の演算部として実装することもできる。

図２３は、図２１の構成の別の変形例を示す。図２１の演算部１８３１が備えていた通信処理機能（図１３では要求処理部１３０５が備えていた通信処理機能）を分離させて、単独の回路として通信処理部１８３８を配置したものである。ＣＰＵ等の演算部１８３１が行っていた通信処理（TCP/IPなど）の一部または全部を通信処理部１８３８がCPU等に代わって実行することで、ＣＰＵ等の負荷を下げ、別の処理に集中することができる。

＜第８の実施形態＞
図２４は本発明の実施形態に係るシステムを示す。代理取得装置２００４ならびに状態制御装置２００５が、インターネット等のバックボーンを構成する有線ネットワークである第１ネットワーク２００７に接続され、第１ネットワーク２００７上のサーバ装置２００６と通信可能である。代理取得装置２００４ならびに状態制御装置２００５は、第２ネットワーク２００２にも接続され、第２ネットワーク２００２上の基地局を介して、端末装置２００１と通信可能である。なお、代理取得装置２００４は、ネットワーク２００７に直接接続される他、第２ネットワーク２００２および第１ネットワーク２００７間を接続するゲートウェイを配置し、このゲートウェイを介して第１ネットワーク２００７と接続してもよい。また、代理取得装置２００４ならびに状態制御装置２００５は、基地局を介して端末装置２００１と接続する他、端末装置２００１と直接、無線接続する構成も可能である。代理取得装置２００４は、端末装置２００１からの取得要求を受信して、必要な情報を第１ネットワーク２００７上のサーバ装置２００６から取得する装置である。サーバ装置２００６は第１の実施形態で述べたサーバ装置と同様のものである。状態制御装置２００５は、代理取得装置２００４と第１ネットワーク２００７または第２ネットワーク２００２を介して通信可能である。状態制御装置２００５は、端末装置の状態を制御する装置であり、一例として、端末装置２００１に対してスリープ状態への遷移指示を送信する。

図２５は、代理取得装置２００４と状態制御装置２００５の構成を示したものである。

代理取得装置２００４は、要求処理部２１０１と、情報保持部２１０２と、情報確認部２１０３と、応答生成部２１０４と、スリープ時間算出部２１０５と、通信情報保持部２１０６とを備える。状態制御装置２００５は、要求処理部２１０７を備える。本実施形態では、情報保持部２１０２、情報確認部２１０３、応答生成部２１０４、スリープ時間算出部２１０５、通信情報保持部２１０６は第１の実施形態と同様であるが、要求処理部２１０１の機能の一部が異なる。

要求処理部２１０１は、第１の実施形態で述べた要求処理部１０１（図１参照）と同様に、端末装置から情報の取得を要求する取得要求を受信する機能、要求された情報をサーバ装置から取得する必要があるかを判定する機能、取得する必要がある場合には要求された情報を取得する機能、取得した情報を端末装置に送信する出力機能、情報の取得に必要なネットワーク処理を行う通信処理機能などの機能を備えるが、応答生成部２１０４が生成したスリープ応答を端末装置に返す機能は備えない。第１の実施形態では、応答生成部からスリープ応答を受け取った要求処理部が端末装置にそのスリープ応答を送信していたが、本実施形態では、要求処理部２１０１は、応答生成部２１０４が生成したスリープ応答を、端末装置２００１ではなく、状態制御装置２００５に第２ネットワーク２００２を介して端末装置２００１の識別子と共に通知する。

状態制御装置２００５の要求処理部２１０７は、代理取得装置２００４から送信されたスリープ応答および対象となる端末装置の識別子を受信する。状態制御装置２００５の要求処理部２１０７は、代理取得装置２００４から通知されたスリープ応答と対象となる端末装置の識別子を受け取ると、該識別子で特定される端末装置に対してスリープ応答を第２ネットワーク２００２を介して送信する。すなわち、第1の実施形態で述べた要求処理部の機能のうち、端末装置にスリープ応答を送信する通知機能は、本実施形態では代理取得装置２００４とは別の状態制御装置２００５に備えられる。

なお、状態制御装置２００５は、該端末装置の識別子に対して自身が管理する別の識別子を対応づけて管理する記憶部を備えていても良い。また、状態制御装置２００５は、端末装置の識別子ごとに、端末装置の状態を維持管理する記憶部を備えていてもよい。さらに、状態制御装置２００５は、スリープ応答を、端末装置が解釈可能な方式に変換する機能を具備していてもよい。変換機能の一例として、ＨＴＴＰの応答メッセージとして代理取得装置２００４から通知されたスリープ応答を、セルラーネットワークで使用される制御信号や無線ＬＡＮで使用される制御信号に変換する機能などが該当する。

以上のように、第１の実施形態で述べた要求処理部の機能は、単一の装置内で実現される場合のみならず、複数の装置に分離して実現することが可能である。つまり、第１の実施形態で述べた要求処理装置が備える機能のうちスリープ応答を通知する機能を単独の装置として配置することで、端末装置（要求元）の状態を制御する装置を実現可能である。

尚、本実施形態の通信装置は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち通信装置内の各処理部は、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することが出来る。このとき、通信装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、CD-ROMなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、通信装置内の各記憶部は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはCD-R 、CD-RW、DVD-RAM、DVD-R等の記憶媒体などを適宜利用して実現することが出来る。

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

Claims (17)

1. 要求元から第１情報の取得要求を受信し、前記第１情報の取得先から前記第１情報を取得する必要があるか否かを、あらかじめ決められた条件に基づき判定する処理部と、
   前記処理部が前記第１情報を取得する必要があると判定した場合に、前記要求元に低消費電力状態への遷移指示を含む第１応答を通知する通知部と、
   を備えた処理装置。
2. 前記処理部は、前記第１情報が取得済みか否かを確認し、取得済みでなければ、前記第１情報を取得する必要があると判定する
   請求項１に記載の処理装置。
3. 前記処理部は、前記取得済みの第１情報の有効期限が過ぎている場合、または前記第１情報の取得から一定時間が経過した場合は、前記第１情報を取得する必要があると判定する
   請求項２に記載の処理装置。
4. 前記処理部は、前記第１情報が取得済みである場合は、前記第１情報を取得する必要がないと判定し、
   前記通知部は、前記取得済みの第１情報を含む第２応答を前記要求元に送信する
   請求項１ないし３のいずれか一項に記載の処理装置。
5. 前記処理部は、前記第１情報が取得済みでない場合は、前記第１情報を前記取得先から取得し、
   前記通知部は、前記処理部により取得された第１情報を含む第３応答を前記要求元に通知する
   請求項１ないし４のいずれか一項に記載の処理装置。
6. 前記第１情報を前記要求元に適合した形式に変換する変換部をさらに備え、
   前記通知部は、前記変換部により前記第１情報を変換した情報の取得要求の送信指示を含む前記第１応答を前記要求元に通知し、
   前記通知部は、前記要求元から第１取得要求が受信されると、前記変換部により前記第１情報を変換した情報を含む第４応答を前記要求元に出力する
   ことを特徴とする請求項１ないし５のいずれか一項に記載の処理装置。
7. 前記通知部は、前記要求元が低消費電力状態に遷移している時間を特定するための特定情報を含む前記第１応答を前記要求元に通知する
   ことを特徴とする請求項１ないし６のいずれか一項に記載の処理装置。
8. 前記第１情報を取得するのに要する時間情報に基づいて、前記要求元が低消費電力状態に遷移している時間を特定するための特定情報を算出する算出部
   をさらに備えたことを特徴とする請求項７に記載の処理装置。
9. 前記算出部は、前記第１の情報の取得先との間の通信特性と前記第１情報のサイズ情報の少なくとも１つに基づいて、前記第１情報を取得するのに要する時間情報を算出する
   ことを特徴とする請求項８に記載の処理装置。
10. 前記第１情報を解析し、前記第１情報から参照されている第２情報を前記第２情報の取得先から取得するプリチェッチ部と、
    前記第２情報を取得するのに要する時間情報、または前記第２情報のサイズ情報に基づき、前記要求元が低消費電力状態に遷移している時間を特定するための特定情報を算出する算出部と、を備え、
    前記通知部は、前記算出部が算出した特定情報を含む前記第１応答を前記要求元に通知する
    ことを特徴とする請求項１ないし９のいずれか一項に記載の処理装置。
11. 前記算出部は、前記第２情報の取得先との間の通信特性、前記第２情報のサイズ情報、および前記第２情報の個数の少なくとも１つに基づき、前記第２情報を取得するのに要する時間情報を算出する
    請求項１０に記載の処理装置。
12. 前記第１情報を解析し、前記第１情報から参照されている第２情報を前記第２情報の取得先から取得するプリチェッチ部と
    前記第１情報および前記第２情報を記憶する記憶部の残量、通信処理に関するバッファの残量、またはあらかじめ決められた上限時間、に基づいて、前記要求元が低消費電力状態に遷移している時間を特定するための特定情報を算出する算出部と、を備え、
    前記通知部は、前記特定情報を含む前記第１応答を前記要求元に通知する
    ことを特徴とする請求項１ないし１１のいずれか一項に記載の処理装置。
13. 前記処理部は、ネットワークを介して前記要求元から前記第１情報の取得要求を受信し、
    前記通知部は、前記ネットワークを介して前記第１応答を前記要求元に送信する
    請求項１ないし１２のいずれか一項に記載の処理装置。
14. 前記処理部は、内部バスを介して前記要求元から前記第１情報の取得要求を受信し、
    前記通知部は、前記第１応答を、レジスタ、または前記内部バス上のメッセージ交換により、前記要求元に通知する
    請求項１ないし１２のいずれか一項に記載の処理装置。
15. 要求元から第１情報の取得要求を受信し、前記第１情報の取得先から前記第１情報を取得する必要があるか否かをあらかじめ決められた条件に基づき判定する処理部と、前記処理部が前記第１情報を取得する必要があると判定した場合に、前記要求元に低消費電力状態への遷移指示を含む第１応答を通知する通知部と、を含むネットワークインタフェースと、
    プログラムを記憶する記憶部と、
    前記ネットワークインタフェースおよび前記記憶部と内部バスを介して接続され、前記記憶部からプログラムを読み出して実行することにより前記ネットワークインタフェース部を制御する演算部と、
    を備えた端末装置。
16. 前記要求元は、前記演算部である
    請求項１５に記載の端末装置。
17. 要求元から第１情報の取得要求を受信するステップと、
    前記第１情報の取得先から前記第１情報を取得する必要があるか否かをあらかじめ決められた条件に基づき判定するステップと、
    前記第１情報を取得する必要があると判定された場合に、前記要求元に低消費電力状態への遷移指示を含む第１応答を通知するステップと
    を備えた情報通信方法。

Images