(57)【要約】【課題】クライアント装置が保有する画像ファイルをアルバムサイトへアップロードする際に発生する作業の煩雑さを軽減する。【解決手段】アルバムサイトのサーバ装置がデータ記憶領域ＤＢを有し、所定のデータとそのデータを集約的に管理する単位である管理単位の名前とを関連付けて管理している。クライアント装置は、クライアント装置内の１つ以上の画像ファイルを含むデータ群を、そのデータ群に対応するデータ群名に関連付けて管理するとともに、サーバ装置にデータ群をデータ群名とともにアップロードする。サーバ装置は、クライアント装置からアップロードされたデータ群名に該当する管理単位名がデータ記憶領域に存在するかどうか判定する。判定の結果、例えば、該当するデータ群名がない場合は、自動的にデータ群名に対応する管理単位名を新規に定義し、該管理単位名に対応付けてデータ群を記憶する。【選択図】      図１
2005267614.tif 000002
【特許請求の範囲】
【請求項１】
データ記憶領域を有し、所定のデータと該データを集約的に管理する単位である管理単位の名前としての管理単位名とを関連付けて管理することが可能なサーバ装置と、ネットワークを経由して前記サーバ装置と接続されたクライアント装置と、を備える情報処理システムであって、
前記クライアント装置は、該クライアント装置内のデータ又はデータ群を、該データに対応するデータ名又は前記データ群に対応するデータ群名に関連付けて管理する管理手段と、
前記サーバ装置に前記データ群を前記又はデータ群名とともに送付する送付手段とを備え、
前記サーバ装置は、前記クライアント装置から送られてきたデータ群名に該当する管理単位名が前記データ記憶領域に存在するか否か判別する判別手段と、
前記判別結果に応じて、前記送られてきたデータ群名に対応する管理単位名を新規に定義し該管理単位名に関連付けて、前記送られてきたデータ群を前記データ記憶領域に記憶する記憶手段とを備えたことを特徴とする情報処理システム。
【請求項２】
データ記憶領域を有し、所定のデータと該データを集約的に管理する単位である管理単位の名前としての管理単位名とを関連付けて管理することが可能なサーバ装置であって、
ネットワークを介して前記サーバ装置と接続されたクライアント装置からデータ群とともにそれに対応するデータ群名を受信する受信手段と、
前記受信されたデータ群名に該当する管理単位名が前記データ記憶領域に存在するか否か判別する判別手段と、
前記判別結果に応じて、前記受信されたデータ群名に対応する管理単位名を新規に定義し、該管理単位名に関連付けて、前記受信されたデータ群を前記データ記憶領域に記憶することを特徴とするサーバ装置。
【請求項３】
前記判別結果に応じて、前記クライアント装置から受信されたデータ群に含まれるデータを前記データ記憶領域に既に存在する管理単位名に関連付けて、それに対応するデータ名とともに前記データ記憶領域に記憶する第２の記憶手段とを更に備えたことを特徴とする請求項２に記載のサーバ装置。
【請求項４】
前記クライアント装置は所定の情報を表示する表示デバイスを有し、前記データ記憶領域に登録するところの前記クライアント装置内のデータ又はデータ群をユーザに選択させるためのグラフィック・ユーザー・インターフェイスを前記表示デバイスに表示させる表示制御手段を有することを特徴とする請求項２に記載のサーバ装置。
【請求項５】
前記データ記憶領域には、管理単位名とそれに対応するところの少なくともデータを公開する相手先の情報を含む管理単位名属性値が保存されており、
前記記憶手段は、前記データ群名に対応する管理単位名を新規に定義するとともに、該新規に定義した管理単位名に対応する管理単位名属性値を複製し、前記送られてきたデータ群とともに前記データ記憶領域に記憶することを特徴とする請求項２に記載のサーバ装置。
【請求項６】
データ記憶領域を有し、所定のデータと該データを集約的に管理する単位である管理単位の名前としての管理単位名とを関連付けて管理することが可能なサーバ装置を制御する方法であって、
ネットワークを介して前記サーバ装置と接続されたクライアント装置からデータ群とともにそれに対応するデータ群名を受信するステップと、
前記受信されたデータ群に対応するデータ群名に該当する管理単位名が前記データ記憶領域に存在するか否か判別するステップと、
前記判別結果に応じて、前記データ群名に対応する管理単位名を新規に定義し、該管理単位名に関連付けて、前記受信されたデータ群を前記データ記憶領域に記憶するステップとを有することを特徴とするサーバ装置の制御方法。
【請求項７】
前記判別結果に応じて、前記クライアント装置から受信されたデータ群に含まれるデータを前記データ記憶領域に既に存在する管理単位名に関連付けて、それに対応するデータ名とともに前記データ記憶領域に記憶するステップとを更に備えたことを特徴とする請求項６に記載のサーバ装置の制御方法。
【請求項８】
前記クライアント装置は所定の情報を表示する表示デバイスを有し、前記データ記憶領域に登録するところの前記クライアント装置内のデータ又はデータ群をユーザに選択させるためのグラフィック・ユーザー・インターフェイスを前記表示デバイスに表示させることを特徴とする請求項６に記載のサーバ装置の制御方法。
【請求項９】
前記データ記憶領域には、管理単位名とそれに対応するところの少なくともデータを公開する相手先の情報を含む管理単位名属性値が保存されており、
前記記憶するステップでは、前記データ群名に対応する管理単位名を新規に定義させるとともに、該新規に定義した管理単位名に対応する管理単位名属性値を複製させ、前記送られてきたデータ群とともに前記データ記憶領域に記憶させることを特徴とする請求項６に記載のサーバ装置の制御方法。
【請求項１０】
請求項６乃至９のいずれか１項に記載の制御方法をコンピュータに実行させることを特徴とするプログラム。
【請求項１１】
請求項１０に記載のプログラムをコンピュータ読み取り可能に記憶したことを特徴とする記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アルバムに複数の画像データを関連付けて保持可能なＷｅｂアルバムシステムに関する。
【背景技術】
【０００２】
従来、静止画・動画等の画像データを公開あるいは共有したいユーザ（以下オーナー）が、Ｗｅｂサーバに開設されているアルバムサイトにアルバムを作成し、当該画像データをアップロードして該アルバムに登録し、該アルバムを特定多数のユーザ（以下ゲスト）に公開することで、画像データをオーナーとゲストとで共有するサービスがある（特許文献１参照）。
【０００３】
その際、オーナーは自分のパーソナルコンピュータ（ＰＣ）に搭載されたブラウザソフトに表示された所定のウィンドウに、複数の画像データをファイル単位でドラッグ＆ドロップすることで、アップロードする画像ファイルを指定してアップロードすることができた。
【０００４】
一方、オーナーは、自分のＰＣのハードディスクドライブ（ＨＤＤ）上で、ディレクトリやフォルダを用いて複数の画像データの整理を行っていることが多い。例えば、「２００３年 運動会」というフォルダを作成して、その下に２００３年の運動会に関する画像データを集めて管理する、といったことは、普通に行われている。
【特許文献１】特開２００３−１０８８１５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上記のような状況において、オーナーが「２００３年 春の遠足 夢見ヶ崎動物公園にて」というＰＣ上のフォルダに整理した画像ファイルをＷｅｂアルバムを用いてゲストに公開しようと考えた場合を考える。
【０００６】
オーナーは、まずＷｅｂアルバムをサービスしているＷｅｂサーバが提供するアルバムサイトに接続し、画像データをアップロードする先のアルバムを選択する。ここで、「２００３年 春の遠足 夢見ヶ崎動物公園にて」というアルバムが存在しない場合、オーナーは当該名を持ったアルバムを、アルバム選択に先立って、Ｗｅｂサーバ上に作成する必要がある。
【０００７】
その後、オーナーは「２００３年 春の遠足 夢見ヶ崎動物公園にて」というフォルダの下の画像データを指定してＷｅｂサーバへアップロードすることで、「２００３年 春の遠足 夢見ヶ崎動物公園にて」というアルバムに画像データが登録される。
【０００８】
即ち、オーナーは既に自分のＰＣのＨＤＤ上で「２００３年 春の遠足 夢見ヶ崎動物公園にて」という名前のフォルダを作成して整理していたにも関わらず、それらの画像データをネットワーク上のＷｅｂアルバムに登録する際にも、Ｗｅｂアルバムを作成し、再度「２００３年 春の遠足 夢見ヶ崎動物公園にて」という文字列を入力してアルバム名称を設定したり、画像データを登録したり、その他の属性情報を設定する必要があった。
【０００９】
当然、アップロード処理はアルバム毎に別々に行わなければならない。そのため多数のアルバムを作成しようとする場合には、アルバム名称の入力作業だけでも非常に手間がかかることとなる。
【００１０】
更に、画像データ登録後にゲストに対して公開するのならば、公開先のゲストのリストを設定することも、各々のアルバムごとに行う必要がある。従って、アルバムが増加し、同時に公開先のゲストの数が多くなると、本来公開したくなかった相手を誤って公開先と指定してしまうといった間違いが多くなる。
【００１１】
従って、本発明は上述した課題に鑑みてなされたものであり、ＰＣ上の画像ファイルをフォルダ単位で指定してＷｅｂアルバムサイトへアップロードする作業の煩雑さを軽減することである。
【課題を解決するための手段】
【００１２】
上述した課題を解決し、目的を達成するために、本発明に係わる情報処理システムは、データ記憶領域を有し、所定のデータと該データを集約的に管理する単位である管理単位の名前としての管理単位名とを関連付けて管理することが可能なサーバ装置と、ネットワークを経由して前記サーバ装置と接続されたクライアント装置と、を備える情報処理システムであって、前記クライアント装置は、該クライアント装置内のデータ又はデータ群を、該データに対応するデータ名又は前記データ群に対応するデータ群名に関連付けて管理する管理手段と、前記サーバ装置に前記データ群を前記又はデータ群名とともに送付する送付手段とを備え、前記サーバ装置は、前記クライアント装置から送られてきたデータ群名に該当する管理単位名が前記データ記憶領域に存在するか否か判別する判別手段と、前記判別結果に応じて、前記送られてきたデータ群名に対応する管理単位名を新規に定義し該管理単位名に関連付けて、前記送られてきたデータ群を前記データ記憶領域に記憶する記憶手段とを備えたことを特徴とする。
【００１３】
また、本発明に係わるサーバ装置は、データ記憶領域を有し、所定のデータと該データを集約的に管理する単位である管理単位の名前としての管理単位名とを関連付けて管理することが可能なサーバ装置であって、ネットワークを介して前記サーバ装置と接続されたクライアント装置からデータ群とともにそれに対応するデータ群名を受信する受信手段と、前記受信されたデータ群名に該当する管理単位名が前記データ記憶領域に存在するか否か判別する判別手段と、前記判別結果に応じて、前記受信されたデータ群名に対応する管理単位名を新規に定義し、該管理単位名に関連付けて、前記受信されたデータ群を前記データ記憶領域に記憶することを特徴とする。
【００１４】
また、本発明に係わるサーバ装置の制御方法は、データ記憶領域を有し、所定のデータと該データを集約的に管理する単位である管理単位の名前としての管理単位名とを関連付けて管理することが可能なサーバ装置を制御する方法であって、ネットワークを介して前記サーバ装置と接続されたクライアント装置からデータ群とともにそれに対応するデータ群名を受信するステップと、前記受信されたデータ群に対応するデータ群名に該当する管理単位名が前記データ記憶領域に存在するか否か判別するステップと、前記判別結果に応じて、前記データ群名に対応する管理単位名を新規に定義し、該管理単位名に関連付けて、前記受信されたデータ群を前記データ記憶領域に記憶するステップとを有することを特徴とする。
【００１５】
また、本発明に係わるプログラムは、上記の制御方法をコンピュータに実行させることを特徴とする。
【００１６】
また、本発明に係わる記憶媒体は、上記のプログラムをコンピュータ読み取り可能に記憶したことを特徴とする。
【発明の効果】
【００１７】
本発明によれば、ユーザがコンピュータ端末上の画像ファイルをネットワーク経由でアルバムサイトのサーバ装置へアップロードする作業の煩雑さを軽減することが可能となる。
【発明を実施するための最良の形態】
【００１８】
以下、本発明の好適な実施形態について説明する。
【００１９】
まず、本実施形態の概要について説明する。
【００２０】
本実施形態では、Ｗｅｂサーバの記憶装置へアップロードする対象として、個々の画像データではなく、１つ又は複数の画像データを含むフォルダが選択された場合、フォルダをＷｅｂサーバで管理されるアルバムとして扱うようにすることで、アルバム作成とアルバム名入力の煩雑な処理を回避するとともに、アルバム毎にアップロード処理を繰り返す必要をなくすようにしている。
【００２１】
更に、アップロードする対象のフォルダの名称と同一の名称のアルバムがＷｅｂサーバ上に存在しない場合、自動的にＷｅｂサーバ上にそのフォルダの名称と同じ名称のアルバムを新たに作成し、そのアルバムの属性情報として、アップロード処理起動の際に選ばれていたアルバムの属性情報を設定するようにすることで、公開先のゲスト登録を含む属性情報を改めて設定する必要をなくすようにしている。
【００２２】
このように構成することで、クライアントＰＣ上で「２００３年 春の遠足 夢見ヶ崎動物公園にて」という名称のフォルダに整理されていた画像データ群を、Ｗｅｂサーバ上のＷｅｂアルバムに登録する際には、単にそのフォルダを指定してアップロードすればよいこととなる。
【００２３】
更に、アルバムの属性設定の操作も最小限に抑えることができ、ユーザの利便性を改善できる。
【００２４】
ここで、アルバムに設定される属性情報としては、アルバムの公開先となるゲストの電子メールアドレス、アルバムに含まれる画像データのダウンロードを許可するか否か、アルバムに含まれる画像データを公開先ゲストのプリンタで印刷することを許可するか否か、アルバムに含まれる画像データの印刷を印刷業者に注文することを許可するか否か等が挙げられる。
【００２５】
以下、本発明の実施形態について、図面を参照して具体的に説明する。
【００２６】
（第１の実施形態）
図１は、Ｗｅｂアルバムシステムの全体構成を示すブロック図である。
【００２７】
Ｗｅｂアルバムサービスを提供するＷｅｂサーバ１０１と、オーナーが使用するクライアントＰＣ（Personal Computer）１０２は、ネットワーク（ＮＥＴ）１０３で接続されている。
【００２８】
データベース（ＤＢ）１０４は、画像データ、アルバム関連情報などを含む、Ｗｅｂアルバムサービスを実行するために必要なデータ類を全て保有する。図１の場合は「ＡＬＢＵＭ♯１」「ＡＬＢＵＭ♯２」「ＡＬＢＵＭ♯３」の３つのアルバムが格納されている。ＤＢのテーブル編成方法などは、説明を省略する。
【００２９】
なお、本実施形態においては、ＤＢは無制限の記憶領域を持つと仮定し、オーナーが作成可能なアルバムの個数、アルバム毎に登録可能な画像データ数、サイズ等に制限はないものとする。
【００３０】
次に、Ｗｅｂサーバ上で動作するＡＰＰ１０５はアプリケーションソフトウェアの実行部である。ＡＰＰは、具体的にはCentral Processing Unit（ＣＰＵ）で構成される。ＡＰＰ１０５は、Ｗｅｂサーバ１０１内のRandom Access memory（ＲＡＭ）やRead Only Memory（ＲＯＭ）又はＷｅｂサーバ１０１と接続された外部記憶装置に記憶されたアプリケーションソフトウェアを読み出し、その指令を受けて、以下に詳細に説明するＷｅｂアルバムサービスに関する各種処理を実行する。ＡＰＰ１０５は必要に応じて、アプリケーションソフトウェアやOperating System（ＯＳ）の指令を受けて、ＤＢ１０４にアクセスし、ＤＢ１０４のレコードの登録・更新・削除等の処理を行うことが可能である。
【００３１】
ここで、ＡＰＰ１０５に関して、本実施形態を実現するために必要な仕様を説明する。
【００３２】
Ｗｅｂアルバムサービスの全機能を実現するＡＰＰ１０５は、クライアントＰＣ１０２からＨＴＴＰ ＰＯＳＴされたエンティティボディを受け取り、ＤＢ１０４へのアクセスなど必要な処理を行った上で、適切なＨＴＭＬソースをクライアントＰＣ１０２に戻す処理を担う。
【００３３】
エンティティボディは、通常のＨＴＴＰ ＰＯＳＴにおいて広く行われるように、変数＝値を＆で連接した構造をなし、値はＵＲＬ（Uniform Resource Locator）エンコードされている。構造やエンコードに関しての詳細説明は省略する。
【００３４】
Ｗｅｂアルバムサービスの全機能をＡＰＰ１０５が実現している以上、ＡＰＰ１０５は、ＤＢ１０４から画像データの削除、ＤＢ１０４でのアルバムの管理等、様々な機能を持つのが通常であって、本実施形態においては、それらの機能の指定を、エンティティボディに含まれる変数ＦＵＮＣの値で行うこととする。
【００３５】
しかしながら、本実施形態では画像データの登録処理のみ説明すればよく、従ってその際に使用されるエンティティに関してのみ説明すればよい。従って、ここではＦＵＮＣ、ＡＬＢＵＭ、ＮＡＭＥ、ＢＯＤＹという、４つの変数と値に関してのみ説明する。
【００３６】
上述したように、ＦＵＮＣは、ＡＰＰ１０５に対して処理を指定する働きを持つ。本実施形態においては、その値は、画像データの登録を意味する「ｒｅｇｉｓｔ」とする。
【００３７】
ＡＬＢＵＭは、後述するＮＡＭＥ、ＢＯＤＹで指定された画像データを登録する先のアルバムの名称である。
【００３８】
ここで、ＡＬＢＵＭで指定されたアルバム名と同じ名称を持つアルバムが本登録実行前にＤＢ１０４上に存在していたら、ＡＰＰ１０５は、特に新規のアルバム作成などの処理は行わず、画像データを当該アルバムに追加する。なお、新たな画像データによってアルバムの画像データを上書きするようにしてもよい。
【００３９】
そのようなアルバムがＤＢ１０４に存在していなければ、ＡＰＰ１０５はＡＬＢＵＭで指定されたアルバム名のアルバムを新たにＤＢ１０４上に作成し、そこに画像データを登録する。
【００４０】
ＮＡＭＥは、ＡＬＢＵＭで指定したアルバムに、後述する画像データＢＯＤＹを登録する際に、名前として登録される文字列である。
【００４１】
本実施形態においては、ＮＡＭＥをアルバム毎にユニークな画像識別子として扱っている。即ち、ＡＰＰ１０５は、ＡＬＢＵＭで指定したアルバムに既存の画像データの名前と同じ名前がＮＡＭＥで指定された新たな画像データを登録する際には、既存の画像データを消去して、ＢＯＤＹで指定した新しい画像データで上書きする。尚、ＢＯＤＹは、実際にＤＢ１０４に登録される画像データ本体である。
【００４２】
クライアントＰＣ１０２はオーナーが画像データをＷｅｂサーバ１０１経由でＤＢ１０４にアップロードするために使用するＰＣであり、例えばＷｉｎｄｏｗｓ（登録商標）のようなＯＳや、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）のようなＷｅｂブラウザ１０６が搭載され、それらの指令を受けて動作するコンピュータである。クライアントＰＣ１０２には、Ｗｅｂブラウザ１０６に組み込まれたアプリケーションソフトウェアの指令を受けて画像データのアップロードを簡便に実行するＡｄｄＯｎ１０７も備えている。ＡｄｄＯｎ１０７は、具体的には、クライアントＰＣのＣＰＵである。
【００４３】
図２は、オーナーのクライアントＰＣ１０２が、ＤＢ１０４のＷｅｂアルバムに画像データをアップロード・登録する際に、クライアントＰＣ１０２がＷｅｂブラウザ１０６の指令を受けて、ディスプレイに表示する画面である。
【００４４】
Ｐ１０１は、オーナーが所有するアルバムの一覧である。図２においては、「ＡＬＢＵＭ♯１」、「ＡＬＢＵＭ♯２」、「ＡＬＢＵＭ♯３」という３つのアルバムを所有しており、現在「ＡＬＢＵＭ♯２」が選択されていることを示している。
【００４５】
Ｐ１０２は、アップロードするファイルやフォルダをドラッグ＆ドロップで指定するためのアップロード指定領域である。ＡｄｄＯｎ１０７はアップロード指定領域Ｐ１０２に、ポインティングデバイスから入力があったかどうかを検知する。ただし、本実施形態においては、ポインティングデバイスからフォルダのドラッグ＆ドロップが入力された場合に、アップロード指定領域Ｐ１０２では、該フォルダ以下のファイル一覧が表示されるのではなく、フォルダとして表示される。
【００４６】
例えば、図３のようなファイル・フォルダの状況において、ファイル「boke.jpg」、フォルダ「２００３年 春の遠足 夢見ヶ崎動物公園にて」、フォルダ「２００３年 夏の臨海学校 蓮沼海岸にて」という３つのアイテムが選択され、ポインティングデバイスからアップロード指定領域Ｐ１０２にドラッグ＆ドロップが入力されると、本実施形態の場合、Ａｄｄｏｎ１０７は図４のようにフォルダが表示されている状態をディスプレイに表示する。
【００４７】
一方、例えばフォルダ「２００３年 春の遠足 夢見ヶ崎動物公園にて」だけが選択され、ポインティングデバイスからアップロード指定領域Ｐ１０２にドラッグ＆ドロップが入力されると、フォルダの名前は廃棄されて、その直下にある「a.jpg」「b.jpg」がドラッグ＆ドロップされた場合と同様の結果になる。
【００４８】
Ｐ１０３は、ポインティングデバイスからアップロード処理の開始指示を入力するためのボタンである。ポインティングデバイスから本ボタンＰ１０３のクリックが入力されると、ＡｄｄＯｎ１０７はＵＰＬＯＡＤ処理を起動する。ＵＰＬＯＡＤ処理の詳細は後述する。
【００４９】
一方Ｐ１０４はポインティングデバイスから、アップロード処理を行わずに終了指示を入力するボタンである。ポインティングデバイスから本ボタンＰ１０４のクリックが入力されると、ファイルやフォルダの指定の有無に関わらず、一切のアップロード処理を行わないで所定のページに遷移する。本実施形態においては、該所定のページに関しては説明を省略する。
【００５０】
図５は、クライアントＰＣ１０２のＡｄｄＯｎ１０７が行う、ＵＰＬＯＡＤ処理の詳細を記述するフローチャートである。
【００５１】
Ｓ−２−１において、Ａｄｄｏｎ１０７は、現在選択されているアルバム名ＡＬＢＵＭ、アップロード対象のアイテム一覧であるＡＬＬ_ＩＴＥＭ、フォルダに含まれるファイルの一覧であるＦＩＬＥＳ、ＡＬＬ_ＩＴＥＭやＦＩＬＥＳから取り出したアイテムを格納するＩＴＥＭ、データのアップロード先であるＵＲＬ、フォルダ名から生成されたアルバム名ＮＥＷＡＬＢＵＭ等、以降の処理に必要な情報を初期化する。
【００５２】
Ｓ−２−２において、Ａｄｄｏｎ１０７は、ＡＬＬ_ＩＴＥＭ中に未処理アイテムが残っているか調べられる。残っていなければ、Ｓ−２−３に進む。残っていれば、Ｓ−２−４に進む。
【００５３】
Ｓ−２−３において、Ａｄｄｏｎ１０７は、ＵＰＬＯＡＤ処理終了後に、所定のページを開くように設定し、ＵＰＬＯＡＤ処理自体を終了する。通常、アルバムを表示する画面に遷移するが、遷移する先のページは本出願に関係しないので説明は省略する。
【００５４】
Ｓ−２−４において、Ａｄｄｏｎ１０７は、ＡＬＬ_ＩＴＥＭに含まれる未処理アイテムを一つ選択して、ＩＴＥＭに格納する。
【００５５】
Ｓ−２−５において、Ａｄｄｏｎ１０７は、ＩＴＥＭの種別を判別する。具体的には、ＩＴＥＭがファイルなのか、フォルダなのかが区別される。Ａｄｄｏｎ１０７は、ファイルと判別した場合Ｓ−２−７、フォルダと判別した場合はＳ−２−６に遷移する。
【００５６】
ＩＴＥＭがファイルと判別された場合、Ｓ−２−７において、Ａｄｄｏｎ１０７は、アルバムに登録される画像データの名前を示す変数ＮＡＭＥをＩＴＥＭから取り出す。本実施形態においては、パスの最後のエレメント、即ちＩＴＥＭがc:\foo\bar\a.jpgならば、a.jpgがＮＡＭＥとなる。
【００５７】
ついでＳ−２−９において、ＡｄｄＯｎ１０７は、アルバム名を示す変数ＡＬＢＵＭに対して、ＮＡＭＥを画像の名前として、ＩＴＥＭが指し示すファイルの内容を画像データとして、ＨＴＴＰ ＰＴを用いてＵＲＬにＰＯＳＴすることで、ＡＰＰ１０５への画像データの登録要求を完了し、Ｓ−２−２に戻る。尚、このＰＯＳＴを受けたＡＰＰ１０５は、上述した仕様に従って、アルバムに画像データを登録する。
【００５８】
Ｓ−２−５において、ＡｄｄＯｎ１０７はＩＴＥＭがフォルダと判断された場合、Ｓ−２−６において、ＩＴＥＭからアルバム名が生成され、ＮＥＷＡＬＢＵＭに格納される。本実施形態においては、Ｓ−２−７同様ＩＴＥＭの最後のエレメント、この場合ＩＴＥＭが「c:\foo\bar」ならばbarがＮＥＷＡＬＢＵＭとなる。
【００５９】
続いてＳ−２−８において、ＡｄｄＯｎ１０７はＦＩＬＥＳにＩＴＥＭが指し示しているフォルダ以下に存在するファイルの一覧を作成する。本処理は一般的によく行われるため、ここでは詳細説明は省略する。
【００６０】
Ｓ−２−１０において、ＡｄｄＯｎ１０７はＦＩＬＥＳに未処理ファイルが残っているかをチェックし、未処理ファイルがなければＳ−２−２に戻る。
【００６１】
Ｓ−２−１０において、ＡｄｄＯｎ１０７はＦＩＬＥＳに未処理ファイルが残っているとチェックしたら、Ｓ−２−１１でファイルを一つ選び、ＩＴＥＭに読み出す。
【００６２】
Ｓ−２−１２において、Ｓ−２−７同様、ＡｄｄＯｎ１０７はＩＴＥＭの最後のエレメントから、アルバムに登録される際の画像データの名前ＮＡＭＥを決定する。
【００６３】
Ｓ−２−１３において、Ｓ−２−９同様、ＡｄｄＯｎ１０７はアルバム名ＮＥＷＡＬＢＵＭに対して、ＮＡＭＥを画像の名前として、ＩＴＥＭが指し示すファイルを画像データとして、ＨＴＴＰ ＰＯＳＴを用いてＵＲＬに画像データ登録要求をＰＯＳＴし、ＡｄｄＯｎ１０７はＳ−２−１０に戻る。
【００６４】
一方、ＰＯＳＴを受け取ったＡＰＰ１０５は、アルバムＮＥＷＡＬＢＵＭに対して、画像データを登録する。概説の通り、ＤＢ１０４上にＮＥＷＡＬＢＵＭが存在していなかった場合は、まずアルバムＮＥＷＡＬＢＵＭをＤＢ１０４上に作成してから、画像登録処理を実施する。
【００６５】
以下、クライアントＰＣ１０２のＡｄｄＯｎ１０７が実行するＵＰＬＯＡＤ処理について、図５のフローチャートを、具体的に図４に示すような画面の場合に適用して説明する。
【００６６】
Ｓ−２−１において、ＡｄｄＯｎ１０７は、図４のから入力される各種情報を読み出すとともに、ＵＰＬＯＡＤの引数の値から、図６のごとく変数にセットする。
ここで、ＡｄｄＯｎ１０７は、ＡＬＢＵＭには、Ｐ１０１において選択されているアルバム、図４の場合「ＡＬＢＵＭ♯２」を変数としてセットする。
【００６７】
ＡＬＬ_ＩＴＥＭにはＰ１０２にドロップされているファイルやフォルダのパス、図４の場合、「boke.jpg」、「２００３年 春の遠足 夢見ヶ崎動物公園にて」、「夏の臨海学校 蓮沼海岸にて」のフルパスである「c:\boke.jp」、「c:\２００３年 春の遠足 夢見ヶ崎動物公園にて」、「c:\２００３年 夏の臨海学校 蓮沼海岸にて」をセットする。
【００６８】
ＵＲＬとは画像のアップロード（ＰＯＳＴ）先であって、ＡｄｄＯｎ１０７はＵＰＬＯＡＤ呼出時に外部から与えらた値をＵＲＬにセットする。
【００６９】
Ｓ−２−１での以上のような初期化が終了した後、Ｓ−２−２でＡｄｄＯｎ１０７は、ＡＬＬ_ＩＴＥＭの中から未処理のアイテム「c:\boke.jpg」を選択してＩＴＥＭに格納し、Ｓ−２−５に遷移する。
【００７０】
Ｓ−２−５においてＡｄｄＯｎ１０７は、ＩＴＥＭの内容「c:\boke.jp」がフォルダかファイルかを判定する。「c:\boke.jp」はファイルであるため、ＡｄｄＯｎ１０７はＳ−２−７に進む。
【００７１】
Ｓ−２−７において、ＡｄｄＯｎ１０７は図７に示したＨＴＴＰ ＰＯＳＴリクエストを発行して、Ｓ−２−２に戻る。
【００７２】
尚、ＡｄｄＯｎ１０７からＨＴＴＰ ＰＯＳＴリクエストを受信したＡＰＰ１０５は、Ｓ−２−７においてＰＯＳＴされたデータを受け取り、ＤＢ１０４上のＡＬＢＵＭ♯２にboke.jpgを追加（あるいは上書き）する。
【００７３】
なお、図７で示したデータは、実際には値をＵＲＬエンコードした上で＆で連接されてエンティティとなることに注意する。
【００７４】
Ｓ−２−２においてＡＬＬ_ＩＴＥＭ上には未処理のアイテムが残っているので、ＡｄｄＯｎ１０７は、Ｓ−２−４で「c:\２００３年 春の遠足 夢見ヶ崎動物公園にて」を選択してＩＴＥＭに格納し、Ｓ−２−５に移る。
【００７５】
Ｓ−２−５において、ＡｄｄＯｎ１０７は、ＩＴＥＭがファイルかフォルダかを判別する。この場合、「c:\２００３年 春の遠足 夢見ヶ崎動物公園にて」はフォルダであるから、ＡｄｄＯｎ１０７は、Ｓ−２−６に進む。
【００７６】
Ｓ−２−６において、ＡｄｄＯｎ１０７は、ＩＴＥＭからＮＥＷＡＬＢＵＭとして「２００３年 春の遠足 夢見ヶ崎動物公園にて」を切り出してＮＥＷＡＬＢＵＭに格納し、Ｓ−２−８に進む。
【００７７】
Ｓ−２−８において、ＡｄｄＯｎ１０７は、ＩＴＥＭに格納しているフォルダ「c:\２００３年 春の遠足 夢見ヶ崎動物公園にて」以下に存在するファイル「c:\２００３年 春の遠足 夢見ヶ崎動物公園にて\a.jpg」、「c:\２００３年 春の遠足 夢見ヶ崎動物公園にて\b.jpg」をＦＩＬＥＳに格納し、Ｓ−２−１０に進む。
【００７８】
Ｓ−２−１０において、ＦＩＬＥＳには未処理のファイルが含まれているので、ＡｄｄＯｎ１０７はＳ−２−１１に進む。
【００７９】
Ｓ−２−１１において、ＡｄｄＯｎ１０７は、ＦＩＬＥＳから「c:\２００３年 春の遠足 夢見ヶ崎動物公園にて\a.jpg」を選択してＩＴＥＭに格納し、Ｓ−２−１２に進む。
【００８０】
Ｓ−２−１２において、ＡｄｄＯｎ１０７は、ＩＴＥＭから、ＮＡＭＥとして「a.jpg」を切り出す。
【００８１】
Ｓ−２−１３において、ＡｄｄＯｎ１０７は、図８で示すデータを生成し、ＵＲＬにＨＴＴＰ ＰＯＳＴする。ＢＯＤＹは、ＩＴＥＭが指し示すファイルの内容である。ＡｄｄＯｎ１０７は新規にアルバムが作成されたことを特に認識せずに、Ｓ−２−１０に戻る。
【００８２】
図８で示したデータは、図７同様、実際には値をＵＲＬエンコードした上で＆で連接されてエンティティとなる。
【００８３】
尚、上記したようにＡｄｄＯｎ１０７からＰＯＳＴを受けたＡＰＰ１０５は新たにアルバム「２００３年 春の遠足 夢見ヶ崎動物公園にて」をＤＢ１０４に作成した上で、画像データＢＯＤＹを名前ＮＡＭＥで当該アルバムに登録する。
【００８４】
Ｓ−２−１０において、ＦＩＬＥＳには「c:\２００３年 春の遠足 夢見ヶ崎動物公園にて\b.jpg」が残っているので、ＡｄｄＯｎ１０７は再度Ｓ−２−１１に進む。
【００８５】
Ｓ−２−１１において、ＡｄｄＯｎ１０７は、「c:\２００３年 春の遠足 夢見ヶ崎動物公園にて\b.jpg」をＩＴＥＭに格納する。
【００８６】
更に、Ｓ−２−１３において、ＡｄｄＯｎ１０７は、図９で示すデータをＵＲＬに対してＨＴＴＰ ＰＯＳＴし、Ｓ−２−１０に戻る。
【００８７】
尚、上記したようにＡｄｄＯｎ１０７からＰＯＳＴを受けたＡＰＰ１０５は、先ほど作成されたアルバム「２００３年 春の遠足 夢見ヶ崎動物公園にて」に、画像データＢＯＤＹを名前b.jpgで追加する。
【００８８】
Ｓ−２−１０において、今度はＦＩＬＥＳに未処理ファイルがないため、ＡｄｄＯｎ１０７は、Ｓ−２−２に戻る。
【００８９】
Ｓ−２−２において、ＡＬＬ_ＩＴＥＭに未処理アイテム「c:\２００３年 夏の臨海学校 蓮沼海岸にて」が残っているので、ＡｄｄＯｎ１０７は、Ｓ−２−３にて「c:\２００３年 夏の臨海学校 蓮沼海岸にて」を選び、ＩＴＥＭに格納する。
【００９０】
以下、「c:\２００３年 春の遠足 夢見ヶ崎動物公園にて」の際と同様の処理が進み、図１０、図１１で示したＡｄｄＯｎ１０７によるＨＴＴＰ ＰＯＳＴが行われた後、Ｓ−２−２にてＡＬＬ_ＩＴＥＭに未処理アイテムが存在しないために、ＡｄｄＯｎ１０７はＳ−２−３に遷移する。
【００９１】
Ｓ−２−３において、画像データの登録終了後に別のページに遷移するように設定する。なお、遷移するページの性質等は本実施形態と直接関係しないので、説明を省略する。
【００９２】
Ｓ−２−３が終了したら、ＡｄｄＯｎ１０７はＵＰＬＯＡＤ処理を終了する。
【００９３】
（第２の実施形態）
第１の実施形態においては、アップロードしようとするフォルダの名称と同じ名称のアルバムがＤＢ１０４上に存在しない場合には、自動的に新規のアルバムを作成した上で指定された画像データを登録できたが、公開先ゲストのリストや、アルバムに含まれる画像データの閲覧を許可するか否か、アルバムに含まれる画像データの印刷を許可するか否か、アルバムに含まれる画像データのダウンロードを許可するか否か、など、アルバムに関連する属性情報に関しては、別に設定する必要があった。
【００９４】
この問題を解決するために、ＡｄｄＯｎ１０７がＨＴＴＰ ＰＯＳＴするデータに、登録先アルバム名とは別に、選択されているアルバム名ＣＵＲＲＥＮＴを渡すように、第１の実施形態を拡張する。
【００９５】
例えば、図１０で例示した、ＡｄｄＯｎ１０７からＡＰＰ１０５へＰＯＳＴされるエンティティは、図４で「ＡＬＢＵＭ♯２」が選択されているので、図１２に示した通り、ＣＵＲＲＥＮＴの値は「ＡＬＢＵＭ♯２」となる。
【００９６】
ここで、ＰＯＳＴされるエンティティにＣＵＲＲＥＮＴが追加されたことに伴って、第２の実施形態におけるＡＰＰ１０５には、第１の実施形態で示したＡＰＰ１０５の仕様に、更に以下の仕様が追加される。
【００９７】
ＤＢ１０４上に存在しないアルバム名がＡＬＢＵＭにて指定された場合、ＣＵＲＲＥＮＴで指定されたアルバムがＤＢ１０４上に存在したら、ＣＵＲＲＥＮＴのアルバムに関連付けられたアルバム属性情報を、新規に作成したアルバムのアルバム属性情報にコピーするように構成する。
【００９８】
なお、アルバム属性情報には、少なくとも公開先ゲストのメールアドレスを含むリストが含まれる。
【００９９】
なお、第１及び第２の実施形態においては、ＡＰＰ１０５へのデータ送付に、ＨＴＴＰ ＰＯＳＴのみを使用し、かつ一つの画像データ登録のためにただ１回のＨＴＴＰ ＰＯＳＴで全ての転送処理を行っているが、これは例えばＢＯＤＹの転送には別の接続（例えばＦＴＰ）を利用しても同様の効果がある。
【０１００】
以上説明したように、第１の実施形態によれば、アップロードする対象としてフォルダが選択された場合、フォルダをアルバム名として扱うようにすることで、アルバム作成とアルバム名入力の煩雑さを回避するとともに、アルバム毎にアップロード処理を繰り返す必要をなくすことができる。
【０１０１】
更に、第２の実施形態によれば、フォルダ名と同一のアルバムが存在しない場合、フォルダ名と同じアルバムを作成するが、そのアルバムの属性情報は、アップロード処理起動の際に選ばれていたアルバムの属性情報を継承するようにすることで、公開先のゲストのリストを含む属性情報を改めて設定する必要をなくすことができる。
【０１０２】
最後に、Ｗｅｂサーバ１０１又はクライアントＰＣ１０２を構成するコンピュータ装置の一例について、図１３のブロック図を参照して説明する。同図において、１３０１はＲＡＭ１３０２に格納されている制御プログラムに従って装置全体の制御を行うＣＰＵ、１３０２はＣＰＵ１３０１にて実行される本装置の制御プログラム、文書データ、クライアント１０３の状態を管理するためのセッションオブジェクトなどを格納するＲＡＭなどの内部記憶部、１３０３はＣＰＵ１３０１の制御の下にインターネットなどのネットワークとの接続を行ってデータなどを送受信するネットワークインタフェースである。
【０１０３】
１３０４はファイルを保存する磁気ディスクなどの外部記憶装置である。１３０５はディスプレイ、１３０６はキーボード、１３０７はマウスなどのポインティングデバイスである。ＲＡＭ１３０２に格納されている制御プログラムは、同じくＲＡＭ１３０２に格納されているＯＳ（Operating System）の機能を必要に応じて使用し、ＲＡＭ１３０２に一時記憶するデータの内容を読み書きしたり、ネットワークインタフェース１３０３を通じてデータの送受信を行ったり、キーボード１３０６やポインティングデバイス１３０７からの入力を受け取ったり、ディスプレイ１３０５に表示を行ったりすることで、所定の動作を行う。
【０１０４】
ここでは、制御プログラムはＲＡＭ１３０２に格納されているものとしたが、制御プログラムを外部記憶装置１３０４から読み込んで実行するようにしてもよいし、ネットワークインタフェース１３０３を介して受信して実行するようにしてもよい。また、図２には示していないが、ＲＯＭ等の読み出し専用の内部記憶部から読み込んで実行するようにしてもよい。
【０１０５】
さらに、キーボード１３０６やポインティングデバイス１３０７の代わりに、あるいはそれらに加えて、音声入力等の他の入力装置を備えることもできる。また、これらすべての構成要素を必ずしも備える必要はなく、サーバ１０１においては多くの場合、ディスプレイ１３０５が省略されたり、キーボード１３０６やポインティングデバイス１３０７を他のコンピュータと共有したりすることとなる。
【０１０６】
以上のように、上記の実施形態によれば、ＰＣ上の画像ファイルのアルバムサイトへのアップロード作業の煩雑さを軽減することが可能となる。
【０１０７】
（他の実施形態）
また、各実施形態の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１０８】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１０９】
本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。
【図面の簡単な説明】
【０１１０】
【図１】Ｗｅｂアルバムシステムの全体構成を示すブロック図である。
【図２】オーナーがアルバムに画像ファイルをアップロード・登録するための画面を示す図である。
【図３】ファイル・フォルダの状況を示す図である。
【図４】図３に示す構成のファイル・フォルダをアルバムにアップロード・登録するための画面を示す図である。
【図５】ＡｄｄＯｎ内部で行われる、ＵＰＬＯＡＤ処理の詳細を記述するフローチャートである。
【図６】図４の状態を読み出して、ＵＰＬＯＡＤの引数の値から変数をセットした状態を示す図である。
【図７】ＨＴＴＰ ＰＯＳＴリクエストを示す図である。
【図８】ＵＲＬに対してＨＴＴＰ ＰＯＳＴされるデータを示す図である。
【図９】ＵＲＬに対してＨＴＴＰ ＰＯＳＴされるデータを示す図である。
【図１０】ＵＲＬに対してＨＴＴＰ ＰＯＳＴされるデータを示す図である。
【図１１】ＵＲＬに対してＨＴＴＰ ＰＯＳＴされるデータを示す図である。
【図１２】第２の実施形態におけるＨＴＴＰ ＰＯＳＴされるデータを示す図である。
【図１３】コンピュータ装置の構成を示すブロック図である。
【図１】
2005267614.tif 000003
【図２】
2005267614.tif 000004
【図３】
2005267614.tif 000005
【図４】
2005267614.tif 000006
【図５】
2005267614.tif 000007
【図６】
2005267614.tif 000008
【図７】
2005267614.tif 000009
【図８】
2005267614.tif 000010
【図９】
2005267614.tif 000011
【図１０】
2005267614.tif 000012
【図１１】
2005267614.tif 000013
【図１２】
2005267614.tif 000014
【図１３】
2005267614.tif 000015