(57)【要約】      （修正有）【課題】サーバが記憶していないコンテンツであっても、そのサーバからコンテンツを取得して閲覧することができるシステムを提供する。【解決手段】閲覧者ＰＣ１２０からサーバ１００にコンテンツが要求されると、そのコンテンツがサーバの記憶部１０２に記憶されていない場合に、その要求されたコンテンツを作成者のＰＣ１１０に要求して取得する。こうしてその要求されたコンテンツを作成者のＰＣ１１０から取得するか、或は記憶部１０２から読み出して閲覧者のＰＣ１２０に送信する。【選択図】図１
2009146226.tif 000002
【特許請求の範囲】
【請求項１】
サーバ装置及びコンテンツ提供端末及び閲覧端末を具備し、前記コンテンツ提供端末から提供されるコンテンツファイルを前記サーバ装置を介して前記閲覧端末に配信する情報処理システムであって、
前記サーバ装置は、
コンテンツファイルを記憶する記憶手段と、
前記記憶手段に記憶されたコンテンツファイルに関する情報を記述するコンテンツ更新情報を作成するコンテンツ更新情報作成手段と、
前記閲覧端末からのコンテンツ更新情報の要求に応じてコンテンツ更新情報を前記閲覧端末に送信する送信手段と、
前記コンテンツ更新情報に基づいて前記閲覧端末から要求されるコンテンツファイルが前記記憶手段に記憶されていない場合に、前記要求されたコンテンツファイルを前記コンテンツ提供端末に要求して取得する取得手段と、
前記閲覧端末から要求されたコンテンツファイルを、前記取得手段により取得するか、或は前記記憶手段から読み出して前記閲覧端末に送信するコンテンツ送信手段とを有し、
前記閲覧端末は、
前記サーバ装置からコンテンツ更新情報を受信して表示する表示手段と、
前記表示手段に表示されたコンテンツ更新情報に基づいて前記サーバ装置にコンテンツファイルを要求するコンテンツ要求手段と、
前記コンテンツ要求手段で要求したコンテンツファイルを前記サーバ装置から受信するコンテンツ受信手段と、
を有することを特徴とする情報処理システム。
【請求項２】
前記コンテンツ更新情報は、ＲＳＳ規格にのっとって記述されたＸＭＬ文書で記述されていることを特徴とする請求項１に記載の情報処理システム。
【請求項３】
前記コンテンツ更新情報は、前記記憶手段に記憶されたコンテンツファイルと前記コンテンツ提供端末が有するコンテンツファイルとを識別可能な情報を含むことを特徴とする請求項１又は２に記載の情報処理システム。
【請求項４】
前記閲覧端末は、ＵＲＬにアクセスしてコンテンツ更新情報を受信し、
前記サーバ装置は、前記閲覧端末からの要求に応じて前記記憶手段に記憶されたコンテンツファイルを示すＵＲＬを作成して当該閲覧端末に送信し、
前記閲覧端末は次回の要求の際に前記ＵＲＬを使用することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
【請求項５】
前記サーバ装置は、
前記記憶手段に記憶されているコンテンツファイルを管理し、前記記憶手段における前記コンテンツ提供端末からのコンテンツファイルの容量を所定量に制限するコンテンツ管理手段を更に有することを特徴とする請求項１乃至４のいずれか１項に記載の情報処理システム。
【請求項６】
前記コンテンツ提供端末は、当該コンテンツ提供端末のネットワークアドレスを前記サーバ装置に送信する手段を有することを特徴とする請求項１乃至５のいずれか１項に記載の情報処理システム。
【請求項７】
前記サーバ装置は、前記記憶手段に記憶されているコンテンツファイルの記憶状況が変化したときに前記コンテンツ更新情報を更新する更新手段を更に有することを特徴とする請求項１乃至６のいずれか１項に記載の情報処理システム。
【請求項８】
サーバ装置及びコンテンツ提供端末及び閲覧端末を具備し、前記コンテンツ提供端末から提供されるコンテンツファイルを前記サーバ装置により前記閲覧端末に配信する情報処理システムで使用されるサーバ装置であって、
コンテンツファイルを記憶する記憶手段と、
前記記憶手段に記憶されたコンテンツファイルに関する情報を記述するコンテンツ更新情報を作成するコンテンツ更新情報作成手段と、
前記閲覧端末からのコンテンツ更新情報の要求に応じてコンテンツ更新情報を前記閲覧端末に送信する送信手段と、
前記コンテンツ更新情報に基づいて前記閲覧端末から要求されるコンテンツファイルが前記記憶手段に記憶されていない場合に、前記要求されたコンテンツファイルを前記コンテンツ提供端末に要求して取得する取得手段と、
前記閲覧端末から要求されたコンテンツファイルを、前記取得手段により取得するか、或は前記記憶手段から読み出して前記閲覧端末に送信するコンテンツ送信手段と、
を有することを特徴とするサーバ装置。
【請求項９】
サーバ装置及びコンテンツ提供端末及び閲覧端末を具備し、前記コンテンツ提供端末から提供されるコンテンツファイルを前記サーバ装置により前記閲覧端末に配信する情報処理システムの制御方法であって、
前記閲覧端末から前記サーバ装置に対して、前記サーバ装置が有しているコンテンツファイルのコンテンツ更新情報を要求する工程と、
前記閲覧端末からのコンテンツ更新情報の要求に応じてコンテンツ更新情報を前記閲覧端末に送信する工程と、
前記閲覧端末が、前記サーバ装置からコンテンツ更新情報を受信して表示する工程と
前記表示したコンテンツ更新情報に基づいて、前記閲覧端末から前記サーバ装置にコンテンツファイルを要求する工程と、
前記コンテンツ更新情報に基づいて前記閲覧端末から要求されるコンテンツファイルが前記サーバ装置の記憶部に記憶されていない場合に、当該要求されたコンテンツファイルを前記コンテンツ提供端末に要求して取得する取得工程と、
前記閲覧端末から要求されたコンテンツファイルを、前記取得工程で取得するか、或は前記記憶部から読み出して、前記サーバ装置から前記閲覧端末に送信する工程と
を有することを特徴とする情報処理システムの制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、文章・静止画・動画・音楽などのコンテンツファイルを配信・閲覧する情報処理システム及びそのサーバ装置と、その制御方法に関する。
【背景技術】
【０００２】
ＰＣやデジタルカメラ、デジタルビデオの普及に伴い、個人が作成或は撮影した文章、静止画、動画、音楽等のコンテンツを、インターネットを通じて配信することが多く行われるようになった。コンテンツの作成者は、作成したコンテンツを、常時インターネットに接続されて稼動しているコンピュータ（以下、サーバ）の記憶領域にアップロードする。一方、コンテンツの閲覧者は、このサーバにアクセスして、欲しいコンテンツをダウンロードし、閲覧する。
【０００３】
サーバ及びコンテンツのアップロードやダウンロードに関して、現在最も普及しているのは、ウェブを用いたサービスである。また近年では、サーバにブログ機能やアルバム機能を搭載して、一般のコンテンツ作成者が容易にコンテンツを更新してアップロードできるサービスが増えている。
【０００４】
このようなサーバでは、現在どのようなコンテンツが搭載されているかをＲＳＳと呼ばれる規格を用いて記述し、閲覧者に便宜を図っているものもある。ＲＳＳ規格では、ウェブサイトの更新内容を簡単にまとめて配信するＸＭＬベースのフォーマット（ＸＭＬ文書）を用いてＲＳＳファイルを作成するよう定められている。ＲＳＳを使用しているサーバのコンテンツを閲覧するコンテンツ閲覧者は、まずＲＳＳリーダと呼ばれるプログラムを用いて、サーバ上にあるＲＳＳ規格に則って記述されたファイル（以下、ＲＳＳファイル）を定期的に受信する。ＲＳＳリーダは、その受信したＲＳＳファイルを解析し、そのサーバにどのようなコンテンツが更新されたかを閲覧者に提示する。これによってコンテンツ閲覧者は、一々サーバにアクセスすることなく、そのサーバにどのようなコンテンツがあり、そのコンテンツが更新されたかを知ることができる。
【０００５】
図１４は、上述した従来のコンテンツ配信システムを説明する図である。
【０００６】
ＰＣ１５０１はコンテンツ作成者のＰＣ、１５０２はサーバ、ＰＣ１５０３はコンテンツ閲覧者のＰＣである。コンテンツ作成者のＰＣ１５０１は、そのコンテンツ作成者が作成したコンテンツ１５０４を記憶している。そしてコンテンツ作成者は、このコンテンツ１５０４をサーバ１５０２の記憶領域１５０５にアップロードする。これによりサーバ１５０２で動作しているアプリケーションが、そのサーバ１５０２でのコンテンツの変更に対応してＲＳＳファイル１５０６を生成する。
【０００７】
一方、閲覧者のＰＣ１５０３では、ＲＳＳリーダ１５０７が定期的にサーバ１５０２にアクセスしてＲＳＳファイル１５０６を取得し、閲覧者に対して、サーバ１５０２のコンテンツの更新を提示する。そして閲覧者は、気に入ったコンテンツがあれば、ウェブブラウザなどを用いてサーバ１５０２にアクセスし、そのコンテンツを取得して閲覧することができる。
【特許文献１】特開２００３−１８６７８５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
図１６に示した従来技術では、コンテンツ作成者のＰＣ１５０１は、ネットワークに接続されて常時稼動しているサーバ１５０２に、全てのコンテンツをアップロードする必要がある。多くの場合、サーバはユーザ一人当たりの記憶容量を制限している。このため、コンテンツ数が多い場合や、動画のような容量の大きなコンテンツをアップロードする場合には、そのサーバにおけるコンテンツ総量が、一人当たりの記憶容量を超えてしまう場合がある。
【０００９】
また、コンテンツ作成者のＰＣの全てのコンテンツをサーバにアップロードするのではなく、コンテンツの一部のみをアップロードするというアイデアが存在する。例えば、特許文献１では、ローカルサーバはコンテンツの一部しか持たない。そして、もし閲覧者がローカルサーバ上にないコンテンツの閲覧を希望した場合は、ローカルサーバは、そのコンテンツをメインサーバから取得して閲覧者のＰＣに送信する。
【００１０】
しかし、このようなシステムでは、全てのコンテンツを記憶し、常時ネットワークに接続されて稼動しているメインサーバを用意しなければならない。一般ユーザにとって、そのようなサーバを用意することは容易ではない。
【００１１】
本発明の目的は、上記従来技術の問題点を解決することにある。
【００１２】
本願発明の特徴は、サーバが記憶していないコンテンツであっても、閲覧者が、そのサーバからコンテンツを取得して閲覧することができることにある。
【課題を解決するための手段】
【００１３】
上記目的を達成するために本発明の一態様に係る情報処理システムは以下のような構成を備える。即ち、
サーバ装置及びコンテンツ提供端末及び閲覧端末を具備し、前記コンテンツ提供端末から提供されるコンテンツファイルを前記サーバ装置により前記閲覧端末に配信する情報処理システムであって、
前記サーバ装置は、
コンテンツファイルを記憶する記憶手段と、
前記記憶手段が記憶しているコンテンツファイルを記述するコンテンツ更新情報を作成するコンテンツ更新情報作成手段と、
前記閲覧端末からのコンテンツ更新情報の要求に応じてコンテンツ更新情報を前記閲覧端末に送信する送信手段と、
前記コンテンツ更新情報に基づいて前記閲覧端末から要求されるコンテンツファイルが前記記憶手段に記憶されていない場合に、前記要求されたコンテンツファイルを前記コンテンツ提供端末に要求して取得する取得手段と、
前記閲覧端末から要求されたコンテンツファイルを、前記取得手段により取得するか、或は前記記憶手段から読み出して前記閲覧端末に送信するコンテンツ送信手段とを有し、
前記閲覧端末は、
前記サーバ装置からコンテンツ更新情報を受信してユーザに表示するコンテンツ情報閲覧手段と、
前記コンテンツ情報閲覧手段に表示したコンテンツ更新情報に基づいて前記サーバ装置にコンテンツファイルを要求するコンテンツ要求手段と、
前記コンテンツ要求手段で要求したコンテンツファイルを前記サーバ装置から受信するコンテンツ受信手段と、
前記コンテンツ受信手段により受信したコンテンツファイルを表示するコンテンツ表示手段と、を有することを特徴とする。
【００１４】
上記目的を達成するために本発明の一態様に係るサーバ装置は以下のような構成を備える。即ち、
サーバ装置及びコンテンツ提供端末及び閲覧端末を具備し、前記コンテンツ提供端末から提供されるコンテンツファイルを前記サーバ装置により前記閲覧端末に配信する情報処理システムで使用されるサーバ装置であって、
コンテンツファイルを記憶する記憶手段と、
前記記憶手段が記憶しているコンテンツファイルを記述するコンテンツ更新情報を作成するコンテンツ更新情報作成手段と、
前記閲覧端末からのコンテンツ更新情報の要求に応じてコンテンツ更新情報を前記閲覧端末に送信する送信手段と、
前記コンテンツ更新情報に基づいて前記閲覧端末から要求されるコンテンツファイルが前記記憶手段に記憶されていない場合に、前記要求されたコンテンツファイルを前記コンテンツ提供端末に要求して取得する取得手段と、
前記閲覧端末から要求されたコンテンツファイルを、前記取得手段により取得するか、或は前記記憶手段から読み出して前記閲覧端末に送信するコンテンツ送信手段とを有することを特徴とする。
【００１５】
上記目的を達成するために本発明の一態様に係る情報処理システムの制御方法は以下のような工程を備える。即ち、
サーバ装置及びコンテンツ提供端末及び閲覧端末を具備し、前記コンテンツ提供端末から提供されるコンテンツファイルを前記サーバ装置により前記閲覧端末に配信する情報処理システムの制御方法であって、
前記閲覧端末から前記サーバ装置に対して、前記サーバ装置が有しているコンテンツファイルのコンテンツ更新情報を要求する工程と、
前記閲覧端末からのコンテンツ更新情報の要求に応じてコンテンツ更新情報を前記閲覧端末に送信する工程と、
前記閲覧端末が、前記サーバ装置からコンテンツ更新情報を受信してユーザに表示する工程と
前記表示したコンテンツ更新情報に基づいて、前記閲覧端末から前記サーバ装置にコンテンツファイルを要求する工程と、
前記コンテンツ更新情報に基づいて前記閲覧端末から要求されるコンテンツファイルが前記サーバ装置の記憶部に記憶されていない場合に、当該要求されたコンテンツファイルを前記コンテンツ提供端末に要求して取得する取得工程と、
前記閲覧端末から要求されたコンテンツファイルを、前記取得工程で取得するか、或は前記記憶部から読み出して、前記サーバ装置から前記閲覧端末に送信する工程と、
前記閲覧端末が、前記要求したコンテンツファイルを前記サーバ装置から受信して表示する工程とを有することを特徴とする。
【発明の効果】
【００１６】
本発明によれば、コンテンツ提供者は常にサーバ装置にコンテンツファイルを記憶していなくても、閲覧者端末にコンテンツファイルをサーバ装置を介して提供できる。
【発明を実施するための最良の形態】
【００１７】
以下、添付図面を参照して本発明の好適な実施の形態を詳しく説明する。尚、以下の実施の形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施の形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。
【００１８】
図１は、本発明の実施の形態に係るコンテンツ提供システム（情報処理システム）の構成を説明する図である。
【００１９】
１００はサーバ装置であり、１１０はコンテンツ作成者のパーソナルコンピュータ装置（ＰＣ、コンテンツ提供端末）であり、１２０はコンテンツ閲覧者のＰＣ（閲覧端末）である。ネットワーク１３０は、サーバ１００とＰＣ１１０、サーバ１００とＰＣ１２０を接続するネットワークである。
【００２０】
サーバ１００において、記憶部１０２（コンテンツデータベース（ＤＢ））は、コンテンツファイルを記憶するハードディスクドライブや、ＤＶＤ−ＲＡＭ等の書き込み可能な記憶メディアである。コンテンツ管理部１０３は、記憶部１０２に記憶されるコンテンツファイルの検索・追加・削除などを行う。尚、本実施の形態では、サーバ１００のコンテンツ管理部１０３は、コンテンツＤＢを用いてコンテンツファイルを管理する。
【００２１】
図１３は、コンテンツＤＢの一例を示す図である。
【００２２】
図１３では、コンテンツファイルを一意に識別するためのＩＤ、ファイル名、作成者のＰＣ１１０からアップロードされた時刻（アップロード時刻）、閲覧者のＰＣ１２０にダウンロードされた回数（参照回数）を記憶している。更に、サーバ１００の記憶部１０２におけるファイルパス（データのアドレス）を関連付けることによりコンテンツファイルを管理している。
【００２３】
ＲＳＳファイル受信部１０４は、ＲＳＳファイルを受信して記憶部１０２に保存する。本実施の形態のＲＳＳファイルは、コンテンツ作成者のＰＣ１１０に記憶されているコンテンツファイルの内容や、サーバ１００に記憶されているコンテンツ作成者のコンテンツファイルの更新を示すフィード（Feed）である。ここでは一例としてＲＳＳのファイルフォーマットを有するものとする。
【００２４】
コンテンツ受信部１０５は、コンテンツ作成者のＰＣ１１０からコンテンツファイルを受信して記憶部１０２に記憶する。ＲＳＳファイル送信部１０６は、記憶部１０２に記憶されているＲＳＳファイル（コンテンツ更新情報）を閲覧者のＰＣ１２０に送信する。コンテンツ送信部１０７は、記憶部１０２に記憶されているコンテンツファイルを読み出して閲覧者のＰＣ１２０に送信する。これら１０４〜１０７で示される各部は、ネットワーク１３０を通じて他のコンピュータと通信を行うもので、実際にはネットワークカード等で構成される。ＲＳＳファイル作成部（コンテンツ更新情報作成部）１０８は、サーバ１００の記憶部１０２にどのようなコンテンツファイルが記憶されているか（記憶状況）をコンテンツ管理部１０３から取得してＲＳＳファイルを作成する。
【００２５】
尚、上述したサーバ１００の各機能を実行する各部は、サーバ１００のＣＰＵ、メモリ及びハードディスク、及びそこに記憶されたプログラム等により実現される。これは以下の実施の形態２，３でも同様である。
【００２６】
次にコンテンツ作成者のＰＣ１１０について説明する。
【００２７】
記憶部１１２はコンテンツファイルを記憶しており、ハードディスクドライブやＤＶＤ−ＲＡＭ等の書き込み可能な記憶メディアなどで構成される。操作部１１３は、ユーザからの入力操作を受け付けるもので、キーボードやマウス等を含んでいる。ＲＳＳファイル作成部１１４は、記憶部１１２に記憶されたコンテンツファイルの内容を表す作成者のＲＳＳファイルを作成する。ＲＳＳファイル送信部１１５は、ＲＳＳファイル作成部１１４で作成した作成者ＲＳＳファイルをサーバ１００に送信する。コンテンツ送信部１１６は、記憶部１１２に記憶されたコンテンツファイルを送信する。ＲＳＳファイル送信部１１５及びコンテンツ送信部１１６は、ネットワーク１３０を通じて他のコンピュータと通信を行うもので、実際にはネットワークカード等で構成される。コンテンツ作成者は、操作部１１３による操作で、コンテンツ送信部１１６を用いて、作成したコンテンツファイルをサーバ１００に送信する。
【００２８】
これによりサーバ１００は、コンテンツ受信部１０５を用いて、コンテンツ作成者のＰＣ１１０からコンテンツファイルを受信して記憶部１０２に記憶するとともにコンテンツ管理部１０３で管理する。また、ＲＳＳファイル作成部１０８は、その記憶部１０２のコンテンツファイルの更新に応じてサーバのＲＳＳファイルの内容を書き換える。サーバＲＳＳファイルはアドレス（ＵＲＬ：Universal Resource Locator）に関連づけて記憶部１０２に記憶される。
【００２９】
次にコンテンツ閲覧者のＰＣ１２０について説明する。
【００３０】
記憶部１２２は、サーバ１００から受信したコンテンツファイルを記憶する、ハードディスクドライブや、ＤＶＤ−ＲＡＭ等の書き込み可能な記憶メディアである。操作部１２３は、ユーザからの入力を受け付ける入力部で、キーボードやマウス等を有している。表示部１２４は、ＲＳＳファイルに記述されているコンテンツ一覧情報及びコンテンツファイルを表示する。この表示部１２４は、ディスプレイ及びスピーカ等、或はそれらをＰＣ１２０に接続するためのインタフェースを具備しており、コンテンツ一覧画面の表示、コンテンツファイルの表示で使用される。ＲＳＳファイル受信部１２５は、サーバ１００からＲＳＳファイルを受信して記憶部１２２に記憶する。
【００３１】
本実施の形態に係るＲＳＳファイル受信部１２５はＲＳＳリーダを備え、サーバ１００が配信するＲＳＳファイルを定期的に取得する。そして、ＲＳＳファイルが更新されていれば、その旨を表示部１２４に表示するなどして閲覧者に通知する。尚、本実施の形態では、フィードリーダの一例として、ＲＳＳのファイルフォーマットを有するフィードを取得するＲＳＳリーダを用いる場合について説明する。
【００３２】
コンテンツ受信部１２６は、サーバ１００からコンテンツファイルを受信して記憶部１２２に記憶する。ＲＳＳファイル受信部１２５とコンテンツ受信部１２６は、ネットワーク１３０を通じて他のコンピュータと通信を行うもので、ネットワークカード等で構成される。
【００３３】
次に図２及び図３を参照して、コンテンツ閲覧者のＰＣ１２０が如何にしてコンテンツファイルを取得するかを説明する。
【００３４】
図２は、本実施の形態に係るサーバ、コンテンツ作成者のＰＣ、コンテンツ閲覧者のＰＣとの間の通信シークエンスを説明する図である。図おいて、コンテンツ作成者のＰＣ１１０がサーバ１００からアクセス可能な状態でのサーバ１００とコンテンツ作成者のＰＣ１１０との間、及びサーバ１００とコンテンツ閲覧者のＰＣ１２０との間での通信シークエンスを表わしている。尚、図２では図１と同様の構成については同一の符号を付与し、以下、それらの説明を省略する。
【００３５】
閲覧者のＰＣ１２０には、サーバ１００から送信されるＲＳＳファイル１０１を解析してコンテンツ一覧を表示部１２４に表示するＲＳＳリーダ１２７がインストールされており、動作している。また作成者のＰＣ１１０の記憶部１１２には、ＲＳＳファイル作成部１１４によって、記憶部１１２の全てのコンテンツファイルに関する情報を含むよう作成されたＲＳＳファイル１１７（以下、作成者ＲＳＳファイル）が記憶されている。また作成者のＰＣ１１０には、ウェブサーバプログラム１１１がインストールされて動作している。
【００３６】
尚、サーバ１００では、コンテンツＤＢ（記憶部１０２）におけるコンテンツ作成者１人当りの記憶容量が制限されている。そのため、コンテンツ作成者が作成した全てのコンテンツファイルをサーバ１００に記憶することができないため、コンテンツ作成者のＰＣ１１０で作成したコンテンツファイルの内、一部のコンテンツファイルだけが記憶部１０２に記憶されている。また記憶部１０２には、ＲＳＳファイル作成部１０８が作成したＲＳＳファイル１０１（以下、サーバＲＳＳファイル）が記憶されている。また記憶部１０２には、閲覧者のＰＣ１２０から要求されたコンテンツファイルを特定するためのリクエストリスト１０９が記憶されている。
【００３７】
次にこれらサーバ１００とＰＣ１１０，１２０との間のやり取りについて説明する。
【００３８】
まず閲覧者のＰＣ１２０において、閲覧者のＰＣ１２０のＲＳＳリーダ１２７は、定期的に、予め登録されているＵＲＬに基づき、サーバ１００にアクセスする（２０１）。これによりサーバ１００は、ＵＲＬと対応するサーバＲＳＳファイル１０１を読み出し、ＲＳＳファイル送信部１０６により閲覧者のＰＣ１２０に送信する（２０２）。尚、サーバ１００は、ＲＳＳファイル受信部１０４によって、作成者のＰＣ１１０から作成者ＲＳＳファイル１１７のコピーを受信しており、サーバＲＳＳファイル１０１の初期値として、そのコピーされた作成者ＲＳＳファイル１１７を使用する。
【００３９】
次に閲覧者のＰＣ１２０は、受信したサーバＲＳＳファイル１０１を解析し、サーバ１００に対してコンテンツファイルを要求する（コンテンツ要求：２０３）。ここで閲覧者のＰＣ１２０は、サーバＲＳＳファイル１０１に載っている全てのコンテンツファイルを要求するようにしても良い。また或は、表示部１２４に表示されたコンテンツ一覧をユーザが見て、ダウンロードしたいコンテンツファイルを操作部１２３を用いて指示し、その指示されたコンテンツファイルだけを要求しても良い。また閲覧者のＰＣ１２０は、過去に要求したコンテンツファイルの履歴を記憶しており、サーバＲＳＳファイル１０１に載っているコンテンツファイルの内、過去に要求したことがないコンテンツファイルを要求するようにしても良い。
【００４０】
このときサーバ１００は、その要求されたコンテンツファイルが記憶部１０２に記憶されている場合は、記憶部１０２からそのコンテンツファイルを読み出し、コンテンツ送信部１０７を用いて閲覧者のＰＣ１２０に送信する（２０５）。これにより閲覧者のＰＣ１２０は、コンテンツ受信部１２６を用いてそれを受信し、それを記憶部１２２に記憶する。そして、そのコンテンツを表示部１２４によりコンテンツ表示或は出力する。
【００４１】
一方、その要求されたコンテンツファイルがサーバ１００に記憶されていない場合は、サーバ１００は作成者のＰＣ１１０のウェブサーバプログラム１１１にアクセスして、作成者のＰＣ１１０にそのコンテンツファイルを要求する（２０４）。これにより作成者のＰＣ１１０は、コンテンツ送信部１１６を用いて、そのコンテンツファイルをサーバ１００に送信する（２０６）。これによりサーバ１００は、コンテンツ受信部１０５により、そのコンテンツファイルを受信して取得することができる。そしてサーバ１００は、そのコンテンツファイルをコンテンツ送信部１０７から閲覧者のＰＣ１２０に送信する（２０７）。
【００４２】
こうして閲覧者のＰＣ１２０は、サーバ以外に記憶されているコンテンツファイルをコンテンツ受信部１２６により受信して記憶部１２２に記憶する。そして、そのコンテンツを表示部１２４により表示或は出力する。
【００４３】
図３は、図２の２０４において、コンテンツ作成者のＰＣ１１０がサーバ１００からアクセスできない状態で、サーバ１００とコンテンツ作成者のＰＣ１１０との間、及びサーバ１００とコンテンツ閲覧者のＰＣ１２０との間の通信シークエンスを表す図である。サーバ１００がコンテンツ作成者のＰＣ１１０にアクセスできない理由としては、コンテンツ作成者のＰＣ１１０がネットワーク１３０に接続されていないか、或は電源が入っていない等が考えられる。図３では、前述の図１及び図２と同様の構成については同一の符号を付与し、以下ではそれらの説明を省略する。
【００４４】
コンテンツファイルがサーバ１００になく、図２の２０４で、サーバ１００が作成者のＰＣ１１０にアクセスできない場合は、サーバ１００は、そのコンテンツファイルが要求されたことを記憶部１０２のリクエストリスト１０９に記憶する。
【００４５】
一方、サーバ１００は、作成者のＰＣ１１０に対して、定期的にポーリングを行っている（３０５）。そして作成者のＰＣ１１０がアクセス可能な状態になれば、作成者のＰＣ１１０にアクセスする。そして、リクエストリスト１０９に記憶されている各コンテンツファイルの要求するリクエストを作成者のＰＣ１１０に送信してウェブサーバプログラム１１１に渡す（３０６）。これにより作成者のＰＣ１１０は、その要求に相当するコンテンツファイルをコンテンツ送信部１１６によってサーバ１００に送信する（３０７）。こうしてサーバ１００はコンテンツ受信部１０５によってそれを受信する。こうしてサーバ１００が取得したコンテンツファイルは、サーバ１００の記憶部１０２に記憶される。そしてサーバ１００は現在、記憶部１０２に記憶されているコンテンツファイルの状態に基づいてサーバＲＳＳファイル１０１を更新する。またその取得したコンテンツファイルのＩＤをリクエストリスト１０９から削除しておく。これにより、取得済みのコンテンツファイルを再度作成者のＰＣ１１０に要求することがなくなる。
【００４６】
そして、閲覧者のＰＣ１２０のＲＳＳリーダ１２７がサーバ１００にアクセスして（３０１）、その更新されたサーバＲＳＳファイル１０１を受信する（３０２）。閲覧者のＰＣ１２０は、そのサーバＲＳＳファイル１０１の更新を検知して、そのコンテンツファイルを取得し、その更新されたコンテンツファイルの一覧を表示部１２４に表示する。次に閲覧者がＰＣ１２０で、更新されたコンテンツ一覧に基づいて操作部１２３で操作することにより、閲覧者のＰＣ１２０がコンテンツファイルを要求する（３０３）。これによりサーバ１００は、その要求されたコンテンツファイルを記憶部１０２から読み出し、コンテンツ送信部１０７から閲覧者のＰＣ１２０に送信する（３０４）。尚、図３の３０１〜３０４は、図２の２０１〜２０３，２０５と共通する処理を示している。
【００４７】
次に、図４及び図５のフローチャートを参照して本実施の形態に係るサーバ１００の動作について説明する。
【００４８】
図４は、本実施の形態において、閲覧者のＰＣ１２０からコンテンツファイルの閲覧リクエストを受けたときのサーバ１００の動作を説明するフローチャートである。
【００４９】
まずステップＳ４０１で、閲覧者のＰＣ１２０からのアクセスを受信する（図２の２０１）。次にステップＳ４０２で、ＲＳＳファイル送信部１０６を用いて、サーバＲＳＳファイル１０１を閲覧者のＰＣ１２０に送信する（図２の２０２）。次にステップＳ４０３に進み、閲覧者のＰＣ１２０からコンテンツファイルの閲覧要求を受け取る（図２の２０３）。次にステップＳ４０４に進み、コンテンツ管理部１０３により、その要求されたコンテンツファイルがサーバ１００の記憶部１０２に記憶されているかどうかを調べる。ここでサーバ１００に、そのコンテンツファイルが記憶されているとステップＳ４１５に進み、コンテンツ送信部１０７を用いて、その要求されたコンテンツファイルを閲覧者のＰＣ１２０に送信する。
【００５０】
一方ステップＳ４０４で、その要求されたコンテンツファイルが記憶部１０２に存在しない場合はステップＳ４０５に進み、作成者のＰＣ１１０にアクセス可能かどうか調べる。ここでアクセスできないと判断した場合はステップＳ４０６に進み、そのコンテンツファイルのリクエストがあったことをリクエストリスト１０９に記憶する。そしてステップＳ４０７に進み、閲覧者のＰＣ１２０に、その要求されたコンテンツファイルが取得できなかったことを通知する。
【００５１】
一方、ステップＳ４０５で、作成者のＰＣ１１０にアクセスできると判断した場合はステップＳ４０８に進み、コンテンツ受信部１０５により、作成者のＰＣ１１０から、そのコンテンツファイルを受信する。次にステップＳ４０９に進み、コンテンツ管理部１０３を用いて、そのコンテンツファイルが以前にサーバ１００が取得したものであるかどうかを調べる。もし以前に取得したことがなければステップＳ４１０に進み、そのコンテンツファイルにユニークなＩＤ（識別情報）を割り当てる。そしてステップＳ４１１に進み、コンテンツデータベース（以下、コンテンツＤＢ）に登録する。またステップＳ４０９で、そのコンテンツファイルが以前にサーバ１００が取得したことがあればステップＳ４１１に進んでコンテンツＤＢに登録する。
【００５２】
本実施の形態に係るコンテンツＤＢの具体的な内容例は、前述の図１３に示すデータ構成と同様である。
【００５３】
次にステップＳ４１２に進み、コンテンツ管理部１０３により、新たにコンテンツファイルを取得したことによって、記憶部１０２における、そのコンテンツ作成者の記憶容量の上限値（所定量）を超えたかどうかを判定する。もし超えていればステップＳ４１３に進んで、コンテンツ管理部１０３は、新しいコンテンツファイルが記憶できる記憶容量を確保するために、そのコンテンツ作成者が作成した他のコンテンツファイルを削除する。ここで削除されるコンテンツファイルは、今回リクエストされていないものや、記憶された日時が古いものや、閲覧者のＰＣ１２０に送信された最終日時が古いもの等であっても良い。また或はリクエスト回数が少ないものであっても良く、又はそれ以外の方法で選択しても良い。こうしてコンテンツを削除して空き領域を確保した後、ステップＳ４１２に進み、再度、そのコンテンツ作成者の記憶容量の上限値を超えているかどうかを判定する。そしてステップＳ４１２で、記憶容量の上限値を超えていなければ、コンテンツファイルを記憶部１０２に記憶する。次にステップＳ４１４に進み、サーバ１００はＲＳＳファイル作成部１０８を用いて、現在の記憶部１０２に記憶されたコンテンツファイルと作成者ＲＳＳファイル１１７との比較に基づき、サーバＲＳＳファイル１０１を更新して作成する。そして、その更新されたサーバＲＳＳファイル１０１を閲覧者のＰＣ１２０に送信してＲＳＳリーダ１２７に渡す（２０２，３０２）。そして、その更新されたコンテンツの一覧を表示部１２４に表示させる。コンテンツの一覧には、サーバ１００に存在するコンテンツファイルと作成者のＰＣ１１０には存在するがサーバ１００には存在しないコンテンツファイルとを識別して表示される。その後、閲覧者のＰＣ１２０は、操作部１２３で操作される閲覧者の操作に応答して、コンテンツ一覧の中からコンテンツファイルを選択し、そのコンテンツファイル要求をサーバ１００に送信する（２０３，３０３）。そしてステップＳ４１５に進み、サーバ１００は、閲覧者のＰＣ１２０からのリクエストに応答して、コンテンツ送信部１０７を用いて、その要求されたコンテンツファイルを閲覧者のＰＣ１２０に送信する（２０５，３０４）。
【００５４】
尚、本実施の形態では、サーバ１００がコンテンツファイルを作成者のＰＣ１１０から取得したときに、サーバ１００の記憶部１０２に記憶されるコンテンツファイルの総容量が一時的にコンテンツ作成者の記憶容量の上限値を超えることが考えられる。そこで、サーバ１００の動作として、まずコンテンツファイルを受信する前に作成者のＰＣ１１０にコンテンツファイルの容量を問い合わせる。そして、その容量以上の空き容量をサーバ１００の記憶部１０２に確保した後、作成者のＰＣ１１０から、その要求されたコンテンツファイルを取得するようにしても良い。
【００５５】
図５は、本実施の形態に係るサーバ１００が作成者のＰＣ１１０に対して定期的にポーリングを行う動作を説明するフローチャートである。
【００５６】
まずステップＳ５０１で、作成者のＰＣ１１０にアクセス可能かどうかを調べる。アクセスできないときはそのまま終了する。アクセス可能と判定するとステップＳ５０２に進み、サーバ１００のリクエストリスト１０９に、作成者のＰＣ１１０に要求すべきコンテンツファイルが存在するかどうかを調べる。存在していなければそのまま処理を終了する。ステップＳ５０２で、リクエストリスト１０９に、作成者のＰＣ１１０に要求すべきコンテンツファイルが存在していればステップＳ５０３に進む。ステップＳ５０３では、作成者のＰＣ１１０にアクセスして、そのコンテンツファイルを要求する。次にステップＳ５０４で、その要求に応じて作成者のＰＣ１１０から送信されるコンテンツファイルをコンテンツ受信部１０５により受信して取得する。そしてステップＳ５０５に進み、コンテンツ管理部１０３を用いて、そのコンテンツファイルが以前にサーバ１００が取得したものであるかどうかを調べる。もし以前に取得したことがなければステップＳ５０６に進み、そのコンテンツファイルにユニークなＩＤを割り当てる。次にステップＳ５０７に進み、そのコンテンツファイルをコンテンツＤＢに登録する。また一方、ステップＳ５０５で、そのコンテンツが既に取得したことがあればステップＳ５０７に進んでコンテンツＤＢに登録する。
【００５７】
その後、ステップＳ５０８に進み、再度、その取得したコンテンツファイルを要求しないように、そのコンテンツファイルの情報をリクエストリストから削除する。次にステップＳ５０９に進み、コンテンツ管理部１０３が、新たにコンテンツファイルを取得したことによって、コンテンツ作成者の記憶容量の上限値を超えたかどうかを判定する。もし超えていればステップＳ５１０に進み、既に記憶部１０２に記憶されている、そのコンテンツ作成者が作成した他のコンテンツファイルを削除する。この記憶容量の上限値を超える場合のコンテンツファイルの削除方法は、前述の図４のステップＳ４１３で説明した処理と同様である。こうしてコンテンツファイルを削除した後ステップＳ５０９に進み、もう一度、上限値を越えているか否かを判定する。そしてステップＳ５０９で、記憶容量の上限値を超えていなければコンテンツファイルを保持しておく。そしてステップＳ５１１に進み、サーバ１００はＲＳＳファイル作成部１０８を用いて、現在の記憶部１０２に記憶されたコンテンツファイルと作成者ＲＳＳファイル１１７との比較に基づき、サーバＲＳＳファイル１０１を作成してステップＳ５０２に戻る。
【００５８】
こうして作成者のＰＣ１１０から取得したコンテンツファイルはサーバ１００の記憶部１０２に記憶され、次回、閲覧者のＰＣ１２０が、更新されたサーバＲＳＳファイル１０１に基づき、そのコンテンツファイルをサーバ１００にリクエストする。これによりサーバ１００は、コンテンツ送信部１０７により、その要求されたコンテンツファイルを閲覧者のＰＣ１２０に送信することができる。
【００５９】
本実施の形態１において、サーバ１００がＲＳＳファイル１０１を作成するためには、ＲＳＳファイル作成部１０８は、コンテンツデータベースのエントリを参照してＲＳＳファイル１０１を作成しても良い。また或は、サーバ１００とコンテンツ作成者のＰＣ１１０との通信内容からＲＳＳファイル１０１を作成しても構わない。
【００６０】
また本実施の形態１では、サーバ１００のコンテンツの記憶状態が変化したときにＲＳＳファイル１０１を更新している。しかし、閲覧者のＰＣ１２０からアクセスがあったときにコンテンツの記憶状態の変化を調べて、必要があればＲＳＳファイル１０１を更新するようにしても構わない。
【００６１】
また上記説明では、サーバ１００が新たなコンテンツファイルをコンテンツ作成者のＰＣ１１０から取得したときに、その作成者の記憶容量の上限値を越えた場合に、コンテンツファイルを消去するようにしているが、それ以外の方法も考えられる。例えば、コンテンツＤＢに記憶しているコンテンツファイルのアップロード時間を利用して、アップロードから一定時間経過したコンテンツを順に削除しても構わない。
【００６２】
［実施の形態２］
以下、本発明の実施の形態２について説明する。
【００６３】
図６は、本発明の実施の形態２に係るコンテンツ提供システムの構成を説明する図である。尚、図１と共通しているのものについては同じ符号を付与し、それらの説明を省略する。ここでサーバ１００ａは、ＵＲＬ送信部６０８、ＵＲＬ作成部６０９を有し、また閲覧者のＰＣ１２０ａは、ＵＲＬ受信部６２７を有している点が前述の実施の形態１の図１と異なっている。
【００６４】
ＵＲＬ作成部６０９は、最初のリクエストで閲覧者のＰＣ１２０ａから送られたＵＲＬ（基本ＵＲＬ）と、記憶部１０２が記憶しているコンテンツファイルとから、閲覧者のＰＣ１２０が次回のアクセスに利用するためのＵＲＬ（更新ＵＲＬ）を作成する。このＵＲＬ作成部６０９の動作については後に詳述する。ＵＲＬ送信部６０８は、ＵＲＬ作成部６０９で作成された更新ＵＲＬを送信する。このＵＲＬ送信部６０８も、ネットワーク１３０を通じて他のコンピュータと通信を行うもので、実際にはネットワークカード等で構成される。
【００６５】
閲覧者のＰＣ１２０ａにおいて、ＵＲＬ受信部６２７は、サーバ１００ａから更新ＵＲＬを受信する。このＵＲＬ受信部６２７もネットワーク１３０を通じて他のコンピュータと通信を行っており、実際にはネットワークカードなどで構成される。
【００６６】
図７は、本実施の形態２に係るサーバ１００ａと閲覧者のＰＣ１２０ａとの通信シークエンスを説明する図である。尚、ここでサーバ１００ａと作成者のＰＣ１１０の間の通信シークエンスは、前述の実施の形態１と同じであるため、その説明を省略する。また図７では図１及び図２と同様の構成については同一の符号を付与し、以下では説明を省略する。
【００６７】
まず閲覧者のＰＣ１２０ａがＲＳＳリーダ１２７を実行して、基本ＵＲＬを用いてサーバ１００ａにアクセスする（７０１）。ここで述べる「基本ＵＲＬ」は、サーバ１００ａ上のサーバＲＳＳファイル１０１を取得するためのアドレスである。これによりサーバ１００ａは、閲覧者のＰＣ１２０ａに対して、ＲＳＳファイル送信部１０６を用いてＲＳＳファイル１０１を送信する。またＵＲＬ送信部６０８を用いて、次回に閲覧者のＰＣ１２０ａがアクセスする際に使用すべき更新ＵＲＬを送信する（７０２）。この更新ＵＲＬには、基本ＵＲＬと対応するサーバＲＳＳファイル１０１に記載されており、現在、サーバ１００ａの記憶部１０２に記憶されているコンテンツファイルのＩＤとその有無を示すパラメータが設定される。ここで閲覧者のＰＣ１２０ａは、ＲＳＳファイル受信部１２５及びＵＲＬ受信部６２７を用いて、サーバＲＳＳファイル１０１と更新ＵＲＬとを受信する。次に閲覧者のＰＣ１２０ａは、サーバ１００ａに対して、サーバＲＳＳファイル１０１に載っているコンテンツファイルを要求する（７０３）。これによりサーバ１００ａは、コンテンツ送信部１０７を用いてコンテンツファイルを閲覧者のＰＣ１２０ａに送信する。これにより閲覧者のＰＣ１２０ａは、そのコンテンツファイルを受信して記憶部１２２に記憶する（６０４）。
【００６８】
そして閲覧者のＰＣ１２０ａが２回目以降にサーバ１００ａにアクセスするときは、ＲＳＳリーダ１２７は、７０２で与えられた更新ＵＲＬを用いてサーバ１００ａにアクセスする（７０５）。これによりサーバ１００ａは、記憶部１０２に記憶されているコンテンツファイルを参照した結果と更新ＵＲＬのパラメータにしたがってサーバＲＳＳファイル１０１と更新ＵＲＬを作成し、閲覧者のＰＣ１２０ａに送り返す（７０６）。この新たに作成される更新ＵＲＬには、サーバ１００ａの記憶部１０２に記憶されているコンテンツファイルの記憶状況に応じて前回の更新ＵＲＬに設定されたコンテンツファイルの有無を変更し、新たに記憶されたコンテンツファイルを追加するよう設定する。
次に閲覧者のＰＣ１２０ａは、サーバ１００ａに対して、サーバＲＳＳファイル１０１に載っているコンテンツファイルのダウンロードを要求する（７０７）。これに応答してサーバ１００ａからコンテンツファイルが閲覧者のＰＣ１２０ａに送信される（７０８）。
【００６９】
次に図８を参照して、前述の更新ＵＲＬについて説明する。
【００７０】
図８は、閲覧者のＰＣ１２０ａが次回のアクセスに利用するための更新ＵＲＬの具体例を説明する図である。
【００７１】
８０１は、基本ＵＲＬを示し、それを更新した更新ＵＲＬは例えば８０２のようになる。ここで、ｉｄＡ８０３及びｉｄＢ８０４は、サーバ１００ａにおいてコンテンツファイルごとに割り当てられたユニークなＩＤである。図８では、それぞれＡとＢが割り振られたコンテンツファイルを意味する。８０５及び８０６は、コンテンツファイルのサーバ１００ａでの存在状況を表すフラグで、「０」又は「１」の値をとる。
【００７２】
図８では、「０」は、そのコンテンツファイルがサーバ１００ａの記憶部１０２に記憶されていないことを表す。逆に「１」は、そのコンテンツファイルが記憶部１０２に記憶されていることを表す。即ち、８０２では、コンテンツファイルＡはサーバ１００ａに存在するが、コンテンツファイルＢはサーバ１００ａに存在しないことを表している。
【００７３】
次に図９（Ａ）（Ｂ）を参照して、実施の形態２に係る更新ＵＲＬの作成シーケンスについて詳しく説明する。尚、図９において、図７と共通する部分は同じ記号で示している。
【００７４】
現在、作成者のＰＣ１１０には、コンテンツファイルＡ〜Ｅ（１００３〜１００７）が存在し、そのうちコンテンツファイルＡ（１００３）、コンテンツファイルＢ（１００４）、コンテンツファイルＥ（１００７）がサーバ１００ａに記憶されているとする。ここで各コンテンツファイルの識別情報（ＩＤ）は、それぞれｉｄＡ，ｉｄＢ，ｉｄＣ，ｉｄＤ，ｉｄＥである。尚、図９の９０１では、サーバ１００ａに以前は記憶されていたが現在は記憶されていないコンテンツファイルは斜線を付して示している。
【００７５】
このサーバ１００ａに、閲覧者のＰＣ１２０ａが基本ＵＲＬを用いてアクセスすると（７０１）、サーバＲＳＳファイル１０１とともに更新ＵＲＬが、サーバ１００ａから閲覧者のＰＣ１２０ａに返送される。このときの更新ＵＲＬは、サーバ１００ａの記憶部１０２に記憶されているコンテンツファイルについて存在を示すパラメータが設定される。例えばコンテンツＩＤがＡ、Ｃ、Ｄ、Ｅのコンテンツファイルが存在する場合「idA=1&idC=1&idD=1&idE=1」となる。
その後、サーバ１００ａの記憶部１０２からコンテンツＩＤがＣとＤのコンテンツファイルが削除された場合、閲覧者のＰＣ１２０ａがこの更新ＵＲＬを用いてサーバ１００ａにアクセスすると、サーバ１００ａは９０２のように表される更新ＵＲＬを作成する。更新ＵＲＬ９０２はコンテンツＩＤがＣとＤのコンテンツファイルが削除され、Ａ、Ｂ、Ｅのコンテンツファイルが存在していることを表す。
【００７６】
ここでサーバ１００ａは、ＲＳＳファイル作成部１０８を用いて、その作成したサーバＲＳＳファイル１０１と更新ＵＲＬを閲覧者のＰＣ１２０ａに返す（７０２）。このときＲＳＳファイル作成部１０８は、作成者のＰＣ１１０から取得した作成者ＲＳＳファイル１１７の内容と、記憶部１０２に記憶されたコンテンツファイルとに基づいてサーバＲＳＳファイル１０１を作成する。このＲＳＳファイル１１７では、サーバ１００ａに存在するコンテンツファイルと、サーバ１００ａに存在しないが作成者のＰＣ１１０に存在するコンテンツファイルとがそれぞれ識別可能に表示される。そして、閲覧者のＰＣ１２０ａは、表示部１２４を用いて、そのサーバＲＳＳファイル１０１に基づき、コンテンツ一覧を表示する。
【００７７】
図１０（Ａ）〜（Ｃ）は、閲覧者のＰＣ１２０ａの表示部１２４に表示されるコンテンツ一覧画面の例を示す図である。
【００７８】
図１０（Ａ）は、サーバ１００ａに記憶されているコンテンツファイルＡ，Ｂ，Ｅのリストの表示例を示す。
【００７９】
図１０（Ｂ）は、サーバ１００ａに記憶されているコンテンツファイルＡ，Ｂ，Ｅのリストとともに、作成者のＰＣ１１０に存在するが、サーバ１００ａに記憶されていないコンテンツファイルの存在を閲覧者に伝えるメッセージ１１００を表示する例を示す。
【００８０】
図１０（Ｃ）は、サーバ１００ａに記憶されているコンテンツファイルＡ，Ｂ，Ｅのリストとともに、作成者のＰＣ１１０に存在するが、サーバ１００ａに記憶されていないコンテンツＣ，Ｄのタイトルを表示する一例を示している。
ここで、これらコンテンツファイルのファイル名又はタイトルは、サーバＲＳＳファイル１０１に記述されており、閲覧者のＰＣ１２０はサーバ１００ａにリクエストすることにより取得可能である。
【００８１】
さらに、サーバ１００ａは閲覧者のＰＣ１２０からのアクセスに利用された更新ＵＲＬのパラメータを参照してサーバＲＳＳファイル１０１を作成する。これにより、以前は存在すると通知したが現在は存在しないコンテンツファイルや、以前は存在しないと通知したが現在は存在するコンテンツファイルを区別して閲覧者のＰＣ１２０に通知できる。閲覧者のＰＣ１２０のＲＳＳリーダはこのようなサーバＲＳＳファイル１０１にしたがい、以前通知されたときは存在したが現在は存在しないコンテンツファイルをコンテンツ一覧画面で区別して表示させる。また、以前通知されたときは存在しなかったが現在は存在するコンテンツファイルをコンテンツ一覧画面で区別して表示させる。
【００８２】
そして、閲覧者のＰＣ１２０ａがコンテンツ受信部１２６を用いてコンテンツファイルＡ，Ｂ，Ｅをサーバ１００ａから取得する（図７の７０３，７０４）。
【００８３】
その後、時間が経過し、コンテンツ作成者が新たなコンテンツファイルを作成して作成者のＰＣ１１０に記憶したり、サーバ１００ａが、前述の実施の形態１で説明したようにして、新たにコンテンツファイルを作成者のＰＣ１１０から取得する。また或は記憶部１０２から削除して、コンテンツファイルの状態が図９の９０３で示すようになったとする。即ち、コンテンツＡ（１０１１）、コンテンツＣ（１０１３）、コンテンツＦ（１０１６）がサーバ１００ａに現在記憶されているとする。ここでサーバ１００ａが有していないコンテンツファイルは斜線を付して示している。
【００８４】
このとき、閲覧者のＰＣ１２０ａがサーバ１００に対して更新ＵＲＬ９０２を用いてアクセスしてきたとする（７０５）。このときサーバ１００ａは、次回のアクセスで使用するための更新ＵＲＬを図９（Ｂ）に示すように決定する。即ち、コンテンツファイルごとに、そのコンテンツファイルが現在、サーバ１００ａの記憶部１０２にあれば変数ｘを「１」にセットし、なければ「０」にセットする。次に、更新ＵＲＬ９０２のパラメータにおける各コンテンツファイルのフラグが「１」ならば変数ｙを「１」に、「０」ならば変数ｙを「０」にする。但し、更新ＵＲＬ９０４に存在しないコンテンツファイルについてはｙを「０」にする。そして、次回のアクセスに利用する更新ＵＲＬの各コンテンツファイルのフラグに設定する値ｚを、ｚ＝ｘ ＯＲ ｙで計算する。
【００８５】
この結果を図９（Ｂ）に示す。図９（Ｂ）では、サーバ１００ａの記憶部１０２に記憶されていないコンテンツファイル（ｉｄＢ，ｉｄＤ，ｉｄＥ）のｘの値が「０」にセットされ、記憶されているコンテンツファイル（ｉｄＡ，ｉｄＣ，ｉｄＦ）のｘの値が「１」にセットされている。また変数ｙの値に関しては、更新ＵＲＬ９０２でｉｄＣ＝０，ｉｄＤ＝０より、コンテンツファイル（ｉｄＣ，ｉｄＤ）のｙの値だけが「０」にセットされている。そして「ｘ or ｙ」の欄には、これらｘの値とｙの値との論理和が記入されている。
【００８６】
こうしてサーバ１００ａは、サーバＲＳＳファイル１０１とともに更新ＵＲＬ９０４を閲覧者のＰＣ１２０ａに送信する（７０６）。
【００８７】
そして、閲覧者のＰＣ１２０ａがコンテンツ受信部１２６を用いてコンテンツファイルＣやＦをサーバ１００ａから取得する（図７の７０７，７０８）。
【００８８】
また、閲覧者のＰＣ１２０ａがコンテンツファイルをダウンロードしたかどうかを更新ＵＲＬのパラメータに設定するようにしてもよい。この場合、閲覧者のＰＣ１２０ａが基本ＵＲＬを使ってサーバ１００ａにアクセスすると、サーバ１００ａは記憶部１０２に記憶されたコンテンツファイルについてダウンロードしていないことを示すパラメータを設定した更新ＵＲＬを閲覧者のＰＣ１２０ａに送信する。次に閲覧者のＰＣ１２０ａが更新ＵＲＬを使ってアクセスするとサーバ１００ａは記憶部１０２に記憶されているコンテンツファイルを参照した結果と作成者ＲＳＳファイル、更新ＵＲＬのパラメータにしたがってサーバＲＳＳファイルを作成する。そしてサーバＲＳＳファイルを閲覧者のＰＣ１２０ａに送信する。閲覧者のＰＣ１２０ａはＲＳＳリーダプログラムおよびサーバＲＳＳファイルにしたがって図１４に示すようなコンテンツ一覧画面を表示部１２４に表示させる。図１４ではコンテンツファイルのサムネイル画像１４０１が表示される。コンテンツファイルが動画像データの場合は代表フレームの静止画像が表示される。サーバ１００ａの記憶部１０２に記憶されているコンテンツファイルについてはダウンロードを指示するためのダウンロードボタン１４０２が表示される。サーバ１００ａの記憶部１０２に記憶されていないコンテンツファイルについてはサーバ１００ａに取得をリクエストするための予約ボタン１４０３が表示される。更新ＵＲＬのパラメータが、閲覧者のＰＣ１２０ａが既にダウンロードしていることを示すコンテンツファイルについては警告メッセージ１４０４が表示される。更新ＵＲＬのパラメータにないコンテンツファイルは新規と判断し、案内メッセージ１４０５が表示される。
【００８９】
以上説明した更新ＵＲＬを用いることにより、サーバ１００ａは閲覧者のＰＣ１２０ａが過去にどのコンテンツファイルを取得しているか、或は取得していないかを把握することができる。更に、閲覧者にそのことを通知することができ、閲覧者の利便性を向上させることができる。
【００９０】
また本実施の形態では、閲覧者毎に前回までのアクセスと今回のアクセスに対して通知したコンテンツファイルの内容の差分を識別できるように通知する。これにより、サーバの記憶部からコンテンツファイルが削除されたり追加されたりという変更がよく行われるような場合に、閲覧者は変更を容易に知ることができ、利便性を向上させることができる。
【００９１】
尚、ＵＲＬの長さには制限があるため、上記のＵＲＬ作成方法では、コンテンツファイル数が多数になった場合、ＵＲＬの長さ制限を越えてしまう可能性がある。そのような場合は、各コンテンツファイルのＩＤを１ビットで表現し、ＵＲＬの「？」以降を１６進数で表すなどの方法をとれば良い。
【００９２】
［実施の形態３］
前述の実施の形態１及び２は、サーバ１００がコンテンツ作成者のＰＣ１１０にアクセスするため、コンテンツ作成者のＰＣ１１０のネットワークアドレスが固定されており、サーバ１００がそのアドレスを知っていなければならなかった。そこで本実施の形態３では、コンテンツ作成者のＰＣ１１０のネットワークアドレスが変化しても動作する例を説明する。
【００９３】
まず、本実施の形態３の構成を説明する。
【００９４】
図１１は、本発明の実施の形態３に係るコンテンツ提供システムの構成を説明する図である。尚、図１と共通しているのものについては同じ符号を付与し、それらの説明を省略する。ここでサーバ１００ｂは、アドレス受信部１１０８を有し、また作成者のＰＣ１１０ｂは、アドレス送信部１１１７を有している点が前述の実施の形態１の図１と異なっている。
【００９５】
サーバ１００ｂのアドレス受信部１１０８は、作成者のＰＣ１１０ｂのアドレスを受信する。このアドレス受信部１１０８も、ネットワークを通じて他のコンピュータと通信を行い、実際にはネットワークカードなどで構成される。作成者のＰＣ１１０ｂのアドレス送信部１１１７は、作成者のＰＣ１１０ｂのアドレスをサーバ１００ｂに送信する。このアドレス送信部１１１７もネットワークを通じて他のコンピュータと通信を行い、実際にはネットワークカードなどで構成される。
【００９６】
次に、本実施の形態３の構成が前述の実施の形態１と異なる点を説明する。この異なる点は、コンテンツ作成者のＰＣ１１０ｂがサーバ１００ｂからアクセスできない状態にある場合のサーバ１００ｂとコンテンツ作成者のＰＣ１１０ｂとの間、及びサーバ１００ｂとコンテンツ閲覧者のＰＣ１２０との間での通信シークエンスである。次に本実施の形態３に係る通信シークエンスを図１２を参照して説明する。
【００９７】
図１２は、本実施の形態３に係るサーバ１００ｂと作成者のＰＣ１１０ｂとの間の通信シークエンスを説明する図である。
【００９８】
本実施の形態３では、作成者のＰＣ１１０ｂが起動すると、予め設定されているアドレスを用いてサーバ１００ｂにアクセスする（１２０１）。このアクセスに成功すると作成者のＰＣ１１０ｂは、アドレス送信部１１１７を用いて、自分のネットワークアドレスをサーバ１００ｂに送信する（１２０２）。これによりサーバ１００ｂは、アドレス受信部１１０８によりそのアドレスを受信し、それを記憶部１０２に記憶する。次にサーバ１００ｂは、リクエストリスト１０９に記憶されている各コンテンツファイルのリクエストを作成者のＰＣ１１０ｂに送信する（１２０３）。これにより作成者のＰＣ１１０ｂは、そのリクエストに対応するコンテンツファイルを記憶部１１２から読み出し、コンテンツ送信部１１６を用いてサーバ１００ｂに送信する。こうしてサーバ１００ｂは、コンテンツ受信部１０５によりそのコンテンツファイルを受信する（１２０４）。こうしてサーバ１００ｂが取得したコンテンツファイルは、サーバ１００ｂの記憶部１０２に記憶される。そして次に閲覧者のＰＣ１２０からコンテンツファイルのリクエストを受けたときに、そのコンテンツファイルをコンテンツ送信部１０７から閲覧者のＰＣ１２０に送信する。
【００９９】
上記の通信シークエンスにおいて、サーバ１００ｂは、作成者のＰＣ１１０ｂのネットワークアドレスを記憶する。こうして記憶したアドレスは、作成者のＰＣ１１０ｂがネットワーク１３０に接続されており、サーバ１００ｂからアクセス可能な状態にあるときの通信シークエンス（図２の２０４等に相当）で使用される。
【０１００】
以上により、作成者のＰＣ１１０ｂのアドレスが固定されていない場合でも、サーバ１００は、その作成者のＰＣ１１０ｂにアクセスして、そのコンテンツファイルを取得することができる。
【０１０１】
なお、本発明のサーバ装置や作成者のＰＣ、閲覧者のＰＣを実現するためのコンピュータ装置の構成の一例を図１５のブロック図を参照して説明する。サーバ装置や各ＰＣはそれぞれ単一のコンピュータ装置で実現してもよいし、必要に応じた複数のコンピュータ装置に各機能を分散して実現するようにしてもよい。複数のコンピュータ装置で構成される場合は、互いに通信可能なようにＬＡＮなどで接続されている。
【０１０２】
図１５において、１５５１はコンピュータ装置１５５０全体を制御するＣＰＵである。１５５２は変更を必要としないプログラムやパラメータを格納するＲＯＭである。１５５３は後述する外部記憶装置１５５４などから供給されるプログラムやデータを一時記憶するＲＡＭである。１５５４はコンピュータ装置１５５０に固定して設置されたハードディスク又は、コンピュータ装置１５５０から着脱可能なフレキシブルディスク（ＦＤ）やコンパクトディスク（ＣＤ）、ＤＶＤ等の光ディスクメディアである。また１５５４はＩＣカードやメモリカード等のカード型メディアのような外部記憶装置である。外部記憶装置１５５４には、ＯＳやＷｅｂブラウザプログラムなどが記憶されている。また、閲覧者のＰＣのハードディスク１５５４にはＲＳＳリーダプログラムも記憶されている。１５５５はユーザの操作を受け、データを入力するポインティングデバイスやキーボードなどの入力デバイス１５５９とのインターフェースである。１５５６はコンピュータ装置１５５０の保持するデータや供給されたデータを表示するためのモニタ１５１０とのインターフェースである。１５５７はインターネット１３０などのネットワーク回線に接続するためのネットワークインタフェイスである。１５５８はデジタルスチルカメラやデジタルビデオ、スキャナなどの画像入力デバイス１５１２とのインターフェースである。１５１３は１５５１〜１５５８の各ユニットを通信可能に接続するシステムバスである。
【０１０３】
なお本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが該供給されたプログラムを読み出して実行することによっても達成され得る。その場合、プログラムの機能を有していれば、形態は、プログラムである必要はない。
【０１０４】
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明のクレームでは、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【０１０５】
プログラムを供給するための記録媒体としては、様々なものが使用できる。例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などである。
【０１０６】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページからハードディスク等の記録媒体にダウンロードすることによっても供給できる。その場合、ダウンロードされるのは、本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルであってもよい。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。
【０１０７】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布する形態としても良い。その場合、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムが実行可能な形式でコンピュータにインストールされるようにする。
【０１０８】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される形態以外の形態でも実現可能である。例えば、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。
【０１０９】
更に、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれるようにしてもよい。この場合、その後で、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によって前述した実施形態の機能が実現される。
【図面の簡単な説明】
【０１１０】
【図１】本発明の一実施の形態に係るコンテンツ提供システムの構成を説明する図である。
【図２】本発明の一実施の形態１におけるコンテンツ作成者のＰＣとサーバ及びコンテンツ作成者のＰＣとの間の通信シーケンスを説明する図である。
【図３】本発明の一実施の形態１におけるコンテンツ作成者のＰＣとサーバ及びコンテンツ作成者のＰＣとの間の通信シーケンスを表す図である。
【図４】本発明の一実施の形態において、サーバの動作を説明するフローチャートである。
【図５】本発明の一実施の形態に係るサーバの動作を説明するフローチャートである。
【図６】本発明の一実施の形態に係るコンテンツ提供システムの構成を説明する図である。
【図７】本発明の一実施の形態に係るサーバと閲覧者のＰＣとの通信シーケンスを説明する図である。
【図８】本発明の一実施の形態に係る閲覧者のＰＣがサーバへのアクセスに利用するためのＵＲＬを説明する図である。
【図９】本発明の一実施の形態に係るサーバと閲覧者のＰＣとの通信シーケンスを説明する図である。
【図１０】本発明の一実施の形態において閲覧者のＰＣの表示部に表示されるコンテンツ一覧の例を示す図である。
【図１１】本発明の一実施の形態に係るコンテンツ提供システムの構成を説明する図である。
【図１２】本発明の一実施の形態に係るサーバと作成者のＰＣとの間の通信シーケンスを説明する図である。
【図１３】本発明の一実施の形態に係るコンテンツＤＢに格納される情報の一例を示す図である。
【図１４】本発明の一実施の形態に係るコンテンツ一覧画面の例を示す図である。
【図１５】本発明の一実施形態に係るコンピュータ装置の構成を示す図である。
【図１６】従来のコンテンツ配信システムを説明する図である。
【図１】
2009146226.tif 000003
【図２】
2009146226.tif 000004
【図３】
2009146226.tif 000005
【図４】
2009146226.tif 000006
【図５】
2009146226.tif 000007
【図６】
2009146226.tif 000008
【図７】
2009146226.tif 000009
【図８】
2009146226.tif 000010
【図９】
2009146226.tif 000011
【図１０】
2009146226.tif 000012
【図１１】
2009146226.tif 000013
【図１２】
2009146226.tif 000014
【図１３】
2009146226.tif 000015
【図１４】
2009146226.tif 000016
【図１５】
2009146226.tif 000017
【図１６】
2009146226.tif 000018