文書管理システムにおける文書更新方法
【課題】 文書管理システムを導入していない環境において、文書管理システム内の文書を直接更新することを目的とする。
【解決手段】 バインダ文書をエクスポートする際に、文書から求めらるハッシュ値、サーバのアドレス、文書を特定する文書ＩＤを埋め込んだ文書を作成する。文書更新者は、当該文書を起動すると、埋め込まれたハッシュ値、文書から求めたハッシュ値、サーバに格納されたハッシュ値を比較して、文書が正当なものであるか検証して、文書更新を認める。また、バインダ文書と言う独自フォーマットを利用することにより、通常扱えない文書が流通することになり、アプリケーション文書をエクスポートするよりセキュリティが高まる。
【解決手段】 バインダ文書をエクスポートする際に、文書から求めらるハッシュ値、サーバのアドレス、文書を特定する文書ＩＤを埋め込んだ文書を作成する。文書更新者は、当該文書を起動すると、埋め込まれたハッシュ値、文書から求めたハッシュ値、サーバに格納されたハッシュ値を比較して、文書が正当なものであるか検証して、文書更新を認める。また、バインダ文書と言う独自フォーマットを利用することにより、通常扱えない文書が流通することになり、アプリケーション文書をエクスポートするよりセキュリティが高まる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子的な文書管理システムに関するものである。
【背景技術】
【０００２】
企業ではドキュメント管理システムを導入し、文書の再利用を推進しようとしている。初期の製品は紙の文書をスキャナで画像として取り込み、登録保存うるようなものであったが、最近はパソコンで作られた文書が多くなり、それも登録保存できるようになってきた。
【０００３】
文書管理システムにおいては、様々な文書をデータベース内に保存し、複数の利用者から共有される形態を取る。文書管理システムでは、文書の実体を表すデータを保持するとともに、前記文書に付随する様々な文書情報も保持している。文書管理システム内で、文書の登録、削除や更新処理を行うことができる。
【０００４】
また、最近では登録されている複数の文書から任意のページを抜き出してバインダのように綴じて一つの文書のようにすることもできるようになっている。それをここでは電子バインダと呼ぶ。
【０００５】
従来は文書更新を行う際に、文書管理システムのクライアントソフトウェア全体をインストールする必要があった。一般に、文書管理システムのクライアントソフトウェアは、機能を多く有し、巨大なソフトウェアであり、また、データベースの接続を設定する必要があるなど、ユーザ環境によって文書管理システムを導入することが困難であった。そのため、文書管理システムを導入していないユーザに対しては、文書管理システムの文書を一旦ファイルとして保存して、電子メールや物理的なＣＤ−ＲやＭＯなどのメディアによって前記文書管理システムを導入していないユーザに渡すなどをしていた。更には、更新後に再度前記文書管理システムを導入していないユーザが編集された文書を電子メール等により文書管理システムを導入しているユーザに送付し、前記文書管理システムを導入しているユーザが、文書管理システムに再登録、もしくは文書の更新作業を行う。
【０００６】
又、従来例としては、例えば特許文献１をあげることが出来る。
【特許文献１】特開2003-173329号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
文書管理システムを導入していないユーザに対して文書更新を依頼する場合は、文書を一旦アプリケーションが扱えるファイルにして送付し、編集後に再度更新済みファイルを受信し、文書管理システムに再登録、あるいは更新するため、ユーザの手間が掛かった。
【０００８】
また、一旦ファイル化するために、文書管理システム外に文書が流通してしまい、不正利用される可能性がある。
【課題を解決するための手段】
【０００９】
本発明は、
文書を登録する手段と、前記登録された文書を更新する手段を持ち、文書に関する情報を文書管理テーブルとして保持する、文書管理システムにおいて、文書を外部へ保存する際に、前記文書に関する情報が保持されているサーバのＵＲＬ情報と、文書を特定するための文書ＩＤと、前記文書より求められるハッシュ値を前記文書中に埋め込み、更には、文書を外部にエクスポート中には他ユーザが前記文書を操作できないようにロックを行い、文書を更新する際に、前記文書中に埋め込まれたハッシュ値と実文書データから求められるハッシュ値と文書管理テーブル内に保持されたハッシュ値とを比較して文書の更新を認めることを特徴とする文書更新方法であるので、
文書管理システムを導入していないユーザに対して文書更新を依頼する場合は、文書を一旦アプリケーションが扱えるファイルにして送付し、編集後に再度更新済みファイルを受信し、文書管理システムに再登録、あるいは更新するため、ユーザの手間が掛かかり、
また、一旦ファイル化するために、文書管理システム外に文書が流通してしまい、不正利用される可能性があることが解消される。
【発明の効果】
【００１０】
以上述べてきたように、文書を登録する手段と、前記登録された文書を更新する手段を持ち、文書に関する情報を文書管理テーブルとして保持する、文書管理システムにおいて、文書を外部へ保存する際に、前記文書に関する情報が保持されているサーバのＵＲＬ情報と、文書を特定するための文書ＩＤと、前記文書より求められるハッシュ値を前記文書中に埋め込み、更には、文書を外部にエクスポート中には他ユーザが前記文書を操作できないようにロックを行い、文書を更新する際に、前記文書中に埋め込まれたハッシュ値と実文書データから求められるハッシュ値と文書管理テーブル内に保持されたハッシュ値とを比較して文書の更新を認めることを特徴とする文書更新方法によって、文書管理システムを導入していないユーザに対して文書更新を依頼する場合は、文書を一旦アプリケーションが扱えるファイルにして送付し、編集後に再度更新済みファイルを受信し、文書管理システムに再登録、あるいは更新するため、ユーザの手間が掛かかり、また、一旦ファイル化するために、文書管理システム外に文書が流通してしまい、不正利用される可能性があることが解消される。
【発明を実施するための最良の形態】
【００１１】
以下、図面を参照して本発明を説明する。
【実施例１】
【００１２】
本発明は、文書管理システムに関する発明である。
【００１３】
図１に本発明における文書管理システムの構成を表す図である。１０１は、クライアントＰＣであり、この中に文書管理ソフトウェアのクライアントソフトが存在している。１０２は、文書データサーバであり、この中に文書管理システムに入力された文書の実体が格納される。文書に付随する作成者や作成日、更新日などの情報は、１０３の文書情報サーバ内に格納される。これら、クライアントＰＣ１０１、文書データサーバ１０２、文書情報サーバ１０３は、ネットワーク１０５で結ばれている。ここで、ネットワーク１０５は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）である場合が多い。図１においては、説明の簡便化のために、クライアントＰＣ１０１を１台にしてあるが、通常の文書管理システムの運用においては、複数台のクライアントＰＣが存在する。また、ネットワークを介して、文書管理ソフトウェアのクラインとソフトが存在しないクライアントＰＣ１０４がある。
【００１４】
具体的に、文書を文書管理システムに登録する処理について説明する。クライアントＰＣ１０１において、文書管理ソフトウェアのクライアントソフトを用いて文書を登録すると、当該文書の実体を文書データサーバ１０２へ格納し、当該文書の作成者や更新日時、要約、検索情報、サムネイルなどの付随する文書情報が、文書情報サーバ１０３に格納される。文書管理ソフトウェアのクライアントソフトにおいて、検索、サムネイル表示等の文書に付随する情報を表示するときは、文書情報サーバから情報を得て表示を行い、また、文書の実データにアクセスする必要のある場合は、文書データサーバから文書データを取得する。
【００１５】
本実施例によると、文書管理システムのクライアントソフトウェアが無い環境、すなわちクライアントＰＣ１０４のような環境においても、文書データサーバのデータを更新することが可能となる。以下、具体的に説明を行う。
【００１６】
まず、本実施例を説明するための文書フォーマットとして、電子バインダ文書を説明する。
【００１７】
電子バインダ文書は、異なる文書を統一的なフォーマットに変換する。たとえば、TIFFやビットマップファイルのような画像フォーマット、あるいは、PDF、また、World Wide Web Consortiumで作成されたSVGなどでページデータを表す。そして、変換されたページデータを基にページや文書の順番の入れ替えや回転、削除などの編集操作を行う。
【００１８】
この統一的なフォーマットへの変換には、ページデータを確定させる必要があるために、アプリケーションから印刷を実行することで、ページデータを生成させる方法がある。このとき、所望のページデータフォーマットに変換するために、プリンタドライバを用いて、ページデータを統一的なフォーマットに変換する。これは、図２に示すように、バインダ生成プログラム２０１がバインダに取り込みたいアプリケーションファイル２０２に関連付いたアプリケーション２０３を起動させ、特定の統一フォーマットへ変換するプリンタドライバ２０４を用いて印刷させるように実行する。プリンタドライバによって生成されたデータをページデータとしてバインダ内部に取り込む。
【００１９】
ここで、アプリケーションを起動して特定のプリンタドライバで印刷することによって、ページデータ生成して電子バインダ文書に取り込む方式について説明したが、特定のアプリケーションに関連付かないファイルフォーマット、たとえば画像フォーマットなどは、アプリケーションを起動しないで、直接、統一的なフォーマットに変換してもよい。
【００２０】
電子バインダ文書の中には、変換されたページデータとともにオリジナル文書データを持ってもよい。オリジナル文書データとは、変換に利用された元となるデータのことである。電子バインダ文書では、オリジナル文書データを持つ場合に、電子バインダ文書のページとして利用されている変換されたページがオリジナル文書データの何ページに相当するのか覚えている。すなわち、電子バインダ文書内のページ番号から、オリジナル文書とその何ページ目に相当するか判明し、逆にオリジナル文書内の特定のページが電子バインダ文書の何ページ目に相当するか分かる。
【００２１】
図５に一つの事例のソフトウェアのＧＵＩを用いて、説明を行う。５０１は、文書管理ソフトウェアの例である。５０２は、コンピュータのOS上で管理されたファイル管理の例である。５０３は、本発明の事項を処理するバインダソフトウェアの例である。５０４は、オリジナル文書を管理するＤｏｃｕｍｅｎｔ Ｌｉｓｔである。５０５は、オリジナルの各ページを表示するＰａｇｅ Ｖｉｅｗである。５０６は、バインダ文書を管理するＷｏｒｋｓｐａｃｅである。５０７は、電子バインダ文書を表示するための表示ソフトウェアである。
【００２２】
図５では、たとえば、文書管理ソフトウェア５０１やOＳのファイル管理５０２からマウスによるドラッグ＆ドロップによってバインダソフトウェアにオリジナル文書を持ってくると、先に説明したプリンタドライバなどによる統一フォーマットへの変換を行う。このとき、このシステムでは、オリジナル文書を電子バインダ文書内に取り込み、Ｄｏｃｕｍｅｎｔ Ｌｉｓｔにオリジナル文書の一覧が表示され、Ｐａｇｅ Ｖｉｅｗに選択されたオリジナル文書の各ページが表示されている。Ｗｏｒｋｓｐａｃｅ、ＤｏｃｕｍｅｎｔＬｉｓｔ、ＰａｇｅＶｉｅｗには、各ページを縮小表示したサムネイルを用いて表示される。
【００２３】
このバインダソフトウェアの例では、ＤｏｃｕｍｅｎｔＬｉｓｔやＰａｇｅＶｉｅｗからＷｏｒｋｓｐａｃｅにページや文書を移動することで、電子バインダ文書としてのデータを構築していく。また、Ｗｏｒｋｓｐａｃｅ内でページの並べ替えなどが行える。
【００２４】
また、電子バインダ文書のページ構成としてより簡潔に行うために、ＰａｇｅＶｉｅｗが存在せずに文書単位で電子バインダ文書を構成することが可能である。このようなバインダソフトウェアの例として、図３を用いて説明する。３０１は図５と同じようにＷｏｒｋｓｐａｃｅであり、バインダデータを表す。Ｗｏｒｋｓｐａｃｅ３０１が５０６と異なるのは、ここで扱われるのが、文書単位のデータになることである。たとえば、図３では、Ｗｏｒｋｓｐａｃｅに３文書あり、それぞれ３０３、３０４、３０５である。それぞれ文書の先頭ページのサムネイルが表示され、また、サムネイルの隅にどのようなアプリケーションのファイルであるかを示すアイコンが付加されている。
【００２５】
ＤｏｃｕｍｅｎｔＬｉｓｔ３０２には、バインダ内のオリジナル文書の一覧が表示される。このとき、３０６のように、文書名とこの文書に関連付いたアプリケーションのアイコンが表示される。もし、３０７のようにアイコンが表示されていない場合は、バインダ内にオリジナル文書は入っておらず、変換後のページデータだけが入っている。
【００２６】
本実施例では、電子バインダ文書を例に説明する。電子バインダ文書を文書管理システムからエクスポート（取り出す）する。これは、クライアントＰＣ１０１から電子バインダ文書をエクスポートすることと同義である。電子バインダ文書をクライアントＰＣ１０１からエクスポートするときに、文書データサーバ１０２から文書の実データが取り出される。更に、文書情報サーバ１０３の文書情報に対してロックされた旨の情報が記述される。
【００２７】
例えば、文書情報として、図６に示すような文書管理テーブルによって管理されているとする。なお、図６は文書情報の一部であり、この他に文書に関連する情報が格納されているものとする。６０１は、文書ＩＤであり、当該文書管理システム内で文書を唯一に特定するＩＤである。同一文書管理システム内において、この文書ＩＤ６０１が重なることはない。６０２は、ロックフラグである。各文書がロックされているかを示すものであり、これは、文書を共有する際に誰かが編集を行っているときに他ユーザが変更できなくするためのフラグである。更に、６０６に編集ユーザＩＤフィールドがあり、編集中の場合にはこの６０６に編集しているユーザを特定する一意なＩＤが与えられる。６０２のロックフラグが立っている場合には、文書がロックされており、編集ユーザＩＤ６０６で指定された文書の編集ユーザ以外は、当該文書の編集が行えない。文書の編集終了後に、ロックフラグ６０２と編集ユーザＩＤフィールド６０６はクリアされる。
【００２８】
６０３は、エクスポートロックフラグである。文書がエクスポートされた場合に、このフラグが立つ。このとき、ロックフラグ６０２と同様に、エクスポートユーザＩＤフィールド６０７があり、エクスポートしたユーザを特定するＩＤが記載される。文書のエクスポート中は他ユーザが編集等の文書関連の操作を行えなくなる。更に、文書をエクスポートする際には、文書データからハッシュ関数によってハッシュ値が計算される。このハッシュ値の計算には公知の技術であるハッシュ関数を利用する。例えば、ＲＦＣ１３２１（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ）で規定されるＭＤ５を利用する。この値が６０４のハッシュ値フィールドに与えられる。６０８は、エクスポートパスワードフィールドであり、エクスポートする際にパスワードを設定した場合には、６０８にパスワードが格納される。アクセスする際に、パスワードを確認することにより、認証を行える。
【００２９】
また、６０５には、ユーザＩＤフィールドがあり、この文書の所有者のＩＤが格納さえる。文書情報のテーブルはこの限りではなく、例えば、更新日時、サムネイル情報といった文書情報や、本実施例で触れていないが、ユーザ間におけるアクセス権の設定、あるいは、グループを定義することによりグループでのアクセス権などの情報を与えることも可能である。
【００３０】
図６中には明示していないが、文書データの実体がどの文書データベースのどこにあるかと言った情報も文書管理テーブル内に格納されているものとする。
【００３１】
文書をエクスポートするときに、先に記したようにハッシュ値を計算する。計算したハッシュ値を実文書データに埋め込み、その文書をエクスポートする。具体的には、図７に示すように、実文書データ７０１に対して、ハッシュデータ７０２を付加する。なお、この実施例においては、先頭に付加しているが、末尾や中間に存在させるようにさせてもよい。先に説明したように、ハッシュ関数としてＭＤ５を利用する場合は、ハッシュデータ７０２は、１２８ビットとなる。更には、文書情報サーバのＵＲＬ情報をＵＲＬフィールド７０３に格納する。当該文書の文書ＩＤを文書ＩＤフィールド７０４に格納する。
【００３２】
文書をエクスポートすると、先に述べたようにエクスポートロックフラグ６０３が有効になり、エクスポートユーザＩＤフィールド６０５にエクスポートしたユーザＩＤが記載される。また、文書から計算されて実データに埋め込まれたハッシュ値をハッシュ値フィールド６０４に書き込む。
【００３３】
エクスポートする処理について、図８のフローチャートを利用して説明する。Ｓ８０１でエクスポートしよとする文書のロックフラグ６０２が有効であるか判断する。有効であれば、文書が自分、もしくは他のユーザによって利用されているため、エクスポートできないので、処理を終了する。ロックフラグ６０２が有効でなければ、Ｓ８０２へ進み、ロックフラグ６０２を有効にする。６０６編集ユーザＩＤフィールドに自らのユーザＩＤを格納する。このようにロックすることで、他ユーザが当該文書を編集できないようにする。
【００３４】
Ｓ８０３へ進み、文書データを文書データベースより取り出す。Ｓ８０４において、ハッシュ値を計算する。Ｓ８０５では、計算されたハッシュ値を６０４ハッシュ値フィールドに格納する。Ｓ８０６に進んで、前記ハッシュ値、文書情報サーバのＵＲＬ情報、文書ＩＤを文書データに埋め込む。Ｓ８０７へ進み、６０３エクスポートロックフラグを立てる。Ｓ８０８で、６０７エクスポートユーザＩＤフィールドにエクスポートを実行したユーザＩＤを記載する。Ｓ８０９では、Ｓ８０６で情報が埋め込まれた文書データをディスク上の所望の場所に移動する。Ｓ８１０で、Ｓ８０１で立てた６０２ロックフラグを解除する。
【００３５】
図８の処理に従えば、文書更新のために必要なデータを付加した文書をエクスポートすることが可能となる。
【００３６】
前記文書更新のために必要なデータを付加した文書を電子メールや物理的なメディアを媒体として他ユーザに送付する。前記他ユーザが文書管理ソフトウェアのクライアントソフトを所持していなければ直接更新することができないが、本実施例においては、バインダの編集機能のみを有するソフトウェアでのみ文書の編集、更新処理を行うことが可能となる。以下では、前記文書更新のために必要なデータを付加した文書をエクスポートされた文書とする。
【００３７】
これは、ユーザが前記エクスポートされた文書を起動したときに、文書中に含まれる文書情報サーバのＵＲＬ情報７０３に対してアクセスを行い、文書管理テーブルにおける文書ＩＤ７０４で特定される文書に対応する６０４ハッシュ値フィールドと、前記起動した文書データ中のハッシュ値７０２と、実文書データ７０１から再度求めたハッシュ値の３つの値を比較する。前記エクスポートされた文書データ中のハッシュ値７０２と、実文書データ７０１から再度求めたハッシュ値が異なっていれば、実文書データが変更されている、もしくは文書データ中のハッシュ値が変更されていることが分かり、起動を認めない。また、文書管理テーブルにおける文書ＩＤ７０４で特定される文書に対応する６０４ハッシュ値フィールドと、前記エクスポートされた文書データ中のハッシュ値７０２が異なっている場合も、変更があったものとして起動を認めない。
【００３８】
当該文書、すなわちバインダ文書を編集して、保存するときには、再度文書情報サーバＵＲＬ７０３で指定される文書情報サーバにアクセスを行い、文書データベースの格納されているデータに対して、更新処理を行う。更新処理でなくても、新規に文書の追加処理でも構わない。
【００３９】
以下、図９のフローチャートを用いて上記処理を説明する。Ｓ９０１で、エクスポートされた文書データより、ハッシュ値を取り出す。Ｓ９０２では、エクスポートされた文書データより、文書ＩＤを取り出す。Ｓ９０３では、エクスポートされた文書データより、文書情報サーバのＵＲＬ情報を取り出す。Ｓ９０４では、エクスポートされた文書データより、実文書データを取り出す。ここで、実文書データは、ファイルなどの物理的にアクセス可能な媒体として取り出すのではなく、コンピュータにおけるメモリ上に展開して取り出すようにする。このようにすることによって、編集ユーザが実文書データを取得できないようにする。
【００４０】
Ｓ９０５では、Ｓ９０４で取り出された実文書データに対してハッシュ値を計算する。このハッシュ値の計算方法は、文書情報サーバで計算されるものと同一である。Ｓ９０６では、Ｓ９０５で計算されたハッシュ値とＳ９０１で取り出されたハッシュ値が同一かを判断する。同一でない場合は、処理を終了する。同一の場合は、Ｓ９０７へ進み、Ｓ９０３で得られた文書情報サーバのＵＲＬにアクセスが可能であるかを判断する。アクセス不可能であれば、処理を終了する。アクセス可能であれば、Ｓ９０８へ進む。Ｓ９０８では、Ｓ９０１で取り出されたハッシュ値と文書管理テーブルにおいてＳ９０２で取り出された文書ＩＤに対応する６０４ハッシュ値フィールドの値との比較を行う。同一でなければ、処理を終了する。同一であれば、Ｓ９０９へ進む。Ｓ９０９では、当該文書に対するエクスポートパスワードフィールド６０８にパスワードが設定されているか調べる。パスワードが設定されていなければ、Ｓ９１２へ進む。パスワードが設定されていれば、Ｓ９１０へ進みパスワードの入力をユーザに行われせる。Ｓ９１１では、入力したパスワードを確認して、異なっていれば、再度入力させるためにＳ９１０へ戻る。なお、本実施例のフローチャートでは、パスワードの入力を何度でも認めるようになっているが、規定回パスワードを間違えたらアクセスできなくするような仕組みであってもよい。なお、パスワードの確認方法については、本実施例の範疇ではなく、公知の技術を用いればよい。パスワードが正しければ、Ｓ９１２へ進む。Ｓ９１２では、Ｓ９０４で取り出された実データを編集可出来るように開く。
【００４１】
なお、Ｓ９１０でパスワードの確認を行っているが、このパスワードはエクスポートしたユーザが設定したパスワードであり、このパスワードを知っていれば文書管理ソフトウェアのユーザでなくとも文書更新が可能である。文書管理ソフトウェアのユーザに限定したい場合は、Ｓ９１０において、文書管理ソフトウェアにおけるユーザＩＤとパスワードの確認を行うようにすればよい。
【００４２】
本実施例では、先に説明した文書管理システムの一機能であるバインダ機能を利用しているために、実文書データの取り出しによって一時的に利用可能なファイルを出力することによるセキュリティの低下を防御できる。これは、一般アプリケーションであれば、前記アプリケーションが文書を読み込めるようにするために、ディスク上などにファイルで存在する必要がある。本実施例では、バインダであるので実文書データ取り出した際に直接データをアプリケーション（バインダビューア）に展開できるため、悪意のあるユーザによる不正使用を防げる。
【００４３】
以上が、文書を開くときの処理を説明するフローチャートである。編集については、先に説明したように行う。
【００４４】
文書を編集後について、図１０のフローチャートを用いて説明を行う。Ｓ１００１において、文書情報サーバを経由して、実文書を文書データベースに登録する。Ｓ１００２では、文書情報サーバに対して新規に文書を登録する。なお、文書を新規に登録するのではなく、当該文書を上書きによる更新、あるいは、バージョン管理による新規バージョン登録による更新を行ってもよい。Ｓ１００３では、６０４ハッシュ値フィールドに対して、無効な値を入れることで再更新をできなくする。
【００４５】
エクスポートを実行したユーザが、文書管理システムのクライアントソフトウェアを用いて当該文書にアクセスした場合、６０４ハッシュ値フィールドが無効な値になっていることから、当該文書に対して更新が行われたことを把握できる。エクスポートを実行したユーザは、更新文書を受け入れる、あるいは別名として保存するなど文書管理システム上で処理を行う。文書更新を完了したあとは、エクスポートロックフラグ６０３が解除され、エクスポートユーザＩＤフィールド６０５とハッシュ値フィールド６０４がクリアされる。
【００４６】
なお、本実施例中で、通信に用いるプロトコルとして言明していないが、例えば、公知の技術であるセキュリティ機能を有するｈｔｔｐｓ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ）などを用いる。
【００４７】
文書フォーマット内部にＵＲＬ情報を持つものとして、特開２００３−１７３３２９「文書管理システム」があるが、これは、複数の文書保存サービスが存在している環境で保存位置を明確にするものであり、ディレクトリサービスに文書位置を登録し、各クライアント上にファイルが存在するため、本発明による文書管理システムのように一意に管理された文書を対象としていない。
【００４８】
本実施例では、文書を編集する対象として、バインダ文書としたが、バインダ文書に限らず、ワードプロセッサや表計算ソフトウェアなど一般のアプリケーション文書を実文書データとしてもよい。但し、実文書データが一般のアプリケーション文書である場合には、実文書データを取り出した段階で、編集作業を行うユーザが、実文書データを取得することが可能となる。バインダ文書の場合は、文書管理ソフトウェアに依存したフォーマットであるため、実文書データを取得することができてしまう。実文書データを取得できてもよい場合には、一般のアプリケーション文書に対しても適用することが可能である。バインダ文書で無く、一般のアプリケーションを対象文書とすることにより、本実施例の図２、図３、図５で説明した文書編集機能が不要となり、実文書データと文書情報取り出し機能、及びハッシュ値による文書検証機能、及び文書更新機能のみの実装されたモジュールとなり、文書管理システムを導入できないユーザにとって、より軽快に扱うことが可能となる。
【００４９】
以上説明したように、本発明によれば、文書管理システムにおけるクライアントソフトウェアにおいて、クライアントソフトウェアが無い環境でも文書更新を行うことができる。
【実施例２】
【００５０】
実施例１においては、単一のユーザからの更新のみを対象としていたが複数のユーザからの更新処理を行えるようにしてもよい。
【００５１】
図１１に示す文書管理テーブルのように、１１０１更新データリンクリストを設ければよい。１１０１は、リストの参照先を表し、更新データリンクリストは、１１０３のようなリスト形式で表される。複数ユーザから文書更新を行った場合の具体的な動作について説明する。各ユーザより文書更新がなされる度に、更新された文書は新規文書として登録される。このときに新規文書ＩＤが付与されるが、１１０２の更新文書フィールドを設け、ここに更新前の文書を表す親文書ＩＤが格納され、この文書は通常では扱えない文書となる。更新の確認のみ行える。
【００５２】
更新データリンクリストは、１１０４文書ＩＤフィールド、１１０５ユーザＩＤフィールド、１１０６更新日時フィールドからなる。文書更新を行うために、ユーザが文書情報サーバにアクセスしてきた場合には、実文書データを新規文書として登録して、文書ＩＤを取得する。ただし、１１０２の更新文書フィールドに親文書ＩＤを入れ、通常の文書として扱えない文書とする。取得した文書ＩＤを１１０４文書ＩＤフィールドにいれ、また、アクセスしてきたユーザＩＤを１１０５ユーザＩＤフィールドに格納する。ここで、先の実施例１で説明したように、文書管理ソフトウェアでないユーザがアクセスした場合には、特定のキーワードを入れる、アクセスしてきたコンピュータのＩＰアドレスを入れる、ユーザにユーザ名を入れさせる、ＯＳのユーザ名を利用するなどの仕組みがある。また、１１０６には、更新を行った日時が格納される。
【００５３】
具体的には、図１１において、文書ＩＤが００１５２ものがエクスポートされたとする。エクスポートされた文書は、ユーザＩＤがＵ００７７３のユーザによって編集され、文書管理ソフトに再登録されたとする。この再登録された文書が、文書ＩＤ００６４９で表される文書である。更新文書であるため、１１０２更新文書フィールドには、親文書の文書ＩＤである００１５２が入り、通常では見られない文書となる。この文書は、文書ＩＤ００１５２の１１０１更新データリンクリストの示される更新データリンクリスト内にユーザ情報や日時とともに情報が収められ、００１５２の文書とともに前記００６４９の文書にアクセスすうことが可能となる。
【００５４】
エクスポートを行ったユーザは、各文書を比較して、必要な文書のみを登録したり、文書をまとめたりすることで、文書更新を完了する。なお、文書更新を完了した際に、エクスポートロックフラグ６０３が解除され、エクスポートユーザＩＤフィールド６０５とハッシュ値フィールド６０４がクリアされることにより、更なる文書更新を認めないようにする。
【００５５】
また、本実施例によれば、実施例１では、一度しかユーザに更新の機会を与えなかったが、１ユーザが複数回文書を更新するように認めるようにしてもよい。このとき、ユーザＩＤによって区別を行っているため、同一ユーザからの複数の更新は、最新の更新だけを取っておくようにすることも可能である。
【実施例３】
【００５６】
実施例１、２においては、無条件にアクセスを更新を認めていたが、アクセス可能なユーザやＩＰアドレスを設定してアクセス制限を掛けてもよい。
【００５７】
図４に示す文書管理テーブルのように、１２０１アクセス可能ユーザリリスト、１２０２アクセス可能ＩＰアドレスリストを設ける。１２０１は、アクセスが可能なユーザＩＤの一覧を表すリストへの参照を表す。アクセス可能なユーザＩＤリストは、１２０３に示すように、アクセスを許可するユーザＩＤに対しては、「＋」を付与し、アクセスを拒否するユーザＩＤに対しては「−」を付与する。同様に、１２０２はアクセス可能なＩＰアドレスの一覧を表すリストへの参照を表す。アクセス可能なＩＰリストは、１２０４に示すように、アクセスを許可するＩＰアドレスに対しては、「＋」を付与し、アクセスを拒否するＩＰアドレスに対しては「−」を付与する。ここで、ＩＰアドレスに対しては、例えば「192.10.1.*」のように、アスタリスク（＊）を用いて一定の範囲のＩＰアドレス全てをアクセス許可、不許可にしてもよい。また、本実施例では、１２０１、１２０３において、ユーザＩＤによるアクセス制御を行っているが、文書管理ソフトウェアにおいて、複数のユーザをまとめて管理するためのユーザグループの概念がある場合には、ユーザグループ単位でアクセス制御を行ってもよい。
【図面の簡単な説明】
【００５８】
【図１】文書管理システムの構成の一例。
【図２】バインダソフトウェアの処理の一例。
【図３】バインダソフトウェアの画面構成例。
【図４】アクセス可能なユーザＩＤとＩＰアドレスのフィールドが設けられた文書管理テーブルの例。
【図５】文書管理システムとバインダソフトウェアの表示例。
【図６】文書管理テーブルの例。
【図７】情報が埋め込まれてエクスポートされた文書の例。
【図８】文書をエクスポートすることを説明するフローチャート。
【図９】エクスポートされた文書を編集対象として開くことを説明するフローチャート。
【図１０】文書編集後の文書登録処理を説明するフローチャート。
【図１１】更新文書リスト保持できる文書管理テーブルの例。
【技術分野】
【０００１】
本発明は、電子的な文書管理システムに関するものである。
【背景技術】
【０００２】
企業ではドキュメント管理システムを導入し、文書の再利用を推進しようとしている。初期の製品は紙の文書をスキャナで画像として取り込み、登録保存うるようなものであったが、最近はパソコンで作られた文書が多くなり、それも登録保存できるようになってきた。
【０００３】
文書管理システムにおいては、様々な文書をデータベース内に保存し、複数の利用者から共有される形態を取る。文書管理システムでは、文書の実体を表すデータを保持するとともに、前記文書に付随する様々な文書情報も保持している。文書管理システム内で、文書の登録、削除や更新処理を行うことができる。
【０００４】
また、最近では登録されている複数の文書から任意のページを抜き出してバインダのように綴じて一つの文書のようにすることもできるようになっている。それをここでは電子バインダと呼ぶ。
【０００５】
従来は文書更新を行う際に、文書管理システムのクライアントソフトウェア全体をインストールする必要があった。一般に、文書管理システムのクライアントソフトウェアは、機能を多く有し、巨大なソフトウェアであり、また、データベースの接続を設定する必要があるなど、ユーザ環境によって文書管理システムを導入することが困難であった。そのため、文書管理システムを導入していないユーザに対しては、文書管理システムの文書を一旦ファイルとして保存して、電子メールや物理的なＣＤ−ＲやＭＯなどのメディアによって前記文書管理システムを導入していないユーザに渡すなどをしていた。更には、更新後に再度前記文書管理システムを導入していないユーザが編集された文書を電子メール等により文書管理システムを導入しているユーザに送付し、前記文書管理システムを導入しているユーザが、文書管理システムに再登録、もしくは文書の更新作業を行う。
【０００６】
又、従来例としては、例えば特許文献１をあげることが出来る。
【特許文献１】特開2003-173329号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
文書管理システムを導入していないユーザに対して文書更新を依頼する場合は、文書を一旦アプリケーションが扱えるファイルにして送付し、編集後に再度更新済みファイルを受信し、文書管理システムに再登録、あるいは更新するため、ユーザの手間が掛かった。
【０００８】
また、一旦ファイル化するために、文書管理システム外に文書が流通してしまい、不正利用される可能性がある。
【課題を解決するための手段】
【０００９】
本発明は、
文書を登録する手段と、前記登録された文書を更新する手段を持ち、文書に関する情報を文書管理テーブルとして保持する、文書管理システムにおいて、文書を外部へ保存する際に、前記文書に関する情報が保持されているサーバのＵＲＬ情報と、文書を特定するための文書ＩＤと、前記文書より求められるハッシュ値を前記文書中に埋め込み、更には、文書を外部にエクスポート中には他ユーザが前記文書を操作できないようにロックを行い、文書を更新する際に、前記文書中に埋め込まれたハッシュ値と実文書データから求められるハッシュ値と文書管理テーブル内に保持されたハッシュ値とを比較して文書の更新を認めることを特徴とする文書更新方法であるので、
文書管理システムを導入していないユーザに対して文書更新を依頼する場合は、文書を一旦アプリケーションが扱えるファイルにして送付し、編集後に再度更新済みファイルを受信し、文書管理システムに再登録、あるいは更新するため、ユーザの手間が掛かかり、
また、一旦ファイル化するために、文書管理システム外に文書が流通してしまい、不正利用される可能性があることが解消される。
【発明の効果】
【００１０】
以上述べてきたように、文書を登録する手段と、前記登録された文書を更新する手段を持ち、文書に関する情報を文書管理テーブルとして保持する、文書管理システムにおいて、文書を外部へ保存する際に、前記文書に関する情報が保持されているサーバのＵＲＬ情報と、文書を特定するための文書ＩＤと、前記文書より求められるハッシュ値を前記文書中に埋め込み、更には、文書を外部にエクスポート中には他ユーザが前記文書を操作できないようにロックを行い、文書を更新する際に、前記文書中に埋め込まれたハッシュ値と実文書データから求められるハッシュ値と文書管理テーブル内に保持されたハッシュ値とを比較して文書の更新を認めることを特徴とする文書更新方法によって、文書管理システムを導入していないユーザに対して文書更新を依頼する場合は、文書を一旦アプリケーションが扱えるファイルにして送付し、編集後に再度更新済みファイルを受信し、文書管理システムに再登録、あるいは更新するため、ユーザの手間が掛かかり、また、一旦ファイル化するために、文書管理システム外に文書が流通してしまい、不正利用される可能性があることが解消される。
【発明を実施するための最良の形態】
【００１１】
以下、図面を参照して本発明を説明する。
【実施例１】
【００１２】
本発明は、文書管理システムに関する発明である。
【００１３】
図１に本発明における文書管理システムの構成を表す図である。１０１は、クライアントＰＣであり、この中に文書管理ソフトウェアのクライアントソフトが存在している。１０２は、文書データサーバであり、この中に文書管理システムに入力された文書の実体が格納される。文書に付随する作成者や作成日、更新日などの情報は、１０３の文書情報サーバ内に格納される。これら、クライアントＰＣ１０１、文書データサーバ１０２、文書情報サーバ１０３は、ネットワーク１０５で結ばれている。ここで、ネットワーク１０５は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）である場合が多い。図１においては、説明の簡便化のために、クライアントＰＣ１０１を１台にしてあるが、通常の文書管理システムの運用においては、複数台のクライアントＰＣが存在する。また、ネットワークを介して、文書管理ソフトウェアのクラインとソフトが存在しないクライアントＰＣ１０４がある。
【００１４】
具体的に、文書を文書管理システムに登録する処理について説明する。クライアントＰＣ１０１において、文書管理ソフトウェアのクライアントソフトを用いて文書を登録すると、当該文書の実体を文書データサーバ１０２へ格納し、当該文書の作成者や更新日時、要約、検索情報、サムネイルなどの付随する文書情報が、文書情報サーバ１０３に格納される。文書管理ソフトウェアのクライアントソフトにおいて、検索、サムネイル表示等の文書に付随する情報を表示するときは、文書情報サーバから情報を得て表示を行い、また、文書の実データにアクセスする必要のある場合は、文書データサーバから文書データを取得する。
【００１５】
本実施例によると、文書管理システムのクライアントソフトウェアが無い環境、すなわちクライアントＰＣ１０４のような環境においても、文書データサーバのデータを更新することが可能となる。以下、具体的に説明を行う。
【００１６】
まず、本実施例を説明するための文書フォーマットとして、電子バインダ文書を説明する。
【００１７】
電子バインダ文書は、異なる文書を統一的なフォーマットに変換する。たとえば、TIFFやビットマップファイルのような画像フォーマット、あるいは、PDF、また、World Wide Web Consortiumで作成されたSVGなどでページデータを表す。そして、変換されたページデータを基にページや文書の順番の入れ替えや回転、削除などの編集操作を行う。
【００１８】
この統一的なフォーマットへの変換には、ページデータを確定させる必要があるために、アプリケーションから印刷を実行することで、ページデータを生成させる方法がある。このとき、所望のページデータフォーマットに変換するために、プリンタドライバを用いて、ページデータを統一的なフォーマットに変換する。これは、図２に示すように、バインダ生成プログラム２０１がバインダに取り込みたいアプリケーションファイル２０２に関連付いたアプリケーション２０３を起動させ、特定の統一フォーマットへ変換するプリンタドライバ２０４を用いて印刷させるように実行する。プリンタドライバによって生成されたデータをページデータとしてバインダ内部に取り込む。
【００１９】
ここで、アプリケーションを起動して特定のプリンタドライバで印刷することによって、ページデータ生成して電子バインダ文書に取り込む方式について説明したが、特定のアプリケーションに関連付かないファイルフォーマット、たとえば画像フォーマットなどは、アプリケーションを起動しないで、直接、統一的なフォーマットに変換してもよい。
【００２０】
電子バインダ文書の中には、変換されたページデータとともにオリジナル文書データを持ってもよい。オリジナル文書データとは、変換に利用された元となるデータのことである。電子バインダ文書では、オリジナル文書データを持つ場合に、電子バインダ文書のページとして利用されている変換されたページがオリジナル文書データの何ページに相当するのか覚えている。すなわち、電子バインダ文書内のページ番号から、オリジナル文書とその何ページ目に相当するか判明し、逆にオリジナル文書内の特定のページが電子バインダ文書の何ページ目に相当するか分かる。
【００２１】
図５に一つの事例のソフトウェアのＧＵＩを用いて、説明を行う。５０１は、文書管理ソフトウェアの例である。５０２は、コンピュータのOS上で管理されたファイル管理の例である。５０３は、本発明の事項を処理するバインダソフトウェアの例である。５０４は、オリジナル文書を管理するＤｏｃｕｍｅｎｔ Ｌｉｓｔである。５０５は、オリジナルの各ページを表示するＰａｇｅ Ｖｉｅｗである。５０６は、バインダ文書を管理するＷｏｒｋｓｐａｃｅである。５０７は、電子バインダ文書を表示するための表示ソフトウェアである。
【００２２】
図５では、たとえば、文書管理ソフトウェア５０１やOＳのファイル管理５０２からマウスによるドラッグ＆ドロップによってバインダソフトウェアにオリジナル文書を持ってくると、先に説明したプリンタドライバなどによる統一フォーマットへの変換を行う。このとき、このシステムでは、オリジナル文書を電子バインダ文書内に取り込み、Ｄｏｃｕｍｅｎｔ Ｌｉｓｔにオリジナル文書の一覧が表示され、Ｐａｇｅ Ｖｉｅｗに選択されたオリジナル文書の各ページが表示されている。Ｗｏｒｋｓｐａｃｅ、ＤｏｃｕｍｅｎｔＬｉｓｔ、ＰａｇｅＶｉｅｗには、各ページを縮小表示したサムネイルを用いて表示される。
【００２３】
このバインダソフトウェアの例では、ＤｏｃｕｍｅｎｔＬｉｓｔやＰａｇｅＶｉｅｗからＷｏｒｋｓｐａｃｅにページや文書を移動することで、電子バインダ文書としてのデータを構築していく。また、Ｗｏｒｋｓｐａｃｅ内でページの並べ替えなどが行える。
【００２４】
また、電子バインダ文書のページ構成としてより簡潔に行うために、ＰａｇｅＶｉｅｗが存在せずに文書単位で電子バインダ文書を構成することが可能である。このようなバインダソフトウェアの例として、図３を用いて説明する。３０１は図５と同じようにＷｏｒｋｓｐａｃｅであり、バインダデータを表す。Ｗｏｒｋｓｐａｃｅ３０１が５０６と異なるのは、ここで扱われるのが、文書単位のデータになることである。たとえば、図３では、Ｗｏｒｋｓｐａｃｅに３文書あり、それぞれ３０３、３０４、３０５である。それぞれ文書の先頭ページのサムネイルが表示され、また、サムネイルの隅にどのようなアプリケーションのファイルであるかを示すアイコンが付加されている。
【００２５】
ＤｏｃｕｍｅｎｔＬｉｓｔ３０２には、バインダ内のオリジナル文書の一覧が表示される。このとき、３０６のように、文書名とこの文書に関連付いたアプリケーションのアイコンが表示される。もし、３０７のようにアイコンが表示されていない場合は、バインダ内にオリジナル文書は入っておらず、変換後のページデータだけが入っている。
【００２６】
本実施例では、電子バインダ文書を例に説明する。電子バインダ文書を文書管理システムからエクスポート（取り出す）する。これは、クライアントＰＣ１０１から電子バインダ文書をエクスポートすることと同義である。電子バインダ文書をクライアントＰＣ１０１からエクスポートするときに、文書データサーバ１０２から文書の実データが取り出される。更に、文書情報サーバ１０３の文書情報に対してロックされた旨の情報が記述される。
【００２７】
例えば、文書情報として、図６に示すような文書管理テーブルによって管理されているとする。なお、図６は文書情報の一部であり、この他に文書に関連する情報が格納されているものとする。６０１は、文書ＩＤであり、当該文書管理システム内で文書を唯一に特定するＩＤである。同一文書管理システム内において、この文書ＩＤ６０１が重なることはない。６０２は、ロックフラグである。各文書がロックされているかを示すものであり、これは、文書を共有する際に誰かが編集を行っているときに他ユーザが変更できなくするためのフラグである。更に、６０６に編集ユーザＩＤフィールドがあり、編集中の場合にはこの６０６に編集しているユーザを特定する一意なＩＤが与えられる。６０２のロックフラグが立っている場合には、文書がロックされており、編集ユーザＩＤ６０６で指定された文書の編集ユーザ以外は、当該文書の編集が行えない。文書の編集終了後に、ロックフラグ６０２と編集ユーザＩＤフィールド６０６はクリアされる。
【００２８】
６０３は、エクスポートロックフラグである。文書がエクスポートされた場合に、このフラグが立つ。このとき、ロックフラグ６０２と同様に、エクスポートユーザＩＤフィールド６０７があり、エクスポートしたユーザを特定するＩＤが記載される。文書のエクスポート中は他ユーザが編集等の文書関連の操作を行えなくなる。更に、文書をエクスポートする際には、文書データからハッシュ関数によってハッシュ値が計算される。このハッシュ値の計算には公知の技術であるハッシュ関数を利用する。例えば、ＲＦＣ１３２１（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ）で規定されるＭＤ５を利用する。この値が６０４のハッシュ値フィールドに与えられる。６０８は、エクスポートパスワードフィールドであり、エクスポートする際にパスワードを設定した場合には、６０８にパスワードが格納される。アクセスする際に、パスワードを確認することにより、認証を行える。
【００２９】
また、６０５には、ユーザＩＤフィールドがあり、この文書の所有者のＩＤが格納さえる。文書情報のテーブルはこの限りではなく、例えば、更新日時、サムネイル情報といった文書情報や、本実施例で触れていないが、ユーザ間におけるアクセス権の設定、あるいは、グループを定義することによりグループでのアクセス権などの情報を与えることも可能である。
【００３０】
図６中には明示していないが、文書データの実体がどの文書データベースのどこにあるかと言った情報も文書管理テーブル内に格納されているものとする。
【００３１】
文書をエクスポートするときに、先に記したようにハッシュ値を計算する。計算したハッシュ値を実文書データに埋め込み、その文書をエクスポートする。具体的には、図７に示すように、実文書データ７０１に対して、ハッシュデータ７０２を付加する。なお、この実施例においては、先頭に付加しているが、末尾や中間に存在させるようにさせてもよい。先に説明したように、ハッシュ関数としてＭＤ５を利用する場合は、ハッシュデータ７０２は、１２８ビットとなる。更には、文書情報サーバのＵＲＬ情報をＵＲＬフィールド７０３に格納する。当該文書の文書ＩＤを文書ＩＤフィールド７０４に格納する。
【００３２】
文書をエクスポートすると、先に述べたようにエクスポートロックフラグ６０３が有効になり、エクスポートユーザＩＤフィールド６０５にエクスポートしたユーザＩＤが記載される。また、文書から計算されて実データに埋め込まれたハッシュ値をハッシュ値フィールド６０４に書き込む。
【００３３】
エクスポートする処理について、図８のフローチャートを利用して説明する。Ｓ８０１でエクスポートしよとする文書のロックフラグ６０２が有効であるか判断する。有効であれば、文書が自分、もしくは他のユーザによって利用されているため、エクスポートできないので、処理を終了する。ロックフラグ６０２が有効でなければ、Ｓ８０２へ進み、ロックフラグ６０２を有効にする。６０６編集ユーザＩＤフィールドに自らのユーザＩＤを格納する。このようにロックすることで、他ユーザが当該文書を編集できないようにする。
【００３４】
Ｓ８０３へ進み、文書データを文書データベースより取り出す。Ｓ８０４において、ハッシュ値を計算する。Ｓ８０５では、計算されたハッシュ値を６０４ハッシュ値フィールドに格納する。Ｓ８０６に進んで、前記ハッシュ値、文書情報サーバのＵＲＬ情報、文書ＩＤを文書データに埋め込む。Ｓ８０７へ進み、６０３エクスポートロックフラグを立てる。Ｓ８０８で、６０７エクスポートユーザＩＤフィールドにエクスポートを実行したユーザＩＤを記載する。Ｓ８０９では、Ｓ８０６で情報が埋め込まれた文書データをディスク上の所望の場所に移動する。Ｓ８１０で、Ｓ８０１で立てた６０２ロックフラグを解除する。
【００３５】
図８の処理に従えば、文書更新のために必要なデータを付加した文書をエクスポートすることが可能となる。
【００３６】
前記文書更新のために必要なデータを付加した文書を電子メールや物理的なメディアを媒体として他ユーザに送付する。前記他ユーザが文書管理ソフトウェアのクライアントソフトを所持していなければ直接更新することができないが、本実施例においては、バインダの編集機能のみを有するソフトウェアでのみ文書の編集、更新処理を行うことが可能となる。以下では、前記文書更新のために必要なデータを付加した文書をエクスポートされた文書とする。
【００３７】
これは、ユーザが前記エクスポートされた文書を起動したときに、文書中に含まれる文書情報サーバのＵＲＬ情報７０３に対してアクセスを行い、文書管理テーブルにおける文書ＩＤ７０４で特定される文書に対応する６０４ハッシュ値フィールドと、前記起動した文書データ中のハッシュ値７０２と、実文書データ７０１から再度求めたハッシュ値の３つの値を比較する。前記エクスポートされた文書データ中のハッシュ値７０２と、実文書データ７０１から再度求めたハッシュ値が異なっていれば、実文書データが変更されている、もしくは文書データ中のハッシュ値が変更されていることが分かり、起動を認めない。また、文書管理テーブルにおける文書ＩＤ７０４で特定される文書に対応する６０４ハッシュ値フィールドと、前記エクスポートされた文書データ中のハッシュ値７０２が異なっている場合も、変更があったものとして起動を認めない。
【００３８】
当該文書、すなわちバインダ文書を編集して、保存するときには、再度文書情報サーバＵＲＬ７０３で指定される文書情報サーバにアクセスを行い、文書データベースの格納されているデータに対して、更新処理を行う。更新処理でなくても、新規に文書の追加処理でも構わない。
【００３９】
以下、図９のフローチャートを用いて上記処理を説明する。Ｓ９０１で、エクスポートされた文書データより、ハッシュ値を取り出す。Ｓ９０２では、エクスポートされた文書データより、文書ＩＤを取り出す。Ｓ９０３では、エクスポートされた文書データより、文書情報サーバのＵＲＬ情報を取り出す。Ｓ９０４では、エクスポートされた文書データより、実文書データを取り出す。ここで、実文書データは、ファイルなどの物理的にアクセス可能な媒体として取り出すのではなく、コンピュータにおけるメモリ上に展開して取り出すようにする。このようにすることによって、編集ユーザが実文書データを取得できないようにする。
【００４０】
Ｓ９０５では、Ｓ９０４で取り出された実文書データに対してハッシュ値を計算する。このハッシュ値の計算方法は、文書情報サーバで計算されるものと同一である。Ｓ９０６では、Ｓ９０５で計算されたハッシュ値とＳ９０１で取り出されたハッシュ値が同一かを判断する。同一でない場合は、処理を終了する。同一の場合は、Ｓ９０７へ進み、Ｓ９０３で得られた文書情報サーバのＵＲＬにアクセスが可能であるかを判断する。アクセス不可能であれば、処理を終了する。アクセス可能であれば、Ｓ９０８へ進む。Ｓ９０８では、Ｓ９０１で取り出されたハッシュ値と文書管理テーブルにおいてＳ９０２で取り出された文書ＩＤに対応する６０４ハッシュ値フィールドの値との比較を行う。同一でなければ、処理を終了する。同一であれば、Ｓ９０９へ進む。Ｓ９０９では、当該文書に対するエクスポートパスワードフィールド６０８にパスワードが設定されているか調べる。パスワードが設定されていなければ、Ｓ９１２へ進む。パスワードが設定されていれば、Ｓ９１０へ進みパスワードの入力をユーザに行われせる。Ｓ９１１では、入力したパスワードを確認して、異なっていれば、再度入力させるためにＳ９１０へ戻る。なお、本実施例のフローチャートでは、パスワードの入力を何度でも認めるようになっているが、規定回パスワードを間違えたらアクセスできなくするような仕組みであってもよい。なお、パスワードの確認方法については、本実施例の範疇ではなく、公知の技術を用いればよい。パスワードが正しければ、Ｓ９１２へ進む。Ｓ９１２では、Ｓ９０４で取り出された実データを編集可出来るように開く。
【００４１】
なお、Ｓ９１０でパスワードの確認を行っているが、このパスワードはエクスポートしたユーザが設定したパスワードであり、このパスワードを知っていれば文書管理ソフトウェアのユーザでなくとも文書更新が可能である。文書管理ソフトウェアのユーザに限定したい場合は、Ｓ９１０において、文書管理ソフトウェアにおけるユーザＩＤとパスワードの確認を行うようにすればよい。
【００４２】
本実施例では、先に説明した文書管理システムの一機能であるバインダ機能を利用しているために、実文書データの取り出しによって一時的に利用可能なファイルを出力することによるセキュリティの低下を防御できる。これは、一般アプリケーションであれば、前記アプリケーションが文書を読み込めるようにするために、ディスク上などにファイルで存在する必要がある。本実施例では、バインダであるので実文書データ取り出した際に直接データをアプリケーション（バインダビューア）に展開できるため、悪意のあるユーザによる不正使用を防げる。
【００４３】
以上が、文書を開くときの処理を説明するフローチャートである。編集については、先に説明したように行う。
【００４４】
文書を編集後について、図１０のフローチャートを用いて説明を行う。Ｓ１００１において、文書情報サーバを経由して、実文書を文書データベースに登録する。Ｓ１００２では、文書情報サーバに対して新規に文書を登録する。なお、文書を新規に登録するのではなく、当該文書を上書きによる更新、あるいは、バージョン管理による新規バージョン登録による更新を行ってもよい。Ｓ１００３では、６０４ハッシュ値フィールドに対して、無効な値を入れることで再更新をできなくする。
【００４５】
エクスポートを実行したユーザが、文書管理システムのクライアントソフトウェアを用いて当該文書にアクセスした場合、６０４ハッシュ値フィールドが無効な値になっていることから、当該文書に対して更新が行われたことを把握できる。エクスポートを実行したユーザは、更新文書を受け入れる、あるいは別名として保存するなど文書管理システム上で処理を行う。文書更新を完了したあとは、エクスポートロックフラグ６０３が解除され、エクスポートユーザＩＤフィールド６０５とハッシュ値フィールド６０４がクリアされる。
【００４６】
なお、本実施例中で、通信に用いるプロトコルとして言明していないが、例えば、公知の技術であるセキュリティ機能を有するｈｔｔｐｓ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ）などを用いる。
【００４７】
文書フォーマット内部にＵＲＬ情報を持つものとして、特開２００３−１７３３２９「文書管理システム」があるが、これは、複数の文書保存サービスが存在している環境で保存位置を明確にするものであり、ディレクトリサービスに文書位置を登録し、各クライアント上にファイルが存在するため、本発明による文書管理システムのように一意に管理された文書を対象としていない。
【００４８】
本実施例では、文書を編集する対象として、バインダ文書としたが、バインダ文書に限らず、ワードプロセッサや表計算ソフトウェアなど一般のアプリケーション文書を実文書データとしてもよい。但し、実文書データが一般のアプリケーション文書である場合には、実文書データを取り出した段階で、編集作業を行うユーザが、実文書データを取得することが可能となる。バインダ文書の場合は、文書管理ソフトウェアに依存したフォーマットであるため、実文書データを取得することができてしまう。実文書データを取得できてもよい場合には、一般のアプリケーション文書に対しても適用することが可能である。バインダ文書で無く、一般のアプリケーションを対象文書とすることにより、本実施例の図２、図３、図５で説明した文書編集機能が不要となり、実文書データと文書情報取り出し機能、及びハッシュ値による文書検証機能、及び文書更新機能のみの実装されたモジュールとなり、文書管理システムを導入できないユーザにとって、より軽快に扱うことが可能となる。
【００４９】
以上説明したように、本発明によれば、文書管理システムにおけるクライアントソフトウェアにおいて、クライアントソフトウェアが無い環境でも文書更新を行うことができる。
【実施例２】
【００５０】
実施例１においては、単一のユーザからの更新のみを対象としていたが複数のユーザからの更新処理を行えるようにしてもよい。
【００５１】
図１１に示す文書管理テーブルのように、１１０１更新データリンクリストを設ければよい。１１０１は、リストの参照先を表し、更新データリンクリストは、１１０３のようなリスト形式で表される。複数ユーザから文書更新を行った場合の具体的な動作について説明する。各ユーザより文書更新がなされる度に、更新された文書は新規文書として登録される。このときに新規文書ＩＤが付与されるが、１１０２の更新文書フィールドを設け、ここに更新前の文書を表す親文書ＩＤが格納され、この文書は通常では扱えない文書となる。更新の確認のみ行える。
【００５２】
更新データリンクリストは、１１０４文書ＩＤフィールド、１１０５ユーザＩＤフィールド、１１０６更新日時フィールドからなる。文書更新を行うために、ユーザが文書情報サーバにアクセスしてきた場合には、実文書データを新規文書として登録して、文書ＩＤを取得する。ただし、１１０２の更新文書フィールドに親文書ＩＤを入れ、通常の文書として扱えない文書とする。取得した文書ＩＤを１１０４文書ＩＤフィールドにいれ、また、アクセスしてきたユーザＩＤを１１０５ユーザＩＤフィールドに格納する。ここで、先の実施例１で説明したように、文書管理ソフトウェアでないユーザがアクセスした場合には、特定のキーワードを入れる、アクセスしてきたコンピュータのＩＰアドレスを入れる、ユーザにユーザ名を入れさせる、ＯＳのユーザ名を利用するなどの仕組みがある。また、１１０６には、更新を行った日時が格納される。
【００５３】
具体的には、図１１において、文書ＩＤが００１５２ものがエクスポートされたとする。エクスポートされた文書は、ユーザＩＤがＵ００７７３のユーザによって編集され、文書管理ソフトに再登録されたとする。この再登録された文書が、文書ＩＤ００６４９で表される文書である。更新文書であるため、１１０２更新文書フィールドには、親文書の文書ＩＤである００１５２が入り、通常では見られない文書となる。この文書は、文書ＩＤ００１５２の１１０１更新データリンクリストの示される更新データリンクリスト内にユーザ情報や日時とともに情報が収められ、００１５２の文書とともに前記００６４９の文書にアクセスすうことが可能となる。
【００５４】
エクスポートを行ったユーザは、各文書を比較して、必要な文書のみを登録したり、文書をまとめたりすることで、文書更新を完了する。なお、文書更新を完了した際に、エクスポートロックフラグ６０３が解除され、エクスポートユーザＩＤフィールド６０５とハッシュ値フィールド６０４がクリアされることにより、更なる文書更新を認めないようにする。
【００５５】
また、本実施例によれば、実施例１では、一度しかユーザに更新の機会を与えなかったが、１ユーザが複数回文書を更新するように認めるようにしてもよい。このとき、ユーザＩＤによって区別を行っているため、同一ユーザからの複数の更新は、最新の更新だけを取っておくようにすることも可能である。
【実施例３】
【００５６】
実施例１、２においては、無条件にアクセスを更新を認めていたが、アクセス可能なユーザやＩＰアドレスを設定してアクセス制限を掛けてもよい。
【００５７】
図４に示す文書管理テーブルのように、１２０１アクセス可能ユーザリリスト、１２０２アクセス可能ＩＰアドレスリストを設ける。１２０１は、アクセスが可能なユーザＩＤの一覧を表すリストへの参照を表す。アクセス可能なユーザＩＤリストは、１２０３に示すように、アクセスを許可するユーザＩＤに対しては、「＋」を付与し、アクセスを拒否するユーザＩＤに対しては「−」を付与する。同様に、１２０２はアクセス可能なＩＰアドレスの一覧を表すリストへの参照を表す。アクセス可能なＩＰリストは、１２０４に示すように、アクセスを許可するＩＰアドレスに対しては、「＋」を付与し、アクセスを拒否するＩＰアドレスに対しては「−」を付与する。ここで、ＩＰアドレスに対しては、例えば「192.10.1.*」のように、アスタリスク（＊）を用いて一定の範囲のＩＰアドレス全てをアクセス許可、不許可にしてもよい。また、本実施例では、１２０１、１２０３において、ユーザＩＤによるアクセス制御を行っているが、文書管理ソフトウェアにおいて、複数のユーザをまとめて管理するためのユーザグループの概念がある場合には、ユーザグループ単位でアクセス制御を行ってもよい。
【図面の簡単な説明】
【００５８】
【図１】文書管理システムの構成の一例。
【図２】バインダソフトウェアの処理の一例。
【図３】バインダソフトウェアの画面構成例。
【図４】アクセス可能なユーザＩＤとＩＰアドレスのフィールドが設けられた文書管理テーブルの例。
【図５】文書管理システムとバインダソフトウェアの表示例。
【図６】文書管理テーブルの例。
【図７】情報が埋め込まれてエクスポートされた文書の例。
【図８】文書をエクスポートすることを説明するフローチャート。
【図９】エクスポートされた文書を編集対象として開くことを説明するフローチャート。
【図１０】文書編集後の文書登録処理を説明するフローチャート。
【図１１】更新文書リスト保持できる文書管理テーブルの例。
【特許請求の範囲】
【請求項１】
文書を登録する手段と、前記登録された文書を更新する手段を持ち、文書に関する情報を文書管理テーブルとして保持する、文書管理システムにおいて、文書を外部へ保存する際に、前記文書に関する情報が保持されているサーバのＵＲＬ情報と、文書を特定するための文書ＩＤと、前記文書より求められるハッシュ値を前記文書中に埋め込み、更には、文書を外部にエクスポート中には他ユーザが前記文書を操作できないようにロックを行い、文書を更新する際に、前記文書中に埋め込まれたハッシュ値と実文書データから求められるハッシュ値と文書管理テーブル内に保持されたハッシュ値とを比較して文書の更新を認めることを特徴とする文書更新方法。
【請求項２】
前記請求項１に記載の文書管理システムにおいて、パスワードによる認証を行うことを特徴とする文書更新方法。
【請求項３】
前記請求項１ないしは２に記載の文書管理システムにおいて、複数の更新文書を保持する文書更新データリストを有することを特徴とする文書更新方法。
【請求項４】
前記請求項１ないしは２ないしは３に記載の文書管理システムにおいて、文書更新を認めるユーザを指定するためのアクセス可能ユーザリスト、及びＩＰアドレスを指定するためのアクセス可能ＩＰアドレスリストを持つことを特徴とする文書更新方法。
【請求項５】
前記請求項４に記載の文書管理システムにおいて、アクセス可能ユーザリストで文書更新を認めないユーザを指定することを特徴とし、アクセス可能ＩＰアドレスリストで文書更新を認めないＩＰアドレスを指定することを特徴とする文書更新方法。
【請求項６】
前記請求項１から請求項５に記載の文書管理システムにおいて、利用対象文書がバインダ文書であることを特徴とする文書更新方法。
【請求項７】
前記請求項１から請求項５に記載の文書管理システムにおいて、利用対象文書を問わないことを特徴とする文書更新方法。
【請求項１】
文書を登録する手段と、前記登録された文書を更新する手段を持ち、文書に関する情報を文書管理テーブルとして保持する、文書管理システムにおいて、文書を外部へ保存する際に、前記文書に関する情報が保持されているサーバのＵＲＬ情報と、文書を特定するための文書ＩＤと、前記文書より求められるハッシュ値を前記文書中に埋め込み、更には、文書を外部にエクスポート中には他ユーザが前記文書を操作できないようにロックを行い、文書を更新する際に、前記文書中に埋め込まれたハッシュ値と実文書データから求められるハッシュ値と文書管理テーブル内に保持されたハッシュ値とを比較して文書の更新を認めることを特徴とする文書更新方法。
【請求項２】
前記請求項１に記載の文書管理システムにおいて、パスワードによる認証を行うことを特徴とする文書更新方法。
【請求項３】
前記請求項１ないしは２に記載の文書管理システムにおいて、複数の更新文書を保持する文書更新データリストを有することを特徴とする文書更新方法。
【請求項４】
前記請求項１ないしは２ないしは３に記載の文書管理システムにおいて、文書更新を認めるユーザを指定するためのアクセス可能ユーザリスト、及びＩＰアドレスを指定するためのアクセス可能ＩＰアドレスリストを持つことを特徴とする文書更新方法。
【請求項５】
前記請求項４に記載の文書管理システムにおいて、アクセス可能ユーザリストで文書更新を認めないユーザを指定することを特徴とし、アクセス可能ＩＰアドレスリストで文書更新を認めないＩＰアドレスを指定することを特徴とする文書更新方法。
【請求項６】
前記請求項１から請求項５に記載の文書管理システムにおいて、利用対象文書がバインダ文書であることを特徴とする文書更新方法。
【請求項７】
前記請求項１から請求項５に記載の文書管理システムにおいて、利用対象文書を問わないことを特徴とする文書更新方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２００７−３４９３３（Ｐ２００７−３４９３３Ａ）
【公開日】平成１９年２月８日（２００７．２．８）
【国際特許分類】
【出願番号】特願２００５−２２０８１７（Ｐ２００５−２２０８１７）
【出願日】平成１７年７月２９日（２００５．７．２９）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成１９年２月８日（２００７．２．８）
【国際特許分類】
【出願日】平成１７年７月２９日（２００５．７．２９）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]