JP2004021304A

JP2004021304A - クライアント・サーバ形式のダウンロードシステム

Info

Publication number: JP2004021304A
Application number: JP2002171469A
Authority: JP
Inventors: Atsushi Ito; 伊藤　淳
Original assignee: Sharp Corp
Current assignee: Sharp Corp
Priority date: 2002-06-12
Filing date: 2002-06-12
Publication date: 2004-01-22

Abstract

【課題】サーバ・クライアント形式のダウンロードシステムにおいて、ダウンロード対象コンテンツの内容及びクライアントマシンの動作状況に応じて、コンテンツのダウンロードを確実に行うことができるダウンロードシステムを提供する。
【解決手段】ネットワークを通じてデータを送受信するクライアント・サーバ形式のダウンロードシステムであって、サーバは送信データに関する情報をクライアントに提供し、クライアントは、該情報に基づいて前記送信データを受信するか否かを決定することを特徴とするダウンロードシステム。
【選択図】　図１

Description

【０００１】
【発明の属する技術分野】
本発明はクライアント・サーバ形式のダウンロードシステムに関し、特に、ＨＴＭＬ、ＸＭＬ等のマークアップ言語を用いて、合法かつ信頼性の高いデータのダウンロードを行うダウンロードシステムに関するものである。
【０００２】
【従来の技術】
近年、インターネットでは、ＡＤＳＬやＣＡＴＶなどの普及により、高速通信、常時接続及び低価格の使用料を特徴とするいわゆるブロードバンド接続環境が一般的なものになっている。また、一般ユーザ向けのパーソナルコンピュータにおいても、処理速度の向上、記憶装置の大容量化、周辺機器の充実及び販売価格の低下が著しく進んでいる。さらに、ＡＶ機器のデジタル化が進み、デジタルデータを扱うための演算装置、記憶装置、表示装置、通信インターフェイス等を備えたものが実用されるようになってきている。このようなＡＶ機器同士をネットワーク接続したり、通信モデム等を介してインターネット上のリソースを利用することも広く行われるようになっている。上記のようなネットワーク環境の発展に伴い、ネットワークを通じた電子決済システム、電子コンテンツ著作権システム、電子認証システムなどのネットワーク技術も開発されている。現在、インターネットに接続可能なユーザに対して、これらの技術を利用したさまざまなネットワークサービス事業が展開されている。
【０００３】
このようなネットワークサービス事業の中では、インターネットを通じて音楽や映像などの有料コンテンツデータをダウンロード配信するコンテンツ配信サービスが代表的なものである。例えば、ユーザはコンピュータ又はデジタルＡＶ機器に搭載されたＷｅｂブラウジングソフトウェア（以下、「Ｗｅｂブラウザ」とする）を用いて、インターネット上のコンテンツ配信サイトを閲覧し、サイト上に欲しいコンテンツがあれば、これを選択してダウンロードすることができるようなサービスが提供されている。有料コンテンツをダウンロードする場合には、上記のような電子決済システムを用いれば、ユーザはその場で決済を済ませてすぐに欲しいコンテンツを手に入れることができる。
【０００４】
上記の例において、ユーザがコンテンツ配信サイトを閲覧したりコンテンツをダウンロードしたりする際には、ユーザ機器内のＷｅｂブラウザと配信サイトのサーバコンピュータ内のＷｅｂサーバソフトウェアとが、インターネットを通じてＨＴＴＰ　（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）と呼ばれるプロトコルに基づいて必要な情報を送受信している。Ｗｅｂサイトを構成するデータは、ＨＴＭＬ　（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ、ハイパーテキストマークアップ言語）により作成されており、ユーザ機器のＷｅｂブラウザは、サーバコンピュータからこのＨＴＭＬデータを受信した後、これを解析、制御して、当該ＷｅｂサイトをＷｅｂブラウザ上に表示する。
【０００５】
ＨＴＭＬは“＜＞”に囲まれた所定の識別ラベル（又はＨＴＭＬタグ）を含んでいる。この識別ラベルは、“＜＞”の中に含まれる要素及び属性により、当該ＨＴＭＬデータのデータ構造や文書の修飾情報を示す。Ｗｅｂブラウザは、この識別ラベルを解析することにより表示画面上に様々な表示を行うことができる。
【０００６】
このような識別ラベルの中でも重要なのは、Ｗｅｂサイト上の他の文書又は他のリソースとのリンクを示すアンカータグである。アンカータグには、アンカー要素（ａ要素）が定義されており、リンク先を示すｈｒｅｆ属性とともに用いられる。リンク先を示すアンカータグは開始タグ“＜ａ　ｈｒｅｆ＝”リンク先ＵＲＩ”＞”と終了タグ＜／ａ＞とからなり、これらに挟まれる部分には、通常リンクされていることを示すテキストを挿入する。アンカータグにより指定されるリンク先には、当該Ｗｅｂサイトのサーバ内の他の文書又はファイル、インターネット上の他のサイト上の文書又はファイル、ユーザ機器内にある文書又はファイルなど、Ｗｅｂブラウザが到達可能なあらゆるリソースを指定することができる。
【０００７】
例えば、現在閲覧しているＷｅｂサイトと同じディレクトリにある＊＊＊．ｈｔｍｌというＨＴＭＬ文書にリンクする場合には＜ａ　ｈｒｅｆ＝”＊＊＊．ｈｔｍｌ”＞（リンクのための表示テキスト）＜／ａ＞と記述する。また、インターネット上のリソース（ファイルやデータなど）にリンクする場合には、“ｈｔｔｐ：／／〜”から始まるＵＲＬをｈｒｅｆ属性に指定すればよい。「リンクのための表示テキスト」とは、例えば、「ここをクリックしてダウンロード」や「＊＊＊のページを表示する」などである。
【０００８】
ユーザがＷｅｂブラウザ上で上記アンカータグに挟まれた（リンクのための表示テキスト）の部分をクリックすると、Ｗｅｂブラウザは当該リンク先のリソースを取得する。このとき、例えばリンク先がＨＴＭＬ文書であれば、これをユーザ機器にダウンロードした後Ｗｅｂブラウザ上に表示する。また、リンク先が音声データや映像データなどＷｅｂブラウザでは表示できないリソースである場合には、これらをハードディスク等の記憶装置の所定の場所にダウンロードし保存するようにしてもよい。
但し、有料コンテンツのダウンロードにおいては、通常、コンテンツへのリンクをクリックした後に、電子決済等の手続が始まるようになっているが、ここではこの手続についての説明は省略する。
【０００９】
【発明が解決しようとする課題】
ところで、コンテンツ配信サービスにより提供される主なコンテンツは、画像、音楽及び動画コンテンツであり、これらは圧縮形式であっても相当大きいファイルサイズとなる。このため、ユーザ機器の記憶装置内にダウンロードするコンテンツを記憶するための容量が残っているかどうかが問題となることがある。もし、残りの記憶容量が不足しているにも関わらずダウンロードを開始してしまうと、記憶容量を使い切ったときにダウンロードが途中停止してしまう。このとき、記憶装置には不完全なデータが記憶されていることになるが、画像、音楽及び動画コンテンツデータの場合には、このような不完全データは利用不可能となることが多い。
【００１０】
特に、有料コンテンツをダウンロードしているときに、上記のようにダウンロードが不完全に終わってしまった場合には、ユーザは代金を支払ったにもかかわらず、目的のコンテンツを手に入れられなかったことになる。また、ファイルサイズの大きなコンテンツをダウンロードしていた場合には、途中までのダウンロードにかかった時間が無駄となってしまう。
【００１１】
そこで、データをダウンロードする前に記憶装置の残記憶容量をチェックしてダウンロード可能かどうかを判断する方法が考えられている。特開平８−１６６８５８号は、フォントを記憶する記憶装置を有するプリンタにおいて、ホストコンピュータから新たなフォントデータをダウンロードする際に、予め記憶装置の空き記憶容量をチェックすることにより、フォントデータを確実にダウンロードすることができるプリンタ制御方法を開示している。空き記憶容量が不足している場合には、既に記憶しているデータを圧縮したり、使用頻度の低いフォントデータを２次記憶装置にバックアップしたりすることにより、新たなフォントデータのダウンロードが可能となっている。
【００１２】
ホストコンピュータからプリンタにダウンロードされるフォント情報はそれほど容量の大きいデータではなく、またデータサイズもほぼ一定であるから、プリンタに用いる場合にはこの方法は有効である。しかしながら、上記のようなコンテンツのダウンロードにおいては、コンテンツの種類によってデータサイズが大きく異なるので、毎回ダウンロードするコンテンツのデータサイズをダウンロード前に取得してから記憶装置の残記憶容量をチェックしなければならず、特開平８−１６６８５８号に開示された方法ではこれを行うことは不可能である。
【００１３】
また、上記のような記憶装置の記憶容量の問題以外にも、マルチタスク動作のコンピュータでは、ダウンロード以外のタスクの実行によりＣＰＵやメインメモリのリソースが不足すると、ダウンロードに障害を及ぼす可能性があるという問題がある。
【００１４】
したがって、本発明は、サーバ・クライアント形式のダウンロードシステムにおいて、上記のような問題点を解決し、ダウンロード対象コンテンツの内容及びクライアントマシンの動作状況に応じて、確実にコンテンツのダウンロードを行うことができる信頼性の高いダウンロードシステムを提供することを目的とするものである。
【００１５】
【課題を解決するための手段】
本発明は、ネットワークを通じてデータを送受信するクライアント・サーバ形式のダウンロードシステムであって、サーバは送信データに関する情報をクライアントに提供し、クライアントは、該情報に基づいて前記送信データを受信するか否かを決定することを特徴とするダウンロードシステムを提供する。
前記送信データに関する情報は、前記送信データのサイズ、クライアントが前記送信データを受信するのに必要とするメモリ容量、及びクライアントにおいて前記送信データを記憶する手段に関する情報を含んでいるのが好ましい。
【００１６】
前記クライアントは、記憶装置の空き記憶容量を増加させる手段と、メインメモリの空き記憶容量を増加させる手段とを有し、前記送信データに関する情報に基づいて、前記手段のいずれか又は両方を実行するようにしてもよい。
また、本発明は、クライアント・サーバ形式のダウンロードシステムに用いるマークアップ言語であって、サーバがクライアントに送信する送信データに関する情報を記述可能であることを特徴とするマークアップ言語を提供する。
【００１７】
前記送信データに関する情報は、クライアントにおいて前記送信データをダウンロードするのに必要な記憶容量及びメモリ容量、並びに前記送信データを記憶する手段に関する情報を含んでいるのが好ましい。
前記マークアップ言語にはＨＴＭＬ又はＸＭＬを用いて、前記送信データに関する情報をハイパーリンク要素に付随させることができる。
【００１８】
また、本発明は、クライアント・サーバ形式のダウンロードシステムにおいてクライアントがダウンロードを制御する方法であって、クライアントはサーバから送信データに関する情報を取得し、該情報に基づいて前記送信データを受信するか否かを決定することを特徴とする方法を提供する。
【００１９】
また、本発明は、サーバからダウンロードを行うクライアント装置であって、前記サーバから送信されるマークアップ言語を処理する手段と、前記マークアップ言語に含まれる情報に基づいて、前記サーバからのデータの受信を制御する手段とを有することを特徴とするクライアント装置を提供する。
また、本発明は、クライアントにデータを提供するサーバ装置であって、前記データに関する情報をマークアップ言語によりクライアントに提供することを特徴とするサーバ装置を提供する。
【００２０】
【発明の実施の形態】
以下、添付図面を参照しながら、本発明の実施の形態を詳細に説明する。
まず、クライアント・サーバ形式ダウンロードシステムの概念を説明する。図１は、クライアント・サーバ形式ダウンロードシステムの一形態の構成を示す概念図である。図１において、ダウンロードシステムは、サーバ１、ネットワーク２及びクライアント３から構成されている。サーバ１はコンテンツ配信側であり、Ｗｅｂサイトを記述するマークアップ言語（ＨＴＭＬ）データ及び配信するコンテンツデータを記憶する記憶装置と、ネットワーク２に接続するための通信インターフェイスと、記憶しているデータ及び通信を管理するＷｅｂサーバソフトウェアとを有している。ネットワーク２は、複数のコンピュータ間での通信を可能にするネットワークであればよく、例えば、インターネット、ＬＡＮ、ＷＡＮ等を用いることができる。クライアント３はコンテンツ受信側であり、ダウンロードしたデータを記憶する記憶装置と、ネットワーク２に接続するための通信インターフェイスと、サーバ１のＷｅｂサイトを閲覧するＷｅｂブラウザとを有している。
【００２１】
クライアント３がサーバ１のＷｅｂサイトを訪問すると、サーバ１は当該ＷｅｂサイトのＨＴＭＬデータをクライアント３に送信する。クライアント３がサイト上でリンクされているコンテンツを取得するようサーバ１に要求すると、サーバ１は、クライアント３が当該コンテンツの取得を許可されているかどうかを判断し、許可されていれば要求されたコンテンツをクライアント３に送信する。ここで、サーバ１とクライアント３との間の通信は、ネットワーク２上で利用可能なプロトコルを利用して行われる。例えば、ネットワーク２がインターネットである場合には、サーバ１及びクライアント３は、ＴＣＰ／ＩＰプロトコル上でＨＴＴＰプロトコルによる通信を行う。このとき、サーバ１及びクライアント３の通信インターフェイスは、ＴＣＰ／ＩＰプロトコルを実装しており、サーバ１のＷｅｂサーバソフトウェア及びクライアント３のブラウザは、ともにＨＴＴＰプロトコルを実装しているものとする。
次に、本発明の一実施形態に用いるクライアントについて説明する。本実施形態では、クライアントにデジタルオーディオ装置を用いるが、本発明で利用するクライアントはこれに限定されるわけではない。
【００２２】
図２は、本実施形態においてクライアントとして用いるオーディオ装置の構成を概略的に示す機能ブロック図である。図２において、オーディオ装置は、ハードディスク１０、メモリカードスロット１１、表示部１２、ユーザインターフェイス部１３、プログラムＲＯＭ１４、ＣＰＵ１５、ＲＡＭ１６、オーディオ再生部１７及びモデム１８、並びにこれらを接続するシステムバス１９を有する。
【００２３】
図２に示すオーディオ装置において、ハードディスク１０は、ダウンロードしたオーディオデータ、ブラウザその他のソフトウェア、設定データ等を電子的に記憶するための記憶装置である。ハードディスク１０は、例えば、磁気式ディスク、光学式ディスク等の不揮発性の記憶装置を用いるのが好ましいが、デジタルデータを記憶することができる装置であればどのようなものでもよい。メモリカードスロット１１もまた、メモリカードを装着して、ダウンロードしたオーディオデータ、ブラウザその他のソフトウェア、設定データ等を電子的に記憶することができる記憶装置である。尚、本発明のクライアントはこれらの両方を備えている必要は無く、ハードディスク１０又はメモリカードスロット１１のいずれか一方のみを備えるようにしてもよい。
表示部１２は小型の液晶ディスプレイや有機ＥＬディスプレイ等を含んでおり、オーディオ装置の状態や日時、時刻等の情報が表示可能なほか、ＷｅｂブラウザによりＷｅｂサイトを表示できるようになっている。
【００２４】
ユーザインターフェイス部１３は、ユーザがオーディオ装置に操作信号を入力するためのインターフェイスであり、本実施形態では、複数の入力キーを含んでいる。これらの入力キーは、「再生」、「停止」、「インデックス表示」等のオーディオデータに対する所定の操作と、表示部１２上に表示されるＷｅｂブラウザ画面に対する所定の操作とに対応しており、ユーザは入力キーによりこれらの操作を行うことができるようになっている。
【００２５】
プログラムＲＯＭ１４は、書き換え不可能な記憶手段であり、オーディオ装置が行う処理に必要なプログラムやデータを格納している。プログラムＲＯＭ１４には、例えば、オーディオ装置の基本的動作を規定するプログラム（オペレーティングシステム）、各構成部分のインターフェイスのドライバソフトウェア、ＴＣＰ／ＩＰやＨＴＴＰ等の通信プロトコルスタックなどを格納しておくことができる。また、オーディオ装置のＷｅｂブラウザをプログラムＲＯＭ１４に格納するようにしてもよい。
【００２６】
ＣＰＵ１５は、マイクロプロセッサ等からなり、オーディオ装置の各構成部分の動作、及び入出力されるデータの流れを制御する。ＲＡＭ１６は半導体メモリ等を含むランダムアクセス可能な記憶手段であり、オーディオ装置のメインメモリとして用いる。ＣＰＵ１５は、プログラムＲＯＭ１４又はハードディスク１０に格納されているプログラム及びデータをＲＡＭ１６にロードし、所定の演算処理を行うことにより、当該プログラムに規定された処理又は制御を行う。
【００２７】
オーディオ再生部１７は、スピーカ、アンプ等を含むデジタルオーディオデータを再生可能な再生装置である。モデム１８は、電話回線等を通じてインターネットに接続するための通信手段である。これらの他に、図示しないが、オーディオ装置はネットワーク通信のためのインターフェイスを有しており、このインターフェイスはモデム１８と一体になっていてもよい。
【００２８】
ここで、上記のように構成されたオーディオ装置において、ユーザが表示部１２上に表示されるＷｅｂブラウザを用いて音楽コンテンツ配信サイトにアクセスし、ユーザの望む音楽コンテンツをダウンロードする際のＷｅｂブラウザの表示例及びユーザによる操作例を説明する。
【００２９】
図３は、ユーザがアクセスしている音楽コンテンツ配信サイトの一画面をＷｅｂブラウザにより表示する例を示す図である。図３において表示されているページでは、アーティストＡの曲名１〜３及びアーティストＢから選択してダウンロードすることが可能となっている。但し、ダウンロード可能なコンテンツはこれらだけではなく、画面右下部の「次ページへ」を選択することにより、ユーザは他のコンテンツをＷｅｂブラウザ上に表示させることも可能である。
【００３０】
この画面において、ユーザは、ユーザインターフェイス部１３の所定の入力キーを入力することにより、画面上の矢印を操作することができるようになっている。この画面内にユーザが欲しいコンテンツがある場合には、ユーザは当該コンテンツの曲名に矢印を合わせ、所定の入力キーを入力することによりダウンロードの操作をすることができる。このとき、実際にダウンロードを開始する前に、画面のページを切り替えて、電子決済又は電子認証を行ったり、選択したコンテンツの詳細情報（例えば、再生時間、ファイルサイズ、価格など）を表示する確認画面を表示したりしてもよい。
尚、図３では、本実施形態におけるＷｅｂブラウザの表示例を示すために必要最小限の項目のみを図示しているが、コンテンツ配信サイトの各ページの表示形態については、ＨＴＭＬにより表現できる範囲内で自由に構成することができる。
【００３１】
上記のようにユーザがオーディオ装置のＷｅｂブラウザを操作して、コンテンツ配信サイトを表示し、所望のコンテンツを選択してダウンロードするとき、Ｗｅｂブラウザとコンテンツ配信サイトのＷｅｂサーバとの間では、以下に示すようなＨＴＴＰプロトコルによる通信が行われている。
【００３２】
ユーザがＷｅｂブラウザ上でコンテンツ配信サイトを訪問すると、Ｗｅｂブラウザはコンテンツ配信サイトサーバにアクセスし、サイトの表示画面データを含むＨＴＭＬデータをダウンロードする。本実施形態では、図３に示す画面において、ユーザは任意の曲名を選択しダウンロードすることが出来るようになっているが、この機能はＨＴＭＬのアンカー要素により実現されている。例えば、図３の画面の“曲名１”と表示されている部分は、ＨＴＭＬデータ中では、アンカー要素を含むハイパーリンクタグを用いて以下のように記述されている。
＜ａｈｒｅｆ＝”ｈｔｔｐ：／／ｗｗｗ．ｘｘｘ．ｙｙｙ．ｚｚｚ／ｄｏｗｎｌｏａｄ／ｍｕｓｉｃ１．ｄａｔ”　ｄｏｗｎｌｏａｄ＿ｓｉｚｅ＝５００００００　ｃａｃｈｅ＿ｓｉｚｅ＝１０００００　ｍｅｍｏｒｙ＿ｔｙｐｅ＝ｈｄｄ＞　曲名１＜／ａ＞
【００３３】
ここで、上記のハイパーリンクタグについて説明する。要素“ａ”はネットワーク内の他のリソースへのハイパーリンクを示す要素であり、この要素を含むタグに挟まれた部分をハイパーリンク先のリソースに関連付ける機能を提供する。属性“ｈｒｅｆ”はハイパーリンク先のＵＲＩを示す属性であり、上記では、サイト“ｗｗｗ．ｘｘｘ．ｙｙｙ．ｚｚｚ”のディレクトリ“ｄｏｗｎｌｏａｄ”にある“ｍｕｓｉｃ１．ｄａｔ”というファイルがハイパーリンク先であることを示している。またハイパーリンクに　“ｈｔｔｐ”　プロトコルを用いることが示されているが、これ以外にも“ｆｔｐ”等のプロトコルを指定することができる。
【００３４】
属性“ｄｏｗｎｌｏａｄ＿ｓｉｚｅ”は“ｍｕｓｉｃ１．ｄａｔ”のファイルサイズを示す属性であり、上記の例では５００００００バイト（５Ｍバイト）となっている。属性“ｃａｃｈｅ＿ｓｉｚｅ”は、オーディオ装置が“ｍｕｓｉｃ１．ｄａｔ”をダウンロード処理するときにＲＡＭ１６上に確保するキャッシュメモリ領域のサイズを示す属性であり、上記の例では１０００００バイト（１００Ｋバイト）となっている。
【００３５】
属性“ｍｅｍｏｒｙ＿ｔｙｐｅ”は、ダウンロードした“ｍｕｓｉｃ１．ｄａｔ”を記憶する媒体を示す属性であり、上記の例では“ｈｄｄ”、すなわちハードディスクに保存することを示している。この属性“ｍｅｍｏｒｙ＿ｔｙｐｅ”を用いることにより、クライアントがサーバからダウンロードするコンテンツデータの保存先の記憶装置をサーバ側で一意に決めることができるようになる。
【００３６】
尚、本実施形態において、属性“ｍｅｍｏｒｙ＿ｔｙｐｅ”に指定する値は、“ｈｄｄ”（ハードディスク）及び“ｃａｒｄ”（メモリカード）のいずれかを指定するようになっているが、これ以外の形態の記憶媒体も指定できるようオーディオ装置のＷｅｂブラウザを設定することも可能である。
【００３７】
また、本実施形態では、上記の例に含まれる以外にも様々な属性を追加することができる。例えば、ダウンロードを行う前に所定の方法で決済を行うよう指定する属性を含んでいてもよい。また、上記の例では、ダウンロード対象のコンテンツが“ｍｕｓｉｃ１．ｄａｔ”となっているが、本実施形態では、“＊＊＊．ｍｐ３”、“＊＊＊．ｗａｖ”等を含む任意のファイル形式のコンテンツをダウンロードすることができる。
【００３８】
今、図３に示す画面において、ユーザが曲名１を選択してダウンロードするよう操作したとする。このときのＷｅｂブラウザの動作を以下に説明する。図４は、本実施形態のオーディオ装置のＷｅｂブラウザがコンテンツをダウンロードするときの動作を示すフローチャート図である。
【００３９】
ユーザが曲名１のダウンロード操作を行うと、Ｗｅｂブラウザは表示しているＨＴＭＬデータから曲名１のハイパーリンクタグに含まれる情報を取得し解析する。ここで上記の例を用いると、曲名１のハイパーリンクタグは、ｈｒｅｆ属性、ｄｏｗｎｌｏａｄ＿ｓｉｚｅ属性、ｃａｃｈｅ＿ｓｉｚｅ属性及びｍｅｍｏｒｙ＿ｔｙｐｅ属性を含んでいる。
【００４０】
図４に示すフローチャート図を参照すると、まずステップＳ１において、Ｗｅｂブラウザはオーディオ装置の記憶装置の空き記憶容量を演算する。本例では、ｍｅｍｏｒｙ＿ｔｙｐｅ属性においてハードディスクが指定されているので、Ｗｅｂブラウザはハードディスク１０の空き記憶容量を計算する。続いてステップＳ２において、Ｗｅｂブラウザはハードディスク１０の空き記憶容量とダウンロードしようとする曲名１のファイルサイズとを比較する。曲名１のファイルサイズはｄｏｗｎｌｏａｄ＿ｓｉｚｅ属性の値を参照すると５Ｍバイトであることがわかる。ここで、ハードディスク１０の空き記憶容量が５Ｍバイト以下である場合には、Ｗｅｂブラウザは記憶容量不足と判断し、“ダウンロードするためのハードディスクの空き記憶容量がありません！！”とのエラーメッセージを表示した後、以降の処理を中断する。尚、上記では、ハードディスク１０の空き記憶容量が５Ｍバイトより少しでも多ければ記憶容量が足りていると判断しているが、実際にはダウンロード後に多少の空き記憶容量を確保するために、例えば、ＯＳ等が快適に動作する程度のマージンを判断基準に設けるのが好ましい。（但し、このマージンサイズをユーザが設定可能としてもよい。）ステップＳ２においてハードディスク１０の空き記憶容量が十分であると判断すると、Ｓ３に進み、Ｗｅｂブラウザはメインメモリ（ＲＡＭ１６）の空き記憶容量を演算する。ここで、ＲＡＭ１６の空き記憶容量とは、ＲＡＭ１６の記憶領域のうち、実行中の他のタスクにより占有されておらず、Ｗｅｂブラウザがダウンロード処理に使用可能な領域のサイズのことである。続いてＳ４において、ＷｅｂブラウザはＲＡＭ１６の空き記憶容量と、曲名１のダウンロードに必要なメモリ使用量とを比較する。必要なメモリ使用量はｃａｃｈｅ＿ｓｉｚｅ属性の値を参照すると１００Ｋバイトであることがわかる。ここで、ＲＡＭ１６において現在使用可能なメモリ容量が１００Ｋバイト以下である場合には、ＷｅｂブラウザはＲＡＭ１６内のキャッシュ領域不足と判断し、“ダウンロードするためのメインメモリの空き記憶容量がありません！！”とのエラーメッセージを表示した後、以降の処理を中断する。ここでも、ステップＳ２と同様に、メモリ容量の過不足の判断基準に一定のマージンを設けてもよい。
【００４１】
ハードディスク１０の空き記憶容量及びＲＡＭ１６の空き記憶容量ともに十分であると判断すると、ＷｅｂブラウザはステップＳ５に進み、ｈｒｅｆ属性により指定されているファイルｍｕｓｉｃ１．ｄａｔをダウンロードするよう処理する。このときＷｅｂブラウザは、オーディオ装置内の通信インターフェイスに、サイト“ｗｗｗ．ｘｘｘ．ｙｙｙ．ｚｚｚ”のディレクトリ“ｄｏｗｎｌｏａｄ”にある“ｍｕｓｉｃ１．ｄａｔ”というファイルを取得するという要求を送信すると、通信インターフェイスはこの要求をＴＣＰ／ＩＰプロトコルに従ってモデム１８を通じてインターネットに送信する。また、Ｗｅｂブラウザ上でのダウンロード処理方式等は、Ｗｅｂブラウザが実装するＨＴＴＰプロトコルに従うものとする。例えば、ダウンロード要求はＨＴＴＰ　ＧＥＴメソッド又はＨＴＴＰ　ＰＯＳＴメソッドにより行うことができる。
ステップＳ５において、ファイル“ｍｕｓｉｃ１．ｄａｔ”のファイルダウンロードが終了すると、Ｗｅｂサーバはこのファイルをハードディスク１０の所定の場所に記憶し、全ての処理が終了となる。
【００４２】
以上に説明した本実施形態のオーディオ装置によれば、コンテンツデータをダウンロードする前に、ＨＴＭＬデータに含まれるハイパーリンクタグの各属性から、ダウンロードに必要なハードディスク及びメインメモリの空き記憶容量に関する情報を取得するので、空き記憶容量不足の場合には、無駄にダウンロードを行うことなく、処理を中断することができる。また、Ｗｅｂブラウザがハードディスク又はメインメモリの空き記憶容量が不足していることをユーザに警告するので、ユーザはハードディスクから不要なデータを削除したり、実行中のタスクを中断又は終了させることにより、ダウンロードに必要な環境を整えてから再度コンテンツデータをダウンロードすることができる。
【００４３】
上記のオーディオ装置の実施形態では、ハードディスク又はメインメモリにおいてダウンロードに必要な空き記憶容量が不足している場合には、ダウンロード処理を中断しているが、以下に示す本発明の他の実施形態では、この後もダウンロード処理を続行することが可能である。
【００４４】
本発明の他の実施形態において、Ｗｅｂブラウザは、ハードディスク又はメインメモリがダウンロードに必要な空き記憶容量を有していないと判断すると、ハードディスク又はメインメモリの空き記憶容量を増やすためのプログラムを実行する。このプログラムは、プログラムＲＯＭ又はハードディスク内に格納されていてもよく、あるいはダウンロード先のＷｅｂサーバから取得するようにしてもよい。
【００４５】
ここで、上記ハードディスクの空き記憶容量を増やすためのプログラムとは、オーディオ装置において次のような操作を行うプログラムのことである。例えば、ハードディスク内の削除可能なファイル（ごみ箱等に入っているファイル）を削除する、ハードディスク内の所定のファイルを圧縮する、ハードディスク内の所定のファイルをメモリカード等の他の媒体に移動する（メモリカードにコピーした後ハードディスクから消去する）、重複するファイルを１つにするなどの操作を行うことにより、ハードディスクの空き記憶容量を増加させることができる。
【００４６】
また、上記メインメモリの空き記憶容量を増やすためのプログラムとは、オーディオ装置において次のような操作を行うプログラムのことである。例えば、メインメモリに格納されているデータ配置を整理する、ハードディスク上にキャッシュメモリを設けメインメモリ内のデータの一部を待避させる、中断可能なタスクを中断する、現在実行中のタスクのうちユーザが選択したタスクを終了するなどの操作を行うことにより、メインメモリの空き記憶容量を増加させることができる。
【００４７】
上記の操作を行った後、Ｗｅｂブラウザは再び、ハードディスク又はメインメモリがダウンロードに必要な空き記憶容量を有しているかどうかをチェックし、十分な空き記憶容量がある場合には、次のステップの処理に移行することができる。
【００４８】
図５は、上記他の実施形態においてＷｅｂブラウザがコンテンツをダウンロードするときの動作を示すフローチャート図である。図５において、ステップＳ１、Ｓ２、Ｓ５、Ｓ６及びＳ９については、図４のフローチャート図における対応するステップと同様であるので、説明を省略する。
【００４９】
図５に示すフローチャート図のステップＳ２において、Ｗｅｂブラウザはハードディスクの空き記憶容量が不足していると判断すると、ステップＳ３に進み、上記ハードディスクの空き記憶容量を増やすためのプログラムを実行する。このプログラムの実行は、ユーザの指示により、又はユーザによる設定等により自動的に行われるものである。その後、ステップＳ４において、Ｗｅｂブラウザは再びハードディスクの空き記憶容量の過不足を判断し、十分な空き記憶容量がある場合にはステップＳ５に進みダウンロード処理を続行する。上記プログラムを実行しても十分な空き記憶容量が確保できなかった場合には、エラーメッセージを表示してダウンロード処理を中断する。
【００５０】
また、図５に示すフローチャート図のステップＳ６において、Ｗｅｂブラウザはメインメモリの空き記憶容量が不足していると判断すると、ステップＳ７に進み、上記メインメモリの空き記憶容量を増やすためのプログラムを実行する。その後、ステップＳ８において、Ｗｅｂブラウザは再びメインメモリの空き記憶容量の過不足を判断し、十分な空き記憶容量がある場合にはステップＳ９に進みダウンロード処理を続行する。上記プログラムを実行しても十分な空き記憶容量が確保できなかった場合には、エラーメッセージを表示してダウンロード処理を中断する。
【００５１】
以上に示した本発明の他の実施形態によれば、コンテンツデータのダウンロードに必要な記憶容量がハードディスク又はメインメモリに残っていない場合であっても、ダウンロード開始前に、ハードディスク又はメインメモリ空き記憶容量を増やすプログラムを実行することにより、当該コンテンツデータのダウンロードが可能となるようオーディオ装置を調整することができる。
【００５２】
以上の実施形態では、クライアントとしてデジタルオーディオ装置を用いる例を示したが、本発明のサーバ・クライアント形式のダウンロードシステムにおいては、クライアント側に、上記オーディオ装置と同等の機能を有するパーソナルコンピュータや他のデジタルＡＶ機器を用いることができる。
【００５３】
本発明のさらに他の実施形態として、クライアントにパーソナルコンピュータを用いることもできる。本発明に用いるパーソナルコンピュータは、図２に示す構成を有する上記実施形態のオーディオ装置とほぼ同等の構成部分及び機能を備えることができる。パーソナルコンピュータを用いれば、上記のＷｅｂブラウザや他のプログラムにはより複雑なものを用いることが可能となり、また表示画面の自由度も高くなるという利点がある。
【００５４】
本発明のダウンロードシステムには、上記以外にも様々な代替例を応用することができる。例えば、コンテンツ配信サイトを記述するマークアップ言語は、ＨＴＭＬのみならず、ＸＭＬ（ｅＸｔｅｎｓｉｖｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）等のデータ構造記述言語を用いることができる。ＸＭＬはＨＴＭＬよりも拡張性の高いマークアップ言語であり、多様化するコンテンツ配信サービスに適したマークアップ言語であるといえる。尚、インターネットのＴＣＰ／ＩＰプロトコル上でＸＭＬデータを送受信するためのプロトコルには、ＸＭＬＰ、ＳＯＡＰなどを用いることができる。
【００５５】
また、本発明に用いるハイパーリンクタグの属性は、上記以外にも様々に拡張することが可能である。例えば、サーバが配信するコンテンツの著作権情報を示す属性を含むことにより、著作権保護の観点からも信頼性の高いコンテンツ配信サービスを実施することができる。
【００５６】
また、本発明のダウンロードシステムは、時間的条件、地理的条件、ユーザ固有の事情等により大きく変化する通信環境にも柔軟に対応することができる。例えば、属性“ｃａｃｈｅ＿ｓｉｚｅ”はファイルサイズに応じて決まる所定の値に設定してもよいが、ダウンロード使用とする時点でのクライアント機器の環境、通信回線の状態等に応じて変化するようにすれば、さらに確実にダウンロードを行うことができる。
【００５７】
以上、本発明のクライアント・サーバ形式のダウンロードシステムを、実施形態に沿って説明したが、本発明はこれらの実施形態に限定されるものではなく、本発明の各構成部分、利用形態等については、本発明の要旨を逸脱しない範囲内において種々変更を加えることができる。
【００５８】
【発明の効果】
以上、説明したように本発明のクライアント・サーバ形式のダウンロードシステムによれば、Ｗｅｂサーバがダウンロードを開始する前に、ダウンロードするコンテツの情報を取得し、該情報に基づいて、記憶装置及びメインメモリに十分な残り記憶容量があるかどうかをチェックするので、記憶容量不足のためにダウンロードが途中停止してしまったり、途中までのダウンロードにかかった時間が無駄となってしまったりするような事態を避けることができる。
【００５９】
また、マルチタスク動作のコンピュータにおいてダウンロードする場合にも、他のタスクの実行によるＣＰＵやメインメモリのリソース不足のために、ダウンロードに障害が及ぶことがないよう、ダウンロード前に調整することができる。
さらに、本発明のダウンロードシステムでは、サーバが配信するコンテンツに当該コンテンツの著作権情報を含めることにより、合法性の高いコンテンツ配信サービスを実施することができる。
【図面の簡単な説明】
【図１】クライアント・サーバ形式ダウンロードシステムの一形態の構成を示す概念図である。
【図２】本発明の一実施形態においてクライアントとして用いるオーディオ装置の構成を概略的に示す機能ブロック図である。
【図３】コンテンツ配信サイトの一画面のＷｅｂブラウザによる表示例を示す図である。
【図４】オーディオ装置のＷｅｂブラウザがコンテンツをダウンロードするときの動作を示すフローチャート図である。
【図５】本発明の他の実施形態において、オーディオ装置のＷｅｂブラウザがコンテンツをダウンロードするときの動作を示すフローチャート図である。
【符号の説明】
１　　　　サーバ
２　　　　ネットワーク
３　　　　クライアント
１０　　ハードディスク
１１　　メモリカードスロット
１２　　表示部
１３　　ユーザインターフェイス部
１４　　プログラムＲＯＭ
１５　　ＣＰＵ
１６　　ＲＡＭ
１７　　オーディオ再生部
１８　　モデム
１９　　システムバス

Claims

クライアント・サーバ形式のダウンロードシステムに用いるマークアップ言語であって、サーバがクライアントに送信する送信データに関する情報を記述可能であることを特徴とするマークアップ言語。
前記送信データに関する情報は、クライアントにおいて前記送信データをダウンロードするのに必要な記憶容量に関する情報を含むことを特徴とする請求項１に記載のマークアップ言語。
前記送信データに関する情報は、クライアントにおいて前記送信データをダウンロードするのに必要なメモリ容量に関する情報を含むことを特徴とする請求項１に記載のマークアップ言語。
前記送信データに関する情報は、クライアントにおいて前記送信データを記憶する手段に関する情報を含むことを特徴とする請求項１に記載のマークアップ言語。
前記マークアップ言語はＨＴＭＬであり、前記送信データに関する情報はハイパーリンク要素に付随することを特徴とする請求項１から４のいずれか一項に記載のマークアップ言語。
前記マークアップ言語はＸＭＬであり、前記送信データに関する情報はハイパーリンク要素に付随することを特徴とする請求項１から４のいずれか一項に記載のマークアップ言語。
クライアント・サーバ形式のダウンロードシステムにおいてクライアントがダウンロードを制御する方法であって、
クライアントはサーバから送信データに関する情報を取得し、該情報に基づいて前記送信データを受信するか否かを決定することを特徴とする方法。
サーバからダウンロードを行うクライアント装置であって、前記サーバから送信されるマークアップ言語を処理する手段と、
前記マークアップ言語に含まれる情報に基づいて、前記サーバからのデータの受信を制御する手段とを有することを特徴とするクライアント装置。
クライアントにデータを提供するサーバ装置であって、
前記データに関する情報をマークアップ言語によりクライアントに提供することを特徴とするサーバ装置。
ネットワークを通じてデータを送受信するクライアント・サーバ形式のダウンロードシステムであって、
サーバは、送信データに関する情報をクライアントに提供することを特徴とするダウンロードシステム。
前記クライアントは、前記送信データに関する情報に基づいて前記送信データを受信するか否かを決定することを特徴とする請求項１０に記載のダウンロードシステム。
前記送信データに関する情報は、前記送信データのサイズに関する情報を含むことを特徴とする請求項１０に記載のダウンロードシステム。
前記送信データに関する情報は、クライアントが前記送信データを受信するのに必要とするメモリ容量に関する情報を含むことを特徴とする請求項１０に記載のダウンロードシステム。
前記送信データに関する情報は、クライアントにおいて前記送信データを記憶する手段に関する情報を含むことを特徴とする請求項１０に記載のダウンロードシステム。
前記クライアントは、前記クライアントの記憶装置の空き記憶容量を増加させる手段を有し、前記送信データに関する情報に基づいて前記手段を実行することを特徴とする請求項１０に記載のダウンロードシステム。
前記クライアントは、前記クライアントのメインメモリの空き記憶容量を増加させる手段を有し、前記送信データに関する情報に基づいて前記手段を実行することを特徴とする請求項１０に記載のダウンロードシステム。