JP2003331095A - Ｄｂ管理によるワークフロー（申請承認業務）システム - Google Patents

Abstract

(57)【要約】 【課題】 承認者の作業場所を柔軟に変更すること、お
よび申請書類の承認状況管理を可能とする申請承認シス
テムを提供する。 【解決手段】 Ｗｅｂサーバ２００と、ネットワークを
介してＷｅｂサーバ２００に接続されるクライアント１
００と、データベース３００と、Ｗｅｂサーバ２００内
のデータベースアクセスモジュール２１０とから構成さ
れ、データベース３００にはクライアント１００から入
力された申請書データが格納され、データベースアクセ
スモジュール２１０は、申請書データを、データベース
３００に格納された所定の承認ルートにしたがって、必
要な承認者間に回覧し、それぞれの申請書データに関す
る承認履歴を管理する。データベースアクセスモジュー
ル２１０は、また、利用者を識別して各利用者ごとに指
定された画面パターンをクライアント１００に表示させ
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、申請書類の承認処
理を支援するシステムに関し、特に、申請に関するデー
タをサーバ上で一元管理し、承認者がクライアントから
サーバにアクセスして承認処理を行うシステムに関す
る。

【０００２】

【従来の技術】従来、申請書の承認業務（ワークフロ
ー）を実現する手段として、申請データを承認者宛に直
接送付する方法が多くある。

【０００３】

【発明が解決しようとする課題】しかしながら、これら
従来の方法においては、承認者の作業場所が固定される
うえ、処理状態を確認することができなかった。

【０００４】本発明の課題は、承認者の作業場所を柔軟
に変更すること、および申請書類の承認状況管理を可能
とする申請承認システムを提供することである。

【０００５】また、申請データ以外に画面情報もデータ
ベースで管理することで、利用クライアントを変更した
場合も常に同じ環境でシステムを利用することができる
ようにすることである。

【０００６】

【課題を解決するための手段】そこで、本発明は、ネッ
トワークを介して複数のクライアントからアクセスされ
るサーバであって、いずれかの前記クライアントから申
請者によって入力され、承認依頼された申請書データを
所定のデータベースに格納する手段と、前記承認依頼さ
れた申請書データを、前記データベースに格納された所
定の承認ルートにしたがって、必要な承認者間に回覧す
る回覧手段と、前記承認依頼されたそれぞれの申請書デ
ータに関する承認履歴を前記データベースに格納し、前
記格納した承認履歴を管理する承認履歴管理手段とを備
え、前記回覧手段は、いずれかの前記クライアントを用
いたいずれかの前記承認者からのアクセスに応答して、
前記データベースに格納された申請書データを参照さ
せ、必要な承認処理を促し、前記承認履歴管理手段は、
前記承認者によって必要な承認処理がなされた場合に
は、当該承認処理がなされた申請書データに関する承認
履歴を更新する申請承認サーバ、およびこのサーバを含
む申請承認システムを特徴とする。

【０００７】また、前記データベースには、それぞれの
申請者および承認者が使用する画面パターンを指定する
画面指定情報と、前記それぞれの申請者および承認者が
使用する複数種の画面パターンデータとが格納されてお
り、前記申請承認サーバは、前記クライアントを用いた
前記申請者または前記承認者からのアクセスに応じて、
当該申請者または承認者の識別情報の入力を要求し、入
力された識別情報に基づいて前記データベースから当該
申請者または承認者が使用する画面パターンを特定し、
特定された画面パターンを前記申請者または承認者のク
ライアントに表示させる画面選択手段をさらに備えるよ
うにした。

【０００８】また、前記回覧手段は、前記クライアント
を用いた前記承認者からのアクセスに応じて、当該承認
者の識別情報の入力を要求し、入力された識別情報に基
づいて前記データベースから当該承認者が承認すべき申
請書データを抽出し、抽出した申請書データの一覧を前
記承認者のクライアントに表示させるようにした。

【０００９】さらに、前記データベースに格納された所
定の承認ルートは、階層構造で定義されており、前記階
層構造の第１層は、前記承認ルートの基本的な承認ステ
ップが定義されており、前記階層構造の第２層は、前記
それぞれの承認ステップを構成する承認者と承認者が指
定される単位を表す属性とが定義されており、前記階層
構造の第２層は、さらに、１つの承認ステップにおいて
複数の承認者が定義されている場合には、当該１つの承
認ステップにおける前記複数の承認者間の承認順序が定
義されるようにした。

【００１０】また、前記階層構造の第２層には、複数の
承認者を含む承認者グループ単位で所定の承認者グルー
プが承認者として指定され、前記承認履歴管理手段は、
前記指定された所定の承認者グループに含まれるいずれ
かの承認者によって必要な承認処理がなされた場合に
は、当該承認処理がなされた申請書データに関する承認
履歴を更新するようにした。

【００１１】そして、前記データベースには、それぞれ
の申請書データについて、承認の順番がいずれの承認者
にあるかを示す順番フラグが設定されており、前記承認
履歴管理手段は、順番フラグが立てられた承認者によっ
て必要な承認処理がなされた場合には、当該承認者の順
番フラグをクリアし、次の順位の承認者の順番フラグを
立てるようにした。

【００１２】また、上記サーバの発明は、システムの発
明としても成立する。また、上記発明は、コンピュータ
に所定の機能を実現させるプログラムまたはそのプログ
ラムを記録した記録媒体としても成立する。

【００１３】また、本明細書における手段は、ハードウ
ェア、ソフトウェアまたはハードウェアおよびソフトウ
ェアの組み合わせにより実現可能である。ハードウェア
およびソフトウェアの組み合わせによる実行は、例え
ば、所定のプログラムを有するコンピュータ・システム
における実行が該当する。

【００１４】そして、１つの手段が有する機能が２つ以
上のハードウェア、ソフトウェアまたはハードウェアお
よびソフトウェアの組み合わせにより実現されても、２
つ以上の手段の機能が１つのハードウェア、ソフトウェ
アまたはハードウェアおよびソフトウェアの組み合わせ
により実現されても良い。

【００１５】

【発明の実施の形態】以下、本発明の実施の形態につい
て図面を参照して説明する。図１は、本発明の実施の形
態に係る申請承認システムの構成を示すブロック図であ
る。

【００１６】（実施の形態の概要）まず、図１を参照し
て本実施の形態の概要について説明する。本発明では、
図１に示すように、ワークフロー（申請承認処理の流
れ）システムの実現において必要となるデータ（社員の
情報、組織の情報、申請書の内容など）を全てデータベ
ース３００に保存し、データベースの内容をクライアン
トから参照・状態の変更を行うことで、あたかも申請デ
ータを回覧している様に見せる仕組みを実現する。ま
た、クライアントでの表示をあらかじめ指定した形式で
表示する仕組みにより、利用者の特性（申請業務のみを
行う者、承認業務のみを行う者など）に応じた画面構成
を切り替えて利用することができる仕組みを実現する。
なお、上記機能をＷｅｂサーバ２００内のデータベース
アクセスモジュール２１０により行う。

【００１７】（実施の形態の構成）次に、図面を参照し
て本実施の形態の構成を説明する。図１に示すように、
本実施の形態に係る申請承認システムは、Ｗｅｂサーバ
２００と、利用者が使用するクライアント１００，１０
１，１０２と、データベース３００とから構成される。
なお、以下においてはクライアントの代表としてクライ
アント１００を用いて説明する。

【００１８】Ｗｅｂサーバ２００は、サーバ装置等の情
報処理装置によって実現される。Ｗｅｂサーバ２００
は、データベースアクセスモジュール２１０を備え、こ
のモジュールは、例えばＷｅｂサーバ２００上でソフト
ウェアを実行することにより実現される。

【００１９】データベースアクセスモジュール２１０
は、データベース３００に格納された情報を管理し、ク
ライアント１００との間で通信を行い、申請承認処理を
支援する。

【００２０】データベース３００は、記憶装置によって
実現され、社員情報，組織情報，書類設計情報，フロー
情報，画面表示形式情報等が格納される。

【００２１】クライアント１００は、パーソナルコンピ
ュータ，ＰＤＡ，携帯電話等の情報処理装置によって実
現される。クライアント１００は、ＬＡＮ，インターネ
ット等のネットワークを介してＷｅｂサーバ２００へア
クセスし、データベースアクセスモジュール２１０との
間で通信を行う。

【００２２】次に、図２を参照して利用者に応じた画面
出力の制御を説明する。図２は、利用者に応じた画面出
力の制御を説明する図である。

【００２３】利用者の使用する画面情報は、画面パター
ンごとに画面パターン情報２０としてデータベースに保
存する。また、社員個人の設定を保存している社員情報
１０には、その個人が使用する画面が指定されている。

【００２４】個人がシステムを利用する場合は利用者の
社員情報１０から利用画面を特定して、その画面構成を
画面パターン情報２０から読み込むことで、利用者画面
を表示させる。

【００２５】具体的には、図２は、画面パターンの例と
してメニューパターンについて説明している。画面パタ
ーン情報２０には、現場メニュー，課長クラスメニュー
等の種々の画面パターンが登録されており、それぞれの
画面パターンについては、出力メニュー，背景色，初期
画面，書類表示を選択等が設定されている（図２の
ｂ）。

【００２６】一方、社員情報１０には、社員の識別情報
と、個々の社員が使用する画面パターンの指定情報とが
関連付けて登録されている（図２のａ）。

【００２７】例えば、Ａ現場担当者がシステムを利用す
る場合は、Ａ現場担当者が入力したＩＤ等の識別情報に
基づいて、データベースアクセスモジュール２１０が社
員情報１０を参照してＡ現場担当者用に指定された画面
パターンを特定する。図２では、現場メニューが特定さ
れることとなる。次に、データベースアクセスモジュー
ル２１０は、特定された現場メニューを画面パターン情
報２０から読み出してＡ現場担当者のクライアントに送
信して表示させる。

【００２８】一方、例えば、利用者である申請者が使用
する申請書類が複数種存在する場合には、各書類を一定
のカテゴリで分類して管理し、各申請書類のインデック
スをクライアント画面に表示させて使用する書類を選択
させるようにしてもよい（図２のｃ，ｄ，ｆ）。この場
合には、データベースアクセスモジュール２１０は、選
択された申請書類の画面をクライアントに表示させる。

【００２９】なお、初期画面においては、申請書類を、
承認依頼一覧，申請中書類一覧，本日決済書類一覧等に
分類して一覧表示する構成としてもよい（図２のｅ）。
この場合には、データベースアクセスモジュール２１０
は、上記一覧内から選択された申請書類の画面をクライ
アントに表示させる。なお、この初期画面を生成する手
順については後述する。

【００３０】次に、図３を参照して承認処理フローの流
れの制御について説明する。図３は、承認データの流れ
を制御するフロー制御の構成を示す図である。承認フロ
ーの流れは、承認ステップ情報４０、フロー情報５０、
グループ情報６０によって階層的に管理される。

【００３１】フロー情報５０では承認順が指定されてい
る。そのフロー情報を組み合わせて一つの処理フローを
定義しているものが承認ステップ情報４０である。

【００３２】フロー情報５０には承認者の指定以外に複
数の承認者をまとめた承認者グループを定義できる。そ
のグループに属す承認者の情報を管理している物が承認
グループ情報６０である。承認処理は図３によって表さ
れるフロー情報に従って承認者間を回覧される。

【００３３】具体的には、図３は、経費関係の申請書類
の承認処理ルートの定義例を説明している。承認ステッ
プ情報４０には、承認ルートに含まれる複数の基本的な
承認ステップが定義されている（図３のａ）。そして、
個々の承認ステップにおいては、対象となる承認フロー
が指定されている。また、個々の承認ステップにおいて
は、複数の承認フローを指定し、いずれかの承認フロー
を選択するための分岐条件を設定することもできる。

【００３４】次に、フロー情報５０には、承認ステップ
情報４０で指定される個々の承認フローの具体的な内容
が定義されている（図３のｂ）。具体的には、承認フロ
ーにおける承認順，承認方法，承認者指定方法，承認
者，承認種類等が定義される。承認方法には、例えば順
次承認かまたは一斉承認かが設定される。順次承認の場
合には、承認順には個々の承認者の承認順序が設定され
る。一方、一斉承認の場合には、承認順には個々の承認
者のパラレルな承認が設定される。

【００３５】承認者指定方法には、承認者が指定される
単位を示す承認者の属性が設定される。属性は、例え
ば、個人，職位，固定組織長，承認担当グループ等であ
る。そして、承認者には、具体的な承認者が識別情報
（職位名，氏名，承認担当グループ名，ＩＤ等）によっ
て指定される。また、承認種類には、決済・確認等の承
認の種類が設定される。

【００３６】次に、グループ情報６０には、フロー情報
５０で承認者として指定される個々の承認担当グループ
の具体的な内容が定義されている（図３のｃ）。具体的
には、各グループにおける承認者指定方法，承認者等が
定義される。なお、承認担当グループが指定された場合
には、当該指定されたグループに属する承認者のいずれ
かが承認処理を行えば、その承認ステップが完了するよ
うにしてもよい。

【００３７】以上のようにして階層的に定義された処理
フローは、具体的には図３のｄのような承認ルートとな
る。データベースアクセスモジュール２１０は、このよ
うにして設定された承認ルートに沿って、申請書を回覧
する。

【００３８】このような構成とすることにより、承認ル
ートを階層的に管理することが可能となる。また、承認
ルートの変更を容易に行うことができる。

【００３９】（実施の形態の動作）次に、実施の形態の
動作を説明する。図１において、申請承認業務を行う者
はクライアント１００〜１０２を利用する。利用者の画
面は、クライアントの利用開始時に入力した利用者識別
番号により、該当する画面情報をデータベース３００よ
り取り出し表示する。そのため、利用者の画面構成を複
数作成しておき、利用者の業務内容に応じて、利用する
画面を指定することで必要な画面を表示させる。業務内
容が変更になった場合は、利用画面の指定情報を変更す
ることで画面構成を変更することができる。

【００４０】業務を行う場合はクライアント１００〜１
０２で行い、入力された申請情報はデータベース３００
に蓄積される。入力されたデータを次の承認者に送る場
合は、データベース３００に蓄積されている承認順デー
タの内容を変更することで、該当者が画面を表示した場
合、そのデータが表示される。

【００４１】次に、データベースアクセスモジュール２
１０（以下、モジュール２１０）の機能を中心として、
本実施の形態の動作を説明する。ここで、図４は、本発
明の実施の形態に係る申請承認システムの動作を説明す
るフローチャートであり、図５は、申請書ファイルの構
成例を説明する図であり、図６は、承認者情報の構成例
を説明する図である。

【００４２】まず、利用者（ここでは申請者）は、クラ
イアント１００を利用して申請書を入力する（ステップ
５０１）。具体的には、申請者がクライアント１００か
らＷｅｂサーバ２００にアクセスすると、モジュール２
１０が申請者の識別情報を要求する。申請者が自身の識
別情報を入力すると、モジュール２１０は、社員情報１
０を参照して申請者の画面パターンを特定し、特定した
画面パターンを画面パターン情報２０から取り出してク
ライアント１００に表示させる。ここでは、画面パター
ンとして申請書の作成画面が表示されることとする。申
請者は画面上で必要な申請情報を入力する。

【００４３】なお、特定した画面パターンの初期画面に
複数の申請書が設定されている場合には、図２のｆに示
すように複数の申請書のインデックスが表示される。申
請者が所望のインデックスを選択すると、モジュール２
１０は、選択された申請書の画面をクライアント１００
に送信して表示させる。

【００４４】次に、申請者は、必要に応じて承認ルート
を変更し、承認ルートを決定する（ステップ５０２）。
具体的には、図３のａに示されるように、承認ルートが
申請時に変更可能なものであれば、申請時に承認ステッ
プの変更，承認者の追加変更等を行う。一方、承認ルー
トが申請時に変更不可能なものであれば、予め設定され
た承認ステップでの固定承認ルートのままとなる。

【００４５】承認ルートは、また、承認時に変更される
構成としてもよい。具体的には、図３のａに示されるよ
うに、承認ルートが承認時に変更可能なものであれば、
承認時に承認ステップの変更，承認者の追加変更等を行
う。一方、承認ルートが承認時に変更不可能なものであ
れば、申請段階で決定されたルートでの固定承認ルート
のままとなる。以上のような承認ルートの変更は、モジ
ュール２１０が提供する承認ルート変更手段を介して行
われる。

【００４６】申請情報が入力され、承認ルートが決定さ
れると、モジュール２１０は、申請書情報と承認者情報
とをデータベース３００に登録する（ステップ５０
３）。具体的には、図５に示されるように、各申請書に
一意の申請書ＩＤを割り当て、申請書ＩＤをキーとして
申請書情報と承認者情報とを登録する。

【００４７】申請書情報は、申請書を入力した申請者の
氏名および識別情報（例えばＩＤ），申請書の内容，申
請書名，発行日付等を含む。また、申請書情報は、上述
したような、決定後の承認ルートデータを含むようにし
てもよい。

【００４８】承認者情報とは、各申請書を承認すべき承
認者に関する情報であり、例えば図６に示されるよう
に、各申請書について、承認者識別情報（例えばＩ
Ｄ），承認者名，各承認者の承認順，承認日，状態フラ
グ，順番フラグ等を含む。状態フラグは、承認がなされ
たか否かを示し、承認済みの場合には「１」、未承認の
場合には「０」がセットされる。順番フラグは、承認の
順番がどの承認者にあるのかを示し、現在承認すべき承
認者に「１」がセットされ、承認を行うことにより０ク
リアされて次の承認者のフラグが「１」にセットされ
る。なお、承認者情報には、図示しない否決フラグを設
けてもよい。この場合には、いずれかの承認者が否決を
入力するとその承認者の否決フラグが「１」にセットさ
れる。

【００４９】このような承認者情報は、モジュール２１
０が、上記決定された承認ルートに基づいて生成するよ
うにしてもよい。この場合には、モジュール２１０は、
承認ルートからそれぞれの承認者と各承認者の承認順と
を抽出して承認者情報を生成する。

【００５０】次に、利用者（ここでは承認者）がＷｅｂ
サーバ２００にアクセスすると（ステップ５０４）、当
該承認者が承認すべき申請書が当該承認者のクライアン
トに表示される（ステップ５０５）。具体的には、承認
者がクライアント１００からＷｅｂサーバ２００にアク
セスすると、モジュール２１０が承認者の識別情報を要
求する。承認者が自身の識別情報を入力すると、モジュ
ール２１０は、社員情報１０を参照して承認者の画面パ
ターンを特定し、特定した画面パターンを画面パターン
情報２０から取り出してクライアント１００に表示させ
る。ここでは、申請書の承認画面が表示されることとす
る。

【００５１】また、承認画面の初期画面には、例えば図
２のｅの承認依頼一覧のように、当該承認者が承認すべ
き申請書の一覧を表示させるようにしてもよい。具体的
には、モジュール２１０は、入力された承認者の識別情
報（承認者ＩＤ）に基づいて承認者情報を検索し、当該
承認者の順番フラグが「１」になっている申請書を抽出
して一覧表示する。

【００５２】また、当該利用者が申請した申請書があれ
ば、その申請書の現在の状況を表示してもよい。具体的
には、図２のｅに示されるように、申請中書類一覧とし
て申請書が現在どの承認者のところにあるのか各申請書
ごとに一覧表示してもよい。この場合には、モジュール
２１０は、利用者の識別情報を用いて申請書ファイルを
検索し、当該利用者が承認依頼した申請書を特定し、こ
の申請書の承認者情報から承認順番がある（順番フラグ
が「１」である）承認者を特定して表示する。

【００５３】次に、承認者が承認処理をおこなうと（ス
テップ５０６）、データベース３００の承認者情報が更
新される（ステップ５０７）。具体的には、承認者がク
ライアントの画面上で承認を入力すると、モジュール２
１０は、承認された申請書の承認者情報に対して、当該
承認者の状態フラグを「１」にセットし、承認日に現在
の日時をセットし、順番フラグを０にクリアし、次の順
位の承認者の順番フラグを「１」にセットする。

【００５４】このような承認者情報が申請書情報ととも
に保存されるので、承認途中の段階であれば、どこで承
認が止まっているのか等を参照することができる。ま
た、承認後であれば、誰がいつ承認したのかということ
を参照することができる。

【００５５】以上、好適な実施の形態を用いて本発明を
説明してきたが、本発明は上記の実施の形態に限定され
るものではない。当業者は、ここに開示された実施の形
態に基づいて、本発明の範囲から外れることなしに適宜
変更または改良を行うことが可能である。また、このよ
うな変更あるいは改良も本発明に含まれる。

【００５６】

【発明の効果】以上説明したように、本発明によれば、
全てのデータがデータベースで管理されており、利用者
画面、データの表示はデータベースのデータを基に作成
されるため、利用場所の制限を受けることなく、どのク
ライアントからでも同様の作業を行うことができる。

【図面の簡単な説明】

【図１】本発明の実施の形態に係る申請承認システムの
構成を示すブロック図である。

【図２】利用者に応じた画面出力の制御を説明する図で
ある。

【図３】承認データの流れを制御するフロー制御の構成
を示す図である。

【図４】本発明の実施の形態に係る申請承認システムの
動作を説明するフローチャートである。

【図５】申請書ファイルの構成例を説明する図である。

【図６】承認者情報の構成例を説明する図である。

【符号の説明】

１０ 社員情報 ２０ 画面パターン情報 ４０ 承認ステップ情報 ５０ フロー情報 ６０ グループ情報 １００，１０１，１０２ クライアント ２００ Ｗｅｂサーバ ２１０ データベースアクセスモジュール ３００ データベース

Claims (6)

【特許請求の範囲】
1. 【請求項１】ネットワークを介して複数のクライアント
   からアクセスされるサーバであって、 いずれかの前記クライアントから申請者によって入力さ
   れ、承認依頼された申請書データを所定のデータベース
   に格納する手段と、 前記承認依頼された申請書データを、前記データベース
   に格納された所定の承認ルートにしたがって、必要な承
   認者間に回覧する回覧手段と、 前記承認依頼されたそれぞれの申請書データに関する承
   認履歴を前記データベースに格納し、前記格納した承認
   履歴を管理する承認履歴管理手段とを備え、 前記回覧手段は、いずれかの前記クライアントを用いた
   いずれかの前記承認者からのアクセスに応答して、前記
   データベースに格納された申請書データを参照させ、必
   要な承認処理を促し、 前記承認履歴管理手段は、前記承認者によって必要な承
   認処理がなされた場合には、当該承認処理がなされた申
   請書データに関する承認履歴を更新する申請承認サー
   バ。
2. 【請求項２】前記データベースには、それぞれの申請者
   および承認者が使用する画面パターンを指定する画面指
   定情報と、前記それぞれの申請者および承認者が使用す
   る複数種の画面パターンデータとが格納されており、 前記申請承認サーバは、 前記クライアントを用いた前記申請者または前記承認者
   からのアクセスに応じて、当該申請者または承認者の識
   別情報の入力を要求し、入力された識別情報に基づいて
   前記データベースから当該申請者または承認者が使用す
   る画面パターンを特定し、特定された画面パターンを前
   記申請者または承認者のクライアントに表示させる画面
   選択手段をさらに備える請求項１に記載の申請承認サー
   バ。
3. 【請求項３】前記回覧手段は、前記クライアントを用い
   た前記承認者からのアクセスに応じて、当該承認者の識
   別情報の入力を要求し、入力された識別情報に基づいて
   前記データベースから当該承認者が承認すべき申請書デ
   ータを抽出し、抽出した申請書データの一覧を前記承認
   者のクライアントに表示させる請求項１または２に記載
   の申請承認サーバ。
4. 【請求項４】前記データベースに格納された所定の承認
   ルートは、階層構造で定義されており、 前記階層構造の第１層は、前記承認ルートの基本的な承
   認ステップが定義されており、 前記階層構造の第２層は、前記それぞれの承認ステップ
   を構成する承認者と承認者が指定される単位を表す属性
   とが定義されており、 前記階層構造の第２層は、さらに、１つの承認ステップ
   において複数の承認者が定義されている場合には、当該
   １つの承認ステップにおける前記複数の承認者間の承認
   順序が定義される請求項１〜３のいずれかに記載の申請
   承認サーバ。
5. 【請求項５】前記階層構造の第２層には、複数の承認者
   を含む承認者グループ単位で所定の承認者グループが承
   認者として指定され、 前記承認履歴管理手段は、前記指定された所定の承認者
   グループに含まれるいずれかの承認者によって必要な承
   認処理がなされた場合には、当該承認処理がなされた申
   請書データに関する承認履歴を更新する請求項４に記載
   の申請承認サーバ。
6. 【請求項６】前記データベースには、それぞれの申請書
   データについて、承認の順番がいずれの承認者にあるか
   を示す順番フラグが設定されており、 前記承認履歴管理手段は、順番フラグが立てられた承認
   者によって必要な承認処理がなされた場合には、当該承
   認者の順番フラグをクリアし、次の順位の承認者の順番
   フラグを立てる請求項１〜５のいずれかに記載の申請承
   認サーバ。