JP4176359B2 - データ取得方法、中継装置、プログラムおよび記録媒体 - Google Patents
データ取得方法、中継装置、プログラムおよび記録媒体 Download PDFInfo
- Publication number
- JP4176359B2 JP4176359B2 JP2002056272A JP2002056272A JP4176359B2 JP 4176359 B2 JP4176359 B2 JP 4176359B2 JP 2002056272 A JP2002056272 A JP 2002056272A JP 2002056272 A JP2002056272 A JP 2002056272A JP 4176359 B2 JP4176359 B2 JP 4176359B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- received
- determination information
- client device
- restart
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、クライアント装置が中継装置を介してサーバ装置からデータを取得するデータ取得方法と、これら各方法を実行する中継装置と、これら各方法をコンピュータ装置に実行させるためのプログラムと当該プログラムを記録したコンピュータ装置が読み取り可能な記録媒体とに関する。
【０００２】
【従来の技術】
近年、インターネットの急速な普及に伴い、インターネット上で各種サービスの提供を行うインフォメーションプロバイダー（以下、「ＩＰ」とする）が多数出現してきている。ユーザーは、これらＩＰの提供するサービスの利用を所望する場合には、これらＩＰがインターネット上で提供するコンテンツをダウンロードし、当該コンテンツを実行する必要がある。
【０００３】
より詳しく説明すると、ＩＰが提供するコンテンツは、文書の中に画像や音声、動画、他の文書の所在場所等を埋め込むことができる記述言語であるＨＴＭＬ（Hyper Text Markup Language）で記述されたテキストデータと、ＨＴＭＬに従って当該テキストデータに関連付けられた画像データや音声データ等で構成されている。また、これらコンテンツは、インターネットに接続されたＷＷＷ（World Wide Web）サーバに格納されている。
ユーザーは、コンテンツの取得および解釈実行機能を有するソフトウェア（以下、「ブラウザ」とする）をクライアント装置で実行してインターネットに接続されたＷＷＷサーバからコンテンツをダウンロードすることができる。なお、ユーザーのクライアント装置は、インターネットに直接的に接続されるのではなく、インターネットプロトコルの確立を行うゲートウェイサーバ（アクセスサーバ）を介してインターネットに接続される。この種のゲートウェイサーバはクライアント装置と通信するための第一の通信回線（例えば構内ネットワークや公衆網など）と第二の通信回線（インターネット）とに接続されており、クライアント装置とサーバ装置との通信を中継する。また、代理サーバ機能を備えたゲートウェイサーバも広く普及している。また、ユーザーが用いるクライアント装置としては、ブラウザ機能付き携帯電話やＰＤＡ（Personal Digital Assistance）やＰＣ（Personal Computer）などが広く普及している。
【０００４】
【発明が解決しようとする課題】
上述したように、ユーザーは、クライアント装置でブラウザを実行することによりＷＷＷサーバからコンテンツをダウンロードすることができるが、例えば、通信障害等によりＷＷＷサーバからのコンテンツのダウンロードが中断された場合には、所望するコンテンツを取得できない。
このような場合に、ユーザーが、当該コンテンツの利用を望むならば、再度、当該コンテンツのダウンロードを最初からやり直さなければならないといった問題点があった。
【０００５】
上記の問題点を解決する方法として従来のデータ通信技術では、サーバ装置にクライアント装置のデータの受信状況を監視させるとともに、クライアント装置へのデータ送信が中断された場合には、クライアント装置にそれまで受信した部分を記憶させる方法が提案されている。
このような方法を用いると、ユーザーにより同一データのダウンロードが指示された場合には、中断されたデータ送信を中断された時点から再開し、クライアント装置が未受信の部分のみを送信し、クライアント装置で中断されるまでに受信した部分と再開後に受信した部分とを結合してユーザーの所望するデータを取得することが可能となる。
また、サーバ装置の処理負荷を軽減するために、サーバ装置とクライアント装置との通信を中継する中継装置を設け、当該中継装置に上述のクライアント装置へのデータのダウンロード状況を監視させる方法も提案されている。
【０００６】
しかし、上述の方法を用いた場合であっても、ダウンロードが中断された時から中断されたダウンロードの再開が要求されるまでの間に、サーバ装置に記憶されているダウンロード対象のデータが更新されてしまった場合には、サーバ装置は、クライアント装置に記憶されているデータとは異なる更新済みのデータからクライアント装置が未受信の部分を切り出してクライアント装置に送信してしまうため、中断されたデータ送信を正しく再開できないといった問題点がある。
また、一般的にデータ通信に係る費用は、通信データ量に応じてユーザーに課金されるものであり、上述したようにダウンロード対象のデータが更新されていた場合には、中断されたデータ送信を正しく再開できないにもかかわらず、ユーザーは、通信コスト（通信時間、料金）の負担を強いられるといった問題点もある。
【０００７】
本発明は、上述した問題点を鑑みてなされたものであり、サーバ装置からのデータ送信が中断された場合には、中断されたデータ送信を中断された時点から再開することを可能にするとともに、データ送信が中断された時から、再開されるまでの間に、データが更新された場合であっても、ユーザーに無駄な通信コストの負担を強いることのないデータ取得方法を提供することを目的とする。
【０００８】
【課題を解決するための手段】
請求項１に係る発明は、中継装置が、クライアント装置から要求された第一のデータと該第一のデータに関連付けられた第二のデータとをサーバ装置から取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータを該クライアント装置に送信する送信過程と、前記クライアント装置が、前記中継装置からのデータ送信が中断された時点までに受信した前記第三のデータの既受信部分を記憶する記憶過程と、前記クライアント装置が前記既受信部分に基づいて前記第三のデータにおける前記データ送信が中断された位置を示す再開位置情報を算出し、該再開位置情報と前記既受信部分とに基づいて第一の再開判定情報を算出し、該再開位置情報と該第一の再開判定情報とを前記中継装置に送信して前記データ送信の再開を要求する要求過程と、前記中継装置が前記サーバ装置に格納されている前記第一及び第二のデータを取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータと前記再開位置情報とから第二の再開判定情報を算出し、該第二の再開判定情報と前記第一の再開判定情報とを比較し、両者が一致する場合にのみ、前記データ送信を再開可能と判定する判定過程と、前記中継装置が、前記判定過程にて前記データ送信を再開可能と判定された場合にのみ前記第三のデータのうち前記クライアント装置が受信していない未受信部分のみを前記クライアント装置に送信する未受信部分送信過程と、前記クライアント装置が、前記既受信部分と前記未受信部分とを結合して表示する表示過程とを有することを特徴とするデータ取得方法を提供する。
【０００９】
請求項３に係る発明は、中継装置が、クライアント装置から要求された第一のデータと該第一のデータに関連付けられた第二のデータとをサーバ装置から取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータを該クライアント装置に送信する送信過程と、前記クライアント装置が、前記中継装置からのデータ送信が中断された時点までに受信した前記第三のデータの既受信部分を記憶する記憶過程と、前記クライアント装置が前記既受信部分を第一の再開判定情報として前記中継装置に送信して前記データ送信の再開を要求する要求過程と、前記中継装置が前記サーバ装置に格納されている前記第一及び第二のデータを取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータの先頭から前記既受信部分の長さで特定される部分を第二の再開判定情報として取得し、該第二の再開判定情報と前記第一の再開判定情報とを比較し、両者が一致する場合にのみ、前記データ送信を再開可能と判定する判定過程と、前記中継装置が、前記判定過程にて前記データ送信を再開可能と判定された場合にのみ前記第三のデータのうち前記クライアント装置が受信していない未受信部分のみを前記クライアント装置に送信する未受信部分送信過程と、前記クライアント装置が、前記既受信部分と前記未受信部分とを結合して表示する表示過程とを有することを特徴とするデータ取得方法を提供する。
【００１０】
請求項４に係る発明は、クライアント装置から要求された第一のデータと該第一のデータに関連付けられた第二のデータとをサーバ装置から取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータを該クライアント装置に送信する送信手段と、前記送信手段からのデータ送信が中断された時点までに受信した前記第三のデータの既受信部分を記憶している前記クライアント装置が前記既受信部分に基づいて前記第三のデータにおける前記データ送信が中断された位置を示す再開位置情報を算出し、該再開位置情報と前記既受信部分とに基づいて第一の再開判定情報を算出し、該再開位置情報と該第一の再開判定情報とを送信して前記データ送信の再開を要求した場合に、前記サーバ装置に格納されている前記第一及び第二のデータを取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータと前記再開位置情報とから第二の再開判定情報を算出し、該第二の再開判定情報と前記第一の再開判定情報とを比較し、両者が一致する場合にのみ、前記データ送信を再開可能と判定する判定手段と、前記判定手段にて前記データ送信を再開可能と判定された場合にのみ前記第三のデータのうち前記クライアント装置が受信していない未受信部分のみを前記クライアント装置に送信する未受信部分送信手段とを有することを特徴とする中継装置を提供する。
【００１１】
請求項５に係る発明は、クライアント装置から要求された第一のデータと該第一のデータに関連付けられた第二のデータとをサーバ装置から取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータを該クライアント装置に送信する送信手段と、前記送信手段からのデータ送信が中断された時点までに受信した前記第三のデータの既受信部分を記憶している前記クライアント装置が前記既受信部分を第一の再開判定情報として送信して前記データ送信の再開を要求した場合に、前記サーバ装置に格納されている前記第一及び第二のデータを取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータの先頭から前記既受信部分の長さで特定される部分を第二の再開判定情報として取得し、該第二の再開判定情報と前記第一の再開判定情報とを比較し、両者が一致する場合にのみ、前記データ送信を再開可能と判定する判定手段と、前記判定手段にて前記データ送信を再開可能と判定された場合にのみ前記第三のデータのうち前記クライアント装置が受信していない未受信部分のみを前記クライアント装置に送信する未受信部分送信手段とを有することを特徴とする中継装置を提供する。
【００１２】
請求項６に係る発明は、コンピュータ装置を、クライアント装置から要求された第一のデータと該第一のデータに関連付けられた第二のデータとをサーバ装置から取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータを該クライアント装置に送信する送信手段と、前記送信手段からのデータ送信が中断された時点までに受信した前記第三のデータの既受信部分を記憶している前記クライアント装置が前記既受信部分に基づいて前記第三のデータにおける前記データ送信が中断された位置を示す再開位置情報を算出し、該再開位置情報と前記既受信部分とに基づいて第一の再開判定情報を算出し、該再開位置情報と該第一の再開判定情報とを送信して前記データ送信の再開を要求した場合に、前記サーバ装置に格納されている前記第一及び第二のデータを取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータと前記再開位置情報とから第二の再開判定情報を算出し、該第二の再開判定情報と前記第一の再開判定情報とを比較し、両者が一致する場合にのみ、前記データ送信を再開可能と判定する判定手段と、前記判定手段にて前記データ送信を再開可能と判定された場合にのみ前記第三のデータのうち前記クライアント装置が受信していない未受信部分のみを前記クライアント装置に送信する未受信部分送信手段として機能させるためのプログラムを提供する。
【００１３】
請求項７に係る発明は、コンピュータ装置を、クライアント装置から要求された第一のデータと該第一のデータに関連付けられた第二のデータとをサーバ装置から取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータを該クライアント装置に送信する送信手段と、前記送信手段からのデータ送信が中断された時点までに受信した前記第三のデータの既受信部分を記憶している前記クライアント装置が前記既受信部分を第一の再開判定情報として送信して前記データ送信の再開を要求した場合に、前記サーバ装置に格納されている前記第一及び第二のデータを取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータの先頭から前記既受信部分の長さで特定される部分を第二の再開判定情報として取得し、該第二の再開判定情報と前記第一の再開判定情報とを比較し、両者が一致する場合にのみ、前記データ送信を再開可能と判定する判定手段と、前記判定手段にて前記データ送信を再開可能と判定された場合にのみ前記第三のデータのうち前記クライアント装置が受信していない未受信部分のみを前記クライアント装置に送信する未受信部分送信手段として機能させるためのプログラムを提供する。
【００１４】
このようなデータ取得方法、中継装置、プログラムおよび記録媒体を用いると、中継装置は、クライアント装置から再開を要求されたデータ送信が再開可能である場合にのみデータ送信を再開する。
【００１５】
【発明の実施の形態】
以下、図面を参照して本発明に係る実施形態について説明する。ただし、本発明の技術的範囲は係る実施形態に限定されるものではなく、係る実施形態に周知技術を適用して得られる、特許請求の範囲に記載された範囲内の任意の態様を含む。
【００１６】
（１）全体構成
図１は、本発明に係るデータ取得方法を実施する通信システムの概要を示す図である。この図に示す通信システムでは、データ端末装置（以下、「ＤＴＥ」とする）１１は、ＨＴＴＰ（Hyper Text Transfer Protocol）のＧＥＴメソッドまたはＰＯＳＴメソッドを用いて軽量代理サーバ（以下、「ＬＷＰ」とする）１５を介してインターネット１４に接続されたＷＷＷサーバ１６からコンテンツをダウンロードしている。
ここで、ＤＴＥ１１とＬＷＰ１５との間で、ＧＥＴメソッドを用いたコンテンツのダウンロードが中断されると、ＤＴＥ１１は当該ダウンロードが中断された時点までに受信した部分（以下、「既受信部分」とする）を記憶し、その後、ユーザーにより中断されたダウンロードの再開が指示されると、ＬＷＰ１５に中断されたダウンロードの再開を要求する。すなわち、ＤＴＥ１１は、中断により受信しなかった部分（以下、「未受信部分」とする）のみの送信をＬＷＰ１５に要求する。
一方、ＤＴＥ１１からダウンロードの再開を要求されたＬＷＰ１５は、既受信部分とＷＷＷサーバ１６に記憶されているコンテンツの既受信部分に対応する部分とが一致するか否かを判定し、一致した場合にのみ未受信部分をＤＴＥ１１へ送信する。この未受信部分をＤＴＥ１１が受信すると、ＤＴＥ１１は自装置に記憶している既受信部分とＬＷＰ１５から送信された未受信部分とを結合してコンテンツを取得する。
以上に説明したように、図１に示す通信システムは、中断されたコンテンツのダウンロードの再開を可能とすると同時に、既受信部分とコンテンツの既受信部分に対応する部分とが一致しない場合には、未受信部分の送信を行わずに、ＬＷＰ１５からＤＴＥ１１への無用なデータのダウンロードを抑止している。
【００１７】
なお、図１に示す通信システムは、ＰＯＳＴメソッドによるコンテンツのダウンロードが中断された場合には、当該中断されたダウンロードの再開を行わない。これは、ＰＯＳＴメソッドを用いてダウンロードされるコンテンツは、ダウンロードが要求される度毎にＷＷＷサーバでＣＧＩ（Common Gateway Interface）等を用いて動的に生成されるものであり、ＤＴＥ１１が、最初のダウンロードを要求した時点と再開を要求した時点とで、必ずしも同一のコンテンツが生成されないからである。
また、この図においては、図面および説明が煩雑になることを防ぐために、１つのＷＷＷサーバと１つのＤＴＥとが例示されているが、実際には多数のＷＷＷサーバとＤＴＥとが存在する。またＤＴＥは携帯電話機能を有し、移動通信網経由で音声通話を行うことが可能であるが、音声通話に係る部分は本発明とは直接関係がないため、本実施形態においては、音声通話に係る説明および図示を省略する。
【００１８】
（２）ＤＴＥ１１−ＬＷＰ１５間およびＬＷＰ１５−ＷＷＷサーバ１６間の通信シーケンス
図２は、図１に示す通信システムで、ＤＴＥ１１がＬＷＰ１５を介してＷＷＷサーバ１６からテキストデータと画像データとから構成されているコンテンツをダウンロードする場合に、ＤＴＥ１１とＬＷＰ１５とＷＷＷサーバ１６のとの間で送受信される通信シーケンスを示す図である。
【００１９】
まず、ＤＴＥ１１は、テキストデータのダウンロードを要求するリクエスト２１をＬＷＰ１５に送信する。このリクエスト２１は移動パケット通信網１２、ゲートウェイサーバ１３、インターネット１４を順に介してＬＷＰ１５へ到達する。
ＤＴＥ１１から送信されたリクエスト２１を受信したＬＷＰ１５は、当該テキストデータのダウンロードを要求するリクエスト２２をインターネット１４を介してＷＷＷサーバ１６に送信する。
ＬＷＰ１５から送信されたリクエスト２２を受信したＷＷＷサーバ１６は、リクエスト２２に指定されているテキストデータを読み出し、当該テキストデータを含んだレスポンス２３をインターネット１４を介してＬＷＰ１５に返信する。このレスポンス２３をＬＷＰ１５が受信すると、詳細は後述するコンテンツ代理取得処理で説明するが、ＬＷＰ１５は当該テキストデータに関連付けられている画像データのダウンロードを要求するリクエスト２４をＷＷＷサーバ１６へ送信する。
ＬＷＰ１５から送信されたリクエスト２４を受信したＷＷＷサーバ１６は、リクエスト２４に指定されている画像データを読み出し、当該画像データを含んだレスポンス２５をインターネット１４を介してＬＷＰ１５に返信する。
このレスポンス２５をＬＷＰ１５が受信すると、詳細は後述する関連データ結合処理で説明するが、ＬＷＰ１５は先に取得したテキストデータと画像データとから後述するダウンロードデータを生成する。
次に、ＬＷＰ１５は当該ダウンロードデータを含むレスポンス２６をＤＴＥ１１から送信されたリクエスト２１に対応したレスポンスとしてＤＴＥ１１へ送信する。ＬＷＰ１５から送信されたレスポンス２６はインターネット１４、ゲートウェイサーバ１３、移動パケット通信網１２を順に介してＤＴＥ１１により受信される。
なお、図２では、図面が煩雑になることを防ぐために、各通信メッセージ（各リクエストおよび各レスポンス）は、１つの通信メッセージであるかのように示されているが、実際には、通信対象のデータを所定の大きさ（バイト数）に分割した複数のパケットの送受信が行われている。以下の説明では、本発明の説明に直接関連する場合を除き、各通信メッセージを１つのパケットの送受信であるとして説明する。
【００２０】
（３）ＬＷＰ１５で生成されるダウンロードデータの概略
上述したように、ＬＷＰ１５は、ＤＴＥ１１からダウンロードを要求されたコンテンツが、テキストデータと当該テキストデータに対応付けられた画像データとから構成されている場合には、これらテキストデータと画像データとから１つのダウンロードデータを生成し、当該ダウンロードデータをＤＴＥ１１へ送信している。以下では、ＤＴＥ１１から要求されたコンテンツがテキストデータ（aaaa.html）と画像データ（bbbb.gif）とから構成されている場合に、ＬＷＰ１５が生成するダウンロードデータについて説明する。
図３は、テキストデータ（aaaa.html）の要部を示す図である。当該テキストデータはＨＴＭＬで記述されており、図３に示すように、ＩＭＧタグを有している。ここで、ＩＭＧタグとは、当該テキストデータに関連付けられた画像データに関する情報を記述するタグである。具体的には、ＩＭＧタグのＳＲＣ属性には当該テキストデータに関連付けられている画像データのＵＲＩ（Uniform Resource Identifier）が記述されており、ＷＩＤＴＨ属性およびＨＩＧＨＴ属性には表示する画像の大きさが記述されている。当該ＩＭＧタグには、図４に示される画像イメージを記憶した画像データ（bbbb.gif）のＵＲＩが、ＳＲＣ属性に記述されている。
図５は、上述のテキストデータ（aaaa.html）と画像データ（bbbb.gif）とから生成されるダウンロードデータの概要を示す図である。この図に示されるようにダウンロードデータは、テキスト領域５１と画像領域５２との二つの領域を有している。テキスト領域５１には、テキストデータ（aaaa.html）のＩＭＧタグのＳＲＣ属性に指定されているＵＲＩを所定の文字列（例えば、ＩＭＧＤＡＴＡ０１）で置き換えたものが格納されている。一方、画像領域５２には、テキストデータのＩＭＧタグのＳＲＣ属性に指定されていた画像データ（bbbb.gif）を所定のアルゴリズム（例えば、Ｂａｓｅ６４）でエンコードしてテキスト化したデータ（以下、「画像テキスト」とする）が格納されている。ここで、当該画像テキストには、当該画像テキストの開始位置を示すタグである＜ＩＭＧＤＡＴＡ０１＞と、当該画像テキストの終了位置を示すタグ＜／ＩＭＧＤＡＴＡ０１＞とが付与されている。
なお、コンテンツがテキストデータのみから構成されている場合には、ＬＷＰ１５は、画像領域５２を有しないダウンロードデータを生成する。また、テキストデータに複数個の画像データが関連付けれれている場合には、ＬＷＰ１５は、図６に示すように、テキストデータに関連付けられている画像データの個数分だけ、画像領域５２に複数個の画像テキストを有するダウンロードデータを生成する。
【００２１】
（４）ＷＷＷサーバ１６の構成および機能
ＷＷＷサーバ１６は、インターネット１４を用いて実現されているＷＷＷを構成する一般的なコンピュータ装置であり、インターネット１４を介してＨＴＴＰに従ったリクエストを受信すると、これに対応したレスポンスをインターネット１４へ送出するＨＴＴＰサーバ機能を備えている。例えば、ＷＷＷサーバは、ＨＴＭＬで記述されたテキストデータと画像データ等のデータファイルとを記憶しており、受信したリクエストがＧＥＴメソッドで指定されたＵＲＩに対応するファイルを読み出し、当該ファイルを含んだレスポンスを返信する。
【００２２】
（５）ＤＴＥ１１の構成および機能
（５−１）ＤＴＥ１１の構成
図７は、ＤＴＥ１１のハードウェア構成を示すブロック図であり、この図に示されるようにＤＴＥ１１は、ＣＰＵ７１と、無線通信部７２と、操作部７３と、表示部７４と、揮発性メモリ７５と、不揮発性メモリ７６と、各要素間のデータ授受を仲介するバス７７とを有している。
【００２３】
無線通信部７２は、例えばアンテナ等を含む無線通信インターフェースであり、ＣＰＵ７１から供給された情報を移動パケット通信網１２へ送出するとともに、移動パケット通信網１２を介して受信した情報をＣＰＵ７１へ渡す。操作部７３は、例えばユーザーに操作される操作子（テンキーやカーソル等）を備え、操作子の操作内容を示す情報をＣＰＵ７１へ渡す。表示部７４は、例えば液晶ディスプレイであり、ＣＰＵ７１から供給される画像情報に応じた画像を表示する。
【００２４】
揮発性メモリ７５は、ＲＡＭ（Random Access Memory）であり、不揮発性メモリ７６は、例えばデータを書き換え不能に記憶するＲＯＭ（Read Only Memory）７６１と、データを書き換え可能に記憶するＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）７６２とを有する。ＲＯＭ７６１は、オペレーティングシステム（以下「ＯＳ」という）やブラウザ等のソフトウェアを記憶している。
【００２５】
（５−２）ＤＴＥ１１の機能
次に、ＣＰＵ７１がＲＯＭ７６１に記憶されているソフトウェアを実行することによりＣＰＵ７１に付与される機能について説明する。ただし、ブラウザを搭載している一般的な携帯電話の有する機能と略同一の機能については説明を省略し、ここでは、本実施形態の動作に直接的に関係する機能についてのみ説明する。
【００２６】
ＣＰＵ７１は、ＤＴＥ１１の電源（図示略）が投入されると、ＲＯＭ７６１からＯＳを読み出して実行する。ＯＳを実行した状態のＣＰＵ７１は、揮発性メモリ７５をワークエリアとして使用すること、ＤＴＥ１１の各部を制御すること、およびユーザーによる操作部７３の操作内容に応じて、ブラウザ等のソフトウェアをＲＯＭ７６１から読み出して実行することができる。
なお、ＤＴＥ１１に搭載されているブラウザには、ＵＲＩを指定してコンテンツ全体のダウンロードを要求するためのユーザーインターフェースが設けられている他に、ＵＲＩを指定して未受信部分のみのダウンロードを要求するためのユーザーインターフェースも設けられている。
【００２７】
（５−２−１）プロファイル情報設定機能
プロファイル情報設定機能は、ＣＰＵ７１が、ユーザーにより入力されたＬＷＰのサーバ名またはＩＰアドレスや、中断されたダウンロードの再開を許可するか否かを示す情報等のＤＴＥ１１とＬＷＰ１５との間の通信に関する情報をプロファイル情報としてＥＥＰＲＯＭ７６２に記憶させる機能である。
【００２８】
図８は、プロファイル情報設定プログラムを実行中のＣＰＵ７１により実行されるプロファイル情報設定処理の流れを示すフローチャートである。この図に示されるように、ユーザーがＤＴＥ１１の操作部７３を用いて、プロファイル情報設定処理の開始を指示すると、ＣＰＵ７１は、ＥＥＰＲＯＭ７６２に記憶されているプロファイル情報を読み出して揮発性メモリ７５に一時的に記憶させるとともに、表示部７４を制御し、揮発性メモリ７５に一時的に記憶させたプロファイル情報にもとづいて図９に示すプロファイル情報設定画面を表示させる（ステップＳＡ１）。
【００２９】
図９はプロファイル情報設定画面の一例を示す図であり、入力領域９１は、ＤＴＥ１１と通信を行うＬＷＰ１５のＩＰアドレスが入力される入力領域であり、リストボックス９２は、表示部７４に表示する画像の表示階調が入力される入力領域であり、リストボックス９３には、中断されたダウンロードの再開を許可するか否かを示す情報が入力される入力領域である。
ユーザーにより何らかの入力操作が行われると、ＣＰＵ７１は操作部７３を介してユーザーの操作内容を受け取り（ステップＳＡ２）、ユーザーの操作内容の判定を行う（ステップＳＡ３）。すなわち、ユーザーの操作内容が設定ボタン９４の押下（以下「設定操作」という）であるか、キャンセルボタン９５の押下（以下「キャンセル操作」という）であるか、設定操作でもなく、キャンセル操作でもない操作（以下「その他操作」という）であるかを判定する。
【００３０】
ユーザーの操作内容が、その他操作であった場合には、ＣＰＵ７１は、ユーザーの操作内容で揮発性メモリ７５に記憶してあるプロファイル情報を更新して、当該更新後のプロファイル情報にもとづいてプロファイル情報設定画面を表示部７４に再表示（ステップＳＡ１）させ、再度ユーザーからの入力操作を待ち受ける。
ユーザーの操作内容が、設定操作であった場合には、ＣＰＵ７１は、揮発性メモリ７５に記憶してあるプロファイル情報で、ＥＥＰＲＯＭ７６２に記憶されているプロファイル情報を上書き更新（ステップＳＡ４）して、プロファイル情報設定処理を終了する。ユーザーの操作内容が、キャンセル操作であった場合には、ＣＰＵ７１は、上記の上書き更新を行わずにプロファイル情報設定処理を終了する。
【００３１】
（５−２−２）コンテンツ取得機能および解釈・表示機能
コンテンツ取得機能は、ＤＴＥ１１がＬＷＰ１５を介してＷＷＷサーバ１６からコンテンツをダウンロードする機能であり、ブラウザを実行した状態のＣＰＵ７１が備えるＨＴＴＰクライアント機能を用いて実現される。また、解釈・表示機能はダウンロードされたコンテンツを解釈・表示する機能であり、ブラウザを実行したＣＰＵ７１が備えるＨＴＭＬ解釈機能とユーザーインターフェース提供機能とを用いて実現される。
【００３２】
図１０は、ブラウザを実行中のＣＰＵ７１により実行されるコンテンツ取得処理の流れを示すフローチャートである。この図に示されように、ユーザーがＤＴＥ１１の操作部７３を用いてコンテンツ取得処理の開始を指示すると、ＣＰＵ７１は、まず、ユーザーの操作内容が、コンテンツ全体をダウンロードを要求する操作（以下、「全体要求操作」という）であるか、中断されたダウンロードを再開し、コンテンツの未受信部分のみのダウンロードを要求する操作（以下、「未受信部分要求操作」という）であるかの判定を行う（ステップＳＢ１）。
全体要求操作であった場合には、ＣＰＵ７１は、後述する全体要求処理を行い（ステップＳＢ２）、当該コンテンツ取得処理を終了する。
未受信部分要求操作であった場合には、ＣＰＵ７１は、まず、ＥＥＰＲＯＭ７６２からプロファイル情報を読み出し、中断されたダウンロードの再開が許可されているか否かの判定を行う（ステップＳＢ３）。
【００３３】
許可されている場合には、ＣＰＵ７１は、後述する未受信部分要求処理を行い（ステップＳＢ４）、当該コンテンツ取得処理を終了する。
許可されていない場合には、ＣＰＵ７１は、ユーザーにプロファイル情報の設定を促すテキストデータ（例えば、“プロファイル情報を再設定して下さい”）を表示部７４に表示させて（ステップＳＢ５）、当該コンテンツ取得処理を終了する。
【００３４】
（５−２−３）全体要求処理
図１１は、ブラウザを実行中のＣＰＵ７１により実行される全体要求処理の流れを示すフローチャートである。まず、ＣＰＵ７１は、無線通信部７２を制御してＣＰＵ７１とＬＷＰ１５との間にＴＣＰコネクション（以下、「クライアントＴＣＰコネクション」とする）を確立する（ステップＳＣ１）。次に、ＣＰＵ７１はＧＥＴメソッドを用いたリクエスト（例えば、“GET //?http://www.****.co.jp/a
aa.html/HTTP/1.0”）を生成し、当該リクエストを上記クライアントＴＣＰコネクションを介してＬＷＰ１５に送信する（ステップＳＣ２）。
【００３５】
以後、ＣＰＵ７１は上記リクエストに対するレスポンスの受信を完了したか否かの判定を行う（ステップＳＣ３）。
完了していない場合にのみ、ＣＰＵ７１は、所定の時間が経過した否かの判定を行い（ステップＳＣ４）、経過していない場合には、ステップＳＣ３以降の処理を繰り返し、経過した場合には、上記リクエストに記述されていたＵＲＩとプロファイル情報と既受信部分とを対応付けてＥＥＰＲＯＭ７６２に記憶する（ステップＳＣ５）。
【００３６】
次に、ＣＰＵ７１は、上記クライアントＴＣＰコネクションを切断し（ステップＳＣ６）、ＬＷＰ１５から送信されたダウンロードデータに対して後述するコンテンツ表示処理を行い（ステップＳＣ７）、当該全体要求処理を終了する。なお、通信障害などにより、クライアントＴＣＰコネクションが既に切断されている場合には、ＣＰＵ７１は、ステップＳＣ６の処理を行わない。
【００３７】
（５−２−４）未受信部分要求処理
図１２は、ブラウザを実行中のＣＰＵ７１により実行される未受信部分要求処理の流れを示すフローチャートである。まず、ＣＰＵ７１は、ＥＥＰＲＯＭ７６２からユーザーにより未受信部分要求操作が行われたＵＲＩに対応する既受信部分を取得し、当該既受信部分に対して後述する再開位置情報算出処理を行い、再開位置情報を取得する（ステップＳＤ１）。
【００３８】
次に、ＣＰＵ７１は、ＥＥＰＲＯＭ７６２に記憶されている既受信部分の先頭から再開位置情報で指定される部分に対して所定のハッシュ値生成アルゴリズム（例えば、Ａｄｌｅｒ−３２）を用いてハッシュ値を算出し、当該ハッシュ値を再開判定情報として取得する（ステップＳＤ２）。ここで、ハッシュ値生成アルゴリズムとは、入力データから固定長の疑似乱数を生成するアルゴリズムであり、当該アルゴリズムにより生成された固定長の擬似乱数を「ハッシュ値」と呼ぶ。一般に、ハッシュ値生成アルゴリズムには、不可逆な一方向演算を含むため、ハッシュ値から入力データを再現することはできず、また、同じハッシュ値を持つ異なるデータを作成することが極めて困難である。
【００３９】
次に、ＣＰＵ７１は、上述した全体要求処理のステップＳＣ１と同一の処理を行い、ＣＰＵ７１とＬＷＰ１５との間にクライアントＴＣＰコネクションを確立し（ステップＳＤ３）、ＨＴＴＰのＧＥＴメソッドを用いたリクエスト（例えば、“GET /offset-cheksum//?http:www.****.co.jp/aaaa.html/HTTP1.0”）を生成して、当該リクエストを上記クライアントＴＣＰコネクションを介してＬＷＰ１５に送信する（ステップＳＤ４）。なお、上記のリクエスト例で、offsetはステップＳＤ１で取得した再開位置情報を１６進数文字列に変換した文字列データであり、checksumはステップＳＤ２で取得した再開判定情報を１６進数文字列に変換した文字列データである。
【００４０】
以後、ＣＰＵ７１は上記リクエストに対するレスポンスの受信を完了したか否かの判定を行い（ステップＳＤ５）、完了していない場合にのみ、ＣＰＵ７１は、所定の時間が経過した否かの判定を行い（ステップＳＤ６）、経過していない場合には、ステップＳＤ５以降の処理を繰り返し、経過した場合には、上記リクエストに記述されていたＵＲＩとプロファイル情報と既受信部分とを対応付けてＥＥＰＲＯＭ７６２に記憶する（ステップＳＤ７）。
【００４１】
次に、ＣＰＵ７１は、上記クライアントＴＣＰコネクションを切断し（ステップＳＤ８）、ＬＷＰ１５から未受信部分が送信されたか否かを判定する（ステップＳＤ９）。なお、通信障害などにより、クライアントＴＣＰコネクションが既に切断されている場合には、ＣＰＵ７１は、ステップＳＤ８の処理を行わない。未受信部分が送信された場合には、ＣＰＵ７１はＥＥＰＲＯＭ７６２に記憶されている既受信部分とＬＷＰ１５から受信した未受信部分とを結合してダウンロードデータを取得し（ステップＳＤ１０）、当該ダウンロードデータに対して後述するコンテンツ表示処理を行って（ステップＳＤ１１）、当該未受信部分要求処理を終了する。
未受信部分が送信されなかった場合には、ＣＰＵ７１は、未受信部分が送信されなかったことを示すテキストデータ（例えば、“コンテンツは更新されています。”）を表示部７４に表示させて（ステップＳＤ１２）、当該未受信部分要求処理を終了する。
【００４２】
（５−２−５）再開位置情報算出処理
図１３は、コンテンツ取得処理を実行中のＣＰＵ７１により実行される再開位置情報算出処理の流れを示すフローチャートである。まず、ＣＰＵ７１は、ＥＥＰＲＯＭ７６２からユーザーにより入力されたＵＲＩに対応する既受信部分を読み出し、当該既受信部分が画像テキストを有するか否かの判定を行う。すなわち、ＣＰＵ７１は、既受信部分が所定のタグ（本実施形態の場合には、上述した＜ＩＭＧＤＡＴＡ０１＞タグ）を有する場合には、画像テキストを有すると判定し、当該タグを有しない場合には、画像テキストを有しないと判定する（ステップＳＥ１）。
【００４３】
画像テキストを有しない場合には、ＣＰＵ７１は、当該既受信部分の大きさ（バイト数）を再開位置情報として、当該再開位置情報算出処理を終了する（ステップＳＥ２）。
画像テキストを有する場合には、ＣＰＵ７１は、当該既受信部分に対応づけらえたプロファイル情報をＥＥＰＲＯＭ７６２から取得し、当該プロファイル情報に設定されている表示階調と、現在のプロファイル情報に設定されている表示階調とが異なるか否かを判定する（ステップＳＥ３）。
【００４４】
同一である場合には、ＣＰＵ７１は、当該既受信部分の大きさを再開位置情報とし（ステップＳＥ４）、異なる場合には、当該既受信部分のテキスト部５１の大きさ（バイト数）を再開位置情報として（ステップＳＥ５）、当該再開位置算出処理を終了する。
【００４５】
（５−２−６）コンテンツ表示処理
ＣＰＵ７１は、ダウンロードデータのテキスト領域５１（図５参照）をＨＴＭＬ文法に従って解釈し、その記述に応じたレイアウトの画像データを生成し、表示部７４に供給する。なお、完全にコンテンツを取得できなかった場合には、ＣＰＵ７１は、取得した部分までの解釈を行う。当該解釈においては、ＣＰＵ７１は階層的に記述された各種のタグに対応した処理を行う。ＣＰＵ７１が行う処理のうち、本実施形態の動作に直接関連する処理について以下に説明する。
【００４６】
▲１▼ＩＭＧタグ処理
ＣＰＵ７１は、ＩＭＧタグのＳＲＣ属性に記述されている文字列（例えば、“ＩＭＧＤＡＴＡ０１”）と同一の文字列を有するタグ（例えば、＜ＩＭＧＤＡＴＡ０１＞）で特定される画像テキストを画像領域５２から読み出し、当該画像テキストを所定のアルゴリズム（例えば、Ｂａｓｅ６４等）を用いてデコードして画像データに再生し、表示部７４を制御して当該画像データで表される画像をＩＭＧタグに指定されているＷＩＤＴＨ属性およびＨＩＧＨＴ属性で指定されたサイズで表示させる。
【００４７】
（６）ＬＷＰ１５の構成および機能
（６−１）ＬＷＰ１５の構成
図１４は、ＬＷＰ１５のハードウェア構成を示すブロック図であり、この図に示されるようにＬＷＰ１５は、ＣＰＵ１４１と、通信インターフェース部１４２と、不揮発性メモリ１４３と、揮発性メモリ１４４と、記憶装置１４５と、補助記憶装置１４６と、これら各要素間のデータ授受を仲介するバス１４７とを有している。
【００４８】
通信インターフェース部１４２は、例えばネットワークインターフェースであり、ＣＰＵ１４１から供給された情報をインターネット１４へ送出するとともに、インターネット１４を介して受信した情報をＣＰＵ１４１へ渡す。不揮発性メモリ１４３は、例えばＲＯＭ（Read Only Memory）であり、ＬＷＰ１５の電源が投入されたときに、記憶装置１４５に記憶されているＯＳを読み出して実行する機能を有するプログラムであるＩＬ（Initial Loader）を記憶している。揮発性メモリ１４４は、例えばＲＡＭ（Random Access Memory）である。補助記憶装置１４６は、例えばＣＤ−ＲＯＭ等のコンピュータ装置が読み取り可能な記録媒体に記録されているデータを読み取る機能を有するものである。記憶装置１４５は、例えばハードディスクドライブであり、ＯＳおよび後述するコンテンツ代理取得プログラム等のソフトウェア等を記憶している。
【００４９】
（６−２）ＬＷＰ１５の機能
次に、ＣＰＵ１４１が記憶装置１４５に記憶されたソフトウェアを実行することでＬＷＰ１５に付与される機能について説明する。なお、ＤＴＥ１１とＷＷＷサーバ１６との通信を中継するためのＨＴＴＰ処理機能については、一般的な代理サーバ装置の有する機能と略同一であるため説明を省略し、本実施形態に直接関係する機能についてのみ説明する。
【００５０】
ＣＰＵ１４１は、ＬＷＰ１５の電源（図示略）が投入されると、まず、不揮発性メモリ１４３からＩＬを読み出して実行する。ＩＬを実行した状態のＣＰＵ１４１は、記憶装置１４５からＯＳを読み出して実行する。ＯＳを実行した状態のＣＰＵ１４１は、揮発性メモリ１４４をワークエリアとして使用すること、ＬＷＰ１５の各部を制御することができる。なお、ＯＳを実行中のＣＰＵ１４１は複数のプログラムを並列に実行することができる。また、ＣＰＵ１４１は、即座にコンテンツ代理取得を行うためのプログラムを起動し、ＤＴＥ１１からのリクエストを待ちうける。
【００５１】
（６−２−１）コンテンツ代理取得機能
コンテンツ代理取得機能は、ＤＴＥ１１からのリクエストに応じてＷＷＷサーバ１６からコンテンツを取得して、ＤＴＥ１１からのリクエストに応じた加工を行った後に上記リクエストに対するレスポンスとしてＤＴＥ１１へ転送する機能である。
【００５２】
図１５は、コンテンツ代理取得プログラムを実行中のＣＰＵ１４１により実行されるコンテンツ代理取得処理の流れを示すフローチャートである。この図に示されるように、ＣＰＵ１４１は、ＤＴＥ１１からのコネクション確立要求に応じてクライアントＴＣＰコネクションを確立する（ステップＳＦ１）。そして当該ＴＣＰコネクションを介してＤＴＥ１１からＨＴＴＰのＧＥＴメソッドを用いたリクエストを受信すると、ＣＰＵ１４１は、当該ＧＥＴメソッドのリクエストラインを解析し、当該リクエストラインに記述されているＵＲＩや再開位置情報や再開判定情報を取得する（ステップＳＦ２）。
【００５３】
次に、ＣＰＵ１４１は、ＤＴＥ１１から受信したリクエストに記述されていたＵＲＩに対応するＷＷＷサーバ１６との間でＴＣＰコネクション（以下、「サーバＴＣＰコネクション」とする）を確立する（ステップＳＦ３）。
【００５４】
更にＣＰＵ１４１は、当該リクエストを加工（例えば、クライアントＴＣＰコネクションを介してＤＴＥ１１から受信したリクエストでは、当該リクエストの送信元はＤＴＥ１１になっているが、当該リクエストの送信元をＬＷＰ１５に書き換える等）し、加工後のリクエストを当該サーバＴＣＰコネクション経由で送信する（ステップＳＦ４）。
以後、ＣＰＵ１４１は上記リクエストに対するレスポンスを待ち（ステップＳＦ５）、当該レスポンスを受信すると、当該サーバＴＣＰコネクションを切断する（ステップＳＦ６）。なお、通信障害などにより、サーバＴＣＰコネクションが既に切断されている場合には、ＣＰＵ７１は、ステップＳＦ６の処理を行わない。
【００５５】
次に、ＣＰＵ１４１は、上記レスポンスに含まれるテキストデータに、後述する関連データ結合処理を行ってダウンロードデータを生成する（ステップＳＦ７）。
次に、ＣＰＵ１４１は、ＤＴＥ１１からコンテンツ全体の送信を要求されたのか、未受信部分のみの送信を要求されたのかを判定する（ステップＳＦ８）。
コンテンツ全体の送信を要求された場合には、ＣＰＵ１４１は、ステップＳＦ７で生成したダウンロードデータを上記クライアントＴＣＰコネクションを介して、ＤＴＥ１１からのリクエストに対応するレスポンスとして送信し（ステップＳＦ９）、当該クライアントＴＣＰコネクションを切断し（ステップＳＦ１４）、当該コンテンツ代理取得処理を終了する。
未受信部分のみの送信を要求された場合には、ＣＰＵ１４１は、ステップＳＦ７で生成したダウンロードデータに対して再開判定情報を算出する（ステップＳＦ１０）。具体的には、当該ダウンロードデータの先頭から、ステップＳＦ２で取得した再開位置情報で指定される長さの部分に対して、ＤＴＥ１１で用いたハッシュ値生成アルゴリズムと同一のアルゴリズムを用いて再開判定情報を算出する。
【００５６】
次に、ＣＰＵ１４１は、ステップＳＦ１０で算出した再開判定情報と、ステップＳＦ２で取得した再開判定情報とが一致するか否かの判定を行う（ステップＳＦ１１）。
一致する場合には、ＣＰＵ１４１は、ステップＳＦ７で生成したダウンロードデータの先頭からステップＳＦ２で取得した再開位置情報で指定される長さの部分を切り捨てて未受信部分を生成し、当該未受信部分を上記クライアントＴＣＰコネクションを介して、ＤＴＥ１１からのリクエストに対応するレスポンスとして送信し（ステップＳＦ１２）、当該クライアントＴＣＰコネクションを切断し（ステップＳＦ１４）、当該コンテンツ代理取得処理を終了する。
一致しない場合には、ＣＰＵ１４１は、再開不能であることを示す情報を含むレスポンスを、対応するクライアントＴＣＰコネクションを介して、ＤＴＥ１１からのリクエストに対応するレスポンスとして送信した後に（ステップＳＦ１３）、当該クライアントＴＣＰコネクションを切断し（ステップＳＦ１４）、当該コンテンツ代理取得処理を終了する。
【００５７】
（６−２−２）関連データ結合処理
図１６は、コンテンツ代理取得処理を実行中のＣＰＵ１４１により実行される関連データ結合処理の流れを示すフローチャートである。この図に示されるように、まず、ＣＰＵ１４１は、コンテンツ代理取得処理のステップＳＦ５でＷＷＷサーバ１６から取得したテキストデータを解析し、当該テキストデータがＩＭＧタグを有するか否かを判定する（ステップＳＧ１）。
【００５８】
ＩＭＧタグを有しない場合には、ＣＰＵ１４１は、当該テキストデータをダウンロードデータとして当該関連データ結合処理を終了し、ＩＭＧタグを有する場合には、ＣＰＵ１４１は、当該ＩＭＧタグのＳＲＣ属性に指定されたＵＲＩに対応するＷＷＷサーバとの間でサーバＴＣＰコネクションを確立する（ステップＳＧ２）。
【００５９】
次に、ＣＰＵ１４１は、当該ＵＲＩで指定される画像データを取得するためのリクエストを生成し、当該サーバＴＣＰコネクションを介して当該ＵＲＩで指定されるＷＷＷサーバに送信する（ステップＳＧ３）。
以後、ＣＰＵ１４１は当該リクエストに対するレスポンスの受信を待ち（ステップＳＧ４）、当該レスポンスを受信すると、当該サーバＴＣＰコネクションを切断する（ステップＳＧ５）。なお、通信障害などにより、当該サーバＴＣＰコネクションが既に切断されている場合には、ＣＰＵ７１は、ステップＳＧ５の処理を行わない。
【００６０】
次に、ＣＰＵ１４１は、揮発性メモリ１４４に記憶されているプロファイル情報から表示階調を読み出し、ステップＳＦ４で取得した画像データを当該表示階調になるように圧縮して、圧縮済みの画像データを生成し（ステップＳＧ６）、当該圧縮済みの画像データを、所定のアルゴリズム（例えば、Ｂａｓｅ６４）を用いてエンコードして画像テキストを生成し、当該画像テキストを揮発性メモリ１４４に一時的に記憶させる（ステップＳＧ７）。
【００６１】
次に、ＣＰＵ１４１は、テキストデータのＩＭＧタグのＳＲＣ属性で指定されているＵＲＩを所定の文字列（例えば、“ＩＭＧＤＡＴＡ０１”）に置き換え、更に、ステップＳＧ７で生成した画像テキストの開始位置と終了位置とを指定するために、所定のタグ（例えば、上述の＜ＩＭＧＤＡＴＡ０１＞タグと＜／ＩＭＧＤＡＴＡ０１＞タグ）を付与して、ＩＭＧタグを書き換えたテキストデータの末尾へ追加書き込みする（ステップＳＧ８）。
以降、ＣＰＵ１４１は、テキストデータに記述されているＩＭＧタグの個数分だけ、ステップＳＧ２からステップＳＧ８までの処理を行ってダウンロードデータを生成し、当該関連データ結合処理を終了する。
【００６２】
（７）動作例
本実施形態の動作はプロファイル情報の内容、コンテンツの内容に応じて異なり、その動作パターンは多数となるが、以下では本発明の特徴を表す動作例について説明する。ただし、以下に説明する動作例の前提として、ＤＴＥ１１がＷＷＷサーバ１６から取得するコンテンツは、図３に示されるテキストデータ（aaaa.html）と図４に示される画像データ（bbbb.gif）とから構成されているものとし、当該コンテンツがＤＴＥ１１へダウンロードされると、ＤＴＥ１１は、図１７に示す画像を表示部７４に表示する。
【００６３】
（７―１）ダウンロードが中断された場合の動作例
ＤＴＥ１１がＷＷＷサーバ１６から上記のコンテンツをダウンロード中に、ダウンロードが中断された場合の動作について図１８に示すシーケンス図を用いて説明する。ユーザーがＤＴＥ１１の操作部７３を操作してＷＷＷサーバ１６からコンテンツ全体を取得することを指示すると、ＤＴＥ１１は、上述したコンテンツ取得機能を用いて全体要求処理（図１０：ステップＳＢ２）を行う。まず、ＤＴＥ１１は、ＬＷＰ１５との間でクライアントＴＣＰコネクションを確立し（図１１：ステップＳＣ１）、ＬＷＰ１５へテキストデータ（aaaa.html）を要求するリクエスト１７１を送信する（図１１：ステップＳＣ２）。
【００６４】
上記リクエストを受信したＬＷＰ１５は、上述したコンテンツ代理取得機能を用いてコンテンツ代理取得処理を行い、まず、ＷＷＷサーバ１６からテキストデータ（aaaa.html）を取得する（図１５：ステップＳＦ５）。次に、ＬＷＰ１５は、上述した関連データ結合処理を行い（図１５：ステップＳＦ６）、当該テキストデータを解析する（図１６：ステップＳＧ１）。当該テキストデータはＩＭＧタグを有するので、ＬＷＰ１５は、ＷＷＷサーバ１６から画像データ（bbbb.gif）を取得し（図１６：ステップＳＧ４）、テキストデータ（aaaa.html）と画像データ（bbbb.gif）とから図５に示すダウンロードデータを生成し（図１６：ステップＳＧ８）、当該ダウンロードデータを含むレスポンス１７６をＤＴＥ１１へ返信する（図１５：ステップＳＦ９）。なお、当該レスポンスは当該ダウンロードデータを所定のデータ量（バイト数）に分割した複数のパケットの送受信として行われる。
【００６５】
ここで、コンテンツをダウンロード中のユーザーが通信サービスエリア外に移動したことにより、ＤＴＥ１１とＬＷＰ１５とのクライアントＴＣＰコネクションが切断されたとする。すると、ＤＴＥ１１は、所定の時間が経過するまでレスポンスの受信完了を待ち受けるが（図１１：ステップＳＣ３）、もはや、後続のパケットを受信することはない。以降、所定の時間が経過するとＤＴＥ１１は、これまでに受信したパケットに含まれるデータを既受信部分としてＵＲＩやプロファイル情報と対応づけてＥＥＰＲＯＭ７６２に記憶し（図１１：ステップＳＣ５）、既受信部分を表示する（図１１：ステップＳＣ６）。例えば、ＤＴＥ１１が、図１９に示すダウンロードデータの先頭から破線１９１までの部分を受信していた場合には、当該既受信部分には、文字列“ＩＪＫＬＭＮ”と画像テキストとに関する情報が含まれていないために、ＤＴＥ１１は、図２０に示す画像を表示部７４に表示させる。
【００６６】
（７―２）コンテンツの続きを取得する場合の動作例
次に、上記に説明した中断が発生した後に、ユーザーによりダウンロードの再開が指示された場合の動作例について説明する。
（７―２―１）テキストデータの続きから取得する場合の動作例
ＤＴＥ１１のＥＥＰＲＯＭ７６２に、図１９に示すダウンロードデータの先頭から破線１９１までの部分が、ＵＲＩやダウンロードが中断された時点のプロファイル情報と対応づけられて既受信部分として記憶されているものとする。また、ＤＴＥ１１の表示部７４には当該既受信部分に対応する画像として、図２０に示される画像が表示されている。
【００６７】
ユーザーがＤＴＥ１１の操作部７３を操作してＷＷＷサーバ１６から当該コンテンツの続きを取得することを指示すると、ＤＴＥ１１は、上述した未受信部分要求処理を用い、まず、ＥＥＰＲＯＭ７６２に記憶されている既受信部分から再開位置情報（図１２：ステップＳＤ１）と再開判定情報とを算出する（図１２：ステップＳＤ２）。なお、ＥＥＰＲＯＭ７６２に記憶されている既受信部分はＩＭＧタグを有していないので、当該既受信部分の大きさ（バイト数）が再開位置情報に設定される。
以下、ＤＴＥ１１は、ＤＴＥ１１とＬＷＰ１５との間でクライアントＴＣＰコネクションを確立し、一方、ＬＷＰ１５は、上述したコンテンツ全体のダウンロードの場合と同一の処理を行う。すなわち、ＬＷＰ１５は、ＷＷＷサーバ１６との間でサーバＴＣＰコネクションの確立から、関連データ結合処理までの処理を行う。
【００６８】
次に、ＬＷＰ１５は、関連データ結合処理で生成したデータの先頭から再開位置情報で指定される長さの部分に対して、再開判定情報を算出し、当該再開判定情報とＤＴＥ１１から送信された再開判定情報とが一致するか否かの判定を行う（図１５：ステップＳＦ１０）。ここで、これら再開判定情報が一致するか否かは、ＷＷＷサーバ１６に記憶されているテキストデータ（aaaa.html）が、ダウンロードが中断された時点から、コンテンツの続きを取得が指示されるまでの間に、更新されたか否かに依存する。以下、更新されていた場合と更新されていなかった場合とに分けて動作例を説明する。
【００６９】
▲１▼ 更新されていなかった場合
ＷＷＷサーバ１６に記憶されているテキストデータ（aaaa.html）が更新されていなかった場合には、ＤＴＥ１１から送信された再開判定情報とＬＷＰ１５で生成した再開判定情報とは一致する。従って、ＬＷＰ１５は図１９に示すダウンロードデータの破線１９１から当該ダウンロードデータの末尾までの部分を未受信部分として、当該未受信部分を含むレスポンスをＤＴＥ１１に返信する（図１５：ステップＳＦ１２）。
ＤＴＥ１１は、当該レスポンスを受信すると、上述したコンテンツ表示処理を行い、ＥＥＰＲＯＭ７６２に記憶されている既受信部分（図１９に示すダウンロードデータの先頭から破線１９１までの部分）と、当該レスポンスに含まれる未受信部分（図１９に示すダウンロードデータの破線１９１から当該データの末尾までの部分）とを結合して（図１２：ステップＳＤ１０）、図１９に示すダウンロードデータを取得し、当該データを解釈して図１７に示す画像を表示部７４に表示する。
【００７０】
▲２▼ 更新されていた場合
ＷＷＷサーバ１６に記憶されているテキストデータ（aaaa.html）が更新されていた場合には、ＤＴＥ１１から送信された再開判定情報とＬＷＰ１５で生成した再開判定情報とは一致しない。従って、ＬＷＰ１５は再開不能であることを示す情報を含むレスポンスを、ＤＴＥ１１に返信する（図１５：ステップＳＦ１３）。 ＤＴＥ１１は、当該レスポンスを受信すると、未受信部分が送信されなかったことを示すテキストデータ（例えば、“コンテンツは更新されています。”）を表示部７４に表示させる。
【００７１】
（７―２―２）画像データの続きから取得する場合の動作例
次に、ＤＴＥ１１のＥＥＰＲＯＭ７６２に、図１９に示すダウンロードデータの先頭から破線１９３までの部分が既受信部分として、プロファイル情報と対応づけられて記憶されているものとする。当該既受信部分には、テキストデータの全部と画像テキストの一部とが含まれているために、ＤＴＥ１１は、図２１に示す画像を表示部７４に表示させている。
なお、以下に説明する動作例では、ＷＷＷサーバ１６に記憶されているコンテンツを構成するテキストデータ（aaaa.html）と画像データ（bbbb.gif）とは、いずれもダウンロードが中断後に、更新されていないものとする。
【００７２】
ユーザーがＤＴＥ１１の操作部７３を操作してＷＷＷサーバ１６からコンテンツの続きを取得することを指示すると、ＤＴＥ１１は、上述したコンテンツ取得処理を行い、まず、ＥＥＰＲＯＭ７６２に記憶されている既受信部分から再開位置情報（図１２：ステップＳＤ１）と再開判定情報（図１２：ステップＳＤ２）とを算出する。この時、ＥＥＰＲＯＭ７６２に記憶されている既受信部分はＩＭＧタグを有するので、ＤＴＥ１１は、ダウンロードが中断された時の表示階調と、現在プロファイル情報に設定されている表示階調とが異なるか否かを判定する（図１３：ステップＳＥ３）。
【００７３】
▲１▼ 表示階調が同一である場合の動作例
ダウンロードが中断された時の表示階調と現在プロファイル情報に設定されている表示階調とが同一である場合には、ＥＥＰＲＯＭ７６２に記憶されている既受信部分の大きさ（バイト数）を再開位置情報として、再開判定情報を算出する（図１３：ステップＳＥ４）。
以下、ＤＴＥ１１は、ＤＴＥ１１とＬＷＰ１５との間でクライアントＴＣＰコネクションを確立し、一方、ＬＷＰ１５は、上述したコンテンツ全体のダウンロードの場合と同一の処理を行う。すなわち、ＬＷＰ１５は、ＷＷＷサーバ１６との間でサーバＴＣＰコネクションの確立から、関連データ結合処理までの処理を行い、ＬＷＰ１５は図１９に示すダウンロードデータの破線１９３から当該データの末尾までの部分を未受信部分として、当該未受信部分を含むレスポンスをＤＴＥ１１に返信する。
ＤＴＥ１１は、当該レスポンスを受信すると、上述したコンテンツ表示処理を行い、ＥＥＰＲＯＭ７６２に記憶されている既受信部分（図１９に示すダウンロードデータの先頭から破線１９３までの部分）と、当該レスポンスに含まれる未受信部分（図１９に示すダウンロードデータの破線１９３から当該データの末尾までの部分）とを結合して、図１９に示すダウンロードデータを取得し、当該ダウンロードデータを解釈して図１７に示す画像を表示部７４に表示する。
【００７４】
▲２▼ 表示階調が異なる場合の動作例
ダウンロードが中断された時の表示階調と、現在プロファイル情報に設定されている表示階調とが異なる場合には、ＥＥＰＲＯＭ７６２に記憶されている既受信部分の先頭から破線１９２で示される部分の大きさを再開位置情報として（図１３：ステップＳＥ５）、当該部分に対して再開判定情報を算出する。
【００７５】
以下、ＤＴＥ１１は、ＤＴＥ１１とＬＷＰ１５との間でクライアントＴＣＰコネクションを確立し、一方、ＬＷＰ１５は、上述したコンテンツ全体のダウンロードの場合と同一の処理を行う。すなわち、ＷＷＷサーバ１６との間でサーバＴＣＰコネクションの確立から、関連データ結合処理までの処理を行い、ＬＷＰ１５は図１９に示すダウンロードデータの破線１９２から当該データの末尾までの部分を未受信部分として、当該未受信部分を含むレスポンスをＤＴＥ１１に返信する。
【００７６】
ＤＴＥ１１は、当該レスポンスを受信すると、上述したコンテンツ表示処理を行い、ＥＥＰＲＯＭ７６２に記憶されている既受信部分（図１９に示すダウンロードデータの先頭から破線１９３までの部分）と、当該レスポンスに含まれる未受信部分（図１９に示すダウンロードデータの破線１９２から当該データの末尾までの部分）とを結合して図１９に示すダウンロードデータを取得する。なお、重複する部分（図１９に示すダウンロードデータの破線１９２から破線１９３までの部分）は、当該レスポンスに含まれる未受信部分で上書きされる。以下ＤＴＥ１１は、当該データを解釈して図１７に示す画像を表示部７４に表示する。
【００７７】
（８）実施形態効果
本実施形態によれば、ＷＷＷサーバ１６からＤＴＥ１１へのコンテンツのダウンロードが中断された場合には、ＤＴＥ１１が既受信部分を記憶するために、中断された時点からダウンロードを再開して、未受信部分のみ取得し、ＤＴＥ１１に記憶されている既受信部分とＬＷＰ１５から取得した未受信部分とを結合してコンテンツを取得することが可能となり、コンテンツ全体を再度取得する場合に比べて、短時間にコンテンツを取得できるといった効果を奏する。
【００７８】
また、本実施形態によれば、ＬＷＰ１５が、ＤＴＥ１１から送信された再開判定情報と、ＬＷＰ１５で算出した再開判定情報とが一致した場合にのみ未受信部分を送信するために、ＬＷＰ１５からＤＴＥ１１への結合不能なデータの送信が抑止され、ユーザーの負担する通信コストが削減されるといった効果を奏する。
【００７９】
また、本実施形態によれば、コンテンツが複数個のデータから構成されている場合であっても、これら複数個のデータをＬＷＰ１５で１つのダウンロードデータに結合してＤＴＥ１１にダウンロードするために、ＬＷＰ１５からＤＴＥ１１へのダウンロードが中断され、その後、ＤＴＥ１１からダウンロードの再開を要求された時に、当該ダウンロードデータが更新されたか否かを再開判定情報を用いて１回だけ比較すれば、中断されたダウンロードの再開が可能であるか否かを判定できるといった効果を奏する。
【００８０】
また、本実施形態によれば、再開判定情報としてＡｄｌｅｒ−３２アルゴリズムにより算出された固定長のハッシュ値を用いるために、ＤＴＥ１１に記憶されている既受信部分全体を用いる場合に比較して、通信データ量を削減できるといった効果を奏する。また、ハッシュ値生成アルゴリズムとしてＡｄｌｅｒ−３２を使用するために、他のハッシュ値生成アルゴリズム（例えば、ＣＲＣ−３２等）に比較して、高速にハッシュ値を算出できるといった効果を奏する。
【００８１】
（９）変形例
［変形例１］
上述した実施形態では、ブラウザ機能付き携帯電話をＤＴＥとして用いる場合の実施例について説明したが、ＤＴＥはブラウザ機能付き携帯電話に限定されるものではなくブラウザ機能付きＰＤＡ（Personal Digital Assistance）やブラウザ機能付きＰＣ（Personal Computer）でも良い、要はブラウザ機能を搭載しインターネットに接続可能な端末装置であれば良い。
【００８２】
［変形例２］
上述した実施形態では、ＬＷＰ１５がコンテンツ代理取得処理で生成したダウンロードデータを記憶装置１４５に記憶せず、ＤＴＥ１１からコンテンツのダウンロードを要求される度にダウンロードデータを生成する場合の実施例について説明したが、ＬＷＰ１５にバス１４７を介してＣＰＵ１４１に現在日時を供給する時計部１４８を更に設け、ＣＰＵ１４１が、ダウンロードデータを生成した場合には、当該ダウンロードデータの作成日時を時計部１４８から取得し、当該作成日時と当該ダウンロードデータとを対応付けて記憶装置１４５に記憶させても良い。
【００８３】
この様な構成および機能を有するＬＷＰ１５は、ＤＴＥ１１からコンテンツのダウンロード要求を受信した場合に、図２２のフローチャートに示されるコンテンツ代理取得処理を行う。なお、図２２に示すフローチャートでは、ＴＣＰコネクションの確立・切断と、レスポンス受信待とは省略されており、当該処理の要部のみが示されている。
ＣＰＵ１４１は、ＤＴＥ１１からＨＴＴＰのＧＥＴメソッドを用いたリクエストを受信すると、ＣＰＵ１４１は、当該ＧＥＴメソッドのリクエストラインを解析し、当該リクエストラインに記述されているＵＲＩや再開位置情報や再開判定情報を取得する（ステップＳＨ１）。
【００８４】
次に、ＣＰＵ１４１は、ＤＴＥ１１からダウンロードを要求されたダウンロードデータを記憶装置１４５に記憶しているか否かの判定を行う（ステップＳＨ２）。
記憶している場合には、ＣＰＵ１４１は、記憶装置１４５に記憶しているダウンロードデータが最新であるか否かの判定を行う（ステップＳＨ１１）。具体的には、当該ダウンロードデータの作成日時と、当該ダウンロードデータを構成するテキストデータおよび画像データの作成日時とを比較し、当該ダウンロードデータの作成日時が最新である場合にのみ当該ダウンロードデータは最新であると判定する（ステップＳＨ１２）。最新でない場合には、ＣＰＵ１４１は、後述するステップＳＨ３以降の処理を行い、最新である場合には、ＣＰＵ１４１は、記憶装置１４５に記憶されているダウンロードデータを用いて後述するステップＳＨ５以降の処理を行う。
記憶していない場合には、ＣＰＵ１４１は、ＷＷＷサーバ１６からテキストデータを取得し（ステップＳＨ３）、ＷＷＷサーバ１６から受信したテキストデータに対して関連データ結合処理を行ってダウンロードデータを生成する（ステップＳＨ４）。
【００８５】
次に、ＣＰＵ１４１は、ＤＴＥ１１からコンテンツ全体の送信を要求されたのか、未受信部分のみの送信を要求されたのかを判定する（ステップＳＨ５）。
コンテンツ全体の送信を要求された場合には、ＣＰＵ１４１は、ダウンロードデータをＤＴＥ１１送信して（ステップＳＨ６）、当該当該処理を終了する。
未受信部分のみの送信を要求された場合には、ＣＰＵ１４１は、ダウンロードデータに対して再開判定情報を算出し（ステップＳＨ７）、ステップＳＨ７で算出した再開判定情報と、ステップＳＨ１で取得した再開判定情報とが一致するか否かの判定を行う（ステップＳＨ８）。
【００８６】
一致する場合には、ＣＰＵ１４１は、ダウンロードデータから未受信部分を生成し、当該未受信部分をＤＴＥ１１へ送信して（ステップＳＨ９）、当該処理を終了する。
一致しない場合には、ＣＰＵ１４１は、再開不能であることを示す情報をＤＴＥ１１へ送信（ステップＳＨ１０）して、当該処理を終了する。
【００８７】
［変形例３］
上述した実施形態では、ＬＷＰ１５が、ＤＴＥ１１からダウンロードを要求されたデータと当該データに関連付けられたデータとから１つのダウンロードデータを生成して、当該ダウンロードデータをＤＴＥ１１へダウンロードする場合の実施例について説明したが、テキストデータのダウンロードと、当該テキストデータに関連付けられたデータ（他のテキストデータ、画像、音声、プログラム等）のダウンロードとを個別に行っても良い。
具体的には、ＤＴＥ１１は、まず、ＬＷＰ１５を介してＷＷＷサーバ１６からテキストデータをダウンロードし、当該テキストデータを解釈して、当該テキストデータに関連付けられているデータを一つづつＬＷＰ１５を介してＷＷＷサーバ１６からダウンロードして、ユーザーの所望するコンテンツを取得する。
このような場合には、例えば、テキストデータのダウンロードに対して、当該テキストデータに関連付けられた他のデータの更新の有無は、影響を与えない。従って、テキストデータのダウンロードが中断された場合に、当該ダウンロードが再開可能であるか否かを判定するには、ダウンロード対象のテキストデータが更新されたか否かを判定すれば良い。一方、テキストデータに関連付けられたデータのダウンロードが中断された場合に、当該ダウンロードが再開可能であるか否かを判定するには、ダウンロード対象のデータが更新されたか否かを判定すれば良い。
【００８８】
［変形例４］
また、上述した実施形態では、ハッシュ値算出アルゴリズムとしてＡｄｌｅｒ−３２アルゴリズムを用いる場合の実施例について説明したが、他のハッシュ値算出アルゴリズム（例えばＣＲＣ−３２等）を用いても良い。
【００８９】
［変形例５］
また、上述した実施形態では、ハッシュ値を用いて、中断されたデータ送信が再開可能であるか否かを判定する実施例について説明したが、ハッシュ値ではなく、ＤＴＥ１１のＥＥＰＲＯＭ７６２に記憶されているデータそのものを用いて再開可能か否かを判定しても良い。具体的には、ＤＴＥ１１からＬＷＰ１５へ未受信部分のみの送信を要求する場合に、ＤＴＥ１１が、リクエストラインにＤＴＥ１１が記憶している既受信部分を設定してＬＷＰ１５にリクエストを送信し、ＬＷＰ１５は、関連データ結合処理で生成したダウンロードデータの先頭からＤＴＥ１１から送信された当該既受信部分の長さで特定される部分と、ＤＴＥ１１から送信された既受信部分とを比較し、両者が一致する場合にのみ中断されたダウンロードの再開を行っても良い。
【００９０】
［変形例６］
また、上述した実施形態では、ＤＴＥ１１のＥＥＰＲＯＭ７６２に記憶されている既受信部分全体を用いて、中断されたデータ送信が再開可能であるか否かを判定する実施例について説明したが、当該既受信部分の特定の一部分を用いて、中断されたデータ送信が再開可能であるか否かを判定しても良い。例えば、ＤＴＥ１１のＥＥＰＲＯＭ７６２に記憶されている既受信部分の奇数バイト目と、ＬＷＰ１５で生成されたダウンロードデータの先頭からＤＴＥ１１から送信された当該既受信部分の長さで特定される部分の奇数バイト目とが全て一致した場合にのみ中断されたデータ送信の再開を行うとしても良い。
【００９１】
［変形例７］
また、上述した実施形態では、ＤＴＥ１１のＥＥＰＲＯＭ７６２に記憶されている既受信部分を用いて、中断されたデータ送信が再開可能であるか否かを判定する実施例について説明したが、ＤＴＥ１１に、バス７７を介してＣＰＵ７１に現在日時を供給する時計部７８を更に設け、ＬＷＰ１５からのデータのダウンロードが中断されると、ＣＰＵ７１は、それまでに受信したデータと時計部７８から取得した日時とを対応付けてＥＥＰＲＯＭ７６２に記憶させ、ダウンロードの再開を要求する際に、当該日時をＬＷＰ１５に送信し、ＬＷＰ１５で当該日時とＷＷＷサーバ１６に記憶されているデータの作成日時とをＬＷＰ１５で比較し、前者が後者より新しい場合にのみ中断されたダウンロードの再開を行うとしても良い。
【００９２】
［変形例８］
また、上述した実施形態では、ダウンロード中断前後でＷＷＷサーバ１６の有するデータが更新されたために、結合不能と判定された場合にはエラーメッセージを送信し、再度データ全体のダウンロードを促す実施形態について説明したが、更新後のデータから生成されたダウンロードデータ全体をダウンロードしても良い。
【００９３】
［変形例９］
また、上述した実施形態では、一台のＬＷＰ１５で中継を行う実施形態について説明したが、信頼性向上および負荷分散の観点から、例えば複数台のＬＷＰからなるクラスター構成あるいはホットスタンバイ構成等の多重化構成にしても良い。
【００９４】
［変形例１０］
また、上述した実施形態では、ＬＷＰ１５が予め本発明に係るプログラムを記憶している場合の実施形態について説明したが、当該プログラムを記憶していない一般的な代理サーバ機能を有するコンピュータ装置に、コンピュータ装置が読み取り可能な記録媒体に記録されている当該プログラムを読み込ませて、当該プログラムを当該代理サーバ装置に記憶させ、上述した実施形態におけるＬＷＰ１５と略同一の機能を追加しても良い。
また、上述した実施形態では、ＤＴＥ１１が予め本発明に係るプログラムを記憶している場合の実施形態について説明したが、ダウンロードしたプログラムを記憶および実行する機能を有する一般的なブラウザ機能付携帯電話に、本件発明に係るプログラムを記憶させてＤＴＥ１１と略同一の機能を付与しても良い。具体的には、本発明に係るプログラムを記録したコンピュータ装置が読み取り可能な記録媒体から当該プログラムを代理サーバ装置に読み込ませて当該代理サーバ装置の記憶装置に当該プログラムを記憶させ、前記携帯電話に前記代理サーバ装置から当該プログラムをダウンロードして記憶させることにより、ＤＴＥ１１と略同一の機能を追加しても良い。
【００９５】
［変形例１１］
また、上述した実施形態では、移動パケット通信網１２とインターネット１４とをゲートウェイサーバ１３を介して接続し、インターネット１４に接続されたＬＷＰ１５において本件発明に係る中継方法を実行する場合の実施例について説明したが、ゲートウェイサーバ１３にＬＷＰ１５の機能を実現するプログラムを記憶させ、ゲートウェイサーバ１３で本件発明に係る中継方法を実行させても良い。
【００９６】
［変形例１２］
また、上述した実施形態では、ＤＴＥ１１とＬＷＰ１５とが、移動パケット通信網１２とゲートウェイサーバ１３とインターネット１４とを介して通信を行う通信態様の場合の実施例について説明したが、ＤＴＥ１１とＬＷＰ１５との間の通信態様は、このような通信態様に限定されるものではなく、移動パケット通信網１２に替えて非パケット通信網を用いた通信態様でも良く、また、インターネット１４に替えて構内ＬＡＮ（いわゆるイントラネット）を用いた通信態様でも良く、また、インターネット１４のみを用いた通信態様でも良く、構内ＬＡＮのみを用いた通信態様であっても良い。
また、上述した実施形態では、ＬＷＰ１５とＷＷＷサーバ１６とが、インターネット１４を介して通信を行う通信態様の場合の実施例について説明したが、ＬＷＰ１５とＷＷＷサーバ１６との間の通信態様は、インターネット１４を用いた通信態様に限定されるものではなく、構内ＬＡＮを用いた通信態様であっても良い。
【００９７】
［変形例１３］
また、上述した実施形態では、ＤＴＥ１１がＬＷＰ１５を介してＷＷＷサーバ１６から取得するデータが、ＨＴＭＬで記述されたテキストデータとＨＴＭＬに従って当該テキストデータに関連付けられた他のデータ（画像データや音声データ等）とを有するコンテンツである場合の実施例について説明したが、コンテンツを構成するテキストデータは、ＨＴＭＬで記述されたテキストデータに限られるものではなく、ＨＴＭＬを機能拡張した記述言語であるＸＨＴＭＬ（eXtensible Hyper Text Markup Language）で記述されたテキストデータであっても良い。要は、文書の中に画像や音声、動画、他の文書の所在場所等を埋め込むことができる記述言語で記述されたテキストデータであれば良い。
【００９８】
［変形例１４］
また、上述した実施形態では、ＤＴＥ１１が再開位置情報を算出する際に、既受信部分が画像テキストを有する場合には、既受信部分を記憶した時点の表示階調と未受信部分の取得が要求された時点の表示階調とが一致するか否かの判定を行い（図１３：ステップＳＥ３参照）、一致する場合と一致しない場合とで異なる値を再開位置情報に設定する場合の実施例について説明したが、このような判定を行わずに、再開位置情報の設定を行っても良い。具体的には、ＤＴＥ１１は、既受信部分を記憶した時点の表示階調と未受信部分の取得が要求された時点の表示階調とが一致するか否かにかかわらず、既受信部分の大きさを再開位置情報に設定しても良い。
【００９９】
［変形例１５］
また、上述した実施形態では、ＤＴＥ１１が再開位置情報を算出する際に、既受信部分が画像テキストを有するか否かの判定を行い（図１３：ステップＳＥ１参照）、有する場合と有しない場合とで異なる処理を行って再開位置情報を算出する場合の実施例について説明したが、このような判定を行わずに、再開位置情報の設定を行っても良い。具体的には、ＤＴＥ１１は、既受信部分が画像テキストを有するか否かにかかわらず、既受信部分の大きさを再開位置情報に設定しても良い。
【０１００】
【発明の効果】
本発明によれば、ＷＷＷサーバ１６からＤＴＥ１１へのコンテンツのダウンロードが中断された場合には、ＤＴＥ１１が既受信部分を記憶するために、中断された時点からダウンロードを再開して、未受信部分のみ取得し、ＤＴＥ１１に記憶されている既受信部分とＬＷＰ１５から取得した未受信部分とを結合してコンテンツを取得することが可能となり、コンテンツ全体を再度取得する場合に比べて、短時間にコンテンツを取得できるといった効果を奏する。
【０１０１】
また、本発明によれば、ＬＷＰ１５は、ＤＴＥ１１から送信された既受信部分情報と、ＷＷＷサーバ１６から取得した更新情報とが一致した場合にのみ未受信部分をＤＴＥ１１へ送信するために、ＬＷＰ１５からＤＴＥ１１への結合不能なデータの送信が抑止され、ユーザーの負担する通信コストが削減されるといった効果を奏する。
【図面の簡単な説明】
【図１】 図１は、本発明に係るデータ取得方法を実行する通信システムの全体構成の一例を示す図である。
【図２】 図２は、同システムの動作の概要を示すシーケンス図である。
【図３】 図３は、同システムを構成するＷＷＷサーバ１６に記憶されているテキストデータの要部を示す図である。
【図４】 図４は、同システムを構成するＷＷＷサーバ１６に記憶されている画像データの画像イメージを示す図である。
【図５】 図５は、同システムを構成するＬＷＰ１５からＤＴＥ１１へ送信されるダウンロードデータの一例を示す図ある。
【図６】 図６は、同システムを構成するＬＷＰ１５からＤＴＥ１１へ送信されるダウンロードデータの一例を示す図ある。
【図７】 図７は、同システムを構成するＤＴＥ１１の構成例を示すブロック図である。
【図８】 図８は、同ＤＴＥ１１が実行するプロファイル情報設定処理の流れを示すフローチャートである。
【図９】 図９は、同プロファイル情報設定処理にてＤＴＥ１１の表示部７４に表示されるプロファイル情報設定画面の一例である。
【図１０】 図１０は、同ＤＴＥ１１が実行するコンテンツ取得処理の流れを示すフローチャートである。
【図１１】 図１１は、同ＤＴＥ１１が実行する全体要求処理の流れを示すフローチャートである。
【図１２】 図１２は、同ＤＴＥ１１が実行する未受信部分要求処理の流れを示すフローチャートである。
【図１３】 図１３は、同ＤＴＥ１１が実行する再開位置算出処理の流れを示すフローチャートである。
【図１４】 図１４は、同システムを構成するＬＷＰ１５の構成例を示すブロック図である。
【図１５】 図１５は、同ＬＷＰ１５が実行するコンテンツ代理取得処理の流れを示すフローチャートである。
【図１６】 図１６は、同ＬＷＰ１５が実行する関連データ結合処理の流れを示すフローチャートである。
【図１７】 図１７は、同システムを構成するＷＷＷサーバ１６に記憶されているコンテンツをＤＴＥ１１が解釈表示した場合に、表示部７４に表示される画像の一例を示す図である。
【図１８】 図１８は、同システムの動作の一例を示すシーケンス図である。
【図１９】 図１９は、同システムを構成するＤＴＥ１１のＥＥＰＲＯＭ７６２に記憶されている既受信部分を示す図である。
【図２０】 図２０は、同システムを構成するＤＴＥ１１の表示部７４に表示される画像の一例を示す図である。
【図２１】 図２１は、同システムを構成するＤＴＥ１１の表示部７４に表示される画像の一例を示す図である。
【図２２】 図２２は、［変形例２］に係るＬＷＰ１５が実行するコンテンツ代理取得処理の流れを示すフローチャートである。
【符号の説明】
１１ ＤＴＥ
１２ 移動パケット通信網
１３ ゲートウェイサーバ
１４ インターネット
１５ ＬＷＰ
１６ ＷＷＷサーバ
【発明の属する技術分野】
本発明は、クライアント装置が中継装置を介してサーバ装置からデータを取得するデータ取得方法と、これら各方法を実行する中継装置と、これら各方法をコンピュータ装置に実行させるためのプログラムと当該プログラムを記録したコンピュータ装置が読み取り可能な記録媒体とに関する。
【０００２】
【従来の技術】
近年、インターネットの急速な普及に伴い、インターネット上で各種サービスの提供を行うインフォメーションプロバイダー（以下、「ＩＰ」とする）が多数出現してきている。ユーザーは、これらＩＰの提供するサービスの利用を所望する場合には、これらＩＰがインターネット上で提供するコンテンツをダウンロードし、当該コンテンツを実行する必要がある。
【０００３】
より詳しく説明すると、ＩＰが提供するコンテンツは、文書の中に画像や音声、動画、他の文書の所在場所等を埋め込むことができる記述言語であるＨＴＭＬ（Hyper Text Markup Language）で記述されたテキストデータと、ＨＴＭＬに従って当該テキストデータに関連付けられた画像データや音声データ等で構成されている。また、これらコンテンツは、インターネットに接続されたＷＷＷ（World Wide Web）サーバに格納されている。
ユーザーは、コンテンツの取得および解釈実行機能を有するソフトウェア（以下、「ブラウザ」とする）をクライアント装置で実行してインターネットに接続されたＷＷＷサーバからコンテンツをダウンロードすることができる。なお、ユーザーのクライアント装置は、インターネットに直接的に接続されるのではなく、インターネットプロトコルの確立を行うゲートウェイサーバ（アクセスサーバ）を介してインターネットに接続される。この種のゲートウェイサーバはクライアント装置と通信するための第一の通信回線（例えば構内ネットワークや公衆網など）と第二の通信回線（インターネット）とに接続されており、クライアント装置とサーバ装置との通信を中継する。また、代理サーバ機能を備えたゲートウェイサーバも広く普及している。また、ユーザーが用いるクライアント装置としては、ブラウザ機能付き携帯電話やＰＤＡ（Personal Digital Assistance）やＰＣ（Personal Computer）などが広く普及している。
【０００４】
【発明が解決しようとする課題】
上述したように、ユーザーは、クライアント装置でブラウザを実行することによりＷＷＷサーバからコンテンツをダウンロードすることができるが、例えば、通信障害等によりＷＷＷサーバからのコンテンツのダウンロードが中断された場合には、所望するコンテンツを取得できない。
このような場合に、ユーザーが、当該コンテンツの利用を望むならば、再度、当該コンテンツのダウンロードを最初からやり直さなければならないといった問題点があった。
【０００５】
上記の問題点を解決する方法として従来のデータ通信技術では、サーバ装置にクライアント装置のデータの受信状況を監視させるとともに、クライアント装置へのデータ送信が中断された場合には、クライアント装置にそれまで受信した部分を記憶させる方法が提案されている。
このような方法を用いると、ユーザーにより同一データのダウンロードが指示された場合には、中断されたデータ送信を中断された時点から再開し、クライアント装置が未受信の部分のみを送信し、クライアント装置で中断されるまでに受信した部分と再開後に受信した部分とを結合してユーザーの所望するデータを取得することが可能となる。
また、サーバ装置の処理負荷を軽減するために、サーバ装置とクライアント装置との通信を中継する中継装置を設け、当該中継装置に上述のクライアント装置へのデータのダウンロード状況を監視させる方法も提案されている。
【０００６】
しかし、上述の方法を用いた場合であっても、ダウンロードが中断された時から中断されたダウンロードの再開が要求されるまでの間に、サーバ装置に記憶されているダウンロード対象のデータが更新されてしまった場合には、サーバ装置は、クライアント装置に記憶されているデータとは異なる更新済みのデータからクライアント装置が未受信の部分を切り出してクライアント装置に送信してしまうため、中断されたデータ送信を正しく再開できないといった問題点がある。
また、一般的にデータ通信に係る費用は、通信データ量に応じてユーザーに課金されるものであり、上述したようにダウンロード対象のデータが更新されていた場合には、中断されたデータ送信を正しく再開できないにもかかわらず、ユーザーは、通信コスト（通信時間、料金）の負担を強いられるといった問題点もある。
【０００７】
本発明は、上述した問題点を鑑みてなされたものであり、サーバ装置からのデータ送信が中断された場合には、中断されたデータ送信を中断された時点から再開することを可能にするとともに、データ送信が中断された時から、再開されるまでの間に、データが更新された場合であっても、ユーザーに無駄な通信コストの負担を強いることのないデータ取得方法を提供することを目的とする。
【０００８】
【課題を解決するための手段】
請求項１に係る発明は、中継装置が、クライアント装置から要求された第一のデータと該第一のデータに関連付けられた第二のデータとをサーバ装置から取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータを該クライアント装置に送信する送信過程と、前記クライアント装置が、前記中継装置からのデータ送信が中断された時点までに受信した前記第三のデータの既受信部分を記憶する記憶過程と、前記クライアント装置が前記既受信部分に基づいて前記第三のデータにおける前記データ送信が中断された位置を示す再開位置情報を算出し、該再開位置情報と前記既受信部分とに基づいて第一の再開判定情報を算出し、該再開位置情報と該第一の再開判定情報とを前記中継装置に送信して前記データ送信の再開を要求する要求過程と、前記中継装置が前記サーバ装置に格納されている前記第一及び第二のデータを取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータと前記再開位置情報とから第二の再開判定情報を算出し、該第二の再開判定情報と前記第一の再開判定情報とを比較し、両者が一致する場合にのみ、前記データ送信を再開可能と判定する判定過程と、前記中継装置が、前記判定過程にて前記データ送信を再開可能と判定された場合にのみ前記第三のデータのうち前記クライアント装置が受信していない未受信部分のみを前記クライアント装置に送信する未受信部分送信過程と、前記クライアント装置が、前記既受信部分と前記未受信部分とを結合して表示する表示過程とを有することを特徴とするデータ取得方法を提供する。
【０００９】
請求項３に係る発明は、中継装置が、クライアント装置から要求された第一のデータと該第一のデータに関連付けられた第二のデータとをサーバ装置から取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータを該クライアント装置に送信する送信過程と、前記クライアント装置が、前記中継装置からのデータ送信が中断された時点までに受信した前記第三のデータの既受信部分を記憶する記憶過程と、前記クライアント装置が前記既受信部分を第一の再開判定情報として前記中継装置に送信して前記データ送信の再開を要求する要求過程と、前記中継装置が前記サーバ装置に格納されている前記第一及び第二のデータを取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータの先頭から前記既受信部分の長さで特定される部分を第二の再開判定情報として取得し、該第二の再開判定情報と前記第一の再開判定情報とを比較し、両者が一致する場合にのみ、前記データ送信を再開可能と判定する判定過程と、前記中継装置が、前記判定過程にて前記データ送信を再開可能と判定された場合にのみ前記第三のデータのうち前記クライアント装置が受信していない未受信部分のみを前記クライアント装置に送信する未受信部分送信過程と、前記クライアント装置が、前記既受信部分と前記未受信部分とを結合して表示する表示過程とを有することを特徴とするデータ取得方法を提供する。
【００１０】
請求項４に係る発明は、クライアント装置から要求された第一のデータと該第一のデータに関連付けられた第二のデータとをサーバ装置から取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータを該クライアント装置に送信する送信手段と、前記送信手段からのデータ送信が中断された時点までに受信した前記第三のデータの既受信部分を記憶している前記クライアント装置が前記既受信部分に基づいて前記第三のデータにおける前記データ送信が中断された位置を示す再開位置情報を算出し、該再開位置情報と前記既受信部分とに基づいて第一の再開判定情報を算出し、該再開位置情報と該第一の再開判定情報とを送信して前記データ送信の再開を要求した場合に、前記サーバ装置に格納されている前記第一及び第二のデータを取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータと前記再開位置情報とから第二の再開判定情報を算出し、該第二の再開判定情報と前記第一の再開判定情報とを比較し、両者が一致する場合にのみ、前記データ送信を再開可能と判定する判定手段と、前記判定手段にて前記データ送信を再開可能と判定された場合にのみ前記第三のデータのうち前記クライアント装置が受信していない未受信部分のみを前記クライアント装置に送信する未受信部分送信手段とを有することを特徴とする中継装置を提供する。
【００１１】
請求項５に係る発明は、クライアント装置から要求された第一のデータと該第一のデータに関連付けられた第二のデータとをサーバ装置から取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータを該クライアント装置に送信する送信手段と、前記送信手段からのデータ送信が中断された時点までに受信した前記第三のデータの既受信部分を記憶している前記クライアント装置が前記既受信部分を第一の再開判定情報として送信して前記データ送信の再開を要求した場合に、前記サーバ装置に格納されている前記第一及び第二のデータを取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータの先頭から前記既受信部分の長さで特定される部分を第二の再開判定情報として取得し、該第二の再開判定情報と前記第一の再開判定情報とを比較し、両者が一致する場合にのみ、前記データ送信を再開可能と判定する判定手段と、前記判定手段にて前記データ送信を再開可能と判定された場合にのみ前記第三のデータのうち前記クライアント装置が受信していない未受信部分のみを前記クライアント装置に送信する未受信部分送信手段とを有することを特徴とする中継装置を提供する。
【００１２】
請求項６に係る発明は、コンピュータ装置を、クライアント装置から要求された第一のデータと該第一のデータに関連付けられた第二のデータとをサーバ装置から取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータを該クライアント装置に送信する送信手段と、前記送信手段からのデータ送信が中断された時点までに受信した前記第三のデータの既受信部分を記憶している前記クライアント装置が前記既受信部分に基づいて前記第三のデータにおける前記データ送信が中断された位置を示す再開位置情報を算出し、該再開位置情報と前記既受信部分とに基づいて第一の再開判定情報を算出し、該再開位置情報と該第一の再開判定情報とを送信して前記データ送信の再開を要求した場合に、前記サーバ装置に格納されている前記第一及び第二のデータを取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータと前記再開位置情報とから第二の再開判定情報を算出し、該第二の再開判定情報と前記第一の再開判定情報とを比較し、両者が一致する場合にのみ、前記データ送信を再開可能と判定する判定手段と、前記判定手段にて前記データ送信を再開可能と判定された場合にのみ前記第三のデータのうち前記クライアント装置が受信していない未受信部分のみを前記クライアント装置に送信する未受信部分送信手段として機能させるためのプログラムを提供する。
【００１３】
請求項７に係る発明は、コンピュータ装置を、クライアント装置から要求された第一のデータと該第一のデータに関連付けられた第二のデータとをサーバ装置から取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータを該クライアント装置に送信する送信手段と、前記送信手段からのデータ送信が中断された時点までに受信した前記第三のデータの既受信部分を記憶している前記クライアント装置が前記既受信部分を第一の再開判定情報として送信して前記データ送信の再開を要求した場合に、前記サーバ装置に格納されている前記第一及び第二のデータを取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータの先頭から前記既受信部分の長さで特定される部分を第二の再開判定情報として取得し、該第二の再開判定情報と前記第一の再開判定情報とを比較し、両者が一致する場合にのみ、前記データ送信を再開可能と判定する判定手段と、前記判定手段にて前記データ送信を再開可能と判定された場合にのみ前記第三のデータのうち前記クライアント装置が受信していない未受信部分のみを前記クライアント装置に送信する未受信部分送信手段として機能させるためのプログラムを提供する。
【００１４】
このようなデータ取得方法、中継装置、プログラムおよび記録媒体を用いると、中継装置は、クライアント装置から再開を要求されたデータ送信が再開可能である場合にのみデータ送信を再開する。
【００１５】
【発明の実施の形態】
以下、図面を参照して本発明に係る実施形態について説明する。ただし、本発明の技術的範囲は係る実施形態に限定されるものではなく、係る実施形態に周知技術を適用して得られる、特許請求の範囲に記載された範囲内の任意の態様を含む。
【００１６】
（１）全体構成
図１は、本発明に係るデータ取得方法を実施する通信システムの概要を示す図である。この図に示す通信システムでは、データ端末装置（以下、「ＤＴＥ」とする）１１は、ＨＴＴＰ（Hyper Text Transfer Protocol）のＧＥＴメソッドまたはＰＯＳＴメソッドを用いて軽量代理サーバ（以下、「ＬＷＰ」とする）１５を介してインターネット１４に接続されたＷＷＷサーバ１６からコンテンツをダウンロードしている。
ここで、ＤＴＥ１１とＬＷＰ１５との間で、ＧＥＴメソッドを用いたコンテンツのダウンロードが中断されると、ＤＴＥ１１は当該ダウンロードが中断された時点までに受信した部分（以下、「既受信部分」とする）を記憶し、その後、ユーザーにより中断されたダウンロードの再開が指示されると、ＬＷＰ１５に中断されたダウンロードの再開を要求する。すなわち、ＤＴＥ１１は、中断により受信しなかった部分（以下、「未受信部分」とする）のみの送信をＬＷＰ１５に要求する。
一方、ＤＴＥ１１からダウンロードの再開を要求されたＬＷＰ１５は、既受信部分とＷＷＷサーバ１６に記憶されているコンテンツの既受信部分に対応する部分とが一致するか否かを判定し、一致した場合にのみ未受信部分をＤＴＥ１１へ送信する。この未受信部分をＤＴＥ１１が受信すると、ＤＴＥ１１は自装置に記憶している既受信部分とＬＷＰ１５から送信された未受信部分とを結合してコンテンツを取得する。
以上に説明したように、図１に示す通信システムは、中断されたコンテンツのダウンロードの再開を可能とすると同時に、既受信部分とコンテンツの既受信部分に対応する部分とが一致しない場合には、未受信部分の送信を行わずに、ＬＷＰ１５からＤＴＥ１１への無用なデータのダウンロードを抑止している。
【００１７】
なお、図１に示す通信システムは、ＰＯＳＴメソッドによるコンテンツのダウンロードが中断された場合には、当該中断されたダウンロードの再開を行わない。これは、ＰＯＳＴメソッドを用いてダウンロードされるコンテンツは、ダウンロードが要求される度毎にＷＷＷサーバでＣＧＩ（Common Gateway Interface）等を用いて動的に生成されるものであり、ＤＴＥ１１が、最初のダウンロードを要求した時点と再開を要求した時点とで、必ずしも同一のコンテンツが生成されないからである。
また、この図においては、図面および説明が煩雑になることを防ぐために、１つのＷＷＷサーバと１つのＤＴＥとが例示されているが、実際には多数のＷＷＷサーバとＤＴＥとが存在する。またＤＴＥは携帯電話機能を有し、移動通信網経由で音声通話を行うことが可能であるが、音声通話に係る部分は本発明とは直接関係がないため、本実施形態においては、音声通話に係る説明および図示を省略する。
【００１８】
（２）ＤＴＥ１１−ＬＷＰ１５間およびＬＷＰ１５−ＷＷＷサーバ１６間の通信シーケンス
図２は、図１に示す通信システムで、ＤＴＥ１１がＬＷＰ１５を介してＷＷＷサーバ１６からテキストデータと画像データとから構成されているコンテンツをダウンロードする場合に、ＤＴＥ１１とＬＷＰ１５とＷＷＷサーバ１６のとの間で送受信される通信シーケンスを示す図である。
【００１９】
まず、ＤＴＥ１１は、テキストデータのダウンロードを要求するリクエスト２１をＬＷＰ１５に送信する。このリクエスト２１は移動パケット通信網１２、ゲートウェイサーバ１３、インターネット１４を順に介してＬＷＰ１５へ到達する。
ＤＴＥ１１から送信されたリクエスト２１を受信したＬＷＰ１５は、当該テキストデータのダウンロードを要求するリクエスト２２をインターネット１４を介してＷＷＷサーバ１６に送信する。
ＬＷＰ１５から送信されたリクエスト２２を受信したＷＷＷサーバ１６は、リクエスト２２に指定されているテキストデータを読み出し、当該テキストデータを含んだレスポンス２３をインターネット１４を介してＬＷＰ１５に返信する。このレスポンス２３をＬＷＰ１５が受信すると、詳細は後述するコンテンツ代理取得処理で説明するが、ＬＷＰ１５は当該テキストデータに関連付けられている画像データのダウンロードを要求するリクエスト２４をＷＷＷサーバ１６へ送信する。
ＬＷＰ１５から送信されたリクエスト２４を受信したＷＷＷサーバ１６は、リクエスト２４に指定されている画像データを読み出し、当該画像データを含んだレスポンス２５をインターネット１４を介してＬＷＰ１５に返信する。
このレスポンス２５をＬＷＰ１５が受信すると、詳細は後述する関連データ結合処理で説明するが、ＬＷＰ１５は先に取得したテキストデータと画像データとから後述するダウンロードデータを生成する。
次に、ＬＷＰ１５は当該ダウンロードデータを含むレスポンス２６をＤＴＥ１１から送信されたリクエスト２１に対応したレスポンスとしてＤＴＥ１１へ送信する。ＬＷＰ１５から送信されたレスポンス２６はインターネット１４、ゲートウェイサーバ１３、移動パケット通信網１２を順に介してＤＴＥ１１により受信される。
なお、図２では、図面が煩雑になることを防ぐために、各通信メッセージ（各リクエストおよび各レスポンス）は、１つの通信メッセージであるかのように示されているが、実際には、通信対象のデータを所定の大きさ（バイト数）に分割した複数のパケットの送受信が行われている。以下の説明では、本発明の説明に直接関連する場合を除き、各通信メッセージを１つのパケットの送受信であるとして説明する。
【００２０】
（３）ＬＷＰ１５で生成されるダウンロードデータの概略
上述したように、ＬＷＰ１５は、ＤＴＥ１１からダウンロードを要求されたコンテンツが、テキストデータと当該テキストデータに対応付けられた画像データとから構成されている場合には、これらテキストデータと画像データとから１つのダウンロードデータを生成し、当該ダウンロードデータをＤＴＥ１１へ送信している。以下では、ＤＴＥ１１から要求されたコンテンツがテキストデータ（aaaa.html）と画像データ（bbbb.gif）とから構成されている場合に、ＬＷＰ１５が生成するダウンロードデータについて説明する。
図３は、テキストデータ（aaaa.html）の要部を示す図である。当該テキストデータはＨＴＭＬで記述されており、図３に示すように、ＩＭＧタグを有している。ここで、ＩＭＧタグとは、当該テキストデータに関連付けられた画像データに関する情報を記述するタグである。具体的には、ＩＭＧタグのＳＲＣ属性には当該テキストデータに関連付けられている画像データのＵＲＩ（Uniform Resource Identifier）が記述されており、ＷＩＤＴＨ属性およびＨＩＧＨＴ属性には表示する画像の大きさが記述されている。当該ＩＭＧタグには、図４に示される画像イメージを記憶した画像データ（bbbb.gif）のＵＲＩが、ＳＲＣ属性に記述されている。
図５は、上述のテキストデータ（aaaa.html）と画像データ（bbbb.gif）とから生成されるダウンロードデータの概要を示す図である。この図に示されるようにダウンロードデータは、テキスト領域５１と画像領域５２との二つの領域を有している。テキスト領域５１には、テキストデータ（aaaa.html）のＩＭＧタグのＳＲＣ属性に指定されているＵＲＩを所定の文字列（例えば、ＩＭＧＤＡＴＡ０１）で置き換えたものが格納されている。一方、画像領域５２には、テキストデータのＩＭＧタグのＳＲＣ属性に指定されていた画像データ（bbbb.gif）を所定のアルゴリズム（例えば、Ｂａｓｅ６４）でエンコードしてテキスト化したデータ（以下、「画像テキスト」とする）が格納されている。ここで、当該画像テキストには、当該画像テキストの開始位置を示すタグである＜ＩＭＧＤＡＴＡ０１＞と、当該画像テキストの終了位置を示すタグ＜／ＩＭＧＤＡＴＡ０１＞とが付与されている。
なお、コンテンツがテキストデータのみから構成されている場合には、ＬＷＰ１５は、画像領域５２を有しないダウンロードデータを生成する。また、テキストデータに複数個の画像データが関連付けれれている場合には、ＬＷＰ１５は、図６に示すように、テキストデータに関連付けられている画像データの個数分だけ、画像領域５２に複数個の画像テキストを有するダウンロードデータを生成する。
【００２１】
（４）ＷＷＷサーバ１６の構成および機能
ＷＷＷサーバ１６は、インターネット１４を用いて実現されているＷＷＷを構成する一般的なコンピュータ装置であり、インターネット１４を介してＨＴＴＰに従ったリクエストを受信すると、これに対応したレスポンスをインターネット１４へ送出するＨＴＴＰサーバ機能を備えている。例えば、ＷＷＷサーバは、ＨＴＭＬで記述されたテキストデータと画像データ等のデータファイルとを記憶しており、受信したリクエストがＧＥＴメソッドで指定されたＵＲＩに対応するファイルを読み出し、当該ファイルを含んだレスポンスを返信する。
【００２２】
（５）ＤＴＥ１１の構成および機能
（５−１）ＤＴＥ１１の構成
図７は、ＤＴＥ１１のハードウェア構成を示すブロック図であり、この図に示されるようにＤＴＥ１１は、ＣＰＵ７１と、無線通信部７２と、操作部７３と、表示部７４と、揮発性メモリ７５と、不揮発性メモリ７６と、各要素間のデータ授受を仲介するバス７７とを有している。
【００２３】
無線通信部７２は、例えばアンテナ等を含む無線通信インターフェースであり、ＣＰＵ７１から供給された情報を移動パケット通信網１２へ送出するとともに、移動パケット通信網１２を介して受信した情報をＣＰＵ７１へ渡す。操作部７３は、例えばユーザーに操作される操作子（テンキーやカーソル等）を備え、操作子の操作内容を示す情報をＣＰＵ７１へ渡す。表示部７４は、例えば液晶ディスプレイであり、ＣＰＵ７１から供給される画像情報に応じた画像を表示する。
【００２４】
揮発性メモリ７５は、ＲＡＭ（Random Access Memory）であり、不揮発性メモリ７６は、例えばデータを書き換え不能に記憶するＲＯＭ（Read Only Memory）７６１と、データを書き換え可能に記憶するＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）７６２とを有する。ＲＯＭ７６１は、オペレーティングシステム（以下「ＯＳ」という）やブラウザ等のソフトウェアを記憶している。
【００２５】
（５−２）ＤＴＥ１１の機能
次に、ＣＰＵ７１がＲＯＭ７６１に記憶されているソフトウェアを実行することによりＣＰＵ７１に付与される機能について説明する。ただし、ブラウザを搭載している一般的な携帯電話の有する機能と略同一の機能については説明を省略し、ここでは、本実施形態の動作に直接的に関係する機能についてのみ説明する。
【００２６】
ＣＰＵ７１は、ＤＴＥ１１の電源（図示略）が投入されると、ＲＯＭ７６１からＯＳを読み出して実行する。ＯＳを実行した状態のＣＰＵ７１は、揮発性メモリ７５をワークエリアとして使用すること、ＤＴＥ１１の各部を制御すること、およびユーザーによる操作部７３の操作内容に応じて、ブラウザ等のソフトウェアをＲＯＭ７６１から読み出して実行することができる。
なお、ＤＴＥ１１に搭載されているブラウザには、ＵＲＩを指定してコンテンツ全体のダウンロードを要求するためのユーザーインターフェースが設けられている他に、ＵＲＩを指定して未受信部分のみのダウンロードを要求するためのユーザーインターフェースも設けられている。
【００２７】
（５−２−１）プロファイル情報設定機能
プロファイル情報設定機能は、ＣＰＵ７１が、ユーザーにより入力されたＬＷＰのサーバ名またはＩＰアドレスや、中断されたダウンロードの再開を許可するか否かを示す情報等のＤＴＥ１１とＬＷＰ１５との間の通信に関する情報をプロファイル情報としてＥＥＰＲＯＭ７６２に記憶させる機能である。
【００２８】
図８は、プロファイル情報設定プログラムを実行中のＣＰＵ７１により実行されるプロファイル情報設定処理の流れを示すフローチャートである。この図に示されるように、ユーザーがＤＴＥ１１の操作部７３を用いて、プロファイル情報設定処理の開始を指示すると、ＣＰＵ７１は、ＥＥＰＲＯＭ７６２に記憶されているプロファイル情報を読み出して揮発性メモリ７５に一時的に記憶させるとともに、表示部７４を制御し、揮発性メモリ７５に一時的に記憶させたプロファイル情報にもとづいて図９に示すプロファイル情報設定画面を表示させる（ステップＳＡ１）。
【００２９】
図９はプロファイル情報設定画面の一例を示す図であり、入力領域９１は、ＤＴＥ１１と通信を行うＬＷＰ１５のＩＰアドレスが入力される入力領域であり、リストボックス９２は、表示部７４に表示する画像の表示階調が入力される入力領域であり、リストボックス９３には、中断されたダウンロードの再開を許可するか否かを示す情報が入力される入力領域である。
ユーザーにより何らかの入力操作が行われると、ＣＰＵ７１は操作部７３を介してユーザーの操作内容を受け取り（ステップＳＡ２）、ユーザーの操作内容の判定を行う（ステップＳＡ３）。すなわち、ユーザーの操作内容が設定ボタン９４の押下（以下「設定操作」という）であるか、キャンセルボタン９５の押下（以下「キャンセル操作」という）であるか、設定操作でもなく、キャンセル操作でもない操作（以下「その他操作」という）であるかを判定する。
【００３０】
ユーザーの操作内容が、その他操作であった場合には、ＣＰＵ７１は、ユーザーの操作内容で揮発性メモリ７５に記憶してあるプロファイル情報を更新して、当該更新後のプロファイル情報にもとづいてプロファイル情報設定画面を表示部７４に再表示（ステップＳＡ１）させ、再度ユーザーからの入力操作を待ち受ける。
ユーザーの操作内容が、設定操作であった場合には、ＣＰＵ７１は、揮発性メモリ７５に記憶してあるプロファイル情報で、ＥＥＰＲＯＭ７６２に記憶されているプロファイル情報を上書き更新（ステップＳＡ４）して、プロファイル情報設定処理を終了する。ユーザーの操作内容が、キャンセル操作であった場合には、ＣＰＵ７１は、上記の上書き更新を行わずにプロファイル情報設定処理を終了する。
【００３１】
（５−２−２）コンテンツ取得機能および解釈・表示機能
コンテンツ取得機能は、ＤＴＥ１１がＬＷＰ１５を介してＷＷＷサーバ１６からコンテンツをダウンロードする機能であり、ブラウザを実行した状態のＣＰＵ７１が備えるＨＴＴＰクライアント機能を用いて実現される。また、解釈・表示機能はダウンロードされたコンテンツを解釈・表示する機能であり、ブラウザを実行したＣＰＵ７１が備えるＨＴＭＬ解釈機能とユーザーインターフェース提供機能とを用いて実現される。
【００３２】
図１０は、ブラウザを実行中のＣＰＵ７１により実行されるコンテンツ取得処理の流れを示すフローチャートである。この図に示されように、ユーザーがＤＴＥ１１の操作部７３を用いてコンテンツ取得処理の開始を指示すると、ＣＰＵ７１は、まず、ユーザーの操作内容が、コンテンツ全体をダウンロードを要求する操作（以下、「全体要求操作」という）であるか、中断されたダウンロードを再開し、コンテンツの未受信部分のみのダウンロードを要求する操作（以下、「未受信部分要求操作」という）であるかの判定を行う（ステップＳＢ１）。
全体要求操作であった場合には、ＣＰＵ７１は、後述する全体要求処理を行い（ステップＳＢ２）、当該コンテンツ取得処理を終了する。
未受信部分要求操作であった場合には、ＣＰＵ７１は、まず、ＥＥＰＲＯＭ７６２からプロファイル情報を読み出し、中断されたダウンロードの再開が許可されているか否かの判定を行う（ステップＳＢ３）。
【００３３】
許可されている場合には、ＣＰＵ７１は、後述する未受信部分要求処理を行い（ステップＳＢ４）、当該コンテンツ取得処理を終了する。
許可されていない場合には、ＣＰＵ７１は、ユーザーにプロファイル情報の設定を促すテキストデータ（例えば、“プロファイル情報を再設定して下さい”）を表示部７４に表示させて（ステップＳＢ５）、当該コンテンツ取得処理を終了する。
【００３４】
（５−２−３）全体要求処理
図１１は、ブラウザを実行中のＣＰＵ７１により実行される全体要求処理の流れを示すフローチャートである。まず、ＣＰＵ７１は、無線通信部７２を制御してＣＰＵ７１とＬＷＰ１５との間にＴＣＰコネクション（以下、「クライアントＴＣＰコネクション」とする）を確立する（ステップＳＣ１）。次に、ＣＰＵ７１はＧＥＴメソッドを用いたリクエスト（例えば、“GET //?http://www.****.co.jp/a
aa.html/HTTP/1.0”）を生成し、当該リクエストを上記クライアントＴＣＰコネクションを介してＬＷＰ１５に送信する（ステップＳＣ２）。
【００３５】
以後、ＣＰＵ７１は上記リクエストに対するレスポンスの受信を完了したか否かの判定を行う（ステップＳＣ３）。
完了していない場合にのみ、ＣＰＵ７１は、所定の時間が経過した否かの判定を行い（ステップＳＣ４）、経過していない場合には、ステップＳＣ３以降の処理を繰り返し、経過した場合には、上記リクエストに記述されていたＵＲＩとプロファイル情報と既受信部分とを対応付けてＥＥＰＲＯＭ７６２に記憶する（ステップＳＣ５）。
【００３６】
次に、ＣＰＵ７１は、上記クライアントＴＣＰコネクションを切断し（ステップＳＣ６）、ＬＷＰ１５から送信されたダウンロードデータに対して後述するコンテンツ表示処理を行い（ステップＳＣ７）、当該全体要求処理を終了する。なお、通信障害などにより、クライアントＴＣＰコネクションが既に切断されている場合には、ＣＰＵ７１は、ステップＳＣ６の処理を行わない。
【００３７】
（５−２−４）未受信部分要求処理
図１２は、ブラウザを実行中のＣＰＵ７１により実行される未受信部分要求処理の流れを示すフローチャートである。まず、ＣＰＵ７１は、ＥＥＰＲＯＭ７６２からユーザーにより未受信部分要求操作が行われたＵＲＩに対応する既受信部分を取得し、当該既受信部分に対して後述する再開位置情報算出処理を行い、再開位置情報を取得する（ステップＳＤ１）。
【００３８】
次に、ＣＰＵ７１は、ＥＥＰＲＯＭ７６２に記憶されている既受信部分の先頭から再開位置情報で指定される部分に対して所定のハッシュ値生成アルゴリズム（例えば、Ａｄｌｅｒ−３２）を用いてハッシュ値を算出し、当該ハッシュ値を再開判定情報として取得する（ステップＳＤ２）。ここで、ハッシュ値生成アルゴリズムとは、入力データから固定長の疑似乱数を生成するアルゴリズムであり、当該アルゴリズムにより生成された固定長の擬似乱数を「ハッシュ値」と呼ぶ。一般に、ハッシュ値生成アルゴリズムには、不可逆な一方向演算を含むため、ハッシュ値から入力データを再現することはできず、また、同じハッシュ値を持つ異なるデータを作成することが極めて困難である。
【００３９】
次に、ＣＰＵ７１は、上述した全体要求処理のステップＳＣ１と同一の処理を行い、ＣＰＵ７１とＬＷＰ１５との間にクライアントＴＣＰコネクションを確立し（ステップＳＤ３）、ＨＴＴＰのＧＥＴメソッドを用いたリクエスト（例えば、“GET /offset-cheksum//?http:www.****.co.jp/aaaa.html/HTTP1.0”）を生成して、当該リクエストを上記クライアントＴＣＰコネクションを介してＬＷＰ１５に送信する（ステップＳＤ４）。なお、上記のリクエスト例で、offsetはステップＳＤ１で取得した再開位置情報を１６進数文字列に変換した文字列データであり、checksumはステップＳＤ２で取得した再開判定情報を１６進数文字列に変換した文字列データである。
【００４０】
以後、ＣＰＵ７１は上記リクエストに対するレスポンスの受信を完了したか否かの判定を行い（ステップＳＤ５）、完了していない場合にのみ、ＣＰＵ７１は、所定の時間が経過した否かの判定を行い（ステップＳＤ６）、経過していない場合には、ステップＳＤ５以降の処理を繰り返し、経過した場合には、上記リクエストに記述されていたＵＲＩとプロファイル情報と既受信部分とを対応付けてＥＥＰＲＯＭ７６２に記憶する（ステップＳＤ７）。
【００４１】
次に、ＣＰＵ７１は、上記クライアントＴＣＰコネクションを切断し（ステップＳＤ８）、ＬＷＰ１５から未受信部分が送信されたか否かを判定する（ステップＳＤ９）。なお、通信障害などにより、クライアントＴＣＰコネクションが既に切断されている場合には、ＣＰＵ７１は、ステップＳＤ８の処理を行わない。未受信部分が送信された場合には、ＣＰＵ７１はＥＥＰＲＯＭ７６２に記憶されている既受信部分とＬＷＰ１５から受信した未受信部分とを結合してダウンロードデータを取得し（ステップＳＤ１０）、当該ダウンロードデータに対して後述するコンテンツ表示処理を行って（ステップＳＤ１１）、当該未受信部分要求処理を終了する。
未受信部分が送信されなかった場合には、ＣＰＵ７１は、未受信部分が送信されなかったことを示すテキストデータ（例えば、“コンテンツは更新されています。”）を表示部７４に表示させて（ステップＳＤ１２）、当該未受信部分要求処理を終了する。
【００４２】
（５−２−５）再開位置情報算出処理
図１３は、コンテンツ取得処理を実行中のＣＰＵ７１により実行される再開位置情報算出処理の流れを示すフローチャートである。まず、ＣＰＵ７１は、ＥＥＰＲＯＭ７６２からユーザーにより入力されたＵＲＩに対応する既受信部分を読み出し、当該既受信部分が画像テキストを有するか否かの判定を行う。すなわち、ＣＰＵ７１は、既受信部分が所定のタグ（本実施形態の場合には、上述した＜ＩＭＧＤＡＴＡ０１＞タグ）を有する場合には、画像テキストを有すると判定し、当該タグを有しない場合には、画像テキストを有しないと判定する（ステップＳＥ１）。
【００４３】
画像テキストを有しない場合には、ＣＰＵ７１は、当該既受信部分の大きさ（バイト数）を再開位置情報として、当該再開位置情報算出処理を終了する（ステップＳＥ２）。
画像テキストを有する場合には、ＣＰＵ７１は、当該既受信部分に対応づけらえたプロファイル情報をＥＥＰＲＯＭ７６２から取得し、当該プロファイル情報に設定されている表示階調と、現在のプロファイル情報に設定されている表示階調とが異なるか否かを判定する（ステップＳＥ３）。
【００４４】
同一である場合には、ＣＰＵ７１は、当該既受信部分の大きさを再開位置情報とし（ステップＳＥ４）、異なる場合には、当該既受信部分のテキスト部５１の大きさ（バイト数）を再開位置情報として（ステップＳＥ５）、当該再開位置算出処理を終了する。
【００４５】
（５−２−６）コンテンツ表示処理
ＣＰＵ７１は、ダウンロードデータのテキスト領域５１（図５参照）をＨＴＭＬ文法に従って解釈し、その記述に応じたレイアウトの画像データを生成し、表示部７４に供給する。なお、完全にコンテンツを取得できなかった場合には、ＣＰＵ７１は、取得した部分までの解釈を行う。当該解釈においては、ＣＰＵ７１は階層的に記述された各種のタグに対応した処理を行う。ＣＰＵ７１が行う処理のうち、本実施形態の動作に直接関連する処理について以下に説明する。
【００４６】
▲１▼ＩＭＧタグ処理
ＣＰＵ７１は、ＩＭＧタグのＳＲＣ属性に記述されている文字列（例えば、“ＩＭＧＤＡＴＡ０１”）と同一の文字列を有するタグ（例えば、＜ＩＭＧＤＡＴＡ０１＞）で特定される画像テキストを画像領域５２から読み出し、当該画像テキストを所定のアルゴリズム（例えば、Ｂａｓｅ６４等）を用いてデコードして画像データに再生し、表示部７４を制御して当該画像データで表される画像をＩＭＧタグに指定されているＷＩＤＴＨ属性およびＨＩＧＨＴ属性で指定されたサイズで表示させる。
【００４７】
（６）ＬＷＰ１５の構成および機能
（６−１）ＬＷＰ１５の構成
図１４は、ＬＷＰ１５のハードウェア構成を示すブロック図であり、この図に示されるようにＬＷＰ１５は、ＣＰＵ１４１と、通信インターフェース部１４２と、不揮発性メモリ１４３と、揮発性メモリ１４４と、記憶装置１４５と、補助記憶装置１４６と、これら各要素間のデータ授受を仲介するバス１４７とを有している。
【００４８】
通信インターフェース部１４２は、例えばネットワークインターフェースであり、ＣＰＵ１４１から供給された情報をインターネット１４へ送出するとともに、インターネット１４を介して受信した情報をＣＰＵ１４１へ渡す。不揮発性メモリ１４３は、例えばＲＯＭ（Read Only Memory）であり、ＬＷＰ１５の電源が投入されたときに、記憶装置１４５に記憶されているＯＳを読み出して実行する機能を有するプログラムであるＩＬ（Initial Loader）を記憶している。揮発性メモリ１４４は、例えばＲＡＭ（Random Access Memory）である。補助記憶装置１４６は、例えばＣＤ−ＲＯＭ等のコンピュータ装置が読み取り可能な記録媒体に記録されているデータを読み取る機能を有するものである。記憶装置１４５は、例えばハードディスクドライブであり、ＯＳおよび後述するコンテンツ代理取得プログラム等のソフトウェア等を記憶している。
【００４９】
（６−２）ＬＷＰ１５の機能
次に、ＣＰＵ１４１が記憶装置１４５に記憶されたソフトウェアを実行することでＬＷＰ１５に付与される機能について説明する。なお、ＤＴＥ１１とＷＷＷサーバ１６との通信を中継するためのＨＴＴＰ処理機能については、一般的な代理サーバ装置の有する機能と略同一であるため説明を省略し、本実施形態に直接関係する機能についてのみ説明する。
【００５０】
ＣＰＵ１４１は、ＬＷＰ１５の電源（図示略）が投入されると、まず、不揮発性メモリ１４３からＩＬを読み出して実行する。ＩＬを実行した状態のＣＰＵ１４１は、記憶装置１４５からＯＳを読み出して実行する。ＯＳを実行した状態のＣＰＵ１４１は、揮発性メモリ１４４をワークエリアとして使用すること、ＬＷＰ１５の各部を制御することができる。なお、ＯＳを実行中のＣＰＵ１４１は複数のプログラムを並列に実行することができる。また、ＣＰＵ１４１は、即座にコンテンツ代理取得を行うためのプログラムを起動し、ＤＴＥ１１からのリクエストを待ちうける。
【００５１】
（６−２−１）コンテンツ代理取得機能
コンテンツ代理取得機能は、ＤＴＥ１１からのリクエストに応じてＷＷＷサーバ１６からコンテンツを取得して、ＤＴＥ１１からのリクエストに応じた加工を行った後に上記リクエストに対するレスポンスとしてＤＴＥ１１へ転送する機能である。
【００５２】
図１５は、コンテンツ代理取得プログラムを実行中のＣＰＵ１４１により実行されるコンテンツ代理取得処理の流れを示すフローチャートである。この図に示されるように、ＣＰＵ１４１は、ＤＴＥ１１からのコネクション確立要求に応じてクライアントＴＣＰコネクションを確立する（ステップＳＦ１）。そして当該ＴＣＰコネクションを介してＤＴＥ１１からＨＴＴＰのＧＥＴメソッドを用いたリクエストを受信すると、ＣＰＵ１４１は、当該ＧＥＴメソッドのリクエストラインを解析し、当該リクエストラインに記述されているＵＲＩや再開位置情報や再開判定情報を取得する（ステップＳＦ２）。
【００５３】
次に、ＣＰＵ１４１は、ＤＴＥ１１から受信したリクエストに記述されていたＵＲＩに対応するＷＷＷサーバ１６との間でＴＣＰコネクション（以下、「サーバＴＣＰコネクション」とする）を確立する（ステップＳＦ３）。
【００５４】
更にＣＰＵ１４１は、当該リクエストを加工（例えば、クライアントＴＣＰコネクションを介してＤＴＥ１１から受信したリクエストでは、当該リクエストの送信元はＤＴＥ１１になっているが、当該リクエストの送信元をＬＷＰ１５に書き換える等）し、加工後のリクエストを当該サーバＴＣＰコネクション経由で送信する（ステップＳＦ４）。
以後、ＣＰＵ１４１は上記リクエストに対するレスポンスを待ち（ステップＳＦ５）、当該レスポンスを受信すると、当該サーバＴＣＰコネクションを切断する（ステップＳＦ６）。なお、通信障害などにより、サーバＴＣＰコネクションが既に切断されている場合には、ＣＰＵ７１は、ステップＳＦ６の処理を行わない。
【００５５】
次に、ＣＰＵ１４１は、上記レスポンスに含まれるテキストデータに、後述する関連データ結合処理を行ってダウンロードデータを生成する（ステップＳＦ７）。
次に、ＣＰＵ１４１は、ＤＴＥ１１からコンテンツ全体の送信を要求されたのか、未受信部分のみの送信を要求されたのかを判定する（ステップＳＦ８）。
コンテンツ全体の送信を要求された場合には、ＣＰＵ１４１は、ステップＳＦ７で生成したダウンロードデータを上記クライアントＴＣＰコネクションを介して、ＤＴＥ１１からのリクエストに対応するレスポンスとして送信し（ステップＳＦ９）、当該クライアントＴＣＰコネクションを切断し（ステップＳＦ１４）、当該コンテンツ代理取得処理を終了する。
未受信部分のみの送信を要求された場合には、ＣＰＵ１４１は、ステップＳＦ７で生成したダウンロードデータに対して再開判定情報を算出する（ステップＳＦ１０）。具体的には、当該ダウンロードデータの先頭から、ステップＳＦ２で取得した再開位置情報で指定される長さの部分に対して、ＤＴＥ１１で用いたハッシュ値生成アルゴリズムと同一のアルゴリズムを用いて再開判定情報を算出する。
【００５６】
次に、ＣＰＵ１４１は、ステップＳＦ１０で算出した再開判定情報と、ステップＳＦ２で取得した再開判定情報とが一致するか否かの判定を行う（ステップＳＦ１１）。
一致する場合には、ＣＰＵ１４１は、ステップＳＦ７で生成したダウンロードデータの先頭からステップＳＦ２で取得した再開位置情報で指定される長さの部分を切り捨てて未受信部分を生成し、当該未受信部分を上記クライアントＴＣＰコネクションを介して、ＤＴＥ１１からのリクエストに対応するレスポンスとして送信し（ステップＳＦ１２）、当該クライアントＴＣＰコネクションを切断し（ステップＳＦ１４）、当該コンテンツ代理取得処理を終了する。
一致しない場合には、ＣＰＵ１４１は、再開不能であることを示す情報を含むレスポンスを、対応するクライアントＴＣＰコネクションを介して、ＤＴＥ１１からのリクエストに対応するレスポンスとして送信した後に（ステップＳＦ１３）、当該クライアントＴＣＰコネクションを切断し（ステップＳＦ１４）、当該コンテンツ代理取得処理を終了する。
【００５７】
（６−２−２）関連データ結合処理
図１６は、コンテンツ代理取得処理を実行中のＣＰＵ１４１により実行される関連データ結合処理の流れを示すフローチャートである。この図に示されるように、まず、ＣＰＵ１４１は、コンテンツ代理取得処理のステップＳＦ５でＷＷＷサーバ１６から取得したテキストデータを解析し、当該テキストデータがＩＭＧタグを有するか否かを判定する（ステップＳＧ１）。
【００５８】
ＩＭＧタグを有しない場合には、ＣＰＵ１４１は、当該テキストデータをダウンロードデータとして当該関連データ結合処理を終了し、ＩＭＧタグを有する場合には、ＣＰＵ１４１は、当該ＩＭＧタグのＳＲＣ属性に指定されたＵＲＩに対応するＷＷＷサーバとの間でサーバＴＣＰコネクションを確立する（ステップＳＧ２）。
【００５９】
次に、ＣＰＵ１４１は、当該ＵＲＩで指定される画像データを取得するためのリクエストを生成し、当該サーバＴＣＰコネクションを介して当該ＵＲＩで指定されるＷＷＷサーバに送信する（ステップＳＧ３）。
以後、ＣＰＵ１４１は当該リクエストに対するレスポンスの受信を待ち（ステップＳＧ４）、当該レスポンスを受信すると、当該サーバＴＣＰコネクションを切断する（ステップＳＧ５）。なお、通信障害などにより、当該サーバＴＣＰコネクションが既に切断されている場合には、ＣＰＵ７１は、ステップＳＧ５の処理を行わない。
【００６０】
次に、ＣＰＵ１４１は、揮発性メモリ１４４に記憶されているプロファイル情報から表示階調を読み出し、ステップＳＦ４で取得した画像データを当該表示階調になるように圧縮して、圧縮済みの画像データを生成し（ステップＳＧ６）、当該圧縮済みの画像データを、所定のアルゴリズム（例えば、Ｂａｓｅ６４）を用いてエンコードして画像テキストを生成し、当該画像テキストを揮発性メモリ１４４に一時的に記憶させる（ステップＳＧ７）。
【００６１】
次に、ＣＰＵ１４１は、テキストデータのＩＭＧタグのＳＲＣ属性で指定されているＵＲＩを所定の文字列（例えば、“ＩＭＧＤＡＴＡ０１”）に置き換え、更に、ステップＳＧ７で生成した画像テキストの開始位置と終了位置とを指定するために、所定のタグ（例えば、上述の＜ＩＭＧＤＡＴＡ０１＞タグと＜／ＩＭＧＤＡＴＡ０１＞タグ）を付与して、ＩＭＧタグを書き換えたテキストデータの末尾へ追加書き込みする（ステップＳＧ８）。
以降、ＣＰＵ１４１は、テキストデータに記述されているＩＭＧタグの個数分だけ、ステップＳＧ２からステップＳＧ８までの処理を行ってダウンロードデータを生成し、当該関連データ結合処理を終了する。
【００６２】
（７）動作例
本実施形態の動作はプロファイル情報の内容、コンテンツの内容に応じて異なり、その動作パターンは多数となるが、以下では本発明の特徴を表す動作例について説明する。ただし、以下に説明する動作例の前提として、ＤＴＥ１１がＷＷＷサーバ１６から取得するコンテンツは、図３に示されるテキストデータ（aaaa.html）と図４に示される画像データ（bbbb.gif）とから構成されているものとし、当該コンテンツがＤＴＥ１１へダウンロードされると、ＤＴＥ１１は、図１７に示す画像を表示部７４に表示する。
【００６３】
（７―１）ダウンロードが中断された場合の動作例
ＤＴＥ１１がＷＷＷサーバ１６から上記のコンテンツをダウンロード中に、ダウンロードが中断された場合の動作について図１８に示すシーケンス図を用いて説明する。ユーザーがＤＴＥ１１の操作部７３を操作してＷＷＷサーバ１６からコンテンツ全体を取得することを指示すると、ＤＴＥ１１は、上述したコンテンツ取得機能を用いて全体要求処理（図１０：ステップＳＢ２）を行う。まず、ＤＴＥ１１は、ＬＷＰ１５との間でクライアントＴＣＰコネクションを確立し（図１１：ステップＳＣ１）、ＬＷＰ１５へテキストデータ（aaaa.html）を要求するリクエスト１７１を送信する（図１１：ステップＳＣ２）。
【００６４】
上記リクエストを受信したＬＷＰ１５は、上述したコンテンツ代理取得機能を用いてコンテンツ代理取得処理を行い、まず、ＷＷＷサーバ１６からテキストデータ（aaaa.html）を取得する（図１５：ステップＳＦ５）。次に、ＬＷＰ１５は、上述した関連データ結合処理を行い（図１５：ステップＳＦ６）、当該テキストデータを解析する（図１６：ステップＳＧ１）。当該テキストデータはＩＭＧタグを有するので、ＬＷＰ１５は、ＷＷＷサーバ１６から画像データ（bbbb.gif）を取得し（図１６：ステップＳＧ４）、テキストデータ（aaaa.html）と画像データ（bbbb.gif）とから図５に示すダウンロードデータを生成し（図１６：ステップＳＧ８）、当該ダウンロードデータを含むレスポンス１７６をＤＴＥ１１へ返信する（図１５：ステップＳＦ９）。なお、当該レスポンスは当該ダウンロードデータを所定のデータ量（バイト数）に分割した複数のパケットの送受信として行われる。
【００６５】
ここで、コンテンツをダウンロード中のユーザーが通信サービスエリア外に移動したことにより、ＤＴＥ１１とＬＷＰ１５とのクライアントＴＣＰコネクションが切断されたとする。すると、ＤＴＥ１１は、所定の時間が経過するまでレスポンスの受信完了を待ち受けるが（図１１：ステップＳＣ３）、もはや、後続のパケットを受信することはない。以降、所定の時間が経過するとＤＴＥ１１は、これまでに受信したパケットに含まれるデータを既受信部分としてＵＲＩやプロファイル情報と対応づけてＥＥＰＲＯＭ７６２に記憶し（図１１：ステップＳＣ５）、既受信部分を表示する（図１１：ステップＳＣ６）。例えば、ＤＴＥ１１が、図１９に示すダウンロードデータの先頭から破線１９１までの部分を受信していた場合には、当該既受信部分には、文字列“ＩＪＫＬＭＮ”と画像テキストとに関する情報が含まれていないために、ＤＴＥ１１は、図２０に示す画像を表示部７４に表示させる。
【００６６】
（７―２）コンテンツの続きを取得する場合の動作例
次に、上記に説明した中断が発生した後に、ユーザーによりダウンロードの再開が指示された場合の動作例について説明する。
（７―２―１）テキストデータの続きから取得する場合の動作例
ＤＴＥ１１のＥＥＰＲＯＭ７６２に、図１９に示すダウンロードデータの先頭から破線１９１までの部分が、ＵＲＩやダウンロードが中断された時点のプロファイル情報と対応づけられて既受信部分として記憶されているものとする。また、ＤＴＥ１１の表示部７４には当該既受信部分に対応する画像として、図２０に示される画像が表示されている。
【００６７】
ユーザーがＤＴＥ１１の操作部７３を操作してＷＷＷサーバ１６から当該コンテンツの続きを取得することを指示すると、ＤＴＥ１１は、上述した未受信部分要求処理を用い、まず、ＥＥＰＲＯＭ７６２に記憶されている既受信部分から再開位置情報（図１２：ステップＳＤ１）と再開判定情報とを算出する（図１２：ステップＳＤ２）。なお、ＥＥＰＲＯＭ７６２に記憶されている既受信部分はＩＭＧタグを有していないので、当該既受信部分の大きさ（バイト数）が再開位置情報に設定される。
以下、ＤＴＥ１１は、ＤＴＥ１１とＬＷＰ１５との間でクライアントＴＣＰコネクションを確立し、一方、ＬＷＰ１５は、上述したコンテンツ全体のダウンロードの場合と同一の処理を行う。すなわち、ＬＷＰ１５は、ＷＷＷサーバ１６との間でサーバＴＣＰコネクションの確立から、関連データ結合処理までの処理を行う。
【００６８】
次に、ＬＷＰ１５は、関連データ結合処理で生成したデータの先頭から再開位置情報で指定される長さの部分に対して、再開判定情報を算出し、当該再開判定情報とＤＴＥ１１から送信された再開判定情報とが一致するか否かの判定を行う（図１５：ステップＳＦ１０）。ここで、これら再開判定情報が一致するか否かは、ＷＷＷサーバ１６に記憶されているテキストデータ（aaaa.html）が、ダウンロードが中断された時点から、コンテンツの続きを取得が指示されるまでの間に、更新されたか否かに依存する。以下、更新されていた場合と更新されていなかった場合とに分けて動作例を説明する。
【００６９】
▲１▼ 更新されていなかった場合
ＷＷＷサーバ１６に記憶されているテキストデータ（aaaa.html）が更新されていなかった場合には、ＤＴＥ１１から送信された再開判定情報とＬＷＰ１５で生成した再開判定情報とは一致する。従って、ＬＷＰ１５は図１９に示すダウンロードデータの破線１９１から当該ダウンロードデータの末尾までの部分を未受信部分として、当該未受信部分を含むレスポンスをＤＴＥ１１に返信する（図１５：ステップＳＦ１２）。
ＤＴＥ１１は、当該レスポンスを受信すると、上述したコンテンツ表示処理を行い、ＥＥＰＲＯＭ７６２に記憶されている既受信部分（図１９に示すダウンロードデータの先頭から破線１９１までの部分）と、当該レスポンスに含まれる未受信部分（図１９に示すダウンロードデータの破線１９１から当該データの末尾までの部分）とを結合して（図１２：ステップＳＤ１０）、図１９に示すダウンロードデータを取得し、当該データを解釈して図１７に示す画像を表示部７４に表示する。
【００７０】
▲２▼ 更新されていた場合
ＷＷＷサーバ１６に記憶されているテキストデータ（aaaa.html）が更新されていた場合には、ＤＴＥ１１から送信された再開判定情報とＬＷＰ１５で生成した再開判定情報とは一致しない。従って、ＬＷＰ１５は再開不能であることを示す情報を含むレスポンスを、ＤＴＥ１１に返信する（図１５：ステップＳＦ１３）。 ＤＴＥ１１は、当該レスポンスを受信すると、未受信部分が送信されなかったことを示すテキストデータ（例えば、“コンテンツは更新されています。”）を表示部７４に表示させる。
【００７１】
（７―２―２）画像データの続きから取得する場合の動作例
次に、ＤＴＥ１１のＥＥＰＲＯＭ７６２に、図１９に示すダウンロードデータの先頭から破線１９３までの部分が既受信部分として、プロファイル情報と対応づけられて記憶されているものとする。当該既受信部分には、テキストデータの全部と画像テキストの一部とが含まれているために、ＤＴＥ１１は、図２１に示す画像を表示部７４に表示させている。
なお、以下に説明する動作例では、ＷＷＷサーバ１６に記憶されているコンテンツを構成するテキストデータ（aaaa.html）と画像データ（bbbb.gif）とは、いずれもダウンロードが中断後に、更新されていないものとする。
【００７２】
ユーザーがＤＴＥ１１の操作部７３を操作してＷＷＷサーバ１６からコンテンツの続きを取得することを指示すると、ＤＴＥ１１は、上述したコンテンツ取得処理を行い、まず、ＥＥＰＲＯＭ７６２に記憶されている既受信部分から再開位置情報（図１２：ステップＳＤ１）と再開判定情報（図１２：ステップＳＤ２）とを算出する。この時、ＥＥＰＲＯＭ７６２に記憶されている既受信部分はＩＭＧタグを有するので、ＤＴＥ１１は、ダウンロードが中断された時の表示階調と、現在プロファイル情報に設定されている表示階調とが異なるか否かを判定する（図１３：ステップＳＥ３）。
【００７３】
▲１▼ 表示階調が同一である場合の動作例
ダウンロードが中断された時の表示階調と現在プロファイル情報に設定されている表示階調とが同一である場合には、ＥＥＰＲＯＭ７６２に記憶されている既受信部分の大きさ（バイト数）を再開位置情報として、再開判定情報を算出する（図１３：ステップＳＥ４）。
以下、ＤＴＥ１１は、ＤＴＥ１１とＬＷＰ１５との間でクライアントＴＣＰコネクションを確立し、一方、ＬＷＰ１５は、上述したコンテンツ全体のダウンロードの場合と同一の処理を行う。すなわち、ＬＷＰ１５は、ＷＷＷサーバ１６との間でサーバＴＣＰコネクションの確立から、関連データ結合処理までの処理を行い、ＬＷＰ１５は図１９に示すダウンロードデータの破線１９３から当該データの末尾までの部分を未受信部分として、当該未受信部分を含むレスポンスをＤＴＥ１１に返信する。
ＤＴＥ１１は、当該レスポンスを受信すると、上述したコンテンツ表示処理を行い、ＥＥＰＲＯＭ７６２に記憶されている既受信部分（図１９に示すダウンロードデータの先頭から破線１９３までの部分）と、当該レスポンスに含まれる未受信部分（図１９に示すダウンロードデータの破線１９３から当該データの末尾までの部分）とを結合して、図１９に示すダウンロードデータを取得し、当該ダウンロードデータを解釈して図１７に示す画像を表示部７４に表示する。
【００７４】
▲２▼ 表示階調が異なる場合の動作例
ダウンロードが中断された時の表示階調と、現在プロファイル情報に設定されている表示階調とが異なる場合には、ＥＥＰＲＯＭ７６２に記憶されている既受信部分の先頭から破線１９２で示される部分の大きさを再開位置情報として（図１３：ステップＳＥ５）、当該部分に対して再開判定情報を算出する。
【００７５】
以下、ＤＴＥ１１は、ＤＴＥ１１とＬＷＰ１５との間でクライアントＴＣＰコネクションを確立し、一方、ＬＷＰ１５は、上述したコンテンツ全体のダウンロードの場合と同一の処理を行う。すなわち、ＷＷＷサーバ１６との間でサーバＴＣＰコネクションの確立から、関連データ結合処理までの処理を行い、ＬＷＰ１５は図１９に示すダウンロードデータの破線１９２から当該データの末尾までの部分を未受信部分として、当該未受信部分を含むレスポンスをＤＴＥ１１に返信する。
【００７６】
ＤＴＥ１１は、当該レスポンスを受信すると、上述したコンテンツ表示処理を行い、ＥＥＰＲＯＭ７６２に記憶されている既受信部分（図１９に示すダウンロードデータの先頭から破線１９３までの部分）と、当該レスポンスに含まれる未受信部分（図１９に示すダウンロードデータの破線１９２から当該データの末尾までの部分）とを結合して図１９に示すダウンロードデータを取得する。なお、重複する部分（図１９に示すダウンロードデータの破線１９２から破線１９３までの部分）は、当該レスポンスに含まれる未受信部分で上書きされる。以下ＤＴＥ１１は、当該データを解釈して図１７に示す画像を表示部７４に表示する。
【００７７】
（８）実施形態効果
本実施形態によれば、ＷＷＷサーバ１６からＤＴＥ１１へのコンテンツのダウンロードが中断された場合には、ＤＴＥ１１が既受信部分を記憶するために、中断された時点からダウンロードを再開して、未受信部分のみ取得し、ＤＴＥ１１に記憶されている既受信部分とＬＷＰ１５から取得した未受信部分とを結合してコンテンツを取得することが可能となり、コンテンツ全体を再度取得する場合に比べて、短時間にコンテンツを取得できるといった効果を奏する。
【００７８】
また、本実施形態によれば、ＬＷＰ１５が、ＤＴＥ１１から送信された再開判定情報と、ＬＷＰ１５で算出した再開判定情報とが一致した場合にのみ未受信部分を送信するために、ＬＷＰ１５からＤＴＥ１１への結合不能なデータの送信が抑止され、ユーザーの負担する通信コストが削減されるといった効果を奏する。
【００７９】
また、本実施形態によれば、コンテンツが複数個のデータから構成されている場合であっても、これら複数個のデータをＬＷＰ１５で１つのダウンロードデータに結合してＤＴＥ１１にダウンロードするために、ＬＷＰ１５からＤＴＥ１１へのダウンロードが中断され、その後、ＤＴＥ１１からダウンロードの再開を要求された時に、当該ダウンロードデータが更新されたか否かを再開判定情報を用いて１回だけ比較すれば、中断されたダウンロードの再開が可能であるか否かを判定できるといった効果を奏する。
【００８０】
また、本実施形態によれば、再開判定情報としてＡｄｌｅｒ−３２アルゴリズムにより算出された固定長のハッシュ値を用いるために、ＤＴＥ１１に記憶されている既受信部分全体を用いる場合に比較して、通信データ量を削減できるといった効果を奏する。また、ハッシュ値生成アルゴリズムとしてＡｄｌｅｒ−３２を使用するために、他のハッシュ値生成アルゴリズム（例えば、ＣＲＣ−３２等）に比較して、高速にハッシュ値を算出できるといった効果を奏する。
【００８１】
（９）変形例
［変形例１］
上述した実施形態では、ブラウザ機能付き携帯電話をＤＴＥとして用いる場合の実施例について説明したが、ＤＴＥはブラウザ機能付き携帯電話に限定されるものではなくブラウザ機能付きＰＤＡ（Personal Digital Assistance）やブラウザ機能付きＰＣ（Personal Computer）でも良い、要はブラウザ機能を搭載しインターネットに接続可能な端末装置であれば良い。
【００８２】
［変形例２］
上述した実施形態では、ＬＷＰ１５がコンテンツ代理取得処理で生成したダウンロードデータを記憶装置１４５に記憶せず、ＤＴＥ１１からコンテンツのダウンロードを要求される度にダウンロードデータを生成する場合の実施例について説明したが、ＬＷＰ１５にバス１４７を介してＣＰＵ１４１に現在日時を供給する時計部１４８を更に設け、ＣＰＵ１４１が、ダウンロードデータを生成した場合には、当該ダウンロードデータの作成日時を時計部１４８から取得し、当該作成日時と当該ダウンロードデータとを対応付けて記憶装置１４５に記憶させても良い。
【００８３】
この様な構成および機能を有するＬＷＰ１５は、ＤＴＥ１１からコンテンツのダウンロード要求を受信した場合に、図２２のフローチャートに示されるコンテンツ代理取得処理を行う。なお、図２２に示すフローチャートでは、ＴＣＰコネクションの確立・切断と、レスポンス受信待とは省略されており、当該処理の要部のみが示されている。
ＣＰＵ１４１は、ＤＴＥ１１からＨＴＴＰのＧＥＴメソッドを用いたリクエストを受信すると、ＣＰＵ１４１は、当該ＧＥＴメソッドのリクエストラインを解析し、当該リクエストラインに記述されているＵＲＩや再開位置情報や再開判定情報を取得する（ステップＳＨ１）。
【００８４】
次に、ＣＰＵ１４１は、ＤＴＥ１１からダウンロードを要求されたダウンロードデータを記憶装置１４５に記憶しているか否かの判定を行う（ステップＳＨ２）。
記憶している場合には、ＣＰＵ１４１は、記憶装置１４５に記憶しているダウンロードデータが最新であるか否かの判定を行う（ステップＳＨ１１）。具体的には、当該ダウンロードデータの作成日時と、当該ダウンロードデータを構成するテキストデータおよび画像データの作成日時とを比較し、当該ダウンロードデータの作成日時が最新である場合にのみ当該ダウンロードデータは最新であると判定する（ステップＳＨ１２）。最新でない場合には、ＣＰＵ１４１は、後述するステップＳＨ３以降の処理を行い、最新である場合には、ＣＰＵ１４１は、記憶装置１４５に記憶されているダウンロードデータを用いて後述するステップＳＨ５以降の処理を行う。
記憶していない場合には、ＣＰＵ１４１は、ＷＷＷサーバ１６からテキストデータを取得し（ステップＳＨ３）、ＷＷＷサーバ１６から受信したテキストデータに対して関連データ結合処理を行ってダウンロードデータを生成する（ステップＳＨ４）。
【００８５】
次に、ＣＰＵ１４１は、ＤＴＥ１１からコンテンツ全体の送信を要求されたのか、未受信部分のみの送信を要求されたのかを判定する（ステップＳＨ５）。
コンテンツ全体の送信を要求された場合には、ＣＰＵ１４１は、ダウンロードデータをＤＴＥ１１送信して（ステップＳＨ６）、当該当該処理を終了する。
未受信部分のみの送信を要求された場合には、ＣＰＵ１４１は、ダウンロードデータに対して再開判定情報を算出し（ステップＳＨ７）、ステップＳＨ７で算出した再開判定情報と、ステップＳＨ１で取得した再開判定情報とが一致するか否かの判定を行う（ステップＳＨ８）。
【００８６】
一致する場合には、ＣＰＵ１４１は、ダウンロードデータから未受信部分を生成し、当該未受信部分をＤＴＥ１１へ送信して（ステップＳＨ９）、当該処理を終了する。
一致しない場合には、ＣＰＵ１４１は、再開不能であることを示す情報をＤＴＥ１１へ送信（ステップＳＨ１０）して、当該処理を終了する。
【００８７】
［変形例３］
上述した実施形態では、ＬＷＰ１５が、ＤＴＥ１１からダウンロードを要求されたデータと当該データに関連付けられたデータとから１つのダウンロードデータを生成して、当該ダウンロードデータをＤＴＥ１１へダウンロードする場合の実施例について説明したが、テキストデータのダウンロードと、当該テキストデータに関連付けられたデータ（他のテキストデータ、画像、音声、プログラム等）のダウンロードとを個別に行っても良い。
具体的には、ＤＴＥ１１は、まず、ＬＷＰ１５を介してＷＷＷサーバ１６からテキストデータをダウンロードし、当該テキストデータを解釈して、当該テキストデータに関連付けられているデータを一つづつＬＷＰ１５を介してＷＷＷサーバ１６からダウンロードして、ユーザーの所望するコンテンツを取得する。
このような場合には、例えば、テキストデータのダウンロードに対して、当該テキストデータに関連付けられた他のデータの更新の有無は、影響を与えない。従って、テキストデータのダウンロードが中断された場合に、当該ダウンロードが再開可能であるか否かを判定するには、ダウンロード対象のテキストデータが更新されたか否かを判定すれば良い。一方、テキストデータに関連付けられたデータのダウンロードが中断された場合に、当該ダウンロードが再開可能であるか否かを判定するには、ダウンロード対象のデータが更新されたか否かを判定すれば良い。
【００８８】
［変形例４］
また、上述した実施形態では、ハッシュ値算出アルゴリズムとしてＡｄｌｅｒ−３２アルゴリズムを用いる場合の実施例について説明したが、他のハッシュ値算出アルゴリズム（例えばＣＲＣ−３２等）を用いても良い。
【００８９】
［変形例５］
また、上述した実施形態では、ハッシュ値を用いて、中断されたデータ送信が再開可能であるか否かを判定する実施例について説明したが、ハッシュ値ではなく、ＤＴＥ１１のＥＥＰＲＯＭ７６２に記憶されているデータそのものを用いて再開可能か否かを判定しても良い。具体的には、ＤＴＥ１１からＬＷＰ１５へ未受信部分のみの送信を要求する場合に、ＤＴＥ１１が、リクエストラインにＤＴＥ１１が記憶している既受信部分を設定してＬＷＰ１５にリクエストを送信し、ＬＷＰ１５は、関連データ結合処理で生成したダウンロードデータの先頭からＤＴＥ１１から送信された当該既受信部分の長さで特定される部分と、ＤＴＥ１１から送信された既受信部分とを比較し、両者が一致する場合にのみ中断されたダウンロードの再開を行っても良い。
【００９０】
［変形例６］
また、上述した実施形態では、ＤＴＥ１１のＥＥＰＲＯＭ７６２に記憶されている既受信部分全体を用いて、中断されたデータ送信が再開可能であるか否かを判定する実施例について説明したが、当該既受信部分の特定の一部分を用いて、中断されたデータ送信が再開可能であるか否かを判定しても良い。例えば、ＤＴＥ１１のＥＥＰＲＯＭ７６２に記憶されている既受信部分の奇数バイト目と、ＬＷＰ１５で生成されたダウンロードデータの先頭からＤＴＥ１１から送信された当該既受信部分の長さで特定される部分の奇数バイト目とが全て一致した場合にのみ中断されたデータ送信の再開を行うとしても良い。
【００９１】
［変形例７］
また、上述した実施形態では、ＤＴＥ１１のＥＥＰＲＯＭ７６２に記憶されている既受信部分を用いて、中断されたデータ送信が再開可能であるか否かを判定する実施例について説明したが、ＤＴＥ１１に、バス７７を介してＣＰＵ７１に現在日時を供給する時計部７８を更に設け、ＬＷＰ１５からのデータのダウンロードが中断されると、ＣＰＵ７１は、それまでに受信したデータと時計部７８から取得した日時とを対応付けてＥＥＰＲＯＭ７６２に記憶させ、ダウンロードの再開を要求する際に、当該日時をＬＷＰ１５に送信し、ＬＷＰ１５で当該日時とＷＷＷサーバ１６に記憶されているデータの作成日時とをＬＷＰ１５で比較し、前者が後者より新しい場合にのみ中断されたダウンロードの再開を行うとしても良い。
【００９２】
［変形例８］
また、上述した実施形態では、ダウンロード中断前後でＷＷＷサーバ１６の有するデータが更新されたために、結合不能と判定された場合にはエラーメッセージを送信し、再度データ全体のダウンロードを促す実施形態について説明したが、更新後のデータから生成されたダウンロードデータ全体をダウンロードしても良い。
【００９３】
［変形例９］
また、上述した実施形態では、一台のＬＷＰ１５で中継を行う実施形態について説明したが、信頼性向上および負荷分散の観点から、例えば複数台のＬＷＰからなるクラスター構成あるいはホットスタンバイ構成等の多重化構成にしても良い。
【００９４】
［変形例１０］
また、上述した実施形態では、ＬＷＰ１５が予め本発明に係るプログラムを記憶している場合の実施形態について説明したが、当該プログラムを記憶していない一般的な代理サーバ機能を有するコンピュータ装置に、コンピュータ装置が読み取り可能な記録媒体に記録されている当該プログラムを読み込ませて、当該プログラムを当該代理サーバ装置に記憶させ、上述した実施形態におけるＬＷＰ１５と略同一の機能を追加しても良い。
また、上述した実施形態では、ＤＴＥ１１が予め本発明に係るプログラムを記憶している場合の実施形態について説明したが、ダウンロードしたプログラムを記憶および実行する機能を有する一般的なブラウザ機能付携帯電話に、本件発明に係るプログラムを記憶させてＤＴＥ１１と略同一の機能を付与しても良い。具体的には、本発明に係るプログラムを記録したコンピュータ装置が読み取り可能な記録媒体から当該プログラムを代理サーバ装置に読み込ませて当該代理サーバ装置の記憶装置に当該プログラムを記憶させ、前記携帯電話に前記代理サーバ装置から当該プログラムをダウンロードして記憶させることにより、ＤＴＥ１１と略同一の機能を追加しても良い。
【００９５】
［変形例１１］
また、上述した実施形態では、移動パケット通信網１２とインターネット１４とをゲートウェイサーバ１３を介して接続し、インターネット１４に接続されたＬＷＰ１５において本件発明に係る中継方法を実行する場合の実施例について説明したが、ゲートウェイサーバ１３にＬＷＰ１５の機能を実現するプログラムを記憶させ、ゲートウェイサーバ１３で本件発明に係る中継方法を実行させても良い。
【００９６】
［変形例１２］
また、上述した実施形態では、ＤＴＥ１１とＬＷＰ１５とが、移動パケット通信網１２とゲートウェイサーバ１３とインターネット１４とを介して通信を行う通信態様の場合の実施例について説明したが、ＤＴＥ１１とＬＷＰ１５との間の通信態様は、このような通信態様に限定されるものではなく、移動パケット通信網１２に替えて非パケット通信網を用いた通信態様でも良く、また、インターネット１４に替えて構内ＬＡＮ（いわゆるイントラネット）を用いた通信態様でも良く、また、インターネット１４のみを用いた通信態様でも良く、構内ＬＡＮのみを用いた通信態様であっても良い。
また、上述した実施形態では、ＬＷＰ１５とＷＷＷサーバ１６とが、インターネット１４を介して通信を行う通信態様の場合の実施例について説明したが、ＬＷＰ１５とＷＷＷサーバ１６との間の通信態様は、インターネット１４を用いた通信態様に限定されるものではなく、構内ＬＡＮを用いた通信態様であっても良い。
【００９７】
［変形例１３］
また、上述した実施形態では、ＤＴＥ１１がＬＷＰ１５を介してＷＷＷサーバ１６から取得するデータが、ＨＴＭＬで記述されたテキストデータとＨＴＭＬに従って当該テキストデータに関連付けられた他のデータ（画像データや音声データ等）とを有するコンテンツである場合の実施例について説明したが、コンテンツを構成するテキストデータは、ＨＴＭＬで記述されたテキストデータに限られるものではなく、ＨＴＭＬを機能拡張した記述言語であるＸＨＴＭＬ（eXtensible Hyper Text Markup Language）で記述されたテキストデータであっても良い。要は、文書の中に画像や音声、動画、他の文書の所在場所等を埋め込むことができる記述言語で記述されたテキストデータであれば良い。
【００９８】
［変形例１４］
また、上述した実施形態では、ＤＴＥ１１が再開位置情報を算出する際に、既受信部分が画像テキストを有する場合には、既受信部分を記憶した時点の表示階調と未受信部分の取得が要求された時点の表示階調とが一致するか否かの判定を行い（図１３：ステップＳＥ３参照）、一致する場合と一致しない場合とで異なる値を再開位置情報に設定する場合の実施例について説明したが、このような判定を行わずに、再開位置情報の設定を行っても良い。具体的には、ＤＴＥ１１は、既受信部分を記憶した時点の表示階調と未受信部分の取得が要求された時点の表示階調とが一致するか否かにかかわらず、既受信部分の大きさを再開位置情報に設定しても良い。
【００９９】
［変形例１５］
また、上述した実施形態では、ＤＴＥ１１が再開位置情報を算出する際に、既受信部分が画像テキストを有するか否かの判定を行い（図１３：ステップＳＥ１参照）、有する場合と有しない場合とで異なる処理を行って再開位置情報を算出する場合の実施例について説明したが、このような判定を行わずに、再開位置情報の設定を行っても良い。具体的には、ＤＴＥ１１は、既受信部分が画像テキストを有するか否かにかかわらず、既受信部分の大きさを再開位置情報に設定しても良い。
【０１００】
【発明の効果】
本発明によれば、ＷＷＷサーバ１６からＤＴＥ１１へのコンテンツのダウンロードが中断された場合には、ＤＴＥ１１が既受信部分を記憶するために、中断された時点からダウンロードを再開して、未受信部分のみ取得し、ＤＴＥ１１に記憶されている既受信部分とＬＷＰ１５から取得した未受信部分とを結合してコンテンツを取得することが可能となり、コンテンツ全体を再度取得する場合に比べて、短時間にコンテンツを取得できるといった効果を奏する。
【０１０１】
また、本発明によれば、ＬＷＰ１５は、ＤＴＥ１１から送信された既受信部分情報と、ＷＷＷサーバ１６から取得した更新情報とが一致した場合にのみ未受信部分をＤＴＥ１１へ送信するために、ＬＷＰ１５からＤＴＥ１１への結合不能なデータの送信が抑止され、ユーザーの負担する通信コストが削減されるといった効果を奏する。
【図面の簡単な説明】
【図１】 図１は、本発明に係るデータ取得方法を実行する通信システムの全体構成の一例を示す図である。
【図２】 図２は、同システムの動作の概要を示すシーケンス図である。
【図３】 図３は、同システムを構成するＷＷＷサーバ１６に記憶されているテキストデータの要部を示す図である。
【図４】 図４は、同システムを構成するＷＷＷサーバ１６に記憶されている画像データの画像イメージを示す図である。
【図５】 図５は、同システムを構成するＬＷＰ１５からＤＴＥ１１へ送信されるダウンロードデータの一例を示す図ある。
【図６】 図６は、同システムを構成するＬＷＰ１５からＤＴＥ１１へ送信されるダウンロードデータの一例を示す図ある。
【図７】 図７は、同システムを構成するＤＴＥ１１の構成例を示すブロック図である。
【図８】 図８は、同ＤＴＥ１１が実行するプロファイル情報設定処理の流れを示すフローチャートである。
【図９】 図９は、同プロファイル情報設定処理にてＤＴＥ１１の表示部７４に表示されるプロファイル情報設定画面の一例である。
【図１０】 図１０は、同ＤＴＥ１１が実行するコンテンツ取得処理の流れを示すフローチャートである。
【図１１】 図１１は、同ＤＴＥ１１が実行する全体要求処理の流れを示すフローチャートである。
【図１２】 図１２は、同ＤＴＥ１１が実行する未受信部分要求処理の流れを示すフローチャートである。
【図１３】 図１３は、同ＤＴＥ１１が実行する再開位置算出処理の流れを示すフローチャートである。
【図１４】 図１４は、同システムを構成するＬＷＰ１５の構成例を示すブロック図である。
【図１５】 図１５は、同ＬＷＰ１５が実行するコンテンツ代理取得処理の流れを示すフローチャートである。
【図１６】 図１６は、同ＬＷＰ１５が実行する関連データ結合処理の流れを示すフローチャートである。
【図１７】 図１７は、同システムを構成するＷＷＷサーバ１６に記憶されているコンテンツをＤＴＥ１１が解釈表示した場合に、表示部７４に表示される画像の一例を示す図である。
【図１８】 図１８は、同システムの動作の一例を示すシーケンス図である。
【図１９】 図１９は、同システムを構成するＤＴＥ１１のＥＥＰＲＯＭ７６２に記憶されている既受信部分を示す図である。
【図２０】 図２０は、同システムを構成するＤＴＥ１１の表示部７４に表示される画像の一例を示す図である。
【図２１】 図２１は、同システムを構成するＤＴＥ１１の表示部７４に表示される画像の一例を示す図である。
【図２２】 図２２は、［変形例２］に係るＬＷＰ１５が実行するコンテンツ代理取得処理の流れを示すフローチャートである。
【符号の説明】
１１ ＤＴＥ
１２ 移動パケット通信網
１３ ゲートウェイサーバ
１４ インターネット
１５ ＬＷＰ
１６ ＷＷＷサーバ
Claims (8)
- 中継装置が、クライアント装置から要求された第一のデータと該第一のデータに関連付けられた第二のデータとをサーバ装置から取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータを該クライアント装置に送信する送信過程と、
前記クライアント装置が、前記中継装置からのデータ送信が中断された時点までに受信した前記第三のデータの既受信部分を記憶する記憶過程と、
前記クライアント装置が前記既受信部分に基づいて前記第三のデータにおける前記データ送信が中断された位置を示す再開位置情報を算出し、該再開位置情報と前記既受信部分とに基づいて第一の再開判定情報を算出し、該再開位置情報と該第一の再開判定情報とを前記中継装置に送信して前記データ送信の再開を要求する要求過程と、
前記中継装置が前記サーバ装置に格納されている前記第一及び第二のデータを取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータと前記再開位置情報とから第二の再開判定情報を算出し、該第二の再開判定情報と前記第一の再開判定情報とを比較し、両者が一致する場合にのみ、前記データ送信を再開可能と判定する判定過程と、
前記中継装置が、前記判定過程にて前記データ送信を再開可能と判定された場合にのみ前記第三のデータのうち前記クライアント装置が受信していない未受信部分のみを前記クライアント装置に送信する未受信部分送信過程と、
前記クライアント装置が、前記既受信部分と前記未受信部分とを結合して表示する表示過程と
を有することを特徴とするデータ取得方法。 - 前記第一の再開判定情報と前記第二の再開判定情報とは、いずれも同一のハッシュ値生成アルゴリズムで算出されるハッシュ値であることを特徴とする請求項１に記載のデータ取得方法。
- 中継装置が、クライアント装置から要求された第一のデータと該第一のデータに関連付けられた第二のデータとをサーバ装置から取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータを該クライアント装置に送信する送信過程と、
前記クライアント装置が、前記中継装置からのデータ送信が中断された時点までに受信した前記第三のデータの既受信部分を記憶する記憶過程と、
前記クライアント装置が前記既受信部分を第一の再開判定情報として前記中継装置に送信して前記データ送信の再開を要求する要求過程と、
前記中継装置が前記サーバ装置に格納されている前記第一及び第二のデータを取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータの先頭から前記既受信部分の長さで特定される部分を第二の再開判定情報として取得し、該第二の再開判定情報と前記第一の再開判定情報とを比較し、両者が一致する場合にのみ、前記データ送信を再開可能と判定する判定過程と、
前記中継装置が、前記判定過程にて前記データ送信を再開可能と判定された場合にのみ前記第三のデータのうち前記クライアント装置が受信していない未受信部分のみを前記クライアント装置に送信する未受信部分送信過程と、
前記クライアント装置が、前記既受信部分と前記未受信部分とを結合して表示する表示過程と
を有することを特徴とするデータ取得方法。 - クライアント装置から要求された第一のデータと該第一のデータに関連付けられた第二のデータとをサーバ装置から取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータを該クライアント装置に送信する送信手段と、
前記送信手段からのデータ送信が中断された時点までに受信した前記第三のデータの既受信部分を記憶している前記クライアント装置が前記既受信部分に基づいて前記第三のデータにおける前記データ送信が中断された位置を示す再開位置情報を算出し、該再開位置 情報と前記既受信部分とに基づいて第一の再開判定情報を算出し、該再開位置情報と該第一の再開判定情報とを送信して前記データ送信の再開を要求した場合に、前記サーバ装置に格納されている前記第一及び第二のデータを取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータと前記再開位置情報とから第二の再開判定情報を算出し、該第二の再開判定情報と前記第一の再開判定情報とを比較し、両者が一致する場合にのみ、前記データ送信を再開可能と判定する判定手段と、
前記判定手段にて前記データ送信を再開可能と判定された場合にのみ前記第三のデータのうち前記クライアント装置が受信していない未受信部分のみを前記クライアント装置に送信する未受信部分送信手段と
を有することを特徴とする中継装置。 - クライアント装置から要求された第一のデータと該第一のデータに関連付けられた第二のデータとをサーバ装置から取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータを該クライアント装置に送信する送信手段と、
前記送信手段からのデータ送信が中断された時点までに受信した前記第三のデータの既受信部分を記憶している前記クライアント装置が前記既受信部分を第一の再開判定情報として送信して前記データ送信の再開を要求した場合に、前記サーバ装置に格納されている前記第一及び第二のデータを取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータの先頭から前記既受信部分の長さで特定される部分を第二の再開判定情報として取得し、該第二の再開判定情報と前記第一の再開判定情報とを比較し、両者が一致する場合にのみ、前記データ送信を再開可能と判定する判定手段と、
前記判定手段にて前記データ送信を再開可能と判定された場合にのみ前記第三のデータのうち前記クライアント装置が受信していない未受信部分のみを前記クライアント装置に送信する未受信部分送信手段と
を有することを特徴とする中継装置。 - コンピュータ装置を、
クライアント装置から要求された第一のデータと該第一のデータに関連付けられた第二のデータとをサーバ装置から取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータを該クライアント装置に送信する送信手段と、
前記送信手段からのデータ送信が中断された時点までに受信した前記第三のデータの既受信部分を記憶している前記クライアント装置が前記既受信部分に基づいて前記第三のデータにおける前記データ送信が中断された位置を示す再開位置情報を算出し、該再開位置情報と前記既受信部分とに基づいて第一の再開判定情報を算出し、該再開位置情報と該第一の再開判定情報とを送信して前記データ送信の再開を要求した場合に、前記サーバ装置に格納されている前記第一及び第二のデータを取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータと前記再開位置情報とから第二の再開判定情報を算出し、該第二の再開判定情報と前記第一の再開判定情報とを比較し、両者が一致する場合にのみ、前記データ送信を再開可能と判定する判定手段と、
前記判定手段にて前記データ送信を再開可能と判定された場合にのみ前記第三のデータのうち前記クライアント装置が受信していない未受信部分のみを前記クライアント装置に送信する未受信部分送信手段
として機能させるためのプログラム。 - コンピュータ装置を、
クライアント装置から要求された第一のデータと該第一のデータに関連付けられた第二のデータとをサーバ装置から取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータを該クライアント装置に送信する送信手段と、
前記送信手段からのデータ送信が中断された時点までに受信した前記第三のデータの既受信部分を記憶している前記クライアント装置が前記既受信部分を第一の再開判定情報として送信して前記データ送信の再開を要求した場合に、前記サーバ装置に格納されている前記第一及び第二のデータを取得し、該第一及び第二のデータを結合して第三のデータを生成し、該第三のデータの先頭から前記既受信部分の長さで特定される部分を第二の再開 判定情報として取得し、該第二の再開判定情報と前記第一の再開判定情報とを比較し、両者が一致する場合にのみ、前記データ送信を再開可能と判定する判定手段と、
前記判定手段にて前記データ送信を再開可能と判定された場合にのみ前記第三のデータのうち前記クライアント装置が受信していない未受信部分のみを前記クライアント装置に送信する未受信部分送信手段
として機能させるためのプログラム。 - 請求項６または７に記載のプログラムを記録したコンピュータ装置が読み取り可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002056272A JP4176359B2 (ja) | 2002-03-01 | 2002-03-01 | データ取得方法、中継装置、プログラムおよび記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002056272A JP4176359B2 (ja) | 2002-03-01 | 2002-03-01 | データ取得方法、中継装置、プログラムおよび記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003256313A JP2003256313A (ja) | 2003-09-12 |
| JP4176359B2 true JP4176359B2 (ja) | 2008-11-05 |
Family
ID=28666889
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002056272A Expired - Fee Related JP4176359B2 (ja) | 2002-03-01 | 2002-03-01 | データ取得方法、中継装置、プログラムおよび記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4176359B2 (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2014149813A (ja) * | 2013-01-31 | 2014-08-21 | Naver Corp | モバイル端末で大容量のファイルが添付されたメールを送信する方法およびシステム |
| US20210385512A1 (en) * | 2015-06-01 | 2021-12-09 | Comcast Cable Communications, Llc | Transmission of applications with content |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2006110005A1 (en) * | 2005-04-15 | 2006-10-19 | Ktfreetel Co., Ltd. | Method for providing contents for mobile comunication terminal |
| JP2010063037A (ja) * | 2008-09-05 | 2010-03-18 | Riso Kagaku Corp | データ転送システム、データ受信装置および画像形成装置 |
| JP5309085B2 (ja) * | 2010-06-11 | 2013-10-09 | 株式会社ジェイ・ジー・エス・オー | 印刷プログラムおよび印刷方法 |
| JP6102627B2 (ja) * | 2013-08-09 | 2017-03-29 | ブラザー工業株式会社 | 中継装置、画像処理装置、中継方法、プログラム、及びシステム |
| JP2016541048A (ja) * | 2013-10-28 | 2016-12-28 | 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． | サービスプロキシを使用してデータを転送する方法、デバイスおよびシステム |
| US9665432B2 (en) | 2014-08-07 | 2017-05-30 | Microsoft Technology Licensing, Llc | Safe data access following storage failure |
| US9847918B2 (en) | 2014-08-12 | 2017-12-19 | Microsoft Technology Licensing, Llc | Distributed workload reassignment following communication failure |
| JP6138178B2 (ja) * | 2015-01-23 | 2017-05-31 | 三菱電機ビルテクノサービス株式会社 | 中継装置、データ通信システム及びプログラム |
-
2002
- 2002-03-01 JP JP2002056272A patent/JP4176359B2/ja not_active Expired - Fee Related
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2014149813A (ja) * | 2013-01-31 | 2014-08-21 | Naver Corp | モバイル端末で大容量のファイルが添付されたメールを送信する方法およびシステム |
| US20210385512A1 (en) * | 2015-06-01 | 2021-12-09 | Comcast Cable Communications, Llc | Transmission of applications with content |
| US11595705B2 (en) * | 2015-06-01 | 2023-02-28 | Comcast Cable Communications, Llc | Transmission of applications with content |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003256313A (ja) | 2003-09-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6396805B2 (en) | System for recovering from disruption of a data transfer | |
| Housel et al. | WebExpress: A client/intercept based system for optimizing Web browsing in a wireless environment | |
| JP4079288B2 (ja) | ネットワーク経由でソフトウェアを自動的にアップグレードする方法、そのシステム及びその記憶媒体 | |
| JP4176359B2 (ja) | データ取得方法、中継装置、プログラムおよび記録媒体 | |
| JP2000099463A (ja) | デ―タネットワ―クの二方向対話通信装置用の中心化されたサ―ビス管理システム | |
| JP2008097201A (ja) | ブラウザデータ共有システム、サーバ、方法およびプログラム | |
| US20050278717A1 (en) | Mobile communication terminal and application control method | |
| JP4839715B2 (ja) | シンクライアントシステム | |
| JPH09214708A (ja) | ファクシミリ装置 | |
| JP2003529974A (ja) | 機器を制御するシステム及び方法 | |
| JP2007529051A (ja) | 異なるプラットホームにおいてフォントサイズを維持するための方法及びシステム | |
| JP2002372543A (ja) | 分析装置の管理システム及び管理方法 | |
| JP2010015432A (ja) | サーバ装置、サーバベース・コンピューティング・システム、およびサーバ制御プログラム | |
| US20050038864A1 (en) | Methodology for performing caching procedures in an electronic network | |
| JP2008067311A (ja) | 移動通信端末及びダウンロード再開制御方法 | |
| JP2005032151A (ja) | 端末属性情報提供システム | |
| JP2002351677A (ja) | アプリケーション・プログラム実行順序制御システム | |
| JP2003348152A (ja) | 情報送出装置および情報送出方法 | |
| JP3984099B2 (ja) | 携帯端末 | |
| JP2005107662A (ja) | Ｗｗｗシステム処理方法およびシステム | |
| JP5205789B2 (ja) | データ処理システム、デーモンプログラム、およびコンピュータ起動方法 | |
| JP2008015658A (ja) | アプリケーション提供システム及びアプリケーション提供方法 | |
| JP2010055493A (ja) | サーバ装置、サーバベース・コンピューティング・システム、およびサーバ制御プログラム | |
| JP2004362266A (ja) | 遠隔制御方法、サーバ装置及び仮想マシンプログラム | |
| KR20010097304A (ko) | 무선인터넷을 지원하는 모바일폰상에서 정보를다운로드하는 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041005 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070320 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070521 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070612 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070810 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080819 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080820 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110829 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110829 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120829 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120829 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130829 Year of fee payment: 5 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |