(57)【要約】【課題】  コンテンツのダウンロードの途中で通信ネットワークの通信状況の悪化が発生した場合、コンテンツのデータの一部欠落の発生を回避しつつ、コンテンツの全体のデータを取得するための無駄な通信を抑制することができる移動体通信端末を提供する。【解決手段】  本移動体通信端末（携帯電話機１０）は、コンテンツ取得要求送信手段１１０とコンテンツ取得応答受信手段１１１とデータサイズ判断手段１１３とデータ再取得手段１１２とを備える。データサイズ判断手段１１３は、コンテンツ取得応答に続いてコンテンツ提供サーバから送信された切断要求を受信したときに、コンテンツ取得応答の受信データサイズと送信データサイズとが一致しているか否かを判断する。データ再取得手段１１２は、受信データサイズと送信データサイズとが一致していないとき、コンテンツ提供サーバから受信できていないデータセグメントを再取得する。【選択図】  図７
2006114967.tif 000002
【特許請求の範囲】
【請求項１】
所定の通信プロトコルを用いた通信により通信ネットワーク上のコンテンツ提供サーバからコンテンツをダウンロード可能な移動体通信端末であって、
コンテンツの取得を要求するコンテンツ取得要求を上記コンテンツ提供サーバに送信するコンテンツ取得要求送信手段と、
上記コンテンツが分割された複数のデータセグメントを含むコンテンツ取得応答を上記コンテンツ提供サーバから受信するコンテンツ取得応答受信手段と、
上記コンテンツ取得応答に続いて上記コンテンツ提供サーバから送信された切断要求を受信したときに、上記受信した各データセグメントのデータサイズを合算した受信データサイズと上記コンテンツ取得応答のヘッダーに記述された送信データサイズとが一致しているか否かを判断するデータサイズ判断手段と、
上記受信データサイズと上記送信データサイズとが一致していないとき、上記コンテンツ提供サーバから受信できていないデータセグメントを再取得するデータ再取得手段と
を備えたことを特徴とする移動体通信端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、携帯電話通信網等の通信ネットワークを介して通信可能な携帯電話機等の移動体通信端末に関する。
【背景技術】
【０００２】
従来、この種の携帯電話機などの移動体通信端末において通信ネットワーク上のサーバからコンテンツをダウンロードする方法としては、次のようなＨＴＴＰ等の通信プロトコルを使った通信シーケンスを実行するＨＴＴＰ通信を利用した方法が広く知られている。すなわち、移動体通信端末に表示されているＷＷＷページ上にあるアンカー設定済みの文字列や絵文字を利用者が選択すると、移動体通信端末は、そのアンカーで指定されたコンテンツ提供サーバに、ＨＴＴＰリクエスト等のコンテンツ取得要求を送信する。コンテンツ提供サーバは、上記コンテンツ取得要求に応答するように、コンテンツを含むＨＴＴＰレスポンス等のコンテンツ取得応答を移動体通信端末に送信する。これらのコンテンツ取得要求及びコンテンツ取得応答は例えばＴＣＰ（Transmission Control Protocol）を使って送受信され、コンテンツを含むコンテンツ取得応答はデータサイズが大きいため、複数のデータセグメントに分割される。上記コンテンツ取得応答を受信した移動体通信端末では、コンテンツ取得応答に含まれるコンテンツのデータを展開して表示したり所定のフォルダーに保存したりすることができる。
【０００３】
また、最近では、所望のコンテンツを確実にダウンロードできるように、移動体通信端末と通信ネットワーク上のサーバとの間で複数回送受信する通信シーケンスを実行する方法が採用する場合がある（非特許文献１参照）。この方法は、モバイル通信関連の業界団体であるＯＭＡ（Open Mobile Alliance）で標準化された方法である（以下、この方法を「ＯＭＡ方式のコンテンツ提供方法」という）。このＯＭＡ方式のコンテンツ提供方法では、上記通常のＨＴＴＰ通信を利用した方法とは異なり、まずコンテンツのダウンロードに先立って、ダウンロード対象のコンテンツに関するダウンロード情報を含むダウンロード記述子ファイルを、通信ネットワーク上のサーバから取得する。このダウンロード情報は、ダウンロード対象のコンテンツが登録されているＵＲＩ（Uniform Resource Identifier）やコンテンツの種別及びサイズなど情報である。次に、上記ダウンロード情報を利用者が確認し、移動体通信端末を操作してダウンロードを承諾するか否かを入力する。利用者がダウンロードを承諾すると、移動体通信端末は、上記ダウンロード情報のＵＲＩで指定されたコンテンツ提供サーバに、利用者がダウンロードを承諾したコンテンツについて、ＨＴＴＰ等の通信プロトコルによるコンテンツ取得要求を送信する。コンテンツ提供サーバは、上記コンテンツ取得要求に応答するように、コンテンツを含むコンテンツ取得応答を移動体通信端末に送信する。
【非特許文献１】"Generic Content Download Over The Air Specification Version 1.0 Proposed Version 20-June-2002", Open Mobile Alliance, OMA - Download - OTA - v1_0 - 20020620 - p.
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところが、上記通常のＨＴＴＰ通信やＯＭＡ方式の通信を用いたコンテンツ提供方法において、通信ネットワークの通信状況の悪化により、上記コンテンツ提供サーバが次のように上記複数のデータセグメントの送信中に移動体通信端末とのセッションを強制的に切断する場合があった。コンテンツ提供サーバは、データセグメントの送信時に監視タイマーをスタートし、この監視タイマーが切れる前（タイムアウトが発生する前）に移動体通信端末から受信確認信号（ＡＣＫ信号）を受信したら、次のデータセグメントを送信する。一方、通信状況の悪化により、移動体通信端末がコンテンツ提供サーバからのデータセグメントを受信することができない場合、コンテンツ提供サーバは、監視タイマーが切れる前に移動体通信端末から受信確認信号（ＡＣＫ信号）を受信しないことになる。このように監視タイマーが切れる前に受信確認信号（ＡＣＫ信号）を受信しないとき、コンテンツ提供サーバは、移動体通信端末に切断要求（ＦＩＮ）を送信し、移動体通信端末とのセッションを強制的に切断する。あるいは、上記監視タイマーが切れる前に受信確認信号（ＡＣＫ信号）を受信しないとき、コンテンツ提供サーバは、受信確認信号（ＡＣＫ信号）を受信できなかったデータセグメントを再送する。このデータセグメントの再送を所定回数繰り返したとき、コンテンツ提供サーバは、移動体通信端末に切断要求（ＦＩＮ）を送信し、移動体通信端末とのセッションを強制的に切断する。
【０００５】
移動体通信端末は、上記切断要求（ＦＩＮ）を受信すると、データセグメントの送信が途中で中断されていにもかかわらず、コンテンツを構成するすべてのデータセグメントを正常に受信できたと誤認識し、データセグメントの連結処理を実行する。しかしながら、データセグメントの一部が欠落しているため、移動体通信端末は、データセグメントの連結処理を行っても完全なコンテンツのデータを生成することができず、そのコンテンツをアプリケーションで使用するとエラーになってしまう。そのため、利用者は、移動体通信端末を操作して上記コンテンツの全体を最初から再取得する処理を実行することになり、無駄な通信が発生してしまうという問題があった。
【０００６】
本発明の目的は、コンテンツのダウンロードの途中で通信ネットワークの通信状況の悪化が発生した場合、コンテンツのデータの一部欠落の発生を回避しつつ、コンテンツの全体のデータを取得するための無駄な通信を抑制することができる移動体通信端末を提供することである。
【課題を解決するための手段】
【０００７】
上記目的を達成するために、請求項１の発明は、所定の通信プロトコルを用いた通信により通信ネットワーク上のコンテンツ提供サーバからコンテンツをダウンロード可能な移動体通信端末であって、コンテンツの取得を要求するコンテンツ取得要求を上記コンテンツ提供サーバに送信するコンテンツ取得要求送信手段と、上記コンテンツが分割された複数のデータセグメントを含むコンテンツ取得応答を上記コンテンツ提供サーバから受信するコンテンツ取得応答受信手段と、上記コンテンツ取得応答に続いて上記コンテンツ提供サーバから送信された切断要求を受信したときに、上記受信した各データセグメントのデータサイズを合算した受信データサイズと上記コンテンツ取得応答のヘッダーに記述された送信データサイズとが一致しているか否かを判断するデータサイズ判断手段と、上記受信データサイズと上記送信データサイズとが一致していないとき、上記コンテンツ提供サーバから受信できていないデータセグメントを再取得するデータ再取得手段とを備えたことを特徴とするものである。
【０００８】
また、上記「コンテンツ」としては、ＷＥＢページのデータのほか、画像ファイル、音楽ファイル、プログラムファイル等の各種ファイル、及び画像や音楽などのストリーミングデータが挙げられる。
また、上記「移動体通信端末」としては、ＰＤＣ（Personal Digital Cellular）方式、ＧＳＭ（Global System for Mobile Communication）方式、ＴＩＡ（Telecommunications Industry Association）方式等の携帯電話機、ＩＭＴ（International Mobile Telecommunications）−２０００で標準化された携帯電話機、ＴＤ−ＳＣＤＭＡ（Time Division Synchronous Code Division Multiple Access）方式の一つであるＴＤ−ＳＣＤＭＡ（ＭＣ：Multi Carrier）方式の携帯電話機、ＰＨＳ（Personal Handyphone System）、自動車電話機等の通話機能を有する電話機が挙げられる。また、この「移動体通信端末」としては、上記電話機のほか、通話機能を有するＰＤＡ（Personal Digital Assistance）等の通信端末も挙げられる。
また、上記移動体通信端末における制御や情報処理は、その移動体通信端末に設けられたコンピュータで所定のプログラムを実行することによって実現することもできる。このコンピュータで用いるプログラムの受け渡しは、デジタル情報としてプログラムを記録したＦＤ，ＣＤ−ＲＯＭ等の記録媒体を用いて行なってもいいし、コンピュータネットワーク等の通信ネットワークを用いて行なってもよい。
【発明の効果】
【０００９】
本発明によれば、コンテンツ提供サーバから送信された切断要求を受信したときに、コンテンツ取得応答で受信できたデータセグメントのデータサイズを合算した受信データサイズと、コンテンツ取得応答のヘッダーに記述された送信データサイズとが一致しているか否かを判断する。ここで、コンテンツのダウンロードの途中で通信ネットワークの通信状況の悪化が発生したことにより、上記受信データサイズと送信データサイズとが一致していないとき、コンテンツのダウンロードが完結していないと判断する。この判断に基づき、コンテンツ提供サーバから受信できていないデータセグメントの部分を再取得することにより、コンテンツのデータの一部欠落の発生を回避することができる。しかも、上記コンテンツのデータの再取得を、コンテンツ提供サーバから受信できていないデータセグメントについてのみ行っているので、コンテンツの全体を再取得する場合に比して、コンテンツの全体のデータを取得するための無駄な通信を抑制することができるという効果がある。
【発明を実施するための最良の形態】
【００１０】
以下、図面を参照して本発明の実施の形態について説明する。
図１は本実施形態に係る通信システム全体の概略構成の一例を示す説明図である。この通信システムは、移動体通信端末としての携帯電話機１０と、通信ネットワークとしての携帯電話通信網２０とを用いて構成されている。携帯電話通信網２０は、基地局２１０と、コアネットワーク２２と、ＩＰ（Internet Protocol）ネットワーク２３とを備えている。
【００１１】
上記基地局２１０は、管轄対象のセルごとに設けられ、携帯電話通信網２０内の有線回線からのデータを無線インタフェースに合うデータフォーマットに変換し、管轄対象のセル内にある携帯電話機１０に無線周波数で送信する。逆に無線周波数で送信される携帯電話機１０からのデータを受信して有線インタフェースに合うデータフォーマットに変換し、携帯電話通信網２０内の有線回線部分に転送する。
【００１２】
上記コアネットワーク２２は、図示しない位置登録データベース（ＨＬＲ，ＶＬＲ）、加入者データベース、課金システム等を有し、各携帯電話機間の通信等を中継するように通信制御を行う。更に、コアネットワーク２２は、各携帯電話機と、携帯電話通信網２０内の構成要素との間における通信を中継するように通信制御を行う。また、コアネットワーク２２は、各携帯電話機と他の通信ネットワークとの間における通信を中継するように通信制御を行う。
【００１３】
また、上記コアネットワーク２２は、回線交換網のほかパケット交換網を有している。このパケット交換網は、ＳＧＳＮ（Serving GPRS Support Node）２４やＧＧＳＮ（Gateway GPRS Support Node）２５等のノードを有している。ＳＧＳＮ２４は、基地局２１が接続されている図示しない無線ネットワークコントローラとコアネットワーク２２側のパケット交換網との間のゲートウェイ機能と、各携帯電話機１０の位置管理、セキュリティ管理及びアクセス制御を行う機能とを有している。また、ＧＧＳＮ２５は、コアネットワーク２２側のパケット交換網と、ＩＰネットワーク２３との間のゲートウェイ機能を有している。
【００１４】
上記ＩＰネットワーク２３は、プロキシサーバ２６、ゲートウェイサーバ２７、その他図示しないＷＥＢサーバ等を有している。プロキシサーバ２６は、各携帯電話機１０と、ＩＰネットワーク２３内のサーバやインターネット上のサーバとの間の通信を中継する処理を行う。このプロキシサーバ２６は、コアネットワーク２２における通信プロトコルとＩＰネットワーク２３やインターネット３０等の他の通信ネットワークにおける通信プロトコルが異なる場合に、両通信プロトコルを合わせるためのプロトコル変換機能も有している。
なお、このＩＰネットワーク２３の中に、ＷＥＢサーバや、コンテンツをダウンロードするためのダウンロードサーバを設けてもよい。
【００１５】
上記ゲートウェイサーバ２７は、携帯電話通信網２０のＩＰネットワーク２３とインターネット３０との間のゲートウェイ機能とファイヤウォール機能とを有している。
【００１６】
上記携帯電話通信網２０のＩＰネットワーク２３を介して接続されているインターネット３０には、各種コンテンツ提供サーバが接続されている。このコンテンツ提供サーバとしては、ＷＥＢページを提供するＷＥＢサーバ４０や、画像ファイル、音楽ファイル、プログラムファイルなどのコンテンツを主に提供するダウンロードサーバ５０等がある。なお、このＷＥＢサーバ４０やダウンロードサーバ５０は、携帯電話通信網２０のＩＰネットワーク２３内に配置しておいてもよい。
【００１７】
上記インターネット３０上の各種コンテンツ提供サーバから携帯電話機１０にコンテンツをダウンロードするときには、ネットワークの各階層において所定の通信プロトコルが用いられる。例えば、ＷＥＢサーバ４０からＷＥＢページをダウンロードするときのアプリケーション層の通信プロトコルとしては、ＨＴＴＰ（HyperText Transfer Protocol）、Ｗ−ＨＴＴＰ（Wireless HyperText Transfer Protocol）、ＷＴＰ(Wireless Transaction Protocol)、ＷＳＰ（Wireless Session Protocol）等が用いられる。
【００１８】
図２は、上記ダウンロードサーバ５０のハードウェア構成の一例を示すブロック図である。なお、上記ＷＥＢサーバ４０も同様に構成することができる。
このダウンロードサーバ５０は、システムバス５００、ＣＰＵ５０１、内部記憶装置、外部記憶装置５０４、入力装置５０５、出力装置５０６、及びインターネット用通信装置５０７を備えている。上記内部記憶装置は、ＲＡＭ５０２やＲＯＭ５０３等で構成されている。上記外部記憶装置は、ハードディスクドライブ（ＨＤＤ）や光ディスクドライブ等で構成されている。上記入力装置５０５は、マウスやキーボード等で構成されている。上記出力装置５０６は、ディスプレイやプリンタ等で構成されている。上記インターネット用通信装置５０７は、所定の通信プロトコルにより、インターネット３０上の各種クライアント端末や他のサーバと通信したり、携帯電話通信網２０上のプロキシサーバ２３と通信したりするための装置である。
【００１９】
上記ＣＰＵ５０１やＲＡＭ５０２等の構成要素はお互いに、システムバス５００を介して、データやプログラムの命令等のやり取りを行っている。このダウンロードサーバ５０を所定の手順に従って動作させるためのプログラムはＲＯＭ５０３や外部記憶装置５０５に記憶されており、必要に応じてＣＰＵ５０１やＲＡＭ５０２上の作業エリアに呼び出されて実行される。
【００２０】
また、上記ダウンロードサーバ５０やＷＥＢサーバ４０等のコンテンツ提供サーバは、一部又は全体を専用の制御装置として構成してもいいし、一部又は全体を汎用のコンピュータシステムを用いて構成してもよい。また、コンテンツ提供サーバは、１台のコンピュータで構成してもいいし、複数の機能をそれぞれ受け持つ複数台のコンピュータをネットワークで結んで構成してもよい。
【００２１】
図３は、本実施形態に係るダウンロードサーバ５０の主要な機能を抽出して示した機能ブロック図である。このダウンロードサーバ５０は、コンテンツ記憶手段５１０とコンテンツ取得要求受信手段５１１とコンテンツ処理手段５１２とコンテンツ取得応答送信手段５１３とを有している。更に、ダウンロードサーバ５０は、ダウンロード情報要求受信手段５１４とダウンロード情報応答送信手段５１５とダウンロード完了通知受信手段５１６とダウンロード完了応答送信手段５１７とを有している。
上記ダウンロードサーバ５０は、ＣＰＵ等からなるハードウェア上で所定のプログラムを実行することにより、上記各手段の機能を実現している。
【００２２】
上記コンテンツ記憶手段５１０は上記内部記憶装置や外部記憶装置で構成され、ダウンロード対象の画像ファイル、音楽ファイル、プログラムファイル等のオブジェクトからなるコンテンツを記憶している。
【００２３】
上記コンテンツ取得要求受信手段５１１は上記インターネット用通信装置５０７等で構成され、所定の通信プロトコルを使って携帯電話機１０から送信されたコンテンツ取得要求を受信する。例えば、利用者が指定したコンテンツを取得すべく携帯電話機１０から送信されてきたＨＴＴＰ要求を受信する。
なお、このコンテンツ取得要求受信手段５１１は携帯電話機１０からコンテンツ再取得要求（ＨＴＴＰ要求）を受信するコンテンツ再取得要求受信手段として兼用されている。このコンテンツ再取得要求（ＨＴＴＰ要求）のヘッダーには、再取得対象のデータセグメントを特定するためのデータを記述する「Range」フィールドが設けられている。
【００２４】
上記コンテンツ処理手段５１２は上記ＣＰＵ５０１等で構成され、上記携帯電話機１０から受信したコンテンツ取得要求に基づいてコンテンツ記憶手段（データベース）５１０を参照し、上記コンテンツ取得要求で要求するコンテンツのオブジェクトを含むようにコンテンツ取得応答を生成する。このコンテンツ取得応答は、コンテンツ全体のデータサイズが大きい場合、複数のデータセグメントに分割されて生成される。
【００２５】
上記コンテンツ取得応答送信手段５１３は上記インターネット用通信装置５０７等で構成され、インターネット３０及び携帯電話通信網２０を介して、コンテンツ記憶手段５１０から読み出したコンテンツのオブジェクトを含むコンテンツ取得応答を、所定の通信プロトコルを使って携帯電話機１０に送信する。例えば、コンテンツのオブジェクトのデータを分割した複数のデータセグメント（エンティティ）からなるＨＴＴＰ応答を携帯電話機１０に送信する。このＨＴＴＰ応答のヘッダーの「Content-Length」フィールドには、送信対象のコンテンツ全体のデータサイズの値（単位：バイト）が記述される。
なお、このコンテンツ取得応答送信手段５１３は、上記コンテンツ再取得要求に対応するコンテンツの一部データを含むコンテンツ再取得応答（ＨＴＴＰ応答）を携帯電話機１０に送信するコンテンツ再取得応答送信手段として兼用されている。
【００２６】
上記ダウンロード情報要求受信手段５１４は上記インターネット用通信装置５０７等で構成され、所定の通信プロトコル（例えば、Ｗ−ＨＴＴＰ）を使って携帯電話機１０から送信されたダウンロード情報要求を受信する。このダウンロード情報要求で要求するダウンロード情報は、ダウンロード記述子（ＤＤ：Download Descriptor）とも呼ばれ、ダウンロード対象のコンテンツオブジェクトのＵＲＩ（objectURI）、そのコンテンツのタイプ及びサイズ等のコンテンツの属性情報、ダウンロード確認時の利用者へのメッセージ情報（Description）、ダウンロード確認通知のＵＲＩ（InstallNotifyURI）等が含まれる。
【００２７】
上記ダウンロード情報応答送信手段５１５は、上記インターネット用通信装置５０７等で構成され、インターネット３０及び携帯電話通信網２０を介して、上記ダウンロード情報を含むダウンロード情報応答を所定の通信プロトコルを使って携帯電話機１０に送信する。例えば、上記ダウンロード情報を含むＨＴＴＰ応答を携帯電話機１０に送信する。
【００２８】
上記ダウンロード完了通知受信手段５１６は上記インターネット用通信装置５０７等で構成され、上記コンテンツのダウンロードが完了した携帯電話機１０から所定の通信プロトコルを使って送信されたダウンロード完了通知を受信する。
【００２９】
上記ダウンロード完了応答送信手段５１７は上記インターネット用通信装置５０７等で構成され、上記ダウンロード完了通知を確かに受信した旨を示すダウンロード完了応答を所定の通信プロトコルを使って携帯電話機１０に送信する。
【００３０】
図４は携帯電話機１０の一構成例を示す外観図であり、図５は、その携帯電話機１０のハードウェア構成を示す概略構成図である。また、図６は、携帯電話機１０におけるソフトウェア構造の説明図である。
この携帯電話機１０は、クラムシェル（折り畳み）タイプの携帯電話機であり、システムバス１００、ＣＰＵ１０１、ＲＡＭ１０２やＲＯＭ１０３等の記憶装置、入力装置１０４、出力装置１０５、携帯電話通信網用通信装置１０６を備えている。ＣＰＵ１０１やＲＡＭ１０２等の構成要素は、システムバス１００を介して、互いに各種データやプログラムの命令等のやり取りを行っている。
【００３１】
上記ＣＰＵ１０１は、上記記憶装置から所定のプログラムを読み込んで実行することにより、ネイティブ側の電話機プラットフォームの基本ソフトＯＳ上で、音声通話機能や、アプリケーションソフト（以下「アプリケーション」という。）による各種機能を実現することができる。このアプリケーションによる機能としては、ＷＥＢブラウザー、メーラー、音楽再生、動画表示、外部装置とのデータ送受信、アドレス帳管理、スケジューラ、メモ帳等がある。
【００３２】
また、上記ＣＰＵ１０１は、上記記憶装置から所定のプログラムを読み込んで実行することにより、上記ネイティブ側の電話機プラットフォームとは異なるアプリケーション実行環境を構築することができる。そして、このアプリケーション実行環境上で、携帯電話機にプリインストールされているアプリケーションや利用者がダウンロードして登録したアプリケーション等の各種アプリケーションを実行することができる。このアプリケーションとしては、プラットフォームに依存しないオブジェクト指向プログラミングによって開発されたＪＡＶＡ（登録商標）、Ｃ＋＋等のプログラム言語で記述されたアプリケーションや、Ｃ言語やアセンブリ言語で記述されたアプリケーションなどが挙げられる。また、これらのアプリケーション実行環境は、例えばＪＡＶＡ（登録商標）の仮想マシン（ＶＭ：Virtual Machine）やＢＲＥＷ（登録商標）等のミドルウェアによって構築される。
【００３３】
上記入力装置１０４は、データ入力キー（テンキー、＊キー、＃キー）１１、通話開始キー１２、終話キー１３、スクロールキー１４、多機能キー１５、マイク１６等から構成されている。この入力装置１０４のテンキー１１、通話開始キー１２、終話キー１３等により、利用者が操作可能な操作部が構成される。この操作部を操作することにより、利用者は、携帯電話機１０に対してコンテンツ取得先のＵＲＬ等のデータを入力したり、電話着信の際に通話の開始及び終了を行ったり、アプリケーションプログラムの選択、起動及び停止を行ったりすることができる。また、利用者は上記操作部を操作することにより、上記ダウンロードサーバ５０から画像ファイル、音楽ファイル、アプリケーションプログラム等のコンテンツをダウンロードして登録することができる。また、利用者は上記操作部を操作することにより、登録した画像ファイルを展開して表示したり、音楽ファイルを展開して再生したり、アプリケーションプログラムを選択して実行したりすることができる。また、利用者は上記操作部を操作することにより、携帯電話通信網２０の図示しない情報配信サーバから受信した情報を表示することもできる。
【００３４】
上記出力装置１０５は、表示手段である液晶ディスプレイ（ＬＣＤ）１７、スピーカ１８、図示しない振動デバイス等から構成されている。上記液晶ディスプレイ（ＬＣＤ）１７やスピーカ１８等からなる出力装置等で構成されている出力部は、携帯電話通信網２０を介して受信したＷｅｂページを液晶ディスプレイ（ＬＣＤ）１７に表示したり、携帯電話通信網２０から情報を着信した旨を利用者に知らせたりするときに用いられる。具体的には、その情報を着信すると、出力部の液晶ディスプレイ（ＬＣＤ）１７に着信報知画像を表示したり、スピーカ１８から着信音を出力させたりする。また、この出力部は、上記ゲーム等のアプリケーションプログラムの実行中に、そのプログラム実行に関連した画像の表示や音の出力に用いたり、情報配信サーバから受信した情報を表示したりするときにも用いられる。
なお、上記スピーカ１８は、通話中の音声を聞くための受話器用スピーカ（レシーバ）と、着信音や音楽などを出力する外部出力用スピーカとを別々に設けて構成してもいいし、これらの受話器用スピーカ及び外部出力用スピーカを兼用するように一つのスピーカで構成してもよい。
【００３５】
上記出力装置１０５を構成する振動デバイスは、この振動デバイスは、マナーモード（サイレントモード）設定時などに音声電話を着信したりメールや各種配信情報を受信したりしたときに、携帯電話機１０の全体を振動させ、その着信等を利用者に知らせるように制御することができる。また、この振動デバイスは、上記ゲーム等のアプリケーションプログラムの実行中に、そのプログラム実行に関連した振動を携帯電話機１０の全体に発生させるように制御することができる。
【００３６】
上記携帯電話通信網用通信装置１０６は、変復調器、シンセサイザ、周波数変換器，高周波増幅器などにより構成され、携帯電話通信網２０を介して他の携帯電話機や上述したサーバ１１等と通信するときに用いられる。この携帯電話通信網用通信装置１０６は、携帯電話通信網２０を介して他の携帯電話機とメールのやり取りを行ったり、携帯電話通信網２０からゲートウェイサーバを介して、インターネット等の外部の通信ネットワークに接続し、インターネット上での電子メールのやり取り等を行ったりするための通信手段として用いられる。更に、この携帯電話通信網用通信装置１０６は、携帯電話通信網１０を介して、ダウンロードサーバ５０が提供するアプリケーションプログラムをダウンロードしたり、現在位置の位置情報を含む配信情報を受信したりする情報受信手段としても用いられる。
【００３７】
図７は、本実施形態に係る携帯電話機１０の主要な機能を抽出して示した機能ブロック図である。この携帯電話機１０は、コンテンツ取得要求送信手段１１０とコンテンツ取得応答受信手段１１１とデータサイズ判断手段１１３とを有している。更に、携帯電話機１０は、ダウンロード情報要求送信手段１１４とダウンロード情報受信手段１１５とダウンロード完了通知送信手段１１６とダウンロード完了応答受信手段１１７とコンテンツ記憶手段１１８とを有している。
【００３８】
上記コンテンツ取得要求送信手段１１０は上記携帯電話通信網用通信装置１０６等で構成され、所定の通信プロトコルを使ってコンテンツの取得を要求するコンテンツ取得要求をダウンロードサーバ５０に送信する。このコンテンツ取得要求送信手段１１０は、１回のコンテンツデータ取得動作によってコンテンツのデータの全部を受信できなかった場合に、その受信できなかったデータセグメントについてコンテンツ再取得要求を送信するコンテンツ再取得要求受信手段として兼用されている。
【００３９】
上記コンテンツ取得応答受信手段１１１は、上記携帯電話通信網用通信装置１０６等で構成され、所定の通信プロトコルを使ってダウンロードサーバ５０から送信されたコンテンツを含むコンテンツ取得応答を受信する。このコンテンツ取得応答受信手段１１１は、上記コンテンツ再取得要求に対してダウンロードサーバ５０から送信される不足データセグメントを含むコンテンツ再取得応答を受信するコンテンツ再取得応答送信手段として兼用されている。
【００４０】
これらのコンテンツ取得要求送信手段（コンテンツ再取得要求受信手段）１１０及びコンテンツ取得応答受信手段（コンテンツ再取得応答送信手段）１１１によりデータ再取得手段１１２が構成される。このデータ再取得手段１１２は、１回のコンテンツデータ取得動作によってコンテンツのデータの全部を受信できなかった場合に、ダウンロードサーバ５０から受信できなかったデータセグメントを再取得する。
【００４１】
上記データサイズ判断手段１１３は上記ＣＰＵ１０１等で構成され、ダウンロードサーバ５０から送信された送信データサイズと、実際に受信することができたデータセグメント全体の受信データサイズとが一致しているか否かを判断する。このデータサイズ判断手段１１３は、ダウンロードした複数のデータセグメントを連結して一つのコンテンツのデータを生成したり、生成したコンテンツのデータをコンテンツ記憶手段１１８に保存したり、コンテンツのデータ展開処理してディスプレイ１７などに出力したりするコンテンツデータ処理手段として兼用されている。
【００４２】
上記ダウンロード情報要求送信手段１１４は上記携帯電話通信網用通信装置１０６等で構成され、所定の通信プロトコルを使ってダウンロードサーバ５０にダウンロード情報要求を送信する。前述のように、このダウンロード情報要求で要求するダウンロード情報は、ダウンロード対象のコンテンツオブジェクトのＵＲＩ（objectURI）、そのコンテンツのタイプ及びサイズ等のコンテンツの属性情報、ダウンロード確認時の利用者へのメッセージ情報（Description）、ダウンロード確認通知のＵＲＩ（InstallNotifyURI）等の情報である。
【００４３】
上記ダウンロード情報応答受信手段１１５は上記携帯電話通信網用通信装置１０６等で構成され、所定の通信プロトコルを使ってダウンロードサーバ５０から送信されたダウンロード情報を含むダウンロード情報応答を受信する。
【００４４】
上記ダウンロード完了通知送信手段１１６は上記携帯電話通信網用通信装置１０６等で構成され、上記コンテンツのダウンロードが完了した後、所定の通信プロトコルを使ってダウンロードサーバ５０にダウンロード完了通知（InstallNotify）を送信する。
【００４５】
上記ダウンロード完了応答受信手段１１７は上記携帯電話通信網用通信装置１０６等で構成され、上記ダウンロード完了通知に対してダウンロードサーバ５０から送信されたダウンロード完了応答を、所定の通信プロトコルを使って受信する。
【００４６】
上記コンテンツ記憶手段１１８は上記ＲＡＭ１０２やＲＯＭ１０３等で構成され、画像、音楽、アプリケーションプログラムなどの各種コンテンツのデータを記憶する。
【００４７】
図８は、上記構成の携帯電話機１０において音楽コンテンツをダウンロードするときの携帯電話機１０とサーバ４０，５０との間の通信手順の一例を示すシーケンス図である。なお、本例における音楽コンテンツのダウンロード手順は、前述のＯＭＡ方式のダウンロード手順を採用している。また、本例は、コンテンツのダウンロード時にＨＴＴＰ応答を構成する３つのデータセグメントの一つが通信エラーなどで欠落し、その欠落したデータセグメントを再取得する場合について示している。
【００４８】
まず、利用者は、携帯電話機１０を操作してブラウザのアプリケーションを起動し、ＷＥＢサーバ４０の音楽試聴のコンテンツ紹介サイトにアクセスする（ステップＳ１〜Ｓ３）。このアクセスにより、携帯電話機１０のディスプレイ１７の画面１７ａには、図９（ａ）に示す音楽コンテンツ紹介のＷＥＢページが表示される（ステップＳ４）。
【００４９】
次に、利用者は、ディプレイ１７の画面１７ａに表示された音楽コンテンツ紹介のページを確認し、試聴を希望する音楽コンテンツのタイトルを選択するように所定のキー操作を行う（ステップＳ５）。携帯電話機１０は、このキー操作を受付けると、ダウンロード情報取得要求としてのＨＴＴＰ要求を、ダウンロードサーバ５０に送信する（ステップＳ６）。
【００５０】
上記ＨＴＴＰ要求を受信したダウンロードサーバ５０は、上記利用者が希望するコンテンツのダウンロードに関するダウンロード情報（ObjectURI、ファイルタイプ、ファイルサイズ等の情報）をコンテンツ記憶手段（コンテンツデータベース）から読み出す（ステップＳ７）。そして、このダウンロード情報を含むダウンロード情報応答としてのＨＴＴＰ応答を生成し、携帯電話機１０に送信する（ステップＳ８）。
【００５１】
次に、携帯電話機１０は、上記ＨＴＴＰ応答を受信すると、ディスプレイ１７の画面に、図９（ｂ）に示すように上記ダウンロード情報に基づいて作成したダウンロード確認画面を表示する（ステップＳ９）。利用者は、ダウンロード確認画面の内容を確認し、ダウンロードＯＫのキー操作を行う。具体的には、ダウンロード確認画面の下側にある「ＹＥＳ」キーを選択する操作を行う。このキー操作を受け付けた携帯電話機１０は、ダウンロードサーバ５０に、上記利用者が希望するコンテンツをダウンロードするためのコンテンツ取得要求としてのＨＴＴＰ要求を送信する（ステップＳ１０、Ｓ１１）。このＨＴＴＰ要求が送信されると、携帯電話機１０のディスプレイ１７には、図９（ｃ）に示すように、ダウンロード中である旨を示すメッセージと、ダウンロードの進捗状況を示すバー表示とが表示される。
【００５２】
上記ＨＴＴＰ要求を受信したダウンロードサーバ５０は、上記利用者が希望するコンテンツをコンテンツ記憶手段（コンテンツデータベース）から読み出す（ステップＳ１２）。次に、ダウンロードサーバ５０は、上記コンテンツを含むＨＴＴＰ応答を携帯電話機１０に送信し、ＨＴＴＰ応答の送信が完了したら、携帯電話機１０との接続を切断するための接続要求としてのＦＩＮメッセージを送信する（ステップＳ１３）。
【００５３】
次に、携帯電話機１０は、上記ＨＴＴＰ応答を受信すると、ＨＴＴＰ応答に含まれているコンテンツのデータサイズを確認する（ステップＳ１４）。具体的には、ＨＴＴＰ応答に含まれているコンテンツの受信データサイズと、ＨＴＴＰ応答のヘッダーの「Content-Length」フィールドの値として記述されているコンテンツの送信データサイズとが一致しているか否かを確認する。本例では、後述のようにＨＴＴＰ応答を構成する複数のデータセグメントの一つが欠落しているため、上記コンテンツの受信データサイズが送信データサイズよりも小さいと判断し、次のように欠落したデータセグメントについて再取得動作（Byte Range Operation）を実行する。この再取得動作（Byte Range Operation）はＲＦＣ２６１６に規定されている手順に準拠して行われる（ＲＦＣ２６１６の段落１４．３５及び１３．５４の記載参照）。
【００５４】
携帯電話機１０は、上記データサイズの確認の後、上記欠落したデータセグメントについてコンテンツ再取得要求としてのＨＴＴＰ要求をダウンロードサーバ５０に送信する（ステップＳ１５）。このＨＴＴＰ要求のヘッダーの「Range」フィールドには、上記欠落したデータセグメントを特定するためのデータが記述される。
【００５５】
上記ＨＴＴＰ要求を受信したダウンロードサーバ５０は、そのＨＴＴＰ要求で指定されたコンテンツをコンテンツ記憶手段（コンテンツデータベース）から読み出す（ステップＳ１６）。次に、ダウンロードサーバ５０は、上記コンテンツの欠落したデータセグメントを含むＨＴＴＰ応答を携帯電話機１０に送信し、ＨＴＴＰ応答の送信が完了したら、携帯電話機１０との接続を切断するための接続要求としてのＦＩＮメッセージを送信する（ステップＳ１７）。
【００５６】
次に、携帯電話機１０は、上記ＨＴＴＰ応答を受信すると、上記再送されたデータセグメントについて、送信データサイズと受信データサイズとが一致しているか否かを確認する（ステップＳ１８）。そして、携帯電話機１０は、上記送信データサイズと受信データサイズとが一致していることを確認すると、ダウンロードサーバ５０の所定のＵＲＩ（InstallNotifyURI）に、ダウンロードが完了した旨を示すダウンロード完了通知としてＨＴＴＰ要求（InstallNotify）を送信する（ステップＳ１９）。
一方、上記ダウンロード完了通知を受信したダウンロードサーバ５０は、ダウンロード完了応答としてのＨＴＴＰ応答を携帯電話機１０に返信する（ステップＳ２０）。
【００５７】
携帯電話機１０は、ダウンロードサーバ５０からダウンロード完了応答を受信した後、図９（ｄ）に示すダウンロード完了通知を表示し、利用者に対してダウンロード完了を知らせるとともに、すぐに試聴するか否かを利用者に問い合せる。ここで、ダウンロードした音楽コンテンツの試聴を希望するキー操作、具体的に「ＹＥＳ」キーを選択するキー操作を行うと、携帯電話機１０は、ダウンロードした音楽コンテンツのデータについて展開処理を行い、スピーカ１８やイヤホン等から楽曲の出力を開始する。
【００５８】
図１０及び１１はそれぞれ、上記図８のシーケンスにおけるコンテンツ取得要求の送信（ステップＳ６）からコンテンツ全体のデータの受信（ステップＳ２０）までの手順についてより詳しく示したシーケンス図及びフローチャートである。
【００５９】
携帯電話機１０において、利用者が希望するコンテンツの取得を要求するコンテンツ取得要求としてのＨＴＴＰ要求は、アプリケーション層のＨＴＴＰからトランスポート層のＴＣＰに渡され、ダウンロードサーバ５０に送信される（図１０のステップS101、S102）。
【００６０】
次に、ダウンロードサーバ５０は、利用者が希望するコンテンツをコンテンツ記憶手段（コンテンツデータベース）から読み出し（図１０のステップS103）、コンテンツ全体のデータを分割した複数のデータセグメント（エンティティ）からなるコンテンツ取得要求としてのＨＴＴＰ応答を、携帯電話機１０に返信する（図１０のステップS104〜S106）。本例では、ＨＴＴＰ応答が３つのデータセグメントに分割されて携帯電話機１０に送信される。このＨＴＴＰ応答のデータセグメントは、次のように携帯電話機１０に送信される。
ダウンロードサーバ５０は、第１番目のデータセグメント１／３を送信したとき、監視タイマーをスタートする（S104）。携帯電話機１０は、データセグメント１／３を受信すると、そのデータセグメントを受け取った旨を示す受信確認信号としてのＡＣＫ信号をダウンロードサーバに送信する。ダウンロードサーバ５０は、監視タイマーが切れる前（タイムアウトが発生する前）に携帯電話機１０からのＡＣＫ信号を受信すると、第２番目のデータセグメント２／３を送信し、上記S104の場合と同様に監視タイマーをスタートする（S105）。また、ダウンロードサーバ５０は、同様に、監視タイマーが切れる前（タイムアウトが発生する前）に携帯電話機１０からのＡＣＫ信号を受信すると、第３番目のデータセグメント３／３を送信し、上記S104の場合と同様に監視タイマーをスタートする（S106）。
【００６１】
ここで、携帯電話通信網２０等の通信ネットワークにおける通信状況の悪化により、ダウンロードサーバ５０は、次のように携帯電話機１０との接続を切断するために接続要求としてのＦＩＮメッセージを携帯電話機１０に送信する（図１０のステップS107）。すなわち、通信状況の悪化により、携帯電話機１０が上記第３番目のデータセグメント３／３を受信できないとき、携帯電話機１０はＡＣＫ信号を送信しないので、ダウンロードサーバ５０は、監視タイマーが切れる前に携帯電話機１０からＡＣＫ信号を受信しないことになる。このように監視タイマーが切れる前にＡＣＫ信号を受信しないとき、ダウンロードサーバ５０は、携帯電話機１０にＦＩＮメッセージを送信し、携帯電話機１０とのセッションを強制的に切断する。
また、上記監視タイマーが切れる前にＡＣＫ信号を受信しないとき、ダウンロードサーバ５０は、ＡＣＫ信号を受信できなかった第３番目のデータセグメント３／３を再送する場合がある。この場合、第３のデータセグメント３／３の再送を所定回数繰り返したとき、ダウンロードサーバ５０は、携帯電話機１０にＦＩＮメッセージを送信し、携帯電話機１０とのセッションを強制的に切断する。
【００６２】
以上のようにＦＩＮメッセージを送信されたとき、携帯電話機１０のトランスポート層（ＴＣＰ）で受信したＨＴＴＰ応答は、第１番目のデータセグメント１／３及び第２番目のデータセグメント２／３しか含まず、第３番目のデータセグメント３／３が欠落した状態になっている。
【００６３】
次に、上記ＨＴＴＰ応答及びＦＩＮメッセージを受信した携帯電話機１０のトランスポート層（ＴＣＰ）は、上記ＨＴＴＰ応答のデータをアプリケーション層（ＨＴＴＰ）に渡す（図１０のステップS108）。
【００６４】
上記ＨＴＴＰ応答のデータを受け取った携帯電話機１０のアプリケーション層（ＨＴＴＰ）では、例えば図１１に示すように、ＨＴＴＰ応答に含まれるコンテンツデータのデータサイズの確認が行われる。
図１１において、ＨＴＴＰ応答及びＦＩＮメッセージを受信した後（図１１のステップS201〜S202）、携帯電話機１０のアプリケーション層（ＨＴＴＰ）では、ＨＴＴＰ応答のヘッダーの「Content-Length」フィールドから、３つのデータセグメント全体の送信データサイズが読み出される（図１１のステップS203）。また、受信した第１のデータセグメント及び第２のデータセグメントから、実際に受信したデータセグメントの受信データサイズが算出される（図１１のステップS204）。そして、上記送信データサイズと上記受信データサイズとが一致しているか否かが判断される（図１１のステップS205）。
【００６５】
上記ステップS205のデータサイズの確認において、上記送信データサイズと上記受信データサイズとが一致している場合は、コンテンツのデータを正常に受信できたと判断し、受信した複数のデータセグメントについて連結処理を行い、コンテンツのデータを復元するように生成する（図１１のステップS208）。
【００６６】
一方、上記ステップS205のデータサイズの確認において、上記送信データサイズと上記受信データサイズとが一致していない場合例えば上記送信データサイズが上記受信データサイズよりも大きい場合は、コンテンツのデータが一部欠落していると判断し、次のように欠落データセグメントについて再取得動作（Byte Range Operation）を実行する。
【００６７】
上記再取得動作（Byte Range Operation）において、携帯電話機１０のアプリケーション層（ＨＴＴＰ）で作成されたコンテンツ再取得要求としてのＨＴＴＰ要求が、トランスポート層（ＴＣＰ）に渡された後、ダウンロードサーバ５０に送信される（図１０のS110及びS111、図１１のステップS206）。このＨＴＴＰ要求のヘッダーの「Range」フィールドには、上記欠落したデータセグメントを特定するためのデータが記述される。
【００６８】
上記ＨＴＴＰ要求を受信したダウンロードサーバ５０は、そのＨＴＴＰ要求で指定されたコンテンツを読み出し（図１０のステップS113）、コンテンツ再取得応答としてのＨＴＴＰ応答を生成する。このＨＴＴＰ応答は、上記欠落した第３番目のデータセグメントを含むように生成される。次に、ダウンロードサーバ５０は、ＨＴＴＰ応答を携帯電話機１０に送信し、ＨＴＴＰ応答の送信が完了したら、携帯電話機１０との接続を切断するための接続要求としてのＦＩＮメッセージを送信する（図１０のステップS114）。
【００６９】
次に、携帯電話機１０では、上記ＨＴＴＰ応答及びＦＩＮメッセージを受信すると、受信したＨＴＴＰ応答が、トランスポート層（ＴＣＰ）からアプリケーション層（ＨＴＴＰ）に渡される（図１０のステップS115、図１１のステップS207,S202）。この携帯電話機１０のアプリケーション層（ＨＴＴＰ）において、前述のようにデータサイズの確認が行われる（図１０のステップS116、図１１のステップS203〜S205）。
【００７０】
次に、上記コンテンツの再取得の結果、上記送信データサイズと上記受信データサイズとが一致した場合は、最終的にコンテンツ全体のデータを正常に受信できたと判断し、受信した複数のデータセグメントについて連結処理を行い、コンテンツのデータを復元するように生成する（図１０のステップS117、図１１のステップS208）。
【００７１】
以上、本実施形態によれば、ダウンロードサーバ５０から送信された切断要求（ＦＩＮ）を受信したときに、コンテンツ取得応答（ＨＴＴＰ応答）で受信できたデータセグメントのデータサイズを合算した受信データサイズと、コンテンツ取得応答（ＨＴＴＰ応答）のヘッダー（Content-Length）に記述された送信データサイズとが一致しているか否かを判断する。ここで、コンテンツのダウンロードの途中で携帯電話通信網２０の通信状況の悪化等が発生したことにより、上記受信データサイズと送信データサイズとが一致していないとき、コンテンツのダウンロードが完結していないと判断する。この判断に基づき、ダウンロードサーバ５０から受信できていないデータセグメントの部分を再取得することにより、コンテンツのデータの一部欠落の発生を回避することができる。
しかも、上記コンテンツのデータの再取得を、ダウンロードサーバ５０から受信できていないデータセグメントについてのみ行っているので、コンテンツの全体を再取得する場合に比して、コンテンツの全体のデータを取得するための無駄な通信を抑制することができることができる。
【００７２】
なお、上記実施形態では、図８に示すようにＯＭＡ方式のダウンロード手順を用いてコンテンツをダウンロードする場合について説明したが、本発明は、ＯＭＡ方式のダウンロード手順を用いずに通常のＨＴＴＰ通信によってコンテンツをダウンロードする場合についても同様に適用することができる。すなわち、上記実施形態において、携帯電話機１０は、通常のＨＴＴＰ通信とは異なり、コンテンツダウンロードに先だってＵＲＩ、ファイルタイプ等のダウンロード情報をサーバ５０から取得するとともに、コンテンツダウンロード後にダウンロード完了通知をサーバ５０に送信している。本発明は、かかるＯＭＡ方式におけるダウンロード情報の事前取得やダウンロード完了通知の送信を行わない通常のＨＴＴＰ通信によってコンテンツをダウンロードする場合についても同様に適用することができる。
【００７３】
また、上記実施形態では、監視タイマーと受信確認信号（ＡＣＫ信号）とを組み合わせて通信状況を監視する場合について説明したが、本発明は、このような通信状況の監視を行わない場合にも同様に適用することができる。すなわち、上記実施形態では、監視タイマーが切れる前に受信確認信号（ＡＣＫ信号）を受信しないときや、監視タイマーに基づいて同じデータセグメントの再送を所定回数繰り返したときに、サーバは通信状況が悪化していると判断し、移動体通信端末（携帯電話機）に切断要求（ＦＩＮ）を送信してセッションを切断している。本発明は、かかる通信状況の監視を行わずに、例えばサーバが、コンテンツ取得応答を構成する複数のデータセグメントのすべてを送信した後、受信確認信号（ＡＣＫ信号）の受信の有無にかかわらず切断要求（ＦＩＮ）を送信する場合にも同様に適用することができる。この場合も、移動体通信端末は、受信データサイズと送信データサイズとが一致していないとき、コンテンツのダウンロードが完結していないと判断し、サーバから受信できていないデータセグメントの部分を再取得することにより、コンテンツのデータの一部欠落の発生を回避することができる。しかも、上記コンテンツのデータの再取得を、サーバから受信できていないデータセグメントについてのみ行っているので、コンテンツの全体を再取得する場合に比して、コンテンツの全体のデータを取得するための無駄な通信を抑制することができる。
【図面の簡単な説明】
【００７４】
【図１】本発明の実施形態に係る通信システム全体の概略構成の一例を示す説明図。
【図２】ダウンロードサーバのハードウェア構成の一例を示すブロック図。
【図３】ダウンロードサーバの主要な機能を抽出して示した機能ブロック図。
【図４】携帯電話機の一構成例を示す外観図。
【図５】携帯電話機のハードウェア構成を示す概略構成図。
【図６】携帯電話機におけるソフトウェア構造の説明図。
【図７】携帯電話機の主要な機能を抽出して示した機能ブロック図。
【図８】音楽コンテンツをダウンロードするときの携帯電話機とサーバとの間の通信手順の一例を示すシーケンス図。
【図９】（ａ）〜（ｄ）はコンテンツダウンロード時における携帯電話機のディスプレイ画面の遷移を示す説明図。
【図１０】携帯電話機とサーバとの間のより詳細な通信手順の一例を示すシーケンス図。
【図１１】サーバからコンテンツをダウンロードするときの携帯電話機における処理手順の一例を示すフローチャート。
【符号の説明】
【００７５】
１０    携帯電話機
２０    携帯電話通信網
３０    インターネット
４０    ＷＥＢサーバ
５０    ダウンロードサーバ
【図１】
2006114967.tif 000003
【図２】
2006114967.tif 000004
【図３】
2006114967.tif 000005
【図４】
2006114967.tif 000006
【図５】
2006114967.tif 000007
【図６】
2006114967.tif 000008
【図７】
2006114967.tif 000009
【図８】
2006114967.tif 000010
【図９】
2006114967.tif 000011
【図１０】
2006114967.tif 000012
【図１１】
2006114967.tif 000013