(57)【要約】【課題】  入力されたファイルを格納し、管理する情報処理装置において、利便性の高いファイル管理技術を提供することを目的とする。【解決手段】  入力されたファイルを格納し、管理する情報処理装置における情報処理方法であって、ファイルを格納する際に、識別子を生成する工程（ステップＳ４０２）と、前記識別子に基づくファイル名によりファイルを格納する工程（ステップＳ４０６）と、ファイル情報（ファイルＩＤ、元ファイル名、格納先）を保持する工程（ステップＳ４０７）と、を備え、ファイルを格納する際に、該ファイルのファイル名と同一のファイル名が前記ファイル情報内に存在していた場合には、ファイル更新するか別ファイル保存するかを判断し、ファイル更新すると判断した場合には、前記ファイル情報から該当部分を削除するとともに、該格納されたファイルを削除することを特徴とする。【選択図】  図４
2006323783.tif 000002
【特許請求の範囲】
【請求項１】
入力されたファイルを格納し、管理する情報処理装置であって、
ファイルを格納する際に、該ファイルを識別するための識別子を生成する生成手段と、
前記生成手段により生成された識別子に基づくファイル名により、または前記生成手段により生成された識別子に基づく格納先にファイルを格納する格納手段と、
ファイルを格納する際に前記生成手段により生成された識別子と、該ファイルの元のファイル名と、該ファイルの格納先との対応関係を第１のテーブルに記述する第１の記述手段と、を備え、
ファイルを格納する際に、該ファイルの元のファイル名と同一のファイル名が、前記第１のテーブル内に既に存在するか否かを判断し、
存在すると判断された場合に、前記同一のファイル名に対応するファイルを更新するか、前記同一のファイル名に対応するファイルとは別ファイル名で格納するかについての指示を受け付け、
更新する旨の指示を受け付けた場合に、前記同一のファイル名に対応するファイルについての前記対応関係を前記第１のテーブルから削除するとともに、該ファイルを前記格納手段より削除する
ことを特徴とする情報処理装置。
【請求項２】
入力されたファイルを格納し、管理する情報処理装置であって、
ファイルを格納する際に、該ファイルを識別するための識別子を生成する生成手段と、
前記生成手段により生成された識別子に基づくファイル名により、または前記生成手段により生成された識別子に基づく格納先にファイルを格納する格納手段と、
ファイルを格納する際に前記生成手段により生成された識別子と、該ファイルの元のファイル名と、該ファイルの格納先との対応関係を第１のテーブルに記述する第１の記述手段と、を備え、
ファイルを格納する際に、該ファイルの元のファイル名と同一のファイル名が、前記第１のテーブル内に既に存在するか否かを判断し、
存在すると判断された場合に、前記同一のファイル名に対応するファイルを更新するか、前記同一のファイル名に対応するファイルとは別ファイル名で格納するかについての指示を受け付け、
更新する旨の指示を受け付けた場合に、前記同一のファイル名に対応するファイルについての前記対応関係に、該対応関係を前記第１のテーブルから削除したことを表わすフラグを付加するとともに、更新されたことを示す識別子を付加する
ことを特徴とする情報処理装置。
【請求項３】
ファイルを格納する際に前記生成手段により生成された識別子と、該ファイルの内容に関連するデータの識別子との対応関係を第２のテーブルに記述する第２の記述手段を更に備え、
前記更新する旨の指示を受け付けた場合に、前記格納手段に既に格納されたファイルについての前記対応関係を前記第２のテーブルから削除することを特徴とする請求項１に記載の情報処理装置。
【請求項４】
入力されたファイルを格納し、管理する情報処理装置における情報処理方法であって、
ファイルを格納する際に、該ファイルを識別するための識別子を生成する生成工程と、
前記生成工程により生成された識別子に基づくファイル名により、または前記生成工程により生成された識別子に基づく格納先にファイルを格納する格納工程と、
ファイルを格納する際に前記生成工程により生成された識別子と、該ファイルの元のファイル名と、該ファイルの格納先との対応関係を第１のテーブルに記述する第１の記述工程と、を備え、
ファイルを格納する際に、該ファイルの元のファイル名と同一のファイル名が、前記第１のテーブル内に既に存在するか否かを判断し、
存在すると判断された場合に、前記同一のファイル名に対応するファイルを更新するか、前記同一のファイル名に対応するファイルとは別ファイル名で格納するかについての指示を受け付け、
更新する旨の指示を受け付けた場合に、前記同一のファイル名に対応するファイルについての前記対応関係を前記第１のテーブルから削除するとともに、該ファイルを削除する
ことを特徴とする情報処理方法。
【請求項５】
入力されたファイルを格納し、管理する情報処理装置における情報処理方法であって、
ファイルを格納する際に、該ファイルを識別するための識別子を生成する生成工程と、
前記生成工程により生成された識別子に基づくファイル名により、または前記生成工程により生成された識別子に基づく格納先にファイルを格納する格納工程と、
ファイルを格納する際に前記生成工程により生成された識別子と、該ファイルの元のファイル名と、該ファイルの格納先との対応関係を第１のテーブルに記述する第１の記述工程と、を備え、
ファイルを格納する際に、該ファイルの元のファイル名と同一のファイル名が、前記第１のテーブル内に既に存在するか否かを判断し、
存在すると判断された場合に、前記同一のファイル名に対応するファイルを更新するか、前記同一のファイル名に対応するファイルとは別ファイル名で格納するかについての指示を受け付け、
更新する旨の指示を受け付けた場合に、前記同一のファイル名に対応するファイルについての前記対応関係に、該対応関係を前記第１のテーブルから削除したことを表わすフラグを付加するとともに、更新されたことを示す識別子を付加する
ことを特徴とする情報処理方法。
【請求項６】
ファイルを格納する際に前記生成工程により生成された識別子と、該ファイルの内容に関連するデータの識別子との対応関係を第２のテーブルに記述する第２の記述工程を更に備え、
前記更新する旨の指示を受け付けた場合に、前記格納工程により既に格納されたファイルについての前記対応関係を前記第２のテーブルから削除することを特徴とする請求項４に記載の情報処理方法。
【請求項７】
請求項４乃至６のいずれかに記載の情報処理方法をコンピュータによって実現させるための制御プログラムを格納した記憶媒体。
【請求項８】
請求項４乃至６のいずれかに記載の情報処理方法をコンピュータによって実現させるための制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、入力されたファイルを格納し、管理する情報処理装置におけるファイル管理技術に関するものである。
【背景技術】
【０００２】
近年、クライアントサーバシステムにおけるＷｅｂサーバでは、各クライアントからファイルやテキスト等の情報を入力された場合（アップロードされた場合も含む）に、当該情報を検索用の付加情報と関連付けて保持するよう構成されている。これにより、各クライアントでは、必要に応じて当該付加情報等を用いて検索を行い、所望の情報のダウンロードや加工出力等を行うことができるようになっている。
【０００３】
このような構成を備えるＷｅｂサーバでは、一般に、クライアントからＷｅｂサーバにアップロードされるファイルと同一のファイル名を有するファイルが既にＷｅｂサーバ内に存在していた場合、１）既存ファイルの更新処理を行う（重複ファイル名不許可のケース）、２）別ファイルとしての新規登録処理を行う（重複ファイル名許可のケース）、のいずれかの方法を用いて当該ファイルを管理することとしている。
【特許文献１】特開平１０−０２１１３０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記従来のクライアントサーバシステムの場合、同一ファイル名のファイルを管理するにあたり、上記２通りの管理方法のいずれかをシステム単位で固定しなければならなかった。このため、上記２通りの管理方法を実現するには、２つのシステムを構築する必要があり、システム構築者にとって利便性が悪いという問題があった。
【０００５】
また、上記２通りの管理方法のうち、１）の既存ファイルの更新処理の場合、ファイル自体は自動更新されるが、当該ファイルに関連付けて保持された付加情報との間の関連付け情報（通常、テキストデータとして管理されている）については、ファイルの更新登録後に再設定しなければならず、ユーザにとって利便性が悪いという問題もあった。
【０００６】
さらに、上記１）の既存ファイルの更新処理の場合、既存ファイルは削除されてしまうため、誤って更新してしまった場合に、復旧に手間がかかるという問題もある。
【０００７】
本発明は、上記の問題に鑑みてなされたものであり、入力されたファイルを格納し、管理する情報処理装置において、システム構築者ならびにユーザにとって利便性の高いファイル管理技術を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記の目的を達成するために本発明に係る情報処理装置は以下のような構成を備える。即ち、
入力されたファイルを格納し、管理する情報処理装置であって、
ファイルを格納する際に、該ファイルを識別するための識別子を生成する生成手段と、
前記生成手段により生成された識別子に基づくファイル名により、または前記生成手段により生成された識別子に基づく格納先にファイルを格納する格納手段と、
ファイルを格納する際に前記生成手段により生成された識別子と、該ファイルの元のファイル名と、該ファイルの格納先との対応関係を第１のテーブルに記述する第１の記述手段と、を備え、
ファイルを格納する際に、該ファイルの元のファイル名と同一のファイル名が、前記第１のテーブル内に既に存在するか否かを判断し、
存在すると判断された場合に、前記同一のファイル名に対応するファイルを更新するか、前記同一のファイル名に対応するファイルとは別ファイル名で格納するかについての指示を受け付け、
更新する旨の指示を受け付けた場合に、前記同一のファイル名に対応するファイルについての前記対応関係を前記第１のテーブルから削除するとともに、該ファイルを前記格納手段より削除することを特徴とする。
【発明の効果】
【０００９】
本発明によれば、入力されたファイルを格納し、管理する情報処理装置において、システム構築者ならびにユーザにとって利便性の高いファイル管理技術を提供することが可能となる。
【発明を実施するための最良の形態】
【００１０】
以下に、本発明の実施の形態について図面を参照しながら説明する。
【００１１】
［第１の実施形態］
＜クライアントサーバシステムの構成＞
図１は本発明の第１の実施形態にかかるＷｅｂサーバ（情報処理装置）と複数のクライアントとを備えるクライアントサーバシステムの構成を示す図である。各クライアントはＷｅｂブラウザを有し、Ｗｅｂサーバに対して指示／操作を行うことができる。
【００１２】
具体的に説明すると、１０１はローカルエリアネットワーク（ＬＡＮ）であり、クライアントとして機能するクライアント用パーソナルコンピュータ（以下「クライアントＰＣ」）１１１、１１２、１１３と、ファイルの管理を行うＷｅｂサーバとして機能するサーバ用パーソナルコンピュータ（以下「サーバＰＣ」）１２１とが、それぞれ当該ＬＡＮ１０１に接続されている。
【００１３】
また、Ｗｅｂサーバとして機能するサーバＰＣ１２１は、クライアントＰＣ１１１、１１２、１１３のＷｅｂブラウザを経由して受信した各種指示に基づいて処理を行い、処理結果を当該指示をしたクライアントＰＣのＷｅｂブラウザに返信する。但し、本実施形態においては、サーバＰＣ１２１とクライアントＰＣ１１１乃至１１３との間の通信手法については特に限定するものではない。また、サーバＰＣ１２１において、直接各種指示を与え、処理を行う形態であっても構わないものとする。
【００１４】
クライアントＰＣ１１１、１１２、１１３内の構成は、ＬＡＮ１０１に接続でき、かつＷｅｂブラウザが動作するのに必要な機能を有する一般的なパーソナルコンピュータであれば、特に限定するものではないため、ここでは説明を省略する。
【００１５】
＜サーバＰＣ１２１のハードウェア構成＞
図２は、本発明の第１の実施形態にかかるサーバＰＣ１２１のハードウェア構成を示す図である。同図において、２０１はビデオＲＡＭ（ＶＲＡＭ）で、ＣＲＴ２０２の画面に表示される文字、イメージを展開記憶する。２０３はビットムーブユニット（ＢＭＵ）で、メモリ間あるいはメモリと各ユニット間のデータ転送をコントロールする。
【００１６】
２０４は入力に関する各種キーを備えたキーボード（ＫｅｙＢｏａｒｄ）であり、２０５は画面上でアイコンなどを指し示すためなどに用いられるポインティングデバイス（ＰＤ）である。２０６はＣＰＵで、２０８のＲＯＭに記憶された制御プログラム（エラー処理プログラムや、後述する本発明の各実施形態を実現するためのプログラム）に基づいてサーバＰＣ１２１の各ユニットを制御する。また、２０９はＲＯＭ２０８に記載された各プログラムをＣＰＵ２０６が実行するときにワークエリア、エラー処理時の一時退避エリアとして用いられるＲＡＭである。
【００１７】
さらに、２１０はハードディスクドライブ（ＨＤＤ）、２１１はフロッピ（登録商標）ディスクドライブ（ＦＤＤ）をそれぞれ示し、各ディスクは後述するアプリケーションプログラムやデータ、データベース、ライブラリなどの保存用に用いられる。また、クライアントＰＣ１１１乃至１１３よりアップロードされたファイルの保存にも用いられるものとする。
【００１８】
２１２はネットワークインターフェイス（Ｎｅｔ−Ｉ／Ｆ）であり、クライアントＰＣ１１１、１１２、１１３との間でＬＡＮ１０１を経由してデータ転送を行う際に、ネットワーク上でデータの制御および診断を行う。２０７は上述した各ユニット間を接続するＩ／Ｏバス（アドレスバス、データバス及び制御バスからなる）である。
【００１９】
上記ハードウェア構成において、サーバＰＣ１２１に電源が投入されると、ＣＰＵ２０６はＲＯＭ２０８のブートプログラムに従ってサーバＰＣ１２１を初期化し、ＨＤＤ２１０よりＯＳのロードを行い、その後に各種アプリケーション等を動作させることになる。
【００２０】
なお、本実施形態にかかるサーバＰＣ１２１は、凡用の情報処理装置（パーソナルコンピュータ等）をその基礎としているので、プログラムはハードディスク２１０等に記憶されているものとしたが、もちろんＲＯＭ２０８に記憶させるようにしてもよいし、記憶媒体によって本発明が限定されるものではない。
【００２１】
また、本実施形態では、データベース及びファイルの管理を行うＷｅｂサーバとして機能するサーバＰＣを１つ配する構成としているが、データベースサーバやファイル共有サーバのようにそれぞれ別の情報処理装置を用いて実現してもよく、特に本発明が限定されるものではない。
【００２２】
＜サーバＰＣ１２１にて保存されるデータベース情報＞
次に図３を用いて、サーバＰＣ１２１にて保存されるデータベース情報の概要について説明する。当該データベース情報は、サーバＰＣ１２１がファイルの管理を行うＷｅｂサーバとして機能するための基本となるデータベース情報である。
【００２３】
図３において、テーブル３０１は「ファイル」情報を格納するテーブルである。ファイルを識別するファイルＩＤと、ファイルの拡張子と、クライアントＰＣよりアップロードした際の元ファイル名（サーバＰＣ１２１側にアップロードすると、ファイルＩＤ＋拡張子としてファイル名を変換して保持するため、元ファイル名を保持する）、サーバＰＣ１２１で格納しているファイルのパス名を保持する。
【００２４】
なお、ファイル自体はデータベースには格納せず、サーバＰＣ１２１内の指定したフォルダにファイル単位で別フォルダを作成して格納するものとする。具体的に説明すると、例えば、ファイルＩＤ＝１のファイルは、元ファイル名が「ｒｅａｄｍｅ．ｔｘｔ」であり、サーバＰＣ１２１ではファイル名を「１．ｔｘｔ」（ファイルＩＤに対応するファイル名）としてフォルダ「ｃ：￥ｆｉｌｅｄａｔａ￥００￥０１」（ファイルＩＤに対応する格納先）に格納している。
【００２５】
同様に、ファイルＩＤ＝２のファイルは、元ファイル名が「図．ｂｍｐ」であり、サーバＰＣ１２１ではファイル名を「２．ｂｍｐ」として「ｃ：￥ｆｉｌｅｄａｔａ￥００￥０２」に格納している。ファイルＩＤ＝３、４、５のファイルも同様である。
【００２６】
なお、フォルダが階層化されているのにも関わらず、一意に識別可能なファイル名で管理しているのは、出力時の加工処理等で同じファイル名が指定された場合でも、問題なく処理を行うことができることを考慮しているためである。但し、ファイル名及びフォルダの構成等については一意に識別可能であれば、特にこれに限定するものではない。
【００２７】
このように、本実施形態にかかるサーバＰＣ１２１では、アップロードされたファイルを格納するにあたり、すべてのファイルに対して個別の識別子を発行するとともに、当該識別子に基づくファイル名で当該識別子に基づく名称のフォルダに別個に格納する点に特徴がある。また、元のファイル名と、当該発行された識別子と、当該ファイルの格納先との対応関係をファイルテーブル３０１にファイルを格納する際に逐次追加していく点に特徴がある。
【００２８】
このような構成を備えることにより、アップロード指示されたファイル名と同じファイル名のファイルが既に格納されていた場合であっても、後述する更新処理を行うか別ファイル名にて格納するかに関わらず、当該アップロード指示されたファイルを格納する処理と、ファイルテーブル３０１に追加していく処理に関しては、同じように実施されることとなる（後述するように、更新処理を行うか別ファイル名にて格納するかは、ファイルテーブル３０１の所定の行の削除と格納されたファイルの削除とを行うか、そのまま残しておくかの違いだけである）。
【００２９】
つまり、更新処理を行う場合と別ファイル名で格納する場合との２つのシステムを構築する必要がなくなり、同一システムで更新処理と別ファイル名による格納とが実現できるようになり、システム構築者にとっては利便性が向上することとなる。
【００３０】
また、同一システムで更新処理と別ファイル名による格納を行うことができることから、アップロード指示を行うユーザにとっても利便性が向上することとなる。
【００３１】
＜サーバＰＣ１２１における処理の流れ＞
次に図４を用いて本実施形態にかかるサーバＰＣ１２１における、アップロード指示されたファイルと同一ファイル名のファイルが既に格納済みであった場合の処理の流れについて説明する。
【００３２】
図４に示すように、クライアントＰＣ１１１乃至１１３よりアップロード指示を受信すると、まずステップＳ４０１では、クライアントＰＣ１１１乃至１１３からアップロード指示されたファイル名と同じファイル名のファイルが既に格納されているか否かを、図３のファイルテーブル３０１に基づいて検索する。
【００３３】
既に存在すると判断された場合にはステップＳ４０２に進む。一方、存在しないと判断された場合には、ステップＳ４０８に進む。
【００３４】
ステップＳ４０２では、同一ファイル名のファイルがあるため、同一ファイルに対して更新処理を行うか、別ファイル名で格納するかをクライアントＰＣ１１１乃至１１３からの指示に基づいて判断する。更新処理を行うと判断した場合にはステップＳ４０３に進む。一方、別ファイルとして新規登録すると判断した場合にはステップＳ４０８に進む。なお、上記指示はファイル単位にクライアントＰＣ１１１乃至１１３から受けるものであっても、あらかじめ設定ファイル等に保持されていてもよく、いずれの指示であるかが確認できれば、特にこれに限定するものではない。
【００３５】
次にステップＳ４０３では、アップロードされるファイルに対して一意に識別可能なファイルＩＤを発行する。そしてステップＳ４０４では、既存の同一ファイル名に対応するファイルの削除処理を行う。
【００３６】
ステップＳ４０５では、ステップＳ４０３で発行されたファイルＩＤを用いてアップロードされたファイルのファイル名を変更する。ステップＳ４０６ではファイル名を変更したファイルを、指定のフォルダに保存する。ステップＳ４０７では、元ファイル名やステップＳ４０６で指定した保存先フォルダの情報を含めてファイルテーブル３０１に登録を行い（あわせて既存の同一ファイル名に対応するファイルについての情報をファイルテーブル３０１から削除し）、処理を終了する。
【００３７】
なお、ステップＳ４０１及び４０２の分岐先となる、ステップＳ４０８では、ステップＳ４０３と同様にアップロード指示されたファイルのファイルＩＤを発行して、ステップＳ４０５に進むこととなる。ただし、この場合、ステップＳ４０７において既存の同一ファイル名に対応するファイルについての情報がファイルテーブル３０１から削除されることはない。
【００３８】
＜更新処理後のデータベース情報＞
図５は、図３で示したファイルテーブル例に対して、図．ｂｍｐというファイルをアップロード指示した時に、更新処理がされた場合のファイルテーブルの更新内容を示した一例である。
【００３９】
ファイルテーブル５０１においては２行目の既存ファイルである「図．ｂｍｐ」を削除して、新たにファイルＩＤが６のデータとして「図．ｂｍｐ」が更新処理されたことを示している。
【００４０】
以上の説明から明らかなように、本実施形態にかかるサーバＰＣによれば、アップロードされたファイルを管理するにあたり、クライアントからサーバＰＣにアップロードされたファイルと同一ファイル名に対応するファイルが既にサーバＰＣ上に存在していた場合でも、既存のファイルを更新処理するか、別ファイル名として格納するかを選択することが可能となり、システム構築者ならびにユーザの利便性が向上する。
【００４１】
［第２の実施形態］
上記第１の実施形態では、アップロードされたファイルを管理するにあたり、当該ファイルに関連付けて保持された付加情報（テキストデータ）がない場合について説明したが、本発明は特にこれに限られず、当該ファイルに関連づけて保持された付加情報があった場合でも適用可能である。以下に詳細を説明する。
【００４２】
＜サーバＰＣ１２１にて保存されるデータベース情報＞
次に図６、図７を用いて、本実施形態にかかるサーバＰＣ１２１にて保存されるデータベース情報の概要について説明する。当該データベース情報は、サーバＰＣ１２１がテキストデータ及びファイルの管理を行うＷｅｂサーバとして機能するための基本となるデータベース情報である。
【００４３】
図６に示す各テーブル（６０１〜６０４）はデータベース内に格納されるデータ構造体とテキストデータとの関係を示している。まず、６０１はデータ構造体を格納するテーブルであり、ここでは「ＬＢＰ」と「複写機」と「カメラ」という３種類の構造体がそれぞれ「ＬＢＰ」、「ＭＦＰ」、「ＣＡＭＥＲＡ」というＩＤにて定義されている。
【００４４】
６０２はデータ構造体の各項目を格納するテーブルであり、構造体ＩＤが「ＬＢＰ」である「ＬＢＰ」構造体は、項目ＩＤがそれぞれ「ＰＲＯＤＵＣＴ」、「ＰＲＩＣＥ」、「ＣＯＤＥ」で識別される「製品名」と「価格」と「製品コード」を項目名称として定義している。同様に「複写機」構造体は「製品名」と「製品コード」、「カメラ」は「製品名」と「価格」をそれぞれ項目名称として定義している。なお、データ構造体は、テーブル６０１と６０２において定義されたものである。
【００４５】
６０３は、各テキストデータがどのデータ構造体を用いて格納されているかを示したテーブルである。同テーブルに示すように、データＩＤが１のテキストデータは、「複写機」の構造体に情報を格納する。同様にデータＩＤが２のテキストデータは「ＬＢＰ」のデータ構造体に、データＩＤが３のテキストデータは「カメラ」のデータ構造体をそれぞれ情報を格納する。
【００４６】
６０４は、各テキストデータの実際のデータ値を格納するテーブルである。データＩＤが１のテキストデータは、テーブル６０３に示すように、「複写機」のデータ構造体を使用しているため、項目として「製品名」と「製品コード」が格納可能であり、さらに「製品名」には「ｉＲ  ＸＸＸＸ」が格納され、「製品コード」には、「１２３４５６７」が格納される。
【００４７】
同様に、データＩＤが２のテキストデータは「ＬＢＰ」のデータ構造体を使用しているため、「製品名」として「ＬＢＰ−ＹＹＹＹ」が、「価格」として「１２３，４５０」（円）が、「製品コード」として「２２２２２２２」がそれぞれ格納されている。さらにデータＩＤが３のテキストデータは「カメラ」のデータ構造体を使用しているため、「製品名」として「ＩＸＹ  ＺＺＺＺ」が、「価格」として「１２，３４５」（円）がそれぞれ格納されている。
【００４８】
以上がユーザが編集することによって格納されるデータ構造体とテキストデータとの関係を示すテーブルである。
【００４９】
次に図７を用いてファイルとテキストデータとの関連付けを管理するためのテーブルについて説明する。
【００５０】
図７において、テーブル７０１は「ファイル」情報を格納するテーブルである（上記第１の実施形態における図３の３０１と同じ）。ファイルを識別するファイルＩＤと、ファイルの拡張子と、クライアントＰＣよりアップロードした際の元ファイル名（サーバＰＣ１２１側にアップロードすると、ファイルＩＤ＋拡張子としてファイル名を変換して保持するため、元ファイル名を保持する）、サーバＰＣ１２１で格納しているファイルのパス名を保持する。
【００５１】
なお、ファイル自体はデータベースには格納せず、サーバＰＣ１２１内の指定したフォルダにファイル単位で別フォルダを作成して格納するものとする。具体的に説明すると、例えば、ファイルＩＤの１は、元ファイル名が「ｒｅａｄｍｅ．ｔｘｔ」であり、サーバＰＣ１２１ではファイル名を「１．ｔｘｔ」としてフォルダ「ｃ：￥ｆｉｌｅｄａｔａ￥００￥０１」に格納している。同様に、ファイルＩＤの２は、元ファイル名が「図．ｂｍｐ」であり、サーバＰＣ１２１ではファイル名を「２．ｂｍｐ」として「ｃ：￥ｆｉｌｅｄａｔａ￥００￥０２」に格納している。ファイルＩＤの３、４、５も同様である。
【００５２】
なお、フォルダが階層化されているのにも関わらず、一意に識別可能なファイル名で管理しているのは、出力時の加工処理等で同じファイル名が指定された場合でも、問題なく処理を行うことができることを考慮しているためである。但し、ファイル名及びフォルダの構成等については一意に識別可能であれば、特にこれに限定するものではない。
【００５３】
７０２はテキストデータとファイルを関連付けるための関連付けキーを管理するテーブルである。本実施形態では関連付けＩＤが「ＲＥＡＤＭＥ」である「資料」という関連付けキーと、関連付けＩＤが「ＩＭＡＧＥ」である「イメージ」という関連付けキーが格納されている。
【００５４】
７０３はテーブル７０２に格納されている関連付けキーを用いて、テキストデータとファイルの関連付けの情報を格納するテーブルである。例えば、データＩＤが１のテキストデータは、「資料」という関連付けキーを用いてファイルＩＤが１である「Ｒｅａｄｍｅ．ｔｘｔ」という元ファイル名のファイルを関連付けている。また、データＩＤが１のテキストデータは、「イメージ」という関連付けキーを用いてファイルＩＤの２（図．ｂｍｐ）と３（概観．ｊｐｇ）をそれぞれ関連付けている。
【００５５】
なおデフォルトは、同じデータＩＤと関連付けキーの組み合わせにおいて、複数のファイルが関連付けてある場合には、代表ファイルとして指定される（１つしかない場合は必ずデフォルトとなる）。同様にデータＩＤが２のテキストデータは、「資料」に「ｒｅａｄｍｅ．ｔｘｔ」と「イメージ」に「画像．ｊｐｇ」が関連付けられており、データＩＤが３のテキストデータは、「資料」に「ｒｅａｄｍｅ．ｔｘｔ」と「ｒｅａｄｍｅ２．ｔｘｔ」の２つのファイルが関連付けられている。
【００５６】
なお、本実施形態に記載するテーブルの項目は、最小限のものを記載しているが、例えば更新日付や、更新ユーザ等の項目がさらに付加されていてもよく、特にこれに限定するものではない。
【００５７】
＜テキストデータとファイルとの関係＞
図８は、図６および図７に示す各テーブルの情報を図示したものである。左からテキストデータ、関連付けキー、ファイルと分類しており、例えば、データＩＤ＝１のデータは、データ構造体が「複写機」であり、「製品名」と「製品コード」の各項目データを有するテキストデータである。データＩＤ＝２は、データ構造体が「ＬＢＰ」であり、「製品名」と「価格」と「製品コード」の各項目データを有するテキストデータである。またデータＩＤ＝３はデータ構造体が「カメラ」であり、「製品名」と「価格」の各項目データを有するテキストデータである。
【００５８】
またデータＩＤ＝１のテキストデータは、関連付けキーが「資料」と「イメージ」を用いており、「資料」には「ｒｅａｄｍｅ．ｔｘｔ」が、「イメージ」には、「図．ｂｍｐ」と「概観．ｊｐｇ」がそれぞれ関連付けられていることを示している。他のテキストデータも同様に図６と図７で示したテーブルを図示したものとなっていることが確認できる。
【００５９】
＜サーバＰＣ１２１における処理の流れ＞
次に図９を用いて本実施形態にかかるサーバＰＣ１２１における、アップロード指示されたファイルと同一ファイル名のファイルが既に格納済みであった場合の処理の流れについて説明する。
【００６０】
図９に示すように、クライアントＰＣ１１１乃至１１３よりアップロード指示を受信すると、まずステップＳ９０１では、クライアントＰＣ１１１乃至１１３からアップロード指示されたファイル名と同じファイル名のファイルが既に格納されているか否かを、図７のファイルテーブル７０１に基づいて検索する。既に存在すると判断された場合にはステップＳ９０２に進む。一方、存在しないと判断された場合には、ステップＳ９０８に進む。
【００６１】
ステップＳ９０２では、同一ファイル名のファイルがあるため、同一ファイルに対して更新処理を行うか、別ファイル名で格納するかをクライアントＰＣ１１１乃至１１３からの指示に基づいて判断する。更新処理を行うと判断した場合にはステップＳ９０３に進む。一方、別ファイル名で格納すると判断した場合にはステップＳ９０８に進む。なお、上記指示はファイル単位にクライアントＰＣ１１１乃至１１３から受けるものであっても、あらかじめ設定ファイル等に保持されていてもよく、いずれの指示であるかが確認できれば、特にこれに限定するものではない。
【００６２】
次にステップＳ９０３では、アップロードされるファイルに対して一意に識別可能なファイルＩＤを発行する。そしてステップＳ９０４では、既存の同一ファイル名に対応するファイルの削除処理を行うとともに、前記ステップＳ９０３で発行されたファイルＩＤを用いて、既存ファイルが関連付けられていた関連付けテーブル７０３の更新を行う。
【００６３】
ステップＳ９０５では、ステップＳ９０３で発行されたファイルＩＤを用いてアップロードされたファイルのファイル名を変更する。ステップＳ９０６ではファイル名を変更したファイルを、指定のフォルダに保存する。ステップＳ９０７では、元ファイル名やステップＳ９０６で指定した保存先フォルダの情報を含めてファイルテーブル７０１に登録を行い（あわせて既存の同一ファイル名に対応するファイルについての情報をファイルテーブル７０１から削除し）、処理を終了する。
【００６４】
なお、ステップＳ９０１及び９０２の分岐先となる、ステップＳ９０８では、ステップＳ９０３と同様にアップロード指示されたファイルのファイルＩＤを発行して、ステップＳ９０５に進むこととなる。ただし、この場合、ステップＳ９０７において、既存の同一ファイル名に対応するファイルについての情報がファイルテーブル７０１から削除されることはない。
【００６５】
＜更新処理後のデータベース情報＞
図１０は、図７で示したテーブル例に対して、図．ｂｍｐというファイルをアップロード指示した時に、更新処理がされた場合の各テーブルの更新内容を示した一例である。
【００６６】
テーブル１００１においては２行目の既存ファイルである「図．ｂｍｐ」を削除して、新たにファイルＩＤ＝６のファイルとして「図．ｂｍｐ」が更新登録されたことを示している。
【００６７】
またファイルテーブル１００３は、上記の更新登録に伴い、既存の「図．ｂｍｐ」が関連付けられていた、２行目のデータが削除され、最終行に改めてファイルＩＤ＝６のファイルとの関連付けとして更新追加されたことを示している。
【００６８】
以上の説明から明らかなように、本実施形態によれば、クライアントＰＣからサーバＰＣへのファイルのアップロードに際して、当該ファイルに付加情報（テキストデータ）があった場合でも、上記第１の実施形態と同様の効果を享受しつつ、さらに、関連付けテーブルを含めたファイル管理を実現することが可能となる。
【００６９】
［第３の実施形態］
図１１Ａ、１１Ｂおよび図１２を用いて、本発明の第３の実施形態について説明する。本実施形態では、ファイルのアップロードに際して、入力ファイルをページ単位に分割したり、圧縮ファイルにあっては解凍処理を行ったりする場合の処理について説明する。
【００７０】
＜サーバＰＣ１２１に保存されるデータベース情報＞
図１１Ａ、図１１Ｂは入力ファイルをページ単位に分割して登録する場合の処理を説明するための図である。同図において、１１０１はアップロード前の「カタログ．ｄｏｃ」というファイル名のファイルであり、３ページから構成されている。アップロードされると、１１０２で示したファイルＩＤと拡張子で構成されるファイル名「１．ｄｏｃ」に変換される。さらに分割処理を行うため、１１０３で示した「２．ｄｏｃ」「３．ｄｏｃ」「４．ｄｏｃ」にそれぞれ各ページが分割されて格納される。
【００７１】
１１０１は、上記のファイル１１０２及びファイル１１０３の格納先を示すファイルテーブルの一例である。各ファイルは、ファイルＩＤとファイルパスとにより格納先が特定される。
【００７２】
１１０２は、関連付けキーのテーブルの一例であり、関連付けＩＤが「ＯＲＩＧＩＮＡＬ」と「ＤＩＶＩＤＥ」で識別される「親ファイル」と「分割ページ」が定義されている。
【００７３】
１１０３は、関連づけキーテーブル１１０２に示す関連付けキーを用いて、データＩＤが１のテキストデータに対して、「親ファイル」の関連付けキーとして、「カタログ．ｄｏｃ」が設定されており、一方「分割ページ」の関連付けキーとして「カタログ＿００００１．ｄｏｃ」「カタログ＿００００２．ｄｏｃ」「カタログ＿００００３．ｄｏｃ」の各ページ分割ファイルが設定されている。
【００７４】
なお、テーブル１１０４は、入力加工の際にページ分割されたファイルを階層化情報として保持する「ファイル階層」テーブルである。ファイルＩＤの２、３、４はそれぞれ親ファイル＝１の階層化のファイルとして登録されている。
【００７５】
＜テキストデータとファイルとの関係＞
図１２は、図１１Ａ、１１Ｂに示す各テーブルで示した関連付け情報を図示したものである。データＩＤ＝１のテキストデータが、「親ファイル」と「分割ページ」という関連付けキーを有し、それぞれ各ファイルが関連付けられていることが示されている。
【００７６】
＜更新処理後のデータベース情報＞
図１３は、図１１Ｂに示すテーブル状態に対して、さらにクライアントＰＣ１１１乃至１１３から「カタログ．ｄｏｃ」という４ページからなるファイルがアップロードされ、「更新処理」が指示された場合の各テーブルの更新内容の一例である。テーブル１３０１は更新処理後のファイルテーブルであり、入力加工としてページ分割された各ファイルに対しても同一ファイル名のものは更新処理を行っているため、１〜４行目のファイル情報が削除され、新しく５〜９行のファイル情報が追加されている。なお、ファイルＩＤ＝９のファイルは、既存のものではないため、登録処理だけを行うものとなる。
【００７７】
テーブル１３０３は、更新処理後の関連付けテーブルである。同テーブルに示すように、削除された１〜４のファイルＩＤに対応するファイルが削除されるとともに、ファイルＩＤが５〜８の同一ファイル名であるファイルにて関連付けの置き換えが行われる。
【００７８】
なお、テーブル１００４は、入力加工時の親子関係を示す更新処理後の「ファイル階層」テーブルである。同テーブルに示すように、ファイルＩＤが１の親ファイルが削除された時点で下階層に位置するファイルＩＤの２、３、４の情報が削除され、ファイルＩＤが５を親ファイルとするファイルＩＤ６、７、８、９がそれぞれ下階層ファイルとして追加される。
【００７９】
一方、図１４は、図１１Ｂに示すテーブル状態に対して、さらにクライアントＰＣ１１１乃至１１３から「カタログ．ｄｏｃ」という３ページからなるファイルがアップロードされ、「更新処理」が指示された場合の各テーブルの更新内容の一例である。ファイルＩＤが１の「カタログ．ｄｏｃ」は３ページからなるファイルであるため、３ページ目に該当するファイルＩＤが４のファイルは同一ファイル名のアップロードではないが、「ファイル階層」テーブルによって下階層に位置するファイルは、親ファイルが削除されることにより、自動的に削除されることとなる。従って、テーブル１４０１では、１〜４行目のファイルＩＤ１〜４の情報が削除され、ファイルＩＤ５〜７の情報が追加されこととなる。
【００８０】
また、テーブル１１０３の「関連付け」テーブルは、１〜４行目に位置する関連付け情報が削除される。４行目に位置する関連付け情報は、ファイル自体が削除されるので整合性を維持するために自動的に削除されることとなる。また、５〜７行目は、新しく更新処理されたファイルとして登録されることとなる。
【００８１】
さらにファイル階層テーブル１４０４では、２ページからなるファイルのアップロードに対して、ファイルＩＤ６、７が、親ファイルとなるファイルＩＤ＝５のファイルの下階層に配されることとなる。
【００８２】
なお、本実施形態におけるフローチャートは、図６と同様であるため省略する。
【００８３】
以上の説明から明らかなように、本実施形態によれば、クライアントＰＣからサーバＰＣへのファイルのアップロードに際して、当該ファイルを分割して格納したり、圧縮ファイルにあっては解凍処理して格納する場合であっても、上記第１の実施形態と同様の効果を享受しつつ、関連づけテーブルを含めたファイル管理を実現することができる。
【００８４】
［第４の実施形態］
次に図１５を用いて本発明の第４の実施形態について説明する。本実施形態にかかるサーバＰＣは、クライアントＰＣからのアップロード指示のあったファイル名と同一ファイル名に対応するファイルが存在した場合に、更新処理を行うに際して、既存ファイルを削除せずに、重複ファイルの履歴管理を行うように構成されていることを特徴とする。
【００８５】
図１５は、図１１Ｂに示したテーブル状態に対して、さらにクライアントＰＣから「カタログ．ｄｏｃ」という４ページからなるファイルがアップロードされた場合のファイルテーブルの一例を示す図である。なお、図１４に示すファイルテーブルとの相違点は、「削除フラグ」及び、「更新ＩＤ」の項目が追加されているる点である。
【００８６】
この２つの「削除フラグ」及び「更新ＩＤ」を用いることで、ファイル情報をテーブルから削除することなく、重複ファイル名の履歴管理を実現することが可能となる。
【００８７】
ファイルテーブル１５０１内において、「削除フラグ」は前記ファイルテーブル１４０１内で横線によって消されたファイルＩＤ１〜４の情報のように削除されたファイルＩＤに対して付与される。扱いとしては削除ファイルであるが、情報として保持することができる。
【００８８】
また、「更新ＩＤ」は、どのファイルのアップロードが要因で削除処理がなされたかを示したものであり、本実施形態ではファイルＩＤが５である「カタログ．ｄｏｃ」によるアップロードが要因で更新されたことを示している。この２つの情報により、例えば、ファイルＩＤが５の重複ファイル名の履歴を表示したい場合は、更新ＩＤが５となるものを検索することで、１世代前の重複ファイル名のファイルを検出することが可能である。また同様に、１世代前のファイルの更新ＩＤを検索することで、前世代の重複ファイル名を有するファイルを検出することが可能となる。
【００８９】
なお、本実施形態にかかるサーバＰＣにおける処理は、図４のステップＳ４０４の「既存ファイルの削除」処理において、既存ファイル情報を削除するのではなく、かつステップＳ４０７において上記の２項目（削除フラグ、更新ＩＤ）に対して、更新情報を付与することにより実現されるものであり、容易に類推できることからフローチャートについての詳細説明は省略する。
【００９０】
以上の説明から明らかなように、本実施形態によれば、クライアントＰＣからサーバＰＣのファイルのアップロードに際して、同一ファイル名がある場合の処理を「更新」とした場合でも、重複する既存のファイル及びファイル情報を削除することなく、履歴管理を用いたファイル管理を実現することができる。この結果、誤って更新された場合でも、手早く復旧させることが可能となる。
【００９１】
［他の実施形態］
なお、本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。
【００９２】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【００９３】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００９４】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピ（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【００９５】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００９６】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【図面の簡単な説明】
【００９７】
【図１】本発明の第１の実施形態にかかるサーバＰＣ（情報処理装置）と複数のクライアントとを備えるクライアントサーバシステムの構成を示す図である。
【図２】本発明の第１の実施形態にかかるサーバＰＣのハードウェア構成を示す図である。
【図３】本発明の第１の実施形態にかかるサーバＰＣにて保存されるデータベース情報を示す図である。
【図４】本発明の第１の実施形態にかかるサーバＰＣにおいて、アップロード指示されたファイルと同一ファイル名のファイルが既に格納済みであった場合の処理の流れを示すフローチャートである。
【図５】更新処理された場合のファイルテーブルの更新内容の一例を示す図である。
【図６】データベース内に格納されるデータ構造体とテキストデータとの関係を示す図である。
【図７】本発明の第２の実施形態にかかるサーバＰＣにて保存されるデータベース情報（ファイルとテキストデータとの関連付けを管理するためのテーブル）を示す図である。
【図８】図６および図７に示す各テーブルの情報の内容を示した図である。
【図９】本発明の第２の実施形態にかかるサーバＰＣにおいて、アップロード指示されたファイルと同一ファイル名のファイルが既に格納済みであった場合の処理の流れを示すフローチャートである。
【図１０】更新処理がされた場合の各テーブルの更新内容の一例をを示す図である。
【図１１Ａ】入力ファイルをページ単位に分割して格納する場合の処理を説明するための図である。
【図１１Ｂ】入力ファイルをページ単位に分割して格納する場合の、ファイルとテキストデータとの関連付けを管理するためのテーブルを示す図である。
【図１２】図１１Ｂの各テーブルで示した関連付け情報の内容を示した図である。
【図１３】更新処理がされた場合の各テーブルの更新内容の一例を示す図である。
【図１４】更新処理がされた場合の各テーブルの更新内容の一例を示す図である。
【図１５】更新処理がされた場合のファイルテーブルの更新内容の一例を示す図である。
【図１】
2006323783.tif 000003
【図２】
2006323783.tif 000004
【図３】
2006323783.tif 000005
【図４】
2006323783.tif 000006
【図５】
2006323783.tif 000007
【図６】
2006323783.tif 000008
【図７】
2006323783.tif 000009
【図８】
2006323783.tif 000010
【図９】
2006323783.tif 000011
【図１０】
2006323783.tif 000012
【図１１Ａ】
2006323783.tif 000013
【図１１Ｂ】
2006323783.tif 000014
【図１２】
2006323783.tif 000015
【図１３】
2006323783.tif 000016
【図１４】
2006323783.tif 000017
【図１５】
2006323783.tif 000018