JP2006268701A

JP2006268701A - 文書管理システム

Info

Publication number: JP2006268701A
Application number: JP2005088916A
Authority: JP
Inventors: Takashi Mizuno; 貴史水野
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2005-03-25
Filing date: 2005-03-25
Publication date: 2006-10-05

Abstract

【課題】移換え、置換えを有する文書管理システムにおいて、一定期間経過後に文書を長期保存するために、自動的に長期保存用の保管場所へ移動する「置換え」の時に、文書を汎用的なアプリケーションに非依存なフォーマットに自動的に変換を行う。
【解決手段】文書管理システム内の置換え実行時に、文書を自動的に変換する仕組みを持ち、変換方式は、プリンタドライバによってアプリケーションから印刷を実行させることで行い、管理者が各々の文書種別に対して、変換後の文書形式を設定できる仕組みを有し、この設定に従って、置換え時に変換が必要な文書が自動的にフォーマット変換されて長期保存され、また、保存形態としてバインダ文書とすれば、元文書と変換後の文書を同一文書として保持できる。
【選択図】図２

Description

本発明は、電子的な文書管理システムに関するものである。

企業や公官庁のオフィスにおいては、オフィス環境のネットワーク化、デジタル化が進展しつつあり、様々な文書をワードプロセッサソフトウェアや、スプレッドシートソフトウェア、プレゼンテーションソフトウェア等のソフトウェアを利用して、電子文書として保管している。

しかしながら、企業や公官庁においては、例えば、コンピュータディスプレイ上では、文書が読み辛い等の理由からこのような電子文書が印刷されて紙文書として利用されており、依然として紙文書が多く存在している。紙文書の共有や保管、破棄のための管理は、以前より行われており、紙文書の管理方法としては、例えば非特許文献１に示されるようなファイリングシステムが広く用いられている。このファイリングシステムの中で、文書が発生してから、短期保管、長期保存を経て破棄されるまでの一連の文書の流れが重要となる。以下、従来の紙文書に対するファイリングシステムについて、非特許文献１に記載に基づいて説明を行う。

より具体的な例を、図１に示す。

１０１においては、文書の発生を表す。文書とは、例えば、紙などの媒体に記載された手書きの文書や、ワードプロセッサなどのソフトウェアで作成された電子的な文書を印刷した紙などの媒体、あるいは、電子文書の電子データをＣＤ−ＲＯＭなどの記録媒体に記録された媒体であってもよい。１０５に示すように、発生した文書は、キャビネット１０２に保管される。このときに、発生してすぐの文書は利用頻度が高いため、キャビネット１０２でも取り出しの容易な上段（１０２Ａ）に収納される。なお、１０５で文書をキャビネットに移動する際に、キャビネット１０２の容量を有効活用し、文書の探索性の向上を行うために、不要な文書を破棄することを行う（１０９）。

更に、一定期間経過すると、文書の利用頻度が下がるため、多少利用し辛くなっても構わないため、同一キャビネットの中でも、利用が不便な位置に移動される。例えば、図１では、キャビネット１０２内の利用しやすい上段１０２Ａにあった文書が、下段１０２Ｂに移動される（１０６）。このことを「移換え」と言い、文書の短期的な保管の際に用いられる。ここで、「移換え」の際に、先に説明した１０９と同様に、不要な文書の破棄を行う（１１０）。ここで、「移換え」が行われるまでの「一定期間」とは、例えば、年度単位の定型業務を行うような職場の場合には、年度ごとに行ったり、年度で定められないような業務に対しては、例えばプロジェクトの終了単位で行ったり、あるいは、社員の異動の際に行ったりするなど、職場や業務種別の状況に応じて変えてもよい。

「移換え」を行う理由は、文書作成を行う際に、前年度の文書を参考にして、当年度の文書を作成する場合が多いため、このような手法を用いる。このような文書の一例として、例えば、予算申請を行う場合に、前年度のフォーマットや申請理由を参考にして、当年度の記載を行うことがある。

文書の「移換え」が実施された後、更に一定期間経過すると、文書の利用頻度が更に低下するため、紙文書を文書保存箱に格納して、キャビネットから書庫に文書の移動を行う。図１では、キャビネットの下段１０２Ｂから書庫１０３へ文書が移動する（１０７）。この文書の移動１０７のことを「置換え」と呼び、文書を長期的に保存する。ここで、「移換え」の際に、先に説明した１０９、１１０と同様に、不要な文書の破棄を行う（１１１）。「置換え」の時期についても、先の「移換え」の説明と同様に、随時に行う方式と、定期的に行う方式があり、職場や業務種別の状況に応じて変えてもよい。

図１では、「置換え」が実施された文書について、年限を明記していないが、保存年限が決まっている公的な文書などについては、「置換え」時に各年度毎の文書保存箱を用意して、保存してもよい。例えば、書庫１０３において、１０４Ａは、３年保存、１０４Ｂは、５年保存のようにして、年限が来たら、文書保存箱を破棄する（あるいは、保存年限を見直す）ことを行う。

以上、説明してきた内容が紙文書（と電子文書の記録媒体）に対して行われているファイリングシステムの仕組みの一部である。従来は、このような方法を紙文書で行っており、特許文献１では、このような紙文書のファイリングに対して、各紙文書の保存場所や、破棄年限の管理をデータベースを用いて、コンピュータで集中的に管理する方法を提供しているものである。

一方、企業や公官庁では先に説明したように、文書の作成については、ワードプロセッサなどのソフトウェアを用いており、電子文書がオフィス内で用いられる文書の大半を占めるようになってきている。また、紙文書についても、近年はパーソナルスキャナが普及し、また、複写機、プリンタなどにもスキャナ機能が搭載されるようになってきており、オフィス内においても容易に紙文書からスキャンをして、電子的な画像データに変換できるようになってきている。

このような状況の下、企業や公官庁では、文書管理システムを導入し、文書の再利用を推進しようとしている。文書管理システムにおいては、様々な文書をデータベース内に保存し、複数の利用者から共有される形態を取る。文書管理システムでは、文書の実体を表すデータを保持するとともに、前記文書に付随する様々な文書情報も保持している。文書管理システム内で、文書の登録、削除や更新処理を行うことができる。
特開２００２−１６９７０９号公報社団法人日本経営協会著、「改訂版ファイリングデザイナー〜基礎から学ぶトータルファイリングシステム〜」

文書管理システムにおいて、従来の紙文書の利用から、電子文書への移行した際に、紙文書で利用されていたファイリングの手法である「移換え」「置換え」を利用して文書管理（ファイリング）を行いたいと利用者は考えたとしても、電子文書に対して、このような機能を備えた文書管理システムが存在していない。

特に、「置換え」が実施されると、文書は長期保存されることになる。しかしながら、文書フォーマットは、通常アプリケーションに依存しており、長期間の間に当該アプリケーションが動作するオペレーティングシステムが無くなってしまったり、当該文書のフォーマットをサポートしなくなってしまったりすることがあるため、このような場合には文書が長期保存されても文書内容を確認することができないことがあり得る。

本発明は、以上の点に着目して成されたもので、自動的に長期保存用の保管場所へ移動する「置換え」の時に、文書を汎用的なアプリケーションに非依存なフォーマットに自動的に変換を行う文書管理システムを提供することを目的とする。

本発明は、
データ保管するためのデータベースを具備し、前記データベースに文書を登録する手段を具備し、時間を管理するタイマを具備し、前記タイマが一定期間経過すると文書移動を行う移換え・置換え処理手段を具備し、文書フォーマットを変換する文書変換手段を具備する文書管理システムにおいて、前記タイマにより実施される文書の置換え処理において、前記文書変換手段によって前記データベース内の文書を自動的に汎用フォーマットに変換することを特徴とする文書管理システム
であるので、
「置換え」が実施されると、文書は長期保存されることになるが、文書フォーマットは、通常アプリケーションに依存しており、長期間の間に当該アプリケーションが動作するオペレーティングシステムが無くなってしまったり、当該文書のフォーマットをサポートしなくなってしまったりすることがあるため、このような場合には文書が長期保存されても文書内容を確認することができない
ことが解消される。

以下、図面を参照して本発明を説明する。

本発明は、文書管理システムに関する発明である。

図２は、本発明における文書管理システムの構成を表す図である。

２０１は、文書管理サーバであり、データベース２０２を持っている。文書管理サーバ２０１は、文書管理システム内での保管場所や、実文書データの保存場所、作成日、更新日、所有者などの文書属性、ユーザの操作やアクセスを記録しているログをデータベース２０２に保持している。２０３は、文書ボリュームサーバであり、文書の実データが保管される。ここに保管されたデータは、圧縮処理が施され効率的に保管される。

ネットワーク２０４によって、クライアントＰＣ２０５や２０６とサーバ２０１、２０３が接続される。クライアントＰＣ２０５、２０６から、ここには図示していない文書管理クライアントソフトウェアを通じて、サーバに文書データを保管したり、サーバから文書データを取得したりする。

例えば、クライアントＰＣ２０５から文書管理システムに文書データを登録する場合について説明する。クライアントＰＣ２０５上で、文書管理クライアントソフトウェアを起動して、文書管理サーバ２０１と接続する。文書管理システム内のフォルダを指定して、文書データ登録を文書管理クライアントソフトウェアに対して指示を行うと、文書管理サーバ２０１は、フォルダに対するアクセス権があるか、当該文書を格納するだけの容量があるかなど文書登録を許可できるかを判定し、登録できる場合には、当該文書の作成日、更新日、所有者などの属性情報を文書管理サーバ２０１内のデータベース２０２に格納し、当該文書の実データを文書ボリュームサーバ２０３に格納する。

このとき、実文書データの文書ボリュームサーバ２０３の保存場所が、文書管理サーバ２０１に通知され、この情報も保存される。更には、文書登録を行ったと言う記録もログとして保持される。

ここには示していないが、全文検索を行うために登録時にテキストを当該文書から抽出したり、文書の縮小画像を表示するためのサムネイルを登録時に生成するような仕組みがあってもよい。

図３は、文書管理クライアントソフトウェアの一例である。ここで、本実施例で説明する文書管理システムでは、文書の管理体系を複数のキャビネット、キャビネット内に複数のフォルダ、フォルダの中に複数の文書を保持しているものとする。また、フォルダは、内部に更にフォルダを持ってもよい。

３０１は、前述した文書管理体系に基づいたツリー構造でのアクセスを行うためのビューを提供する。３０２や３０３は、キャビネットであり、内部に更にフォルダを含む。３０２は、キャビネットが閉じている状態であり、３０３はキャビネットが開いている状態を表す。閉じている場合は、キャビネットの横に「＋」が表示され、開いている場合は、キャビネットの横に「−」が表示される。この仕組みは、フォルダについても同様である。開いているキャビネットは、内部のフォルダが表示され、３０４のように表示される。

３０５は、キャビネットを選択した場合は、フォルダ一覧が表示され、フォルダを選択した場合は、そのフォルダに含まれる文書やフォルダが表示される。このときの表示方法は、３０５のように文書に対してサムネイルを表示し、フォルダはアイコン表示する形式であっても構わないし、あるいは、図示していないが、文書名やサイズ、ページ数、更新日など文書に付随する情報と共にリスト表示してもよい。また、その複合であってもよい。

本発明では、先に説明したように紙文書におけるファイリング（「移換え」「置換え」）機能を電子文書に対して適用されるものである。図３は、一般的な文書管理クライアントソフトウェアでの構造の説明であったが、本発明では更に、図４のような文書の管理構造になる。

４０１は、当年度の文書を管理するためのキャビネットであり、４０２は、前年度の文書を管理するためのキャビネットである。また、長期保存を行うために文書を保存しておくキャビネットを４０３とする。当年度キャビネット４０１のフォルダ構造は、業務毎に異なった構造をしている。本実施例では、一例として図５の５０１のようなフォルダ構成をしているものとする。

５０１は、当年度キャビネットの構造を表しており、キャビネット内に「出張申請」、「定期代申請」、「購買依頼」、「休暇申請」の４つのフォルダを持つ。５０２は、前年度キャビネットであるが、定型業務であれば、通常は業務内容が変わらないため、フォルダ構成も当年度キャビネットの構成５０１と同様のものとなる。５０３は、長期保存キャビネットであり、利用頻度が下がった文書を一定期間保管しておくためのキャビネットである。ここでは、例えば行政機関で定められた年月だけ保管すべき文書などがある。なお、５０２、５０３は、以下で説明する。

また、前年度キャビネット４０２は、定型業務であれば毎年度同じフォルダ構成をしていた方が利用者にとって使いやすいため、サブフォルダまで含めて当年度キャビネット４０１と同じフォルダ構成をしている（５０２）。長期保存キャビネット４０３は、本実施例では、保存年限毎のフォルダに分かれているものとする。例えば、５０３に示すような５０３１から５０３６のフォルダ構造をしている。ここで、５０３１は、保存期限が３年の文書が入っているフォルダであり、５０３２は、保存期限が５年の文書が入っているフォルダである。

同様に、５０３３は、保存期限が７年、５０３４は、保存期限が１０年のフォルダとなる。また、５０３５は、保存期限がその他の文書のためのフォルダ、５０３６は、保存期限が設定されていない文書のためのフォルダとなる。なお、本実施例では、長期保存は、移動が行われた年度は問わない。

なお、図４の文書管理構造は、一例であって、例えば「当年度」「前年度」だけでなく、更に複数年度に渡って「移換え」が実行できても構わない。また、長期保存も保存年限毎のフォルダに分かれているのでなく、単純な一フォルダにまとめてもよいし、保存年限毎にフォルダを振り分けるなどを行ってもよい。また、置換えが実施された年度毎に分類されていても構わない。キャビネットによって「当年度」「前年度」「長期保存」を管理しているが、同一キャビネット内のフォルダによって管理を行ってもよい。

置換えについて、図４を用いて説明する。年度の変わり目など決められた時期に、前年度キャビネット４０２の中の文書が保管期限に応じて、長期保存キャビネット４０３に移動される。図７で具体的に説明すると、前年度キャビネットに存在している文書７０１が、５年の保管期限とすると、置換えによって、長期保存キャビネットの５年保管期限を表すフォルダ７０３に移動される。

また、前年度キャビネットに存在している文書７０２には、保管期限が設定されていないとすると、置換えによって、長期保存キャビネットの保管期限設定なしフォルダ７０４に移動される。保管期限は、フォルダ単位に付与されていても構わないし、文書単位に付与されていてもよい。階層的なフォルダに複数保管期限が設定されたフォルダが存在している場合、保管期限が付与されているフォルダのうち、より文書に近い（階層が深い）フォルダの設定が有効になる。フォルダと文書の両方に保管期限が設定されている場合は、文書の設定が有効となる。但し、どの保管期限を優先するかについては、管理者が規則を決める仕組みとしてもよい。

移換えについて、図４を用いて説明する。

年度の変わり目など決められた時期に、当年度キャビネット４０１の中の文書を前年度キャビネット４０２の対応するフォルダ位置に移動する。

図８で具体的に説明すると、当年度キャビネットのフォルダ８０２にある文書８０１が、移換えによって前年度キャビネットに移動する。このとき前年度キャビネットの対応する（同一名称を持つ）フォルダＡ８０３へ文書８０１が移動される。また、サブフォルダを持つ場合についても同様に移動される。

例えば、当年度キャビネットのフォルダＢ８１０のサブフォルダＢ１８１１にある文書８０９は、前年度キャビネットの対応するフォルダＢ８１２のサブフォルダＢ１８１３に移動される。フォルダＣ８０５のサブフォルダＣ１８０６にある文書８０４については、前年度キャビネットには、対応するフォルダは、フォルダＣ８０７しか存在していない。そのため、対応するフォルダが無いので移動できない。このときは、移換えの際に自動的にフォルダＣ１８０８を作成して、移動を行う。なお、自動的にフォルダを作成するのではなく、利用者に確認させてからフォルダ作成を行ったり、あるいは、移動先が無いものをまとめて特定のフォルダやキャビネットに移動してもよい。

図６に、本発明の文書管理システムの構成図を示す。

キーボードやマウスなどのユーザ入力装置６０１から文書管理システムに操作の指令を与えると、ユーザ指示部６０２で指令を受けて、文書アクセス部６０５に制御を移す。また、ユーザ指示部６０２での指令が移換え、置換えの条件設定に関することであれば、移換え・置換え条件設定部６１０へ制御が移る。

文書管理システムへの文書登録を行うときには、前記ユーザ指示部から文書登録部６０６で入力待機を行う。オペレーティングシステムのファイルシステムやスキャナなどの入力デバイス６０３から文書登録部６０６に文書の入力があると、文書登録部６０６は、文書アクセス部６０５に文書入力があったことを伝達し、文書管理情報データベース６０８に文書管理情報を登録し、実文書データベース６０９に実文書データを登録する。登録された文書の文書管理情報の変更のするためにも、同様に文書アクセス部６０５から文書管理情報データベース６０８へアクセスして、データベースを更新する。ここで、文書管理情報とは、例えば、文書の保管期限の設定など文書に付随する情報を表す。

また、文書管理システムから出力される場合には、文書アクセス部６０５が実文書データベース６０９から実文書データを取り出し、文書出力処理部６０７にその文書とともに出力指示を与える。文書出力処理部６０７は、出力処理に応じたデバイスを選択し、出力デバイス６０４に文書データを渡して、出力を行う。なお、文書管理システムからの出力とは、文書の表示、エクスポートや印刷、電子メールへの添付など文書管理システムからの出力を意味するため、６０４は、出力デバイスだけでなく、電子メールソフトウェアなどの出力するためのソフトウェアも含む。

文書アクセス部６０５に対して指示され、実施された動作については、全てアクセスログ管理部６１１に通知され、記録されている。なお、記録すべきアクセスログについては、処理、操作を全てでなく、文書管理システムの管理者が適宜必要なものだけを選択出来るようになっていてもよい。

移換え、置換えは、例えば、年度始めの直前等の一定期間で実施されるため、タイマ制御部６１４が移換え、置換え実施日時が来たときに、移換え・置換え処理部６１３を起動する。移換え・置換え処理部６１３は、移換え、置換えを実施するだけでなく、移換え、置換え時に不要な文書を破棄するなど移換え、置換え全般に渡る処理を行っている。また、移換え、置換えの規則についても保持している。つまり、移換え・置換え条件設定部６１０で、条件を設定すると、移換え・置換え処理部６１３に伝えられ、条件が保持される。また、移換え・置換えの実施スケジュールについても、同様に移換え・置換え条件設定部６１０で、条件を設定すると、移換え・置換え処理部６１３に伝えられ、条件がタイマ制御部６１４に伝えられる。

移換え・置換え処理部６１３が、タイマ制御部６１４から起動されると、移換え・置換え処理部６１３は、文書の移換え、置換え処理の指示を文書アクセス部６０５へ行う。ことのき、前記条件に基づいてアクセスログ解析部６１２が実行される。アクセスログ解析部６１２は、アクセスログ管理部６１１に記録されたアクセスログを解析し、前記条件に基づいて移換え・置換え処理部６１３に結果を通達する。移換え・置換え処理部６１３は、不要な文書データあれば、文書アクセス部６０５へ削除依頼を行う。なお、自動的に文書アクセス部６０５へ通知するだけでなく、利用者に判断を求めるようにする場合もあり、その場合は、ユーザ入力装置６０１からの入力をユーザ指示部６０２で判断して処理を行う。

なお、移換え、置換え処理が終了後には、翌年度あるいは次回の移換え、置換えに備えて、移換え置換え処理部６１３からアクセスログ解析部６１２を経由して、アクセスログ管理部６１１に実施対象期間のアクセスログの削除を行う。ただし、この削除を実行しない場合は、アクセスログに記録された日付から、アクセスログ解析部６１２が該当期間か判断することを行う。

また、このときに、置換えに対して文書変換を行う場合には、移換え・置換え処理部６１３が、タイマ制御部６１４から起動された際に、移換え・置換え処理部６１３は、文書変換部６１５に当該文書の文書変換の指示を行う。文書変換部６１５は、文書アクセス部６０５に文書取得を指示し、設定に基づいて文書変換を行い、結果を文書アクセス部６０５を経由して実文書データベース６０９に変換された文書を格納する。同時に、文書管理情報データベース６０８にも変換された情報が格納されていることを記録する。

ここで、文書変換によって変換された文書は、例えば、画像やＡｄｏｂｅ社のＰＤＦやＷＷＷコンソーシアムのＳＶＧと言った汎用的（一般的な）閲覧フォーマットをしているものとする。

図９は、文書管理システムの管理者のための変換条件設定のためのユーザインターフェイスの一例である。

１１０１には、置換え時に自動的に文書変換を実施するオペレーティングシステムの扱う拡張子の一覧を入力する。１１０２は、置換え時に文書変換を行うか否かを問い合わせる拡張子の一覧を入力する。なお、１１０１は、拡張子では無く、拡張子一覧や文書管理システム内で保持している文書フォーマット一覧をリスト表示して、選択させる手段であってもよい。また、置換え時に文書変換を実施するものでなく、実施しないものを指定する仕組みであってもよい。

１１０３、１１０４は、置換え後の文書の保存形態の設定を行う。１１０３、１１０４は排他的な選択であり、１１０３は、置換え後に変換後の文書のみが保存される設定であり、１１０４は、置換え後に変換後の文書と元文書が保存される設定となる。即ち、１１０３が選択されていた場合は、置換え時に文書変換される文書は、変換後の文書のみが実文書データベース６０９に格納される。一方、１１０４が選択されていた場合は、元文書と置換え時に文書変換される文書の両方が実文書データベース６０９に格納される。このときに、文書情報管理データベース６０８には両文書が関連付いた文書であることを登録する。

長期保存フォルダにある文書を開くときに、当該文書が存在せずに変換後の文書のみしか存在しない場合は、変換後の文書が開かれる。元文書と変換後の文書が両方存在する場合は、利用者にどちらで開くのかを選択させて開かせる。

具体的な例として、図１０の条件設定を説明する。

置換え時に自動的に文書変換を実施する文書の拡張子として、「．ａｂｃ」、「．ｔｘｔ」が指定されている。これらの拡張子を持つ文書が置換え時に長期保存フォルダに移動する際に、文書変換処理が実施され、実文書データベースに登録される。

このとき、元文書を残さない設定になっているため、元文書は置換え時に実文書データベースから削除され、変換後の文書のみが保存される。置換え時に自動的に文書変換を実施する問い合わせを行う文書の拡張子として、「．ｘｙｚ」が指定されているので、拡張子「．ｘｙｚ」を持つ文書は、置換え時に管理者に対して、当該文書を変換すべきか否かを問い合わせる。また、文書毎の場合は、毎回全ての文書に対して回答を行うのは、手間が掛かるため、例えば、図１２で示すように設定を一括して行うようにしてもよい。

１４０１は、文書名を表すフィールドである。１４０２は、拡張子を表すフィールドである。１４０３は文書管理システムにおける文書種別を表すフィールドである。１４０４は、処理方法を選択するフィールドである。「文書を変換して、元文書も残す」「文書を変換して、元文書を残さない」「文書を変換しない」の３つの中から選択する。

ここでは、変換するか変換しないかを管理者に問い合わせるものであったが、元文書を残さないことを選択すれば、変換後の文書のみが保存され、元文書も残すことを選択すれば、変換後の文書とともに元文書も保存されるようにしてもよい。更には、この問い合わせは、文書毎に行ってもよいし、拡張子毎に行ってもよい。

本実施例では、アプリケーション文書を汎用的なフォーマットに変換する方法としては、公知の技術であるプリンタドライバによる変換によって行う。これは、アプリケーションを起動して、特定のプリンタドライバを用いて、アプリケーションから印刷を実行することで、オペレーティングシステムが出力した印字データを前記特定のプリンタドライバが解析を行い、例えば画像のような所望の汎用的なフォーマットに変換する。

プリンタドライバによって変換するものとしては、例えば、特開２００２−７３８５号公報がある。この発明は、アプリケーションデータと表示印刷用のデータの双方を保管する発明であって、文書管理システムの入力時にデータ変換が行われており、本発明のように置換え時と言った長期保存に入るタイミングで、長期における見読性を高めるために自動的にフォーマット変換を行うものではない。

フローチャートを用いて、置換え時における文書の自動変換について説明する。

図１１は、移換え、置換え時に元となるフローチャートであり、Ｓ１３０１で、データベースへのアクセスを禁止する。これは、移換え、置換え処理時に他の利用者がデータベースにアクセスしてしまうと、処理中に利用度が変わってしまったり、あるいは、編集などを行ってしまい、移動処理が行えないと言うことが起こらないように他の文書管理ソフトウェア利用者に対してアクセスを禁止する。Ｓ１３０２では、置換え処理を行う。ついで、Ｓ１３０３では、移換え処理を行う。ここで、置換え処理を先に行っているのは、移換えで移動先となる前年度キャビネットを先に処理（空に）しておく必要があるためである。

図１３は、置換え処理を説明するフローチャートである。

Ｓ１５０１からＳ１５０７はループ処理であり、前年度キャビネット内にある全ての文書に対するループとなる。Ｓ１５０２では、前年度キャビネット内からひとつ文書を選択する。Ｓ１５０３では、破棄条件判断処理が呼ばれる。本実施例では、破棄判断処理については明記しないが、文書を破棄すべきか、長期保存すべきかの判断を行う処理である。Ｓ１５０４では、Ｓ１５０３の結果に基づいて、当該文書が破棄対象文書であるかを判断する。もし、破棄対象文書でなければ、Ｓ１５０５へ進み、当該文書の移動処理を行う。この文書変換処理については、図１４のフローチャートで説明する。

その後、Ｓ１５０７へ進む。Ｓ１５０４で、破棄対象文書であれば、Ｓ１５０６へ進み、当該文書を破棄し、Ｓ１５０７へ進む。Ｓ１５０７では、前年度キャビネット内の全ての文書を処理してあれば、Ｓ１５０８へ進む。未処理の文書が存在していれば、Ｓ１５０１へ戻る。Ｓ１５０８では、前年度キャビネット内に存在する文書やフォルダを全て削除する。これは、本実施例における移換え処理で、当年度キャビネットから文書を移動するために行っている。また、削除でなく、特定のキャビネットやフォルダに移動してもよいし、管理者に一覧を提示して、削除するか保存するかを判断するようにしてもよい。削除が終了後に、この処理は終了する。

図１４は、個々の文書に対する置換え時における文書移動処理を説明するフローチャートである。

Ｓ１６０１は、当該文書の文書種別（拡張子）が、管理者が予め定めた文書変換を自動的に行うフォーマットか否かが判断される。文書変換を自動的に行うフォーマットであれば、Ｓ１６０５へ進み文書変換処理が実行される。文書変換を自動的に行うフォーマットでなければ、Ｓ１６０２へ進む。Ｓ１６０２では、管理者が予め定めた文書変換を置換え時に判断を求めるフォーマットか否かが判断される。文書変換を置換え時に判断を求める文書種別（拡張子）であれば、Ｓ１６０３へ進み、文書変換を置換え時に判断を求める文書種別（拡張子）でなければ、当該文書は文書変換する必要がないため、Ｓ１６０９へ進み、Ｓ１６０９で当該文書を長期保存フォルダへ移動して終了する。

Ｓ１６０３では、管理者に当該文書を汎用的なフォーマットに変換するか否かを管理者に判断させる。Ｓ１６０４では、Ｓ１６０３管理者が文書変換を要求しなかった場合は、文書変換を行う必要がないので、Ｓ１６０９へ進み、先に説明した処理が行われる。Ｓ１６０４では、Ｓ１６０３で管理者が文書変換を要求した場合は、文書変換を行わねばならないので、Ｓ１６０５へ進む。Ｓ１６０５では、文書変換処理が行われる。文書変換処理は、図１５のフローチャートで説明する。

Ｓ１６０５で文書変換処理が終了した後、Ｓ１６０６において、元文書についての判断を行う。なお、本実施例では、図９のような変換後の元文書の設定ができるものとする。元文書を残しておく場合は、Ｓ１６０７へ進み、長期保存フォルダに当該文書を移動し、変換後の汎用的なフォーマットを持つ文書も長期保存フォルダに格納する。Ｓ１６０６で、元文書を消す場合は、Ｓ１６０８へ進み、変換後の汎用的なフォーマットを持つ文書のみが長期保存フォルダに格納される。なお、この処理は一文書ずつ行わなくても、図１２を用いて先に説明したようにまとめて行ってもよい。

図１５は、文書変換処理を説明するフローチャートである。

Ｓ１７０１は、当該文書の文書種別（拡張子）に対応するアプリケーションが存在するか否かの判定を行う。アプリケーションが存在していなければ、Ｓ１７１１のエラー処理に進む。アプリケーションが存在していれば、Ｓ１７０２へ進む。Ｓ１７０２では、当該文書に対応するアプリケーションを起動する。Ｓ１７０３では、アプリケーションの起動が成功したか否かを判断する。成功していれば、Ｓ１７０４へ進む。アプリケーションの起動が成功しなかった場合は、Ｓ１７１０へ進む。

Ｓ１７０４では、文書変換を行うための特定のプリンタドライバを選択する処理を行う。Ｓ１７０５でＳ１７０４で選択したプリンタドライバに対して印刷指示を行う。Ｓ１７０６では、印刷が成功したか否かを判断する。成功した場合は、Ｓ１７０７へ進み、成功しなかった場合は、Ｓ１７０９へ進む。Ｓ１７０９では、プリンタドライバを本フローチャートが始まる前のものに戻す処理が行われ、Ｓ１７１０へ進む。

Ｓ１７１０では、Ｓ１７０２で起動したアプリケーションを終了して、Ｓ１７１１へ進む。Ｓ１７０７では、プリンタドライバを本フローチャートが始まる前のものに戻す処理が行われ、Ｓ１７０８へ進み、Ｓ１７０２で起動したアプリケーションを終了する。Ｓ１７１１のエラー処理は、例えば、管理者に自動文書変換を失敗したことを知らせて、管理者自ら当該文書に対応するアプリケーションを起動して、特定のプリンタドライバを選択し、印刷を行い、出来上がったファイルを指定することで当該文書の汎用フォーマットを持つ文書を変換後のデータを文書管理システムに登録することができる。

本実施例では、置換えの際に長期保存されるものは、「元文書だけ」、「変換後の文書だけ」、「元文書と変換後の文書の両方」のどれかに限定していたが、「元文書と変換後の文書の両方」を長期保存の期間より短い一定期間保持し、前記一定期間後に元文書を破棄して、「変換後の文書だけ」を長期保存フォルダに残すようにしてもよい。この場合は、前記一定期間後にタイマ制御部６１４が、移換え置換え処理部６１３を起動し、文書アクセス部６０５に一定期間経過し、「元文書と変換後の文書の両方」を持つ長期保存フォルダの文書を探索して、元文書を削除する。

また、本実施例では、文書管理システムとして予め定められた変換文書フォーマットに固定されていたが、文書管理システムとして、変換後のフォーマットを文書管理システムの管理者が設定できるような仕組みであってもよい。更には、拡張子毎に変換されるフォーマットを指定できる仕組みであってもよい。

例えば、図２０に示すように、自動変換する文書種別、問い合わせを行う文書種別それぞれについて、２２０１で示すように拡張子と２２０２で示す変換後のフォーマットを設定できるような仕組みとしてもよい。つまり、図２０では、自動的に変換されるフォーマットのうち、「．ａｂｃ」は、ビットマップイメージに、「．ｔｘｔ」は、ＳＶＧに自動的に変換され、置換え時に問い合わせを行う文書種別の拡張子「．ｘｙｚ」は、変換される場合は、ＴＩＦＦイメージに変換されるものとする。更には、問い合わせ処理については、置換えの問い合わせ時に、どのフォーマットにすべきかを管理者に入力させて、それに従って自動的に変換していく仕組みでもよい。

第二の実施例においては、置換え時に変換されるフォーマットとして、バインダ文書を用いる例を説明する。

まず、文書管理システムにおけるバインダ文書について説明する。

バインダ文書とは、異なる文書を統一的なフォーマットに変換する。たとえば、ＴＩＦＦやビットマップファイルのような画像フォーマット、あるいは、Ａｄｏｂｅ社のＰＤＦ、また、ＷｏｒｌｄＷｉｄｅＷｅｂＣｏｎｓｏｒｔｉｕｍで策定されたＳＶＧ（ＳｃａｌａｂｌｅＶｅｃｔｏｒＦｏｒｍａｔ）などでページデータを表す。そして、変換されたページデータを基にページや文書の順番の入れ替えや回転、削除などの編集操作を行う。

この統一的なフォーマットへの変換には、アプリケーションから印刷を実行することで、ページデータを生成させる方法がある。このとき、所望のページデータフォーマットに変換するために、実施例１でも説明した公知の技術であるプリンタドライバを用いて、ページデータを統一的なフォーマットに変換する。

これは、図１６に示すように、バインダ文書生成プログラム１８０１がバインダ文書に取り込みたいアプリケーションファイル１８０２に関連付いたアプリケーション１８０３を起動させ、特定の統一フォーマットへ変換するプリンタドライバ１８０４を用いて印刷させるように実行する。プリンタドライバによって生成されたデータをページデータとしてバインダ文書内部に取り込む。ここで、変換された文書は、プリンタドライバを経由して作成されるため、ページ毎のデータとなっているので、ページデータとしている。

ここで、アプリケーションを起動して特定のプリンタドライバで印刷することによって、ページデータ生成してバインダ文書に取り込む方式について説明したが、特定のアプリケーションに関連付かないファイルフォーマット、たとえば画像フォーマットなどは、アプリケーションを起動しないで、直接、統一的なフォーマットに変換してもよい。

バインダ文書の中には、変換されたページデータとともにオリジナル文書データを持ってもよい。オリジナル文書データとは、変換に利用された元となるデータのことである。バインダ文書では、オリジナル文書データを持つ場合に、バインダ文書のページとして利用されている変換されたページがオリジナル文書データの何ページに相当するのか覚えている。すなわち、バインダ文書内のページ番号から、オリジナル文書とその何ページ目に相当するか判明し、逆にオリジナル文書内の特定のページがバインダ文書の何ページ目に相当するか分かる。

図１７に一つの事例のソフトウェアのＧＵＩを用いて、説明を行う。

１９０１は、文書管理ソフトウェアの例である。１９０２は、コンピュータのＯＳ上で管理されたファイル管理の例である。１９０３は、本発明の事項を処理するバインダソフトウェアの例である。なお、このバインダソフトウェア１９０３は、本実施例では、文書管理システム内に含まれるものとするが、文書管理システムとは別ソフトウェアであってもよい。１９０４は、オリジナル文書を管理するＤｏｃｕｍｅｎｔＬｉｓｔである。１９０５は、オリジナルの各ページを表示するＰａｇｅＶｉｅｗである。１９０６は、バインダ文書を管理するＷｏｒｋｓｐａｃｅである。１９０７は、バインダ文書を表示するための表示ソフトウェアである。

図１７では、たとえば、文書管理ソフトウェア１９０１やＯＳのファイル管理１９０２からマウスによるドラッグ＆ドロップによってバインダソフトウェアにオリジナル文書を持ってくると、先に説明したプリンタドライバなどによる統一フォーマットへの変換を行う。このとき、このシステムでは、オリジナル文書をバインダ内に取り込み、ＤｏｃｕｍｅｎｔＬｉｓｔにオリジナル文書の一覧が表示され、ＰａｇｅＶｉｅｗに選択されたオリジナル文書の各ページが表示されている。Ｗｏｒｋｓｐａｃｅ、ＤｏｃｕｍｅｎｔＬｉｓｔ、ＰａｇｅＶｉｅｗには、各ページを縮小表示したサムネイルを用いて表示される。

このバインダソフトウェアの例では、ＤｏｃｕｍｅｎｔＬｉｓｔやＰａｇｅＶｉｅｗからＷｏｒｋｓｐａｃｅにページや文書を移動することで、バインダ文書としてのデータを構築していく。また、Ｗｏｒｋｓｐａｃｅ内でページの並べ替えなどが行える。

また、バインダ文書のページ構成としてより簡潔に行うために、ＰａｇｅＶｉｅｗが存在せずに文書単位でバインダ文書を構成することが可能である。このようなバインダソフトウェアの例として、図１８を用いて説明する。

２００１は図１７と同じようにＷｏｒｋｓｐａｃｅであり、バインダデータを表す。Ｗｏｒｋｓｐａｃｅ２００１が１９０６と異なるのは、ここで扱われるのが、文書単位のデータになることである。たとえば、図１８では、Ｗｏｒｋｓｐａｃｅに３文書あり、それぞれ２００３、２００４、２００５である。それぞれ文書の先頭ページのサムネイルが表示され、また、サムネイルの隅にどのようなアプリケーションのファイルであるかを示すアイコンが付加されている。

ＤｏｃｕｍｅｎｔＬｉｓｔ２００２には、バインダ文書内のオリジナル文書の一覧が表示される。このとき、２００６のように、文書名とこの文書に関連付いたアプリケーションのアイコンが表示される。もし、２００７のようにアイコンが表示されていない場合は、バインダ文書内にオリジナル文書は入っておらず、変換後のページデータだけが入っている。

図１７では、ＧＵＩを用いた例を挙げたが、バインダ文書作成の際には、図１６で説明した処理についてＧＵＩを立ち上げずに、行ってもよい。

置換え時にバインダ文書に変換する場合は、単一のオリジナル文書から成り、図１８で説明した前記オリジナル文書の全てのページがバインダ文書のページとなるバインダ文書を生成する。つまり、オリジナル文書と一対一に対応するバインダ文書が生成される。

第一の実施例では、オリジナル文書と変換後の汎用的なフォーマットの文書の両方を保存する場合に、データベース内での関連付けが必要であり、操作が複雑になる場合がある。本実施例では、バインダ文書に変換して保存することで、元文書と変換後の文書を一つのフォーマットとして扱うことができるため、データの管理が容易となる。また、元文書もバインダ文書の中に含まれているため、データベースにアクセスしなくとも、バインダ文書を取り出してくれば、元文書で開くか、変換後の文書で開くかをユーザの意思によって決定できる。

図１９は、バインダ文書として長期保存を行う場合のフローチャートについて記載している。

Ｓ２１０１は、当該文書の文書種別（拡張子）が、管理者が予め定めた文書変換を自動的に行う文書種別（拡張子）か否かが判断される。文書変換を自動的に行う文書種別（拡張子）であれば、Ｓ２１０５へ進みバインダ文書への変換処理が実行される。文書変換を自動的に行う文書種別（拡張子）でなければ、Ｓ２１０２へ進む。Ｓ２１０２では、管理者が予め定めた文書変換を置換え時に判断する文書種別（拡張子）か否かが判断される。文書変換を置換え時に判断する文書種別（拡張子）であれば、Ｓ２１０３へ進み、文書変換を置換え時に判断する文書種別（拡張子）でなければ、当該文書は文書変換する必要がないため、Ｓ２１０７へ進み、Ｓ２１０７で当該文書を長期保存フォルダへ移動して終了する。

Ｓ２１０３では、管理者に当該文書をバインダ文書に変換するか否かを管理者に判断させる。Ｓ２１０４では、Ｓ２１０３管理者が文書変換を要求しなかった場合は、文書変換を行う必要がないので、Ｓ２１０７へ進み、先に説明した処理が行われる。Ｓ２１０４では、Ｓ２１０３で管理者が文書変換を要求した場合は、文書変換を行わねばならないので、Ｓ２１０５へ進む。Ｓ２１０５では、バインダ文書への変換処理が行われる。バインダ文書への変換処理は、本実施例の始めに説明したように行われる。Ｓ２１０５で文書変換処理が終了した後、Ｓ２１０６へ進み、バインダ文書が長期保存フォルダに格納される。なお、この処理は一文書ずつ行わなくても、実施例１での図１２を用いて先に説明したようにまとめて行ってもよい。

本実施例では、バインダ文書に変換する単位が一文書であったが、前記バインダ文書の構成より、バインダ文書には、複数のオリジナル文書を保持することができる。バインダ文書のオリジナル文書を置換え時の元文書と対応付けることにより、置換え時に複数の文書をまとめて一つのバインダ文書として長期保存することが可能となる。例えば、フォルダ単位にバインダ文書とすることで、関連付いた文書を一まとめとして長期保存させることもできる。更には、バインダ文書の内部でも、特定の文書だけオリジナル文書（元文書）を持たないことが可能であるため、バインダ文書でも元文書を持つか持たないかを設定できる。

また、保存年限毎にバインダ文書としてまとめることも可能である。保存年限毎にまとめることによって、保存年限が切れて破棄を実施する際に、複数の文書を破棄するのではなく、一つのバインダ文書を破棄することで処理を済ませることができる利点がある。更には、フォルダ単位と保存年限を組み合わせて、バインダ文書を作成してもよい。

ファイリングの方式の一例を示す図文書管理システムの構成を示す図文書管理クライアントの画面構成例を示す図移換え・置換え機能を有する文書管理クライアントの画面構成例を示す図移換え・置換えのフォルダの一例を示す図本発明の文書管理システムのブロック図置換えのときの文書移動の例を示す図移換えのときの文書移動の例を示す図自動文書変換条件設定のユーザインターフェイスの一例を示す図自動文書変換条件の設定例を示す図移換え・置換えのメインフローチャート変換対象文書一括設定の一例を示す図置換え処理を説明するフローチャート置換え時の文書移動を説明するフローチャート文書変換処理を説明するフローチャートバインダ文書生成のブロック図バインダ文書を扱うソフトウェアの一例を示す図文書単位にデータを扱うバインダ文書ソフトウェアの一例を示す図バインダ文書を用いて長期保存を行うときのフローチャート文書種別毎に変換されるフォーマットを選択する一例を示す図

符号の説明

２０１文書管理サーバ
２０２データベース
２０３文書ボリュームサーバ
２０４ネットワーク
２０５クライアントＰＣ
２０６クライアントＰＣ

Claims

データ保管するためのデータベースを具備し、前記データベースに文書を登録する手段を具備し、時間を管理するタイマを具備し、前記タイマが一定期間経過すると文書移動を行う移換え・置換え処理手段を具備し、文書フォーマットを変換する文書変換手段を具備する文書管理システムにおいて、前記タイマにより実施される文書の置換え処理において、前記文書変換手段によって前記データベース内の文書を自動的に汎用フォーマットに変換することを特徴とする文書管理システム。
請求項１に記載の文書管理システムにおいて、フォーマット選択手段を具備し、前記フォーマット選択手段によって選択されたフォーマットに変換することを特徴とする文書管理システム。
請求項１または２に記載の文書管理システムにおいて、前記文書変換手段によって変換された文書と変換前の文書を同時に前記データベースに格納することを特徴とする文書管理システム。
請求項３に記載の文書管理システムにおいて、前記タイマが設定された期間後に前記変換前の文書を削除することを特徴とする文書管理システム。
請求項２に記載の文書管理システムにおいて、文書種別毎に変換されるフォーマットを個別に指定するための文書種別フォーマット設定手段を具備し、前記文書種別フォーマット設定手段によって、文書種別毎に異なるフォーマットに変換することを削除することを特徴とする文書管理システム。
請求項２に記載の文書管理システムにおいて、オリジナル文書データと汎用フォーマットである文書データをひとつのフォーマットとして扱うバインダ機能を具備し、変換されたフォーマットとしてバインダ文書を選択することを特徴とする文書管理システム。
請求項６に記載の文書管理システムにおいて、バインダ文書に複数の文書を格納することを特徴とする文書管理システム。
請求項７に記載の文書管理システムにおいて、文書管理システム内のフォルダ単位にバインダ文書に複数の文書を格納することを特徴とする文書管理システム。
請求項７に記載の文書管理システムにおいて、保存年限毎にバインダ文書に複数の文書を格納することを特徴とする文書管理システム。
請求項７に記載の文書管理システムにおいて、元文書を保管すべきかを指定する元文書保管設定手段を具備し、前記元文書保管設定手段によって指定された文書だけ元文書を保持し、他の文書は元文書を保持しないバインダ文書を前記データベースに格納することを特徴とする文書管理システム。