(57)【要約】【課題】文書ファイルに対する処理を依頼するに際し、一部の担当者に処理の依頼が集中すると、業務全体として支障をきたすことになる。【解決手段】提供部１０６は担当者に対して、文書ファイル格納部１０４に格納する文書ファイルを提供する。一方、処理部１１４はユーザによる文書ファイル処理を実行する。そして、処理状況格納部１１０において、ユーザごとの文書ファイル処理の状況が管理されている。設定部１１２は、文書ファイル処理を依頼するユーザを選択するに際して、この各ユーザの処理の状況を参照する。これにより、特定のユーザに処理依頼が殺到するという弊害を回避できる。【選択図】        図２
2004326269.tif 000002
【特許請求の範囲】
【請求項１】
文書ファイルを記憶装置に記憶する格納手段と、
前記文書ファイルに対する処理を担当し得るユーザのリストを登録する登録手段と、
前記リストから、前記文書ファイルの処理を担当するユーザを選択する設定手段と、
前記設定手段により選択された前記ユーザに前記文書ファイルを提供する提供手段と、
前記ユーザの処理状況を検出する検出手段と、
を含み、前記登録手段は、前記検出手段が検出した、各ユーザの処理状況に応じて、前記リストを変更することを特徴とする文書管理装置。
【請求項２】
前記登録手段は、前記検出手段が検出した、各ユーザがそれぞれ処理すべき未処理文書ファイルの量に応じて、前記リストを変更することを特徴とする請求項１に記載の文書管理装置。
【請求項３】
前記検出手段が検出した、各ユーザの処理状況を表示する表示手段を更に含むことを特徴とする請求項１または２に記載の文書管理装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は文書管理技術に関し、とくに、電子化された文書ファイルを取り扱うための技術に関する。
【０００２】
【従来の技術】
ネットワーク技術の発達にともない、ネットワークとの接続機能を有するプリンタ、スキャナ、ファックス、ＭＦＰ（Ｍｕｌｔｉ  Ｆｕｎｃｔｉｏｎａｌ  Ｐｅｒｉｐｈｅｒａｌ）などの機器が普及している。また、ネットワーク化は、例えば社内、ビル内などの限られた範囲のローカルエリアネットワーク（以下、単に「ＬＡＮ」という）に限られるものではない。現在では、ネットワーク化は地球全体規模のネットワーク、いわゆるワイドエリアネットワーク（以下、単に「ＷＡＮ」という）にまで拡大している。こうしたインフラストラクチャーの整備が進むにつれて、例えばビジネスシーンにおいても電子メール、ＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）、ウェブページなどが広範に活用されるようになった。
【０００３】
ネットワーク技術がビジネスに活用されることで、実際の業務体系も徐々に変わりつつある。その一つに、ワークフローシステムの導入があげられる。このシステムは、伝票、帳票、稟議書などの紙ベースの回覧文書を関係者に順次回覧して行っていた従来の業務を、電子的に各担当者のコンピュータに送信することで業務の効率化を図るものである。
【０００４】
【特許文献１】
特開平９−３０５６５７号公報
【０００５】
【発明が解決しようとする課題】
ワークフローシステムにおいては、担当者の処理が遅れると、全体の業務を円滑に行う上で支障となる。特に、一部の担当者に対して、複数の文書ファイル処理依頼が殺到した場合に、このような事態が生じやすい。
【０００６】
本発明は上記課題に鑑みてなされたものであり、その目的は、ユーザの状況に応じて、文書ファイルの処理をすべき担当者を適切に選択するための技術、または、効率的な文書ファイルの管理を行うための技術、の提供にある。
【０００７】
【課題を解決するための手段】
本発明のある態様は、文書管理装置である。この装置は、文書ファイルを記憶装置に記憶する格納手段と、文書ファイルに対する処理を担当し得るユーザのリストを登録する登録手段と、このリストから、文書ファイルの処理を担当するユーザを選択する設定手段と、設定手段により選択されたユーザに文書ファイルを提供する提供手段と、ユーザの処理状況を検出する検出手段を含み、登録手段は、検出手段が検出した、各ユーザの処理状況に応じて、このリストを変更することを特徴とする。
【０００８】
「文書ファイル」は、例えば文字列、画像、音声などを含むデジタルデータである。実際のシステムでは、このデジタルデータが担当者のコンピュータ（以下、単に「クライアント」という）に送信され、クライアント側で解析され表示または音声として出力される。このように文書ファイルとは、従来の紙ベースの文書を単に画像ファイルにしたものだけでなく、所定のアプリケーションで生成されたファイルや音声ファイルなどのデジタルデータも含むものである。
【０００９】
「リスト」とは、文書ファイルに対する処理（以下、単に「文書ファイル処理」とよぶ）を担当できるユーザ（以下、「候補者」とよぶ）のリストをいう。以下、文書ファイル処理を担当するユーザを「担当者」という。担当者は候補者から選ばれる。リストに登録される候補者は一人であってもよい。
【００１０】
担当者を設定するに際して、その担当者が既に多くの文書ファイル処理を担当している場合がある。あるいは、その担当者が会議などにより在席していない場合もある。このような場合、たとえば、その担当者を候補者のリストから外すことにより、全体として文書ファイル処理が滞るのを事前に回避できる。
【００１１】
また、この装置の登録手段は、検出手段が検出した、各ユーザがそれぞれ処理すべき未処理文書ファイルの量に応じて、リストを変更してもよい。あるいは、この装置は、検出手段が検出した、各ユーザの処理状況を表示する表示手段を更に含んでもよい。
【００１２】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。
【００１３】
【発明の実施の形態】
図１は、本実施の形態に係る文書管理システム１０の構成図である。文書管理装置１００は、ＬＡＮ１６を介して接続された第１クライアント１４ａおよび第２クライアント１４ｂなどの複数の端末（以下、単に「クライアント１４」という）に、サービスを提供する。また、文書管理装置１００はＷＡＮ１２を介してクライアント１４と接続されてもよい。本実施の形態において、文書管理装置１００は、例えばファックス機能、スキャナ機能、プリンタ機能、プリンタサーバ機能、ファックスサーバ機能、コピー機能などを有する装置、もしくは複数の機能を有するＭＦＰなどに組み込まれてもよい。
【００１４】
図２は、図１の文書管理装置１００の機能ブロック図である。文書管理装置１００の各構成要素は、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされた本図の構成要素を実現するプログラム、そのプログラムを格納するハードディスクなどの記憶ユニット、ネットワーク接続用インタフェースを中心にハードウエアとソフトウエアの任意の組み合わせによって実現される。そして、その実現方法、装置にはいろいろな変形例があることは、当業者には理解されるところあである。以下説明する各図は、ハードウエア単位の構成ではなく、機能単位のブロックを示している。
【００１５】
入力部１０２は、例えばファクシミリ機能、スキャナ機能、電子メール受信機能、ファイルサーバ機能などのいずれかの機能を用いて文書ファイルを受け付ける。文書ファイル格納部１０４は、入力部１０２が受け付けた文書ファイルを格納する。設定部１１２は、文書ファイル処理を行う担当者とその処理内容を設定する。処理状況格納部１１０は、各ユーザが担当している文書ファイル処理の進捗状況に関する情報（以下、単に「処理状況情報」とよぶ）を格納する。処理状況格納部１１０のデータ構造については後に詳述する。設定部１１２は、担当者を設定するに際して、処理状況格納部１１０に格納されている処理状況情報を参照する。すなわち、未処理の文書ファイルを一定数以上抱えているユーザや、不在のユーザをあらかじめ候補者のリストから外すことができる。また、設定部１１２は、候補者の資格を設定することもできる。さらに、設定部１１２が設定した文書ファイル処理の内容は文書ファイルに対応づけて処理内容格納部１１８に格納される。処理状況表示部１０８は処理状況格納部１１０に格納される処理状況情報を表示する。
【００１６】
提供部１０６は、担当者に文書ファイルを提供する。このとき、提供部１０６は通知部１１６を介して、担当者に文書ファイル処理の依頼（以下、単に「処理依頼」とよぶ）がなされたことを通知する。また、新たな処理依頼がなされたため、提供部１０６はこれを処理状況格納部１１０に格納する処理状況情報に反映させる。処理部１１４は担当者による文書ファイル処理を実行する。処理判断部１２０は実行された文書ファイル処理が、処理内容格納部１１８に格納する処理依頼の内容と一致するか否かの判断を行う。一致した場合には、処理判断部１２０は処理状況格納部１１０に格納する処理状況情報を更新する。文書ファイルに対して、更に次の担当者を設定する必要があれば、設定部１１２は再び担当者の設定を行う。あらかじめ文書ファイルごとに、各担当者とその処理依頼の内容を順番をつけて設定しておいてもよい。
【００１７】
図３は、処理依頼を行う際に表示される処理依頼設定画面１５０を示す。同図では「回覧文書１９１２」という名前の文書ファイルについて担当者を設定し処理依頼を行っている。宛先指定領域１５６は候補者を表示する。ユーザは、宛先指定領域１５６に表示される候補者の中から担当者を選択する。文書ファイル指定領域１５８は、文書ファイル処理の対象となる文書ファイルを表示する。ユーザは処理依頼に際し、コメント指定領域１６０においてコメントを付加できる。さらに、ユーザは処理期限指定領域１６２により、文書ファイル処理の緊急度を設定する。処理内容指定領域１６４は処理依頼の内容を示す。依頼ボタン１５２が押下されると宛先指定領域１５６で指定した候補者を担当者として処理依頼がなされ、当人に通知される。ユーザ情報ボタン１６６が押下されると、ユーザごとに処理状況が表示される。
【００１８】
図４は、処理依頼設定画面１５０においてユーザ情報ボタン１６６が押下されたときに表示されるユーザ処理状況画面１８０を示す。ユーザ指定領域１８２において処理状況を確認したいユーザを選択する。ユーザ状況領域１８４はユーザ指定領域１８２で選択したユーザの在席状況を示す。転送設定領域１８６は不在時の転送設定の有無を示し、転送先指定領域１８８はその転送先を示す。同図では、ユーザ指定領域１８２で選択されたユーザ「ｓａｋａｍｏｔｏ」は在席していないが、処理依頼は転送先指定領域１８８に示すユーザ「ｉｉｄａ」に転送される設定となっている。
【００１９】
未処理案件表示領域１９０は、ユーザ「ｓａｋａｍｏｔｏ」が抱える未処理の文書ファイル（以下、文書ファイルのうち、未処理の文書ファイルであることを強調する意味で使用する場合には、特に「未処理ファイル」とよぶ）を示す。同図では未処理ファイルは４つある。ファイル名表示領域１９２は、未処理ファイル名を示す。閲覧領域１９４は、未処理ファイルが、少なくとも閲覧されているか否かを示す。次担当者表示領域１９６は、該当する未処理ファイルの次の担当者を示す。同図の未処理ファイル「回覧文書１８０２」については次の担当者は未定である。すなわち、ユーザ「ｓａｋａｍｏｔｏ」は、同文書ファイル処理を完了した後に、次の担当者を設定するか否かを決定する。一方、未処理ファイル「業務連絡１４０２」については、次の担当者は「ｔａｎｉｇｕｃｈｉ」に設定されている。また、未処理ファイル「回覧文書１７０３」については、次の担当者はいないので、ユーザ「ｓａｋａｍｏｔｏ」が所定の文書ファイル処理を完了すると、その文書ファイルに対する全ての処理が完了する。
【００２０】
処理済案件表示領域２００は、処理済みの文書ファイルを示す。ファイル名表示領域２０２はそのファイル名を示す。状況表示領域２０４は、ファイル名表示領域２０２に示す文書ファイルの現在の処理状況を示す。同図では、ユーザ「ｓａｋａｍｏｔｏ」が文書ファイル処理を完了した「稟議書１４９５」という文書ファイルは、現在、ユーザ「ｔａｎｉｇｕｃｈｉ」が処理中であることを示す。戻るボタン２０６が押下されると、処理依頼設定画面１５０に戻る。
【００２１】
次に、データ構造について説明する。
【００２２】
図５は、処理状況格納部１１０のデータ構造を示す。処理状況格納部１１０は各ユーザの処理状況情報を格納する。ユーザＩＤ欄２２０はユーザを識別するＩＤ番号を示す。ユーザ名欄２２２は、ユーザの登録名を示す。在席欄２２４は、各ユーザの在席状況を示す。転送欄２２６は、不在時の処理依頼が、他のユーザに転送されるか否かを示す。これは、いわゆるバックアップの設定を示す。
【００２３】
未処理ファイル数欄２２８は、各ユーザの未処理ファイル数を示す。処理件数欄２３０は各ユーザが処理を完了した文書ファイルの数を示す。担当可否欄２３２は、各ユーザが候補者となる資格を有するか否かを示す。閾値欄２３４は、ユーザが一度に抱えることができる未処理ファイルの数を示す。同図では、ユーザ「ａｋａｇｉ」は、１０件まで未処理ファイルを抱えることができるが、未処理ファイル数欄２２８によると現在の未処理ファイル数は６件である。したがって、あと４件まで処理依頼が可能である。また、ユーザ「ｓａｋａｍｏｔｏ」は、在席していないが、ユーザ「ｉｉｄａ」が処理依頼の転送先として設定されている。そしてユーザ「ｉｉｄａ」は、処理依頼が可能であるため、結果としてユーザ「ｓａｋａｍｏｔｏ」も処理依頼が可能、すなわち、候補者として選択可能となる。
【００２４】
次に処理の流れを示す。
【００２５】
図６は、所定の文書ファイルに対して、全ての担当者による文書ファイル処理が完了するまでのフローチャートを示す。文書ファイルが担当者に提供されると、装置は、担当者による処理の実行を待ち受け、これを実行する（Ｓ１０）。実行された文書ファイル処理が、処理依頼されていたものであれば（Ｓ１２のＹ）、処理判断部１２０は、処理状況格納部１１０に格納される処理状況情報を更新する（Ｓ１４）。処理依頼されていたものでなければ（Ｓ１２のＮ）、再びＳ１０に戻り、担当者による処理を待ち受ける。
【００２６】
すべての文書ファイル処理が完了していれば（Ｓ１６のＹ）、一連の処理は終了する。一方、全ての文書ファイル処理が完了していない場合には（Ｓ１６のＮ）、次の担当者に処理依頼が行われる（Ｓ１８）。そして、この新たな担当者に文書ファイルを提供し（Ｓ２０）、再び文書ファイル処理の実行の待ち受けに戻る（Ｓ１０）。
【００２７】
以上、本実施の形態における文書管理装置は、ユーザごとの文書ファイル処理状況を管理している。したがって、負荷がかかっているユーザに処理依頼が集中し、結果として全体の文書ファイル処理が滞るのを事前に回避できる。
【００２８】
以上、本発明を実施の形態をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００２９】
そうした変形例として、処理依頼の緊急度、処理依頼の内容、処理依頼対象となる文書ファイルの情報量などに応じて、担当者にかかる負荷を算定してもよい。そして、その算定された負荷に応じて、候補者を選定することとしてもよい。また、緊急の文書ファイル処理は不可能だが、今日中であれば対応可能なユーザが存在する場合も想定できるため、処理依頼の緊急度に応じて、候補者のリストが変更されてもよい。
【００３０】
【発明の効果】
本発明によれば、ユーザの状況に応じて、文書ファイルの処理担当者を適切に選択することができる。また、本発明によれば効率的な文書ファイルの管理を行うことができる。
【図面の簡単な説明】
【図１】本実施の形態に係る文書管理システムの構成図である。
【図２】図１の文書管理装置の内部の機能ブロック図である。
【図３】文書ファイルの処理依頼を設定するための画面の一例を示す図である。
【図４】ユーザの処理状況を表示する画面の一例を示す図である。
【図５】図２の処理状況格納部のデータ構造の一例を示す図である。
【図６】担当者による所定の文書ファイル処理がすべて完了するまでのフローチャートの一例を示す図である。
【符号の説明】
１４  クライアント、１００  文書管理装置、１０２  入力部、１０４  文書ファイル格納部、１０６  提供部、１０８  処理状況表示部、１１０  処理状況格納部、１１２  設定部、１１４  処理部、１１６  通知部、１１８  処理内容格納部、１２０  処理判断部。
【図１】
2004326269.tif 000003
【図２】
2004326269.tif 000004
【図３】
2004326269.tif 000005
【図４】
2004326269.tif 000006
【図５】
2004326269.tif 000007
【図６】
2004326269.tif 000008