(57)【要約】【課題】動的に変更される部分を有する情報を効率的に取得する。【解決手段】本発明の一態様としての通信装置は、第１〜第Ｎの要素を含む対象情報と、前記第１〜第Ｎの要素のバージョンを特定する第１〜第Ｎ更新情報識別子を記憶する記憶部と、前記第１〜第Ｎ更新情報識別子の全部または一部を含む取得要求を、ネットワークを介して取得先装置に送信する送信部と、前記取得要求により更新情報識別子が送信された要素の少なくとも１つの要素を更新するための第１更新情報と、前記要素の更新情報識別子を更新するための第２更新情報とを受信する受信部と、前記記憶部における前記要素を前記第１更新情報により更新し、前記要素の更新情報識別子を前記第２更新情報により更新する更新部と、を備える。【選択図】図２
2015052821.tif 000002
【特許請求の範囲】
【請求項１】
第１〜第Ｎの要素を含む対象情報と、前記第１〜第Ｎの要素のバージョンを特定する第１〜第Ｎ更新情報識別子を記憶する記憶部と、
前記第１〜第Ｎ更新情報識別子の全部または一部を含む取得要求を、ネットワークを介して取得先装置に送信する送信部と、
前記取得要求により更新情報識別子を送信した要素の少なくとも１つの要素を更新するための第１更新情報と、前記要素の更新情報識別子を更新するための第２更新情報とを前記取得先装置から受信する受信部と、
前記記憶部における前記要素を前記第１更新情報により更新し、前記要素の更新情報識別子を前記第２更新情報により更新する更新部と、
を備えた通信装置。
【請求項２】
対象情報と、前記対象情報のバージョンを特定する第１更新情報識別子とを記憶する記憶部と、
前記第１更新情報識別子を含む第１取得要求を、ネットワークを介して取得先装置に送信する送信部と、
前記対象情報の少なくとも一部を更新するための第１更新情報と、前記第１更新情報識別子を更新するための第２更新情報を前記取得先装置から受信する受信部と、
前記記憶部における前記対象情報の少なくとも一部を前記第１更新情報により更新し、前記第２更新情報により前記第１更新情報識別子を更新する更新部と、
を備えた通信装置。
【請求項３】
前記送信部と前記受信部を含む通信部と、
前記更新部を含む制御部とを備え、
前記制御部は、前記取得要求の送信指示を前記通信部に出力し、その後、第１の状態から第２の状態に遷移し、前記第２の状態は前記第１の状態よりも低消費電力な状態であり、
前記通信部は、前記送信指示を受けて前記取得要求を送信し、前記取得先装置からの前記第１更新情報および第２更新情報の受信が完了したら、完了通知を前記制御部に出力し、
前記制御部は、前記完了通知を前記通信部から受けたら、前記第２状態から前記第１状態に遷移する
請求項１ないし２のいずれか一項に記載の通信装置。
【請求項４】
前記通信部は、前記取得先装置から取得した第１更新情報が、外部サーバが保有する情報への参照を含むときは、前記外部サーバから情報を取得し、前記外部サーバからの情報の取得が完了した後、前記完了通知を出力する
請求項３に記載の通信装置。
【請求項５】
前記記憶部は、前記対象情報をＵＲＩと関連づけて記憶し、
要求元からＵＲＩを指定した取得指示を受け、前記ＵＲＩに対応する対象情報が前記記憶部に記憶されているかを判定する処理部を備え、
前記送信部は、前記記憶部に前記対象情報が記憶されているとき、前記取得要求を前記取得先装置に送信し、前記記憶部に前記対象情報が記憶されていないとき、前記取得指示により指定されたＵＲＩにおける対象情報の取得要求を前記取得先装置に送信する
請求項１ないし４のいずれか一項に記載の通信装置。
【請求項６】
前記第１〜第Ｎの要素は、タグ記述言語によって記述された文書の構成要素である
請求項１または５に記載の通信装置。
【請求項７】
前記第１〜第Ｎの要素は、前記文書を構文解析して得られる木構造のノードに割り当てられた値である
請求項６に記載の通信装置。
【請求項８】
前記第１更新情報は、前記対象情報において更新対象となる箇所を示す更新箇所識別子と、前記更新対象となる箇所の情報を更新するための更新情報とを含む
請求項２に記載の通信装置。
【請求項９】
第１〜第Ｎの要素を含む対象情報と、前記第１〜第Ｎの要素のバージョンを特定する第１〜第Ｎ更新情報識別子とを保持する要求元装置から、前記第１〜第Ｎ更新情報識別子の全部または一部を含む取得要求を、ネットワークを介して受信する受信部と、
前記取得要求により更新情報識別子が送信された要素を更新するか否かを前記要素の更新情報識別子に基づいて判定する処理部と、
前記処理部により更新すると決定された要素について、前記要素を更新するための第１更新情報と、前記要素の更新情報識別子を更新するための第２更新情報とを、前記要求元装置に送信する送信部と
を備えた通信装置。
【請求項１０】
前記第１〜第Ｎの要素のバージョンをそれぞれ表す更新情報識別子を記憶する記憶部を備え、
前記処理部は、前記取得要求により更新情報識別子が送信された要素の前記更新情報識別子が、前記記憶部で管理される前記要素のバージョンと異なるときは、前記要求元装置が保持する前記要素と前記要素の更新情報識別子を、前記記憶部で管理する要素および前記要素の更新情報識別子に更新することを決定する、
請求項９に記載の通信装置。
【請求項１１】
前記第１〜第Ｎの要素は、タグ記述言語によって記述された文書内の構成要素である
請求項９ないし１０のいずれか一項に記載の通信装置。
【請求項１２】
前記第１〜第Ｎの要素は、前記文書を構文解析して得られる木構造のノードに割り当てられた値である
請求項１１に記載の通信装置。
【請求項１３】
対象情報と前記対象情報のバージョンを特定する第１更新情報識別子とを保持する要求元装置から、前記第１更新情報識別子を含む取得要求を、ネットワークを介して受信する受信部と、
前記第１更新情報識別子に基づいて、前記要求元装置で保持される対象情報を更新するか否かを判定する処理部と、
前記処理部により更新すると決定された場合、前記対象情報の少なくとも一部を更新するための第１更新情報と、前記要求元装置で保持される第１更新情報識別子を更新するための第２更新情報とを、前記要求元装置に送信する送信部と、
を備えた通信装置。
【請求項１４】
対象情報を構成する第１〜第Ｎの要素の全部または一部の各バージョンを特定する更新情報識別子を含む取得要求を、ネットワークを介して取得先装置に送信する送信ステップと、
前記取得要求により更新情報識別子が送信された要素の少なくとも１つの要素を更新するための第１更新情報と、前記要素の更新情報識別子を更新するための第２更新情報とを前記取得先装置から受信する受信ステップと、
前記要素を前記第１更新情報により更新し、前記要素の更新情報識別子を前記第２更新情報により更新する更新ステップと
を備えた通信方法。
【請求項１５】
対象情報のバージョンを特定する第１更新情報識別子を含む第１取得要求を、ネットワークを介して取得先装置に送信する送信ステップと、
前記取得先装置から、前記対象情報の少なくとも一部を更新するための第１更新情報と、前記第１更新情報識別子を更新するための第２更新情報を受信する受信ステップと、
前記第１更新情報により前記対象情報を更新し、前記第２更新情報により前記更新情報識別子を更新する更新ステップと、
を備えた通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、通信装置および通信方法に関する。
【背景技術】
【０００２】
ウェブブラウザを用いてインターネット上の情報にアクセスする方法が、広く用いられている。ウェブブラウザは、HTTP（Hyper Text Transfer Protocol）を利用して、インターネット上のウェブサーバから情報を取得している。その基本動作は、ウェブブラウザが欲しい情報を特定するURI（Uniform Resource Identifiers）を含む要求を送信し、サーバがそれに応えることで構成される。
【０００３】
この基本動作は、原則として全ての要求に対して行われるが、サーバ側で情報が更新されていない場合に再取得するのは効率が悪い。そのため、キャッシュ機構や差分転送といった仕組みが用意されている。また、ある情報の取得が途中で中断された場合に、残りの部分だけを要求するような範囲要求の仕組みも用意されている。
【０００４】
HTTPのキャッシュ機構は、URIを情報の単位として扱う。すなわち、あるURIで特定される情報のごく一部が変更された場合であっても、情報全体での更新が必要となる。
【０００５】
これは動的に生成される情報を含む場合に問題となる。例えば、静的に構成されるメニュー部分と、利用者のメールボックスの状況を表示する部分とからなるウェブページを考える。この場合、キャッシュの単位はウェブページ全体であり、メールボックスの状況はアクセスごとに変化する可能性があることから、情報が固定のメニュー部分も含めて全体を再取得する必要が生じる。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
【非特許文献２】RFC 3229 "Delta encoding in HTTP"
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明の実施形態は、動的に変更される部分を有する情報を効率的に取得できるようにすることを目的とする。
【課題を解決するための手段】
【０００８】
本発明の一態様としての通信装置は、第１〜第Ｎの要素を含む対象情報と、前記第１〜第Ｎの要素のバージョンを特定する第１〜第Ｎ更新情報識別子を記憶する記憶部と、前記第１〜第Ｎ更新情報識別子の全部または一部を含む取得要求を、ネットワークを介して取得先装置に送信する送信部と、前記取得要求により更新情報識別子を送信した要素の少なくとも１つの要素を更新するための第１更新情報と、前記要素の更新情報識別子を更新するための第２更新情報とを受信する受信部と、前記記憶部における前記要素を前記第１更新情報により更新し、前記要素の更新情報識別子を前記第２更新情報により更新する更新部と、を備える。
【図面の簡単な説明】
【０００９】
【図１】第１の実施形態に係るネットワークシステムを示す図。
【図２】第１の実施形態係る端末装置と情報提供装置のブロック図。
【図３Ａ】端末装置により行われる情報要求動作のフローチャート。
【図３Ｂ】端末装置により行われる情報要求動作のフローチャート。
【図４Ａ】ＨＴＭＬ文書、木構造、要素、更新情報識別子の例を示す図。
【図４Ｂ】ＨＴＭＬ文書、木構造、要素、更新情報識別子の例を示す図。
【図４Ｃ】ＨＴＭＬ文書、木構造、要素、更新情報識別子の例を示す図。
【図５】端末装置と情報提供装置との間のメッセージシーケンスを示す図。
【図６】サーバが動的にＨＴＭＬ文書を生成・変更する場合の動作シーケンスを示す図。
【図７】第２の実施形態に係る端末装置のブロック図。
【図８】第２の実施形態に係るメッセージシーケンスを示す図。
【図９】第３の実施形態に係るネットワーク構成を示す図。
【図１０】第３の実施形態に係る情報処理装置のブロック図。
【図１１】第３の実施形態に係る動作シーケンスを示す図。
【図１２】管理情報の例を示す図。
【発明を実施するための形態】
【００１０】
以下、図面を参照しながら、本発明の実施形態について説明する。
【００１１】
《第１の実施形態：DOM（Document Object Model）等による情報の管理が可能な端末装置およびサーバの基本形態》
本実施形態は、文書情報等の情報を解釈して構造化し、文書の要素単位、すなわち、データ構造の要素単位で情報更新の管理を行う。個々の要素（論理要素とも呼ばれる）に対して変更を検出できるようにし、その変更のあった要素のみをサーバから取得する。これにより、動的に生成される部分を含む情報を効率的に取得し、変化のない部分はキャッシュ機構を有効利用できる。以下、本実施形態の詳細を説明する。
【００１２】
図１に、本実施形態に係るネットワークシステムを示す。端末装置１１が、情報提供装置１３とネットワーク１２を介して接続されている。ここでは端末装置および情報提供装置は各々１台ずつしか示していないが、複数台が存在してもよい。ここでは１台ずつの場合で説明する。端末装置１１および情報提供装置１３はそれぞれネットワークを介して通信可能な通信装置の一形態である。情報提供装置１３は、端末装置１１に情報を提供する装置、たとえばウェブサーバであり、端末装置１１から見て情報の取得先装置である。また、情報提供装置１３から見て端末装置１１は情報の要求元装置である。
【００１３】
図２に第１の実施形態における端末装置と情報提供装置の構成図を示す。
【００１４】
端末装置は制御部１０１、通信部１１３、保存部（記憶部）１１１、出力部１１２を備える。制御部１０１は、処理部１０２、要求生成部１０４、更新部１０３を備える。
【００１５】
通信部１１３は、情報提供装置と通信するために必要な各種通信処理を実行する。通信部１１３は、例えば、TCP/IPのプロトコルスタックやネットワークインタフェース等である。
【００１６】
処理部１０２は、端末装置で実行する各種処理に対して全体を司る。各種処理としては、ネットワークを介して情報提供装置との間で行う通信処理、取得した情報をキャッシュとして再利用するために保存する処理、取得した情報を表示する処理などがある。
【００１７】
保存部１１１は、データをキャッシュとして記憶する記憶部である。記憶部はメモリ装置であり、不揮発性メモリで構成しても、不揮発性メモリで構成してもよい。保存部１１１は、情報提供装置から提供されるＨＴＭＬ文書等の情報を対象情報として記憶する。対象情報は複数の要素から構成される。保存部１１１は、各要素の識別子と、各要素のバージョンを特定する更新情報識別子を記憶する。ＨＴＭＬ文書は、たとえばＤＯＭ等の木構造へ変換して管理され、木構造の各ノードには要素が割り当てられる。情報提供装置から情報を取得した場合はこれをキャッシュとして保存部１１１に保存する。各要素の識別子は、当該要素が割り当てられたノードの位置を特定する値でもよい（詳細は後述）。各要素の更新情報識別子は、情報提供装置からＨＴＭＬ文書等の情報を取得する際に、当該情報とともに同時に受信する。
【００１８】
要求生成部１０４は、情報提供装置に対して情報の取得を要求するメッセージ（情報取得要求）を生成する。その際、本実施形態で定義した特別なフォーマットに従うメッセージを生成することもある。情報取得要求は、端末装置で管理する情報（対象情報）を構成する複数の要素の各々のバージョンを特定する更新情報識別子と、各要素の識別子とを含む。これらは保存部１１１から読み出すことで取得する。ただし、当該対象情報がまだ一度も取得されていないとき、すなわち、当該対象情報の取得先であるURIへのアクセスがまだ行われておらず当該対象情報が保存部１１１にキャッシュされていないときは、各要素の識別子および更新情報識別子を含めないで情報取得要求を送信する。
【００１９】
更新部１０３は、情報提供装置から情報取得要求に対して取得された応答を解析し、端末装置の保存部１１１にキャッシュされている情報を、必要に応じて更新する。情報提供装置から取得された応答は、情報取得要求で更新情報識別子を送信した複数の要素のうち更新対象となる要素を更新するための更新情報（第１更新情報）と、当該要素の更新情報識別子を更新するための更新情報（第２更新情報）とを含む。更新対象となる要素は、情報提供装置で管理する該当ＵＲＩの情報において該当要素と同じ識別子の要素よりもバージョンが古い要素である。第１更新情報は、更新後の要素そのもののデータでもよいし、要素の差分更新が可能なときは差分データでもよい。第２更新情報は更新後のバージョンを表す更新情報識別子でもよいし、バージョンが順次値が増加する形式を有する場合などは増加分の値でもよい。端末装置から更新情報識別子を含まない情報取得要求が情報提供装置に送信された場合、当該ＵＲＩの位置に配置された情報全体を含む応答を受信する。この応答には、当該情報を構成する各要素のバージョンを表す更新情報識別子と、各要素の識別子が含まれる。
【００２０】
出力部１１２は、端末装置の利用者に対して、保存部１１１に記憶されている情報（対象情報）を表示する。
【００２１】
なお、端末装置が、上述した以外の構成要素を具備している場合もある。それらは本実施形態とは直接関係しないため、ここでの説明を省略する。
【００２２】
一方、情報提供装置は、通信部２０１、制御部２０２、比較部２０３、保存部（記憶部）２０４を備える。
【００２３】
通信部２０１は、ネットワークを介して端末装置から要求を受信して、応答を送信する際に必要となる通信処理を行う。例えば、TCP/IPのプロトコルスタックやネットワークインタフェース等がこれに対応する。
【００２４】
保存部２０４は、URIに対応づけられた情報を保存している。情報は複数の要素を含む。保存する情報は、特定のURIのものでもよいし、複数のURIに対応する場合は、URIごとに情報を保存しても良い。保存部２０４は、URIに対応する情報を構成する複数の要素の各バージョンを特定する更新情報識別子や、情報の階層構造も記憶している。
【００２５】
制御部２０２は、保存部２０４の情報の管理、端末装置から受信する情報取得要求の解析や、端末装置へ送信する応答の生成を行う。
【００２６】
制御部２０２は、保存部２０４においてURIに対応する情報の全部または一部に対する更新を行う場合は、該当する要素を書き換えるとともに、当該要素の更新情報識別子を更新（すなわちバージョンを変更）する。このような情報の更新の管理は、後述する制御部２０２が行う。バージョンは更新するごとに１，２，３、・・・のように順次増加する値でもよいし、更新された日時を特定する値でもよいし、その他の種類の値でもよい。
【００２７】
制御部２０２は、端末装置から情報全体の取得要求（更新情報識別子等を含まない取得要求）があった場合は、該当URIの位置に格納された情報全体を保存部２０４から読み出し、当該読み出した情報を含む応答を端末装置に返信する。このとき、当該情報を構成する各要素の更新情報識別子も応答に含める。
【００２８】
比較部２０３は、端末装置から受信された情報取得要求に含まれる各要素の更新情報識別子と、保存部２０４に保存された該当URIに対応する情報の各要素の更新情報識別子とを比較する。要素毎に、更新情報識別子の一致もしくは不一致の判定をする。不一致が検出された端末装置の要素を更新対象要素として特定し、特定した要素の識別子を制御部２０２に通知する。
【００２９】
制御部２０２は、URIに対応する情報の各要素のうち、当該特定された要素と同じ識別子を有する要素と、その要素の更新情報識別子を保存部２０４から読み出し、読み出したこれらのデータを含む応答を生成し、端末装置に通信部２０１を介して送信する。
【００３０】
なお、情報提供装置が、上述した以外の構成要素を具備している場合もある。それらは本実施形態とは直接関係しないため、ここでの説明は省略する。
【００３１】
図３Ａに本端末装置における情報要求動作のフローチャートを示す。
【００３２】
情報取得動作は、要求する情報のURIを特定することから始まる（Ｓ３０１）。この操作は、例えば、利用者がウェブブラウザに表示されているリンクを選択する等の操作によって実行されうる。他にも、外部のプログラムから、あるURIの情報取得が要求されることもなどが考えられる。これら外部のプログラム、利用者あるいは利用者が操作するマウス等の操作部は、ＵＲＩの指定を行う要求元である。
【００３３】
URIが特定されたら、当該URIで特定される情報（対象情報）のキャッシュ状況を確認する（Ｓ３０２）。保存部１１１に有効なキャッシュがある場合（Ｓ３０２−ＹＥＳ）には、本実施形態の特徴に基づく処理（Ｓ３０３〜Ｓ３１１）を行う。キャッシュが無い場合には、ページ全体（情報全体）を取得し、表示する処理を行う（Ｓ３１２〜Ｓ３１４、Ｓ３０９、Ｓ３１０）。
【００３４】
本実施形態の特徴に基づく処理（Ｓ３０３〜Ｓ３１１）について詳細に説明する。ステップＳ３０１で特定されたURIの情報の有効なキャッシュが保存部１１１に存在する場合（Ｓ３０２−ＹＥＳ）、保存部１１１を参照して、当該情報のキャッシュを取得する。その後、同情報を構成する各要素のバージョン情報を表す更新情報識別子を特定する（Ｓ３０３）。
【００３５】
図４に、端末装置が要求するURIに対応する情報としてＨＴＭＬ文書の例４０１を示す。この情報４０１は、保存部１１１にキャッシュされているものとする。すなわち、情報４０１は、かつて同URIで取得した情報である。ＨＴＭＬ文書４０１を解析した結果として、木構造４０２が得られたと仮定する。この解析は制御部１０１で行う。情報提供装置側でも同様の木構造が管理される。木構造４０２の各要素には、v=N（Nは数字）の形式で、更新情報識別子が付いている。Nが更新情報識別子の値に対応し、v=Nは、この更新情報識別子が付与されている要素のバージョンはNであることを表す。ここでは末端の要素（４０３〜４０７）にのみ更新情報識別子を付けているたが、中間のノードにも同様に更新情報識別子を付けてもよい。ステップＳ３０３では、木構造のノードに付与されているこれらの更新情報識別子をすべて特定する。図におけるＡ、Ｂ、Ｃ、Ｄ、Ｅはノードの箇所を特定する識別子、すなわち要素の識別子である。ここでは模式的にＡ、Ｂ、Ｃ、Ｄ、Ｅにより表現している。識別子の割り当て方法は、階層構造の位置を特定でき、端末装置および情報提供装置間で共通な方法であれば何でも構わない。たとえば予め決めたルールでノードにＡ，Ｂ，Ｃ・・・といった識別子を付与してもよいし、ノードに対応するＨＴＭＬタグを利用して識別子を付与してもかまわない。また、あるノードの１番目の子、２番目の子など、ノード間の親子関係を利用してノードに識別子を付与してもかまわない。要は、端末装置と情報提供装置の双方で同じ方法で、各要素を共通に識別可能な方法であれば何でも良い。
【００３６】
更新情報識別子をすべて特定したら、各要素の識別子および更新情報識別子を含む情報取得要求を生成する（Ｓ３０４）。例えば、ＨＴＭＬ文書４０１に対する要求として、図４Ａに示す要求４０８を生成する。この要求は、各要素の更新情報識別子を「X-DOM-Node-Version」というユーザ定義HTTPヘッダを用いて通知している。X-DOM-Node-Versionは、要素の更新情報識別子を“要素の識別子（更新箇所の識別子）＝更新情報識別子”と表して、セミコロンで区切って並べている。たとえばＡ＝１は、要素Ａのバージョンは１であることを意味している。なお、このフォーマットはひとつの表記例であり、同じ意味が伝えられれば、別のフォーマットを用いてもよい。
【００３７】
各要素の更新情報識別子等を含む情報取得要求を生成したら、同要求を情報提供装置に向けて送信する（Ｓ３０５）。そして、情報提供装置から応答を受信するまで待機する（Ｓ３０６）。この応答の内容は、情報提供装置が部分更新に適合しているか否かで異なり、応答を受信した端末装置は、情報提供装置が部分更新に適合しているかに応じて処理を変える必要がある。部分更新に適合している情報提供装置は本実施形態に係る情報提供装置であり、部分更新に適合していない情報提供装置は一般の情報提供装置である。
【００３８】
そこで、応答を受信した端末装置は、情報提供装置が部分更新に適合しているかどうかを確認し（Ｓ３０７）、部分更新に適合していた場合（Ｓ３０７−ＹＥＳ）、受信した応答に基づいて、保存部１１１におけるＨＴＭＬ文書を構成する複数の要素のうち、変更があった要素だけを更新する（Ｓ３０８）。これにより、保存部１１１に記憶されているＨＴＭＬ文書が更新される（Ｓ３０９）。
【００３９】
情報提供装置が部分更新に適合していなかった場合（Ｓ３０７−ＮＯ）、応答には要求したＨＴＭＬ文書全体が含まれている。したがって、端末装置は、ＨＴＭＬ文書全体を更新する（Ｓ３１１）。これにより、保存部１１１に記憶されているＨＴＭＬ文書が更新される（Ｓ３０９）。
【００４０】
保存部１１１に記憶されたＨＴＭＬ文書が更新されたら、出力部１１２を介して、当該ＨＴＭＬ文書を出力する（Ｓ３１０）。
【００４１】
続いて、ステップＳ３０８の処理で行った部分更新の詳細について述べる。部分更新に適合した応答として、例えば図４に示す応答４０９を受信したと仮定する。この応答は３つの部分で構成されている。第一に「部分更新であること」を示す特別な応答コード（２ＸＸ：Ｘには実際には数字が入る）と、その旨を示す「Partial Update」という文字列（１行目）である。第２に、ユーザ定義ヘッダ「X-DOM-Item」（２行目）であり、これは更新箇所とそのバージョンを示す。「Ｂ＝８」は、箇所Ｂの要素（すなわち要素Ｂ）について、更新後の更新情報識別子（バージョン）が８であることを表す。そして第３に、実際の更新内容（４行目以降）である。更新後の要素Ｂの内容は、「更新された段落」であり、ＨＴＭＬ文書４０１のタグ＜Ｐ＞、＜／Ｐ＞で囲まれた「段落」が、「更新された段落」で更新されることを意味する。
【００４２】
ステップＳ３０７で情報提供装置が部分更新に適合しているかの判定は、応答の１行目を参照して行う。応答が部分更新適合を示すものであった場合には、ステップＳ３０８で、応答で通知された箇所の要素（応答４０９の場合は要素Ｂのみ）の更新処理を行う。
【００４３】
図３ＢにステップＳ３０８の処理のフローチャート（Ｓ３１５〜Ｓ３１８）を示す。
【００４４】
最初に、受信した応答のX-DOM-Itemヘッダに示される更新箇所のうち、まだ選択していない更新箇所があるか確認する（Ｓ３１５）。まだ選択していない更新箇所がある場合（Ｓ３１５−ＹＥＳ）、その更新箇所を選択する（Ｓ３１６）。図４に示す応答４０９の例では、「X-DOM-Item: B=8」とあり、Ｂが唯一の更新箇所であるから、更新箇所Ｂを選択する。その後、保存部１１１に保存されたＨＴＭＬ文書を読み出し、DOM（４０２参照）を構築するなどして、箇所Ｂの要素を特定する（Ｓ３１７）。なお、事前に構築したDOMを保存部１１１に記憶しておき、これを読み出してもよい。そして、要素Ｂの内容を、応答メッセージのボディ部分で通知された内容（応答４０９では『更新された段落』に記述された部分）に置き換える（Ｓ３１８）。その結果、図４に示すに更新された、木構造（ＤＯＭ）４１０ならびにＨＴＭＬ文書４１１が得られる。
【００４５】
以上の処理を、選択されていない更新箇所が無くなるまで繰り返す。図４の応答４０９の例では、更新箇所が１つだけだったが、複数の更新箇所が通知される場合もある。その場合、図４の要求４０８と同じように「X-DOM-Item」ヘッダに、複数の要素の更新情報識別子を、“更新箇所の識別子（要素の識別子）＝更新情報識別子”の形式でそれぞれ表し、これらを区切って並べる。応答に含められる更新部分（更新後の要素）もボディ領域（『更新された段落』）に連続して並べて配置される。したがって、上記と同様にして処理できる。
【００４６】
別の方法として、端末装置は、更新対象となる要素ごとにヘッダで区切ったHTTP応答を情報提供装置から受け取るようにしてもよいし。図４Ｂに、この場合の応答の例４１２を示す。または、MIME/Multipart形式で、複数部分に区切った形の応答を受け取ってもよい。図４に、この場合の応答の例４１３を示す。図４の左には、応答４１２に従って更新された後のＨＴＭＬ文書およびDOMの例が示される。
【００４７】
これまではDOM（木構造）の末端要素のみが更新される場合について述べたが、より大規模に文書が更新される場合もある。これらについては、「X-DOM-Item」ヘッダに、変更を記載する方法で同様に制御すればよい。
【００４８】
例えば、ある要素が無くなる更新を伝える場合を考える。このとき、バージョン0が要素の削除を示すというルールの下では、「X-DOM-Item: B=0」というヘッダを含む応答を受け取ると、位置Ｂにおける要素を削除する。図４Ｃに、この場合の応答の例４１５と、要素Ｂが削除されたDOM414を示す。図４Ｃの一番上には、更新前のDOMと、更新前のＨＴＭＬ文書が示されている。
【００４９】
さらに、要素を削除し、その後に要素を追加する場合では、「X-DOM-Insert-After: /HTML/BODY/」のようなヘッダを含み、さらにXPATH（ＨＴＭＬ文書の構造を表現し、更新場所を特定する）と、更新内容とを含む応答を受け取ればよい。図４Ｃに、この場合の応答の例４１７を示す。この応答４１７に従って更新した後のDOM４１６を示す。要素Ｂが削除されるとともに、要素Ｆ，Ｇが追加されている。要素Ｆのデータはimage.jpgのファイルの画像データであり、要素Ｇのデータは「更新されたテキストです。」である。なお、ここに記載していない処理（置換(Replace)、前に追加(Insert-Before)なども、同様にして実施可能である。
【００５０】
さらに、端末装置が情報提供装置にパラメータ等の何らかの情報を送信し、それに基づいて情報提供装置が動的にＨＴＭＬ文書を生成・変更する場合がある。このような場合、端末装置は、保存部１１１にＨＴＭＬ文書をキャッシュする際に、送信したパラメータに関する情報を併せて保存しておき、再要求時にそのパラメータ値を伴う情報取得要求を生成および送信すればよい。
【００５１】
なお、パラメータ値が変更されている場合には、旧パラメータに加えて新パラメータも付与して送信してもよい。その場合、情報提供装置側で新旧パラメータの違いも考慮して更新情報（第１および第２の更新情報）を生成のうえ、当該更新情報を含む応答を返せばよい。当然、旧パラメータを送信することなく、新パラメータだけを送信して、通常通りＨＴＭＬ文書全体を要求してもよい。
【００５２】
以上が第1の実施形態における端末装置の処理の流れである。
【００５３】
《第１の実施形態：補足：情報提供装置を含めたシーケンス》
続いて、第１の実施形態における情報提供装置を含めた全体の処理の流れを説明する。
【００５４】
図５は、本端末装置と情報提供装置との間のメッセージシーケンスを示す。情報提供装置は、本端末装置のほかにも多数の端末装置と通信をしている可能性があるが、その場合には、それらの端末装置との間でも、本端末装置と同様のメッセージのやり取りが行われる。
【００５５】
端末装置が最初に情報提供装置（ここではウェブサーバ）に対して、ＨＴＭＬ文書の取得を要求する（Ｓ５０１）。この文書はサーバが動的に生成すると仮定する。その要求に対して、情報提供装置は動的にＨＴＭＬ文書を生成して送り返す（Ｓ５０２）。この時、応答５０５に示すように、「Expires:-1」というヘッダが付与されている場合、通常は、端末装置は、応答に含まれるＨＴＭＬ文書をキャッシュすることができない（なおExpiresの値に、有効な正数が設定されていた場合には、その値を有効期間としてキャッシュする）。しかし、本端末装置では、ＨＴＭＬ文書内に更新情報識別子が含まれることを確認したうえで、保存部１１１に、応答に含まれるＨＴＭＬ文書をキャッシュする（Ｓ５０３）。ＨＴＭＬ文書内の更新情報識別子は、ＨＴＭＬ文書内の該当する箇所（ノード）と関連づけられてＨＴＭＬ文書に含まれている。
【００５６】
その後、端末装置が再び同じURIにアクセスする際、ＨＴＭＬ文書を構成する複数の要素の一部または全部の更新情報識別子を含む情報取得要求を生成し、送信する（Ｓ５０４）。図示の例では一部の要素の更新情報識別子として、A=1,B=7,C=1,D=2,E=1を通知している。すなわち、要素Ａのバージョンは１、要素Ｂのバージョンは７、要素Cのバージョンは１、要素Ｄのバージョンは２、要素Ｅのバージョンは１である。
【００５７】
これを受け取った情報提供装置は、自身が保持しているＨＴＭＬ文書の要素のうち端末装置から通知された要素識別子と同じ識別子の要素のバージョンを、端末装置から通知された当該要素のバージョンを比較する。バージョンが異なる場合は、自身が保持している要素と、その更新識別子とを含む応答を送り返す（Ｓ５０５）。図５に示す例では、少なくとも要素Ｂのバージョンが端末装置と情報提供装置とで異なるため、自身が保持しているＨＴＭＬ文書の要素Ｂの内容と、当該要素Ｂのバージョンとを含む応答が返されている。
【００５８】
その後、端末装置は、受け取った応答を用いてキャッシュの内容を更新し、その結果を再びキャッシュする（Ｓ５０６）。すなわち、要素Ｂの内容を、応答に含まれる更新後の要素Ｂの内容に更新し、要素Ｂの更新情報識別子を、応答に含まれる更新情報識別子（ここでは８）に更新する。
【００５９】
同様に、端末装置が情報提供装置にパラメータ等の何らかの情報を送信し、それに基づいてサーバが動的にＨＴＭＬ文書を生成・変更する場合の動作シーケンスを図６に示す。
【００６０】
最初に、URL /test/ で特定できるＨＴＭＬ文書（動的に生成されると仮定）を取得する。この文書の取得にあたっては、パラメータarg1とarg2が必要であり、最初の要求（Ｓ６０１）で、二つのパラメータを指定している。図示の例では、パラメータarg1としてDATA1、パラメータarg2としてDATA2を指定している。
【００６１】
その応答を端末装置が受信した際（Ｓ６０２）、その応答が要素の更新情報識別子を含むことを確認すると、その応答に含まれるデータ（更新情報識別子、動的に生成された/test/の内容等）を、送信したパラメータ（arg1=DATA1,arg2=DATA2）と共にキャッシュしておく（Ｓ６０３）。
【００６２】
その後、同じURLにアクセスする際、ステップＳ６０３にて保存したパラメータと、キャッシュした要素の更新情報識別子とを含む要求を送信する（Ｓ６０４）。図示の例では要素の更新情報識別子として、A=1,B=7,C=1,D=2,E=1が通知されている。
【００６３】
情報提供装置は、端末装置から通知された要素の更新情報識別子とパラメータの値を確認し、更新対象となる要素等を特定し、応答を生成して返す（Ｓ６０５）。図６に示す例では、少なくとも要素Ｂが更新対象として特定され、情報提供装置が有する要素Ｂとその更新情報識別子とを含む応答が返されている。
【００６４】
応答を受けとった端末装置は、これまでと同様に、更新対象となる要素とその更新情報識別子を応答に含まれる内容で更新して、これにより再びキャッシュが更新される（Ｓ６０６）。
【００６５】
なお、図６のシーケンスにおいて、パラメータとその値を各々送信しているが、パラメータ数が多い場合や、パラメータ値が長いテキストとなる場合など、更新情報を取得するための要求のサイズが非常に大きくなる可能性がある。そのような場合には、これらのハッシュ値を求めて送信したり、エンコードするなどして、要求のサイズが小さくなるようにしたりしてもよい。
【００６６】
これまでの説明において、情報提供装置はＨＴＭＬ文書のキャッシュを制御するために、端末装置への応答に"Expires"ヘッダを付与している場合を示した（図５、図６参照）。HTTPプロトコルでは、他のキャッシュ制御方法も規定しており、それらを用いてキャッシュを制御してもよい。
【００６７】
例えば、情報提供装置からの応答に"Etag"によりＨＴＭＬ文書のバージョンを付与し、端末装置からの取得要求に"If-Match"を付与し、端末装置が持っているＨＴＭＬ文書のバージョン（第１更新情報識別子）を含める。情報提供装置は、端末装置からの取得要求に含まれるバージョンが、情報提供装置が現在持っているＨＴＭＬ文書のバージョンに一致するかどうかを確認するようにしてもいい。なお、バージョンは更新するごとに１，２，３、・・・のように順次増加する値でもよいし、更新された日時を特定する値でもよいし、その他の種類の値でもよい。
【００６８】
この場合、情報提供装置は、端末装置が持っているバージョン（端末装置からの取得要求に付加されているＨＴＭＬ文書のバージョン。前述の要素の更新情報識別子とは別のものである）と、現在のＨＴＭＬ文書のバージョンとが一致しない場合に、これらの差分を更新部分として特定する。そして、特定した更新部分の箇所を特定する識別子と、情報提供装置が持っている現在のＨＴＭＬ文書のバージョンを表す情報（第２更新情報）と、更新箇所の更新後の内容（第１更新情報）とを含む応答を返す動作をするようにすればよい。更新箇所は、ＸＰａｔｈでもよいし、ＤＯＭを構築し、該当ノードの箇所を示す識別子でもよい。
【００６９】
端末装置は、現在自身が保有しているＨＴＭＬ文書のうち、更新対象となる箇所を、応答に含まれる更新箇所の識別子から特定し、特定した箇所の内容を、応答に含まれる更新後の内容（第１更新情報）に更新すればよい。また、ＨＴＭＬ文書のバージョン（更新情報識別子）も、応答に含まれるバージョン（第２更新情報）に更新し、次回の取得要求の際は、このバージョンの識別子を含める。なお、更新部分は、ＨＴＭＬの一部でもよいし全体でもよい。
【００７０】
以上、本実施形態によれば、情報提供装置側で一部分が更新されたＨＴＭＬ文書があった場合に、ＨＴＭＬ文書の構造を把握したうえで、その更新のあった部分だけを端末装置に送信し、端末装置はその部分だけを更新する。その際、端末装置からの要求と情報提供装置からの応答とに追加されるデータサイズ、すなわち、更新情報識別子やヘッダ等のサイズと更新内容のサイズとの和が、（従来取得していた）更新後のＨＴＭＬ文書の全体サイズよりも小さい場合、従来よりも、一部分が更新されたＨＴＭＬ文書の取得に要する電力を削減できる。
【００７１】
《第２の実施形態：端末装置にプリフェッチ機能とスリープ機能を追加する》
続いて、第２の実施形態について述べる。第２の実施形態では、第１の実施形態における端末装置に対して更なる低消費電力機能を追加する。
【００７２】
図７に本実施形態の端末装置の構成を示す。第１の実施形態で示した図２に示した通信部１１３が通信部１５３に置き換わり、通信部１５３が第２処理部１２３、保存部（記憶部）１２２、完了通知部１２１を具備する。ここで第２処理部１２３は制御部１５１よりも消費電力が少ない。制御部１５１は、通信部１５３への情報取得要求の送信指示を送り、通信部１５３は、制御部１５１からの指示にしたがって情報取得要求を送信し、端末装置内の制御部１５１に代わって、情報提供装置からの応答の受信処理を実行する。そして、必要な受信処理が完了した後、制御部１５１に処理完了を通知する。制御部１５１は、通信部１５３への情報取得要求の送信指示を送った後、処理完了通知を受けるまで低消費電力な状態へ遷移する。このように、制御部１５１は情報の更新部分を情報提供装置からダウンロードする際に、通信部１５３での受信処理が完了するまで低消費電力な状態へと遷移することで、装置全体として低消費電力化を図ることができる。以下、本実施形態の詳細を説明する。
【００７３】
第２処理部１２３は、第１の実施形態の制御部１５１内の処理部１５２に備えられた機能のうち、情報提供装置との間で交換するメッセージを解釈する機能と、それに基づき必要な情報を情報提供装置から取得する機能とを具備する。また、後述の記憶部１２２に記憶された情報を、制御部１５１に返す機能も具備する。
【００７４】
記憶部１２２は、第２処理部１２３が情報提供装置から取得した情報を一時的に記憶する機能を具備する。先に述べた通り、記憶部１２２に記憶された情報は、第２処理部１３からアクセスできる。
【００７５】
完了通知部１２１は、第２処理部１２３からの指示に基づき、制御部１５１に第２処理部１２３の処理完了を通知する。通知の方法は、ハードウェア割り込みを使う方法などが考えられる。また、処理完了とは、制御部１５１から指示された情報を情報提供装置から取得したことを指す。この時、情報のすべてが取得できている必要はない。一部の情報が取得できたタイミングで通知するようにしてもよい。例えば、制御部１５１の状態遷移に一定の時間が必要となる場合には、その時間を考慮して全ての情報を取得する前に処理完了を通知するようにしてもよい。
【００７６】
なお、通信部１５３は制御部１５１とは独立に動作するため、端末装置内の電源制御回路（図示せず）は、通信部１５３は制御部１５１を個別に制御できるように構成されているものとする。
【００７７】
以下、図８を用いて詳細な動作について述べる。図８は第２の実施形態における制御部１５１内の処理部１５２、通信部１５３、情報提供装置間のメッセージシーケンスを示す。
【００７８】
第１の実施形態と同様に、制御部１５１は、要求する情報のURIを特定し、取得要求を生成する。取得要求の送信を、通信部１５３に指示する（Ｓ８０１）。ここでは最初の取得要求であり、要素の更新情報識別子等を含まない取得要求を生成したと仮定する。また、この時点では制御部１５１は低消費電力状態に状態遷移をしないが、低消費電力な状態へと遷移する構成も可能である（図示せず）。
【００７９】
制御部１５１から取得要求の送信指示を受けた通信部１５３はその内容を解析し、その取得要求が更新情報識別子等を含まないことを確認する（Ｓ８０２）。そして、取得要求の中で指定されている情報提供装置に向けて取得要求を送信する（Ｓ８０３）。
【００８０】
情報提供装置は、端末装置から取得要求を受信し、取得要求されている情報に対応するＨＴＭＬ文書を生成する。そして、生成したＨＴＭＬ文書を含む応答を送り返す（Ｓ８０４）。
【００８１】
応答を受信した通信部１５３は、その内容を解析して、先に送信した取得要求に対する応答であることを確認すると、記憶部１２２に当該応答を保存する（Ｓ８０５）。解析の結果、応答として受信したＨＴＭＬ文書が外部への参照（たとえば外部のサーバに存在する画像データへの参照）を含んでいることが分かった場合には、処理部１５２に応答を返す前に、それらの画像等を事前に取得しておく。取得した画像等は記憶部１２２に保存する。
【００８２】
ＨＴＭＬ文書（およびそこから参照される情報）を受信したら、処理部１５２に応答を返す（Ｓ８０６）。その際、もしステップＳ８０１の後に制御部１５１が低消費電力な状態に遷移していた場合は、完了通知部１２１を介して処理の完了を通知し、制御部１５１を通常動作状態へと遷移させてから、応答を返す。
【００８３】
処理部１５２は、通信部１５３から受信した応答に含まれる情報(ＨＴＭＬ文書)を確認の上、当該ＨＴＭＬ文書をキャッシュする（Ｓ８０７）。出力部１１２が、キャッシュからＨＴＭＬ文書を読み出して、画面に表示する。
【００８４】
その後、端末装置が、ステップＳ８０１と同じURIに対してアクセスを試みたとする。今回は保存部１１１に保存されている情報に基づいて、要素の更新情報識別子等を含む取得要求を生成し、この取得要求の送信指示を通信部１５３へと通知する（Ｓ８０８）。通知後、処理部１５２を含む制御部１５１は、低消費電力な状態へ遷移する（Ｓ８０９）。
【００８５】
取得要求の送信指示の通知を受けた通信部１５３は、その取得要求を解析し（Ｓ８１０）、情報提供装置へ取得要求を送信する（Ｓ８１１）。通信部１５３は情報提供装置から応答を受信し（Ｓ８１２、Ｓ８１４）、応答の解析と記憶部１２２への保存処理を行う（Ｓ８１３、Ｓ８１５）。なお、ここでは個々の要素ごとに、更新された内容を、異なるＨＴＴＰ応答として返すと仮定している。すなわち、図８に示すように、ステップＳ８１２では要素Ｂの更新された内容を返し、ステップＳ８１４では要素Ｅの更新された内容を返している。もし１つの応答ですべての更新された内容を通知する場合には（MIME/Multipartなど）、ステップＳ８１２、Ｓ８１４を１つにまとめた１つのステップの実行になる。
【００８６】
通信部１５３は、すべての応答を受信したと判断したら、完了通知部１２１を介して処理部１５２に処理完了を通知する（Ｓ８１６）。この通知を受け、処理部１５２を含む制御部１５１は、通常の動作状態へと復帰する（Ｓ８１７）。その後、通信部１５３は、応答を処理部１５２に転送し（Ｓ８１８）、処理部１５２はその内容を確認しながら、応答に含まれる更新情報（要素の更新情報識別子、更新された内容等）に基づき、更新処理（要素の更新、削除、追加）等を行って、更新処理の結果を保存部１１１にキャッシュする（Ｓ８１９）。
【００８７】
以上のように、本実施形態では通信部１５３内に、制御部１５１よりも低消費電力な第２処理部１２３を導入し、第２処理部１２３により制御部１５１とは独立して、情報を取得する。これにより第２処理部１２３が情報を取得している間、制御部１５１を低消費電力な状態に遷移させることができ、この結果、より低消費電力に情報を取得できるようになる。
【００８８】
《第３の実施形態：端末装置と情報提供装置の間にブラウザサーバを配置し、端末装置とブラウザサーバに対して本発明の実施形態の機能を利用する》
続いて第３の実施形態について述べる。図９に本実施形態のネットワーク構成を示す。本実施形態では端末装置１１と情報提供装置１５に加え、両者の中間に情報処理装置（ブラウザサーバ）１４が追加される。端末装置１１、情報提供装置１５および情報処理装置１４は、それぞれネットワーク１２に接続された通信装置であり、端末装置１１、情報処理装置１４間で通信し、情報処理装置１４および情報提供装置１５間で通信する。
【００８９】
情報処理装置１４は、端末装置１１が備えるブラウザ機能から分離した一部の機能を実行する。端末装置１１は、分離された残りの部分の機能を実行する。情報提供装置１５は、一般に広く使用されているウェブサーバ等のサーバを用いることができる。このような構成とすることで、既に広く普及している情報提供装置を変更することなく、本発明の実施が可能となる。以下、本実施形態の詳細を説明する。
【００９０】
図１０に、情報処理装置１４の機能ブロック図を示す。
【００９１】
通信部３０１はネットワーク１２と接続し、端末装置との間で情報取得に関するメッセージを送受信する。さらに、通信部３０１は、情報提供装置１５との間で情報取得に関するメッセージを送受信する。
【００９２】
情報取得部３０４は、情報処理部３０２からの指示に基づき、情報提供装置１４から情報を取得する。記憶部３０３は、情報取得部３０４で取得した情報を一時的に記憶する。
【００９３】
情報処理部３０２は、端末装置から受信された取得要求を解析する。解析結果に応じて、情報処理部３０２は、情報の取得を情報取得部３０４に依頼し、情報取得部３０４により情報提供装置１４から取得された情報を処理する。
【００９４】
例えば、情報処理部３０２は、情報提供装置１５から取得した情報に対して、端末装置１１での表示に必要な処理の一部を実行した上で、端末装置１１へと送り返す。ここで必要な処理の一部とは、例えば、構造化された文書の解析や画像の再圧縮、複数の情報提供装置から提供される情報を取り纏めてひとつのＨＴＭＬ文書へ変換すること、などである。
【００９５】
図１１に本実施形態における動作シーケンスを示す。この図では、情報処理装置の効果が分かりやすいように、情報提供装置が２つ（それぞれＡ、Ｂとする）存在する場合を示す。情報提供装置ＡがＨＴＭＬ文書全体を提供し、情報提供装置ＢがそのＨＴＭＬ文書の一部を構成するＨＴＭＬ文書を提供していると仮定する。そして、端末装置１１と情報処理装置１４との間では、要素の更新情報識別子等を含む情報取得要求とその応答が行われる。一方、情報処理装置１４と情報提供装置Ａ、Ｂとの間は標準的なＨＴＴＰによる通信を行う。情報処理装置１４はＨＴＴＰで規定されたキャッシュ管理方法に従って、情報提供装置Ａ、Ｂが保有する情報が変化したかどうかを検出することができる。
【００９６】
はじめに端末装置１１が、対象情報の取得を要求する（Ｓ１１０１）。この取得要求は情報処理装置１４が受信し、情報処理装置１４は取得要求を解析し、自身の記憶部３０３に、対象情報がキャッシュとして蓄積されているかどうかを確認する（Ｓ１１０２）。
【００９７】
ここでは初めての取得要求のため、キャッシュが無いと仮定する。情報処理装置１４は、取得要求にて指定された情報提供装置Ａに対して情報（ＨＴＭＬ文書）の取得を要求し（Ｓ１１０３）、情報提供装置Ａはその情報を含む応答を返す（Ｓ１１０４）。情報処理装置１４は、受信した応答を記憶部３０３に保存した後、その情報の解析を行い、ＨＴＭＬ文書に埋め込まれる情報（embedded_adv.html）の取得が必要であると判断する（Ｓ１１０５）。
【００９８】
情報処理装置１４は、情報提供装置Ｂに対して、埋め込み情報の取得を要求し（Ｓ１１０６）、その応答を受信する（Ｓ１１０７）。情報処理装置１４は、受信した応答に含まれる情報を記憶部３０３に保存し、当該情報を解析する（Ｓ１１０８）。ここでは、更なる情報の取得は不要であると判断する。
【００９９】
情報処理装置１４は、端末装置に返す応答を生成する（Ｓ１１０９）。ここでは複数の情報提供装置Ａ，Ｂから取得した情報（ＨＴＭＬ文書）をひとつの情報にまとめる変換を行うとする。さらに、この変換の過程において、情報を構成する各要素に対して更新情報識別子を付与する。付与する更新情報識別子は、更新毎に値が変更されるような方法であれば、どのような方法で決定してもよい。
【０１００】
複数の情報（ＨＭＴＬ文書）がひとつの情報へ変換されると、この変換後の情報を含む応答（各要素の更新情報識別等も含む）が端末装置に返される（Ｓ１１１０）。端末装置は、その情報を保存する（Ｓ１１１１）。
【０１０１】
その後、端末装置がステップＳ１１０１と同じＵＲＩに対する取得要求を生成すると仮定する。この時、端末装置は、各要素の更新情報識別子等を含む取得要求を生成する。端末装置は、生成した取得要求を情報処理装置に送る（Ｓ１１１２）。
【０１０２】
取得要求を受け取った情報処理装置は、取得要求を解析し、対象情報が記憶部３０３にキャッシュされているかどうかを確認する（Ｓ１１１３）。今回は、過去にアクセス済みであることから、当該ＵＲＩに対応する情報（ＨＴＭＬ文書）がキャッシュに保存されている。ただし、当該保存されているＨＴＭＬ文書のうち、情報提供装置Ｂから取得した埋め込み情報は、有効期間が切れていたと仮定する（この有効期間はＨＴＴＰで定められたキャッシュ管理の方法に基づき判断する）。その結果、情報処理装置１４は情報提供装置Ｂに対して埋め込み情報の取得要求を送信し（Ｓ１１１４）、その応答を得る（Ｓ１１１５）。その後、応答に含まれる埋め込み情報を保存して解析する（Ｓ１１１６）。
【０１０３】
情報処理装置１４は解析の結果、更なる情報の取得は不要であると判断し、端末装置への応答を生成する（Ｓ１１１７）。この応答は、更新された要素（埋め込み情報）の更新情報識別子を含む応答であり、かつ、今回変化したと仮定している情報提供装置Ｂから取得した情報（当該要素の更新後の内容）だけを伝えるものである。
【０１０４】
情報処理装置１４は、生成した応答を、端末装置に返す（Ｓ１１１８）。端末装置は受信した応答に含まれる埋め込み情報と更新情報識別子等を保存する（Ｓ１１１９）。取得した埋め込み情報が反映されたＨＴＭＬ文書全体を表示する（Ｓ１１１９）。
【０１０５】
このように本実施形態では、広く普及している一般の情報提供装置に対して情報処理装置１４を配置することで効率的な情報転送を実現することができる。なお、ここでは２つの情報提供装置から情報を取得する例を示したが、その数は１つでも（１つの情報提供装置が複数の埋め込み情報（断片）を提供することは一般的である）、さらに多くてもよい。
【０１０６】
ここで、本実施形態においては、情報処理装置１４は、ＨＴＴＰで規定されるキャッシュ制御と、要素の識別子と、更新情報識別子との対応関係を維持する必要がある。これには、例えば、図１２に示すような管理情報を用いればよい。この管理情報は、情報処理装置が通信する複数の端末装置に対し共通に適用する。
【０１０７】
図１２（Ａ）に示す管理情報は、端末装置に情報処理装置が応答として送信した情報（図１１に示す例であればpage.html）に対応する管理情報の例である。列１２００は、当該情報に含まれる各要素（すべての要素でなく、部分更新の対象となる要素のみでよい）、列１２０１は当該要素のバージョンを表す更新情報識別子、列１２０２はその情報（page.html）を取得した際にＨＴＴＰヘッダに記載されていたEtagヘッダの値、列１２０３はExpiresヘッダの値を表す。
【０１０８】
行１２１１は、情報提供装置Ａから取得したページ全体（page.html）に含まれていた要素に関するものである（ここでは部分更新の対象となる要素として要素Ａ、Ｄ、Ｅ、Ｆがあったことを示している）。Expiresヘッダは１つのＨＴＴＰメッセージに１つ含まれるため、これら４つの要素は、同じExpiresの値と関連づけられる。
【０１０９】
同様にして行１２１２では、情報提供装置Ｂから埋め込み断片（embedded.html）を取得した際に得たEtagヘッダと、当該埋め込み断片に含まれる要素Ｂ、Ｃが関連づけられている。
【０１１０】
情報提供装置Ｂが一部の情報だけを更新した場合を考える。情報の更新は、取得した情報に対して、記憶部３０３に保存されている要素との差分抽出処理を行うことで検出できる。この場合、EtagもしくはExpiresの部分は新しい値となり、更新された一部の要素に対して更新情報識別子が変化する。図１２（Ｂ）に、要素Ｃの更新が検出されたことにより、要素Ｃの更新情報識別子が７から８に更新された例を示す。要素Ｃ、更新情報識別子８、変更されたEtag（xy0z91m-ilm-82u7e9s）を含む新たな行１２１３が追加され、これに伴い、行１２１２からは要素Ｃが削除されている。
【０１１１】
なお、図１２の例では、EtagとExpiresの２つのヘッダを用いているが、キャッシュや有効期限を管理するための他のヘッダでも同様に扱うことができる。このように各々の情報提供装置が返す応答に対応させて有効期限情報を管理し、かつ、それと関連づけるように更新情報識別子を管理し、更新情報識別子と更新された要素とを端末装置に返すようにしたことで、端末装置において元の情報を構成する要素単位で更新が可能となる。また情報の取得要求の回数を減らすことができる（たとえば埋め込み情報の取得要求は発生しない）とともに、端末装置のブラウザ機能の一部を情報処理装置に移行したことにより、端末装置の低消費電力化が可能になる。
【０１１２】
《第３の実施形態の変形例》
第３の実施形態では、端末装置ではウェブブラウザを動作させ、端末装置と情報処理装置の間でＨＴＴＰによる通信を行っていた。これに対して、より処理効率が高い専用のソフトウェアや通信プロトコルを使用しても良い。
【０１１３】
例えば、情報処理装置がＤＯＭ（木構造）を構築し、そのＤＯＭを適切な方法（例えばバイナリ列やＸＭＬ。変換方法は端末装置と情報処理装置との間で事前に共有しておく）でシリアライズして端末装置に転送し、端末側ではそれを復元して即表示するように実装することもできる。また、情報処理装置は、情報提供装置から取得したＨＴＭＬ文書をシリアライズ等して送信してもよい。情報処理装置は、端末装置に送信したＤＯＭに対してその構成要素の更新情報識別子を管理し、情報提供装置から収集した内容が変化していた場合には、その変化した要素だけを端末装置に通知すればよい。
【０１１４】
さらに別の方法として、情報処理装置が端末装置で表示するＨＴＭＬ文書を画像として生成したうえで、その画像と、そのＨＴＭＬ文書に含まれるリンク情報（例えば<A ref=”http://…./>”）と、画像におけるエリア毎に設定した更新情報識別子をエリアの識別子（更新箇所識別子）とともに端末装置に送信するようにしてもよい。リンク情報は画像上のエリアまたは座標と関連づけておく。情報処理装置は端末装置への応答において更新があった場合に、差分部分に限定して画像を生成して、更新情報識別子とともに端末装置に送信する。更新があった部分の検出には、これまでの実施形態で述べたように、文書の構造を解析し、その有効期間やETag等を用いて求めればよい。なお、一度全体を画像として生成し、そのうえで画像同士の比較で差分の画像を求めてもよい。画像には文書の構造情報が含まれていないため、座標やエリアの情報と更新情報識別子とを画像に関連づければよい。
【０１１５】
画像とリンク情報ならびに更新情報識別子を受信した端末装置は、保存部に保存されている画像情報のうち差分があるエリアの情報を更新する。その後、更新後の画像を表示する。なお、端末装置ではユーザによりリンク情報が関連づけられたエリアをクリック等により選択されると、そのリンク情報へのアクセスの動作を開始する。あるいは、クリックされた座標を情報処理装置に送信し、情報処理装置ではその座標からリンク情報を特定し、リンク先の情報を取得する動作を開始してもよい。この場合、端末装置にリンク情報を送信しなくても良い。
【０１１６】
また、リンク情報に更新があった場合についても同様に扱うことができる。すなわち、情報処理装置がリンク情報の更新部分を抽出し、その結果とリンク情報が関連するエリアの更新情報識別子とを対応づけて送信する。リンク情報は画像上のエリアとリンク先との対応関係を保存した情報であるから、それに対してリンク情報の更新部分を確認することは容易である。端末装置は、リンク情報の差分が通知された際に、リンク情報を部分的に更新することもできる。
【０１１７】
以上のように、本実施形態では情報処理装置と端末装置との間でＨＴＴＰ以外のオーバヘッドが少ない通信プロトコルを用いたとしても、本願発明を実施することができる。
【０１１８】
《第４の実施形態：端末装置にプリフェッチ機能とスリープ機能を追加しつつ、ブラウザサーバを配置し、端末―ブラウザサーバに本発明の実施形態の機能を利用する》
第３〜第４の実施形態における端末装置に対し、第２の実施形態と同様の構成を用いてもよい。その場合、端末装置は各実施形態で述べた動作を行うが、情報の取得中は通信部だけが動作するようになるため、さらなる低消費電力化が期待できる。
【０１１９】
《第５の実施形態：端末装置と情報提供装置の間にブラウザサーバを配置し、ブラウザサーバとウェブサーバ間に本発明の実施形態の機能を利用する》
第３の実施形態（図９〜図１２）では、端末装置と情報処理装置（ブラウザサーバ）との間で本発明の実施形態に係る処理を行った。第５の実施形態では情報処理装置と情報提供装置（ウェブサーバ）との間で本発明の実施形態に係る処理を行う。
【０１２０】
本実施形態において、端末装置は、情報の取得要求を情報処理装置に送る。情報処理装置は、端末装置から要求された情報を、情報提供装置に対して再要求するが、この際に、第１の実施形態で示した端末装置に相当する動作を行う。そして、端末装置から要求された情報を情報提供装置からすべて取得し終わったら、第３の実施形態で述べた情報処理装置の動作（端末装置向けに必要な処理、例えば画像の変換処理や複数のＨＴＭＬ文書をひとつにまとめる処理など）を行い、端末装置に応答を返す。なお、端末装置から要求された情報に前回の要求から変更が一切ない場合は、その旨の応答を返す。
【０１２１】
このようにすることで、端末装置は１回の要求で必要な情報を取得できるうえ、情報処理装置と情報提供装置との間の処理に要する時間が短縮できることから、全体として低消費電力化が可能となる。なお、本実施形態の端末装置にも第２の実施形態と同様にスリープ機能を追加し、取得要求の送信から応答が返ってくるまで低消費電力状態に遷移してもよい。
【０１２２】
なお、各実施形態における端末装置、情報提供装置および情報処理装置は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、端末装置、情報提供装置および情報処理装置の全部または一部の機能は、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、該端末装置、情報提供装置および情報処理装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、ＣＤ−ＲＯＭなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、端末装置、情報提供装置および情報処理装置が備える保存部および記憶部は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用して実現することができる。
【０１２３】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【図１】
2015052821.tif 000003
【図２】
2015052821.tif 000004
【図３Ａ】
2015052821.tif 000005
【図３Ｂ】
2015052821.tif 000006
【図４Ａ】
2015052821.tif 000007
【図４Ｂ】
2015052821.tif 000008
【図４Ｃ】
2015052821.tif 000009
【図５】
2015052821.tif 000010
【図６】
2015052821.tif 000011
【図７】
2015052821.tif 000012
【図８】
2015052821.tif 000013
【図９】
2015052821.tif 000014
【図１０】
2015052821.tif 000015
【図１１】
2015052821.tif 000016
【図１２】
2015052821.tif 000017