JP2005182760A - 情報処理装置およびその制御方法 - Google Patents

Abstract

【課題】 ユーザが転送する画像を選択しながら、仮に選択画像を転送した場合の転送先の記憶領域の残り容量を動的に知ることができるようにする。
【解決手段】 所定容量のデータ記憶領域を提供するサーバにネットワークを介して接続され、そのデータ記憶領域にファイル転送が可能に構成された、クライアントとしての情報処理装置に関する。クライアントはサーバからデータ記憶領域の空き容量の情報を取得する。また、データ記憶領域に転送するファイルをユーザに選択させるためのＧＵＩを表示し、表示したＧＵＩに対する入力デバイスによるドラッグアンドドロップ指示に基づいてデータ記憶領域に転送するファイルを選択する。そして、現在選択されているファイルの合計ファイル容量と取得された前記データ記憶領域の空き容量との差分値を計算する。この差分値は、入力デバイスによる指示に応答してＧＵＩ上にダイナミックに表示される。
【選択図】 図１５

Description

本発明は、コンピュータネットワーク環境におけるファイル転送の技術に関し、特にユーザに所定の記憶容量を割り当てて情報記憶領域を提供するサーバ装置に対してファイルを転送する際に、転送に関わる情報をユーザに提示する技術に関する。

従来より、ネットワーク上にユーザ専用のデータ記憶領域を提供するサービスサイト（ストレージサイト）がある。例えば、ユーザの画像をネットワーク上のサーバが管理する記憶装置に保管し、編集、印刷、閲覧等のサービスを提供するフォトシェアリングサイトもその一つである。

従来、このようなフォトシェアリングサイトをユーザが利用する場合、まず、ユーザが有するコンピュータ機器（ユーザＰＣ）、デジタル撮像機器（デジタルビデオカメラ、デジタルスチルカメラ等）、もしくはデジタル撮像機器を有する電子機器などに保管されている画像を、フォトシェアリングサイトを実現するサーバ装置に転送する（いわゆるアップロード）。かかる後に、これらアップロードした画像の閲覧や、画像処理などのサービスが利用可能になる。

ユーザのアップロード操作は、まずユーザ機器上で、ユーザが保有する画像の中からアップロードする画像を選択し、しかる後にアップロードを指示するという２段階を踏む場合が多い。

アップロードする画像の選択操作においては、各機器で直接選択したり、あるいはコンピュータ機器にいったん転送してからコンピュータ機器上のソフトウェアで選択したりする。

アップロード操作においては、ユーザ機器から直接、又はインターネットに接続可能なコンピュータ機器等を介し、HTTP（Hypertext Transfer Protocol；RFC1945およびRFC2068）、FTP（File Transfer Protocol；RFC959）等のプロトコルを用いて、サーバのあらかじめユーザに割り当てられた記憶領域にそれらの画像をアップロードする。

ところで、通常のフォトシェアリングサイトでは、１ユーザに与えられる記憶領域の容量に対して上限が設定されている場合が多い。このような場合、ユーザは手動でサーバの記憶領域の残容量を問い合わせて確認していた。一方、ユーザはユーザ機器上でアップロードしたい画像を全て選択し、アップロード処理を指示した後に、サーバが選択画像の容量の合計を計算し、その合計値がサーバの記憶領域の残容量を超えていた場合、サーバはユーザ端末にその旨を通知し、全ての画像のアップロード処理を無効にしていた。

あるいは、ユーザがアップロードしたい画像を全て選択した後に、ユーザ端末が選択画像の容量の合計を計算していた。そして、ユーザ端末は、予め決められた所定の枚数や容量をディスプレイ上に表示するとともに、選択画像の容量の合計値を表示することで、選択画像のアップロードが可能であるかをユーザに示唆していた。（非特許文献１参照。）

しかしながら、これら従来の方法では、ユーザが画像を選択しながら、選択画像をアップロードした場合のサーバの記憶領域の残容量を動的に知ることができず、操作性が悪いという問題があった。

キヤノン株式会社「ZoomBrowser EX ソフトウェアユーザガイド Version 4.5」104〜106ページ、２００３年１０月２３日発行

本発明は以上の技術的背景に鑑みてなされたものであり、ユーザが転送する画像を選択しながら、仮に選択画像を転送した場合の転送先の記憶領域の残り容量を動的に知ることができるようにすることを目的とする。

上記した目的を達成するために、例えば本発明の一側面に係る情報処理装置は以下の構成を備える。すなわち、所定容量のデータ記憶領域を提供するサーバにネットワークを介して接続され、前記データ記憶領域にファイル転送が可能に構成された情報処理装置であって、ユーザからの指示を入力する入力デバイスと、画像を表示する表示デバイスと、前記サーバから前記データ記憶領域の空き容量の情報を取得する取得手段と、前記取得手段による取得処理の実行後に、前記データ記憶領域に転送するファイルをユーザに選択させるためのグラフィカルユーザインタフェース（ＧＵＩ）を前記表示デバイスに表示させる表示制御手段と、表示した前記ＧＵＩに対する前記入力デバイスによるドラッグアンドドロップ指示に基づいて前記データ記憶領域に転送するファイルを選択する選択手段と、前記ＧＵＩに対する前記入力デバイスによるドラッグアンドドロップ指示に応答して、前記選択手段によって現在選択されているファイルの合計ファイル容量と前記取得手段によって取得された前記データ記憶領域の空き容量との差分値を計算する計算手段とを有し、前記ＧＵＩは、前記入力デバイスによるドラッグアンドドロップ指示に応答して、前記計算手段により計算された前記差分値をダイナミックに表示する表示領域を含むことを特徴とする。

本発明によれば、ユーザが転送する画像を選択しながら、仮に選択画像を転送した場合の転送先の記憶領域の残り容量を動的に知ることができ、ユーザの使い勝手を向上させることができるという効果が得られる。

また、ユーザが転送する画像を選択している時点で、選択した画像を転送すると残り容量を超えてしまうかどうかを容易に判断できるようになる。

以下、図面を参照して本発明の好適な実施形態について詳細に説明する。

本実施形態では、ユーザＰＣ（クライアント）から、フォトシェアリングサービスを提供するサーバに対して、ユーザの操作により画像ファイルを転送（いわゆるアップロード）するネットワークシステムを説明する。サーバはユーザごとに「アルバム」とよばれる記憶領域を提供している。アルバムとして使用可能な記憶領域の容量はユーザごとにあらかじめ決められている。ユーザがクライアントから画像ファイルをアップロードすると、サーバはアップロードされた画像ファイルをアルバムに格納する。

しかしながら、本発明はサーバがフォトシェアリングサービスを提供するものに限定されるものではなく、サーバがユーザに所定量の記憶容量を提供するのであれば、本発明を適用可能である。また、サーバ装置が接続されるコンピュータネットワークもインターネットに限定されないが、ＴＣＰ／ＩＰ等いわゆるインターネットプロトコル群を用いるコンピュータネットワークであることが好ましい。

＜単位系について＞
本明細書では、ファイルのサイズを表わす単位としてバイト（byte）を使用する。また、2¹⁰（1,024）バイトを表わす単位の略記法としてKB（kilobyte）を使用する。また、2²⁰（1,048,576）バイトを表わす単位の略記法としてMB（megabyte）を使用する。

国際単位系（SI；International System of Units）では接頭辞としての小文字のk（kilo）は10³を表わし、同じく接頭辞としての大文字のM（mega）は10⁶を表わすことになっている。また、国際電気標準会議（IEC；International Electrotechnical Commission）の決定においては、国際単位系の接頭辞と混同されることのないように、2¹⁰を表わす接頭辞としてKi（kibi）を使用し、2²⁰を表わす接頭辞としてMi（mebi）を使用することになっている。

以上の規格に従えば、2¹⁰バイトはKiB（kibibyte）、2²⁰バイトはMiB（mebibyte）と表記すべきところであるが、本明細書ではコンピュータ業界の慣用に従って、2¹⁰バイトをKB、2²⁰バイトをMBと表記することにする。

＜全体構成＞
図１は、本実施形態におけるネットワークシステムの全体構成を示す図である。

１０１はユーザが用いるパーソナルコンピュータ等のコンピュータ機器（以下、ユーザＰＣという。）で、画像ファイルのアップロード操作を行なうクライアントコンピュータとして機能する。クライアント１０１はネットワークインタフェースを経由してインターネット１０３に接続されている。１０２は記憶領域を提供し、画像ファイルのアップロードを受け付けるサーバであり、やはりネットワークインタフェースを経由してインターネット１０３に接続されている。これによりクライアント１０１とサーバ１０２はそれぞれインターネット１０３を通じ、例えばＨＴＴＰプロトコルを使用して相互に通信が可能である。なお、このようなクライアント１０１は複数存在しうるが、ここでは説明を簡単にするためクライアント１０１を代表的に１台だけ表示した。

＜クライアント１０１及びサーバ１０２の構成＞
図２は、クライアント１０１及びサーバ１０２として使用されるコンピュータ装置の構成を示す図である。２０１は本コンピュータ装置全体の制御を行なうＣＰＵ、２０２は主記憶装置として機能するＲＡＭ、２０３はＣＰＵ２０１の制御の下にインターネット等のネットワークとの接続を行なってデータ等を送受信するネットワークインタフェース（Net I/F）である。２０４はデータを保存する磁気ディスク等の外部記憶装置、２０５は画像を表示する表示デバイスとしてのディスプレイ、２０６および２０７はそれぞれ、ユーザからの指示を入力する入力デバイスとしてのキーボードおよびポインティングデバイス（マウス等）である。ＲＡＭ２０２に格納されているプログラムは、同じくＲＡＭ２０２に格納されているＯＳ（Operating System）の機能を必要に応じて使用し、ＲＡＭ２０２に一時記憶するデータの内容を読み書きしたり、外部記憶装置２０４上でデータを読み書きしたり、ネットワークインタフェース２０３を通じてデータの送受信を行なったり、キーボード２０６やポインティングデバイス２０７からの入力を受け取ったり、ディスプレイ２０５に表示を行なったりすることで、所定の動作を行なう。

＜全体のブロック図＞
次に、図３を参照して、本実施形態におけるネットワークシステム内のソフトウェア構成について説明する。

図３は、物理的に図１のような構成を取るクライアント１０１、サーバ１０２、インターネット１０３において、本実施形態の動作に主として関わる論理ブロック、すなわちプログラムモジュール、ファイルエンティティ、データベースエンティティ、および通信経路の構成を示している。

３０１はクライアント１０１のブロック境界を表わし、ここではＯＳの制御下にある環境を指す。アップロードプログラム３０２とアルバム表示プログラム３０４は、通常は外部記憶装置２０４に保存されているが、ユーザ、ＯＳ、あるいは別のプログラムから実行が指示されると、ＯＳの制御によりＲＡＭ２０２に読み込まれ、実行可能な状態となる。３０３は外部記憶装置２０４に保存されている画像ファイルである。画像ファイル３０３は任意のプログラムから読み書き可能であるが、ここでは画像ファイル３０３とアップロードプログラム３０２との間の矢印およびその方向が示すように、アップロードプログラム３０２は画像ファイル３０３の内容を読み込むだけの関係である。アップロードプログラム３０２とアルバム表示プログラム３０４の動作は図６等を用いて後述する。

３０５はサーバ１０２のブロック境界を表わし、ここではＯＳの制御下にある環境を示す。アルバムクエリＣＧＩ３０６、アップロードＣＧＩ３０８、およびアルバム表示ＣＧＩ３０９はそれぞれＣＧＩ（Common Gateway Interface）プログラムである。これらのＣＧＩプログラムは、通常は外部記憶装置２０４に保存されているが、クライアント３０１からＨＴＴＰリクエストの形式で実行要求があると、ＯＳおよびＷｅｂサーバプログラム（図示せず）の制御によりＲＡＭ２０２に読み込まれ、実行可能な状態となる。ＣＧＩプログラムは実行に必要な引数をＨＴＴＰリクエストのリクエストパラメータを通じて受信し、実行結果はＨＴＴＰレスポンスを通じて送信するように動作する。３０７は外部記憶装置２０４上にデータベースプログラム（図示せず）が構成したデータベースである。ＣＧＩプログラム３０６、３０８、３０９はデータベースプログラムやデータベースドライバ（図示せず）の機能を必要に応じて利用することで、データベース３０７の内容を読み書き可能である。ここではサーバブロック３０５内の矢印およびその方向が示すように、アルバムクエリＣＧＩ３０６とアルバム表示ＣＧＩ３０９がデータベース３０７の内容を読み込み、アップロードＣＧＩ３０８がデータベース３０７の内容に書き込む。アルバムクエリＣＧＩ３０６、アップロードＣＧＩ３０８、アルバム表示ＣＧＩ３０９の動作は図９、図１８、図２０等を用いて後述する。

３１０、３１１、３１２はクライアント実行環境３０１とサーバ実行環境３０５との間で使用されるＨＴＴＰ通信経路を示す。各通信経路はクライアント３０１のプログラムからサーバ３０５のＣＧＩプログラムの実行を要求するＨＴＴＰリクエストの形式でインターネット１０３上にコネクションが確立され、サーバ３０５のＣＧＩプログラムがクライアント３０１のプログラムにＨＴＴＰレスポンスを返した時点でコネクションを維持する指示がない限り自動的に破棄される。

＜データベース構成とレコード＞
次に、図４、図５を参照して、本実施形態で使用するデータベースの構成およびレコードについて説明する。

図４は、ユーザ情報を格納するためにデータベース３０７内に構成されたデータベースの構成およびレコードの一例を示す図である。

４０１はユーザ情報のデータベース構成であり、データ列４０２〜４０６がユーザ情報４０１に含まれる。４０２はユーザを識別するために発行するユーザＩＤであり、ＰＫ（Primary Key）を指定しておくことで、ユーザ情報データベース４０１に含まれる全ての行（レコード）でユーザＩＤ４０２が重複しないことがデータベースプログラムにより保証される。したがって、ユーザ情報４０１内のすべてのレコードはユーザＩＤ４０２をキーとすることで一意に識別可能である。４０３は認証用のパスワード、４０４はユーザの氏名、４０５はユーザのメールアドレスである。４０６は使用可能な記憶領域としてユーザに割り当てられている容量、すなわちアルバムの最大容量である。単位は前述のようにバイトを使用する。

４０７は本実施形態で使用するユーザ情報のレコードである。図示のように、４０８〜４１２にはデータベース構成の４０２〜４０６に対応するデータとして、それぞれ「ID1234」、「PAS5678」、「木谷野太郎」、「xx@yy.jp」、「52,428,800」が格納されている。ここで、アルバム最大容量は52,428,800バイト、すなわち50MBである。

図５は、アルバム情報を格納するためにデータベース３０７内に構成されたデータベースの構成およびレコードの一例を示す図である。

５０１はアルバム情報のデータベース構成であり、データ列５０２〜５０６がアルバム情報５０１に含まれる。５０２はユーザＩＤであり、ＦＫ（Foreign Key）として４０２（図４を参照）が指定しておくことで、アルバム情報データベース５０１にレコードを追加する場合、そのユーザＩＤ５０２は、ユーザ情報データベース４０１にも同じユーザＩＤを持つレコードが存在していることがデータベースプログラムにより保証される。５０３は画像ファイルのファイル名、５０４は画像ファイルのサイズ（単位はバイト）、５０５は画像ファイルのサムネイルデータ、５０６は画像ファイルのデータである。サムネイルデータ５０５と画像ファイルデータ５０６はバイナリデータをそのままデータベースに格納するが、そのままでは図示できないため、本実施形態で図示する場合には画像ファイルの内容を表示して代用することにする。

５０７〜５０９は本実施形態で使用するアルバム情報のレコード、すなわち４０７（図４を参照）に示すユーザのアルバム情報を保持するレコードである。レコード５０７にはデータベース構成の５０２〜５０６に対応するデータとして、それぞれ「ID1234」、「車.jpg」、「200,000」、（図示のサムネイルに相当するバイナリデータ）、（図示の画像に相当するバイナリデータ）が格納されている。ここで、画像ファイルサイズは200,000バイト、すなわち約195KBである。５０８および５０９も５０７と同様である。

＜全体動作＞
次に、図６を参照して、本実施形態の全体動作について説明する。

図６は、本実施形態におけるネットワークシステムの全体動作を示すためのＵＭＬ（Unified Modeling Language）シーケンス図である。ここでは主に正常系の動作のみが示されており、異常系（エラー発生時や処理失敗時）の動作については示されない場合がある。

６０１はクライアント１０１を操作するユーザである。

６０２はアップロードプログラム３０２のインスタンス、すなわちアップロードプログラム３０２がクライアント１０１のＲＡＭ２０２に読み込まれて実行可能な状態となっている実体を表わす。６０３はアルバム表示プログラム３０４のインスタンスである。

６０４はクライアント３０１とサーバ３０５とのネットワーク境界を表わす。ただし、これはＵＭＬの表記ではなく、シーケンス図の左側（クライアント側）と右側（サーバ側）とが別の環境で実行されていることを示すための便宜的な表記である。

６０５はアルバムクエリＣＧＩ３０６のインスタンス、すなわちアルバムクエリＣＧＩ３０６がサーバ１０２のＲＡＭ２０２に読み込まれて実行可能な状態となっている実体を表わす。６０６はアップロードＣＧＩ３０８のインスタンス、６０７はアルバム表示ＣＧＩ３０９のインスタンスである。

まず、ユーザ６０１がクライアント１０１のキーボード２０６やポインティングデバイス２０７を使用して、アップロードプログラム３０２の実行をＯＳに指示する（シーケンス６０８）。ＯＳはアップロードプログラム３０２を外部記憶装置２０４からＲＡＭ２０２に読み込んで、アップロードプログラム３０２のインスタンス６０２を作成する。

アップロードプログラム６０２は実行が開始されると、まず認証情報入力画面をディスプレイ２０５に表示する（シーケンス６０９）。ユーザ６０１は表示された認証情報入力画面に対してクライアント１０１のキーボード２０６やポインティングデバイス２０７を使用して認証情報を入力する（シーケンス６１０）。認証情報入力画面の表示および入力の詳細については図７、図８を用いて後述する。

アップロードプログラム６０２はユーザ６０１の認証情報の入力が終わると、ネットワーク１０３を経由してサーバ１０２に対しＨＴＴＰリクエストの形式でアルバムクエリＣＧＩ３０６の実行を依頼する（シーケンス６１１）。この際、ユーザ６０１が入力した認証情報を実行時引数として渡す。サーバ１０２のＯＳおよびＷｅｂサーバプログラムはアップロードプログラム６０２とのＨＴＴＰコネクション３１０を確立し、アルバムクエリＣＧＩ３０６を外部記憶装置２０４からＲＡＭ２０２に読み込んで、アルバムクエリＣＧＩのインスタンス６０５を作成する。アルバムクエリＣＧＩ６０５は引数で指定された認証情報をチェックした後、引数で指定されたユーザのユーザ情報およびアルバム情報をＨＴＴＰレスポンスの形式でアップロードプログラム６０２に返す。アルバムクエリＣＧＩ６０５の動作の詳細については図９を用いて後述する。後述するように、このアルバムクエリＣＧＩ３０６の実行要求に応答してアルバム利用可能サイズが返される。そのため、この時点でユーザに設定されたアルバムの空き容量を取得できる。

アップロードプログラム６０２はアルバムクエリＣＧＩ６０５の呼び出しが終わると、ＨＴＴＰレスポンスで返された情報を利用してＧＵＩ（Graphical User Interface）であるアップロード画面をディスプレイ２０５に表示する（シーケンス６１２）。ユーザ６０１は、表示されたアップロード画面に対して、クライアント１０１のキーボード２０６やポインティングデバイス２０７を使用して、アップロードする画像ファイルを追加したり、追加した画像ファイルをアップロードするかどうかを選択したりする（シーケンス６１３）。アップロードプログラム６０２はユーザ６０１が画像を追加したり選択したりするたびにアップロード画面の表示を更新する（シーケンス６１４）。シーケンス６１３とシーケンス６１４はユーザ６０１が繰り返し実行可能である。アップロード画面の表示の詳細については図１０〜図１７を用いて後述するが、アップロード画面には、現在選択されている画像ファイルの合計ファイル容量と、シーケンス６１１によって取得されたアルバム利用可能サイズとがダイナミック（動的）に表示される。

ユーザ６０１はアップロードする画像ファイルの準備が終了すると、すなわちシーケンス６１３とシーケンス６１４をこれ以上繰り返す必要がないと判断すると、クライアント１０１のキーボード２０６やポインティングデバイス２０７を使用し、アップロードプログラム６０２に画像ファイルのアップロードを指示する（シーケンス６１５）。アップロードプログラム６０２は、ネットワーク１０３を経由してサーバ１０２に対しＨＴＴＰリクエストの形式でアップロードＣＧＩ３０８の実行を依頼する（シーケンス６１６）。この際、ユーザ６０１のユーザ情報に加えて、ユーザ６０１の選択した画像ファイルについての情報も実行時引数として渡す。サーバ１０２のＯＳおよびＷｅｂサーバプログラムはアップロードプログラム６０２とのＨＴＴＰコネクション３１１を確立し、アップロードＣＧＩを外部記憶装置２０４からＲＡＭ２０２に読み込んで、アップロードＣＧＩのインスタンス６０６を作成する。アップロードＣＧＩ６０６は引数で指定された画像ファイルを引数で指定されたユーザのアルバムに登録し、処理結果をＨＴＴＰレスポンスの形式でアップロードプログラム６０２に返す。この動作（シーケンス６１６）はアップロードする画像ファイルの数だけ繰り返す。アップロードＣＧＩ６０６の動作の詳細については図１８、図１９を用いて後述する。

アップロードプログラム６０２はアップロードＣＧＩ３０８の呼び出しがすべて終わると、アルバム表示プログラム３０４の実行をＯＳに指示し、自身の実行を終了する（シーケンス６１７）。この際、シーケンス６１０で入力された認証情報を実行時引数として渡す。ＯＳはアルバム表示プログラム３０４を外部記憶装置２０４からＲＡＭ２０２に読み込んで、アルバム表示プログラムのインスタンス６０３を作成する。アルバム表示プログラム６０３は実行が開始されると、ネットワーク１０３を経由してサーバ１０２に対しＨＴＴＰリクエストの形式でアルバム表示ＣＧＩ３０９の実行を依頼する（シーケンス６１８）。この際、アップロードプログラム６０２から起動時に渡された認証情報をアルバム表示ＣＧＩ３０９への実行時引数として渡す。サーバ１０２のＯＳおよびＷｅｂサーバプログラムはアルバム表示プログラム６０３とのＨＴＴＰコネクション３１２を確立し、アルバム表示ＣＧＩ３０９を外部記憶装置２０４からＲＡＭ２０２に読み込んで、アルバム表示ＣＧＩのインスタンス６０７を作成する。アルバム表示ＣＧＩ６０７は引数で指定されたユーザのアルバムに含まれる画像ファイルの情報をＨＴＴＰレスポンスの形式でアルバム表示プログラム６０３に返す。アルバム表示ＣＧＩ６０７の動作の詳細については図２０を用いて後述する。

アルバム表示プログラム６０３はアルバム表示ＣＧＩ６０７の呼び出しが終わると、ＨＴＴＰレスポンスで返された情報を利用してアルバム画面をディスプレイ２０５に表示する（シーケンス６１９）。アルバム画面の表示については図２１を用いて後述する。

以上が本実施形態の全体動作である。以下、個々の動作を詳細に説明する。

＜認証情報入力画面＞
図７、図８を参照して、認証情報入力画面の表示および入力について説明する。

図７は、アップロードプログラム６０２がシーケンス６０９で表示する認証情報入力画面の一例である。ユーザ６０１はクライアント１０１のキーボード２０６やポインティングデバイス２０７を使用して入力や操作が可能である。７０１はユーザＩＤの入力フィールド、７０２はパスワードの入力フィールドである。ユーザ６０１がＯＫボタン７０３を操作すると、アップロードプログラム６０２は入力終了と判断する。ユーザ６０１がキャンセルボタン７０４を操作すると、アップロードプログラム６０２はプログラムの実行がキャンセルされたと判断し、プログラムを終了する（キャンセルボタン７０４操作時の動作は図６には図示されていない）。

図８は、ユーザ６０１がシーケンス６１０で認証情報入力画面に入力した状態を示す画面の一例である。ここでは、ユーザ情報データベース４０１のレコード４０７に対応する認証情報を入力するものとする。ユーザＩＤ入力フィールド８０１にはユーザＩＤ４０８に対応して「ID1234」が入力されている。パスワード入力フィールド８０２はセキュリティ上の観点から入力文字がエコーバックされず、すべての文字が「＊」で表示されているが、ここではユーザＩＤと同じくパスワード４０９に対応して「PAS5678」が入力されているものとする。

＜アルバムクエリＣＧＩの動作＞
次に、図９を参照して、アルバムクエリＣＧＩの動作について説明する。

図９は、アルバムクエリＣＧＩ６０５の動作（シーケンス６１１）を示すフローチャートである。

ステップＳ９０１はプログラムの開始である。図７に示す認証情報入力画面でユーザ６０１が入力したユーザＩＤとパスワードが、ＨＴＴＰリクエストのパラメータとしてアップロードプログラム６０２から渡されるので、それぞれ変数userIdとpasswordに代入する。ここでは、図８に示したようにユーザＩＤとして「ID1234」、パスワードとして「PAS5678」が渡されたものとする。

ステップＳ９０２で、userIdがユーザＩＤ４０２と一致するレコードをユーザ情報データベース４０１から検索する。図４に示したようにユーザＩＤ４０２はＰＫであることから、userIdとユーザＩＤ４０２が一致するレコードは多くとも１件しか存在しない。

ステップＳ９０３ではステップＳ９０２でレコードが見つかったかどうかを判定する。レコードが見つからなければユーザＩＤが不正であるとしてステップＳ９０８に進んでプログラムを終了し、アップロードプログラム６０２に失敗を返す。レコードが見つかればステップＳ９０４に進む。ここではuserIdが「ID1234」であることから、図４の４０７に示したレコードが見つかるので、ステップＳ９０４に進む。

ステップＳ９０４では、ステップＳ９０２で見つかったレコードのパスワード４０３と、引数で渡されたpasswordとが一致するかどうかを判定する。パスワードが一致しなければパスワードが不正であるとしてＳ９０８に進んでプログラムを終了し、アップロードプログラム６０２に失敗を返す。パスワードが一致すればステップＳ９０５に進む。ここでは見つかったレコード４０７のパスワードが４０９に示すように「PAS5678」であり、passwordも同じく「PAS5678」であることから、ステップＳ９０５に進む。

ステップＳ９０５では、userIdがユーザＩＤ５０２と一致するレコードをアルバム情報データベース５０１からすべて検索し、見つかったレコードの画像ファイルサイズ５０４を累計する。ここではuserId＝「ID1234」であることから、図５の５０７〜５０９に示したレコードが３件見つかるので、画像ファイルサイズを累計した結果、200,000＋300,000＋400,000＝合計900,000バイトという結果を得る。

ステップＳ９０６では、ユーザ情報データベース４０１のアルバム最大容量４０６から、ステップＳ９０５で求めた画像ファイルの合計サイズを引いて、アルバムの利用可能サイズを計算する。ここでは、アルバム最大容量が図４の４１２に示すように52,428,800バイトであり、画像ファイルの合計サイズが上記のように900,000バイトであることから、52,428,800−900,000＝51,528,800バイトという結果を得る。

そして、ステップＳ９０７では、プログラムを終了し、アップロードプログラム６０２に成功を返す。この際、ＨＴＴＰレスポンスの一部として戻り値を返す。ここでは、見つかったレコード４０７の氏名４１０である「木谷野太郎」と、ステップＳ９０６で求めたアルバム利用可能サイズ「51,528,800」を返す。

＜アップロード画面（初期画面）＞
次に、図１０、図１１を参照して、アップロード画面の初期画面について説明する。

図１０はアルバムクエリＣＧＩ６０５の呼び出し（シーケンス６１１）が失敗を返した時にアップロードプログラム６０２がディスプレイ２０５に表示する認証エラー画面である。図９に示したように、アップロードプログラム６０２が失敗を返すのは、引数のユーザＩＤまたはパスワードが不正な場合なので、図１０では「ユーザＩＤが見つからないか、またはパスワードが一致しません」というメッセージを表示している。「ユーザＩＤが見つからない」のか「パスワードが一致しない」のか、いずれの理由で失敗したのかを明示していないのはセキュリティ上の理由による。１００１はＯＫボタンであり、ユーザ６０１がキーボード２０６またはポインティングデバイス２０７を使用して操作すると、アップロードプログラム６０２は認証エラー画面を消去し、シーケンス６０９の認証情報入力画面表示に戻る（認証エラー画面表示に関わる動作は図６に図示していない）。

図１１は、アップロードプログラム６０２がシーケンス６１２でディスプレイ２０５に表示するアップロード画面である。

１１０１は固定のメッセージ部分であるが、一行目の一部に、シーケンス６１１の戻り値として返された氏名「木谷野太郎」を使用している。

１１０２はキャンバスであり、この矩形領域に画像ファイルを追加する。追加する方法はクライアント１０１の外部記憶装置２０４に存在する画像ファイル３０３をユーザ６０１がポインティングデバイス２０７を使用してドラッグし、キャンバス１１０２にドロップすることで行なう。

１１０３はアップロード対象の画像ファイルの合計サイズとファイル数を表示する領域である。ここではまだ画像ファイルが追加されていないので、０ＫＢ（０ファイル）と表示されている。

１１０４はシーケンス６１１の戻り値として返されたアルバム利用可能サイズを表示する領域である。ここでは「51,528,800バイト」＝「49.124メガバイト」≒「49.1メガバイト」であることから、「49.1MB」と表示している。このように、この時点ですでにアルバム利用可能サイズが表示されている。

１１０５はアップロードボタンである。ユーザがキーボード２０６またはポインティングデバイス２０７を使用してアップロードボタン１１０５を操作すると、キャンバス１１０２に追加した画像ファイルのアップロードをアップロードプログラム６０２に指示することになる。

＜アップロードプログラム内部データ構造および動作＞
続いて、図１２、１３を参照して、アップロードプログラムの内部データ構造と動作について説明する。

図１２は、アップロード画面のキャンバス１１０２に画像ファイルが追加された時（シーケンス６１３）に、追加された画像ファイルを管理するために、アップロードプログラム６０２がＲＡＭ２０２に割り当てて使用するデータ構造を表わす図である。

１２０１は一つの画像ファイルに対応するデータ構造を表わす。このデータ構造をセルと呼ぶ。１２０２は画像ファイルのファイル名であり、キャンバス１１０２に画像ファイルがドロップされた際にＯＳから通知される。１２０３は画像ファイルのサイズであり、キャンバス１１０２に画像ファイルがドロップされた際に、アップロードプログラム６０２がＯＳに問い合わせることで取得する。単位はバイトである。１２０４はサムネイルデータであり、同じくキャンバス１１０２に画像ファイルがドロップされた際に、アップロードプログラム６０２が画像ファイルの内容を読み込んで縮小画像を生成する。サムネイルデータ１２０４はバイナリデータとしてＲＡＭ２０２に格納するが、そのままでは図示できないため、図示する場合はサムネイルデータの内容を表示して代用することにする。１２０５はチェックフラグであり、追加した画像ファイルを実際にアップロードするかどうかを管理するために使用する。チェックフラグ１２０５は「ｏｎ」（アップロードする）または「ｏｆｆ」（アップロードしない）のいずれかの状態を取る。画像ファイルがドロップされた時点では「ｏｎ」であるが、その後のユーザの操作により「ｏｆｆ」に変更可能である。

１２０６はセル１２０１を複数連結したリスト構造を表わす。図示のように画像ファイル１〜画像ファイルｎに対応して、セル１２０７−１〜セル１２０７−ｎを割り当て、これらのセルを順序付けたリストに格納することで、複数のセルおよびそれらの順序関係を管理している。

図１３は、アップロードプログラム６０２がディスプレイ２０５にアップロード画面を表示（シーケンス６１４）する動作を示すフローチャートである。ここで、ユーザがアップロード画面に画像ファイルを追加した結果、セルのリストが図１４に示す状態になったとする。この時のアップロード画面の表示は図１５のようになる。この表示動作を図１３のフローチャートを参照して説明する。

動作はステップＳ１３０１より開始する。ステップＳ１３０２は初期化処理である。checkedFileNumはアップロード対象の画像ファイル数、すなわち、セルリスト１２０６において、チェックフラグ１２０５が「ｏｎ」の状態を持つセルの数を表わす。checkedFileBytesはアップロード対象の画像ファイルのサイズ合計、すなわち、セルリスト１２０６において、チェックフラグ１２０５が「ｏｎ」の状態を持つセルの画像ファイルのサイズ１２０３の合計値を表わす。ステップＳ１３０２ではともに０に初期化する。

ステップＳ１３０３はメッセージ部分１５０１を表示する。メッセージの一部に、シーケンス６１１の戻り値として返された氏名「木谷野太郎」を使用する。

ステップＳ１３０４はセルのリストをすべて表示したかどうかの判定処理である。ここではまだ何も表示していないので、ステップＳ１３０５に進む。

ステップＳ１３０５は次に表示するセルを決定する処理である。ここではリストの先頭セル１４０１を選択する。

ステップＳ１３０６はセルのファイル名、サムネイル、チェック状態を表示する処理である。ステップＳ１３０４で選択したセルのファイル名１２０２、サムネイル１２０４、チェックフラグ１２０５の状態をキャンバス１５０２に表示する。ここではセル１４０１が選択されているので、ファイル名「鳥.jpg」を１５０６に表示し、サムネイル（１４０１参照）を１５０７に表示する。チェックフラグについては１５０８において、“レ”（チェックマーク）が入れられた状態が「ｏｎ」を示し、チェックマークが外された状態が「ｏｆｆ」を示す。ここではセル１４０１のチェックフラグが「ｏｎ」なので、１５０８はチェックマークが入った状態の表示を得る。

ステップＳ１３０７はセルのチェックフラグ１２０５が「ｏｎ」か「ｏｆｆ」かの判定処理である。ここでは１４０１に示すように「ｏｎ」なので、ステップＳ１３０８に進む。

ステップＳ１３０８は変数の更新処理である。まず、アップロード対象の画像ファイル数（checkedFileNum）に１を加算する。次に、アップロード対象の画像ファイルのサイズ合計（checkedFileBytes）に画像ファイルのサイズ（ここでは１４０１に示すように100,000）を加算する。この結果、checkedFileNumは１、checkedFileBytesは100,000になる。この後、ステップＳ１３０４に戻る。

続いてセル１４０２に対してステップＳ１３０４〜Ｓ１３０８を適用した結果、１５０９〜１５１１の表示を得て、checkedFileNumは２、checkedFileBytesは300,000になる。この後、ステップＳ１３０４に戻る。

続いてセル１４０３に対してステップＳ１３０４〜Ｓ１３０８を適用した結果、１５１２〜１５１４の表示を得て、checkedFileNumは３、checkedFileBytesは600,000になる。この後、ステップＳ１３０４に戻る。

ここで図１４に示すセルのリストをすべて表示したので、ステップＳ１３０４の判定でステップＳ１３０９に進む。

ステップＳ１３０９は容量部分の表示処理である。まず、１５０３に示すように、アップロード対象のファイルの合計サイズと合計数をcheckedFileBytesとcheckedFileNumを利用して表示する。ここではcheckedFileBytesは「600,000バイト」＝「585.9375キロバイト」≒「586キロバイト」なので、586KBと表示している。また、checkedFileNumは３なので、３ファイルと表示している。次に、１５０４に示すように、アルバム利用可能サイズを表示する。ここではシーケンス６１１の戻り値として返されたアルバム利用可能サイズをそのまま使用し、１１０４と同じように49.1MBと表示している。このように、アップロード対象の画像ファイルを選択している際に、現時点で選択されている画像ファイルの合計ファイル容量と、シーケンス６１１によって取得されたアルバム利用可能サイズとの両方が表示されるので、ユーザは選択した画像を転送するとその転送先の記憶領域の残り容量を超えてしまうかどうかを容易に判断することができる。

そして、ステップＳ１３１０で処理を終了する。

＜画像ファイル選択時の動作＞
図１６〜１７を参照して、画像ファイル選択時の動作について説明する。

図１１に示す画面に画像ファイルを追加して図１５に示す画面が得られると、ユーザ６０１は追加した画像ファイルのチェックフラグを「ｏｆｆ」にしたり「ｏｎ」にしたりすることができる（シーケンス６１３）。操作方法は、クライアント１０１のキーボード２０６やポインティングデバイス２０７を使用して、追加した画像ファイルのチェックフラグ表示を操作することで行なう。たとえば図１５の１５０８に示すチェックフラグ表示をポインティングデバイス２０７を使用してクリックすると、アルバム表示プログラム６０３にＯＳから通知が行なわれるので、アルバム表示プログラム６０３は該当セルのチェックフラグを「ｏｆｆ」に変更する。この結果、セルのリストは図１６に示すように、先頭セル１６０１のチェックフラグが「ｏｆｆ」の状態になる。

セルのリストの状態が変更されるとアップロードプログラム６０２はアップロード画面の再表示を行なう（シーケンス６１４）。図１６に示すセルのリストを図１３のフローチャートに従って再表示すると、図１７に示す表示を得る。図１５と図１７の違いはセル１４０１とセル１６０１のチェックフラグの違いに起因する。相違点の一つ目はチェックフラグ表示１５０８と１７０８であり、二つ目は選択画像サイズ・ファイル数表示１５０３と１７０３である。図１６に示すセルのリストではチェックフラグが「ｏｎ」のセルが２つ（１６０２、１６０３）なので、１７０３に示すアップロード対象のファイルの合計数は２になり、ファイルの合計サイズは「500,000バイト」＝「488.281キロバイト」≒「488キロバイト」なので488KBとなる。

なお、ステップＳ１３０９では、図１５に示す画面において、アップロード対象画像をアップロードした場合のアルバム利用可能サイズも表示するようにしてもよい。具体的には、checkFileBytesの値とシーケンス６１１の戻り値との差分を計算し、仮想アルバム利用可能サイズとして表示する。これにより、ユーザは現在の選択画像をアップロードした後のアルバム利用可能サイズが容易に分かるので、さらに他の画像をアップロード対象画像として追加で選択したり、アップロード対象画像として選択した画像の中から削除する画像を選択したりしやすくなる。

＜アップロードＣＧＩの動作＞
図１８、図１９を参照して、アップロードＣＧＩの動作について説明する。

図１８はアップロードＣＧＩ６０６の動作（シーケンス６１６）を示すフローチャートである。また、図１９はアップロードＣＧＩによるアップロード後のアルバム情報データベースの内容例を示す図である。

ここでは、図１６に示す内部状態を持つアップロードプログラム６０３が図１７に示すアップロード画面を表示しているときに、ユーザ６０１がアップロードボタン１７０５を操作したと仮定する。アップロードプログラムはチェックフラグ１２０５が「ｏｎ」であるセルそれぞれについてアップロードＣＧＩ６０６を呼び出す。ここではセル１６０２と１６０３についてアップロードＣＧＩ６０６が呼び出される。以下、セル１６０２に対する呼び出しを例にとって説明する。

ステップＳ１８０１でアップロードＣＧＩによる処理を開始する。シーケンス６１０でユーザ６０１が入力したユーザＩＤとパスワードが、ＨＴＴＰリクエストのパラメータとしてアップロードプログラム６０２から渡されるので、それぞれ変数userIdとpasswordに代入する。ここでは、図８に示したようにユーザＩＤとして「ID1234」、パスワードとして「PAS5678」が渡されたものとする。また、セルのファイル名と画像ファイルデータもＨＴＴＰリクエストのパラメータとしてアップロードプログラム６０２から渡されるので、それぞれ変数fileNameとfileDataに格納する。セルのファイル名は１２０２に保持するファイル名をそのまま使用する。画像ファイルデータは１２０１に示すセルのデータ構造内に保持していないので、アップロードプログラム６０２が外部記憶装置２０４からファイル名１２０２をキーとして画像ファイル３０３のデータを読み込み、アップロードＣＧＩ６０６に引数として渡す。ここでは、１６０２に示すファイル名（ライオン.jpg）と画像ファイルデータが渡される。

次にステップＳ１８０２で、userIdがユーザＩＤ４０２と一致するレコードをユーザ情報データベース４０１から検索する。図４に示したようにユーザＩＤ４０２はＰＫであることから、userIdとユーザＩＤ４０２が一致するレコードは多くとも１件しか存在しない。

ステップＳ１８０３〜Ｓ１８０４はステップＳ９０３〜Ｓ９０４と同様の認証処理である。同一のユーザＩＤ・パスワードの組み合わせに対してシーケンス６１１ですでにチェックが行なわれているので、ここでのチェック処理は必ず成功する。ステップＳ１８０３〜Ｓ１８０４を行なう目的は、アップロードプログラム６０２以外からアップロードＣＧＩ６０６が呼び出された場合に備えることにある。

ステップＳ１８０５では、引数で渡された画像ファイルデータfileDataから、画像ファイルサイズを計算し、サムネイルを生成する。ここでは１６０２に示すように画像ファイルサイズとして200,000が得られる。また、サムネイルは１６０２に示すのとほぼ同じサムネイルが生成される。図１６のサムネイルはクライアント１０１でアップロードプログラム６０２が生成したものであり、ここで生成するサムネイルはサーバ１０２でアップロードＣＧＩ６０６が生成したものなので、完全に同じものであるとは限らないが、同一の画像ファイルデータから生成したサムネイルなので、表示上はほぼ同じものが生成される。

ステップＳ１８０６では、アルバム情報データベース５０１に新規レコードを追加する。ユーザＩＤ５０２はuserIdを使用する。画像ファイル名５０３はfileNameを使用する。画像ファイルサイズ５０４はステップＳ１８０５で計算した画像ファイルサイズを使用する。サムネイルデータ５０５はステップＳ１８０５で生成したサムネイルデータを使用する。画像ファイルデータ５０６はfileDataを使用する。追加した結果は図１９の１９０４に示すようになる。

ステップＳ１８０７とステップＳ１８０８はそれぞれ成功と失敗を表わす終了処理である。

ここではセル１６０２に対する呼び出しを例にとって説明したが、セル１６０３に対する呼び出しも同様の処理になる。セル１６０３についてアルバム情報データベース５０１に新規レコードを追加した結果は、図１９の１９０５に示すようになる。

以上により、図５に示す状態のアルバム情報データベースに対して、セル１６０２とセル１６０３に示す画像ファイルを図１８に示すフローチャートに従って追加した結果として、図１９に示すようなアルバム情報データベースを得る。

＜アルバム表示ＣＧＩの動作＞
次に、図２０、図２１を参照して、アルバム表示ＣＧＩの動作について説明する。

図２０はアルバム表示ＣＧＩ６０７の動作（シーケンス６１８）を示すフローチャートである。

ステップＳ２００１よりアルバム表示ＣＧＩ６０７による処理が開始する。シーケンス６１０でユーザ６０１が入力したユーザＩＤとパスワードが、シーケンス６１７でアルバム表示プログラム６０３を起動する際に引数として渡されるので、アルバム表示プログラム６０３はそのままアルバム表示ＣＧＩ６０７への引数としてＨＴＴＰリクエストのパラメータで渡す。ここでは、図８に示したようにユーザＩＤとして「ID1234」、パスワードとして「PAS5678」が渡されたものとする。

ステップＳ２００２で、userIdがユーザＩＤ４０２と一致するレコードをユーザ情報データベース４０１から検索する。図４に示したようにユーザＩＤ４０２はＰＫであることから、userIdとユーザＩＤ４０２が一致するレコードは多くとも１件しか存在しない。

ステップＳ２００３〜Ｓ１２０４はステップＳ９０３〜Ｓ９０４と同じ認証処理である。同一のユーザＩＤ・パスワードの組み合わせに対してシーケンス６１１ですでにチェックが行なわれているので、ここでのチェック処理は必ず成功する。ステップＳ２００３〜Ｓ２００４を行なう目的は、アルバム表示プログラム６０３以外からアルバム表示ＣＧＩ６０７が呼び出された場合に備えることにある。

ステップＳ２００５では、userIdがユーザＩＤ５０２と一致するレコードをアルバム情報データベース５０１から検索する。ここでは図１９の１９０１〜１９０５に示す５件のレコードが検索される。

ステップＳ２００６では、ステップＳ２００５で見つかったすべてのレコードから、画像ファイル名５０３とサムネイルデータ５０５をＨＴＴＰレスポンスの形式で戻り値として返す。また、ステップＳ２００２で見つかったレコードの氏名４０４も返す。ここでは、１９０１〜１９０５に示す画像ファイル名「車.jpg」「飛行機.jpg」「船.jpg」「ライオン.jpg」「くま.jpg」と図示のサムネイル、および４１０に示す氏名「木谷野太郎」を返す。

図２１は、アルバム表示プログラム６０３がシーケンス６１９でディスプレイ２０５に表示するアルバム画面である。アルバム表示ＣＧＩから返された氏名を使用してメッセージ部分の表示２１０１を行ない、同じくアルバム表示ＣＧＩから返されたファイル名、サムネイルデータを使用して画像部分の表示２１０２を行なっている。

以上説明したように、本実施形態によれば、アップロード画面を表示する前にサーバからアルバム利用可能サイズが取得されるので、ユーザが転送する画像を選択している時点であらかじめサーバにおいてユーザに設定された記憶領域の残り容量を知ることができる。

また、アップロード対象の画像ファイルを選択している際に、現時点で選択されている画像ファイルの合計ファイル容量と、あらかじめ取得されたアルバム利用可能サイズとの両方が表示されるので、ユーザは選択した画像を転送するとその転送先の記憶領域の残り容量を超えてしまうかどうかを容易に判断することができる。

＜その他の実施形態＞
上述の実施形態では画像ファイルのみを扱ったが、これに限らず、動画や音声ファイルなども同様に扱うことが可能である。

また、図１で、１０３はインターネットであるとしたが、コンピュータ装置のネットワークインタフェースを通じてデータ等の送受信が可能な媒体であれば他のネットワークでも構わない。さらに、ＨＴＴＰプロトコル以外のプロトコルも、クライアントとサーバ双方のソフトウェアがそのプロトコルを利用可能であれば使用することができる。

また、図２でプログラムはＲＡＭ２０２に格納されるとしたが、これに限るものではなく、他の実施形態においてはプログラムを外部記憶装置２０４から読み込んで実行するようにしてもよいし、ネットワークインタフェース２０３を介して受信して実行するようにしてもよい。また、図２には示していないが、ＲＯＭ等の読み出し専用の内部記憶部から読み込んで実行するようにしてもよい。また、キーボード２０６やポインティングデバイス２０７の代わりに、あるいはそれらに加えて、音声入力等の他の入力装置を備えることもできる。また、これらすべての構成要素を必ずしも備える必要はなく、サーバ１０２においては多くの場合ディスプレイ２０５が省略されたり、キーボード２０６やポインティングデバイス２０７を他のコンピュータ装置と共有したりする。

さらに、図３において、クライアントのアップロードプログラム３０２とアルバム表示プログラム３０４は別プログラムであるとしたが、これは同一プログラムの別機能として実現してもよい。また、ここでは独立したプログラムであるとしたが、その他にも、Ｗｅｂブラウザ上で動作するＡｃｔｉｖｅＸ等のプラグインプログラムという形態も考えられる。さらには、Ｗｅｂブラウザ上で動作するＪａｖａＳｃｒｉｐｔ等のスクリプト言語でも実現可能である。

ユーザ情報データベースとアルバム情報データベースは図４と図５に示した以外にも、種々の情報を保持するように構成することができる。たとえばユーザ情報には住所や電話番号、アルバム情報にはアルバム名や作成日時等の情報である。また、サムネイルデータと画像ファイルデータはバイナリデータとしてデータベース内に保持するとしたが、その他の実施方法として、バイナリデータをファイルシステム等にファイルとして保存しておいて、データベースにはその位置を示す情報（ＵＲＬやファイルシステム内のパス名等）だけを保持するという方法も考えられる。

また、アルバムはユーザごとに一つだけ対応して存在するようにしたが、もちろんユーザに複数のアルバムを対応付けて、それらをアルバム名等で識別できるようにすることも可能である。また、複数のアルバムを格納することができるフォルダを設けることも可能である。さらに、フォルダが別のフォルダをも格納することができるようにすれば、アルバムは階層構造を有することになる。

また、図６のシーケンス６１６に示すように画像ファイルを一つずつアップロードＣＧＩでアップロードするようにしたが、ＲＦＣ１８６７、ＲＦＣ２８５４に示されるようなプロトコルを使用して複数の画像ファイルをまとめてアップロードできるようにＣＧＩのインタフェースと動作を変更することもできる。また、この逆に、ファイルサイズの大きい画像ファイルを複数回のＣＧＩ呼び出しに分割してアップロードできるようにＣＧＩのインタフェースと動作を変更することもできる。

また、すべてのＣＧＩ呼び出しで認証情報（ユーザＩＤ、パスワード）を引き回したが、これに代わる方法として、サーバ側でセッションを管理することとし、各ＣＧＩ呼び出しではそのセッションを識別する情報（セッションＩＤ）のみを引き回す手法も一般に行なわれている。

図６のシーケンスでアルバムの利用可能容量を取得したのはシーケンス６１１のみであったが、これに限るものではなく、クライアントではその他のタイミングであるいは定期的にサーバと通信して残り容量を取得し、アップロード画面の表示を更新してもよい。

また、図１１、図１５、図１７に示したアップロード画面では画像ファイルの追加に加えてチェック状態の変更機能しか存在しないが、これに限定されるものではなく、その他の編集機能、たとえば画像ファイルの削除、ファイル名の変更、画像ファイルの入れ替え・ソート等の機能を付加することもできる。

また、図１３のフローチャートでは画像ファイルのチェック状態が変更されるたびにアップロード画面をすべて再描画しているが、変更があった部分だけを再表示するようにしてもよい。

さらに、図１８のステップＳ１８０５ではサーバ側で画像ファイルサイズやサムネイルを計算あるいは生成しているが、これらの情報はクライアント側でも保持しているため、アップロードＣＧＩの引数の一部としてクライアントから送ることも可能である。

なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータがその供給されたプログラムコードを読み出して実行することによっても達成され得る。その場合、プログラムの機能を有していれば、その形態はプログラムである必要はない。

従って、本発明の機能処理をコンピュータで実現するために、そのコンピュータにインストールされるプログラムコード自体およびそのプログラムを格納した記憶媒体も本発明を構成することになる。つまり、本発明の特許請求の範囲には、本発明の機能処理を実現するためのコンピュータプログラム自体、およびそのプログラムを格納した記憶媒体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

プログラムを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ、ＤＶＤ−Ｒ）などがある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、そのホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記憶媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷｅｂサーバも、本発明のクレームに含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記憶媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現される。

本発明の実施形態におけるネットワークシステムの全体構成を示す図である。 実施形態におけるクライアント及びサーバとして使用されるコンピュータ装置の構成を示す図である。 実施形態におけるネットワークシステムのソフトウェア構成を示す図である。 ユーザ情報データベースの構成およびレコードの一例を示す図である。 アルバム情報データベースの構成およびレコードの一例を示す図である。 実施形態におけるネットワークシステムの全体動作を示すシーケンス図である。 認証情報入力画面の一例を示す図である。 図７の認証情報入力画面に認証情報が入力された状態の例を示す図である。 アルバムクエリＣＧＩの動作を示すフローチャートである。 認証エラー画面の一例を示す図である。 アップロード画面（初期表示）の一例を示す図である。 アップロードプログラムの内部データ構造を示す図である。 アップロード画面の表示動作を示すフローチャートである。 画像ファイルを追加したときのセルのリストの例を示す図である。 図１４のセルのリストに対応するアップロード画面の表示例を示す図である。 選択状態を変更したときのセルのリストの例を示す図である。 図１６のセルのリストに対応するアップロード画面の表示例を示す図である。 アップロードＣＧＩの動作を示すフローチャートである。 アップロード後のアルバム情報データベースの内容例を示す図である。 アルバム表示ＣＧＩの動作を示すフローチャートである。 アルバム表示画面の一例を示す図である。

Claims (8)

1. 所定容量のデータ記憶領域を提供するサーバにネットワークを介して接続され、前記データ記憶領域にファイル転送が可能に構成された情報処理装置であって、
   ユーザからの指示を入力する入力デバイスと、
   画像を表示する表示デバイスと、
   前記サーバから前記データ記憶領域の空き容量の情報を取得する取得手段と、
   前記取得手段による取得処理の実行後に、前記データ記憶領域に転送するファイルをユーザに選択させるためのグラフィカルユーザインタフェース（ＧＵＩ）を前記表示デバイスに表示させる表示制御手段と、
   表示した前記ＧＵＩに対する前記入力デバイスによるドラッグアンドドロップ指示に基づいて前記データ記憶領域に転送するファイルを選択する選択手段と、
   前記ＧＵＩに対する前記入力デバイスによるドラッグアンドドロップ指示に応答して、前記選択手段によって現在選択されているファイルの合計ファイル容量と前記取得手段によって取得された前記データ記憶領域の空き容量との差分値を計算する計算手段と、
   を有し、
   前記ＧＵＩは、前記入力デバイスによるドラッグアンドドロップ指示に応答して、前記計算手段により計算された前記差分値をダイナミックに表示する表示領域を含むことを特徴とする情報処理装置。
2. 前記ＧＵＩは、前記選択手段により選択されたファイルの転送指示を送出するための指示ボタンをさらに含むことを特徴とする請求項１に記載の情報処理装置。
3. 前記選択手段により選択されたファイルの縮小ファイルを生成する生成手段をさらに有し、
   前記ＧＵＩは、前記生成手段により生成された前記縮小ファイルの内容を表示する領域をさらに含むことを特徴とする請求項１に記載の情報処理装置。
4. 前記選択手段により選択された各ファイルについて、前記データ記憶領域にファイル転送を行うか否かを、前記入力デバイスにより設定する設定手段をさらに有し、
   前記計算手段は、前記入力デバイスによる前記設定手段への設定に応答して、前記設定手段によって前記データ記憶領域にファイル転送を行うように設定されているファイルの合計ファイル容量と前記取得手段によって取得された前記データ記憶領域の空き容量との差分値を計算し、
   前記ＧＵＩは、前記入力デバイスによる前記設定手段への設定に応答して、前記計算手段により計算された前記差分値をダイナミックに表示する表示領域を含む
   ことを特徴とする請求項１に記載の情報処理装置。
5. 所定容量のデータ記憶領域を提供するサーバにネットワークを介して接続され、前記データ記憶領域にファイル転送が可能に構成された情報処理装置の制御方法であって、
   前記サーバから前記データ記憶領域の空き容量の情報を取得する取得ステップと、
   前記取得ステップの実行後に、前記データ記憶領域に転送するファイルをユーザに選択させるためのグラフィカルユーザインタフェース（ＧＵＩ）を表示デバイスに表示させる表示制御ステップと、
   表示した前記ＧＵＩに対する入力デバイスによるドラッグアンドドロップ指示に基づいて前記データ記憶領域に転送するファイルを選択する選択ステップと、
   前記ＧＵＩに対する前記入力デバイスによるドラッグアンドドロップ指示に応答して、前記選択ステップによって現在選択されているファイルの合計ファイル容量と前記取得手段によって取得された前記データ記憶領域の空き容量との差分値を計算する計算ステップと、
   を有し、
   前記ＧＵＩは、前記計算ステップにより計算された前記差分値をダイナミックに表示する表示領域を含むことを特徴とする情報処理装置の制御方法。
6. 所定容量のデータ記憶領域を提供するサーバにネットワークを介して接続され、前記データ記憶領域にファイル転送が可能に構成された情報処理装置によって実行されるプログラムであって、
   前記サーバから前記データ記憶領域の空き容量の情報を取得する取得ステップのコードと、
   前記取得ステップの実行後に、前記データ記憶領域に転送するファイルをユーザに選択させるためのＧＵＩを表示デバイスに表示させる表示制御ステップのコードと、
   表示した前記ＧＵＩに対する入力デバイスによるドラッグアンドドロップ指示に基づいて前記データ記憶領域に転送するファイルを選択する選択ステップのコードと、
   前記ＧＵＩに対する前記入力デバイスによるドラッグアンドドロップ指示に応答して、前記選択ステップによって現在選択されているファイルの合計ファイル容量と前記取得手段によって取得された前記データ記憶領域の空き容量との差分値を計算する計算ステップのコードと、
   を含み、
   前記ＧＵＩは、前記計算ステップにより計算された前記差分値をダイナミックに表示する表示領域を含むことを特徴とするプログラム。
7. 請求項６に記載のプログラムを格納したコンピュータ読み取り可能な記憶媒体。
8. 所定容量の情報記憶領域を提供するサーバと、ネットワークを介してそのサーバにファイル転送が可能に構成されたクライアントとを含むネットワークシステムであって、
   前記サーバは、
   前記クライアントからの指示に応答して前記データ記憶領域の空き容量を検査しその結果を前記クライアントに返す空き容量検査手段を有し、
   前記クライアントは、
   ユーザからの指示を入力する入力デバイスと、
   画像を表示する表示デバイスと、
   前記サーバに指示を発行することで前記空き容量検査手段による空き容量の情報を取得する取得手段と、
   前記取得手段による取得処理の実行後に、前記データ記憶領域に転送するファイルをユーザに選択させるためのグラフィカルユーザインタフェース（ＧＵＩ）を表示デバイスに表示させる表示制御手段と、
   表示した前記ＧＵＩに対する入力デバイスによるドラッグアンドドロップ指示に基づいて前記データ記憶領域に転送するファイルを選択する選択手段と、
   前記選択手段によって現在選択されているファイルの合計ファイル容量と前記取得手段によって取得された前記データ記憶領域の空き容量との差分値を計算する計算手段と、
   を有し、
   前記ＧＵＩは、前記入力デバイスによるドラッグアンドドロップ指示に応答して、前記計算手段により計算された前記差分値をダイナミックに表示する表示領域を含む
   ことを特徴とするネットワークシステム。

Images