(57)【特許請求の範囲】
【請求項１】
ＨＴＴＰ（Hypertext Transfer Protocol）を利用して通信可能なクライアントとサーバとによって構成されるサムネイル配信システムであって、
前記クライアントにおいて画像として表示可能なデータを原データ、当該原データに基づいて前記クライアントが表示可能な前記画像の縮小画像であるサムネイルを前記クライアントにおいて表示する際に用いられるデータをサムネイル表示用データとして、
前記クライアントは、
１つのファイルに対応するファイル名がリクエスト行に格納され、且つ、サムネイルの要求である旨を示すサムネイル要求情報がリクエストヘッダに格納されたＨＴＴＰリクエストを作成するリクエスト作成手段と、
前記リクエスト作成手段によって作成された前記ＨＴＴＰリクエストを、前記サーバに対して送信するリクエスト送信手段と、
前記リクエスト送信手段による前記ＨＴＴＰリクエストの送信後に前記サーバから送信されてくるＨＴＴＰレスポンスを受信するレスポンス受信手段と、
前記レスポンス受信手段によって受信された前記ＨＴＴＰレスポンスのレスポンスボディに格納された前記サムネイル表示用データを利用して所定のデータ処理を実行するデータ処理手段と
を備え、
前記サーバは、
前記クライアントから送信されてくる前記ＨＴＴＰリクエストを受信するリクエスト受信手段と、
前記リクエスト受信手段によって受信された前記ＨＴＴＰリクエスト中、前記リクエスト行には１つのファイルに対応するファイル名が格納され、且つ、前記リクエストヘッダには前記サムネイル要求情報が格納されている場合に、記憶手段に記憶されたファイルの内、前記ファイル名によって指定された１つのファイルを対象にして、当該対象となるファイルに格納された前記原データに対応する前記サムネイル表示用データがレスポンスボディ内に格納されたＨＴＴＰレスポンスを作成するレスポンス作成手段と、
前記レスポンス作成手段によって作成された前記ＨＴＴＰレスポンスを、前記クライアントに対して送信するレスポンス送信手段と
を備えることを特徴とするサムネイル配信システム。
【請求項２】
前記クライアントは、
前記記憶手段に記憶されたファイルの内、一部または全部のファイルを対象にして、当該対象となるファイルに関するファイル情報を取得するファイル情報取得手段と、
前記ファイル情報取得手段によって取得された前記ファイル情報に基づいて、前記サムネイル表示用データの取得対象となる１または２以上のファイルを選択する選択手段と
を備え、
前記リクエスト作成手段は、前記選択手段によって選択された１または２以上のファイルを１つずつ処理対象として、処理対象としたファイルのファイル名がリクエスト行に格納され、且つ、前記サムネイル要求情報がリクエストヘッダに格納された前記ＨＴＴＰリクエストを作成する処理を、前記選択手段によって選択されたファイル数と同数回実行し、
前記リクエスト送信手段は、前記リクエスト作成手段が前記ＨＴＴＰリクエストを作成するたびに、前記ＨＴＴＰリクエストを前記サーバに対して送信し、
前記レスポンス受信手段は、前記リクエスト送信手段が前記ＨＴＴＰリクエストを前記サーバに対して送信するたびに、その送信後に前記サーバから送信されてくるＨＴＴＰレスポンスを受信する
ことを特徴とする請求項１に記載のサムネイル配信システム。
【請求項３】
前記データ処理手段は、前記レスポンス受信手段が前記ＨＴＴＰレスポンスを受信するたびに、前記ＨＴＴＰレスポンスのレスポンスボディから前記サムネイル表示用データを抽出するとともに、抽出された１または２以上の前記サムネイル表示用データに基づいて表示可能なサムネイルを、クライアント側で各サムネイル毎に設定された表示位置に表示する処理を、前記データ処理として実行する
ことを特徴とする請求項２に記載のサムネイル配信システム。
【請求項４】
前記選択手段は、所定の条件を満足する文字列によって構成されたファイル名を持つファイルを、前記サムネイル表示用データの取得対象となるファイルとして選択する
ことを特徴とする請求項２または請求項３に記載のサムネイル配信システム。
【請求項５】
前記選択手段は、所定の日時に生成または更新されたファイルを、前記サムネイル表示用データの取得対象となるファイルとして選択する
ことを特徴とする請求項２〜請求項４のいずれかに記載のサムネイル配信システム。
【請求項６】
前記リクエスト作成手段は、前記リクエスト行にＧＥＴメソッドが格納され、且つ、前記リクエストヘッダにＰｒａｇｍａヘッダフィールドが設けられ、前記サムネイル要求情報が前記Ｐｒａｇｍａヘッダフィールドのフィールド値として格納されたた前記ＨＴＴＰリクエストを作成する
ことを特徴とする請求項１〜請求項５のいずれかに記載のサムネイル配信システム。
【請求項７】
前記レスポンス作成手段は、前記サムネイル表示用データの提供である旨を示すサムネイル提供情報がレスポンスヘッダに格納された前記ＨＴＴＰレスポンスを作成する
ことを特徴とする請求項１〜請求項６のいずれかに記載のサムネイル配信システム。
【請求項８】
前記レスポンス作成手段は、前記レスポンスヘッダにＰｒａｇｍａヘッダフィールドが設けられ、前記サムネイル提供情報が前記Ｐｒａｇｍａヘッダフィールドのフィールド値として格納されたた前記ＨＴＴＰレスポンスを作成する
ことを特徴とする請求項７に記載のサムネイル配信システム。
【請求項９】
前記クライアントは、
前記レスポンス受信手段によって受信された前記ＨＴＴＰレスポンスのレスポンスヘッダに前記サムネイル提供情報が格納されているか否かにより、前記サーバがサムネイル提供機能を有するか否かを判定する機能判定手段
を備えることを特徴とする請求項７または請求項８に記載のサムネイル配信システム。
【請求項１０】
前記リクエスト作成手段は、１つのファイルに対応するファイル名およびＨＥＡＤメソッドがリクエスト行に格納され、且つ、前記サムネイル要求情報がリクエストヘッダに格納された機能判定用のＨＴＴＰリクエストを作成可能で、当該ＨＴＴＰリクエストを前記リクエスト送信手段が前記サーバに対して送信した後、前記サーバから送信されてくる前記ＨＴＴＰレスポンスを前記レスポンス受信手段によって受信した際に、前記機能判定手段が、前記レスポンスヘッダに前記サムネイル提供情報が格納されているか否かにより、前記サーバがサムネイル提供機能を有するか否かを判定する
ことを特徴とする請求項９に記載のサムネイル配信システム。
【請求項１１】
前記レスポンス作成手段は、前記ＨＴＴＰリクエスト中で指定されたファイル内に前記サムネイル表示用データが格納されていない場合に、前記ファイル内に格納された前記原データに基づいて生成した前記サムネイル表示用データが前記レスポンスボディに格納されたＨＴＴＰレスポンスを作成する
ことを特徴とする請求項１〜請求項１０のいずれかに記載のサムネイル配信システム。
【請求項１２】
前記レスポンス作成手段は、前記ＨＴＴＰリクエスト中で指定されたファイル内に前記サムネイル表示用データが格納されていない場合に、前記ファイル内に格納された前記原データに基づいて生成したサムネイル表示用データが前記レスポンスボディに格納されたＨＴＴＰレスポンス、または前記ファイル内に前記サムネイル表示用データが格納されていない旨を示す情報が前記レスポンスボディに格納されたＨＴＴＰレスポンス、いずれかのＨＴＴＰレスポンスを作成可能で、いずれを作成するかについては、クライアント側での指定に従う
ことを特徴とする請求項１〜請求項１０のいずれかに記載のサムネイル配信システム。
【請求項１３】
前記サーバは、ＷｅｂＤＡＶ（Web-based Distributed Authoring and Versioning）サーバであり、
前記クライアントは、ＷｅｂＤＡＶクライアントである
ことを特徴とする請求項１〜請求項１２のいずれかに記載のサムネイル配信システム。
【請求項１４】
ＨＴＴＰを利用して通信可能なクライアントと協働して、請求項１〜請求項１３のいずれかに記載のサムネイル配信システムを構築可能なサーバであって、
ファイルを記憶する記憶手段と、
前記クライアントから送信されてくる前記ＨＴＴＰリクエストを受信するリクエスト受信手段と、
前記リクエスト受信手段によって受信された前記ＨＴＴＰリクエスト中、前記リクエスト行には１つのファイルに対応するファイル名が格納され、且つ、前記リクエストヘッダには前記サムネイル要求情報が格納されている場合に、前記記憶手段に記憶されたファイルの内、前記ファイル名によって指定された１つのファイルを対象にして、当該対象となるファイルに格納された前記原データに対応する前記サムネイル表示用データがレスポンスボディ内に格納されたＨＴＴＰレスポンスを作成するレスポンス作成手段と、
前記レスポンス作成手段によって作成された前記ＨＴＴＰレスポンスを、前記クライアントに対して送信するレスポンス送信手段と
を備えることを特徴とするサーバ。
【請求項１５】
コンピュータを、請求項１４に記載のサーバが備える各手段として機能させるためのプログラム。
【請求項１６】
ＨＴＴＰを利用して通信可能なサーバと協働して、請求項１〜請求項１３のいずれかに記載のサムネイル配信システムを構築可能なクライアントであって、
１つのファイルに対応するファイル名がリクエスト行に格納され、且つ、サムネイルの要求である旨を示すサムネイル要求情報がリクエストヘッダに格納されたＨＴＴＰリクエストを作成するリクエスト作成手段と、
前記リクエスト作成手段によって作成された前記ＨＴＴＰリクエストを、前記サーバに対して送信するリクエスト送信手段と、
前記リクエスト送信手段による前記ＨＴＴＰリクエストの送信後に前記サーバから送信されてくるＨＴＴＰレスポンスを受信するレスポンス受信手段と、
前記レスポンス受信手段によって受信された前記ＨＴＴＰレスポンスのレスポンスボディに格納された前記サムネイル表示用データを利用して所定のデータ処理を実行するデータ処理手段と
を備えることを特徴とするクライアント。
【請求項１７】
コンピュータを、請求項１６に記載のクライアントが備える各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サムネイル配信システム、サムネイル配信システムを構成するサーバおよびクライアント、これらのサーバやクライアントとしてコンピュータを機能させるためのプログラムに関する。
【背景技術】
【０００２】
従来、ＨＴＴＰを利用して通信可能なクライアント−サーバ間において、サーバ側から提供されるサムネイル（縮小版の画像；以下同様）をクライアント側で表示するシステムが提案されている（例えば、特許文献１参照。）。
【０００３】
上記特許文献１に記載されたシステムの場合、クライアント側のウェブブラウザ上でリンクが設定されたテキストを選択する操作を行うと、まず、サーバ側からクライアント側へＨＴＭＬファイルが伝送される。そして、その後、ＨＴＭＬファイル中からリンクされるサムネイル（別ビットマップファイル）が、さらにサーバ側からクライアント側へと伝送される。
【０００４】
これらＨＴＭＬファイルおよびＨＴＭＬファイル中からリンクされるサムネイルを、クライアント側のウェブブラウザで表示することで、サーバ側より受信したサムネイルの一覧を表示することができる（例えば、特許文献１：段落［００７９］，［００８３］，［００８４］等参照）。
【特許文献１】特開２００３−３７７００号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところで、上記のようなシステムにおいて、サムネイルの基になるファイルのファイル名やファイルの格納場所については、クライアント側で把握できていることも多い。ＨＴＴＰは、その名の通り、ハイパーテキストファイルを送受信するためのプロトコルであるので、ファイル名やファイルの格納場所さえ把握していれば、クライアント側からファイルの送信をリクエストすることができる。しかし、ハイパーテキストにはそもそもサムネイルという概念がないため、ファイル名やファイルの格納場所を把握していたとしても、そのファイルのサムネイルについてクライアント側から送信をリクエストすることが、ＨＴＴＰでは本来できなかった。
【０００６】
また、上記のようなシステムでは、サムネイルはサーバ側で自動的に生成されており、生成されたサムネイルのファイル名や格納場所をクライアント側で把握することはできなかった。
【０００７】
そのため、従来は、上述の如きＨＴＭＬファイルをサーバ側から受け取らない限り、クライアントは、ファイル名やファイルの格納場所を把握していたとしても、サーバに対してそのファイルのサムネイルの配信を要求することができない、という問題があった。
【０００８】
特に、サムネイルの基になるファイルのファイル名が、クライアント側で把握できている場合であっても、それだけでは、そのファイルのサムネイルをサーバに対して要求するようなことはできない、という問題があった。
【０００９】
また、上述の如きＨＴＭＬファイルを受け取る場合、クライアント側で取得したいサムネイルの数が増えるほど、事前にサーバから受け取らなければならないＨＴＭＬ中のリンクも増えることになる。
【００１０】
そのため、膨大な数のリンクをサーバからクライアントへ伝送するような状況になれば、膨大な数のリンクを持つＨＴＭＬファイルを作成するサーバにも、そのようなＨＴＭＬファイルを受信するクライアントにも負荷がかかるという問題があった、また、実際にサムネイルを伝送するのに先立ち、上述の如きＨＴＭＬを伝送するだけでも、相応にネットワークに負荷がかかる、という問題もあった。
【００１１】
本発明は、上記問題を解決するためになされたものであり、その目的は、サムネイルの基になるファイルのファイル名がクライアント側で把握できている場合に、そのファイルのサムネイルへのリンクをサーバからクライアントへ事前に通知しなくても、クライアントがサーバからＨＴＴＰに則って容易にサムネイルを取得することができるサムネイル配信システムを提供することにある。また、そのようなサムネイル配信システムを構成するサーバおよびクライアント、これらのサーバやクライアントとしてコンピュータを機能させるためのプログラムを提供することにある。
【課題を解決するための手段】
【００１２】
以下、本発明において採用した構成について説明する。
まず、請求項１に記載のサムネイル配信システムは、ＨＴＴＰ（Hypertext Transfer Protocol）を利用して通信可能なクライアントとサーバとによって構成されるサムネイル配信システムであって、前記クライアントにおいて画像として表示可能なデータを原データ、当該原データに基づいて前記クライアントが表示可能な前記画像の縮小画像であるサムネイルを前記クライアントにおいて表示する際に用いられるデータをサムネイル表示用データとして、前記クライアントは、１つのファイルに対応するファイル名がリクエスト行に格納され、且つ、サムネイルの要求である旨を示すサムネイル要求情報がリクエストヘッダに格納されたＨＴＴＰリクエストを作成するリクエスト作成手段と、前記リクエスト作成手段によって作成された前記ＨＴＴＰリクエストを、前記サーバに対して送信するリクエスト送信手段と、前記リクエスト送信手段による前記ＨＴＴＰリクエストの送信後に前記サーバから送信されてくるＨＴＴＰレスポンスを受信するレスポンス受信手段と、前記レスポンス受信手段によって受信された前記ＨＴＴＰレスポンスのレスポンスボディに格納された前記サムネイル表示用データを利用して所定のデータ処理を実行するデータ処理手段とを備え、前記サーバは、前記クライアントから送信されてくる前記ＨＴＴＰリクエストを受信するリクエスト受信手段と、前記リクエスト受信手段によって受信された前記ＨＴＴＰリクエスト中、前記リクエスト行には１つのファイルに対応するファイル名が格納され、且つ、前記リクエストヘッダには前記サムネイル要求情報が格納されている場合に、記憶手段に記憶されたファイルの内、前記ファイル名によって指定された１つのファイルを対象にして、当該対象となるファイルに格納された前記原データに対応する前記サムネイル表示用データがレスポンスボディ内に格納されたＨＴＴＰレスポンスを作成するレスポンス作成手段と、前記レスポンス作成手段によって作成された前記ＨＴＴＰレスポンスを、前記クライアントに対して送信するレスポンス送信手段とを備えることを特徴とする。
【００１３】
このように構成されたサムネイル配信システムによれば、クライアントは、サーバに対してサムネイル表示用データの伝送を要求する際、サムネイル表示用データが格納されたファイル名を指定するのではなく、サムネイルの基になる原データが格納されたファイルのファイル名を指定してサムネイル表示用データの伝送を要求する。また、この要求を受けたサーバは、クライアントが指定したファイル名に基づいて、そのファイル名に対応するファイルに格納された原データそのものではなく、その原データに対応したサムネイル表示用データをクライアントに提供する。
【００１４】
したがって、このようなサムネイル配信システムであれば、サムネイル表示用データが格納されたファイル名が認識できていないクライアントであっても、サムネイルの基になる原データが格納されたファイルのファイル名さえ認識できていれば、サーバからサムネイル表示用データを取得することができる。
【００１５】
よって、事前にサーバからＨＴＭＬファイルの如き情報を受け取って、その中に記述されたリンクをたどってサムネイル表示用データを取得する、といった面倒な手間をかけなくても、きわめて簡単にサムネイル表示用データを取得することができる。また、実際にサムネイル表示用データを伝送するのに先立ち、ＨＴＭＬファイルの如き情報を伝送する必要がないので、その分だけネットワークにかかる負荷を軽減することもできる。
【００１６】
加えて、上記のような方式でサムネイル表示用データを取得すれば、広く普及したＨＴＴＰを利用することができるので、ＨＴＴＰに対応したプロキシサーバや各種中継サーバを経由してでも、サムネイル表示用データを取得することができる。
【００１７】
なお、このサムネイル配信システムの場合、クライアントはサムネイル表示用データをサーバ側から取得するので、クライアント側で原データに基づいてサムネイル表示用データを生成するものと比較すると、クライアント側にかかる負荷を軽減できる。また、サーバ側からクライアント側へ原データそのものを伝送してから、クライアント側で原データに基づいてサムネイル表示用データを生成するものと比較すると、このサムネイル配信システムの場合、原データそのものをサーバ側からクライアント側へ伝送しなくても済む。したがって、その分だけネットワークにかかる負荷も軽減できる。
【００１８】
次に、請求項２に記載のサムネイル配信システムは、請求項１に記載のサムネイル配信システムにおいて、前記クライアントは、前記記憶手段に記憶されたファイルの内、一部または全部のファイルを対象にして、当該対象となるファイルに関するファイル情報を取得するファイル情報取得手段と、前記ファイル情報取得手段によって取得された前記ファイル情報に基づいて、前記サムネイル表示用データの取得対象となる１または２以上のファイルを選択する選択手段とを備え、前記リクエスト作成手段は、前記選択手段によって選択された１または２以上のファイルを１つずつ処理対象として、処理対象としたファイルのファイル名がリクエスト行に格納され、且つ、前記サムネイル要求情報がリクエストヘッダに格納された前記ＨＴＴＰリクエストを作成する処理を、前記選択手段によって選択されたファイル数と同数回実行し、前記リクエスト送信手段は、前記リクエスト作成手段が前記ＨＴＴＰリクエストを作成するたびに、前記ＨＴＴＰリクエストを前記サーバに対して送信し、前記レスポンス受信手段は、前記リクエスト送信手段が前記ＨＴＴＰリクエストを前記サーバに対して送信するたびに、その送信後に前記サーバから送信されてくるＨＴＴＰレスポンスを受信することを特徴とする。
【００１９】
このように構成されたサムネイル配信システムによれば、記憶手段に記憶されたファイルに関するファイル情報に基づいて、所望のファイルをクライアント側で選択して、その選択されたファイルに格納された原データに対応するサムネイル表示用データをサーバから取得することができる。
したがって、クライアントが必要か否かを問わず、サーバ側で選定されたサムネイル表示用データすべてがクライアント側へ伝送されてきてしまうものと比較すると、サーバおよびネットワークにかかる無駄な負荷を軽減できる。
次に、請求項３に記載のサムネイル配信システムは、請求項２に記載のサムネイル配信システムにおいて、前記データ処理手段は、前記レスポンス受信手段が前記ＨＴＴＰレスポンスを受信するたびに、前記ＨＴＴＰレスポンスのレスポンスボディから前記サムネイル表示用データを抽出するとともに、抽出された１または２以上の前記サムネイル表示用データに基づいて表示可能なサムネイルを、クライアント側で各サムネイル毎に設定された表示位置に表示する処理を、前記データ処理として実行することを特徴とする。
このように構成されたサムネイル配信システムによれば、サーバから取得した１または２以上のサムネイルをクライアント側で各サムネイル毎に設定された表示位置に表示することができる。
【００２０】
したがって、サムネイルのレイアウトがサーバ側で決められた状態で配信されるウェブページを単にクライアント側で表示するものとは異なり、クライアント側の都合でサムネイルのレイアウトを最適化することができる。
【００２１】
【００２２】
次に、請求項４に記載のサムネイル配信システムは、請求項２または請求項３に記載のサムネイル配信システムにおいて、前記選択手段は、所定の条件を満足する文字列によって構成されたファイル名を持つファイルを、前記サムネイル表示用データの取得対象となるファイルとして選択することを特徴とする。
【００２３】
このように構成されたサムネイル配信システムによれば、ファイル名を構成する文字列により、所望のファイルをサムネイル表示用データの取得対象となるファイルとして選択することができる。
次に、請求項５に記載のサムネイル配信システムは、請求項２〜請求項４のいずれかに記載のサムネイル配信システムにおいて、前記選択手段は、所定の日時に生成または更新されたファイルを、前記サムネイル表示用データの取得対象となるファイルとして選択することを特徴とする。
【００２４】
このように構成されたサムネイル配信システムによれば、ファイルの生成日時または更新日時により、所望のファイルをサムネイル表示用データの取得対象となるファイルとして選択することができる。
次に、請求項６に記載のサムネイル配信システムは、請求項１〜請求項５のいずれかに記載のサムネイル配信システムにおいて、前記リクエスト作成手段は、前記リクエスト行にＧＥＴメソッドが格納され、且つ、前記リクエストヘッダにＰｒａｇｍａヘッダフィールドが設けられ、前記サムネイル要求情報が前記Ｐｒａｇｍａヘッダフィールドのフィールド値として格納されたた前記ＨＴＴＰリクエストを作成することを特徴とする。
【００２５】
このように構成されたサムネイル配信システムによれば、サムネイル要求情報がＰｒａｇｍａヘッダフィールドのフィールド値としてＨＴＴＰリクエスト中に格納される。したがって、各種中継サーバを経由してサムネイルの伝送を実現する場合であっても、Ｐｒａｇｍａヘッダフィールドのフィールド値は、ＨＴＴＰの規格上、確実に保持されることが決まっているため、クライアントからサーバへ確実な情報伝達を行うことができる。
【００２６】
次に、請求項７に記載のサムネイル配信システムは、請求項１〜請求項６のいずれかに記載のサムネイル配信システムにおいて、前記レスポンス作成手段は、前記サムネイル表示用データの提供である旨を示すサムネイル提供情報がレスポンスヘッダに格納された前記ＨＴＴＰレスポンスを作成することを特徴とする。
【００２７】
このように構成されたサムネイル配信システムによれば、ＨＴＴＰレスポンスとして返されたデータが、サムネイル表示用データであることを検証したい場合に、レスポンスヘッダで確認することができ、レスポンスボディとして返される実データを検証しなくても済む。
【００２８】
次に、請求項８に記載のサムネイル配信システムは、請求項７に記載のサムネイル配信システムにおいて、前記レスポンス作成手段は、前記レスポンスヘッダにＰｒａｇｍａヘッダフィールドが設けられ、前記サムネイル提供情報が前記Ｐｒａｇｍａヘッダフィールドのフィールド値として格納されたた前記ＨＴＴＰレスポンスを作成することを特徴とする。
【００２９】
このように構成されたサムネイル配信システムによれば、サムネイル提供情報がＰｒａｇｍａヘッダフィールドのフィールド値としてＨＴＴＰレスポンス中に格納される。したがって、各種中継サーバを経由してサムネイルの伝送を実現する場合であっても、Ｐｒａｇｍａヘッダフィールドのフィールド値は、ＨＴＴＰの規格上、確実に保持されることが決まっているため、サーバからクライアントへ確実な情報伝達を行うことができる。
【００３０】
次に、請求項９に記載のサムネイル配信システムは、請求項７または請求項８に記載のサムネイル配信システムにおいて、前記クライアントは、前記レスポンス受信手段によって受信された前記ＨＴＴＰレスポンスのレスポンスヘッダに前記サムネイル提供情報が格納されているか否かにより、前記サーバがサムネイル提供機能を有するか否かを判定する機能判定手段を備えることを特徴とする。
【００３１】
このように構成されたサムネイル配信システムによれば、サーバから取得したレスポンスヘッダに基づいて、サーバがサムネイル提供機能を有するか否かを判定することができる。したがって、サーバがサムネイル提供機能を有するか否かを判定した上で、サーバがサムネイル提供機能を有する場合にのみサムネイル表示用データの伝送を要求する、といった処理を実現することができる。
【００３２】
次に、請求項１０に記載のサムネイル配信システムは、請求項９に記載のサムネイル配信システムにおいて、前記リクエスト作成手段は、１つのファイルに対応するファイル名およびＨＥＡＤメソッドがリクエスト行に格納され、且つ、前記サムネイル要求情報がリクエストヘッダに格納された機能判定用のＨＴＴＰリクエストを作成可能で、当該ＨＴＴＰリクエストを前記リクエスト送信手段が前記サーバに対して送信した後、前記サーバから送信されてくる前記ＨＴＴＰレスポンスを前記レスポンス受信手段によって受信した際に、前記機能判定手段が、前記レスポンスヘッダに前記サムネイル提供情報が格納されているか否かにより、前記サーバがサムネイル提供機能を有するか否かを判定することを特徴とする。
【００３３】
このように構成されたサムネイル配信システムによれば、レスポンスボディを伝送することなく、レスポンスヘッダに基づいて、サーバがサムネイル提供機能を有するか否かを判定することができる。
【００３４】
なお、請求項９に記載のサムネイル配信システムとしては、請求項１０に記載のＨＥＡＤメソッドに代えて、ＧＥＴメソッドを採用したものを考えることができる。すなわち、この場合、前記リクエスト作成手段は、１つのファイルに対応するファイル名およびＧＥＴメソッドがリクエスト行に格納され、且つ、前記サムネイル要求情報がリクエストヘッダに格納された機能判定用のＨＴＴＰリクエストを作成する。
【００３５】
このような構成を採用しても、レスポンスヘッダに基づいて、サーバがサムネイル提供機能を有するか否かを判定することができる。ただし、ＧＥＴメソッドを採用した場合は、レスポンスヘッダに続いてレスポンスボディも伝送されることになるので、その分だけサーバからクライアントへのデータ伝送量は増大する。したがって、データ伝送量が増大しても機能判定と時を同じくしてレスポンスボディが取得したいような場合にはＧＥＴメソッドを採用し、データ伝送量の抑制を図りたい場合にはＨＥＡＤメソッドを採用すると好ましい。
【００３６】
次に、請求項１１に記載のサムネイル配信システムは、請求項１〜請求項１０のいずれかに記載のサムネイル配信システムにおいて、前記レスポンス作成手段は、前記ＨＴＴＰリクエスト中で指定されたファイル内に前記サムネイル表示用データが格納されていない場合に、前記ファイル内に格納された前記原データに基づいて生成した前記サムネイル表示用データが前記レスポンスボディに格納されたＨＴＴＰレスポンスを作成することを特徴とする。
【００３７】
このように構成されたサムネイル配信システムによれば、サーバは、ファイル内にサムネイル表示用データが格納されていない場合、ファイル内に格納された原データに基づいてサムネイル表示用データを生成し、そのサムネイル表示用データをクライアントに提供することができる。したがって、ファイル内にサムネイル表示用データが格納されていないデータ構造のファイルが指定された場合であっても、ファイルに格納された原データの内容を反映したサムネイルをクライアント側で表示する際に利用可能なサムネイル表示用データをクライアントに提供できる。
【００３８】
次に、請求項１２に記載のサムネイル配信システムは、請求項１〜請求項１０のいずれかに記載のサムネイル配信システムにおいて、前記レスポンス作成手段は、前記ＨＴＴＰリクエスト中で指定されたファイル内に前記サムネイル表示用データが格納されていない場合に、前記ファイル内に格納された前記原データに基づいて生成したサムネイル表示用データが前記レスポンスボディに格納されたＨＴＴＰレスポンス、または前記ファイル内に前記サムネイル表示用データが格納されていない旨を示す情報が前記レスポンスボディに格納されたＨＴＴＰレスポンス、いずれかのＨＴＴＰレスポンスを作成可能で、いずれを作成するかについては、クライアント側での指定に従うことを特徴とする。
【００３９】
このように構成されたサムネイル配信システムによれば、ファイル内にサムネイル表示用データが格納されていない場合、ファイル内に格納された原データに基づいてサムネイル表示用データを生成するか、ファイル内にサムネイル表示用データが格納されていない旨を示す情報を返すかを、クライアント側で指定することができる。したがって、利用者の好みに応じた手法をクライアント側で選び、それに応じたサムネイル表示用データまたは情報をクライアントに提供できる。
【００４０】
次に、請求項１３に記載のサムネイル配信システムは、請求項１〜請求項１２のいずれかに記載のサムネイル配信システムにおいて、前記サーバは、ＷｅｂＤＡＶ（Web-based Distributed Authoring and Versioning）サーバであり、前記クライアントは、ＷｅｂＤＡＶクライアントであることを特徴とする。
【００４１】
このように構成されたサムネイル配信システムによれば、ＷｅｂＤＡＶに対応したサーバおよびクライアントでサムネイル配信システムが構成されているので、ＷｅｂＤＡＶに準拠した手順で、クライアント側からサーバ上のファイルを管理することができるようになる。
【００４２】
次に、請求項１４に記載のサーバは、ＨＴＴＰを利用して通信可能なクライアントと協働して、請求項１〜請求項１３のいずれかに記載のサムネイル配信システムを構築可能なサーバであって、ファイルを記憶する記憶手段と、前記クライアントから送信されてくる前記ＨＴＴＰリクエストを受信するリクエスト受信手段と、前記リクエスト受信手段によって受信された前記ＨＴＴＰリクエスト中、前記リクエスト行には１つのファイルに対応するファイル名が格納され、且つ、前記リクエストヘッダには前記サムネイル要求情報が格納されている場合に、前記記憶手段に記憶されたファイルの内、前記ファイル名によって指定された１つのファイルを対象にして、当該対象となるファイルに格納された前記原データに対応する前記サムネイル表示用データがレスポンスボディ内に格納されたＨＴＴＰレスポンスを作成するレスポンス作成手段と、前記レスポンス作成手段によって作成された前記ＨＴＴＰレスポンスを、前記クライアントに対して送信するレスポンス送信手段とを備えることを特徴とする。
【００４３】
このサーバが備える各手段とクライアントが備える各手段とは、両者を組み合わせることにより、請求項１〜請求項１３のいずれかに記載のサムネイル配信システムを構築できるような組み合わせで採用される。これにより、これらのサーバとクライアントを組み合わせて、請求項１〜請求項１３のいずれかに記載のサムネイル配信システムを構築することができる。
【００４４】
次に、請求項１５に記載のプログラムは、コンピュータを、請求項１４に記載のサーバが備える各手段として機能させるためのプログラムである。
このように構成されたプログラムによれば、コンピュータを、請求項１４に記載のサーバとして機能させることができる。したがって、請求項１４に記載のサーバについて述べたとおりの手法で、請求項１〜請求項１３のいずれかに記載のサムネイル配信システムを構築できる。
【００４５】
次に、請求項１６に記載のクライアントは、ＨＴＴＰを利用して通信可能なサーバと協働して、請求項１〜請求項１３のいずれかに記載のサムネイル配信システムを構築可能なクライアントであって、１つのファイルに対応するファイル名がリクエスト行に格納され、且つ、サムネイルの要求である旨を示すサムネイル要求情報がリクエストヘッダに格納されたＨＴＴＰリクエストを作成するリクエスト作成手段と、前記リクエスト作成手段によって作成された前記ＨＴＴＰリクエストを、前記サーバに対して送信するリクエスト送信手段と、前記リクエスト送信手段による前記ＨＴＴＰリクエストの送信後に前記サーバから送信されてくるＨＴＴＰレスポンスを受信するレスポンス受信手段と、
前記レスポンス受信手段によって受信された前記ＨＴＴＰレスポンスのレスポンスボディに格納された前記サムネイル表示用データを利用して所定のデータ処理を実行するデータ処理手段とを備えることを特徴とする。
【００４６】
このクライアントが備える各手段とサーバが備える各手段とは、両者を組み合わせることにより、請求項１〜請求項１３のいずれかに記載のサムネイル配信システムを構築できるような組み合わせで採用される。これにより、これらのクライアントとサーバを組み合わせて、請求項１〜請求項１３のいずれかに記載のサムネイル配信システムを構築することができる。
【００４７】
次に、請求項１７に記載のプログラムは、コンピュータを、請求項１６に記載のクライアントが備える各手段として機能させるためのプログラムである。
このように構成されたプログラムによれば、コンピュータを、請求項１６に記載のクライアントとして機能させることができる。したがって、請求項１６に記載のクライアントについて述べたとおりの手法で、請求項１〜請求項１３のいずれかに記載のサムネイル配信システムを構築できる。
【発明を実施するための最良の形態】
【００４８】
次に、本発明の実施形態について、いくつかの具体例を挙げて説明する。
（１）第１実施形態
まず、第１実施形態について説明する。
（１．１）システム全体の構成
図１は、本発明の一実施形態として例示するサムネイル配信システム全体の構成を示したブロック図である。
【００４９】
このシステムは、ネットワークを介して接続されたサーバ１とクライアント２によって構成されている。サーバ１は、ＬＡＮ（Local Area Network）３に接続され、クライアント２は、ＬＡＮ４に接続されている。また、ＬＡＮ３、４は、それぞれＨＴＴＰプロキシ機能を有するゲートウェイ５、６を介して、さらに他のネットワーク７（ＬＡＮまたはＷＡＮ（Wide Area Network））に接続されている。
【００５０】
サーバ１およびクライアント２は、ＨＴＴＰサーバ／ＨＴＴＰクライアントとしての機能を有し、上述したネットワーク（ＬＡＮ３、４、および他のネットワーク７）を介してＨＴＴＰによる通信ができるようになっている。
【００５１】
また、サーバ１およびクライアント２は、ＷｅｂＤＡＶにも準拠しており、ＨＴＴＰサーバ／ＨＴＴＰクライアントとしての機能に加え、その拡張仕様であるＷｅｂＤＡＶサーバ／ＷｅｂＤＡＶクライアントとしての機能をも備えている。
【００５２】
本実施形態において、サーバ１は、複合機(MFP;Multifunction Peripheral)として構成されたもので、制御部１１、入力部１２、表示部１３、カードリーダ部１４、ネットワーク通信部１５、スキャナ部１６、プリンタ部１７、ＦＡＸ通信部１８などを備えている。
【００５３】
カードリーダ部１４には、メモリカード１９を装着することができ、制御部１１が後から詳述する処理を実行することにより、サーバ１は、メモリカード１９に格納されたファイルやそのサムネイルを、クライアント２に対して提供することができる。
【００５４】
一方、本実施形態において、クライアント２は、ＰＣ（Personal Computer）によって構成されたものであり、制御部２１、入力部２２、表示部２３、記憶部２４、ネットワーク通信部２５などを備えている。また、サーバ１が備えるメモリカード１９に格納されたファイルのサムネイルを表示する機能や、ＨＴＴＰにてファイルをメモリカード１９からクライアント２の記憶部２４へと転送させる機能などを備えたカードブラウザというソフトウェアを起動することができる。
【００５５】
次に、上記したようなシステム構成における処理について、概要を説明する。
クライアント２が備えるカードブラウザには、ＨＴＴＰにてサーバ１と通信を行うためのネットワーク設定がなされている。また、詳しくは後述するが、サーバ１からサムネイルを取得するファイルを絞り込むための設定や、サムネイルの抽出手順をサーバ１へ指定するための設定もなされている。
【００５６】
クライアント２の利用者が、クライアント２の備えるカードブラウザを起動すると、カードブラウザは、ネットワーク設定に従い、サーバ１にＨＴＴＰでアクセスし、メモリカード１９のフォルダ構成を要求する。サーバ１は要求に対し、メモリカード１９のフォルダ構成を返信するので、カードブラウザは返信されたフォルダ構成を画面に表示する。
【００５７】
続いて、利用者が任意のフォルダを選択すると、カードブラウザは、設定に従ってファイルを絞り込んだ上で、選択されたフォルダに格納されたファイルのサムネイルを設定された抽出手順に従って返信するよう、サーバ１に要求する。サーバ１は要求に対し、フォルダに格納されたファイルのサムネイルを返信するので、カードブラウザは返信されたサムネイルを画面に表示する。
【００５８】
利用者が任意のサムネイルを選択すると、カードブラウザは、選択されたサムネイルに対応するファイルをサーバ１に要求する。サーバ１は要求されたファイルを返信する。
以上が、上記したようなシステム構成における処理に関する概要の説明である。
（１．２）クライアント側の機能および処理
次に、クライアント２側の機能および処理について説明する。
【００５９】
［カードブラウザ起動時の処理］
まず、クライアント２においてカードブラウザを起動した際に実行される処理について、図２に基づいて説明する。カードブラウザは、クライアント２において起動されるソフトウェアである。このカードブラウザは、メモリカード１９に格納されたファイルのサムネイルを表示する機能や、ファイルをメモリカード１９からクライアント２の記憶部２４へと転送させる機能などを備えている。
【００６０】
カードブラウザは、クライアント２において利用者が入力部２２を利用して所定の入力操作を行うと起動される。より具体的な例を挙げれば、例えば、カードブラウザに対応するアイコンを、入力部２２の一つであるポインティングデバイスでクリックする操作（以下、同様の操作のことを単に「クリックする」ともいう））を行うと、カードブラウザが起動される。
【００６１】
カードブラウザが起動されて、クライアント２が図２に示す処理を開始すると、クライアント２は、まず［サーバ能力フラグ］に「−１」をセットして（Ｓ１０５）、フラグの初期化を行う。そして、ネットワーク設定からサーバ１のＩＰアドレスまたはノード名を取得して（Ｓ１１０）、ＨＴＴＰ通信による通信対象を特定する。
【００６２】
続いて、クライアント２は、サーバ１に対してルートフォルダの「ファイル一覧」コマンドを発行して（Ｓ１１５）、「ファイル一覧」コマンドが成功したか否かを判断する（Ｓ１２０）。ここで、「ファイル一覧」コマンドが正常に処理されなかった場合、何らかのエラーがサーバ１から返されたり、何ら応答が返されなかったりする。
【００６３】
そこで、そのような場合は（Ｓ１２０：いいえ）、ダイヤログを表示して「ネットワーク設定が正しいか確認して下さい」とのメッセージを利用者に伝えて（Ｓ１２５）、初期表示を終了する。
【００６４】
ここで、カードブラウザが起動された際、クライアント２の表示部２３には、図３に示すようなメイン画面３１が表示されている。このメイン画面３１内には、２つのウィンドウ３２、３３とボタン３４〜３９などが配置されている。Ｓ１２０の処理で否定判断がなされた場合（Ｓ１２０：いいえ）、メイン画面３１内では、左側のウィンドウ３２、右側のウィンドウ３３ともに、何ら表示のない状態になる。
【００６５】
この場合、利用者は、「ネットワーク設定」ボタン３４をクリックすることにより、サーバ１とのＨＴＴＰ通信を行う上で必要となる各種設定（例えば、ＩＰアドレス、ノード名等々…）を入力することができる。ただし、この種の通信設定は、ＨＴＴＰクライアント機能を持つソフトウェアにおいて一般的に採用されているものと差異がないので、これ以上の説明は省略する。
【００６６】
一方、Ｓ１２０の処理において、「ファイル一覧」コマンドが成功したと判断された場合は（Ｓ１２０：はい）、取得したファイル一覧中に混在するファイルおよびフォルダの中からフォルダだけをピックアップする。そして、サブフォルダがある場合は、サブフォルダにも「ファイル一覧」コマンドを発行する（Ｓ１３０）。
【００６７】
なお、Ｓ１３０の処理は、基本的には、フォルダ内にサブフォルダが存在する限り続けられる。ただし、実用上問題とならない程度まで深い階層に達したら、その時点でそれ以上深い階層のサブフォルダに対しては、「ファイル一覧」コマンドを発行しない仕様としてもよい。
【００６８】
以上のようなＳ１３０の処理を終えたら、左側のウィンドウ３２にツリー構造を表示して（Ｓ１３５）、初期表示を終了する。Ｓ１３５の処理が実行されると、メイン画面３１内において、左側のウィンドウ３２には、メモリカード１９内のフォルダの階層構造がツリー形式で表示される。左側のウィンドウ３２において、ツリー形式の表示中にある記号「＋」、「−」は、その記号の右側に表示されるフォルダの下に、さらに下位のサブフォルダが存在する場合に表示されるものである。なお、この場合でも、右側のウィンドウ３３内は、何ら表示のない状態になる。
【００６９】
［サムネイル設定機能の説明］
次に、メイン画面３１にある「サムネイル設定」ボタン３５をクリックすることによって操作可能となるサムネイル設定機能について説明する。
【００７０】
メイン画面３１にある「サムネイル設定」ボタン３５をクリックすると、クライアント２の表示部２３には、図４に示すサムネイル設定画面４１が表示され、このサムネイル設定画面４１内においてサムネイル設定を行うことができる。
【００７１】
このサムネイル設定画面４１には、複数のタブウィンドウ４３（図４では「設定１」〜「設定７」に対応する７つのタブウィンドウ４３を例示）とボタン４５、４７などが配置されている。
【００７２】
複数のタブウィンドウ４３は重ねて表示された状態になっていて、各タブウィンドウ４３の上端に設けられたタブ４３Ａをクリックすると、クリックされたタブ４３Ａに対応する１つのタブウィンドウ４３が最前面に重なる状態に切り替わるようになっている。
【００７３】
また、各タブウィンドウ４３には、いずれも同じ入力項目が用意されており、各タブウィンドウ４３において、カードブラウザで表示対象として扱うべきファイルを絞り込むための条件を入力できるようになっている。
【００７４】
具体的には、まず、第１の項目として、ファイル名入力欄５１が設けられている。このファイル名入力欄５１には、カードブラウザで表示対象として扱うべきファイルのファイル名を入力することができる。例えば、図４に例示してある「設定１」は、ファイルの拡張子が「．ＪＰＧ」であるファイルのみを、カードブラウザでの表示対象とする旨の設定である。
【００７５】
また、第２の項目として、設定の有効／無効を設定するためのラジオボタン５３が設けられている。このラジオボタン５３は、いずれか１つを択一的に選択でき、有効を選択した場合に、タブウィンドウ４３内の設定が有効となる一方、無効を選択すると、タブウィンドウ４３内の設定が無効となる。
【００７６】
したがって、このラジオボタン５３を利用すれば、設定を一時的に無効にした後、再び有効にしたいような場合に、他の項目をいちいち書き換えるような面倒なことをしなくても、タブウィンドウ４３毎に設定の有効／無効を切り替えることができる。
【００７７】
また、第３の項目として、日付条件入力欄５５が設けられている。この日付条件入力欄５５は、カードブラウザで表示対象として扱うべきファイルの日付条件を入力することができる。例えば、図４に例示してある「設定１」は、ファイルの日付が「１９７０／０１／０１  ００：００〜２０３９／１２／３１」の範囲内であるファイルのみを、カードブラウザでの表示対象とする旨の設定である。
【００７８】
さらに、第４の項目として、サムネイルの取得方法を設定するためのラジオボタン５７が設けられている。このラジオボタン５７も、いずれか１つを択一的に選択できる。
具体的には、サーバ１から取得可能なサムネイルには、いくつかの種類がある。具体的には、（Ａ）サーバ１側で用意された固定画像（以下、固定画像（Ａ）と称す。）、（Ｂ）あらかじめファイル内に格納されていたサムネイルをサーバ１側で抽出したもの（以下、抽出サムネイル（Ｂ）と称す。）、（Ｃ）サーバ１側でファイル内の実データから生成されたサムネイル（以下、生成サムネイル（Ｃ）と称す。）、以上の３種類がある。
【００７９】
これらの内、ファイルにサムネイルが含まれる場合には抽出サムネイル（Ｂ）を取得し、ファイルにサムネイルが含まれない場合には固定画像（Ａ）を取得したい場合、利用者は、上記ラジオボタン５７において、「ファイルにサムネイルが含まれない場合、拡張子毎に決められた固定画像を表示する」を選択する。
【００８０】
また、ファイルにサムネイルが含まれる場合には抽出サムネイル（Ｂ）を取得し、ファイルにサムネイルが含まれない場合には生成サムネイル（Ｃ）を取得したい場合、利用者は、上記ラジオボタン５７において、「ファイルにサムネイルが含まれない場合、サーバ側でサムネイルを作成して表示する」を選択する。
【００８１】
さらに、ファイルにサムネイルが含まれるか否かを問わず、常に生成サムネイル（Ｃ）を取得したい場合、利用者は、上記ラジオボタン５７において、「常にサーバ側でサムネイルを作成して表示する」を選択する。
【００８２】
以上のような１つのタブウィンドウ４３内での設定は、上記第１〜第４の項目すべてがＡＮＤ条件として扱われて１組分の設定とされる。そして、複数のタブウィンドウ４３に対応する複数組分の設定は、複数組分すべてがＯＲ条件として扱われる。
【００８３】
これらの設定は、サムネイル設定画面４１にある「ＯＫ」ボタン４５をクリックすることにより、クライアント２側の設定ファイルに記憶され、後述するクライアント２側での処理において利用されることになる。また、サムネイル設定画面４１にある「キャンセル」ボタン４７をクリックすれば、クライアント２側の設定ファイルを更新することなく、サムネイル設定画面４１を閉じることもできる。
【００８４】
なお、これら「ＯＫ」ボタン４５または「キャンセル」ボタン４７をクリックした際には、更新やキャンセルを行ってもよいかどうかを確認するためのダイヤログも表示されるが、このような確認ダイヤログは、この種のソフトウェアで一般的に採用されているものなので、図示および説明を省略する。
【００８５】
［カードブラウザ操作時の処理］
次に、クライアント２において利用者がカードブラウザを操作した際に実行される処理について、図５に基づいて説明する。この処理は、カードブラウザの起動後、初期表示を終えた時点で引き続いて実行される処理である。
【００８６】
この処理を開始すると、クライアント２は、まず、利用者からの入力待ちとなり、利用者が左側のウィンドウ３２内にあるツリー表示から特定のフォルダを選択するまで待機する（Ｓ２０５）。
【００８７】
Ｓ２０５の処理において、利用者は様々な入力操作を行うことができる。例えば、左側のウィンドウ３２内にある表示された記号「＋」をクリックすると、サブフォルダが展開表示されて記号が「−」に変わる。逆に、「−」をクリックすると、展開表示されていたサブフォルダの表示が消えて記号が「＋」に変わり、記号「＋」のみによってサブフォルダの存在を示す状態になる。
【００８８】
また、左側のウィンドウ３２において、利用者が１つのフォルダをクリック操作すると、そのフォルダ名が反転表示された状態（図３中のフォルダ「１０２ＢＲＯＴＨ」参照）となり、そのフォルダが選択された状態になる。
【００８９】
このような入力操作により、利用者が特定のフォルダを選択したら、クライアント２は、そのフォルダに対して「ファイル一覧」コマンドを発行する（Ｓ２１０）。この「ファイル一覧」コマンドは、クライアント２からサーバ１へと伝送され、サーバ１からはファイル一覧が返されることになる。
【００９０】
そこで、クライアント２は、取得したファイル一覧中に混在するファイルおよびフォルダの中からファイルだけをピックアップする。そして、すべてのファイルについて、右側のウィンドウ３３に仮アイコンおよびファイル名を表示する（Ｓ２１５）。
【００９１】
Ｓ２１５の処理において、右側のウィンドウ３３に表示されるファイルは、それぞれアイコンとファイル名とによって表示される。これらアイコンおよびファイル名を含む右側のウィンドウ３３の表示内容は、サーバ側で作成されたウェブページを表示するものとは異なり、カードブラウザ側の都合でレイアウトが決められたものである。
【００９２】
すなわち、カードブラウザは、各アイコンやファイル名の表示位置を自ら決めてウィンドウ３３内に表示する仕様となっており、この点であらかじめレイアウトされたサムネイルが含まれるウェブページをそのまま表示するウェブブラウザとは異なる仕様になっている。
【００９３】
また、このＳ２１５の時点で、右側のウィンドウ３３に表示されるアイコンは、（Ｄ）クライアント２側で用意された仮アイコン（以下、仮アイコン（Ｄ）と称す。）であり、この仮アイコン（Ｄ）は、既に説明した固定画像（Ａ）、抽出サムネイル（Ｂ）、および生成サムネイル（Ｃ）のいずれとも異なるものである。
【００９４】
Ｓ２１５の処理を終えたら、続いて、クライアント２は、処理対象を最初のファイルに設定（具体的には、ループカウンタを初期化）して、最初のファイルから処理を開始できるようにする（Ｓ２２０）。そして、［サーバ能力フラグ］＝０か否かを判断する（Ｓ２２５）。
【００９５】
［サーバ能力フラグ］には、後述する処理の中で０または１がセットされる可能性があるが、初めてＳ２２５の処理を実行する時点では、Ｓ１０５の処理によって［サーバ能力フラグ］に初期値：−１がセットされている。そのため、この場合、Ｓ２２５の処理では［サーバ能力フラグ］＝０ではないと判断され（Ｓ２２５：いいえ）、クライアント２は、「１ファイルアイコン更新処理」を実行する（Ｓ２３０）。このＳ２３０の「１ファイルアイコン更新処理」は、１つのファイルを対象にして、対象となるファイルに対応するウィンドウ３３内の表示を、サーバ１側から取得したサムネイルで更新する処理となる。この「１ファイルアイコン更新処理」の詳細については、後から図６および図７に基づいて詳述する。
【００９６】
さて、Ｓ２３０の処理を終えたら、最後のファイルまで処理を完了したか否かを判断し（Ｓ２３５）、処理を完了していなければ（Ｓ２３５：いいえ）、Ｓ２２５の処理へと戻る。この時、［サーバ能力フラグ］は、「１ファイルアイコン更新処理（Ｓ２３０）」の中で値が更新されており、その値は１または０となっている。
【００９７】
そのため、［サーバ能力フラグ］＝１の場合のみ、Ｓ２２５の処理では［サーバ能力フラグ］＝０ではないと判断され（Ｓ２２５：いいえ）、クライアント２は、再び「１ファイルアイコン更新処理」を実行することになる（Ｓ２３０）。
【００９８】
そして、［サーバ能力フラグ］＝１である限り、Ｓ２２５〜Ｓ２３５の処理が繰り返され、その繰り返し処理の中で最後のファイルまで処理が完了したら、Ｓ２３５の処理において最後のファイルまで完了したとの判断がなされる（Ｓ２３５：はい）。この場合は、図５に示す処理を終了する。
【００９９】
その結果、右側のウィンドウ３３には、「１ファイルアイコン更新処理」による所期のサムネイルが表示された状態になる。このようにＳ２２５〜Ｓ２３５の処理が繰り返された場合、右側のウィンドウ３３に表示されていた仮アイコン（Ｄ）は、順に上述の固定画像（Ａ）、抽出サムネイル（Ｂ）、生成サムネイル（Ｃ）のいずれかに更新されてゆくことになる。
【０１００】
一方、「１ファイルアイコン更新処理（Ｓ２３０）」の中で、［サーバ能力フラグ］＝０とされた場合、Ｓ２２５の処理では［サーバ能力フラグ］＝０であると判断される（Ｓ２２５：はい）。そのため、この場合も図５に示す処理を終了することになる。ただし、この場合は、サーバ１からサムネイルを取得できなかったことになるので、右側のウィンドウ３３には、Ｓ２１５の処理によって表示された仮アイコン（Ｄ）が、そのまま残された状態になる。
【０１０１】
なお、こうして右側のウィンドウ３３にファイル（＝アイコンおよびファイル名）が表示されたら、以後は、利用者は表示されたファイルをクリック操作で選択することができる。そして、例えば、その状態で「パソコンに転送」ボタン３９をクリックすれば、選択したファイルをサーバ１からクライアント２へ転送することができる。
【０１０２】
また、上記のように個々のファイルをクリックする代わりに、「すべて選択」ボタン３７をクリックすれば、右側のウィンドウ３３に表示されたファイルすべてを選択することもできる。
【０１０３】
また、「再表示」ボタン３６をクリックすると、サーバ１から最新情報が取得されて、左側のウィンドウ３２や右側のウィンドウ３３の表示内容が最新の状態に更新される。さらに、「終了」ボタン３８をクリックすると、カードブラウザを終了する。
【０１０４】
［１ファイルアイコン更新処理］
次に、上記Ｓ２３０の処理で実行される「１ファイルアイコン更新処理」について、図６および図７に基づいて説明する。この処理は、１つのファイルを対象にして、対象となるファイルに対応するウィンドウ３３内の表示を、サーバ１側から取得したサムネイルで更新するために実行される。
【０１０５】
この処理を開始すると、クライアント２は、ループカウンタを初期化して、サムネイル設定画面４１内で設定した複数の設定の内、「設定１」から比較を開始できるようにする（Ｓ３０５）。
【０１０６】
そして、比較を行う項目としては、第１に設定が有効か否かを判断し（Ｓ３１０）、第２にファイル名の設定を満たしているか否かを判断し（Ｓ３１５）、第３に日時の設定を満たしているか否かを判断する（Ｓ３２０）。
【０１０７】
Ｓ３１０の処理において、設定が有効か否かは、サムネイル設定画面４１内にあるラジオボタン５３で選択した設定に基づいて判断される。また、Ｓ３２０の処理において、ファイル名の設定を満たしているか否かは、サムネイル設定画面４１内にあるファイル名入力欄５１での入力内容に基づいて判断される。さらに、Ｓ３３０の処理において、日時の設定を満たしているか否かは、サムネイル設定画面４１内にある日付条件入力欄５５での入力内容に基づいて判断される。
【０１０８】
これら３つの条件の内、１つでも満たしていない条件がある場合は（Ｓ３１０：いいえ、Ｓ３１５：いいえ、およびＳ３２０：いいえの内、いずれか１つ）、Ｓ３２５の処理へと進む。
【０１０９】
Ｓ３２５の処理へと進んだ場合、クライアント２は、最後の設定まで完了したか否かを判断し（Ｓ３２５）、最後の設定まで完了していなければ（Ｓ３２５：いいえ）、Ｓ３１０の処理へと戻る。これにより、Ｓ３１０以降の処理が繰り返され、サムネイル設定画面４１内で設定した複数の設定が順に処理対象とされてゆく。
【０１１０】
そして、その結果、最後の設定まで完了すれば（Ｓ３２５：はい）、図６および図７に示す「１ファイルアイコン更新処理」を終了する。なお、この場合、処理対象となった１つのファイルについては、右側のウィンドウ３３内の表示が、上述の仮アイコン（Ｄ）のままとなる。
【０１１１】
一方、上記３つの条件すべてを満足した場合は（Ｓ３１０：はい、Ｓ３１５：はい、およびＳ３２０：はい、これらすべて）、図７に示すＳ３３０の処理へ進む（以下、図７の説明に移る）。Ｓ３３０の処理へと進むと、クライアント２は、［サーバ能力フラグ］＝−１か否かを判断する（Ｓ３３０）。
【０１１２】
ここで、［サーバ能力フラグ］＝−１であれば（Ｓ３３０：はい）、まだサーバ１の能力チェックがなされていないことを意味する。そこで、この場合は、リクエストヘッダ中のＰｒａｇｍａフィールドにおいて、フィールド値としてＴｈｕｍｂ＝１を設定して、ＨＥＡＤコマンド（メソッドにＨＥＡＤをセットしたＨＴＴＰリクエスト）を発行する（Ｓ３３５）。
【０１１３】
ＨＴＴＰリクエストは、複数行のテキストデータによって構成され、その第１行目を構成するリクエスト行には、メソッド、ＵＲＩ、バージョンなどの情報が記述されている。また、リクエスト行に続く第２行目以降、複数行にわたってリクエストヘッダが記述されている。ヘッダの行数は不定であるが、ヘッダの最終行は次の行が空行（改行コードのみの行）になっていて、その後にリクエストボディが続くデータ構造になっている。
【０１１４】
Ｓ３３５の処理では、上記リクエスト行中のメソッドにＨＥＡＤコマンドをセットし、リクエストヘッダ中にＰｒａｇｍａフィールドを設け、そのフィールド値としてＴｈｕｍｂ＝１を設定し、ＨＴＴＰリクエストをサーバ１へ送信する。
【０１１５】
Ｓ３３５の処理を実行すると、クライアント２からサーバ１へは上記ＨＴＴＰリクエストが伝送される。このとき、サーバ１は、このＨＴＴＰリクエストを解析し、Ｐｒａｇｍａフィールドでの指定に基づいて、サーバ１側に「サムネイル提供機能がある旨を示す情報」をレスポンスヘッダに格納し、ＨＴＴＰレスポンスを返す処理を実行する。
【０１１６】
「サムネイル提供機能がある旨を示す情報」としては、レスポンスヘッダにＰｒａｇｍａフィールドが設けられ、そのフィールド値として、Ｔｈｕｍｂ＝Ｎ（ただし、Ｎは１〜３のいずれか）が格納される。なお、このサーバ１側で実行される処理の詳細については、後から図８〜図１０に基づいて説明する。
【０１１７】
以上のようなサーバ１側での処理により、サーバ１側からＨＴＴＰレスポンスが返されたら、続いて、クライアント２は、サーバ１から戻ったレスポンスヘッダにＰｒａｇｍａフィールドが設けられ、そのフィールド値として、Ｔｈｕｍｂ＝Ｎ（ただし、Ｎは１〜３のいずれか）が設定されているか否かを判断する（Ｓ３４０）。
【０１１８】
ＨＴＴＰレスポンスは、複数行のテキストデータによって構成され、その第１行目を構成するステータス行に続く第２行目以降、複数行にわたってレスポンスヘッダが記述されている。ヘッダの行数は不定であるが、ヘッダの最終行は次の行が空行（改行コードのみの行）になっていて、その後にレスポンスボディが続くデータ構造になっている。
【０１１９】
Ｓ３４０の処理では、レスポンスヘッダ中に「Ｐｒａｇｍａ：Ｔｈｕｍｂ＝…」なる記述があれば（Ｓ３４０：あり）、この場合は、サーバ能力フラグに１をセットして（Ｓ３４５）、Ｓ３５５の処理へと進む。一方、レスポンスヘッダ中に「Ｐｒａｇｍａ：Ｔｈｕｍｂ＝…」なる記述がなければ（Ｓ３４０：なし）、この場合は、サーバ能力フラグに０をセットして（Ｓ３５０）、Ｓ３５５の処理へと進む。
【０１２０】
また、Ｓ３３０の処理において、［サーバ能力フラグ］＝−１でなければ（Ｓ３３０：いいえ）、既にサーバ１の能力チェックがなされていることを意味する。そこで、この場合は、上記Ｓ３３５〜Ｓ３５０の処理を実行することなく、Ｓ３５５の処理へと進む。
【０１２１】
こうしてＳ３５５の処理へと進んだら、クライアント２は［サーバ能力フラグ］＝１か否かを判断する（Ｓ３５５）。ここで、［サーバ能力フラグ］＝１でなければ（Ｓ３５５：いいえ）、サーバ１にサムネイル提供機能がないことを意味する。
【０１２２】
そこで、この場合は、図６および図７に示す「１ファイルアイコン更新処理」を終了する。なお、この場合、処理対象となった１つのファイルについては、右側のウィンドウ３３内の表示が、上述の仮アイコン（Ｄ）のままとなる。
【０１２３】
一方、［サーバ能力フラグ］＝１であれば（Ｓ３５５：はい）、サムネイルの取得方法の設定を判断する（Ｓ３６０）。Ｓ３６０の処理において、サムネイルの取得方法の設定は、サムネイル設定画面４１内にあるラジオボタン５７で選択した設定に基づいて判断される。
【０１２４】
具体的には、ラジオボタン５７で「ファイルにサムネイルが含まれない場合、拡張子毎に決められた固定画像を表示する」が選択されている場合（Ｓ３６０：ファイルにサムネイルが含まれない場合は固定画像）、サーバ１は、リクエストヘッダ中のＰｒａｇｍａフィールドに、フィールド値としてＴｈｕｍｂ＝１を格納して、サムネイル取得のためのＧＥＴコマンド（メソッドにＧＥＴをセットしたＨＴＴＰリクエスト）を発行する（Ｓ３６５）。
【０１２５】
また、ラジオボタン５７で「ファイルにサムネイルが含まれない場合、サーバ側でサムネイルを作成して表示する」が選択されている場合（Ｓ３６０：ファイルにサムネイルが含まれない場合はサーバ側で作成）、サーバ１は、リクエストヘッダ中のＰｒａｇｍａフィールドに、フィールド値としてＴｈｕｍｂ＝２を格納して、サムネイル取得のためのＧＥＴコマンド（メソッドにＧＥＴをセットしたＨＴＴＰリクエスト）を発行する（Ｓ３７０）。
【０１２６】
さらに、ラジオボタン５７で「常にサーバ側でサムネイルを作成して表示する」が選択されている場合（Ｓ３６０：常にサーバ側で作成）、サーバ１は、リクエストヘッダ中のＰｒａｇｍａフィールドに、フィールド値としてＴｈｕｍｂ＝３を格納して、サムネイル取得のためのＧＥＴコマンド（メソッドにＧＥＴをセットしたＨＴＴＰリクエスト）を発行する（Ｓ３７０）。
【０１２７】
以上説明したＳ３６５、Ｓ３７０、またはＳ３７５いずれかの処理により、ＧＥＴコマンドを発行すると、クライアント２からサーバ１へは上記ＨＴＴＰリクエストが伝送される。このとき、サーバ１は、このＨＴＴＰリクエストを解析して、Ｐｒａｇｍａフィールドでの指定に基づいて上述の固定画像（Ａ）、抽出サムネイル（Ｂ）、生成サムネイル（Ｃ）のいずれかをレスポンスボディに格納し、ＨＴＴＰレスポンスを返す処理を実行する。このサーバ１側で実行される処理の詳細については、後から図８〜図１０に基づいて説明する。
【０１２８】
以上のようなサーバ１側での処理により、サーバ１側からＨＴＴＰレスポンスが返されたら、続いて、クライアント２は、ＨＴＴＰレスポンス中のレスポンスボディからサムネイル（上述の固定画像（Ａ）、抽出サムネイル（Ｂ）、生成サムネイル（Ｃ）のいずれか）を抽出し、処理対処となっているファイルのアイコンを、取得したサムネイルに変更し（Ｓ３８０）、図６および図７に示す「１ファイルアイコン更新処理」を終了する。なお、この場合、処理対象となった１つのファイルについては、右側のウィンドウ３３内の表示が、上述の仮アイコン（Ｄ）から固定画像（Ａ）、抽出サムネイル（Ｂ）、生成サムネイル（Ｃ）のいずれかに変更されることになる。
（１．３）サーバ側の機能および処理
次に、サーバ１側の機能および処理について説明する。
【０１２９】
［ＨＴＴＰサーバ処理］
まず、サーバ１が実行するＨＴＴＰサーバ処理について、図８に基づいて説明する。このＨＴＴＰサーバ処理は、サーバ１において常時実行されている処理である。
【０１３０】
この処理を開始すると、サーバ１は、クライアント２からＨＴＴＰポート（８０番）に接続要求があるか否かを判断し（Ｓ４０５）、接続要求がなければ（Ｓ４０５：なし）、Ｓ４０５の処理へ戻ることによってクライアント２から接続要求があるまで待機する。そして、クライアント２から接続要求があった場合は（Ｓ４０５：ＹＥＳ）、ＨＴＴＰポート（８０番）接続処理を実行し（Ｓ４１０）、クライアント２との接続を確立する。
【０１３１】
続いて、サーバ１は、クライアント２からコマンドが来たか否かを判断する（Ｓ４１５）。クライアント２からのコマンドは、クライアント２から伝送されてくるＨＴＴＰリクエストに含まれている。Ｓ４１５の処理では、ＨＴＴＰリクエストの第１行目を構成するリクエスト行がクライアント２から伝送されてきた場合に、コマンドが来たと判断する。
【０１３２】
なお、Ｓ４１５の処理においてサーバ１側が受信するコマンドの内、本システムで重要なものとしては、例えば、クライアント２が上記Ｓ３３５の処理で発行したＨＥＡＤコマンド、あるいは、クライアント２が上記Ｓ３６５、Ｓ３７０、またはＳ３７５いずれかの処理で発行したＧＥＴコマンドなどを挙げることができる。ただし、これら以外にも、様々なコマンドがクライアント２から到来する可能性がある。
【０１３３】
Ｓ４１５の処理において、コマンドが来ていなければ（Ｓ４１５：まだ）、Ｓ４１５の処理へ戻ることによってクライアント２からコマンドが来るまで待機する。また、待機開始後、コマンドが来ないまま所定以上の時間が経過したらタイムアウトであると判断し（Ｓ４１５：タイムアウト）、この場合は、ポート切断処理を実行して（Ｓ４２０）、Ｓ４０５の処理へと戻る。
【０１３４】
一方、Ｓ４１５の処理において、コマンドが来た場合は（Ｓ４１５：来た）、そのコマンドを受け取って記憶する（Ｓ４２５）。具体的には、上述のリクエスト行をクライアント２からのコマンドとして記憶する。
【０１３５】
続いて、サーバ１は、ヘッダ（リクエストヘッダ）が来たか否かを判断する（Ｓ４３０）。このヘッダも、上述のリクエスト行と同様に、クライアント２から伝送されてくるＨＴＴＰリクエストに含まれる情報である。Ｓ４３０の処理では、ヘッダの一部に相当する１行分のデータがクライアント２から伝送されてきた場合に、ヘッダが来たと判断する。
【０１３６】
Ｓ４３０の処理において、ヘッダが来ていなければ（Ｓ４３０：まだ）、Ｓ４３０の処理へ戻ることによってクライアント２からヘッダが来るまで待機する。また、Ｓ４３０の処理において、ヘッダが来た場合は（Ｓ４３０：来た）、そのヘッダを受け取って蓄積記憶し（Ｓ４３５）、Ｓ４３０の処理へと戻る。
【０１３７】
Ｓ４３５の処理の後、Ｓ４３０の処理へと戻るのは、ヘッダが、上述のリクエスト行に続く第２行目以降、複数行にわたって記述されているからである。ヘッダの行数は不定であるが、ヘッダの最終行は次の行が空行（改行コードのみの行）になっていることをもって判断することができる。
【０１３８】
そこで、Ｓ４３０の処理では、空行が検出されるまではヘッダが来たと判断し（Ｓ４３０：来た）、Ｓ４３０〜Ｓ４５０の処理を繰り返すことにより、ヘッダに相当する複数行分のデータを蓄積する。
【０１３９】
一方、Ｓ４３０の処理において、空行が来た場合は（Ｓ４３０：空行が来た）、ヘッダが終了したことを意味するので、この場合は、コマンドがＧＥＴまたはＨＥＡＤであるか否かを判断する（Ｓ４４０）。具体的には、Ｓ４２５の処理で記憶したリクエスト行中のメソッドを表す文字列が、ＧＥＴまたはＨＥＡＤのいずれかであるか否かを判断する。
【０１４０】
そして、コマンドがＧＥＴまたはＨＥＡＤであった場合は（Ｓ４４０：はい）、ヘッダ中に文字列「Ｐｒａｇｍａ：Ｔｈｕｍｂ＝」があるか否かを判断する（Ｓ４４５）。「Ｐｒａｇｍａ：Ｔｈｕｍｂ＝」は、複数行分のデータで構成されるヘッダ中、いずれかの行に記載されている可能性がある文字列で、この文字列が記述されていれば、サムネイルの要求である旨を示すサムネイル要求情報がヘッダに格納されていることになる。
【０１４１】
以上のようなＳ４４０、Ｓ４４５の処理を実行した結果、コマンドがＧＥＴおよびＨＥＡＤのいずれでもない場合（Ｓ４４０：いいえ）、あるいは、ヘッダ中に文字列「Ｐｒａｇｍａ：Ｔｈｕｍｂ＝」がない場合（Ｓ４４５：ない）は、一般的なＨＴＴＰ処理を実行する（Ｓ４５０）。なお、Ｓ４５０の処理は、周知のＨＴＴＰサーバが実行する処理そのものなので、具体的な説明は省略する。
【０１４２】
一方、コマンドがＧＥＴまたはＨＥＡＤのいずれかであって（Ｓ４４０：はい）、且つ、ヘッダ中に文字列「Ｐｒａｇｍａ：Ｔｈｕｍｂ＝」がある場合（Ｓ４４５：ある）は、「サムネイル対応ＨＴＴＰ処理」を実行する（Ｓ４５５）。
【０１４３】
コマンドがＧＥＴ、且つ、ヘッダ中に文字列「Ｐｒａｇｍａ：Ｔｈｕｍｂ＝」があるのは、クライアント２が上記Ｓ３６５、Ｓ３７０、またはＳ３７５いずれかの処理を実行した場合である。また、コマンドがＨＥＡＤ、且つ、ヘッダ中に文字列「Ｐｒａｇｍａ：Ｔｈｕｍｂ＝」があるのは、クライアント２が上記Ｓ３３５の処理を実行した場合である。
【０１４４】
Ｓ４５５の「サムネイル対応ＨＴＴＰ処理」は、クライアント２側からの要求に応じたサムネイルをクライアント２側へ送信する処理となるが、この「サムネイル対応ＨＴＴＰ処理」の詳細については、後から図９および図１０に基づいて詳述する。
【０１４５】
こうして「一般的なＨＴＴＰ処理（Ｓ４５０）」または「サムネイル対応ＨＴＴＰ処理（Ｓ４５５）」のいずれかを終えたら、Ｓ４１５の処理へと戻ることにより、再びクライアント２からＨＴＴＰリクエストが伝送されてくるのを待機する状態になる。そして、ＨＴＴＰリクエストが伝送されてくれば、上述したＳ４２５以降の処理を繰り返す一方、ＨＴＴＰリクエストが伝送されてこなければ、上述したＳ４２０の処理を経てＳ４０５の処理へと戻り、クライアント２からの接続要求を待ち受ける状態となる。
【０１４６】
［サムネイル対応ＨＴＴＰ処理］
次に、上記Ｓ４５５の処理に相当する「サムネイル対応ＨＴＴＰ処理」の詳細について、図９および図１０に基づいて説明する。
【０１４７】
この「サムネイル対応ＨＴＴＰ処理」を開始すると、サーバ１は、まず、「サムネイル抽出／生成処理」を実行する（Ｓ５０５）。この「サムネイル抽出／生成処理」は、詳しくは図１０に示すような処理となる。
【０１４８】
ここで、図１０の説明に移る。「サムネイル抽出／生成処理」では、まず、ヘッダ中にある文字列「Ｐｒａｇｍａ：Ｔｈｕｍｂ＝」に引き続いて記述されている文字が、「１」、「２」、「３」のいずれであるのかを判断する（Ｓ６０５）。ただし、本実施形態において、Ｓ６０５の処理では、「２、３以外」の場合は、すべて「１」であると判断する仕様となっている。
【０１４９】
Ｓ６０５の処理において、「１」であると判断された場合（Ｓ６０５：１）、続いてファイルにサムネイルが含まれているか否かを判断する（Ｓ６１０）。Ｓ６１０の処理において、処理対象となるファイルは１つのファイルであり、そのファイル名は、Ｓ４２５の処理で記憶したリクエスト行中、ＵＲＩに相当する文字列として格納されている。
【０１５０】
比較的広く知られた既存の画像ファイルの内、サムネイルが含まれている可能性がある画像ファイルとしては、例えば、ＪＰＧ形式のファイル、ＢＭＰ形式のファイルなどを挙げることができる。
【０１５１】
ただし、サムネイルの抽出対象となるファイルの具体的な形式は、特に限定されるものではなく、何らかの形でサムネイルがファイル内に含まれていて、且つ、そのサムネイルをサーバ１が抽出できるデータ構造になっていればよい。
【０１５２】
また、ファイルの仕様上、サムネイルが含まれ得る形式のファイルであっても、実際にサムネイルが含まれているか否かは不定である。したがって、Ｓ６１０の処理では、まずサムネイルの抽出対象となるファイル形式であるか否かを確認し、続いて、実際にサムネイルが含まれているか否かを確認することになる。
【０１５３】
以上のようなＳ６１０の処理の結果、ファイルにサムネイルが含まれていない場合は（Ｓ６１０：いいえ）、後述するＨＴＴＰレスポンスを構成するためのデータ群Ｎ、ＤＡＴＡ、ＳＩＺＥに関し、それぞれの格納値として、Ｎ＝１、ＤＡＴＡ＝固定画像の実データ、ＳＩＺＥ＝固定画像のサイズを格納する（Ｓ６１５）。なお、固定画像は、ファイルにサムネイルが含まれていない場合にクライアント２へ伝送される画像であり、どの画像を使用するかはあらかじめファイルの拡張子毎に取り決められている。
【０１５４】
一方、Ｓ６１０の処理の結果、ファイルにサムネイルが含まれている場合は（Ｓ６１０：はい）、上記データ群Ｎ、ＤＡＴＡ、ＳＩＺＥに関し、それぞれの格納値として、Ｎ＝２、ＤＡＴＡ＝ファイル内に含まれるサムネイルの実データ、ＳＩＺＥ＝ファイル内に含まれるサムネイルのサイズを格納する（Ｓ６２０）。
【０１５５】
さて一方、Ｓ６０５の処理において、「２」であると判断された場合も（Ｓ６０５：２）、続いてファイルにサムネイルが含まれているか否かを判断する（Ｓ６２５）。ここで、ファイルにサムネイルが含まれている場合は（Ｓ６２５：はい）、上記データ群Ｎ、ＤＡＴＡ、ＳＩＺＥに関し、それぞれの格納値として、Ｎ＝２、ＤＡＴＡ＝ファイル内に含まれるサムネイルの実データ、ＳＩＺＥ＝ファイル内に含まれるサムネイルのサイズを格納する（Ｓ６２０）。
【０１５６】
一方、Ｓ６２５の処理の結果、ファイルにサムネイルが含まれていない場合は（Ｓ６２５：いいえ）、バッファ１にファイル全体を読み込み（Ｓ６３０）、バッファ１からサムネイルを作成してバッファ２に格納する（Ｓ６３５）。すなわち、サーバ１がメモリ上に２つのバッファを確保して、サムネイルを生成する処理を実行する。
【０１５７】
そして、上記データ群Ｎ、ＤＡＴＡ、ＳＩＺＥに関し、それぞれの格納値として、Ｎ＝３、ＤＡＴＡ＝新たに作成されてバッファ２に格納されたサムネイルの実データ、ＳＩＺＥ＝新たに作成されたサムネイルのサイズを格納する（Ｓ６４０）。
【０１５８】
さらに一方、Ｓ６０５の処理において、「３」であると判断された場合は（Ｓ６０５：３）、上記Ｓ６３０の処理へと進む。その結果、サーバ１は、バッファ１にファイル全体を読み込み（Ｓ６３０）、バッファ１からサムネイルを作成してバッファ２に格納する（Ｓ６３５）。
【０１５９】
そして、上記データ群Ｎ、ＤＡＴＡ、ＳＩＺＥに関し、それぞれの格納値として、Ｎ＝３、ＤＡＴＡ＝新たに作成されてバッファ２に格納されたサムネイルの実データ、ＳＩＺＥ＝新たに作成されたサムネイルのサイズを格納する（Ｓ６４０）。
【０１６０】
以上説明したようなＳ６０５以降の処理が実行される結果、上記データ群Ｎ、ＤＡＴＡ、ＳＩＺＥには何らかのデータが格納され、これにて図１０に示す「サムネイル抽出／生成処理」を終了することになる。そして、この処理を終了すると、図９に示すＳ５０５の処理を終えたことになる。以下、図９の説明に戻る。
【０１６１】
Ｓ５０５の処理を終えたら、サーバ１は、Ｓ５１０〜Ｓ５３５の処理により、クライアント２に対するＨＴＴＰレスポンスの送信を開始する。具体的には、まず、「一般的なＨＴＴＰ処理」の場合と同じヘッダをクライアント２に送信する（Ｓ５１０）。ただし、Ｓ５１０の処理では、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈフィールドの送信は行わない。
【０１６２】
続いて、サーバ１は、ヘッダ（レスポンスヘッダ）の一部としてＰｒａｇｍａ：Ｔｈｕｍｂ＝Ｎをクライアント２に送信する（Ｓ５１５）。すなわち、Ｓ５１５の処理では、レスポンスヘッダ中にＰｒａｇｍａフィールドを設け、そのフィールド値としてＴｈｕｍｂ＝Ｎを格納して、クライアント２への送信を行う。上記フィールド値を構成する文字列の内、「Ｔｈｕｍｂ＝」は固定部分である。また、Ｎは上記Ｓ６１５、Ｓ６２０、Ｓ６４０いずれかの処理で設定された値Ｎであり、具体的には、文字「１」、「２」、「３」のいずれかである。
【０１６３】
続いて、サーバ１は、ヘッダ（レスポンスヘッダ）の一部としてＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：ＳＩＺＥをクライアント２に送信する（Ｓ５２０）。すなわち、Ｓ５１５の処理では、レスポンスヘッダ中にＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈフィールドを設け、そのフィールド値としてＳＩＺＥを格納して、クライアント２への送信を行う。上記フィールド値中、ＳＩＺＥは上記Ｓ６１５、Ｓ６２０、Ｓ６４０いずれかの処理で設定された値ＳＩＺＥ（文字列で表記された数値）である。
【０１６４】
そして、サーバ１は、空行をクライアント２に送信することにより、ヘッダ終了を通知して（Ｓ５２５）、コマンドがＧＥＴまたはＨＥＡＤのいずれであるかを判断する（Ｓ５３０）。具体的には、Ｓ４２５の処理で記憶したリクエスト行中のメソッドを表す文字列が、ＧＥＴまたはＨＥＡＤのいずれかであるかを判断する。
【０１６５】
そして、コマンドがＧＥＴであった場合は（Ｓ５３０：ＧＥＴ）、ＤＡＴＡをＢＡＳＥ６４エンコードしてクライアント２に送信して（Ｓ５３５）、図９に示す処理を終了する。送信対象となるＤＡＴＡは、上記Ｓ６１５、Ｓ６２０、Ｓ６４０いずれかの処理で設定された値ＤＡＴＡである。このＤＡＴＡは、ＨＴＴＰレスポンスの一部を構成するレスポンスボディとして送信される。また、ＢＡＳＥ６４は、ＨＴＴＰ通信において利用される周知の符号化方式である。
【０１６６】
なお、Ｓ５３０の処理において、コマンドがＨＥＡＤであった場合は（Ｓ５３０：ＨＥＡＤ）、Ｓ５３５の処理を実行することなく、図９に示す処理を終了する。これにより、ＨＴＴＰレスポンスとしてレスポンスヘッダだけが返され、レスポンスボディは返されないことになる。
【０１６７】
以上のようなＳ５１０〜Ｓ５３５の処理により、クライアント２に対するＨＴＴＰレスポンスを送信すると、このＨＴＴＰレスポンスがクライアント２へと届く。
このＨＴＴＰレスポンスがクライアント２側に届くと、クライアント２側では、例えば、上述のＳ３４０以降の処理が実行されることにより、レスポンスヘッダ内の情報に基づき、サーバ１がサムネイル提供機能を有するか否かの確認が行われる。
【０１６８】
あるいは、クライアント２側では、上述のＳ３８０の処理が実行され、レスポンスボディからサムネイル（上述の固定画像（Ａ）、抽出サムネイル（Ｂ）、生成サムネイル（Ｃ）のいずれか）が抽出され、処理対処となっているファイルのアイコンが、サーバ１から取得したサムネイルに変更される。
（１．４）第１実施形態の効果
以上説明したサムネイル配信システムによれば、サムネイルを必要とするファイルをクライアント２側で任意に指定すると、そのファイルに対応するサムネイルをサーバ１側から取得することができる。
【０１６９】
したがって、このようなサムネイル配信システムであれば、サムネイルのファイル名が認識できていないクライアント２であっても、サムネイルの基になるファイルのファイル名さえ認識できていれば、サーバ１からサムネイルを取得することができる。
【０１７０】
よって、クライアント２側では、事前にサーバ１からＨＴＭＬファイルの如き情報を受け取って、その中に記述されたリンクをたどってサムネイルを取得する、といった面倒な手間をかけなくても、きわめて簡単にサムネイルを取得することができる。また、実際にサムネイルを伝送するのに先立ち、ＨＴＭＬファイルの如き情報を伝送する必要がないので、その分だけネットワークにかかる負荷を軽減することもできる。
【０１７１】
さらに、このサムネイル配信システムの場合、サムネイルを必要とするファイルをクライアント２側で指定できる。したがって、クライアント２が必要か否かを問わず、サーバ１側で選定されたサムネイルすべてがクライアント２側へ伝送されてきてしまうものと比較すると、サーバ１およびネットワークにかかる無駄な負荷を軽減できる。
【０１７２】
加えて、サムネイルの取得に当たっては、広く普及したＨＴＴＰを利用することができるので、ＨＴＴＰに対応したプロキシサーバや各種中継サーバを経由してでも、サムネイルを取得することができる。
【０１７３】
また、上記サムネイル配信システムによれば、サーバ１が備えるメモリカード１９（記憶手段）に記憶されたファイルに関するファイル情報（ファイル名、日付）に基づいて、所望のファイルをクライアント２側で選択して、サムネイルをサーバ１から取得することができる。しかも、取得した１または２以上のサムネイルを表示する際には、クライアント側のソフトウェアであるカードブラウザが任意に表示位置を決めて表示することができる。
【０１７４】
したがって、サムネイルのレイアウトがサーバ１側で決められた状態で配信されるウェブページを単にクライアント２側で表示するものとは異なり、クライアント２側の都合でサムネイルのレイアウトを最適化することができる。
【０１７５】
さらに、上記サムネイル配信システムによれば、サムネイル要求情報がＰｒａｇｍａヘッダフィールドのフィールド値としてＨＴＴＰリクエスト中に格納される。したがって、各種中継サーバを経由してサムネイルの伝送を実現する場合であっても、Ｐｒａｇｍａヘッダフィールドのフィールド値は、ＨＴＴＰの規格上、確実に保持されることが決まっているため、クライアント２からサーバ１へ確実な情報伝達を行うことができる。
【０１７６】
また、上記画像配信システムによれば、ＨＴＴＰレスポンスとして返されたデータが、サムネイルであることを検証したい場合に、レスポンスヘッダで確認することができるので、レスポンスボディとして返される実データを検証しなくても済む。
【０１７７】
また、上記サムネイル配信システムによれば、サムネイル提供情報がＰｒａｇｍａヘッダフィールドのフィールド値としてＨＴＴＰレスポンス中に格納される。したがって、各種中継サーバを経由してサムネイルの伝送を実現する場合であっても、Ｐｒａｇｍａヘッダフィールドのフィールド値は、ＨＴＴＰの規格上、確実に保持されることが決まっているため、サーバ１からクライアント２へ確実な情報伝達を行うことができる。
【０１７８】
また、上記サムネイル配信システムによれば、ＨＥＡＤコマンドを利用することにより、レスポンスボディを伝送することなく、レスポンスヘッダに基づいて、サーバがサムネイル提供機能を有するか否かを判定することができる。
【０１７９】
加えて、上記サムネイル配信システムによれば、サーバは、ファイル内にサムネイルが含まれていれば、そのサムネイルをクライアントに提供することができる。また、ファイル内にサムネイルが含まれていなければ、事前に用意されたサムネイルをクライアントに提供することができる。さらに、ファイル内にサムネイルが含まれていない場合、ファイルに基づいてサムネイルを生成し、そのサムネイルをクライアントに提供することもできる。あるいは、ファイル内にサムネイルが含まれているか否かを問わず、ファイルに基づいてサムネイルを生成し、そのサムネイルをクライアントに提供することもできる。
【０１８０】
しかも、これら複数通りの手法をどのように組み合わせて利用するかは、利用者がラジオボタン５７で任意に選択できる。したがって、利用者の好みに応じた手法でサムネイルを生成し、そのサムネイルをクライアントに提供できる。
（２）第２実施形態
次に、別の実施形態について説明する。ただし、以下に説明する実施形態は、大部分が上述の実施形態と同様に構成されるので、以下の説明では上述の実施形態との相違点を中心に説明する。なお、上述の実施形態と同様に構成される部分については、上述の実施形態と同じ符号を付すことにして、それらの構成についての詳細な説明は省略する。
（２．１）クライアント側の機能および処理
まず、クライアント２側の機能および処理について、第１実施形態との相違点を中心に説明する。
【０１８１】
［サムネイル設定機能の説明］
第２実施形態においては、まず、カードブラウザのサムネイル設定機能が、第１実施形態とは相違する。具体的には、メイン画面３１にある「サムネイル設定」ボタン３５をクリックすると、クライアント２の表示部２３には、図１１に示すサムネイル設定画面６１が表示され、このサムネイル設定画面６１内においてサムネイル設定を行うことができる。
【０１８２】
このサムネイル設定画面６１内に、複数のタブウィンドウ４３が表示される点は第１実施形態と同じである。また、各タブウィンドウ４３内に表示される項目の内、ファイル名入力欄５１、ラジオボタン５３、および日付条件入力欄５５は、第１実施形態と同様の項目である。
【０１８３】
一方、各タブウィンドウ４３内に表示される項目の内、ラジオボタン６３は、第１実施形態で示したラジオボタン５７とは、若干異なる仕様となっている。具体的には、ラジオボタン６３も、いずれか１つを択一的に選択できる点は第１実施形態と同様であるが、第１実施形態において３つあった選択肢は、第２実施形態においては２つとされている。
【０１８４】
これらの内、ファイルにサムネイルが含まれる場合には抽出サムネイル（Ｂ）を取得し、ファイルにサムネイルが含まれない場合には固定画像（Ａ）を取得したい場合、利用者は、上記ラジオボタン６３において、「拡張子毎に決められた固定画像を表示する」を選択する。
【０１８５】
また、ファイルにサムネイルが含まれる場合には抽出サムネイル（Ｂ）を取得し、ファイルにサムネイルが含まれない場合には生成サムネイル（Ｃ）を取得したい場合、利用者は、上記ラジオボタン６３において、「サーバ側でサムネイルを作成して表示する」を選択する。
【０１８６】
つまり、第１実施形態のラジオボタン５７では選択することができた「常にサーバ側でサムネイルを作成して表示する」という選択肢が、第２実施形態では選択できない仕様となっている。
【０１８７】
このような仕様とすると、常にサーバ１側でサムネイルを作成することはできなくなるが、利用者が不用意に「常にサーバ側でサムネイルを作成して表示する」という選択肢を選択してしまうことはなくなるので、サーバ１に過大な負荷をかけてしまうことはない。したがって、サーバ１の処理能力が比較的低い場合には、このような仕様を採用するメリットがある。
【０１８８】
［１ファイルアイコン更新処理］
次に、上記サムネイル設定機能の仕様変更に伴う「１ファイルアイコン更新処理」の変更点について、図１２に基づいて説明する。
【０１８９】
第１実施形態においては図６および図７に示した「１ファイルアイコン更新処理」を実行していたが、この処理に代えて、第２実施形態においては図６および図１２に示す「１ファイルアイコン更新処理」を実行する。すなわち、第１実施形態からの変更点は、図１２のみに含まれ、図６に示す処理に変更はない。
【０１９０】
具体的には、図７に示すＳ３６０の処理に代えて、Ｓ３６３の処理を実行している点と、Ｓ３７５の処理に相当する処理が存在しない点が、第１実施形態からの変更点であり、その他の点に変更はない。
【０１９１】
詳しく説明すると、第１実施形態では、ラジオボタン５７で３種類の選択肢の中からサムネイルの取得方法を設定できたので、Ｓ３６０の処理（図７参照）では、それら３種類の選択肢の内、いずれが設定されているのかを判断していたが、第２実施形態では、ラジオボタン６３で２種類の選択肢の中からサムネイルの取得方法を設定する仕様に変更されたので、Ｓ３６３の処理では、それら２種類の選択肢の内、いずれが設定されているのかを判断する（Ｓ３６３）。
【０１９２】
なお、それら２種類の選択肢の内、いずれが設定されているかに応じて、Ｓ３６５またはＳ３７０の処理のいずれかへと進むので、第２実施形態では、Ｓ３７５の処理に相当する処理は実行されなくなった。
（２．２）サーバ側の機能および処理
次に、サーバ１側の機能および処理について、第１実施形態との相違点を中心に説明する。
【０１９３】
［サムネイル対応ＨＴＴＰ処理］
次に、上記サムネイル設定機能の仕様変更に伴う「サムネイル対応ＨＴＴＰ処理」の変更点について、図１３に基づいて説明する。
【０１９４】
第１実施形態においては図１０に示した「サムネイル抽出／生成処理」を実行していたが、この処理に代えて、第２実施形態においては図１３に示す「サムネイル抽出／生成処理」を実行する。第１実施形態からの変更点は、Ｓ６０５の処理に代えて、Ｓ６０７の処理を実行している点にあり、その他の点に変更はない。
【０１９５】
具体的には、Ｓ６０５の処理（図１０参照）では、ヘッダ中にある文字列「Ｐｒａｇｍａ：Ｔｈｕｍｂ＝」に引き続いて記述されている文字が、「１」、「２」、「３」のいずれであるのかを判断していたが、Ｓ６０７の処理では、ヘッダ中にある文字列「Ｐｒａｇｍａ：Ｔｈｕｍｂ＝」に引き続いて記述されている文字が、「１」、「２」のいずれであるのかを判断する（Ｓ６０７）。
【０１９６】
つまり、上記サムネイル設定機能の仕様変更に伴い、「Ｐｒａｇｍａ：Ｔｈｕｍｂ＝３」は、クライアント２側から到来しない仕様となっているので、この判定を省略してある。なお、第１実施形態において、「Ｐｒａｇｍａ：Ｔｈｕｍｂ＝３」の場合は、Ｓ６３０の処理へと進むように構成されていたが、Ｓ６３０の処理は、Ｓ６２５の処理からも進む処理となっているので、Ｓ６３０の処理およびそれに続く処理は、第１実施形態と同様に残されている。
（２．３）第２実施形態の効果
以上説明したサムネイル配信システムでも、第１実施形態について述べたとおりの作用、効果を奏する。
【０１９７】
しかも、第２実施形態では、常にサーバ１側でサムネイルが作成される状態にはならないので、サーバ１に過大な負荷をかけてしまうことがなく、サーバ１の処理能力が比較的低い場合でも、システムを適切に運用することができる。
（３）変形例等
以上、本発明の実施形態について説明したが、本発明は上記の具体的な一実施形態に限定されず、この他にも種々の形態で実施することができる。
【０１９８】
例えば、上記実施形態では、ＨＴＴＰリクエストを発行するアプリケーションとして、特定のレイアウトでサムネイルを表示するカードブラウザを例示したが、本発明の最も重要な点は、サムネイル要求情報がリクエストヘッダに格納されたＨＴＴＰリクエストを発行する点にあり、取得したサムネイルをどのように表示するかについては限定されない。
【０１９９】
例えば、一般的なウェブブラウザのように、ＵＲＬを直接入力することができるユーザーインターフェースを持つアプリケーションにおいて、本発明の構成を採用してもよく、この場合、サーバ上のファイルに対応するＵＲＬを直接入力して、そのサムネイルを取得することができる。取得したサムネイルは、上述のカードブラウザのように表示してもよいし、別の用途に利用するためにファイルに保存するようにしてもよく、あるいは、プリンタ等で印刷出力してもよい。
【０２００】
すなわち、サーバからＨＴＴＰレスポンスを受信した後、そのレスポンスボディに格納されたサムネイルを利用してどのようなデータ処理を実行するのかは任意であり、表示、印刷、保存など様々なデータ処理を実行することができる。
【０２０１】
また、上記実施形態では、サーバ１およびクライアント２が、ＷｅｂＤＡＶにも準拠している旨を説明したが、サーバおよびクライアントがＷｅｂＤＡＶに準拠しているものか否かは任意である。
【０２０２】
また、上記実施形態では、Ｓ３３５の処理により、クライアント２がＨＥＡＤコマンドを発行して、サーバ１のサムネイル提供機能の有無を確認していたが、これについては、以下のような構成も採用できる。
【０２０３】
すなわち、１つ目の処理対象ファイルに関してのみ、クライアント２は、例外的にサーバ１のサムネイル提供機能の有無を確認しないまま、Ｓ３６５、Ｓ３７０、またはＳ３７５の処理に相当する処理を実行するように構成する。そして、その結果として返されるＨＴＴＰレスポンスから、サーバ１のサムネイル提供機能の有無を判断する。これにより、サーバ１のサムネイル提供機能の有無が判明する。
【０２０４】
したがって、２つ目以降の処理対象ファイルについては、サーバ１がサムネイル提供機能を有する場合のみ、上記実施形態同様、Ｓ３６５、Ｓ３７０、またはＳ３７５の処理により、クライアント２がＧＥＴコマンドを発行するように構成する。
【０２０５】
このような手法であれば、１つ目の処理対象ファイルのみ、サーバ１にサムネイル提供機能がなくても、ＧＥＴコマンドを発行してしまう可能性があるが、その場合でも、１ファイルのみファイル本体の伝送が発生するだけなので、実用上は特に問題はない。
【０２０６】
むしろ、このようにサーバ１にサムネイル提供機能がない場合には、ファイル本体の伝送が発生するので、これを有効利用するシステムも考え得る。
例えば、サーバ１のサムネイル提供機能の有無をあえて確認することなく、すべての処理対象ファイルについて、ＧＥＴコマンドを発行する構成を採用してもよい。
【０２０７】
この場合、サーバ１がサムネイル提供機能を有していれば、クライアント２へはサムネイルが伝送され、サーバ１がサムネイル提供機能を有していなければ、クライアント２へはファイル本体が伝送される。
【０２０８】
つまり、同じＧＥＴコマンドを発行するだけで、サーバ１側の機能に応じてサムネイルかファイル本体のいずれかが伝送されることになる。このような仕組みであれば、例えば、クライアント２では、伝送されてきたデータがファイル本体であった場合に、ファイル本体に基づいてサムネイルの生成を行うことができる。
【０２０９】
したがって、ネットワーク上での通信トラフィック抑制よりも、クライアント側で確実にサムネイルを取得できるようにすることを重視する場合には、簡単にサムネイルかファイル本体いずれかを取得できるようになる。
【０２１０】
また、上記実施形態では、サーバ１が備えるカードリーダ部１４にセットされたメモリカード１９内のファイルを対象にして、サムネイルの抽出／生成／クライアント２への配信などを行っていたが、これに限らない。すなわち、サムネイルの基になるファイルを記憶する記憶装置については、様々な形態のものを考え得る。
【０２１１】
具体例を挙げれば、サーバ１が備えるハードディスク装置等のように、リムーバブルメディアの装着／脱着ができない形態の記憶装置であってもよい。あるいは、サーバ１がネットワーク経由でアクセス可能なネットワークストレージデバイス等のように、サーバ１の外部に設置される形態の記憶装置であってもよい。さらに、このようなネットワークストレージデバイスの場合においても、例えば、サーバ１と同じＬＡＮ内に存在するカードリーダにセットされたリムーバブルメディアにファイルが記憶されていてもよいし、サーバ１と同じＬＡＮ内に存在するハードディスクタイプのデバイスにファイルが記憶されていてもよい。
【図面の簡単な説明】
【０２１２】
【図１】サムネイル配信システム全体の構成を示したブロック図。
【図２】カードブラウザ起動時の処理のフローチャート。
【図３】カードブラウザのメイン画面の説明図。
【図４】第１実施形態におけるカードブラウザのサムネイル設定画面の説明図。
【図５】カードブラウザ操作時の処理のフローチャート。
【図６】１ファイルアイコン更新処理（その１）のフローチャート。
【図７】第１実施形態における１ファイルアイコン更新処理（その２）のフローチャート。
【図８】ＨＴＴＰサーバ処理のフローチャート。
【図９】サムネイル対応ＨＴＴＰ処理のフローチャート。
【図１０】第１実施形態におけるサムネイル抽出／生成処理のフローチャート。
【図１１】第２実施形態におけるカードブラウザのサムネイル設定画面の説明図。
【図１２】第２実施形態における１ファイルアイコン更新処理（その２）のフローチャート。
【図１３】第２実施形態におけるサムネイル抽出／生成処理のフローチャート。
【符号の説明】
【０２１３】
１・・・サーバ、２・・・クライアント、５，６・・・ゲートウェイ、７・・・ネットワーク、１１，２１・・・制御部、１２，２２・・・入力部、１３，２３・・・表示部、１４・・・カードリーダ部、１５，２５・・・ネットワーク通信部、１６・・・スキャナ部、１７・・・プリンタ部、１８・・・ＦＡＸ通信部、１９・・・メモリカード、２４・・・記憶部、３１・・・メイン画面、３２，３３・・・ウィンドウ、３４〜３９，４５，４７・・・ボタン、４１，６１・・・サムネイル設定画面、４３・・・タブウィンドウ、４３Ａ・・・タブ、５１・・・ファイル名入力欄、５３，５７，６３・・・ラジオボタン、５５・・・日付条件入力欄。
【図１】
0004561804.tif 000002
【図２】
0004561804.tif 000003
【図５】
0004561804.tif 000004
【図６】
0004561804.tif 000005
【図７】
0004561804.tif 000006
【図８】
0004561804.tif 000007
【図９】
0004561804.tif 000008
【図１０】
0004561804.tif 000009
【図１２】
0004561804.tif 000010
【図１３】
0004561804.tif 000011
【図３】
0004561804.tif 000012
【図４】
0004561804.tif 000013
【図１１】
0004561804.tif 000014