アクセス制御システム
【課題】 各業務のステータス管理をなくし、かつ閲覧権限情報をフレキシブルに変更可能であり、さらに過去の組織情報を利用しなくても過去の業務に対して制御可能な、成果物作成および閲覧のアクセス制御システムを提供する。
【解決手段】 各業務に対して利用者に関する情報とともに特定の成果物を作成する手順を定めた成果物作成手順情報を記憶装置に保存する。利用者がアクセスする際、当該アクセスに関連する該当業務の既存の成果物群から、当該アクセスに該当する成果物作成手順情報を特定し、さらに前記既存の成果物群から前記成果物作成手順情報における現在の業務進捗の位置を特定することで、次の工程の担当者を特定し、利用者のアクセス可否に関する制御を図る。
【解決手段】 各業務に対して利用者に関する情報とともに特定の成果物を作成する手順を定めた成果物作成手順情報を記憶装置に保存する。利用者がアクセスする際、当該アクセスに関連する該当業務の既存の成果物群から、当該アクセスに該当する成果物作成手順情報を特定し、さらに前記既存の成果物群から前記成果物作成手順情報における現在の業務進捗の位置を特定することで、次の工程の担当者を特定し、利用者のアクセス可否に関する制御を図る。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アクセス制御システムに関し、詳しくは所定の各業務（以下、「工程」と記載することもある。）の作業を行うことの可否に関するアクセス制御システム、および各成果物を閲覧することの可否に関するアクセス制御システムに関するものである。
【背景技術】
【０００２】
従来、企業等では、複数の担当者が関わり1つの業務を遂行するのが通常である。例えば、ある業務はいくつかの工程から構成されるとしたとき、ある担当者はその中の一部分の工程の作業を行い次の担当者に作業を引き渡し、引き渡された次の担当者はその次の一部分の工程の作業を行い、これを順次繰り返して1つの業務を完了させる、という具合である。
【０００３】
このように、1つの業務の各工程の順序や担当者をルール化したものはワークフロー、またワークフローに基づき業務の効率を向上させるインフラはワークフローシステムと呼ばれる。図５は、交通費の申請という１つの業務についてのワークフローの一例である（５０１）。申請者からの申請（５０２）の後、申請者の直属の係長が申請内容について承認／却下の判定をくだす（５０３）。却下の場合は５０２に戻って申請者が申請をやり直す。承認の場合は申請者の直属の部長が申請内容について承認／却下の判定をくだし（５０４）、却下の場合は５０２に戻って申請者が申請をやり直し、承認の場合はこの業務は完了となる（５０５）。
【０００４】
ワーククフローシステムでは、各担当者は各作業の結果として、何らかの成果物を電子的に作成する。例えば文書や、インフラ上で承認ボタンを押すことが、成果物にあたる。図５の例では、５０２での成果物は交通費の申請書であり、５０３、５０４は承認／却下ボタンの押下（または承認書、却下書）が成果物である。
【０００５】
このような成果物については、セキュリティ上の観点から、成果物を担当者外の人に作成させない、あるいは部外者に以前の成果物を閲覧したり引用したりさせない、といったアクセス権限の制御を行うことが重要となる。
【０００６】
ワークフローにおけるアクセス制御に関して、例えば特許文献１、２、３記載の公知技術が知られている。
【０００７】
特許文献１記載の従来技術は、複数の作業からなる業務の進捗状況を管理するワークフローシステムである。特許文献１の発明は、ある担当者が自分の担当の作業を行う際に、それに関連する他の担当者の作業がすべて処理されたことが確認されないと、その担当者の作業が開始できないようにアクセス制御することで、無駄な作業を行わなくて済むようにできることである。
【０００８】
特許文献２記載の従来技術は、組織変更や人事異動などの変化に対して、文書の閲覧権限を動的に変化させる電子文書回覧ワークフローシステムである。特許文献２の発明は、文書作成時に、閲覧権限設定に反映させる属性（個人属性、組織属性、役割属性）の組合せを選択しておき、当該文書作成に関わった担当者の人事情報を、上記設定されている属性のみに反映させるように制御することで、組織変更や人事異動などの人事環境の変化に対して、作成済みの文書の閲覧権限を動的に変化させることができることである。
【０００９】
特許文献３記載の従来技術は、組織変更や、回覧ルートに変更があっても問題なく処理できるワークフローシステムである。特許文献３の発明は、すべての世代の組織情報を保持しておき、新規文書作成の際にどの世代の組織情報を対象とするかを指定することで、旧組織情報でのワークフローを実現することである。また各業務ごとに業務発生時の回覧ルートを保持しておくことで、回覧ルートが変更されても業務発生時の回覧ルートで回覧できることである。
【００１０】
【特許文献１】特開２００５―２０２９２０号公報
【特許文献２】特開２００６―１７２３７７号公報
【特許文献３】特開２００６−１９５８３３号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、上記特許文献１では、各業務の進捗状況（各業務の現在のステータスという意味で、以下「ステータス」という。）をサーバが保持しており、各担当者がサーバに各自の次の作業を依頼したとき、サーバはそのステータスを参照して、次の作業の着手の可否を判断する構成になっている。
【００１２】
ところが、企業等での業務の数は通常膨大である。例えば、図５では交通費申請のワークフローを示しているが、同時にa人がそれぞれb件を申請したとすると、a×b件の業務が動いていることになる。また一般に交通費申請以外にもワークフローは多数あるため、大量のステータスを管理する必要がある。さらに組織変更や人事異動があった場合については特許文献１に言及はないが、管理しているステータスをすべて修正するという作業が発生することが予想される。このようにステータスの管理が非常に煩雑であるという問題点があった。
【００１３】
また、特許文献２では、閲覧に関し、文書作成時に後で変更可能な属性を定義していることで、権限情報が文書に紐付けされ、閲覧権限に必要な属性情報が増減した場合に対応しにくいという問題点があった。
【００１４】
特許文献３では、すべての世代の組織情報を管理しなくてはいけないということ、さらに旧組織情報でのワークフローを実現するためには、旧組織図だけでなく、その当時誰がどこに所属していたかという、今まで在籍していたすべての人の所属組織の経歴情報を保持しておかなくてはならないという問題点があった。
【００１５】
本発明は、上記従来の事情に基づいて提案されたものであって、成果物作成、または閲覧のためのアクセス権限を制御するアクセス制御システムにおいて、ステータスの保持が不要であり、かつ文書と閲覧権限情報を切り離して管理可能であり、さらに過去の組織情報を利用しなくても過去の業務に対して制御可能なアクセス制御システムを提供することを目的とする。
【課題を解決するための手段】
【００１６】
本発明は、上記目的を達成するために以下の手段を採用している。
つまり、本発明の第１の構成は、特定の業務を実施する担当者に対し、当該業務の成果物作成に関するアクセス権限を制御するアクセス制御システムにおいて、各業務において成果物を作成する手順及び当該業務を実施する担当者の関係を定める成果物作成手順情報を格納する成果物作成手順情報格納手段と、前記各業務に対する成果物を格納する成果物格納手段と、前記成果物格納手段から、前記成果物作成に該当する業務の成果物群を抽出する成果物特定手段と、前記成果物特定手段により抽出された前記成果物群と前記成果物作成手順情報格納手段から、該当する成果物作成手順情報を選択する成果物作成手順特定手段と、前記成果物群より、前記特定された成果物作成手順における現在の業務進捗を示す位置を特定する成果物作成手順内位置特定手段と、前記特定された前記成果物作成手順内の現在の業務進捗を示す位置から、前記成果物作成手順における次の業務の担当者を特定する担当者特定手段と、前記特定された担当者に対して前記次の業務の成果物作成に関するアクセス権限を与える判定手段とを備えることを特徴とする。
【００１７】
次に本発明の第１の構成の作用として、成果物作成のためのアクセス制御方法について述べる。
各業務において、成果物を作成する手順を定めた成果物作成手順を用いる。成果物作成手順は業務ごとに1個あり、手順の変更や組織の変更などを受けて随時更新される。ただし更新は新規に追加することを意味し、過去の成果物作成手順は削除されないことを前提とする。
これらの成果物作成手順は、成果物作成手順情報格納手段により、ＤＢ（データベース）に格納されている。
また、各成果物は、成果物格納手段によりＤＢに格納される。
ここで、上記ＤＢは追加格納、検索ができればよく、ファイルシステム等でも構わない。
ある業務に関し成果物を作成しようとしたときは、その業務に関する今までの成果物群（今までの成果すべてか、その一部）を、上記成果物格納手段から検索して選び出す。成果物群に含まれる情報より、上記成果物作成手順情報格納手段から、その業務に該当する成果物作成手順を検索する。選択された成果物作成手順に、上記成果物群を当てはめて、現在の進捗を示す位置を求め、次の工程およびその担当者を特定する。ここで特定された担当者のみに、次の工程の作業を許可する。
以上により、ステータスを管理することなしに、次の工程の担当者のみに作業を許可するアクセス制御を実現することができる。
【００１８】
次に、本発明の第２の構成は、特定の業務の成果物を閲覧する担当者に対し、当該業務の成果物閲覧に関するアクセス権限を制御するアクセス制御システムにおいて、各業務において成果物を作成する手順及び当該業務の担当者の属性情報を定める成果物作成手順情報を格納する成果物作成手順情報格納手段と、前記各業務に対する成果物を格納する成果物格納手段と、前記成果物格納手段から、前記成果物閲覧に該当する業務に関する成果物群を抽出する成果物特定手段と、前記成果物特定手段により抽出された前記成果物群と前記成果物作成手順情報格納手段から、該当する成果物作成手順情報を選択する成果物作成手順特定手段と、前記成果物群より、前記特定された成果物作成手順における現在の業務進捗を示す位置を特定する成果物作成手順内位置特定手段と、前記特定された前記成果物作成手順内の現在の業務進捗を示す位置から、前記成果物作成手順における次の業務の担当者を特定する担当者特定手段と、前記特定された担当者の属性情報に基づいて、前記成果物群の閲覧可能者を定める判定手段とを備えることを特徴とする。
【００１９】
次に本発明の第２の構成の作用として、成果物閲覧のためのアクセス制御方法について述べる。
次の工程およびその担当者の特定までは、上記成果物作成のためのアクセス制御方法と同様である。
次の作業の担当者の属性（所属や役職）により、成果物一式の閲覧可能者を定める。例えば次の作業の担当者と同じ所属であれば閲覧可としたり、次の作業の担当者より低級の役職では閲覧不可としたりできる。ここで属性は現在の属性を指す。
以上により、ステータスを管理することなしに、成果物閲覧に関するアクセス制御を実現することができる。さらに閲覧の可否は文書とは切り離して管理可能である。また、次の作業の担当者の属性は、現在の属性であるため、閲覧に関するアクセス制御に過去の情報を利用する必要がなくなる。
【発明の効果】
【００２０】
本発明に係る、成果物作成、または閲覧のためのアクセス権限を制御するアクセス制御方法においては、ステータスの保持が不要でありステータス管理のコストを削減できる。かつ文書と閲覧権限情報を切り離して管理可能であるため、閲覧権限情報をフレキシブルに変更可能である。さらに過去の組織情報を利用しなくても過去の業務に対して制御可能となる。
【発明を実施するための最良の形態】
【００２１】
以下、図面を参照して、本発明の詳細を説明する。なお、以下の実施の形態は、本発明を具体化した一例であって、本発明の技術的範囲を限定する性格のものではない。
【００２２】
（実施の形態１）
以下、本発明に係る実施の形態１におけるアクセス制御システムの概略について説明する。
図１は、本発明のアクセス制御を実現するシステム全体の概略図である。図１において、複数の作業者端末１０４1〜１０４n、ＤＢサーバ１０２、アプリケーションサーバ１０３はネットワーク１０１により接続され、相互にデータ送受信可能な構成になっている。ここで作業者端末１０４1〜１０４nはＰＣ（パーソナルコンピュータ）等である。ＤＢサーバ１０２とアプリケーションサーバ１０３は同一のコンピュータ上で実現されてもよい。またアプリケーションサーバ１０３の機能を各作業者端末１０４iが持っている構成でもよい。
【００２３】
図２はＤＢサーバ１０２の概略機能ブロック図である。ＤＢサーバ１０２は成果物格納手段２０１、成果物検索手段２０２、成果物作成手順情報格納手段２０３、成果物作成手順検索手段２０４から構成される。
【００２４】
図３はアプリケーションサーバ１０３の概略機能ブロック図である。アプリケーションサーバ１０３は依頼受付手段３０１、依頼者情報格納手段３０２、成果物特定手段３０３、成果物群格納手段３０４、成果物作成手順情報特定手段３０５、成果物作成手順情報格納手段３０６、成果物作成手順情報内位置特定手段３０７、担当者特定手段３０８、判定手段３０９、成果物格納依頼手段３１０から構成される。
【００２５】
図４は作業者端末１０４iの概略機能ブロック図である。作業者端末１０４iは作業内容依頼手段４０１、作業内容依頼結果表示手段４０２、閲覧依頼手段４０３、閲覧依頼結果表示手段４０４、成果物作成手段４０５、成果物格納依頼手段４０６から構成される。
【００２６】
図６は交通費申請の業務の成果物作成手順を示したもので、図５のワークフローに対応するものである。
【００２７】
この業務は、各個人が交通費申請書を作成することで開始される。成果物作成手順の６０２は、このステップでの成果物が交通費申請書であり、作成者は各個人であることを示している。次の工程における成果物は、交通費承認書（ステップ６０３）または交通費却下書（ステップ６０４）である。どちらも作成者はステップ６０２での申請者の直属の係長である。直属の係長がステップ６０２で申請された内容について承認する場合はステップ６０３に、却下する場合はステップ６０４に進むことを示している。
【００２８】
ステップ６０４に進みステップ６０２での申請が却下された場合の次の工程はステップ６０２であり、申請者の申請からやり直すことになる。ステップ６０３に進み承認された場合は、次の工程における成果物は、交通費承認書（ステップ６０５）または交通費却下書（ステップ６０６）である。どちらも作成者はステップ６０２での申請者の直属の部長である。直属の部長がステップ６０２で申請された内容について承認する場合はステップ６０５に、却下する場合はステップ６０６に進むことを示している。
【００２９】
ステップ６０６に進みステップ６０２での申請が却下された場合の次の工程はステップ６０２であり、申請者の申請からやり直すことになる。ステップ６０５に進み承認された場合はステップ６０７に進み、この業務は完了となる。
【００３０】
ここでは交通費申請の業務に関する成果物作成手順のみを示しているが、例えば休暇申請の業務等、他の業務に関する成果物作成手順もすべて同様に存在する。
【００３１】
図７はこのような成果物作成手順を格納する、ＤＢサーバ１０２の成果物作成手順情報格納手段２０３が保持するデータの一例を示したものである。
【００３２】
図７の列は成果物作成手順ID、該当業務名、リビジョン、適用開始年月日、備考から構成されている。該当業務名は、図６の説明で述べたように、交通費申請の業務や休暇申請の業務等、各業務の名前である。
【００３３】
成果物作成手順IDは、これらの業務を一意的に識別するために便宜上振ったIDである。ここでは交通費申請業務のIDを１、休暇申請業務のIDを２としている。各業務においては、成果物作成手順は複数存在する。それらをリビジョンで識別し、そのリビジョンの適用が開始された年月日を適用開始年月日欄に、リビジョンを作成した理由を備考欄に記載している。例えば交通費申請業務では、２０００年１月１日に成果物作成手順が新規作成（リビジョン１．０）されたのち、２０００年４月１日および２００１年４月１日に組織変更の影響でそれぞれリビジョン１．１、リビジョン１．２の適用が開始されている。さらに２００３年1月1日には運用変更によりリビジョン１．３の適用が開始されている。２００５年4月１日には手順が大きく変更されたためリビジョン２．０を適用した例となっている。休暇申請業務についても同様にリビジョン１．０、１．１、１．２、２．０、２．１が存在し、その他業務についても同様である。
【００３４】
図７では文字のみしか記述されていないが、各リビジョンに対して図６のような成果物作成手順が関連づけられて管理されている。例えば図７の交通費申請のリビジョン２．０が図６の成果物作成手順に対応する等。
【００３５】
図８は、各成果物作成手順の各ステップで作成される成果物を格納する、ＤＢサーバ１０２の成果物格納手段２０１に保持するデータの一例を示したものである。
【００３６】
図８の列は成果物ID、成果物名、作成者、作成年月日、親成果物IDから構成されている。成果物IDは各成果物を一意的に識別するためのIDである。成果物名は、各成果物の名前であり、各成果物作成手順のステップで作成された成果物の名前が格納される。作成者および作成年月日はそれぞれ、その成果物を作成した人の名前と作成した年月日である。最後の親成果物IDは、その成果物の前の工程での成果物に対する成果物IDを示している。各業務のまとまりを示すための情報である。
【００３７】
成果物ID＝１の成果物は図６のステップ６０２で作成された交通費申請書である。作成者はAさんで、２００６年９月１日に作成されている。また同じ日にはBさんからも成果物ID＝２として交通費申請書が成果物として格納されている。成果物ID＝３の成果物は図６のステップ６０４で作成された交通費却下書である。作成者はCさんで、２００６年９月２日に作成されている。
【００３８】
この親成果物IDは１であるため、成果物ID＝１でAさんが申請した交通費申請書に対する直属の係長Cさんの成果物であることが分かる。また同じ日にはDさんから成果物ID＝４で休暇申請書が成果物として格納されている。成果物ID＝５の成果物は、成果物ID＝３で却下された交通費の申請（成果物ID＝１）に対するAさんからの再申請（図６におけるステップ６０２）による成果物であり、成果物ID＝６の成果物は、成果物ID＝２でBさんからの交通費申請書が、直属の係長Eさんに承認された（図６のステップ６０３）ことを示している。以下同様に成果物が順次格納されている。
【００３９】
図６、図７、図８の例および図２、図３、図４、図９を用いて、本発明を実施の形態１、すなわち成果物作成におけるアクセス制御方法を説明する。
【００４０】
２００６年９月２日に作業者Cさんを考える。すなわち図９における作業者端末１０４iはCさんの端末を示している。
【００４１】
まずCさんは作業内容依頼手段４０１を用いてアプリケーションサーバ１０３に作業内容の問合せを行う（ステップ９０１）。アプリケーションサーバ１０３は依頼受付手段３０１でCさんからの依頼を受け付ける。この際、図示しない認証機能等で得たCさんの情報（所属、役職などの属性。ここではAさんの直属の係長であること）を依頼者情報格納手段３０２により格納する（ステップ９０２）。
【００４２】
次に成果物特定手段３０３により、依頼受付手段３０１で受け付けたCさんの作業内容依頼に該当する業務の成果物群の検索をＤＢサーバ１０２に依頼する（ステップ９０３）。ＤＢサーバ１０２は成果物検索手段２０２により成果物格納手段２０１で格納されている成果物を検索し、その結果をアプリケーションサーバ１０３に送る（ステップ９０４）。
【００４３】
ここでは図８における成果物ID＝１の１件だけが送られる。アプリケーションサーバ１０３は成果物群格納手段３０４によりこの１件を格納する（ステップ９０５）。
【００４４】
アプリケーションサーバ１０３は成果物作成手順情報特定手段３０５により、成果物群格納手段３０４に格納されている業務に関する成果物作成手順の検索を、ＤＢサーバ１０２に依頼する（ステップ９０６）。ここは例えば成果物群格納手段３０４に格納されている成果物ID＝１の１件は、２００６年９月１日に作成された交通費申請書であることをＤＢサーバ１０２に知らせる。ＤＢサーバ１０２は成果物作成手順検索手段２０４により成果物作成手順情報格納手段２０３で格納されている成果物作成手順を検索し、その結果をアプリケーションサーバ１０３に送る（ステップ９０７）。ここでは図７における成果物作成手順ID＝１のリビジョン２．０の成果物作成手順（ここでは図６とする）が送られる。アプリケーションサーバ１０３は成果物作成手順情報格納手段３０６によりこの成果物作成手順を格納する（ステップ９０８）。
【００４５】
次に、成果物格納手段３０４に格納されている成果物群と、成果物作成手順情報格納手段３０６に格納されている成果物作成手順より、成果物作成手順内位置特定手段３０７により、現在の成果物作成手順内での位置を特定する。ここでは交通費申請書が成果物群として格納されているため、現在の位置はステップ６０２であり、次の工程はステップ６０３かステップ６０４であることが判明する（ステップ９０９）。
【００４６】
次に担当者特定手段３０８により、ステップ６０３、ステップ６０４ともにAさんの直属の係長が次の工程の担当者であることが特定される（ステップ９１０）。
【００４７】
判定手段３０９は、担当者特定手段３０８の結果（次の工程の担当者はAさんの直属の係長）と依頼者情報格納手段３０２に格納されている情報（作業内容の依頼者CさんはAさんの直属の係長）から、Cさんは次の工程の担当者であることを判定し（ステップ９１１）、その旨をCさんの作業者端末１０４iに返す（ステップ９１２）。
【００４８】
Cさんの作業者端末１０４iはステップ９１２の結果を受けて、作業内容依頼結果表示手段４０２によりその結果を表示する。これを見たCさんは次の工程の担当者は自分であることが分かるため、成果物作成手段４０５を用いて担当の成果物を作成する。ステップ６０３またはステップ６０４のどちらかを選択できるが、ここではステップ６０４を選択したことにし、交通費却下書を成果物として作成し、成果物格納依頼手段４０６を用いてアプリケーションサーバ１０３にＤＢサーバ１０２の成果物格納手段２０１への格納を依頼する。
【００４９】
アプリケーションサーバ１０３は依頼受付手段３０１でCさんからの成果物格納依頼を受け付け、成果物格納依頼手段３１０を通じてＤＢサーバ１０２に成果物格納手段２０１への格納を依頼する。依頼を受けたＤＢサーバは成果物格納手段２０１に格納する（図８の成果物ID＝３）。
【００５０】
同じ２００６年９月２日で作業者Iさん（Aさんの直属の部長）を考える。すなわち図９における作業者端末１０４iはIさんの端末を示している。
【００５１】
まずIさんは作業内容依頼手段４０１を用いてアプリケーションサーバ１０３に作業内容の問合せを行う（ステップ９０１）。アプリケーションサーバ１０３は依頼受付手段３０１でIさんからの依頼を受け付ける。この際、図示しない認証機能等で得たIさんの情報（所属、役職などの属性。ここではAさんの直属の部長であること）を依頼者情報格納手段３０２により格納する（ステップ９０２）。
【００５２】
次に成果物特定手段３０３により、依頼受付手段３０１で受け付けたIさんの作業内容依頼に該当する業務の成果物群の検索をＤＢサーバ１０２に依頼する（ステップ９０３）。ＤＢサーバ１０２は成果物検索手段２０２により成果物格納手段２０１で格納されている成果物を検索し、その結果をアプリケーションサーバ１０３に送る（ステップ９０４）。ここでは図８における成果物ID＝１の１件だけが送られる。アプリケーションサーバ１０３は成果物群格納手段３０４によりこの１件を格納する（ステップ９０５）。
【００５３】
アプリケーションサーバ１０３は成果物作成手順情報特定手段３０５により、成果物群格納手段３０４に格納されている業務に関する成果物作成手順の検索を、ＤＢサーバ１０２に依頼する（ステップ９０６）。
【００５４】
ここは例えば成果物群格納手段３０４に格納されている成果物ID＝１の１件は、２００６年９月１日に作成された交通費申請書であることをＤＢサーバ１０２に知らせる。ＤＢサーバ１０２は成果物作成手順検索手段２０４により成果物作成手順情報格納手段２０３で格納されている成果物作成手順を検索し、その結果をアプリケーションサーバ１０３に送る（ステップ９０７）。
【００５５】
ここでは図７における成果物作成手順ID＝１のリビジョン２．０の成果物作成手順（ここでは図６とする）が送られる。アプリケーションサーバ１０３は成果物作成手順情報格納手段３０６によりこの成果物作成手順を格納する（ステップ９０８）。
【００５６】
次に、成果物格納手段３０４に格納されている成果物群と、成果物作成手順情報格納手段３０６に格納されている成果物作成手順情報より、成果物作成手順内位置特定手段３０７により、現在の成果物作成手順情報内での位置を特定する。ここでは交通費申請書が成果物群として格納されているため、現在の位置はステップ６０２であり、次の工程はステップ６０３かステップ６０４であることが判明する（ステップ９０９）。
【００５７】
次に担当者特定手段３０８により、ステップ６０３、ステップ６０４ともにAさんの直属の係長が次の工程の担当者であることが特定される（ステップ９１０）。
【００５８】
判定手段３０９は、担当者特定手段３０８の結果（次の工程の担当者はAさんの直属の係長）と依頼者情報格納手段３０２に格納されている情報（作業内容の依頼者IさんはAさんの直属の部長）から、Iさんは次の工程の担当者でないことを判定し（ステップ９１１）、その旨をIさんの作業者端末１０４iに返す（ステップ９１２）。
【００５９】
Iさんの作業者端末１０４iはステップ９１２の結果を受けて、作業内容依頼結果表示手段４０２によりその結果を表示する。これを見たIさんは次の工程の担当者は自分でないことが分かるため、この業務に対する作業は行わずに終了する。
【００６０】
しかし２００６年９月６日では、Iさんは、Aさんの交通費申請書（図８における成果物ID＝１）に関する業務の次の工程の担当者であるため、作業を行ってＤＢサーバ１０２にその結果を格納することになる。
【００６１】
以上のように、ステータスを保持することなしに、成果物作成のためのアクセス権限を制御するアクセス制御を実現することが可能となる。
【００６２】
ここで、成果物特定手段３０３で取得する該当成果物群は、成果物作成手順情報特定手段３０５で成果物作成手順情報を特定でき、かつ成果物作成手順情報内位置特定手段３０７で成果物作成手順情報内での現在の位置を特定できるものだけあれば十分である。
【００６３】
しかし、これを実現するためには、各成果物作成手順の各状態に対して、どの成果物を取得すべきかの情報を管理する必要がある。状態の数は膨大となる恐れがあり、実用上の問題となる可能性もある。そのため、成果物特定手段３０３を、該当業務におけるそれまでのすべての成果物を取得するように固定してもよい。
【００６４】
成果物作成手順情報特定手段３０５で成果物作成手順情報を特定し、かつ成果物作成手順情報内位置特定手段３０７で成果物作成手順情報内での現在の位置を特定するには無駄な成果物も取得することになるが、ネットワークの負荷および検索の負荷と引き換えに、上記の問題を回避することができる。
【００６５】
なお、図１０は従来技術である、図６、図８に対するステータス管理を示した図である。図８に格納されている２００６年９月１日から２００６年９月６日までの各業務のステータスを表している。２００６年９月１日終了時のステータスは、２件の業務が動いていて、１件は交通費申請業務で、Aさんが申請してCさんの承認を待っている状態を示している。
【００６６】
もう１件も交通費申請業務で、こちらはBさんが申請してEさんの承認を待っている状態を示している。以下同様に各日が終了した時点でのステータスを示している。ただしこれらのステータスは日の終了時に更新すればよいのではなく、各業務のステータスが遷移したときに反映させる必要がある。
【００６７】
図１０では同時に動いている業務が３個程度であるため単純に見えるが、実際は膨大な業務が同時に動いているので、管理するステータスも膨大になる。さらに組織変更や人事異動があった場合、例えばAさんの直属の係長がCさんからKさんに代わった場合、すべてのステータスにおいて、Aさんの直属の係長としてのCさんに関わるステータスをすべてKさんに変更しなければならない。
【００６８】
膨大なデータに対しては、変更漏れや変更間違いといった誤りも起きやすくなるため、ステータス管理のコストが膨大になる。さらには、実用上、実装不可能となる可能性も否定できない。
【００６９】
これに対し、本発明ではステータスを用いないため、上記問題は発生しない。組織変更や人事異動があった場合には、対応する成果物作成手順のみ更新すればよい。成果物作成手順の個数のほうがステータス情報の個数より遥かに少ない（成果物作成手順１個に対して複数の業務が存在するため）ため、組織変更や人事異動の際の管理コストを減らすことができる。
【００７０】
ステータスを用いない代わりに、成果物作成手順情報内位置特定手段３０７および担当者特定手段３０８が必要となるが、これらはそれぞれ１個の機能としてプログラム等で実現されるものであり、それぞれ１個ずつのプログラムを管理すればよいので、やはり膨大なステータスを管理するよりも管理コストを減らすことができると言える。
【００７１】
（実施の形態２）
次に図６、図７、図８の例および図２、図３、図４、図１１、図１２を用いて、本発明を実施の形態２、すなわち成果物閲覧におけるアクセス制御システムの概略を説明する。
【００７２】
２００６年９月２日に作業者IさんがAさんの交通費申請に関わる業務の成果物の閲覧をする場合を考える。すなわち図１１における作業者端末１０４iはIさんの端末を示している。
【００７３】
まずIさんは閲覧依頼手段４０３を用いてアプリケーションサーバ１０３に閲覧の問合せを行う（ステップ１１０１）。アプリケーションサーバ１０３は依頼受付手段３０１でIさんからの依頼を受け付ける。この際、図示しない認証機能等で得たIさんの情報（所属、役職などの属性。ここではAさんの直属の部長であること）を依頼者情報格納手段３０２により格納する（ステップ９０２）。
【００７４】
次に成果物特定手段３０３により、依頼受付手段３０１で受け付けたIさんの閲覧依頼に該当する業務の成果物群の検索をＤＢサーバ１０２に依頼する（ステップ９０３）。ＤＢサーバ１０２は成果物検索手段２０２により成果物格納手段２０１で格納されている成果物を検索し、その結果をアプリケーションサーバ１０３に送る（ステップ９０４）。
【００７５】
ここでは図８における成果物ID＝１の１件だけが送られる。アプリケーションサーバ１０３は成果物群格納手段３０４によりこの１件を格納する（ステップ９０５）。
【００７６】
アプリケーションサーバ１０３は成果物作成手順情報特定手段３０５により、成果物群格納手段３０４に格納されている業務に関する成果物作成手順情報の検索を、ＤＢサーバ１０２に依頼する（ステップ９０６）。ここは例えば成果物群格納手段３０４に格納されている成果物ID＝１の１件は、２００６年９月１日に作成された交通費申請書であることをＤＢサーバ１０２に知らせる。
【００７７】
ＤＢサーバ１０２は成果物作成手順情報検索手段２０４により成果物作成手順情報格納手段２０３で格納されている成果物作成手順情報を検索し、その結果をアプリケーションサーバ１０３に送る（ステップ９０７）。
【００７８】
ここでは図７における成果物作成手順ID＝１のリビジョン２．０の成果物作成手順（ここでは図６とする）が送られる。アプリケーションサーバ１０３は成果物作成手順情報格納手段３０６によりこの成果物作成手順を格納する（ステップ９０８）。
【００７９】
次に、成果物格納手段３０４に格納されている成果物群と、成果物作成手順情報格納手段３０６に格納されている成果物作成手順情報より、成果物作成手順情報内位置特定手段３０７により、現在の成果物作成手順情報内での位置を特定する。ここでは交通費申請書が成果物群として格納されているため、現在の位置はステップ６０２であり、次の工程はステップ６０３かステップ６０４であることが判明する（ステップ９０９）。
【００８０】
次に担当者特定手段３０８により、ステップ６０３、ステップ６０４ともにAさんの直属の係長が次の工程の担当者であることが特定される（ステップ９１０）。
【００８１】
判定手段３０９は、担当者特定手段３０８で特定された、次の工程の担当者の属性（ここではAさんの直属の係長）と依頼者情報格納手段３０２に格納されている情報（閲覧の依頼者IさんはAさんの直属の部長）から、閲覧の可否を判定する。
【００８２】
判定方法としては、例えば図１２のような表を使った方法が考えられる。図１２のアの表は、横軸が依頼者の所属部署、縦軸が次の工程の担当者の所属部署を示している。また、○は閲覧可であることを示し、×は閲覧不可であることを示している。例えば依頼者の所属が人事部で、次の工程の担当者の所属も人事部の場合は閲覧可であるが、次の工程の担当者の所属が法務部の場合は閲覧不可である。図１２のイの表は、横軸が依頼者の役職、縦軸が次の工程の担当者の役職を意味するもので、表の見方はアと同様である。これらの２つの表の結果がともに○の場合に閲覧可、その他の場合に閲覧不可であるとする。
【００８３】
今の場合、例えばAさんIさんともに人事部で、Aさんは一般社員であるとすると、アの表で○、イの表でも○となるため、IさんはAさんの交通費申請に関わる業務の成果物の閲覧は可であると判定される（ステップ１１１１）。
Iさんの作業者端末１０４iはステップ１１１２の結果を受けて、閲覧依頼結果表示手段４０４によりその結果、すなわちAさんの交通費申請に関わる業務の成果物を表示する。
【００８４】
仮に上記の閲覧申請者がIさんではなく、財務部の部長である場合は、図１２のイの表では○だがアの表では×であるため、Aさんの交通費申請に関わる業務の成果物の閲覧は不可であると判定される（ステップ１１１１）。
【００８５】
以上のように、ステータスを保持することなしに、成果物閲覧のためのアクセス権限を制御するアクセス制御を実現することが可能となる。
【００８６】
また、アクセスの可否の判定には、次の工程の担当者の属性を利用しているため、文書と閲覧権限情報を切り離して管理可能であることが分かる。さらに図１２の判定方法を用いれば、閲覧依頼者と次の工程の担当者の現在の所属、役職から、すべての業務における成果物の閲覧可否を判定できるため、過去の業務に対しても過去の情報を用いずにアクセス制御が可能となる。なぜならば、閲覧依頼者も、次の工程の担当者もその所属、役職は最新の組織情報下で定まるもの１つであるため、組織変更や人事異動が起きた場合には、図１２の表における部署名、役職名をすべて最新の名称に変換すればよいからである。
【００８７】
なお、図１２のアクセスの可否の判定方法が特異でないことは、電子的な成果物を仮に紙に置き換えたとして考えると納得しやすい。仮に成果物が紙であったとすると、１つの業務の成果物一式は、次の工程の担当者の手元にあるはずである。この担当者の手元にある書類を、まったく関係のない部署の人が閲覧可能であり、この担当者より低級の役職にある人が閲覧可能であるとは通常考えにくいからである。
【００８８】
なお、本発明は上述実施例そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上述実施例に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施例に示される全構成要素から幾つかの構成要素を省略してもよい。更に、異なる実施例に亘る構成要素を適宜組み合せてもよい。
【図面の簡単な説明】
【００８９】
【図１】本発明のアクセス制御を実現するシステム全体の概略図。
【図２】ＤＢサーバの概略機能ブロック図。
【図３】アプリケーションサーバの概略機能ブロック図。
【図４】作業者端末の概略機能ブロック図。
【図５】交通費申請ワークフローの一例を示す図。
【図６】交通費申請業務の成果物作成手順の一例を示す図。
【図７】成果物作成手順情報格納手段に格納されているデータの一例を示す図。
【図８】成果物格納手段に格納されているデータの一例を示す図。
【図９】成果物作成時のアクセス制御フローを示す図。
【図１０】ステータス管理の一例を示す図。
【図１１】成果物閲覧時のアクセス制御フローを示す図。
【図１２】成果物閲覧時の可否判断方法の一例を示す図。
【符号の説明】
【００９０】
１０１ ネットワーク
１０２ ＤＢサーバ
１０３ アプリケーションサーバ
１０４i 作業者端末
２０１ 成果物格納手段
２０２ 成果物検索手段
２０３ 成果物作成手順情報格納手段
２０４ 成果物作成手順検索手段
３０１ 依頼受付手段
３０２ 依頼者情報格納手段
３０３ 成果物特定手段
３０４ 成果物群格納手段
３０５ 成果物作成手順特定手段
３０６ 成果物作成手順情報格納手段
３０７ 成果物作成手順内位置特定手段
３０８ 担当者特定手段
３０９ 判定手段
３１０ 成果物格納依頼手段
４０１ 作業内容依頼手段
４０２ 作業内容依頼結果表示手段
４０３ 閲覧依頼手段
４０４ 閲覧依頼結果表示手段
４０５ 成果物作成手段
４０６ 成果物格納依頼手段
５０１ 業務開始ステップ
５０２ 個人による申請ステップ
５０３ 係長による承認／却下ステップ
５０４ 部長による承認／却下ステップ
５０５ 業務完了ステップ
６０１ 業務開始ステップ
６０２ 交通費申請書作成ステップ
６０４ 係長による交通費却下書作成ステップ
６０５ 部長による交通費承認書作成ステップ
６０６ 部長による交通費却下書作成ステップ
６０７ 業務完了ステップ
９０１ 作業内容の問合せステップ
９０２ 依頼者情報格納ステップ
９０３ 業務成果物群の検索依頼ステップ
９０４ 業務成果物群返答ステップ
９０５ 成果物群格納ステップ
９０６ 成果物作成手順の検索依頼ステップ
９０７ 成果物作成手順返答ステップ
９０８ 成果物作成手順格納ステップ
９０９ 成果物作成手順内位置特定ステップ
９１０ 次の工程の担当者特定ステップ
９１１ 判定ステップ
９１２ 判定結果返答ステップ
１１０１ 閲覧の問合せステップ
１１１１ 判定ステップ
１１１２ 判定結果返答ステップ
【技術分野】
【０００１】
本発明は、アクセス制御システムに関し、詳しくは所定の各業務（以下、「工程」と記載することもある。）の作業を行うことの可否に関するアクセス制御システム、および各成果物を閲覧することの可否に関するアクセス制御システムに関するものである。
【背景技術】
【０００２】
従来、企業等では、複数の担当者が関わり1つの業務を遂行するのが通常である。例えば、ある業務はいくつかの工程から構成されるとしたとき、ある担当者はその中の一部分の工程の作業を行い次の担当者に作業を引き渡し、引き渡された次の担当者はその次の一部分の工程の作業を行い、これを順次繰り返して1つの業務を完了させる、という具合である。
【０００３】
このように、1つの業務の各工程の順序や担当者をルール化したものはワークフロー、またワークフローに基づき業務の効率を向上させるインフラはワークフローシステムと呼ばれる。図５は、交通費の申請という１つの業務についてのワークフローの一例である（５０１）。申請者からの申請（５０２）の後、申請者の直属の係長が申請内容について承認／却下の判定をくだす（５０３）。却下の場合は５０２に戻って申請者が申請をやり直す。承認の場合は申請者の直属の部長が申請内容について承認／却下の判定をくだし（５０４）、却下の場合は５０２に戻って申請者が申請をやり直し、承認の場合はこの業務は完了となる（５０５）。
【０００４】
ワーククフローシステムでは、各担当者は各作業の結果として、何らかの成果物を電子的に作成する。例えば文書や、インフラ上で承認ボタンを押すことが、成果物にあたる。図５の例では、５０２での成果物は交通費の申請書であり、５０３、５０４は承認／却下ボタンの押下（または承認書、却下書）が成果物である。
【０００５】
このような成果物については、セキュリティ上の観点から、成果物を担当者外の人に作成させない、あるいは部外者に以前の成果物を閲覧したり引用したりさせない、といったアクセス権限の制御を行うことが重要となる。
【０００６】
ワークフローにおけるアクセス制御に関して、例えば特許文献１、２、３記載の公知技術が知られている。
【０００７】
特許文献１記載の従来技術は、複数の作業からなる業務の進捗状況を管理するワークフローシステムである。特許文献１の発明は、ある担当者が自分の担当の作業を行う際に、それに関連する他の担当者の作業がすべて処理されたことが確認されないと、その担当者の作業が開始できないようにアクセス制御することで、無駄な作業を行わなくて済むようにできることである。
【０００８】
特許文献２記載の従来技術は、組織変更や人事異動などの変化に対して、文書の閲覧権限を動的に変化させる電子文書回覧ワークフローシステムである。特許文献２の発明は、文書作成時に、閲覧権限設定に反映させる属性（個人属性、組織属性、役割属性）の組合せを選択しておき、当該文書作成に関わった担当者の人事情報を、上記設定されている属性のみに反映させるように制御することで、組織変更や人事異動などの人事環境の変化に対して、作成済みの文書の閲覧権限を動的に変化させることができることである。
【０００９】
特許文献３記載の従来技術は、組織変更や、回覧ルートに変更があっても問題なく処理できるワークフローシステムである。特許文献３の発明は、すべての世代の組織情報を保持しておき、新規文書作成の際にどの世代の組織情報を対象とするかを指定することで、旧組織情報でのワークフローを実現することである。また各業務ごとに業務発生時の回覧ルートを保持しておくことで、回覧ルートが変更されても業務発生時の回覧ルートで回覧できることである。
【００１０】
【特許文献１】特開２００５―２０２９２０号公報
【特許文献２】特開２００６―１７２３７７号公報
【特許文献３】特開２００６−１９５８３３号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、上記特許文献１では、各業務の進捗状況（各業務の現在のステータスという意味で、以下「ステータス」という。）をサーバが保持しており、各担当者がサーバに各自の次の作業を依頼したとき、サーバはそのステータスを参照して、次の作業の着手の可否を判断する構成になっている。
【００１２】
ところが、企業等での業務の数は通常膨大である。例えば、図５では交通費申請のワークフローを示しているが、同時にa人がそれぞれb件を申請したとすると、a×b件の業務が動いていることになる。また一般に交通費申請以外にもワークフローは多数あるため、大量のステータスを管理する必要がある。さらに組織変更や人事異動があった場合については特許文献１に言及はないが、管理しているステータスをすべて修正するという作業が発生することが予想される。このようにステータスの管理が非常に煩雑であるという問題点があった。
【００１３】
また、特許文献２では、閲覧に関し、文書作成時に後で変更可能な属性を定義していることで、権限情報が文書に紐付けされ、閲覧権限に必要な属性情報が増減した場合に対応しにくいという問題点があった。
【００１４】
特許文献３では、すべての世代の組織情報を管理しなくてはいけないということ、さらに旧組織情報でのワークフローを実現するためには、旧組織図だけでなく、その当時誰がどこに所属していたかという、今まで在籍していたすべての人の所属組織の経歴情報を保持しておかなくてはならないという問題点があった。
【００１５】
本発明は、上記従来の事情に基づいて提案されたものであって、成果物作成、または閲覧のためのアクセス権限を制御するアクセス制御システムにおいて、ステータスの保持が不要であり、かつ文書と閲覧権限情報を切り離して管理可能であり、さらに過去の組織情報を利用しなくても過去の業務に対して制御可能なアクセス制御システムを提供することを目的とする。
【課題を解決するための手段】
【００１６】
本発明は、上記目的を達成するために以下の手段を採用している。
つまり、本発明の第１の構成は、特定の業務を実施する担当者に対し、当該業務の成果物作成に関するアクセス権限を制御するアクセス制御システムにおいて、各業務において成果物を作成する手順及び当該業務を実施する担当者の関係を定める成果物作成手順情報を格納する成果物作成手順情報格納手段と、前記各業務に対する成果物を格納する成果物格納手段と、前記成果物格納手段から、前記成果物作成に該当する業務の成果物群を抽出する成果物特定手段と、前記成果物特定手段により抽出された前記成果物群と前記成果物作成手順情報格納手段から、該当する成果物作成手順情報を選択する成果物作成手順特定手段と、前記成果物群より、前記特定された成果物作成手順における現在の業務進捗を示す位置を特定する成果物作成手順内位置特定手段と、前記特定された前記成果物作成手順内の現在の業務進捗を示す位置から、前記成果物作成手順における次の業務の担当者を特定する担当者特定手段と、前記特定された担当者に対して前記次の業務の成果物作成に関するアクセス権限を与える判定手段とを備えることを特徴とする。
【００１７】
次に本発明の第１の構成の作用として、成果物作成のためのアクセス制御方法について述べる。
各業務において、成果物を作成する手順を定めた成果物作成手順を用いる。成果物作成手順は業務ごとに1個あり、手順の変更や組織の変更などを受けて随時更新される。ただし更新は新規に追加することを意味し、過去の成果物作成手順は削除されないことを前提とする。
これらの成果物作成手順は、成果物作成手順情報格納手段により、ＤＢ（データベース）に格納されている。
また、各成果物は、成果物格納手段によりＤＢに格納される。
ここで、上記ＤＢは追加格納、検索ができればよく、ファイルシステム等でも構わない。
ある業務に関し成果物を作成しようとしたときは、その業務に関する今までの成果物群（今までの成果すべてか、その一部）を、上記成果物格納手段から検索して選び出す。成果物群に含まれる情報より、上記成果物作成手順情報格納手段から、その業務に該当する成果物作成手順を検索する。選択された成果物作成手順に、上記成果物群を当てはめて、現在の進捗を示す位置を求め、次の工程およびその担当者を特定する。ここで特定された担当者のみに、次の工程の作業を許可する。
以上により、ステータスを管理することなしに、次の工程の担当者のみに作業を許可するアクセス制御を実現することができる。
【００１８】
次に、本発明の第２の構成は、特定の業務の成果物を閲覧する担当者に対し、当該業務の成果物閲覧に関するアクセス権限を制御するアクセス制御システムにおいて、各業務において成果物を作成する手順及び当該業務の担当者の属性情報を定める成果物作成手順情報を格納する成果物作成手順情報格納手段と、前記各業務に対する成果物を格納する成果物格納手段と、前記成果物格納手段から、前記成果物閲覧に該当する業務に関する成果物群を抽出する成果物特定手段と、前記成果物特定手段により抽出された前記成果物群と前記成果物作成手順情報格納手段から、該当する成果物作成手順情報を選択する成果物作成手順特定手段と、前記成果物群より、前記特定された成果物作成手順における現在の業務進捗を示す位置を特定する成果物作成手順内位置特定手段と、前記特定された前記成果物作成手順内の現在の業務進捗を示す位置から、前記成果物作成手順における次の業務の担当者を特定する担当者特定手段と、前記特定された担当者の属性情報に基づいて、前記成果物群の閲覧可能者を定める判定手段とを備えることを特徴とする。
【００１９】
次に本発明の第２の構成の作用として、成果物閲覧のためのアクセス制御方法について述べる。
次の工程およびその担当者の特定までは、上記成果物作成のためのアクセス制御方法と同様である。
次の作業の担当者の属性（所属や役職）により、成果物一式の閲覧可能者を定める。例えば次の作業の担当者と同じ所属であれば閲覧可としたり、次の作業の担当者より低級の役職では閲覧不可としたりできる。ここで属性は現在の属性を指す。
以上により、ステータスを管理することなしに、成果物閲覧に関するアクセス制御を実現することができる。さらに閲覧の可否は文書とは切り離して管理可能である。また、次の作業の担当者の属性は、現在の属性であるため、閲覧に関するアクセス制御に過去の情報を利用する必要がなくなる。
【発明の効果】
【００２０】
本発明に係る、成果物作成、または閲覧のためのアクセス権限を制御するアクセス制御方法においては、ステータスの保持が不要でありステータス管理のコストを削減できる。かつ文書と閲覧権限情報を切り離して管理可能であるため、閲覧権限情報をフレキシブルに変更可能である。さらに過去の組織情報を利用しなくても過去の業務に対して制御可能となる。
【発明を実施するための最良の形態】
【００２１】
以下、図面を参照して、本発明の詳細を説明する。なお、以下の実施の形態は、本発明を具体化した一例であって、本発明の技術的範囲を限定する性格のものではない。
【００２２】
（実施の形態１）
以下、本発明に係る実施の形態１におけるアクセス制御システムの概略について説明する。
図１は、本発明のアクセス制御を実現するシステム全体の概略図である。図１において、複数の作業者端末１０４1〜１０４n、ＤＢサーバ１０２、アプリケーションサーバ１０３はネットワーク１０１により接続され、相互にデータ送受信可能な構成になっている。ここで作業者端末１０４1〜１０４nはＰＣ（パーソナルコンピュータ）等である。ＤＢサーバ１０２とアプリケーションサーバ１０３は同一のコンピュータ上で実現されてもよい。またアプリケーションサーバ１０３の機能を各作業者端末１０４iが持っている構成でもよい。
【００２３】
図２はＤＢサーバ１０２の概略機能ブロック図である。ＤＢサーバ１０２は成果物格納手段２０１、成果物検索手段２０２、成果物作成手順情報格納手段２０３、成果物作成手順検索手段２０４から構成される。
【００２４】
図３はアプリケーションサーバ１０３の概略機能ブロック図である。アプリケーションサーバ１０３は依頼受付手段３０１、依頼者情報格納手段３０２、成果物特定手段３０３、成果物群格納手段３０４、成果物作成手順情報特定手段３０５、成果物作成手順情報格納手段３０６、成果物作成手順情報内位置特定手段３０７、担当者特定手段３０８、判定手段３０９、成果物格納依頼手段３１０から構成される。
【００２５】
図４は作業者端末１０４iの概略機能ブロック図である。作業者端末１０４iは作業内容依頼手段４０１、作業内容依頼結果表示手段４０２、閲覧依頼手段４０３、閲覧依頼結果表示手段４０４、成果物作成手段４０５、成果物格納依頼手段４０６から構成される。
【００２６】
図６は交通費申請の業務の成果物作成手順を示したもので、図５のワークフローに対応するものである。
【００２７】
この業務は、各個人が交通費申請書を作成することで開始される。成果物作成手順の６０２は、このステップでの成果物が交通費申請書であり、作成者は各個人であることを示している。次の工程における成果物は、交通費承認書（ステップ６０３）または交通費却下書（ステップ６０４）である。どちらも作成者はステップ６０２での申請者の直属の係長である。直属の係長がステップ６０２で申請された内容について承認する場合はステップ６０３に、却下する場合はステップ６０４に進むことを示している。
【００２８】
ステップ６０４に進みステップ６０２での申請が却下された場合の次の工程はステップ６０２であり、申請者の申請からやり直すことになる。ステップ６０３に進み承認された場合は、次の工程における成果物は、交通費承認書（ステップ６０５）または交通費却下書（ステップ６０６）である。どちらも作成者はステップ６０２での申請者の直属の部長である。直属の部長がステップ６０２で申請された内容について承認する場合はステップ６０５に、却下する場合はステップ６０６に進むことを示している。
【００２９】
ステップ６０６に進みステップ６０２での申請が却下された場合の次の工程はステップ６０２であり、申請者の申請からやり直すことになる。ステップ６０５に進み承認された場合はステップ６０７に進み、この業務は完了となる。
【００３０】
ここでは交通費申請の業務に関する成果物作成手順のみを示しているが、例えば休暇申請の業務等、他の業務に関する成果物作成手順もすべて同様に存在する。
【００３１】
図７はこのような成果物作成手順を格納する、ＤＢサーバ１０２の成果物作成手順情報格納手段２０３が保持するデータの一例を示したものである。
【００３２】
図７の列は成果物作成手順ID、該当業務名、リビジョン、適用開始年月日、備考から構成されている。該当業務名は、図６の説明で述べたように、交通費申請の業務や休暇申請の業務等、各業務の名前である。
【００３３】
成果物作成手順IDは、これらの業務を一意的に識別するために便宜上振ったIDである。ここでは交通費申請業務のIDを１、休暇申請業務のIDを２としている。各業務においては、成果物作成手順は複数存在する。それらをリビジョンで識別し、そのリビジョンの適用が開始された年月日を適用開始年月日欄に、リビジョンを作成した理由を備考欄に記載している。例えば交通費申請業務では、２０００年１月１日に成果物作成手順が新規作成（リビジョン１．０）されたのち、２０００年４月１日および２００１年４月１日に組織変更の影響でそれぞれリビジョン１．１、リビジョン１．２の適用が開始されている。さらに２００３年1月1日には運用変更によりリビジョン１．３の適用が開始されている。２００５年4月１日には手順が大きく変更されたためリビジョン２．０を適用した例となっている。休暇申請業務についても同様にリビジョン１．０、１．１、１．２、２．０、２．１が存在し、その他業務についても同様である。
【００３４】
図７では文字のみしか記述されていないが、各リビジョンに対して図６のような成果物作成手順が関連づけられて管理されている。例えば図７の交通費申請のリビジョン２．０が図６の成果物作成手順に対応する等。
【００３５】
図８は、各成果物作成手順の各ステップで作成される成果物を格納する、ＤＢサーバ１０２の成果物格納手段２０１に保持するデータの一例を示したものである。
【００３６】
図８の列は成果物ID、成果物名、作成者、作成年月日、親成果物IDから構成されている。成果物IDは各成果物を一意的に識別するためのIDである。成果物名は、各成果物の名前であり、各成果物作成手順のステップで作成された成果物の名前が格納される。作成者および作成年月日はそれぞれ、その成果物を作成した人の名前と作成した年月日である。最後の親成果物IDは、その成果物の前の工程での成果物に対する成果物IDを示している。各業務のまとまりを示すための情報である。
【００３７】
成果物ID＝１の成果物は図６のステップ６０２で作成された交通費申請書である。作成者はAさんで、２００６年９月１日に作成されている。また同じ日にはBさんからも成果物ID＝２として交通費申請書が成果物として格納されている。成果物ID＝３の成果物は図６のステップ６０４で作成された交通費却下書である。作成者はCさんで、２００６年９月２日に作成されている。
【００３８】
この親成果物IDは１であるため、成果物ID＝１でAさんが申請した交通費申請書に対する直属の係長Cさんの成果物であることが分かる。また同じ日にはDさんから成果物ID＝４で休暇申請書が成果物として格納されている。成果物ID＝５の成果物は、成果物ID＝３で却下された交通費の申請（成果物ID＝１）に対するAさんからの再申請（図６におけるステップ６０２）による成果物であり、成果物ID＝６の成果物は、成果物ID＝２でBさんからの交通費申請書が、直属の係長Eさんに承認された（図６のステップ６０３）ことを示している。以下同様に成果物が順次格納されている。
【００３９】
図６、図７、図８の例および図２、図３、図４、図９を用いて、本発明を実施の形態１、すなわち成果物作成におけるアクセス制御方法を説明する。
【００４０】
２００６年９月２日に作業者Cさんを考える。すなわち図９における作業者端末１０４iはCさんの端末を示している。
【００４１】
まずCさんは作業内容依頼手段４０１を用いてアプリケーションサーバ１０３に作業内容の問合せを行う（ステップ９０１）。アプリケーションサーバ１０３は依頼受付手段３０１でCさんからの依頼を受け付ける。この際、図示しない認証機能等で得たCさんの情報（所属、役職などの属性。ここではAさんの直属の係長であること）を依頼者情報格納手段３０２により格納する（ステップ９０２）。
【００４２】
次に成果物特定手段３０３により、依頼受付手段３０１で受け付けたCさんの作業内容依頼に該当する業務の成果物群の検索をＤＢサーバ１０２に依頼する（ステップ９０３）。ＤＢサーバ１０２は成果物検索手段２０２により成果物格納手段２０１で格納されている成果物を検索し、その結果をアプリケーションサーバ１０３に送る（ステップ９０４）。
【００４３】
ここでは図８における成果物ID＝１の１件だけが送られる。アプリケーションサーバ１０３は成果物群格納手段３０４によりこの１件を格納する（ステップ９０５）。
【００４４】
アプリケーションサーバ１０３は成果物作成手順情報特定手段３０５により、成果物群格納手段３０４に格納されている業務に関する成果物作成手順の検索を、ＤＢサーバ１０２に依頼する（ステップ９０６）。ここは例えば成果物群格納手段３０４に格納されている成果物ID＝１の１件は、２００６年９月１日に作成された交通費申請書であることをＤＢサーバ１０２に知らせる。ＤＢサーバ１０２は成果物作成手順検索手段２０４により成果物作成手順情報格納手段２０３で格納されている成果物作成手順を検索し、その結果をアプリケーションサーバ１０３に送る（ステップ９０７）。ここでは図７における成果物作成手順ID＝１のリビジョン２．０の成果物作成手順（ここでは図６とする）が送られる。アプリケーションサーバ１０３は成果物作成手順情報格納手段３０６によりこの成果物作成手順を格納する（ステップ９０８）。
【００４５】
次に、成果物格納手段３０４に格納されている成果物群と、成果物作成手順情報格納手段３０６に格納されている成果物作成手順より、成果物作成手順内位置特定手段３０７により、現在の成果物作成手順内での位置を特定する。ここでは交通費申請書が成果物群として格納されているため、現在の位置はステップ６０２であり、次の工程はステップ６０３かステップ６０４であることが判明する（ステップ９０９）。
【００４６】
次に担当者特定手段３０８により、ステップ６０３、ステップ６０４ともにAさんの直属の係長が次の工程の担当者であることが特定される（ステップ９１０）。
【００４７】
判定手段３０９は、担当者特定手段３０８の結果（次の工程の担当者はAさんの直属の係長）と依頼者情報格納手段３０２に格納されている情報（作業内容の依頼者CさんはAさんの直属の係長）から、Cさんは次の工程の担当者であることを判定し（ステップ９１１）、その旨をCさんの作業者端末１０４iに返す（ステップ９１２）。
【００４８】
Cさんの作業者端末１０４iはステップ９１２の結果を受けて、作業内容依頼結果表示手段４０２によりその結果を表示する。これを見たCさんは次の工程の担当者は自分であることが分かるため、成果物作成手段４０５を用いて担当の成果物を作成する。ステップ６０３またはステップ６０４のどちらかを選択できるが、ここではステップ６０４を選択したことにし、交通費却下書を成果物として作成し、成果物格納依頼手段４０６を用いてアプリケーションサーバ１０３にＤＢサーバ１０２の成果物格納手段２０１への格納を依頼する。
【００４９】
アプリケーションサーバ１０３は依頼受付手段３０１でCさんからの成果物格納依頼を受け付け、成果物格納依頼手段３１０を通じてＤＢサーバ１０２に成果物格納手段２０１への格納を依頼する。依頼を受けたＤＢサーバは成果物格納手段２０１に格納する（図８の成果物ID＝３）。
【００５０】
同じ２００６年９月２日で作業者Iさん（Aさんの直属の部長）を考える。すなわち図９における作業者端末１０４iはIさんの端末を示している。
【００５１】
まずIさんは作業内容依頼手段４０１を用いてアプリケーションサーバ１０３に作業内容の問合せを行う（ステップ９０１）。アプリケーションサーバ１０３は依頼受付手段３０１でIさんからの依頼を受け付ける。この際、図示しない認証機能等で得たIさんの情報（所属、役職などの属性。ここではAさんの直属の部長であること）を依頼者情報格納手段３０２により格納する（ステップ９０２）。
【００５２】
次に成果物特定手段３０３により、依頼受付手段３０１で受け付けたIさんの作業内容依頼に該当する業務の成果物群の検索をＤＢサーバ１０２に依頼する（ステップ９０３）。ＤＢサーバ１０２は成果物検索手段２０２により成果物格納手段２０１で格納されている成果物を検索し、その結果をアプリケーションサーバ１０３に送る（ステップ９０４）。ここでは図８における成果物ID＝１の１件だけが送られる。アプリケーションサーバ１０３は成果物群格納手段３０４によりこの１件を格納する（ステップ９０５）。
【００５３】
アプリケーションサーバ１０３は成果物作成手順情報特定手段３０５により、成果物群格納手段３０４に格納されている業務に関する成果物作成手順の検索を、ＤＢサーバ１０２に依頼する（ステップ９０６）。
【００５４】
ここは例えば成果物群格納手段３０４に格納されている成果物ID＝１の１件は、２００６年９月１日に作成された交通費申請書であることをＤＢサーバ１０２に知らせる。ＤＢサーバ１０２は成果物作成手順検索手段２０４により成果物作成手順情報格納手段２０３で格納されている成果物作成手順を検索し、その結果をアプリケーションサーバ１０３に送る（ステップ９０７）。
【００５５】
ここでは図７における成果物作成手順ID＝１のリビジョン２．０の成果物作成手順（ここでは図６とする）が送られる。アプリケーションサーバ１０３は成果物作成手順情報格納手段３０６によりこの成果物作成手順を格納する（ステップ９０８）。
【００５６】
次に、成果物格納手段３０４に格納されている成果物群と、成果物作成手順情報格納手段３０６に格納されている成果物作成手順情報より、成果物作成手順内位置特定手段３０７により、現在の成果物作成手順情報内での位置を特定する。ここでは交通費申請書が成果物群として格納されているため、現在の位置はステップ６０２であり、次の工程はステップ６０３かステップ６０４であることが判明する（ステップ９０９）。
【００５７】
次に担当者特定手段３０８により、ステップ６０３、ステップ６０４ともにAさんの直属の係長が次の工程の担当者であることが特定される（ステップ９１０）。
【００５８】
判定手段３０９は、担当者特定手段３０８の結果（次の工程の担当者はAさんの直属の係長）と依頼者情報格納手段３０２に格納されている情報（作業内容の依頼者IさんはAさんの直属の部長）から、Iさんは次の工程の担当者でないことを判定し（ステップ９１１）、その旨をIさんの作業者端末１０４iに返す（ステップ９１２）。
【００５９】
Iさんの作業者端末１０４iはステップ９１２の結果を受けて、作業内容依頼結果表示手段４０２によりその結果を表示する。これを見たIさんは次の工程の担当者は自分でないことが分かるため、この業務に対する作業は行わずに終了する。
【００６０】
しかし２００６年９月６日では、Iさんは、Aさんの交通費申請書（図８における成果物ID＝１）に関する業務の次の工程の担当者であるため、作業を行ってＤＢサーバ１０２にその結果を格納することになる。
【００６１】
以上のように、ステータスを保持することなしに、成果物作成のためのアクセス権限を制御するアクセス制御を実現することが可能となる。
【００６２】
ここで、成果物特定手段３０３で取得する該当成果物群は、成果物作成手順情報特定手段３０５で成果物作成手順情報を特定でき、かつ成果物作成手順情報内位置特定手段３０７で成果物作成手順情報内での現在の位置を特定できるものだけあれば十分である。
【００６３】
しかし、これを実現するためには、各成果物作成手順の各状態に対して、どの成果物を取得すべきかの情報を管理する必要がある。状態の数は膨大となる恐れがあり、実用上の問題となる可能性もある。そのため、成果物特定手段３０３を、該当業務におけるそれまでのすべての成果物を取得するように固定してもよい。
【００６４】
成果物作成手順情報特定手段３０５で成果物作成手順情報を特定し、かつ成果物作成手順情報内位置特定手段３０７で成果物作成手順情報内での現在の位置を特定するには無駄な成果物も取得することになるが、ネットワークの負荷および検索の負荷と引き換えに、上記の問題を回避することができる。
【００６５】
なお、図１０は従来技術である、図６、図８に対するステータス管理を示した図である。図８に格納されている２００６年９月１日から２００６年９月６日までの各業務のステータスを表している。２００６年９月１日終了時のステータスは、２件の業務が動いていて、１件は交通費申請業務で、Aさんが申請してCさんの承認を待っている状態を示している。
【００６６】
もう１件も交通費申請業務で、こちらはBさんが申請してEさんの承認を待っている状態を示している。以下同様に各日が終了した時点でのステータスを示している。ただしこれらのステータスは日の終了時に更新すればよいのではなく、各業務のステータスが遷移したときに反映させる必要がある。
【００６７】
図１０では同時に動いている業務が３個程度であるため単純に見えるが、実際は膨大な業務が同時に動いているので、管理するステータスも膨大になる。さらに組織変更や人事異動があった場合、例えばAさんの直属の係長がCさんからKさんに代わった場合、すべてのステータスにおいて、Aさんの直属の係長としてのCさんに関わるステータスをすべてKさんに変更しなければならない。
【００６８】
膨大なデータに対しては、変更漏れや変更間違いといった誤りも起きやすくなるため、ステータス管理のコストが膨大になる。さらには、実用上、実装不可能となる可能性も否定できない。
【００６９】
これに対し、本発明ではステータスを用いないため、上記問題は発生しない。組織変更や人事異動があった場合には、対応する成果物作成手順のみ更新すればよい。成果物作成手順の個数のほうがステータス情報の個数より遥かに少ない（成果物作成手順１個に対して複数の業務が存在するため）ため、組織変更や人事異動の際の管理コストを減らすことができる。
【００７０】
ステータスを用いない代わりに、成果物作成手順情報内位置特定手段３０７および担当者特定手段３０８が必要となるが、これらはそれぞれ１個の機能としてプログラム等で実現されるものであり、それぞれ１個ずつのプログラムを管理すればよいので、やはり膨大なステータスを管理するよりも管理コストを減らすことができると言える。
【００７１】
（実施の形態２）
次に図６、図７、図８の例および図２、図３、図４、図１１、図１２を用いて、本発明を実施の形態２、すなわち成果物閲覧におけるアクセス制御システムの概略を説明する。
【００７２】
２００６年９月２日に作業者IさんがAさんの交通費申請に関わる業務の成果物の閲覧をする場合を考える。すなわち図１１における作業者端末１０４iはIさんの端末を示している。
【００７３】
まずIさんは閲覧依頼手段４０３を用いてアプリケーションサーバ１０３に閲覧の問合せを行う（ステップ１１０１）。アプリケーションサーバ１０３は依頼受付手段３０１でIさんからの依頼を受け付ける。この際、図示しない認証機能等で得たIさんの情報（所属、役職などの属性。ここではAさんの直属の部長であること）を依頼者情報格納手段３０２により格納する（ステップ９０２）。
【００７４】
次に成果物特定手段３０３により、依頼受付手段３０１で受け付けたIさんの閲覧依頼に該当する業務の成果物群の検索をＤＢサーバ１０２に依頼する（ステップ９０３）。ＤＢサーバ１０２は成果物検索手段２０２により成果物格納手段２０１で格納されている成果物を検索し、その結果をアプリケーションサーバ１０３に送る（ステップ９０４）。
【００７５】
ここでは図８における成果物ID＝１の１件だけが送られる。アプリケーションサーバ１０３は成果物群格納手段３０４によりこの１件を格納する（ステップ９０５）。
【００７６】
アプリケーションサーバ１０３は成果物作成手順情報特定手段３０５により、成果物群格納手段３０４に格納されている業務に関する成果物作成手順情報の検索を、ＤＢサーバ１０２に依頼する（ステップ９０６）。ここは例えば成果物群格納手段３０４に格納されている成果物ID＝１の１件は、２００６年９月１日に作成された交通費申請書であることをＤＢサーバ１０２に知らせる。
【００７７】
ＤＢサーバ１０２は成果物作成手順情報検索手段２０４により成果物作成手順情報格納手段２０３で格納されている成果物作成手順情報を検索し、その結果をアプリケーションサーバ１０３に送る（ステップ９０７）。
【００７８】
ここでは図７における成果物作成手順ID＝１のリビジョン２．０の成果物作成手順（ここでは図６とする）が送られる。アプリケーションサーバ１０３は成果物作成手順情報格納手段３０６によりこの成果物作成手順を格納する（ステップ９０８）。
【００７９】
次に、成果物格納手段３０４に格納されている成果物群と、成果物作成手順情報格納手段３０６に格納されている成果物作成手順情報より、成果物作成手順情報内位置特定手段３０７により、現在の成果物作成手順情報内での位置を特定する。ここでは交通費申請書が成果物群として格納されているため、現在の位置はステップ６０２であり、次の工程はステップ６０３かステップ６０４であることが判明する（ステップ９０９）。
【００８０】
次に担当者特定手段３０８により、ステップ６０３、ステップ６０４ともにAさんの直属の係長が次の工程の担当者であることが特定される（ステップ９１０）。
【００８１】
判定手段３０９は、担当者特定手段３０８で特定された、次の工程の担当者の属性（ここではAさんの直属の係長）と依頼者情報格納手段３０２に格納されている情報（閲覧の依頼者IさんはAさんの直属の部長）から、閲覧の可否を判定する。
【００８２】
判定方法としては、例えば図１２のような表を使った方法が考えられる。図１２のアの表は、横軸が依頼者の所属部署、縦軸が次の工程の担当者の所属部署を示している。また、○は閲覧可であることを示し、×は閲覧不可であることを示している。例えば依頼者の所属が人事部で、次の工程の担当者の所属も人事部の場合は閲覧可であるが、次の工程の担当者の所属が法務部の場合は閲覧不可である。図１２のイの表は、横軸が依頼者の役職、縦軸が次の工程の担当者の役職を意味するもので、表の見方はアと同様である。これらの２つの表の結果がともに○の場合に閲覧可、その他の場合に閲覧不可であるとする。
【００８３】
今の場合、例えばAさんIさんともに人事部で、Aさんは一般社員であるとすると、アの表で○、イの表でも○となるため、IさんはAさんの交通費申請に関わる業務の成果物の閲覧は可であると判定される（ステップ１１１１）。
Iさんの作業者端末１０４iはステップ１１１２の結果を受けて、閲覧依頼結果表示手段４０４によりその結果、すなわちAさんの交通費申請に関わる業務の成果物を表示する。
【００８４】
仮に上記の閲覧申請者がIさんではなく、財務部の部長である場合は、図１２のイの表では○だがアの表では×であるため、Aさんの交通費申請に関わる業務の成果物の閲覧は不可であると判定される（ステップ１１１１）。
【００８５】
以上のように、ステータスを保持することなしに、成果物閲覧のためのアクセス権限を制御するアクセス制御を実現することが可能となる。
【００８６】
また、アクセスの可否の判定には、次の工程の担当者の属性を利用しているため、文書と閲覧権限情報を切り離して管理可能であることが分かる。さらに図１２の判定方法を用いれば、閲覧依頼者と次の工程の担当者の現在の所属、役職から、すべての業務における成果物の閲覧可否を判定できるため、過去の業務に対しても過去の情報を用いずにアクセス制御が可能となる。なぜならば、閲覧依頼者も、次の工程の担当者もその所属、役職は最新の組織情報下で定まるもの１つであるため、組織変更や人事異動が起きた場合には、図１２の表における部署名、役職名をすべて最新の名称に変換すればよいからである。
【００８７】
なお、図１２のアクセスの可否の判定方法が特異でないことは、電子的な成果物を仮に紙に置き換えたとして考えると納得しやすい。仮に成果物が紙であったとすると、１つの業務の成果物一式は、次の工程の担当者の手元にあるはずである。この担当者の手元にある書類を、まったく関係のない部署の人が閲覧可能であり、この担当者より低級の役職にある人が閲覧可能であるとは通常考えにくいからである。
【００８８】
なお、本発明は上述実施例そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上述実施例に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施例に示される全構成要素から幾つかの構成要素を省略してもよい。更に、異なる実施例に亘る構成要素を適宜組み合せてもよい。
【図面の簡単な説明】
【００８９】
【図１】本発明のアクセス制御を実現するシステム全体の概略図。
【図２】ＤＢサーバの概略機能ブロック図。
【図３】アプリケーションサーバの概略機能ブロック図。
【図４】作業者端末の概略機能ブロック図。
【図５】交通費申請ワークフローの一例を示す図。
【図６】交通費申請業務の成果物作成手順の一例を示す図。
【図７】成果物作成手順情報格納手段に格納されているデータの一例を示す図。
【図８】成果物格納手段に格納されているデータの一例を示す図。
【図９】成果物作成時のアクセス制御フローを示す図。
【図１０】ステータス管理の一例を示す図。
【図１１】成果物閲覧時のアクセス制御フローを示す図。
【図１２】成果物閲覧時の可否判断方法の一例を示す図。
【符号の説明】
【００９０】
１０１ ネットワーク
１０２ ＤＢサーバ
１０３ アプリケーションサーバ
１０４i 作業者端末
２０１ 成果物格納手段
２０２ 成果物検索手段
２０３ 成果物作成手順情報格納手段
２０４ 成果物作成手順検索手段
３０１ 依頼受付手段
３０２ 依頼者情報格納手段
３０３ 成果物特定手段
３０４ 成果物群格納手段
３０５ 成果物作成手順特定手段
３０６ 成果物作成手順情報格納手段
３０７ 成果物作成手順内位置特定手段
３０８ 担当者特定手段
３０９ 判定手段
３１０ 成果物格納依頼手段
４０１ 作業内容依頼手段
４０２ 作業内容依頼結果表示手段
４０３ 閲覧依頼手段
４０４ 閲覧依頼結果表示手段
４０５ 成果物作成手段
４０６ 成果物格納依頼手段
５０１ 業務開始ステップ
５０２ 個人による申請ステップ
５０３ 係長による承認／却下ステップ
５０４ 部長による承認／却下ステップ
５０５ 業務完了ステップ
６０１ 業務開始ステップ
６０２ 交通費申請書作成ステップ
６０４ 係長による交通費却下書作成ステップ
６０５ 部長による交通費承認書作成ステップ
６０６ 部長による交通費却下書作成ステップ
６０７ 業務完了ステップ
９０１ 作業内容の問合せステップ
９０２ 依頼者情報格納ステップ
９０３ 業務成果物群の検索依頼ステップ
９０４ 業務成果物群返答ステップ
９０５ 成果物群格納ステップ
９０６ 成果物作成手順の検索依頼ステップ
９０７ 成果物作成手順返答ステップ
９０８ 成果物作成手順格納ステップ
９０９ 成果物作成手順内位置特定ステップ
９１０ 次の工程の担当者特定ステップ
９１１ 判定ステップ
９１２ 判定結果返答ステップ
１１０１ 閲覧の問合せステップ
１１１１ 判定ステップ
１１１２ 判定結果返答ステップ
【特許請求の範囲】
【請求項１】
特定の業務を実施する担当者に対し、当該業務の成果物作成に関するアクセス権限を制御するアクセス制御システムにおいて、
各業務において成果物を作成する手順及び当該業務を実施する担当者の関係を定める成果物作成手順情報を格納する成果物作成手順情報格納手段と、
前記各業務に対する成果物を格納する成果物格納手段と、
前記成果物格納手段から、前記成果物作成に該当する業務の成果物群を抽出する成果物特定手段と、
前記成果物特定手段により抽出された前記成果物群と前記成果物作成手順情報格納手段から、該当する成果物作成手順情報を選択する成果物作成手順特定手段と、
前記成果物群より、前記特定された成果物作成手順における現在の業務進捗を示す位置を特定する成果物作成手順内位置特定手段と、
前記特定された前記成果物作成手順内の現在の業務進捗を示す位置から、前記成果物作成手順における次の業務の担当者を特定する担当者特定手段と、
前記特定された担当者に対して前記次の業務の成果物作成に関するアクセス権限を与える判定手段と、
を備えることを特徴とするアクセス制御システム。
【請求項２】
上記成果物特定手段は、該当する業務に関するすべての成果物を選び出すことを特徴とする請求項１に記載のアクセス制御システム。
【請求項３】
上記成果物作成手順特定手段は、上記成果物群から定まる年月日、及び／または時間を参照することを特徴とする請求項２に記載のアクセス制御システム。
【請求項４】
上記担当者特定手段は、上記次の工程の担当グループを特定し、上記判定手段は前記特定された担当グループに属する人にのみ前記次の工程の成果物作成のための作業に対するアクセス権限を与えることを特徴とする請求項２に記載のアクセス制御システム。
【請求項５】
特定の業務の成果物を閲覧する担当者に対し、当該業務の成果物閲覧に関するアクセス権限を制御するアクセス制御システムにおいて、
各業務において成果物を作成する手順及び当該業務の担当者の属性情報を定める成果物作成手順情報を格納する成果物作成手順情報格納手段と、
前記各業務に対する成果物を格納する成果物格納手段と、
前記成果物格納手段から、前記成果物閲覧に該当する業務に関する成果物群を抽出する成果物特定手段と、
前記成果物特定手段により抽出された前記成果物群と前記成果物作成手順情報格納手段から、該当する成果物作成手順情報を選択する成果物作成手順特定手段と、
前記成果物群より、前記特定された成果物作成手順における現在の業務進捗を示す位置を特定する成果物作成手順内位置特定手段と、
前記特定された前記成果物作成手順内の現在の業務進捗を示す位置から、前記成果物作成手順における次の業務の担当者を特定する担当者特定手段と、
前記特定された担当者の属性情報に基づいて、前記成果物群の閲覧可能者を定める判定手段と、
を備えることを特徴とするアクセス制御システム。
【請求項６】
上記成果物特定手段は、該当する業務に関するすべての成果物を選び出すことを特徴とする請求項５に記載のアクセス制御システム。
【請求項７】
上記成果物作成手順特定手段は、上記成果物群から定まる年月日、及び／または時間を参照することを特徴とする請求項６に記載のアクセス制御システム。
【請求項８】
上記担当者特定手段は、上記次の工程の担当グループを特定し、上記判定手段は前記特定された担当グループに属するそれぞれの人の属性により定まる前記成果物群の閲覧可能者の論理和により前記成果物群の閲覧可能者を定めることを特徴とする請求項６に記載のアクセス制御システム。
【請求項９】
上記担当者の属性として、所属、及び／または役職を参照することを特徴とする請求項６に記載のアクセス制御システム。
【請求項１】
特定の業務を実施する担当者に対し、当該業務の成果物作成に関するアクセス権限を制御するアクセス制御システムにおいて、
各業務において成果物を作成する手順及び当該業務を実施する担当者の関係を定める成果物作成手順情報を格納する成果物作成手順情報格納手段と、
前記各業務に対する成果物を格納する成果物格納手段と、
前記成果物格納手段から、前記成果物作成に該当する業務の成果物群を抽出する成果物特定手段と、
前記成果物特定手段により抽出された前記成果物群と前記成果物作成手順情報格納手段から、該当する成果物作成手順情報を選択する成果物作成手順特定手段と、
前記成果物群より、前記特定された成果物作成手順における現在の業務進捗を示す位置を特定する成果物作成手順内位置特定手段と、
前記特定された前記成果物作成手順内の現在の業務進捗を示す位置から、前記成果物作成手順における次の業務の担当者を特定する担当者特定手段と、
前記特定された担当者に対して前記次の業務の成果物作成に関するアクセス権限を与える判定手段と、
を備えることを特徴とするアクセス制御システム。
【請求項２】
上記成果物特定手段は、該当する業務に関するすべての成果物を選び出すことを特徴とする請求項１に記載のアクセス制御システム。
【請求項３】
上記成果物作成手順特定手段は、上記成果物群から定まる年月日、及び／または時間を参照することを特徴とする請求項２に記載のアクセス制御システム。
【請求項４】
上記担当者特定手段は、上記次の工程の担当グループを特定し、上記判定手段は前記特定された担当グループに属する人にのみ前記次の工程の成果物作成のための作業に対するアクセス権限を与えることを特徴とする請求項２に記載のアクセス制御システム。
【請求項５】
特定の業務の成果物を閲覧する担当者に対し、当該業務の成果物閲覧に関するアクセス権限を制御するアクセス制御システムにおいて、
各業務において成果物を作成する手順及び当該業務の担当者の属性情報を定める成果物作成手順情報を格納する成果物作成手順情報格納手段と、
前記各業務に対する成果物を格納する成果物格納手段と、
前記成果物格納手段から、前記成果物閲覧に該当する業務に関する成果物群を抽出する成果物特定手段と、
前記成果物特定手段により抽出された前記成果物群と前記成果物作成手順情報格納手段から、該当する成果物作成手順情報を選択する成果物作成手順特定手段と、
前記成果物群より、前記特定された成果物作成手順における現在の業務進捗を示す位置を特定する成果物作成手順内位置特定手段と、
前記特定された前記成果物作成手順内の現在の業務進捗を示す位置から、前記成果物作成手順における次の業務の担当者を特定する担当者特定手段と、
前記特定された担当者の属性情報に基づいて、前記成果物群の閲覧可能者を定める判定手段と、
を備えることを特徴とするアクセス制御システム。
【請求項６】
上記成果物特定手段は、該当する業務に関するすべての成果物を選び出すことを特徴とする請求項５に記載のアクセス制御システム。
【請求項７】
上記成果物作成手順特定手段は、上記成果物群から定まる年月日、及び／または時間を参照することを特徴とする請求項６に記載のアクセス制御システム。
【請求項８】
上記担当者特定手段は、上記次の工程の担当グループを特定し、上記判定手段は前記特定された担当グループに属するそれぞれの人の属性により定まる前記成果物群の閲覧可能者の論理和により前記成果物群の閲覧可能者を定めることを特徴とする請求項６に記載のアクセス制御システム。
【請求項９】
上記担当者の属性として、所属、及び／または役職を参照することを特徴とする請求項６に記載のアクセス制御システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２００８−６５４６１（Ｐ２００８−６５４６１Ａ）
【公開日】平成２０年３月２１日（２００８．３．２１）
【国際特許分類】
【出願番号】特願２００６−２４０４１３（Ｐ２００６−２４０４１３）
【出願日】平成１８年９月５日（２００６．９．５）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【Ｆターム（参考）】
【公開日】平成２０年３月２１日（２００８．３．２１）
【国際特許分類】
【出願日】平成１８年９月５日（２００６．９．５）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【Ｆターム（参考）】
[ Back to top ]