JP2013156914A - 文書管理サーバ、文書管理方法、プログラム - Google Patents

Abstract

【課題】文書管理サーバで管理されている複数の文書を、簡易な操作でまとめてダウンロード可能にする。
【解決手段】本発明の文書管理サーバは、クライアントからダウンロード対象として指定された複数のコンテンツ文書の実体データを取得し、当該指定された複数のコンテンツ文書の中に同名のコンテンツ文書がある場合は、当該取得した複数のコンテンツ文書それぞれの実体データを、アーカイブファイル内に作成した異なるフォルダに保存する。更に、前記ダウンロード対象として指定された複数のコンテンツ文書それぞれの前記文書管理サーバにおけるパス情報と前記アーカイブファイル内におけるパス情報とを関連付けて記述した情報ファイルを作成し、当該作成した情報ファイルを前記アーカイブファイル内に保存する。そして、前記複数のコンテンツ文書それぞれの実体データと情報ファイルとを保存したアーカイブファイルを、クライアントに送信する。
【選択図】 図１２

Description

本発明は、文書を管理する文書管理サーバ及びその文書管理方法に関する。

従来のウェブブラウザ上で動作する文書管理システムでは、文書管理サーバで管理されているフォルダや文書について表示・検索・ダウンロードなどを行ったり、文書管理サーバに対して文書やファイルのアップロードを行ったりすることができる。また複数の文書をまとめてダウンロードする際には、該複数の文書を１つのファイルにアーカイブしてダウンロードする機能を有する場合もある。例えば、複数のファイルをＺＩＰフォーマットでアーカイブすることにより１つのＺＩＰファイルにまとめてからダウンロードすることが可能である。
また、特許文献１では、ＨＴＭＬで定義されたオブジェクト（アイコンやリンク）をローカルＰＣのＯＳ上へドラッグアンドドロップすることにより、該オブジェクトに対応づけられたファイルを容易にダウンロードするシステムを開示している。
また、特許文献２では、ダウンロードした文書を編集して保存するときに、参照していた別の文書があれば、そのフルパスを文書の中に埋め込んで文書を保存し、再度文書を開いた場合に、文書に埋め込みしたフルパスから先に参照していた文書を閲覧できるようにしている。

ＷＯ２００８／０２９７７４号公報 特開２００６−１２６９６２号公報

文書管理サーバで管理されている文書を検索した結果、複数の異なる保存場所（異なるディレクトリやフォルダ）に保存されている複数の文書がヒットする場合がある。このとき、異なる場所に保存されている同名の文書が検索結果として得られる場合もある。
通常のクライアントＰＣでは、ダウンロード先の同じフォルダに同名の文書を保存することができないので、同名の各文書をダウンロードするたびに、文書名称を変更したり、各文書の保存先のフォルダをユーザがいちいち指定したりする必要がある。このように、複数の文書をダウンロードするためには、煩雑な操作が必要となってしまう場合があるという課題がある。

上記課題を解決するために、本発明の文書管理サーバは、ネットワークを介してクライアントと接続され、階層構造を有するフォルダに格納されているコンテンツ文書を管理する文書管理サーバであって、前記クライアントからダウンロード対象として指定された複数のコンテンツ文書の実体データを取得し、当該指定された複数のコンテンツ文書の中に同名のコンテンツ文書がある場合は、当該取得した複数のコンテンツ文書それぞれの実体データを、アーカイブファイル内に作成した異なるフォルダに保存する実データ保存手段と、前記ダウンロード対象として指定された複数のコンテンツ文書それぞれの前記文書管理サーバにおけるパス情報と前記アーカイブファイル内におけるパス情報とを関連付けて記述した情報ファイルを作成し、当該作成した情報ファイルを前記アーカイブファイル内に保存するアーカイブ情報ファイル保存手段と、前記複数のコンテンツ文書それぞれの実体データと前記情報ファイルとを保存した前記アーカイブファイルを、前記クライアントに送信する送信手段と、を有する。

複数の文書ファイル（複数のコンテンツ文書）をまとめてダウンロードする際に同名の文書ファイルがある場合は、自動的に複数のフォルダを作成してそのフォルダ内に各文書ファイルを保存するので、各文書ファイルの名称を変更することなくまとめてダウンロードできる。
更に、またダウンロードする際に、各文書ファイルに関する情報（パス、プロパティなど）をまとめて記述した情報ファイルを作成して保存するので、各文書ファイルがどこからダウンロードされたものなのか識別することも可能になる。

システム構成図 文書管理サーバおよび文書管理クライアントのハードウェア構成図 実施例１の各処理部の構成例 コンテンツの構成例 実施例１のＵＩ画面の構成例 実施例１のアーカイブファイルの構成例 複数のコンテンツをダウンロードする処理のシーケンス 検索リクエストを送信するフローチャート アーカイブリクエストを送信するフローチャート ダウンロードリクエストを送信するフローチャート 検索処理のフローチャート アーカイブ処理のフローチャート ダウンロード処理のフローチャート 実施例２の各処理部の構成例 アップロード処理後のコンテンツの構成例 実施例２のＵＩ画面の構成例 アップロード対象となるアーカイブファイルの構成例 アーカイブファイルをアップロードする処理のシーケンス アップロードリクエストを送信するフローチャート アップロード処理のフローチャート

＜システム構成＞
図１は、本発明の一実施形態に係る文書管理システムの構成図である。該システムは、文書管理サーバＰＣ１０とクライアントＰＣ２０が、ＬＡＮ３０等のネットワークを介して接続されている。

文書管理サーバＰＣ１０は、文書や画像などのコンテンツ（ファイル）を管理する文書管理機能と、Ｗｅｂアプリケーションサーバ機能とを提供するサーバである。クライアントＰＣ２０は、ウェブブラウザを介して文書管理サーバＰＣ１０に接続してコンテンツを操作する機能を提供する。

文書管理サーバ１０とクライアントＰＣ２０は、一般的な情報処理装置（ＰＣ）のハードウェアで構成することができる。図２は、本実施形態に係る文書管理システムを構成する各ＰＣのハードウェア構成図を示している。図２において、ＣＰＵ２０１は、ＲＯＭ２０３内のプログラム用ＲＯＭに記憶されたプログラムや、ハードディスク２１０からＲＡＭ２０２にロードされたＯＳ（オペレーションシステム）やアプリケーション等のプログラムを実行する。すなわち、コンピュータ（ＣＰＵ）が、コンピュータ読み取り可能な記憶媒体に格納された該プログラムを実行することにより、後述する各フローチャートの処理を実行する各処理部として機能する。ＲＡＭ２０２は、ＣＰＵ２０１のメインメモリであり、ワークエリア等として機能する。キーボードコントローラ２０４は、キーボード２０８や図示しないポインティングデバイス（マウス、タッチパッド、タッチパネル、トラックボールなど）からの操作入力を制御する。ディスプレイコントローラ２０５は、ディスプレイ２０９の表示を制御する。ディスクコントローラ２０６は、各種データを記憶するハードディスク（ＨＤ）やフレキシブルディスク（ＦＤ）等の外部メモリ２１０へのデータアクセスを制御する。ネットワークコントローラ（ＮＣ）２０７はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。

＜実施例１＞
以下、本発明の実施例１に係るシステムの処理の流れについて説明する。

図３は、本発明の実施例１のシステムにおいて、文書管理サーバＰＣ１０とクライアントＰＣ２０が提供する各処理部の構成例を示している。

文書管理サーバＰＣ１０のＣＰＵ２０１がプログラムを実行することにより、文書管理サーバは各処理部３００〜３０７として機能する。なお、コンテンツなどの情報は、外部メモリ２１０に保持され、必要なときにＲＡＭ２０１にロードし処理される。

文書管理サーバＰＣ１０におけるメイン制御部３００は、文書管理サーバのアプリケーションを司るメイン制御処理を行う。また、メイン制御部３００は、入出力制御部３０１、コンテンツ制御部３０２、サービス制御部３０４を制御し、フォルダ情報、コンテンツ情報（コンテンツの名称や保存場所などに関する情報）、コンテンツの実データ（コンテンツ文書の実体である文書ファイル）などの橋渡しを行う。

入出力制御部３０１は、クライアントＰＣ２０からのサービスリクエストを受信して、クライアントＰＣ２０へそのレスポンスを送信する。

コンテンツ制御部３０２は、クライアントＰＣ２０からのリクエストに応じて、コンテンツ情報やコンテンツ実データをＤＢ（データベース）３０３から取得する。なお、コンテンツ情報やコンテンツ実データについては、ＤＢや管理ファイルなどで管理されていても良く、管理形態は特に問わない。

サービス制御部３０４は、入出力管理部３０１が受信したサービスリクエストに応じて、検索処理部３０５、アーカイブ処理部３０６、ダウンロード処理部３０７に処理を振り分けする。処理の結果を各処理部より受取った後、入出力管理部３０１へと受け渡す。

検索処理部３０５は、検索リクエストの検索パラメータ（検索範囲、検索条件）を解析して、検索条件に一致するコンテンツ情報をＤＢ３０３より取得する。取得したコンテンツ情報を結果データとしてサービス制御部３０４に渡す。

アーカイブ処理部３０６は、アーカイブリクエストのパラメータに指定されたコンテンツ情報に対応するコンテンツ実データとそのコンテンツ情報ファイルとを、アーカイブファイル（例えばＺＩＰファイル）にまとめる。アーカイブリクエスト毎に、アーカイブ化したアーカイブファイルを識別するためのファイル識別子（本実施例では、ＧＵＩＤと呼ぶ）を結果データとしてサービス制御部３０４に渡す。

ダウンロード処理部３０７は、ダウンロードリクエストのパラメータに指定されたアーカイブファイル識別子（アーカイブリクエストより取得したＧＵＩＤ）に対応するＺＩＰファイルを、結果データとしてサービス制御部３０４に渡す。

また、クライアントＰＣ２０のＣＰＵ２０１が各処理部のプログラムを読み出して実行することにより、クライアントＰＣは各処理部３１０〜３１２として機能する。

クライアントＰＣ２０のメイン制御部３１０は、クライアントＰＣ２０のアプリケーションを司るメイン制御処理を行う。また、メイン制御部３１０は、入出力管理部３１１、コンテンツ表示部３１２を制御し、コンテンツ情報やコンテンツ実データなどの橋渡しを行う。

入出力管理部３１１は、文書管理サーバＰＣ１０へサービスリクエストを送信して、文書管理サーバＰＣ１０からのレスポンスを受信する。コンテンツ表示部３１２は、文書管理サーバＰＣ１０から受信したコンテンツ情報を解釈してウェブブラウザ上に表示する。

図４は、実施例１において、ＤＢ３０３に保持されているコンテンツの構成図の例である。なお、コンテンツとは、文書や画像などの文書ファイル（以下ではコンテンツ文書と呼ぶ）、ならびに文書ファイルが格納されているフォルダとを指す。フォルダは階層構造になっており、各フォルダ内には、サブのフォルダとコンテンツ文書とを管理することができる。また、コンテンツ文書には、付加属性であるコンテンツ文書プロパティが関連付けられて保持している。

トップフォルダ４００は、全てのコンテンツを束ねる最上位のフォルダである。図４の例においては、トップフォルダ４００の下に、２０１１１１０１フォルダ（以下フォルダ４１０）、２０１１１１０２フォルダ（以下フォルダ４２０）、２０１１１１０３フォルダ（以下フォルダ４３０）が管理されている。フォルダ４１０には、コンテンツ文書である見積書４１１（以下コンテンツ文書４１１）が格納されている。また、コンテンツ文書４１１は、コンテンツ文書プロパティ４１２を保持している。フォルダ４２０には、コンテンツ文書である見積書４２１（以下コンテンツ文書４２１）が格納されている。コンテンツ文書４２１は、コンテンツ文書プロパティ４２２を保持している。フォルダ４３０には、コンテンツ文書である見積書４３１（以下コンテンツ文書４３１）が格納されている。コンテンツ文書４３１は、コンテンツ文書プロパティ４３２を保持している。

図５は、実施例１に係るユーザインタフェース画面（ＵＩ画面）の構成例であり、コンテンツ表示部３１２によりＵＩ画面の表示が行われる。メイン画面５００は、ヘッダー表示領域５０１、検索条件領域５０２、コンテンツ表示領域５０３、プロパティ表示領域５０４、フッター表示領域５０５より構成される。図５の（Ａ）はＵＩ画面全体の構成例、（Ｂ）はコンテンツ文書を選択しているときのコンテンツ表示領域５０３の拡大図、（Ｃ）はコンテキストメニューを表示させているときのコンテンツ表示領域５０３の拡大図である。

ヘッダー表示領域５０１には、アプリケーションの名前やメニューなどが表示される。また、検索条件領域５０２には、ＤＢ３０３で管理されているコンテンツ文書を検索するための条件を設定入力するためのテキスト入力エリアが表示される。本実施例では、検索範囲を設定するための入力エリア５２０と、検索キーワードを設定するための検索キーワード入力エリア５２１と、検索処理を実行開始させるための検索ボタン５２２より構成される。検索ボタン５２２が押下されるのに応じて検索実行の指示を受けたコンテンツ表示部３１２は、検索範囲５２０に入力されたテキストと検索キーワード入力エリア５２１に入力されたテキストとを、パラメータとして検索リクエストを文書管理サーバＰＣ１０へ送信する。

コンテンツ表示領域５０３には、検索条件領域５０２で設定された検索条件に合致すると判断されたコンテンツ文書（すなわち検索結果）が表示される。図５（Ａ）の例では、検索範囲５２０として「トップフォルダ」（４００）、キーワードとして「見積書」が設定された状態で検索実行されたものとする。その検索結果、コンテンツ文書の名称に「見積書」が含まれているコンテンツ文書（４１１，４２１，４３１）が合致すると判断されて、コンテンツ表示領域５０３にそれらのコンテンツ文書が一覧表示されている。一覧表示されているコンテンツ文書の中からユーザの指示にしたがってユーザ所望のコンテンツ文書を選択することができる。例えばコンテンツ文書４２１と４３１とがユーザにより選択された場合、図５（Ｂ）のように、コンテンツ表示部３１２は、コンテンツ文書４２１と４３１とを選択状態５３０、５３１にして表示する。このとき、ユーザのマウス操作により選択状態のコンテンツ文書上にマウスカーソルが重ねられると、コンテンツ表示部３１２は、コンテキストメニューを表示するためのコンテキストメニューボタン５３２を表示する。そして、ユーザの操作によりコンテキストメニューボタン５３２がクリックされると、図５（Ｃ）のように、コンテンツ表示部３１２はコンテキストメニュー５４０を表示する。コンテキストメニュー５４０内の選択肢「ダウンロード」５４１がユーザにより指定されると、コンテンツ表示部３１２は、当該ダウンロードが指示されたときに選択状態になっているコンテンツ文書（図５（Ｃ）では４２１と４３１）をパラメータとしてアーカイブリクエストを文書管理サーバＰＣ１０へ送信する。

プロパティ表示領域５０４は、コンテンツ表示領域５０３でコンテンツデータが選択されたときに、当該選択されたコンテンツ文書のプロパティを表示するための領域である。プロパティは、当該選択されたコンテンツ文書の名称や、コンテンツ文書のパス、コンテンツ文書の属性などの情報を表示するものとする。また、フッター表示領域５０５は、アプリケーションのバージョンやＣｏｐｙＲｉｇｈｔｓを表示するための領域である。

図６の（Ａ）は、図５（Ｃ）においてダウンロードが指示された場合に、文書管理サーバＰＣ１０で作成されるアーカイブファイル６００の構成図である。なお、本実施例において、アーカイブファイル６００はＺＩＰファイル形式で作成されるものとするが、ＺＩＰ形式に限るものではなく、複数のファイルを１つのファイルにできる形式なら他の形式でも良い。

アーカイブファイル６００には、フォルダ６１０、６２０と、アーカイブ情報ファイル６３０とが含まれている。更に、フォルダ６１０内にはコンテンツ文書４２１の実データが含まれ、フォルダ６２０内にはコンテンツ文書４３１の実データが含まれている。

アーカイブ情報ファイル６３０には、クライアントＰＣから受信したアーカイブリクエストで指定されたコンテンツ文書に関する情報（名称、パス、プロパティ）と、アーカイブファイル内における当該コンテンツ文書のパスとが記述されている。図６（Ｂ）の例では、アーカイブ情報ファイル６３０はＸＭＬで構成されているものとするが、ＸＭＬに限るものではなくＣＳＶなどのその他のファイル形式でも構わない。

図６（Ｂ）の例を用いて、アーカイブ情報ファイル６３０のデータ構造を定義している各タグについて説明する。タグ６４０は、＜ｒｅｓｕｌｔ＿ｌｉｓｔ＞と＜／ｒｅｓｕｌｔ＿ｌｉｓｔ＞の対で定義され、タグ６５０、６７０を管理するルートタグである。

タグ６５０は、＜ｒｅｓｕｌｔ＞と＜／ｒｅｓｕｌｔ＞の対で定義され、アーカイブファイル６００に含まれているコンテンツ文書４２１に関する情報（名称、パス、アーカイブファイル６００内におけるパス、プロパティ）を以下のタグで管理する。すなわち、コンテンツ文書の名称が＜ｎａｍｅ＞と＜／ｎａｍｅ＞のタグの間に記述されている。また、コンテンツ文書が文書管理サーバの管理下で管理されていたときのパスが＜ｐａｔｈ＞と＜／ｐａｔｈ＞のタグの間に記述されている。また、アーカイブファイル内における該コンテンツ文書が管理されているパスが＜ｖｐａｔｈ＞と＜／ｖｐａｔｈ＞のタグの間に記述されている。また、コンテンツ文書４２１のプロパティ情報が＜ｐｒｏｐｅｒｔｉｅｓ＞と＜／ｐｒｏｐｅｒｔｉｅｓ＞のタグの間に記述されている。なお、コンテンツ文書４２１のプロパティ情報６６０の詳細を図６（Ｃ）に示す。＜ｐｒｏｐｅｒｔｙ＞と＜／ｐｒｏｐｅｒｔｙ＞の対で定義されるタグ６６１と６６２は、それぞれ、コンテンツ文書４２１に付与されているプロパティ（店舗のプロパティと納期のプロパティ）を以下のタグで管理する。すなわち、各プロパティの名称が＜ｎａｍｅ＞と＜／ｎａｍｅ＞のタグの間に記述され、各プロパティの値が＜ｖａｌｕｅ＞と＜／ｖａｌｕｅ＞のタグの間に記述されている。

タグ６７０は、＜ｒｅｓｕｌｔ＞と＜／ｒｅｓｕｌｔ＞の対で定義され、アーカイブファイル６００に含まれているコンテンツ文書４３１に関する情報（名称、文書管理サーバで管理されていたときのパス、アーカイブファイル６００内におけるパス、プロパティ）を以下のタグで管理する。タグ６７０の構成は、タグ６５０と同様である。なお、コンテンツ文書４３１のプロパティ情報６８０の詳細を図６（Ｄ）に示す。タグ６８０は、＜ｐｒｏｐｅｒｔｉｅｓ＞と＜／ｐｒｏｐｅｒｔｉｅｓ＞の対で定義され、コンテンツ文書４３１に付与されている各プロパティ情報を管理している。タグ６８１内には、「店舗」のプロパティとして「福岡」の値が設定され、タグ６８２内には、「納期」のプロパティとして「２０１１年１２月０３日」の値が設定されている状態を示している。タグ６８０の構成については、タグ６６０と同じである。

以下では、本実施例１の処理の流れについて説明する。図７は、検索実行のリクエストが指示された後、検索結果一覧の中からユーザ所望のコンテンツ文書（ファイル）が選択され、当該選択されたコンテンツ文書をクライアントＰＣ２０上にダウンロードするまでの流れを示すシーケンスである。図７のシーケンスは、コンテンツ文書の検索に関するフロー（Ｓ８０）、コンテンツ文書をアーカイブ処理するフロー（Ｓ９０）、アーカイブファイルをダウンロード処理するフロー（Ｓ１００）で構成されている。図７のシーケンスの詳細について以下に記す。

ステップＳ８０において、まず、コンテンツ表示部３１２は、検索実行ボタン５２２が押下されるのに応じて発行される検索実行イベントを受信すると、検索範囲５２０と検索キーワード５２１とに設定されている条件をパラメータとして検索リクエストを文書管理サーバＰＣ１０へ送信する。該検索リクエストを受信した文書管理サーバＰＣ１０のサービス制御部３０４は、検索処理部３０５へ検索処理の実行を促す。検索処理部３０５は、該検索リクエストに含まれている検索条件（検索範囲と検索キーワード）をコンテンツ制御部３０２に送信して検索させ、コンテンツ制御部から検索結果としてコンテンツ文書情報を取得する。コンテンツ文書情報とは、検索条件に合致したコンテンツ文書の名称や、該コンテンツ文書が管理されているフォルダを示すパスなどの情報である。検索結果として取得するコンテンツ文書情報は、複数のコンテンツ文書に関する情報を同時に取得することが可能である。検索処理部３０５は、取得したコンテンツ文書情報を検索処理結果としてサービス制御部３０４に渡す。サービス制御部３０４は、受け取った検索処理結果のコンテンツ文書情報をパラメータとして設定した検索処理レスポンスを、コンテンツ表示部３１２へ送信する。コンテンツ表示部３１２は、検索処理レスポンスとして受信したコンテンツ文書情報をコンテンツ表示領域５０３に一覧表示する。表示する位置や大きさについては、コンテンツ表示部３１２の中で定義する。なお、定義の方法については、内部リソースとして定義しても良いし、外部ファイルで定義しても良い。

ステップＳ９０では、まず、コンテンツ表示部３１２は、コンテキストメニューからダウンロード５４１が選択されるのに応じて発行される選択イベントを取得すると、選択状態のコンテンツ文書（４２１と４３１）の情報をパラメータにしたアーカイブリクエストを文書管理サーバＰＣ１０へ送信する。アーカイブリクエストを受信した文書管理サーバＰＣ１０のサービス制御部３０４は、アーカイブ処理部３０６へアーカイブ処理の実行を促す。アーカイブ処理部３０６は、アーカイブリクエストに含まれている各コンテンツ文書の情報に基づいて、コンテンツ制御部３０２に対して取得要求を行い、対応するコンテンツ文書実データを取得する。アーカイブ処理部３０６は、取得した各コンテンツ文書の実データをアーカイブファイルへ追加していくことにより、アーカイブファイルを作成する。アーカイブ処理部３０６は、当該作成したアーカイブファイルを識別するためのファイル識別子（ＧＵＩＤ）を関連付け、当該アーカイブファイル識別子を処理結果としてサービス制御部３０４へ渡す。アーカイブ処理結果を受け取ったサービス制御部３０４は、ＧＵＩＤをアーカイブレスポンスのパラメータとしてクライアントＰＣ２０のコンテンツ表示部３１２へ送信する。

ステップＳ１００では、まず、コンテンツ表示部３１２は、受信したアーカイブレスポンスのパラメータとして含まれているＧＵＩＤを抽出し、当該抽出したＧＵＩＤをパラメータとして設定したダウンロードリクエストを文書管理サーバＰＣ１０へ送信する。ダウンロードリクエストを受信した文書管理サーバＰＣ１０のサービス制御部３０４は、ダウンロード処理部３０７へダウンロード処理の実行を促す。ダウンロード処理部３０７は、ダウンロードリクエストに含まれているＧＵＩＤに対応するアーカイブファイルを取得し、当該取得したアーカイブファイルを処理結果としてサービス制御部３０４へ渡す。サービス制御部３０４は、受信したアーカイブファイルをダウンロードレスポンスのパラメータとしてクライアントＰＣ２０のコンテンツ表示部３１２へ送信する。ダウンロードレスポンスを受信したコンテンツ表示部３１２は、当該受信したダウンロードレスポンスに含まれているアーカイブファイルをクライアントＰＣ２０の記憶装置に保存する。

以下では、上述したステップＳ８０、Ｓ９０，Ｓ１００の詳細について説明する。

ステップＳ８０のコンテンツデータ検索処理の詳細について、図８および図１１のフローチャートを用いて説明する。

図８のステップＳ８００において、コンテンツ表示部３１２は、検索実行ボタン５２２がユーザにより押下されるのに応じて発行される検索実行イベントを受信すると、検索範囲５２０と検索キーワード５２１とに設定されている条件をパラメータとして検索リクエストを作成する。そして、当該作成した検索リクエストを文書管理サーバＰＣ１０に送信する。

ステップＳ８０１において、文書管理サーバＰＣ１０のサービス制御部３０４は、サービスリクエストを受信し、当該受信したリクエストの種別を確認する。

文書管理サーバＰＣ１０のサービス制御部３０４は、ステップＳ８０２においてリクエストの種別が不明なリクエストであると判断した場合は、ステップＳ８０３においてリクエストエラーをクライアントＰＣへ送信する。一方、ステップＳ８０２においてリクエストの種別が検索リクエストであると判断した場合は、ステップＳ８０４において検索処理を行う。検索処理の詳細については、図１１にて説明を行う。

ステップＳ８０５において、クライアントＰＣのコンテンツ表示部３１２は、検索リクエストが成功したか否か判断する。ここでは、検索処理レスポンスを受信した場合に検索リクエストが成功したと判断して、ステップＳ８０６において、当該検索処理レスポンスからコンテンツ文書情報を抽出し、コンテンツ表示領域５０３にコンテンツ文書名称とパスを一覧表示する。一方、エラーレスポンスを受信した場合は検索リクエストが失敗したと判断して、ステップＳ８０７において、コンテンツ表示部３１２はエラーメッセージを表示する。

次に、図１１を用いて、ステップＳ８０４の検索処理の詳細について説明する。

検索処理部３０５は、ステップＳ１１０１において、検索リクエストに基づいて、検索キーワード入力エリア５２１に設定されていた検索キーワードを取得する。更に、ステップＳ１１０２において、検索処理部３０５は、検索範囲入力エリア５２０に設定されていた検索範囲を取得する。そして、当該取得した検索キーワードと検索範囲とをパラメータとしてコンテンツ制御部３０２へ検索実行を促す。

コンテンツ制御部３０２は、ステップＳ１１０３において、検索パラメータとして受信した検索範囲と検索キーワードとに基づいて、ＤＢ３０３より一致するコンテンツ文書に関する情報を取得する。コンテンツ制御部３０２は、当該取得したコンテンツ文書に関する情報を、検索結果として検索処理部３０５へ渡す。

ステップＳ１１０４において、検索処理部３０５は、検索結果として渡されたコンテンツ文書に関する情報を順に対象とし、各コンテンツ文書情報から名称やパスを取得して検索結果データに追加していくことにより、検索結果データ（検索結果リスト）を作成する。そして、検索処理部３０５は、作成した検索結果データをサービス制御部３０４に渡す。サービス制御部３０４は、ステップＳ１１０５において、該検索結果データをパラメータとして設定した検索処理レスポンスをクライアントＰＣ２０へ送信する。

ステップＳ９０のコンテンツデータをアーカイブする処理の詳細について、図９および図１２のフローチャートを用いて説明する。

コンテンツ表示部３１２は、コンテキストメニューからダウンロード５４１が選択されるのに応じて発行される選択イベントを受信すると、図９のステップＳ９００において、同じ名称のコンテンツ文書が複数選択状態になっているか否か判定する。同じ名称のコンテンツ文書がダウンロード対象として選択されていると判断した場合、ステップＳ９０１において、コンテンツ表示部３１２はフォルダ作成フラグをＲＡＭ２０２に保持する。

ステップＳ９０２において、コンテンツ表示部３０２は、選択状態になっていると判断した複数のコンテンツ文書（４２１および４３１）に関する情報と、ステップＳ９０１で設定したフォルダ作成フラグとをパラメータとしたアーカイブリクエストを作成する。そして、当該作成したアーカイブリクエストを文書管理サーバＰＣ１０に送信する。

ステップＳ９０３において、文書管理サーバＰＣ１０のサービス制御部３０４は、サービスリクエストを受信し、当該受信したリクエストの種別を確認する。

文書管理サーバＰＣ１０のサービス制御部３０４は、ステップＳ９０４においてリクエストの種別が不明なリクエストであると判断した場合は、ステップＳ９０５においてリクエストエラーをクライアントＰＣへ送信する。一方、ステップＳ９０４においてリクエストの種別がアーカイブリクエストであると判断した場合は、ステップＳ９０６においてアーカイブ処理を行う。アーカイブ処理の詳細については、図１２にて説明を行う。

ステップＳ９０７において、クライアントＰＣのコンテンツ表示部３１２は、アーカイブリクエストが成功したか否か判断する。ここでは、アーカイブレスポンスを受信した場合にアーカイブリクエストが成功したと判断して、ステップＳ８０６において、当該アーカイブレスポンスからＧＵＩＤを抽出し、ＲＡＭ２０２に保存する。一方、エラーレスポンスを受信した場合はアーカイブリクエストが失敗したと判断して、ステップＳ９０９において、コンテンツ表示部３１２はエラーメッセージを表示する。

次に、図１２を用いて、ステップＳ９０６のアーカイブ処理の詳細について説明する。

ステップＳ１２００において、アーカイブ処理部３０６は、アーカイブリクエストに対して作成されるアーカイブファイルを識別するためのＧＵＩＤを作成する。更に、アーカイブ処理部３０６は、作成したＧＵＩＤを文字列として、ＧＵＩＤを名称としたフォルダを作成する。なお、ＧＵＩＤは文書管理システム内で一意の値であればよく、作成方法は特に問わない。また、作成したフォルダの保存位置も任意の位置で構わないが、例えば、文書管理システム内の予め決められた保存位置にフォルダを作成するようにすればよい。

ステップＳ１２０１において、アーカイブ処理部３０６は、コンテンツ文書実データを格納するためのアーカイブファイル（図６（Ａ）の例ではアーカイブファイル６００）を作成する。作成するアーカイブファイルの名称は、ステップＳ１２００で取得したＧＵＩＤを文字列としたものとする。本実施例では、ステップＳ１２００で作成したＧＵＩＤ名フォルダの直下に、当該作成したアーカイブファイルを保存するものとする。

ステップＳ１２０２において、アーカイブ処理部３０６は、アーカイブリクエストから、パラメータとして設定されているフォルダ作成フラグを抽出する。

ステップＳ１２０３において、アーカイブ処理部３０６は、アーカイブリクエストから、パラメータとして設定されているアーカイブ対象のコンテンツ文書に関する情報を抽出する。

ステップＳ１２０４はループ開始端であり、アーカイブ処理部３０６は、アーカイブ対象のコンテンツ文書に関する情報を順に処理対象として、Ｓ１２０４〜Ｓ１２０９の処理を繰り返し行う。すなわち、アーカイブ対象のコンテンツ文書の数に応じて繰り返し処理が行われる。

ステップＳ１２０５において、アーカイブ処理部３０６は、ステップＳ１２０２において抽出したフォルダ作成フラグがＯＮであると判断した場合、ステップＳ１２０６においてアーカイブファイル内のルートの直下に、コンテンツ文書の実データを保存するための新たなフォルダを作成する。すなわち、同名のコンテンツ文書が選択されていると判断した場合は、コンテンツ文書を異なる名称のフォルダ下に保存するために、新たなフォルダ（図６（Ａ）の例ではフォルダ６１０や６２０）を作成する。一方、アーカイブ処理部３０６は、ステップＳ１２０５においてフォルダ作成フラグがＯＦＦである（すなわちフォルダを作成しない）と判断した場合はステップＳ１２０７に進む。

ステップＳ１２０７においては、アーカイブ処理部３０６は、コンテンツ文書情報およびコンテンツ文書実データの取得をコンテンツ制御部３０２に指示する。コンテンツ制御部３０２は、ＤＢ３０３よりコンテンツ文書情報とコンテンツ文書実データを取得して、アーカイブ処理部３０６へ渡す。

ステップＳ１２０８において、アーカイブ処理部３０６は、取得したコンテンツ文書実データをアーカイブファイルに追加保存する。このとき、ステップＳ１２０６でアーカイブファイル内のルート下にフォルダを作成していた場合は、当該作成したフォルダの直下に該コンテンツ文書実データを保存する一方、ステップＳ１２０６でフォルダを作成していなかった場合は、アーカイブファイルのルートの直下（すなわちルートフォルダ内）に該コンテンツ文書実データを保存する。また、Ｓ１２０７で取得したコンテンツ文書情報（名称、パス、プロパティ）と、アーカイブファイル内において該コンテンツ文書の実体データが保存されているパスの情報は、リスト形式でメモリ上に一時保存する。

ステップＳ１２０９は、ステップＳ１２０４の対となるループ終了端である。

ステップＳ１２１０において、アーカイブ処理部３０６は、ステップＳ１２０８にてメモリ上に一時保存しておいたコンテンツ情報とアーカイブファイル内におけるパス情報とに基づいて、アーカイブ情報ファイル６３０を作成する。そして、ステップＳ１２１１において、アーカイブ処理部３０６は、ステップＳ１２１０で作成したアーカイブ情報ファイル６３０を、ステップＳ１２０１で作成したアーカイブファイル６００のルート下に追加保存する。アーカイブ処理部３０６は、ステップＳ１２００にて作成したＧＵＩＤの文字列を、アーカイブ処理結果としてサービス制御部３０４へ渡す。

ステップＳ１２１３において、サービス制御部３０４は、アーカイブレスポンスのパラメータとしてＧＵＩＤを設定して、クライアントＰＣ２０へ送信する。

なお、上述した図１２の説明では、Ｓ１２０６でフォルダを予め作成した後に、Ｓ１２０７で取得したコンテンツ文書の実体データをＳ１２０８でアーカイブファイルに保存するようにしたが、処理の順序はこれに限るものではない。例えば、コンテンツ文書の実体データを取得し、当該実体データをアーカイブファイルに保存する際にフォルダを作成するというような手順でも構わない。

ステップＳ１００のアーカイブファイルをダウンロードする処理の詳細について、図１０と図１３のフローチャートを用いて説明する。

ステップＳ１０００において、コンテンツ表示部３１２は、アーカイブレスポンスからＧＵＩＤを抽出し、当該抽出したＧＵＩＤをパラメータとして設定したダウンロードリクエストを作成し、文書管理サーバＰＣ１０へ当該作成したダウンロードリクエストを送信する。

ステップＳ１００１において、文書管理サーバＰＣ１０のサービス制御部３０４は、サービスリクエストを受信し、リクエスト種別を確認する。

ステップＳ１００２において、文書管理サーバＰＣ１０のサービス制御部３０４は、リクエストの種別が不明なリクエストであると判断した場合、ステップＳ１００３においてリクエストエラーをクライアントＰＣへ送信する。一方、ステップＳ１００２においてリクエストの種別がダウンロードリクエストであると判断した場合は、ステップＳ１００４においてダウンロード処理を行う。ダウンロード処理の詳細については、図１３にて説明を行う。

ステップＳ１００５において、クライアントＰＣのコンテンツ表示部３１２は、ダウンロードリクエストが成功したか否か判断する。ここでは、ダウンロードレスポンスを受信した場合にダウンロードリクエストが成功したと判断して、ステップＳ１００６において、当該ダウンロードレスポンスからアーカイブファイルを取得してクライアントＰＣ２０に保存する。一方、エラーレスポンスを受信した場合はダウンロードリクエストが失敗したと判断して、ステップＳ１００７において、コンテンツ表示部３１２はエラーメッセージを表示する。

次に、図１３を用いて、ステップＳ１００４のダウンロード処理の詳細について説明する。

ステップＳ１３００において、ダウンロード処理部３０７は、ダウンロードリクエストからＧＵＩＤを取得する。

ステップＳ１３０１において、ダウンロード処理部３０７は、当該取得したＧＵＩＤに関連付けられているアーカイブファイルを取得し、当該取得したアーカイブファイルをサービス制御部３０４に渡す。

ステップＳ１３０３において、サービス制御部３０４は、レスポンスデータのパラメータとして、アーカイブファイル６００を設定してクライアントＰＣ２０へ送信する。

＜実施例２＞
以下、本発明の実施例２に係るシステムの処理の流れについて説明する。実施例２においては、実施例１と同様の処理を行うことによってダウンロードしたアーカイブファイルに対して編集等の処理を行った後、文書管理サーバＰＣ１０へ再度アップロードすることで、コンテンツ文書を更新できるようにするものである。以下、異なる部分について図とフローチャートを用いて説明する。

図１４は、実施例２に係る文書管理システムにおいて、文書管理サーバＰＣ１０とクライアントＰＣ２０が提供する各処理部の構成例を示している。アップロード処理部１４００が追加されている以外は、実施例１と同様である。

サービス制御部３０４は、入出力管理部３０１が受信したアップロードリクエストに応じて、アップロード処理部１４００に処理を振り分ける。アップロード処理部１４００は、アップロードリクエストのパラメータとして指定されているアーカイブファイルを展開する。そして、アーカイブファイル内のアーカイブ情報ファイルに記載されている情報に基づいて、コンテンツ制御部３０２を介して、コンテンツ情報の更新、コンテンツ文書実データの登録を行う。

図１５は、本実施例２に係るアップロード処理後のＤＢ３０３に保持されているコンテンツ情報の構成図である。アップロード処理で更新されないコンテンツ文書に関しては、図４と同様のコンテンツ文書がそのまま残ることになる。

図１５の例では、アップロード処理後のコンテンツ文書４２１のコンテンツ文書プロパティ１５１０は、「納期」が「２０１１年１２月１２日」に更新されている。更に、フォルダ４３０内には、コンテンツ文書である「見積書２」（以下コンテンツ文書１５２０）が新たに追加保存され、コンテンツ文書プロパティ１５２１が関連付けられている。

図１６は、本発明の第２の実施形態に係るＵＩ構成図であり、コンテンツ表示部３１２によって表示が行われる。メイン画面５００は、ヘッダー表示領域５０１、ツリー表示領域１６００、検索条件領域５０２、コンテンツ表示領域５０３、プロパティ表示領域５０４、フッター表示領域５０５より構成される。メイン画面５００において、ツリー表示領域１６００が追加されている点が実施例１とは異なるが、それ以外の領域は実施例１と同様である。

ツリー表示領域１６００には、コンテンツ文書を管理するフォルダが階層的に表示される。本実施例２では、図４や図１５に示したフォルダ構造（トップフォルダ４００、フォルダ４１０、４２０、４３０）を表示する。なお、本実施例２では、ツリー表示領域１６００（またはコンテンツ表示領域）にアーカイブファイルをドラッグ＆ドロップ（以後、Ｄ＆Ｄ）することにより、そのアーカイブファイルのアップロード処理が開始されるものとするが、このＤ＆Ｄの手法に限るものではない。例えば、操作メニューからアップロード用コマンドを選択し、アップロード対象のアーカイブファイルを指定するようにしても構わない。

図１７は、アップロード対象となるアーカイブファイルの構成例である。ここでは、実施例１と同様の処理でダウンロードした図６（Ａ）のアーカイブファイルに対して、編集処理を行った後のアーカイブファイルが図１７（Ａ）のような構成になったものとする。編集処理により、コンテンツ文書４２１のプロパティ情報１７３０に含まれる「納期」の値１７３１が「２０１１年１２月１２日」に更新されている。更に、編集処理によって、図６のコンテンツ文書４３１が、図１７のようにコンテンツ文書１７１０（見積書２）に差し替えられているが、そのプロパティ情報６８０の編集は行われていないものとする。

したがって、図１７のアーカイブファイル１７００は、フォルダ６１０、６２０とアーカイブ情報ファイル１７２０とを管理し、フォルダ６１０はコンテンツ文書４２１の実データを含み、フォルダ６２０はコンテンツ文書１７１０の実データを含んでいる状態になっている。図１７（Ｂ）に示すように、編集後のアーカイブ情報ファイル１７２０には、コンテンツ文書（４２１と１７１０）に関する情報（名称、パス、プロパティ）と、アーカイブファイル内における当該コンテンツ文書のパスとが記述されている。以下、編集が行われた箇所のタグの説明を記載する。図１７（Ｂ）のタグ１７３０は、＜ｐｒｏｐｅｒｔｉｅｓ＞と＜／ｐｒｏｐｅｒｔｉｅｓ＞の対で定義され、コンテンツ文書４２１に付与されているプロパティ情報を管理している。タグ１７３０の詳細を図１７（Ｃ）に示しているが、コンテンツ文書４２１のプロパティ６６２のうち、＜ｖａｌｕｅ＞と＜／ｖａｌｕｅ＞のタグ１７３１の間に記述されている値が「２０１１年１２月１２日」に更新されている。また、図６のコンテンツ文書４３１が図１７（Ａ）のようにコンテンツ文書１７１０（見積書２）に差し替えられているので、図１７（Ｂ）のアーカイブ情報ファイル１７２０のように、＜ｎａｍｅ＞と＜／ｎａｍｅ＞のタグ１７４０の間に記述されている文書名が「見積書２」に変更されている。なお、図１７（Ｄ）に示すように、コンテンツ文書１７１０のプロパティ情報６８０は変更されていないので、図６（Ｄ）と同様である。

図１８は、クライアントＰＣ２０上にあるアーカイブファイル１７００を文書管理サーバＰＣ１０へアップロードする処理（Ｓ１９０）の流れを示すシーケンス図である。

コンテンツ表示部３１２は、ユーザの操作によってアーカイブファイル１７００がツリー表示領域１６００にＤ＆Ｄされたときに発行されるイベントを受信すると、当該アーカイブファイル１７００をパラメータとするアップロードリクエストを文書管理サーバＰＣ１０へ送信する。

アップロードリクエストを受信した文書管理サーバＰＣ１０のサービス制御部３０４は、アップロード処理部１４００へアップロード処理の実行を指示する。アップロード処理部１４００は、アーカイブリクエストに含まれているアーカイブファイル１７００を展開して、アーカイブ情報ファイルを解析し、当該アーカイブファイル内に含まれているコンテンツ文書実データとコンテンツ情報（名称、パス、プロパティ）とをコンテンツ制御部３０２へ渡す。

コンテンツ制御部３０２は、パスで指定されているＤＢ３０３内の保存位置に、コンテンツ文書実データとコンテンツ情報を登録し、登録した結果をアップロード処理部１４００に返信する。

アップロード処理部１４００は、アップロード処理結果をサービス制御部３０４に渡す。処理結果を受け取ったサービス制御部３０４は、アップロードレスポンスをクライアントＰＣのコンテンツ表示部３１２に送信する。コンテンツ表示部３１２は、登録処理後のコンテンツ文書の情報をコンテンツ表示領域５０３に一覧表示する。

ステップＳ１９０のアーカイブファイルをクライアントＰＣ２０から文書管理サーバＰＣ１０へアップロードする処理の詳細を、図１９と図２０を用いて説明する。

図１９のステップＳ１９００において、コンテンツ表示部３１２は、アーカイブファイル１７００がツリー表示領域１６００にＤ＆Ｄされたことを検知すると、当該アーカイブファイル１７００をパラメータとしたアップロードリクエストを作成し、文書管理サーバＰＣ１０にアップロードリクエストを送信する。

ステップＳ１９０１において、文書管理サーバＰＣ１０のサービス制御部３０４は、サービスリクエストを受信し、当該受信したリクエストの種別を確認する。

文書管理サーバＰＣ１０のサービス制御部３０４は、ステップＳ１９０２においてリクエストの種別が不明なリクエストであると判断した場合は、ステップＳ１９０３においてリクエストエラーをクライアントＰＣへ送信する。一方、ステップＳ１９０２においてリクエストの種別がアップロードリクエストであると判断した場合は、ステップＳ１９０４においてアップロード処理を行う。アップロード処理の詳細については、図２０にて説明を行う。

ステップＳ１９０５において、クライアントＰＣのコンテンツ表示部３１２は、アップロードリクエストが成功したか否か判断する。ここでは、アップロードレスポンスを受信した場合にアップロードリクエストが成功したと判断して、ステップＳ１９０６において、コンテンツ表示領域５０３の再表示を行う。一方、エラーレスポンスを受信した場合はアップロードリクエストが失敗したと判断して、ステップＳ１９０７において、コンテンツ表示部３１２はエラーメッセージを表示する。

次に、図２０を用いて、ステップＳ１９０４のアップロード処理の詳細について説明する。

アップロード処理部１４００は、ステップＳ２０００において、新たなＧＵＩＤを作成して、ＧＵＩＤを名称としたフォルダを作成する。このフォルダは、アーカイブファイルを展開する際に一時的に利用される作業用フォルダである。

ステップＳ２００１において、アップロード処理部１４００は、アーカイブファイル１７００から、全てのフォルダとコンテンツ文書実データとアーカイブ情報ファイルとを抽出して、ステップＳ２０００で作成したフォルダに保存する。

ステップＳ２００２において、アップロード処理部１４００は、ステップＳ２００１にて保存したアーカイブ情報ファイルを解析し、各コンテンツ文書のコンテンツ情報（名称、パス、プロパティ）を特定する。

ステップＳ２００３はループ開始端であり、アップロード処理部１４００は、アーカイブファイルから抽出したコンテンツ文書を順に処理対象として、Ｓ２００３〜Ｓ２００８の処理を繰り返し行う。

ステップＳ２００４において、アップロード処理部１４００は、ステップＳ２００１において保存したコンテンツ文書実データとパスの情報とを取得して、コンテンツ制御部３０２に対してコンテンツ登録処理を指示する。

ステップＳ２００５において、コンテンツ制御部３０２は、コンテンツ文書実データを、パス情報により指定されたＤＢ３０３中の保存場所に登録する。コンテンツ情報に含まれるパスの情報は、アーカイブファイルをダウンロードした際に各コンテンツ文書が保存されていたパスを示しているので、更新処理後の各コンテンツ文書の実データは、ＤＢ３０３中の元々保存されていた保存位置に更新登録（または追加登録）されることになる。（すなわち、名称が変更されているコンテンツ文書１７１０は、ＤＢ３０３中の元々保存されているコンテンツ文書４３１と名称が異なるので、図１５の１５２０のように追加登録されることになる。名称が変更されていないコンテンツ文書４２１に関しては、ＤＢ３０３中の元々保存されているコンテンツ文書４２１と名称が同じなので、更新登録されることになる。）
ステップＳ２００６において、アーカイブ処理部１４００は、ステップＳ２００２において解析したコンテンツ情報（名称、プロパティ）を取得して、コンテンツ制御部３０２へコンテンツ情報更新処理を指示する。

ステップＳ２００７において、コンテンツ制御部３０２は、ステップＳ２００５で登録したコンテンツ文書に関連するコンテンツ文書プロパティを更新する。

ステップＳ２００８は、ステップＳ２００３の対となるループ終了端である。

ステップＳ２００９において、アップロード処理部１４００は、ステップＳ２０００で作成したＧＵＩＤ名フォルダを削除し、アップロード処理結果をサービス制御部３０４へ渡す。

ステップＳ２０１０において、サービス制御部３０４は、アップロードレスポンスをクライアントＰＣ２０へ送信する。

（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。その処理は、上述した実施例の機能を実現させるソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (10)

1. ネットワークを介してクライアントと接続され、階層構造を有するフォルダに格納されているコンテンツ文書を管理する文書管理サーバであって、
   前記クライアントからダウンロード対象として指定された複数のコンテンツ文書の実体データを取得し、当該指定された複数のコンテンツ文書の中に同名のコンテンツ文書がある場合は、当該取得した複数のコンテンツ文書それぞれの実体データを、アーカイブファイル内に作成した異なるフォルダに保存する実データ保存手段と、
   前記ダウンロード対象として指定された複数のコンテンツ文書それぞれの前記文書管理サーバにおけるパス情報と前記アーカイブファイル内におけるパス情報とを関連付けて記述した情報ファイルを作成し、当該作成した情報ファイルを前記アーカイブファイル内に保存するアーカイブ情報ファイル保存手段と、
   前記複数のコンテンツ文書それぞれの実体データと前記情報ファイルとを保存した前記アーカイブファイルを、前記クライアントに送信する送信手段と、
   を有することを特徴とする文書管理サーバ。
2. 前記アーカイブ情報ファイル保存手段は、前記ダウンロード対象として指定された複数のコンテンツ文書それぞれの前記文書管理サーバにおけるパス情報と前記アーカイブファイル内におけるパス情報と前記複数のコンテンツ文書それぞれのプロパティの情報とを関連付けて記述した前記情報ファイルを作成し、当該作成した情報ファイルを前記アーカイブファイル内に保存することを特徴とする請求項１に記載の文書管理サーバ。
3. 前記文書管理サーバは、
   前記複数のコンテンツ文書それぞれの実体データと前記情報ファイルとを保存した前記アーカイブファイルを、当該アーカイブファイルを識別するためのファイル識別子と関連付けて保存するアーカイブファイル保存手段と、
   前記ファイル識別子を前記クライアントに送信する識別子送信手段と、
   を更に有し、
   前記送信手段は、前記クライアントから前記ファイル識別子を含むダウンロードリクエストを受信した場合に、当該ファイル識別子と関連付けて保存されている前記アーカイブファイルを、前記クライアントへ送信することを特徴とする請求項１または２に記載の文書管理サーバ。
4. 前記文書管理サーバは、
   前記クライアントから送信されてきた検索条件に合致するコンテンツ文書を検索する検索手段と、
   前記検索手段での検索結果を前記クライアントへ送信する検索結果送信手段と、
   を更に備え、
   前記クライアントからダウンロード対象として指定された複数のコンテンツ文書は、前記クライアントにおいて、前記検索結果の中からユーザにより選択されたコンテンツ文書であることを特徴とする請求項１乃至３のいずれか１項に記載の文書管理サーバ。
5. 前記クライアントにおいて更新されたアーカイブファイルのアップロード要求を受信した場合、当該更新されたアーカイブファイル内に含まれる前記情報ファイルを解析することにより当該更新されたアーカイブファイル内に含まれるコンテンツ文書の実体データそれぞれについての前記文書管理サーバにおけるパス情報を取得し、当該パス情報で指定されている保存位置に該コンテンツ文書の実体データを保存するアップロード手段を、
   更に有することを特徴とする請求項１乃至４のいずれか１項に記載の文書管理サーバ。
6. 前記アップロード手段は、更に、該更新されたアーカイブファイル内に含まれる前記情報ファイルを解析することにより当該更新されたアーカイブファイル内に含まれるコンテンツ文書それぞれのプロパティの情報を取得し、当該取得したプロパティの情報を用いて、前記パス情報で指定されている保存位置に保存した前記コンテンツ文書の実体データに関連付けるプロパティ情報を更新することを特徴とする請求項５に記載の文書管理サーバ。
7. 前記実データ保存手段は、前記クライアントからダウンロード対象として指定された複数のコンテンツ文書の実体データを取得し、当該指定された複数のコンテンツ文書の中に同名のコンテンツ文書がない場合は、当該取得した複数のコンテンツ文書それぞれの実体データを、アーカイブファイル内の同一フォルダに保存することを特徴とする請求項１に記載の文書管理サーバ。
8. ネットワークを介してクライアントと接続され、階層構造を有するフォルダに格納されているコンテンツ文書を管理する文書管理サーバが実行する文書管理方法であって、
   前記文書管理サーバの実データ保存手段が、前記クライアントからダウンロード対象として指定された複数のコンテンツ文書の実体データを取得し、当該指定された複数のコンテンツ文書の中に同名のコンテンツ文書がある場合は、当該取得した複数のコンテンツ文書それぞれの実体データを、アーカイブファイル内に作成した異なるフォルダに保存する実データ保存工程と、
   前記文書管理サーバのアーカイブ情報ファイル保存手段が、前記ダウンロード対象として指定された複数のコンテンツ文書それぞれの前記文書管理サーバにおけるパス情報と前記アーカイブファイル内におけるパス情報とを関連付けて記述した情報ファイルを作成し、当該作成した情報ファイルを前記アーカイブファイル内に保存するアーカイブ情報ファイル保存工程と、
   前記文書管理サーバの送信手段が、前記複数のコンテンツ文書それぞれの実体データと前記情報ファイルとを保存した前記アーカイブファイルを、前記クライアントに送信する送信工程と、
   を有することを特徴とする文書管理方法。
9. コンピュータを、請求項１乃至７のいずれか１項に記載の文書管理サーバが有する各手段として機能させるためのプログラム。
10. 請求項９に記載のプログラムを格納した、コンピュータ読み取り可能な記憶媒体。

Images