(57)【要約】【課題】文書管理システムに電子帳票を格納するとき自動的に必要最低限のアクセス権を設定し文書管理システムの容易で適切な運用を提供する。【解決手段】ネットワークに接続された複数の電子計算機を使用して、申請書や稟議書などの帳票を管理する文書管理システムにおいて、ワークフロー管理システムを回覧されてきた帳票データとともに処理履歴を格納できる手段と処理履歴からアクセス可否を決定できるアクセスルールを設定できる手段とアクセス要求があったときに処理履歴とアクセスルールからアクセス可否を決定できる手段とを備えるこことを特徴とする文書管理システムにより容易な運用によって適切なアクセス権を設定出来る。本発明によれば、一度、帳票を格納する書庫にアクセスルールを設定すると回覧されてきたルートによって帳票ごとのアクセス権が自動的にかつ適切に決定される。【選択図】図１０
2008299460.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続された複数の電子計算機を使用して、申請書や稟議書などの帳票を管理する文書管理システムにおいて、ワークフロー管理システムを回覧されてきた帳票データとともに処理履歴を格納できる手段と処理履歴からアクセス可否をユーザＩＤやユーザの組織および職位といった従来から管理メンテナンスする対象となる情報により決定できるアクセスルールを設定できる手段とアクセス要求があったときに処理履歴とアクセスルールからアクセス可否を決定できる手段とを備えることを特徴とする文書管理システム。
【請求項２】
ワークフロービジネスプロセス定義において各ノードでの処理者と処理内容を自動で記録するワークフロー制御方式。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は電子文書を公開するためのアクセス権を制御する技術に関する。
【背景技術】
【０００２】
電子帳票を文書管理システムに格納するにあたって従来の技術では同一の帳票を格納する書庫ごとにアクセス権を設定することは出来た。この手段では帳票一葉ごとのアクセス権の設定が出来ず無理に運用しようとすると全ユーザに対し必要以上にアクセス権を与えるしかなく情報漏えいの観点から問題があった。一方、システム管理者の力を借りれば一葉ごとのアクセス権の設定も可能であったが自動運用は出来なかった。
【０００３】
書類のペーパレス化を実現するには従来のように１枚の帳票を申請部署、承認部署、合議部署とそれぞれの関連部署で控えを取っておくような運用でなく電子的に一箇所に存在させる要求がある。この時、文書管理システムはネットワークを介して多くのユーザに使われるため適切なアクセス制御が行われなくてはいけない。
【０００４】
過去の申請帳票を過去事例として情報共有するためには適切なアクセス制御が必要になってくる。
【０００５】
【特許文献１】特開２００６−１７２３０２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明は文書管理システムに電子帳票を格納するとき自動的に必要最低限のアクセス権を設定し文書管理システムの容易で適切な運用を提供する。
【課題を解決するための手段】
【０００７】
ネットワークに接続された複数の電子計算機を使用して、申請書や稟議書などの帳票を管理する文書管理システムにおいて、ワークフロー管理システムを回覧されてきた帳票データとともに処理履歴を格納できる手段と処理履歴からアクセス可否を決定できるアクセスルールを設定できる手段とアクセス要求があったときに処理履歴とアクセスルールからアクセス可否を決定できる手段とを備えるこことを特徴とする文書管理システムにより容易な運用によって適切なアクセス権を設定出来る。
【発明の効果】
【０００８】
一度、帳票を格納する書庫にアクセスルールを設定すると回覧されてきたルートによって帳票ごとのアクセス権が自動的にかつ適切に決定する。
【発明を実施するための最良の形態】
【０００９】
図１は本発明のワークフローシステムおよび文書管理システムの１実施例のシステム構成図である。図１では、ワークフローシステムおよび文書管理システム、人事管理システムは、１台のサーバ（１１０）とネットワーク（１３０）によって接続された複数台のクライアント（１２０）から構成されている。
【００１０】
図２は本発明のタスク関連図である。サーバ内には大きく分けて、ワークフロー管理部（２８０）と文書管理部（２９０）と人事データ管理部（２７０）から成り立っている。
【００１１】
運用定義管理部（２８１）は業務プロセス定義（１８０）（以下ビジネスプロセス定義、もしくはＢＰ定義と略す）、帳票定義（１９０）を管理しそれらに対する作成／削除／編集を行う。回覧帳票管理部（２８２）は回覧帳票（２００）を管理し、それをＢＰ定義とユーザ定義（１５０）と関連づけて回覧制御する。
【００１２】
文書管理部（２９０）の運用定義管理部（２９３）はアクセス制御を行うためのルール定義（２５０）と帳票を表示するための帳票定義（２６０）を管理しそれらに対する作成／削除／編集を行う。
【００１３】
図３は人事データのユーザ情報（１５０）と組織情報（１６０）の１実施例でありかつそれぞれ１レコード分の例を示している。ユーザ情報（１５０）はシステム内でユニークなユーザＩＤ（１５１）と氏名（１５２）、名字（１５３）、名前（１５４）、職位（１５５）、所属組織ＩＤ（１５６）、内線（１５７）という項目から構成されている。
【００１４】
組織情報はシステム内ユニークな組織ＩＤ（１６１）と組織名（１６２）、組織略称（１６３）、その組織に所属する組織のＩＤ（１６４）、その組織に所属するユーザのＩＤ（１６５）という項目から構成されている。
【００１５】
図４は本発明に係わるシステムの１実施例で用いられるＢＰ定義（１８０）の概念図とそれを構成するためのテーブル群である。ＢＰ定義（１８０）には、１種類の関連線（３４０）と３種類のノードがありノードにはノード名（３２０）が付いている。
・開始ノード（３３０）：一連の業務の始まりをあらわす。
・処理ノード（３５０）：一連の業務中に存在する処理単位をあらわす。
終了ノード（３６０）：一連の業務の終了をあらわす。
【００１６】
このＢＰを表現するためにＢＰ全体の属性を表すＢＰ管理テーブル（３７０）とノードごとの属性を現すノード管理テーブル（３８０）との組み合わせによって表現される。ＢＰ管理テーブル（３７０）は業務プロセスごとにユニークなＩＤであるＢＰＩＤ（３７１）とＢＰ名称（３７２）、管理者（３７３）、開始ノードのノードＩＤを格納する開始ノードＩＤ（３７４）、次に起票される帳票に振られるＩＤを格納する次帳票ＩＤ（３７５）から構成される。
【００１７】
一方、ノード管理テーブル（３８０）はどのＢＰのノードかをあらわすＢＰＩＤ（３８１）とＢＰ内でユニークになるノードＩＤ（３８２）、ノード名（３８３）、ノード種別（３８４）、次のノードへのリンクを表す次ノードＩＤ（３８５）、処理種別（３８６）、起動する帳票を定義する帳票ＩＤ（３８７）から構成される。
【００１８】
図５は本発明に係わるシステムの１実施例で用いられる帳票定義（１９０）の実現方式である。年休取得伺帳票は台紙（４１０）に帳票名（４２０）から所属入力欄（４５０）、氏名入力欄（４６０）など多種類のオブジェクトが乗っている集合体である。それらオブジェクトの集合体である帳票を帳票全体にかかわる属性を帳票管理テーブル（５４０）と各オブジェクトの属性を項目管理テーブル（５５０）によって表現する。
【００１９】
帳票管理テーブル（５４０）は帳票を一意に識別する帳票ＩＤ（５４１）と帳票名称（５４２）、背景色（５４３）、帳票の縦の大きさを表す用紙縦（５４４）、帳票の横の大きさを表す用紙横（５４５）から構成されます。項目管理テーブルは、帳票とのリンクを表す帳票ＩＤ（５５１）と帳票内でユニークな項目ＩＤ（５５２）、項目名称（５５３）、どういう種類の項目かを表す項目種別（５５４）、編集可否（５５５）、右上座標（５５６）、左下座標（５５７）から構成される。
【００２０】
図６は本発明に係わるシステムの１実施例で用いられる回覧帳票データ（２００）および格納帳票データ（２３０）である。（同一形式である）帳票ごとに順番に振ったユニークな帳票ＩＤ（２０１）と帳票ごとに入力可能領域の名前（２０２、２０３、３０４、２０５、etc）をカラムにしたテーブル構造をして１帳票のデータは１レコードとして扱われる。
【００２１】
図７は本発明に係わるシステムの１実施例で用いられる回覧履歴データ（２１０）および回覧履歴データ（２４０）（格納時）である。帳票ＩＤ（２１１）と処理ノード名を格納する処理ノード欄（２１２）、処理内容を格納する処理内容欄（２１３）、処理者の氏名を格納する処理者欄（２１４）、処理した人の処理したときの組織を格納する処理者組織欄（２１５）と処理者が処理した時刻を格納する処理日時（２１６）欄などから構成される。１帳票の履歴は複数レコードを使用して格納される。
【００２２】
クライアント（１２０）からワークフローシステムにログインを行うとワークフロー管理部（２８０）はＢＰ定義テーブルを検索し登録されている業務一覧を取得しそれらを画面に可視化する。起票者がアイコンを選択（ダブルクリックなど）すると回覧帳票管理部（２８２）は選択された業務からＢＰＩＤを取得し、このＢＰＩＤをキーにノード管理テーブルの該当ＢＰの開始ノードを検索する。開始ノードレコードの帳票ＩＤから起動すべき帳票のＩＤがわかる。次に帳票管理テーブルと項目管理テーブルから帳票ＩＤをキーに帳票定義を取得し表示する。ユーザが帳票に対し処理を行うと回覧帳票管理部（２８２）は回覧帳票データテーブルにレコードを生成（起票）し入力情報を該当カラムにセットし、ノード管理テーブルから次の処理者を決定しステータスを次の処理者のトレイに変更し、次帳票ＩＤ（３７５）をインクリメントする。同時に回覧履歴データを生成し回覧履歴データテーブルに申請の履歴レコードを追加する。
【００２３】
回覧中の回覧帳票データ（２００）と回覧履歴データ（２１０）はワークフローデータ管理部（２８０）が管理するワークフローデータ（１７０）の一部として扱われるが、回覧が終了すると文書管理システムに格納する帳票のときは文書管理データの格納帳票データ（２３０）と回覧履歴（２４０）にそれぞれ格納される。
【００２４】
図８は本発明に係わるシステムの１実施例で用いられる文書管理データ内のルール定義（２５０）である。実際には図のように人間にわかる言葉で記述されているわけではないがわかりやすいように人が認識できる言葉で記述する。
【００２５】
１つのルール定義（２５０）は１つ以上のサブルール定義（２５１、２５２）からなる。サブルール定義には優先度（２５３）が設けてあり、優先度１のサブルール定義から順番に評価されていく。また、サブルール定義にはサブルールを満たしたユーザに対し帳票データを表示する帳票（２５４）が設けてあり、通常優先度１の帳票が一番表示項目が多くなるように設定する。優先度１で許可されなかったユーザは優先度２のサブルールの評価に入り、ここで許可されると優先度１のサブルールの帳票より表示項目の少ない優先度２のサブルールの帳票で表示されるわけである。
【００２６】
また、サブルールは通常さらに細かな小ルールからなっている。小ルールのルール設定に使える人事情報はユーザＩＤ、組織ＩＤ、職位といった従来からメンテナンス対象の情報から成っており、この機能を実現するに当たって新たに管理メンテナンスするオブジェクトが増えるわけではない。
【００２７】
図８の実施例は個人にくくりついた申請のアクセス付与の例である。小ルール３は総務部門の人間は帳票の管理者な為、組織ＩＤが総務であれば閲覧できるようにしてある。小ルール１は申請者であれば閲覧できるような設定である。ルール２は個人的な申請であるため、同一組織でなくなったら承認上長であれども閲覧できないように設定している。小ルール３で総務部門には全帳票の閲覧権限を与えている。
【００２８】
図９の実施例は個人にくくりつかない申請のアクセス付与の例である。申請を出した人はその組織を代表して申請を出しただけであるため個人にくくりついたアクセス制御を行うと組織改変や異動によってアクセス制御に不都合が起きる。小ルール１は申請部門の人なら誰でも閲覧できる設定である。小ルール２は合議部署の制御文であり、合議部署では合議部署であると同時に職位に課長以上が必要となり小ルール１よりは厳しくなっている。小ルール３は経理部門には全帳票の閲覧権限を与えている。
【００２９】
図１０は本発明に係わるシステムの１実施例の帳票表示ロジックである。図３の日立上司が図８のルール定義に従い図６の帳票ＩＤ００００１（帳票履歴は図７）を閲覧するときを例にとって説明する。アクセス者が文書管理システムにログインすると文書管理部は格納帳票管理部が格納帳票データテーブルから検索した帳票を一覧にして可視化（アイコン化）する。アクセス者がアイコンを選択（ダブルクリックなど）すると格納帳票管理部はクリックされた帳票ＩＤとアクセス者を引数にしてアクセス制御部に対してアクセス可否の判定依頼をする。
【００３０】
このフローチャートはアクセス者のユーザＩＤと閲覧しようとしている帳票ＩＤとを引数としてアクセス制御部に要求があったことを前提としている（３００）。
【００３１】
人事データ管理部に対してアクセス者のユーザＩＤをキーにしてユーザ情報テーブルと組織情報テーブルから、氏名、組織ＩＤ、職位などのユーザデータを検索し、日立上司、１００００Ａ、課長といったユーザ情報を取得する（３０１）。
【００３２】
文書管理部に対して閲覧希望の格納帳票ＩＤをキーに格納帳票データテーブルを検索することによって各ノードでのノード名、処理内容、処理者、処理者組織、処理日時などを得る（３０２）。
【００３３】
回覧履歴データ中の処理者組織や処理者職位は処理したときのものでありルールには現在の組織、職位も必要なので、現在の組織情報は人事データ管理部に対して全処理者の組織、職位をループに入る前にすべてユーザ情報テーブルと組織情報テーブルから検索する（３０３）。
【００３４】
優先度１のサブルールを満たしたか判定する。図８より優先度１のサブルールはさらに小ルール１，２，３の論理和と成っている。小ルール１から評価していくとアクセス者「日立上司」は申請者「日立太郎」ではない。実際にはアクセス者のユーザＩＤと格納帳票の履歴データテーブルから取得した申請者のユーザＩＤとを比較して等しくないため小ルール１は成り立たないと判断される。次に小ルール２を評価する。アクセス者「日立上司」は履歴中に承認者として（却下したときの履歴は関係ない）存在するので小ルール２の前半は成り立った。すなわちアクセス者ユーザＩＤと格納帳票の履歴データテーブルから取得した処理内容が承認である承認者のユーザＩＤとを比較した結果等しかったということである。ここで現在の申請者の組織と承認者の現在の組織を比較している。異動などによって申請者「日立太郎」と承認者「日立上司」が違う組織にいるとする、すなわち人事管理部に問い合わせた申請者「日立太郎」と承認者「日立上司」との組織ＩＤが等しいか等しくないかということである。等しくなければルール２は成り立たなくなりそうでなければ成り立つ。承認者「日立上司」の所属組織は総務ではないのでルール３は成り立たない。
【００３５】
優先度２のサブルールを見てみると「その他」となっているこれはそこまでの優先度の条件に当てはまらなかった残りのケースすべてを成り立たせる記述である。
【００３６】
つまり「日立上司」は申請者「日立太郎」が現在も同じ組織内にいれば帳票ＩＤ００００１の帳票を優先度１の表示帳票である帳票０１で見ることが出来る。一方、申請者「日立太郎」が別組織に異動していれば帳票ＩＤ００００１の帳票は優先度２の表示帳票である帳票０２でしか見ることが出来ない。
【００３７】
「日立上司」が優先度１の表示帳票である帳票０１で見ることが出来るとアクセス制御部（２９２）の判定になれば、格納帳票管理部（２９１）は帳票０１の表示項目に図６の帳票０００１の帳票データを差し込み表示する。帳票０１の表示項目にない帳票データがあってもそのデータは表示されない（３０５）。
【００３８】
サブルールの解析により表示しない判定が出た場合次の優先度の評価に入る。このとき次の優先度が設定していない場合アクセスは不可と判断し帳票の一部たりとも表示しない（３０６、３０７）。
【００３９】
優先度１の時のサブルール評価と同様に優先度２以降のサブルールを評価し満たしていれば該当優先度に設定してある帳票で表示する。該当優先度のサブルールは満たしたが設定帳票がない場合はアクセス不可と判断する（３０８，３０９）。
【産業上の利用可能性】
【００４０】
本発明は、電子化帳票を一度のアクセス権設定ルールによって自動で適切なアクセス制御の閲覧を可能にする文書管理システムに関する。
【図面の簡単な説明】
【００４１】
【図１】本発明の１実施例のシステム構成図。
【図２】本発明の１実施例のサーバないタスク関連図。
【図３】本発明の１実施例の人事データテーブル図。
【図４】本発明の１実施例のＢＰ定義の概念図。
【図５】本発明の１実施例の帳票定義の概念図。
【図６】本発明の１実施例の回覧帳票データテーブル図。
【図７】本発明の１実施例の回覧履歴データテーブル図。
【図８】本発明の１実施例の文書管理システム内のルール定義概略図（個人申請用）。
【図９】本発明の１実施例の文書管理システム内のルール定義概略図（組織申請用）。
【図１０】本発明の１実施例の文書管理システムが行う帳票アクセス判定の流れ図。
【符号の説明】
【００４２】
１１０…計算機（サーバ）、１２０…計算機（クライアント）、１３０…ネットワーク、１４０…人事データ、１５０…ユーザ情報、１６０…組織情報、１７０…ワークフローデータ、１８０…ＢＰ定義、１９０…帳票定義、２００…回覧帳票データ、２１０…回覧履歴データ、２２０…文書管理データ、２３０…格納帳票データ、２４０…回覧履歴データ、２５０…ルール定義、２６０…帳票定義、２７０…人事データ管理部、２８０…ワークフロー管理部、２８１…運用定義管理部、２８２…回覧帳票管理部、２９０…文書管理部、２９１…格納帳票管理部、２９２…アクセス制御部、２９３…運用定義管理部、１５１…ユーザＩＤカラム、１５２…氏名カラム、１５３…名字カラム、１５４…名前カラム、１５５…職位カラム、１５６…所属組織ＩＤカラム、１５７…内線カラム、１６１…組織ＩＤカラム、１６２…組織名カラム、１６３…組織略称カラム、１６４…下位組織のＩＤを格納するカラム、１６５…所属するユーザのＩＤを格納するカラム、３１０…申請業務のＢＰ定義、３２０…ノード名、３３０…開始ノード、３４０…関連線、３５０…処理ノード、３６０…終了ノード、３７０…ＢＰ管理テーブル、３７１…ＢＰＩＤカラム、３７２…ＢＰ名称カラム、３７３…管理者カラム、３７４…開始ノードＩＤカラム、３７５…次帳票ＩＤカラム、３８０…ノード管理テーブル、３８１…ＢＰＩＤカラム、３８２…ノードＩＤカラム、３８３…ノード名カラム、３８４…ノード種別カラム、３８５…次ノードＩＤカラム、３８６…処理種別カラム、３８７…帳票ＩＤ、４１０…帳票台紙、４２０…帳票題字、４３０…所属名称表示欄、４４０…氏名表示欄、４５０…所属入力欄、４６０…氏名入力欄、４７０…日時表示欄、４８０…事由表示欄、４９０…月入力欄、５００…月表示欄、５１０…日入力欄、５２０…日表示欄、５３０…事由入力欄、５４０…帳票管理テーブル、５４１…帳票ＩＤカラム、５４２…帳票名称カラム、５４３…背景色カラム、５４４…用紙縦カラム、５４５…用紙横カラム、５５０…項目管理テーブル、５５１…帳票ＩＤカラム、５５２…項目ＩＤカラム、５５３…項目名称カラム、５５４…項目種別カラム、５５５…編集可否カラム、５５６…左上座標カラム、５５７…右下座標カラム、２０１…帳票ＩＤカラム、２０２…所属名称入力カラム、２０３…氏名入力カラム、２０４…月入力カラム、２０５…日入力カラム、２１１…帳票ＩＤカラム、２１２…処理ノードカラム、２１３…処理内容カラム、２１４…処理者カラム、２１５…処理者組織カラム、２１６…処理日時カラム、２５１…優先度１のサブルール、２５２…優先度２のサブルール、２５３…優先度、２５４…表示帳票、３００…処理開始、３０１…アクセス者の情報取得処理、３０２…帳票履歴取得処理、３０３…処理者の情報取得処理、３０４…優先度１の判定、３０５…優先度１の帳票表示処理、３０６…次優先度の検索処理、３０７…アクセス不可、３０８…該当優先度判定、３０９…該当優先度帳票の表示処理。
【図１】
2008299460.tif 000003
【図２】
2008299460.tif 000004
【図３】
2008299460.tif 000005
【図４】
2008299460.tif 000006
【図５】
2008299460.tif 000007
【図６】
2008299460.tif 000008
【図７】
2008299460.tif 000009
【図８】
2008299460.tif 000010
【図９】
2008299460.tif 000011
【図１０】
2008299460.tif 000012