(57)【要約】【課題】  システム更改に対し、柔軟な稟議システムを提供することを目的とする。【解決手段】  組織の階層構造を記述した組織情報を記憶する手段と、書類の項目に入力することが出来る値を定義した型を記憶する手段と、書類の項目と型との対応関係を定義した様式を記憶する手段とを備え、前記型と様式に基づいて、チェックプログラムおよび補完プログラムを生成する手段と、前記型と様式に基づいて、利用者に前記チェックプログラムおよび補完プログラムを含む入力画面を提供する手段を備える。  前記入力画面に入力された情報から稟議書類を生成し、稟議書類を記憶する手段を備える。  前記様式は、さらに、様式に基づいて作成される稟議書類の承認経路の定義と、権限の定義を含み、前記組織情報と前記様式から前記稟議書類の承認経路を決定する手段と、前記組織情報と、前記様式の権限の定義と、承認経路の経過状況から、書類の公開や変更などの権限を制御する手段を備える。【選択図】図１０
2015167006.tif 000002
【特許請求の範囲】
【請求項１】
書類を保存するサーバと、権限変更部と、複数のユーザ端末とからなる文書共有システムにおいて、
前記書類は、書類に対する権限の情報を含み、
前記ユーザ端末は、前記書類を保存するサーバから書類を取得するとともに、前記書類に対する権限を変更するための権限変更画面を表示し、ユーザの指示に応じて、前記ユーザを識別するための識別子と前記書類に対する権限の変更指示を前記権限変更部へ送信し、
前記権限変更部は、前記識別子に基づいて、前記ユーザが書類に対する権限を変更する権限を有するか否かを判断し、権限を有すると判断した場合に、前記書類の書類に対する権限の情報を変更して、前記書類を保存するサーバに保存させることを特徴とする文書共有システム。
【請求項２】
請求項１に記載された文書共有システムにおいて、
前記書類は、書類を承認する承認者の順序を定義した承認経路の情報と、書類を承認済みの承認者の情報を含む実施者要素とを含み、
前記権限変更部は、前記承認経路の情報と実施者要素とに基づいて、前記ユーザが次に承認を行うべき承認者であることを確認することで、前記ユーザが書類に対する権限を変更する権限を有すると判断することを特徴とする文書共有システム。
【請求項３】
請求項１、２に記載された文書共有システムにおいて、
前記書類は、書類の作成者の情報と、書類の作成が完了したことを示す情報とを含み、
前記権限変更部は、前記書類の作成者の情報と、書類の作成が完了したことを示す情報とに基づいて、前記ユーザが前記書類の作成者と同じユーザであり、さらに、前記書類の作成が完了していないことを確認することで、前記ユーザが書類に対する権限を変更する権限を有すると判断することを特徴とする文書共有システム。
【請求項４】
請求項１乃至３に記載された文書共有システムにおいて、
前記書類は、書類を承認する承認者の順序を定義した承認経路の情報と、書類を承認済みの承認者の情報を含む実施者要素と、書類の作成者の情報を含み、
前記権限変更部は、前記承認経路の情報、及び、実施者要素に基づいて、前記ユーザが作成者又は承認者であって、前記書類の承認がすべて終了していることを確認することで、前記ユーザが書類に対する権限を変更する権限を有すると判断することを特徴とする文書共有システム。
【請求項５】
請求項１乃至４に記載された文書共有システムにおいて、
前記書類に対する権限の情報は、承認時に実行可能な操作を記述する承認権限の定義、書類の所有者の権限を記述する所有時の権限定義、書類の所有者が他のユーザに付与できる権限を記述する所有時の変更権限定義、及び、最終決裁後の書類の権限を記述する最終決裁後の権限定義のいずれか一つ以上のものを含むことを特徴とする文書共有システム。
【請求項６】
請求項１乃至５に記載された文書共有システムにおいて、
前記書類に対する権限の情報は、最終決裁後に所有者が他のユーザに付与できる権限を記述する最終決裁後の変更権限定義を含むことを特徴とする文書共有システム。
【請求項７】
書類を保存するサーバと、権限変更部と、複数のユーザ端末とからなる文書共有システムにおいて用いられる文書共有方法であって、
前記書類は、書類に対する権限の情報を含み、
前記ユーザ端末が、前記書類を保存するサーバから書類を取得するとともに、前記書類に対する権限を変更するための権限変更画面を表示し、ユーザの指示に応じて、前記ユーザを識別するための識別子と前記書類に対する権限の変更指示を前記権限変更部へ送信するステップと、
前記権限変更部が、前記識別子に基づいて、前記ユーザが書類に対する権限を変更する権限を有するか否かを判断し、権限を有すると判断した場合に、前記書類の書類に対する権限の情報を変更して、前記書類を保存するサーバに保存させるステップとを有することを特徴とする文書共有方法。
【請求項８】
コンピュータを、書類を保存するサーバと、権限変更部と、複数のユーザ端末とからなる文書共有システムとして動作させるためのコンピュータプログラムであって、
前記書類は、書類に対する権限の情報を含み、
前記ユーザ端末が、前記書類を保存するサーバから書類を取得するとともに、前記書類に対する権限を変更するための権限変更画面を表示し、ユーザの指示に応じて、前記ユーザを識別するための識別子と前記書類に対する権限の変更指示を前記権限変更部へ送信するステップと、
前記権限変更部が、前記識別子に基づいて、前記ユーザが書類に対する権限を変更する権限を有するか否かを判断し、権限を有すると判断した場合に、前記書類の書類に対する権限の情報を変更して、前記書類を保存するサーバに保存させるステップとを有することを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】  この発明は稟議システムに関わる。
【背景技術】
【０００２】  近年、社内や組織でやり取りされる書類の電子化が進んでおり、書類の承認・決裁についても電子で行う事が少なくない。【０００３】  書類を電子化し電子的に承認・決裁するにあたり、書類がどのような様式に従うべきか、書類の様式毎にどのような経路で承認・決裁を行うべきかを事前に定めておく事が必要となる。【０００４】  また、作成された書類は、必要なユーザには参照を許すと同時に、情報漏えいや不正アクセスを防ぐため公開範囲を適切に制限することが必要である。【０００５】  従来の技術では、書類の様式を定義するために、書類の電子化のためのミドルウェアを導入し、システムの管理者等がミドルウェアに付属するグラフィカルな専用デザインツールによってデータベースの定義及び入力画面のデザインを行っていた。【０００６】  一方、承認・決裁の経路を定義するためには、ＢＰＥＬなどのビジネスプロセス記述言語により、グラフィカルに経路を記述していく方法がとられていた。この経路の記述は、システムの管理者が書類の様式毎に記述するか、一般利用者が書類を作成する際に選択するといった方法を採ることが一般的であった。【０００７】また、作成した書類に対してアクセス制御をおこなうためには、ＡＣＬ（アクセス制御リスト）やファイルのケイパビリティ等を設定することで、ディレクトリ単位やファイル単位に、個々に設定する方法を採ることが一般的であった。
【先行技術文献】
【０００８】
【特許文献１】特開２００４−２４６５１６号公報
【特許文献２】特開２００７−０７２６９２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】  上記したように、書類の様式の定義は、グラフィカルな専用ツールを利用して個別に作成して実現することが従来行われていた。【００１０】  グラフィカルな専用ツールを利用する従来の方法は、試行しながら小量の様式を作成する場合には、利用者のスキルレベルが低くても使いやすいなどのメリットがある。しかしながら、大量の様式を定義しなければならない場合や、大量の様式に対して修正が発生した場合は、既存の様式を再利用しながら修正することが困難であり、該当する全ての様式を利用者が個別に修正しなければならないなど、利用者に困難かつ多大な作業を強いるものであった。【００１１】  また、会社独自の番号体系のチェック処理を画面に埋め込む必要がある場合は、従来の専用ツールでは想定されていないため、このような画面は作成不可能であるか可能な場合でも定義が難しいことが課題であった。このため、利用者が実用的に使用するためのカスタマイズと称される大規模な改修を行い多大なコストを払って運用することが通例行われてきた。このような改造を行った場合、番号体系やチェックの仕様に変更が発生した場合に、カスタマイズ部分においてこのような変更を考慮していない場合には、十分な対応が行えないか、若しくはさらに多大なコストと時間を費やして対応することなるため、結果的に運用コストが一層増大するか、場合によっては番号体系やチェックの仕様の変更を阻害する要因ともなってきた。【００１２】  次に、承認経路をＢＰＥＬ等の言語を使って記述して行く方法では、飛び決や、代行決裁などの例外的な経路も含め取り得る経路を様式ごとに全て記述しておかなければ動作させることができず、したがって、あらかじめ例外的な経路を全て記述するための膨大な作業を強いられるため、システム構築のコストが高くなる。そして、組織構造や構成員に変更が発生した場合には、定義された承認経路の見直しを様式毎に行う必要がある。さらに、組織構造の一部を改変する場合でも、例外的な経路を記述する必要があるため、承認経路全体に亘って見直しが発生するうえ、改変後の確認作業も、承認経路全体に渡って行う必要があるため、確認作業が膨大となることが課題であった。【００１３】  なお、ここでいう、飛び決とは、予め定められた承認者が不在などの理由で承認できない場合、その上位の承認者が承認を行うことを指す。また、代行承認とは、承認者が不在などの理由で承認できない場合、同一組織内のユーザが代わりに承認を行うことを指す。【００１４】  次に、書類のアクセス制御を、ＡＣＬやケイパビリティを用いて設定する方法では、きめ細かいアクセス制御を行える反面、個々の書類やユーザに対してきめ細かく設定を行う必要があるため、適切に設定するためには多大な労力を必要とする。その結果として必要な制限が行われないか、逆に厳しく制限をしすぎて、情報の共有を阻害してしまうという課題があった。また、組織の構造や構成員に変更が生じた場合、ファイルのアクセス制御やケイパビリティの設定についても設定変更を必要とするが、これらの変更についても多大な労力を必要とするため、組織の変更に柔軟に対応できず、セキュリティのための役割を果たさなくなることが課題であった。【００１５】  ���のことは、承認経路の課題と合わせて、組織自体の改変を阻害する要因ともなってきた。【００１６】  特に、システムが大規模になった場合、小さな仕様変更であってもそれによって影響を受ける範囲が大きく、システム改修のコストが指数関数的に増大する事が課題であった。【００１７】  本発明は、このような書類の様式、承認経路の作成と変更、及び、アクセス制御の設定と変更の作業を少なくにすることで、システムの開発、及び、修正を容易にする事を目的とする。
【課題を解決するための手段】
【００１８】  上記課題を解決するために、本発明では、様式の定義をするための専用言語を用意する。専用言語は、様式を定義するために必要最低限なことだけを記述すればよく、記述量を少なくすることが出来る。また、実際の様式の構成に近い形式で記述することが出来るような文法に設計することで、実際の様式から直感的に記述することが出来る。そのため、汎用的な言語に比べて習得が容易で、様式の記述も容易に行うことができる。専用言語を用いた方法は、グラフィカルな専用ツールを用いて様式を記述する方法に比べ、過去に作成したものを参考に一部分だけ修正して大量の様式を作成したり、作成した大量の様式に対して、同様な修正を一度に反映したりといったことが効率的に行える。さらに、この専用言語は利用者自身が定義を記述するために直接利用するだけでなく、中間言語としても利用できる。例えば、グラフィカルな専用ツールを製造する際にこの専用言語を中間言語として用いることで開発コストを低く抑えることができる。スキルレベルが低いユーザが作成する場合や、少量を試行しながら作成する場合はグラフィカルな専用ツールを用い、大量の様式を定義する場合や保守を行う場合には、専用言語を用いることで、双方のメリットを享受することができる。【００１９】  一般的に書類のテンプレートを定義する際には、書類が含む項目とその項目に入力することができる値の制限を型として定義することが多い。本発明にいても様式は、文書を構成する項目と型との対応関係の記述を含む文書構造の定義と、型の定義とを含み、さらに、承認経路の定義と、権限の定義とを含むものとする（承認経路の定義、権限の定義については後述する。）。ここでいう型とは、その項目に入力することができる値の集合に名前を付けたものと言うことができる。例えば、その項目に整数のみ入力できるであれば項目の型は整数型となり、テキストのみ入力できるのであれば項目の型はテキスト型などとなる。テキスト型や整数型のような、集合の要素数が文字の組み合わせにより膨大となってしまう場合は、その項目に入力することができる値の集合を正規表現で記述することができる。値の集合の要素数が少なければ、正規表現を用いて記述してもよいし、すべての要素を列挙することも可能である。このように、型の定義は、正規表現で記述するか、すべての要素を列挙する方法で定義できる。様式に基づいて書類を作成する際に、入力した項目に誤りがないかエラーチェックを行う場合については、項目のエラーチェックとは、入力された値とこれらの集合値とを突き合わせて、入力した値が集合に含まれるか否かを確認するものであるといえる。このような考えに基づけば、入力した値と集合値とを比較するプログラムを作成すれば、集合値である型の定義に基づいてバリデーションを行うエラーチェックプログラムを自動生成することが可能となる。【００２０】  さらに、項目に入力しうるすべての値を列挙することによって型を定義した場合は、列挙した値は入力値の候補であるといえるので、入力値によって絞り込まれた列挙値を返却するプログラムを作成知れば、入力値の補完プログラムも自動生成することが可能である。【００２１】  このように、本発明では型を正規表現、列���、及び、それらの組み合わせで定義することで、エラーチェックプログラムを自動生成し、型を列挙にて定義した場合は、入力値の補完プログラムを自動生成し、エラーチェックと入力値の補完を含む入力画面を提供することが可能である。【００２２】  入力項目のチェック内容として多くあるのは、入力が必須であるか否かのチェックである。このような場合に対応するために、本発明では型を列挙にて定義する場合に、空集合を意味する記号（例えば「ＮＵＬＬ」のような記号。）を列挙値として利用する方法を提供する。【００２３】  入力値のチェックは正規表現に従って行いつつ、入力の補完値だけを列挙したい場合がある。このような場合に対応するために、本発明では型を列挙にて定義する場合に、列挙値の一つとして正規表現で定義した型を利用する方法を提供する。別の方法として、本発明では型を列挙にて定義する場合に、「任意」を意味する記号を列挙値として利用する方法を提供する。【００２４】  入力項目のエラーチェックや入力値の補完は単項目ではなく複数項目の組み合わせで判断する場合も多い。例えば、車種を選択する入力フォームにおいて、メーカーと車種の入力ボックスがある場合などである。このような場合に対応するために、本発明では型を列挙して定義する場合に、複数項目の値からなるタプルを列挙する方法を提供する。【００２５】  型として列挙値を使用する際には、都道府県のリストや、製品番号など、件数が多く様式にすべて記述することで様式が肥大化するのを避けたい場合や、社内のデータベースに保持する値を直接利用したいといった場合がありうる。このような場合に対応するために、列挙値として外部データベースへの参照を記述する方法や、システム内のデータベースにＣＳＶ等でいったん取り込み、システム内のデータベースへの参照を記述する方法を用いて間接的に入力しうる値を指定する方法を提供する。【００２６】  以上の方法で型を定義することにより、必須チェックや複数項目の組み合わせで判断するチェックを含むエラーチェック、複数項目の組み合わせで判断する入力値の補完、外部データベースを使ったエラーチェック、及び、外部データベースを使った入力値の補完を行うことが可能となる。【００２７】  型は入力できる値の集合といえるので、ある定義済みの型の部分集合を定義することで、当該型に基づいてさらに別の型を定義することや、型と型を組み合わせた別の型を定義することも可能である。【００２８】  型は様式ごとに定義するだけでなく、様式にまたがって共通して利用できるように事前に定義することもできる。例えば、数値やテキストのような基本的な型の他に、一般的な入力フォームで用いられる電話番号や住所といった型を定義しておくことができる。このような型にさらに制限を加えたり組み合わせたりすることで、利用者独自の型も定義可能である。【００２９】  一般的に、組織において書類を作成する場合、上司からの命令によって書類を作成することがほとんどである。本発明では、様式を元に書類を作ることから、様式が存在することを命令が常時発せられている状態ととらえ、その応答として書類の作成やその途中経過の承認があると考える。つまり、様式を定義するデータを業務上の命令として取扱い、このデータをシステムに格納することが、命令が発せられた状態と考える。その様式に基づいて書類を作成することや、承認プロセスを経ることが、命令の遂行に当たり、命令に対する応答である。この時、命令を発したユーザが最終決裁者となり、応答として返ってきた書類の所有者は、命令を発したユーザとなる。図１は、実際の組織階層の例に当てはめた、命令と応答の説明である。図中の部長００１が命令の発令者であるとする。部長００１は、Ｂ部、及び、Ｂ部の下位部門である、Ｃ課、Ｄ課のメンバー００２に作成させたい書類がある場合、命令の内容に即した様式を定義するデータをシステムに格納する。メンバー００２は、様式に従い書類を作成し、命令に対する応答として、書類を命令の発令者である部長００１へ提出する。部長００１は、書類の内容を確認し、命令に沿った内容であれば、決裁を行う。このとき、決裁された書類の所有者は、書類を作成したメンバー００２ではなく、命令を発した部長００１となる。【００３０】  承認経路の記述は、発明が解決しようとする課題の節で述べたように、ＢＰＥＬ等の言語を用いた方法では記述のコストが高いという問題があった。これに対して、本発明では、承認経路を直接記述するのではなく、組織の構造に対応した木構造のデータ構造によって表現した組織情報と、様式に記述された承認経路の定義を元に、承認経路を生成する。【００３１】  前述したように、書類は、命令の発令者である様式の作成者への応答となるが、一般的な階層構造を持つ組織において、書類の作成者から、様式の作成者までの間に、中間管理者が存在すれば、直接応答を返すのではなく、中間管理者による確認を経てから、返されるべきである。すなわち、基本となる承認経路は、書類を作成したユーザから命令者である様式の作成者まで組織階層を上位に辿る経路とする。図２は、実際の組織階層の例に当てはめた、承認経路の説明である。図中の部長００１が命令の発令者で、メンバー００２が応答者である場合、書類の作成から最終決済までの経路は、中間管理者の課長００３を含め、メンバー００２、課長００３、部長００１の順となる。【００３２】  差戻しや飛び決のような経路については、個々に記述するのではなく、組織全体や様式毎の経路の有無を組織情報か様式にフラグとして記述し、そのフラグに従い、承認経路を生成する（図３）。【００３３】  承認経路には単純に組織階層を上向きに辿るもののほか、例えば経理部門の確認を必要とするものなど、組織階層を横断するものも多くある。本発明では、このような承認経路を効率的に取り扱うために、組織階層を構成する部門をライン部門とスタッフ部門の２種類に分けて取り扱う（図４）。【００３４】  ここで、ライン部門とは、例えば、社長→部長→課長→課員のように直線的な命令系統や直系組織のことで、会社の主要な仕事を直接的に担当する部門のことを指す。スタッフ部門とは、社内の共通的な仕事を、間接的に行う部門のことを指す。【００３５】  本発明では、スタッフ部門とした部門は、組織階層内の異なるライン部門から共通的な仕事を依頼される部門であり、すべてのライン部門配下に仮想的に位置する部門と解釈する（図５）。この解釈に基づいて、スタッフ部門を経由する形で組織階層を横断して行われる承認経路については、スタッフ部門による確認の有無を様式の承認経路の定義にフラグとして記述することで、簡便に定義することができる。【００３６】  いずれのフラグも、様式の承認経路の定義に記述がなければ組織情報の値に従い、記述があれば様式の承認経路の定義を優先する。【００３７】  書類のアクセス制御についても、承認経路の定義と同様に、組織情報と権限の定義を元に制御する。【００３８】  まず、ユーザが新規に書類の作成を開始すると、書類は作成中となる。作成中とはユーザが書類の作成を開始したが、すべての入力が終わっておらず、誰にも提出していない状態である。作成中の状態では、当該書類は書類の作成者しか参照することができない（図６）。書類の作成者が書類を完成したと判断した時点で、提出等のアクションを行うと、前述の方法によって生成された承認経路に従い、上位の承認者へ書類が提出される。【００３９】  次に、書類を提出された承認者は、当然ながらその書類を参照可能である必要がある。本発明では、承認を行うユーザが、書類の参照権限を変更する権限も保持すると考える。従来、多くのファイルシステムでは、書類の作成者が書類に対する各種権限を変更する権限を持つことがほとんどであったが、本発明においては、書類の参照権限を変更する権限を、それぞれの段階の承認者に移していく（図７）。書類の作成や承認が終わり、承認経路上の次のユーザが承認を行うユーザになった際、元の作成者や承認者は書類の参照権限を変更する権限を持たず、次のユーザが書類の参照権限を変更する権限を持つことになる。最終的に書類の参照権限を変更する権限を持つユーザは命令者である最終決裁者となる（図８）。本発明では、この書類に対する参照権限などの各種権限を変更する権限を持つユーザを書類の所有者と呼び、書類の所有者を作成者とは別に扱った点が特徴である。【００４０】  さらに、書類の権限の付与対象は、所有者を基準にして組織階層上で相対的に設定することができる。例えば、所有者の上位組織と所有者の下位の組織に対して参照権限を付与するといった具合である（図９）。【００４１】  書類を削除する権限についても、書類の所有者が持つこととする。【００４２】  また、これらの書類は、自身に参照権限があれば、作成中の書類であろうと、共有された書類であろうと共通のアクセス方法で検索できるものとする。【００４３】このような考えに基づき、本発明は次のような手段をとる。【００４４】  書類を保存するサーバと、権限変更部と、複数のユーザ端末とからなる文書共有システムにおいて、前記書類は、書類に対する権限の情報を含み、前記ユーザ端末は、前記書類を保存するサーバから書類を取得するとともに、前記書類に対する権限を変更するための権限変更画面を表示し、ユーザの指示に応じて、前記ユーザを識別するための識別子と前記書類に対する権限の変更指示を前記権限変更部へ送信し、前記権限変更部は、前記識別子に基づいて、前記ユーザが書類に対する権限を変更する権限を有するか否かを判断し、権限を有すると判断した場合に、前記書類の書類に対する権限の情報を変更して、前記書類を保存するサーバに保存させる。【００４��】  前記文書共有システムにおいて、前記書類は、書類を承認する承認者の順序を定義した承認経路の情報と、書類を承認済みの承認者の情報を含む実施者要素とを含み、前記権限変更部は、前記承認経路の情報と実施者要素とに基づいて、前記ユーザが次に承認を行うべき承認者であることを確認することで、前記ユーザが書類に対する権限を変更する権限を有すると判断する。【００４６】  前記文書共有システムにおいて、前記書類は、書類の作成者の情報と、書類の作成が完了したことを示す情報とを含み、前記権限変更部は、前記書類の作成者の情報と、書類の作成が完了したことを示す情報とに基づいて、前記ユーザが前記書類の作成者と同じユーザであり、さらに、前記書類の作成が完了していないことを確認することで、前記ユーザが書類に対する権限を変更する権限を有すると判断する。【００４７】  前記文書共有システムにおいて、前記書類は、書類を承認する承認者の順序を定義した承認経路の情報と、書類を承認済みの承認者の情報を含む実施者要素と、書類の作成者の情報を含み、前記権限変更部は、前記承認経路の情報、及び、実施者要素に基づいて、前記ユーザが作成者又は承認者であって、前記書類の承認がすべて終了していることを確認することで、前記ユーザが書類に対する権限を変更する権限を有すると判断する。【００４８】  前記文書共有システムにおいて、前記書類に対する権限の情報は、承認時に実行可能な操作を記述する承認権限の定義、書類の所有者の権限を記述する所有時の権限定義、書類の所有者が他のユーザに付与できる権限を記述する所有時の変更権限定義、及び、最終決裁後の書類の権限を記述する最終決裁後の権限定義のいずれか一つ以上のものを含む。【００４９】  前記文書共有システムにおいて、前記書類に対する権限の情報は、最終決裁後に所有者が他のユーザに付与できる権限を記述する最終決裁後の変更権限定義を含む。
【発明の効果】
【００５０】  本願発明では、文書構造の定義、型の定義、承認経路の定義、及び、権限の定義を含む様式を、専用言語を用いて記述する事によって、グラフィカルな専用ツールを用いて実現されたものと比較し、多数の様式に関する変更を一度に行うことが容易であり、変更にかかるメンテナンスの時間と経費を節減する効果を有する。【００５１】  グラフィカルな専用ツールを製造する場合においても、専用言語を開発のための中間言語として製造することで、ツールの開発コストを低く抑えることができる効果を有する。【００５２】  様式の定義に用いる型を値の集合として定義することで、入力された値と定義された集合と突き合わせる処理を行うエラーチェックプログラムの自動生成が可能となる。型が有限集合の場合に、取りうる値を列挙することによって型を定義できるようにすることで、エラーチェックプログラムに併せて、入力値の補完プログラムも自動生成することが可能である。列挙にて型を定義する際に、空集合を意味する記号を列挙値として利用できるようにすることで、入力項目の必須チェックを行うエラーチェックプログラムを自動生成することが可能である。列挙にて型を定義する方法において、列挙値として定義済みの別の型を利用できるようにするか、「任意」を意味する記号を列挙値として利用できるようにするとともに、型に制限を加えて別の型を定義することによって、正規表現で定義した型に従った入力値の補完を行うプログラムを自動生成することが可能である。このように型の定義を行い、型を使って様式の項目を定義するだけで、チェックプログラムと入力値の補完プログラムを含む入力画面を提供することができ、チェックプログラムと入力値の補完プログラムを含む入力画面の製造コストを大幅に低減する効果を有する。【００５３】  また、列挙にて型を定義する際に、タプルを使った定義を可能とすることで、通常であれば、複雑なプログラムが必要な複数項目にまたがるエラーチェックや入力値の補助プログラムを生成することができ、様式の記述コスト及び難易度を大幅に低減する効果を有する。【００５４】  列挙値としてデータベースへの参照を記述できるようにすることで、社内で保持するデータベースの値を用いることができるようになり、件数の多い列挙値の記述コストを低減したり、動的に変更される値を型として利用できたり、社内のデータと連携した入力画面の製造を行うことができるといった効果を有する。【００５５】  事前に必要な型を定義しておくことで、新たな型の定義なしに様式を記述することができる。型に制限を加えて別の型を定義できるようにすることで、必要に応じて事前に定義した型に制限を加えて新たな型を定義し、様式の記述を行うことができる。これにより、型の記述を最低限にすることができ、様式の記述コストを低減する効果を有する。【００５６】  承認経路の定義においては組織情報を元に、差戻しや飛び決のような経路の有無をフラグとして記述し、承認経路を自動生成することで、ＢＰＥＬエンジンなどの従来のワークフローエンジンと比較すると、プログラムの記述量が大幅に少なくなり、システムの構築コスト削減、構築速度の向上という効果を有する。【００５７】  ライン部門とスタッフ部門を��義することで、組織を横断する承認経路についても、容易に定義可能になる効果を有する。【００５８】  書類のアクセス制御を組織情報に基づいて行い、書類の作成者と、書類の参照権限や削除権限などの各種権限をもつ所有者とで分け、さらに、承認を行うたびに所有者が移り変わるようにすることで、書類に対する権限を持つユーザが適切なユーザとなり、権限を付け替える手間を無しに、セキュリティを高めることができるという効果を持つ。【００５９】  書類のアクセス制御を組織情報に基づいて行い、書類の作成者と、書類の参照権限を変更する権限をもつ所有者とで権限を分け、さらに、承認を行うたびに所有者が移り変わるようにすることで、書類の参照権限を変更することができるユーザが適切なユーザとなり、書類の共有を行う自由を残しつつ、セキュリティを高めることができるという効果を持つ。【００６０】  書類のアクセス制御を組織情報の階層情報に従い、書類の所有者から相対的に設定できるようにすることで、組織変更があった場合においても、権限を付け替える手間を無しに、適切なセキュリティを保つことができるという効果を持つ。【００６１】  自分自身が作成中の書類で提出前のものについては、作成者自身しか参照できないことを保証することで、作成者にとってはローカルファイルと同様な感覚で書類を扱えるようになり、同時に共有された書類と、作成中の書類をシームレスに検索できるようにすることで、書類が物理的にどこにあるかにかかわらず、容易に見つけることができるようになるという効果を持つ。
【発明を実施するための形態】
【実施例１】
【００６２】１．  システム構成
本発明を実現するために必要な構成要素のブロック図を図１０に示す。本発明の稟議システムは、組織情報・様式・既存の型を保存するサーバ０１００１と、組織情報、様式、及び、既存の型を解釈し、チェックプログラム、補完プログラム、及び、様式中間情報を生成する様式コンパイラ０１００２を実行する様式コンパイルサーバ０１００３と、組織情報参照部０１００４と様式検索部０１００５からなるアプリケーションサーバ０１００６と、生成されたチェックプログラム０１００７、及び、補完プログラム０１００８を実行するアプリケーションサーバ０１００９と、書類起案部０１０１０、書類提出部０１０１１、書類承認部０１０１２、書類検索部０１０１３、書類参照部０１０１４、及び、書類削除部０１０１５からなるアプリケーションサーバ０１０１６と、書類を保存するサーバ０１０１７と、様式選択画面０１０１８、書類検索画面０１０１９、書類入力画面０１０２０、書類承認画面０１０２１、及び、書類参照画面０１０２２を保存し配信するＷｅｂサーバ０１０２３と、認証サーバ０１０２４と、画面を表示するＷＥＢブラウザ０１０２５を持つ複数の利用者端末０１０２６から構成される。【００６３】  組織情報とは、組織の階層構造、ユーザの役職や氏名、及び、承認経路を生成するためのルールや書類に対する操作の可否を定義した権限の定義を記述するものである。【００６４】  組織情報を記述する言語はどのようなものでも構わないが、本実施例ではこれらの情報を、専用の言語（以下、「組織情報記述言語」と呼ぶ。）を設計し記述する。【００６５】  組織情報記述言語は、ユーザ情報０１０２７と組織階層情報０１０２８で構成される。【００６６】  ユーザ情報０１０２７は、ユーザの識別子０１０２９、氏名０１０３０、役職０１０３１、及び、パスワード０１０３２を１レコードとするリストである。組織階層情報０１０２８は組織を構成する部門０１０３３の階層構造で構成される。部門０１０３３が持つ情報は、部門名０１０３４、部門の長０１０３５、部門のメンバー０１０３６、権限の定義０１０３７、下位の部門０１０３３、及び、下位のスタッフ部門０１０３８である。【００６７】  組織情報をユーザの階層構造とせず、部門の階層構造とし、部門にユーザを所属させる構造としたことが特徴である。（図１１）【００６８】  様式とは、利用者が最終成果物である書類を作成するための枠組みを定義する情報であり、一般的にテンプレートと呼ばれるものである。様式を記述する言語はどのようなものでも構わないが、本実施例では専用の言語（以下、「様式記述言語」と呼ぶ。）とする。【００６９】  様式記述言語は、型の定義０１０３９、文書構造の定義０１０４０、承認経路の定義０１０４１、権限の定義０１０４２から成る。【００７０】  型の定義０１０３９とは、書類を構成する項目に入力可能な値の範囲を定義したものである。様式中に定義される型を、ユーザ定義型０１０４３と呼ぶこととする。型の定義０１０３９には、型名０１０４４と型の定義内容０１０４５の組を複数記述できる。型の定義内容０１０４５は、正規表現、列挙値、又は定義済みの別の型名によって型を定義する。列挙値には、テキスト値の他、空集合を意味する特殊��号“ＮＵＬＬ”と定義済みの別の型名が列挙できる。【００７１】  文書構造の定義０１０４０とは、書類の項目名０１０４６と、項目名に対応する型名０１０４７を記述し、その定義を実際の書類の構造に合わせて配置して、書類の構造を定義するものである。書類の項目名に対応づける型名は前述のユーザ定義型０１０４３の他に、既存の型も利用できる。既存の型とは、複数の様式から共通的によく使う型を、事前に定義しておくものである。【００７２】  承認経路の定義０１０４１は、作成された書類の承認経路を定義するものである。承認経路すべてを記述するのではなく、組織情報に示される組織の階層構造に沿わない部分のみを記述する。【００７３】  承認経路の定義０１０４１は、起案可能部門０１０４８、スタッフによる承認の有無０１０４９、承認不要部門０１０５０を記述する。【００７４】  組織情報に記述される権限の定義０１０３７、及び、様式に記述される権限の定義０１０４２は、作成された書類の参照や変更の権限の定義を記述するものである。権限の定義０１０４２は、所有時の権限０１０５１、承認権限０１０５２、決裁後の権限０１０５３を記述する。【００７５】  書類は、様式に定義された項目と、ユーザからの入力値、承認経路の設定から構成されるひとまとまりの情報である。本実施例ではＸＭＬを用いて記述するが、ＪＳＯＮ、ＹＡＭＬなどの他の周知の方法を用いても本発明を実現しうる。【００７６】２．  処理の流れ
２−１．  認証
利用者が利用者端末を用いて本システムにアクセスすると認証が行われる。本発明では、認証を行う方法としてログインダイアログが表示される方式を例示するが、ＩＣカードを用いる方法、利用者の指紋を読み取らせる方法、静脈認証、網膜認証など他の周知の方法を用いてもよい。【００７７】  利用者が、組織情報・様式・既存の型を保存するサーバ０１００１、又は、ＷＥＢサーバ０１０２３へアクセスすると、認証サーバ０１０２４がログインダイアログをＷＥＢブラウザ０１０２５に表示させる。利用者が、ユーザＩＤとパスワードの組を入力すると、認証サーバ０１０２４は、組織情報・様式・既存の型を保存するサーバ０１００１からユーザ一覧を取得し、ユーザＩＤとパスワードの組が正しいか確認する。ユーザＩＤとパスワードの組が正しければ利用者は各サーバにアクセスできる。認証サーバ０１０２４を通したアクセスにおいては、通信の度に各サーバに保証されたユーザＩＤが渡さているものとする。認証は、必ず行われているものとし、以後の処理手順の説明からは省略する。【００７８】  ２−２．  組織情報と様式の作成
最初に、組織情報及び様式の作成からプログラムの生成までを説明する。【００７９】  ２−２−１．組織情報の作成
利用者は組織の構造や、ユーザの所属に関する情報として、実際の組織の階層情報に対応した組織情報を作成し、組織情報・様式・既存の型を保存するサーバ０１００１に保存する。組織情報の作成は、専用のエディタを開発し、それを用いて記述してもよいし、テキストエディタ等で記述してもよい。ＬＤＡＰ等外部の情報を取り込んで加工する方法も考えられる。【００８０】  ２−２−２．様式の作成
様式の作成は、専用のエディタを開発して記述してもよいし、テキストエディタ等で記述してもよい。本発明において、様式の作成者は様式に従って作成された書類の承認経路の最終決裁者であるとともに、書類の最終的な所有者となる。このため、様式中の様式所有者の領域に様式の作成者のユーザＩＤと作成者が所属する部門ＩＤを記述しておくものとする。【００８１】  ２−２−３．組織情報と様式のコンパイル
様式が、組織情報・様式・既存の型を保存するサーバ０１００１に保存されると、組織情報、様式、既存の型を様式コンパイルサーバ０１００３へ送信し、様式コンパイルサーバ０１００３において様式コンパイラ０１００２が起動されて、以下に説明する手順に基づいてチェックプログラム、および、補完プログラムを生成する。【００８２】  様式コンパイラ０１００２は、まず、組織情報・様式・既存の型を保存するサーバ０１００１に保存された既存の型、及び、様式に記述されたユーザ定義型を用いて、画面からの入力値を引数にとり、入力値を型の定義と比較し、エラー判定結果を返却するチェックプログラムを定義された全ての型について生成する。チェックプログラムの処理内容は以下のようになる。【００８３】  （１）入力値を受け取る
（２）入力値が空でない場合
（２．１）型が列挙型の場合
（２．１．１）入力値と同じ値の有無を調べる
（２．１．２）同じ値があった場合：判定結果ＯＫを返却する
（２．１．３）同じ値がなかった場合
（２．１．３．１）列挙値中に型名がないか探す
（２．１．３．２）型名があり型が列挙型の場合：（２．１．１）に戻る
（２．１．３．３）型名があり型が正規表現型の場合：
（２．１．３．３．１）正規表現にマッチするか調べる
（２．１．３．３．２）マッチした場合：判定結果ＯＫを返却する
（２．１．３．３．３）マッチしない場合：判定結果ＮＧを返却する
（２．２）型が正規表現型の場合
（２．２．１）正規表現にマッチするか調べる
（２．２．１．１）マッチした場合：判定結果ＯＫを返却する
（２．２．１．２）マッチしない場合：判定結果ＮＧを返却する
（３）入力値が空の場合
（３．１）型が列挙型の場合
（３．１．１）ｎｕｌｌ記号の有無を調べる
（３．１．２）ｎｕｌｌ記号があった場合：判定結果ＯＫを返却する
（３．１．３）ｎｕｌｌ記号がなかった場合
（３．１．３．１）列挙値中に型名がないか探す
（３．１．３．２）型名があり型が列挙型の場合：（３．１．１）に戻る
（３．１．３．３）型名があり型が正規表現型の場合：
（３．１．３．３．１）正規表現にマッチするか調べる
（３．１．３．３．２）マッチした場合：判定結果ＯＫを返却する
（３．１．３．３．３）マッチしない場合：判定結果ＮＧを返却する
（３．２）型が正規表現型の場合
（３．２．１）正規表現にマッチするか調べる
（３．２．１．１）マッチした場合：判定結果ＯＫを返却する
（３．２．１．２）マッチしない場合：判定結果ＮＧを返却する【００８４】  上記処理内容のフローチャートを図１２、１３に示す。【００８５】  様式コンパイラ０１００２は、チェックプログラムを、例えば、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ、Ｃ言語などのプログラミング言語によって生成したのち、実行可能な形式でアプリケーションサーバ０１００９へ保存する。【００８６】  様式コンパイラ０１００２は、次に、既存の型、及び、様式に記述されたユーザ定義型を用いて、画面からの入力値を引数にとり、補完値を戻り値とする補完プログラムを定義された全ての型について生成する。補完プログラムの処理内容は以下のようになる。【００８７】  （１）入力として  入力値を受け取る
（２）入力値が空の場合
（２．１）型が列挙型の場合
（２．１．１）列挙値の数だけ繰り返す
（２．１．１．１）列挙値が値の場合：補完値のリストに値を加える
（２．１．１．２）列挙値が列挙型の場合：（２．１）に戻る
（２．１．１．２）列挙値が正規表現型の場合：何もしない
（２．１．２）補完値のリストを返却し終了する
（２．２）型が正規表現型の場合：何もしない
（２）入力値が空でない場合：何もしないで終了する【００８８】  様式コンパイラ０１００２は、生成した補完プログラムを、アプリケーションサーバ０１００９へ保存する。【００８９】  上記処理内容のフローチャートを図１４に示す。【００９０】  ２−３．  書類の作成から提出
次に書類の作成から提出までを説明する。【００９１】  ２−３−１．様式の選択
書類の作成者は、まず、様式選択画面０１０１８にアクセスし、自身が作成できる様式を検索する。検索を実行すると、様式選択画面０１０１８は、様式検索部０１０５４に作成者のユーザＩＤを渡す。様式検索部０１０５４は、様式の承認経路の定義の内容から、当該ユーザＩＤが起案可能な様式の、様式の識別子を含む一覧を返却する。様式選択画面０１０１８は、返却された内容から様式の一覧を表示する。【００９２】  ２−３−２．書類の作成
書類の作成者は、一覧から作成したい様式を選択し、書類の作成を実行する。作成を実行すると、様式選択画面は、書類起案部０１０１０に、ユーザＩＤと様式の識別子を送信する。書類起案部０１０１０は、様式検索部０１０５４に様式の識別子を送信し、当該様式を取得する。【００９３】  ２−３−２−１．書類の作成権限の確認
書類起案部０１０１０は、組織情報参照部０１００４から組織情報を取得し、様式と組織情報を確認から、書類の作成権限の確認を行う。様式の承認経路の定義に、起案可能部門０１０４８の記述がある場合、ユーザＩＤが起案可能部門に含まれていれば書類を作成可能と判断する。様式の承認経路の定義に、起案可能部門０１０４８の記述がない場合、様式の所有者の所属部門を組織情報の組織階層情報から特定し、様式の所有者の所属部門の下位の部門をすべて特定する。ユーザＩＤが、特定した部門に含まれれば、書類を作成可能であると判断する。【００９４】  ２−３−２−２．様式からＸＭＬ形式の書類への変換
作成権限に問題がなければ、書類起案部０１０１０は、次の処理を行い、様式からＸＭＬ形式の書類を作成する。【００９５】（１）ルート要素である書類要素０１０５５を作成する。
（２）書類の識別子を発行し、書類要素０１０５５のＩＤ属性０１０５６に記述する。
（３）書類要素０１０５５の下位に様式の識別子を内容とした様式ＩＤ要素０１０５７を作成する。
（４）書類要素０１０５５の下位に様式の所有者の部門ＩＤを内容とした様式所有者要素０１０５８を作成する。
（５）書類要素０１０５５の下位に承認経路要素０１０５９を作成する。
（６）書類要素０１０５５の下位に書面要素０１０６０を作成する。
（７）承認経路要素０１０５９の下位に承認経路の設定を作成する。承認経路の設定については後述する。
（８）様式の項目名と型名の定義の数だけ繰り返す。
（８．１）項目名を要素名とした項目要素０１０６１を作成する。
（８．２）型名を項目要素０１０６１の型属性０１０８９に記述する。【００９６】  上記処理内容のフローチャートを図１５に示す。【００９７】２−３−２−３．承認経路の作成
承認経路の設定は以下の手順で作成する。【００９８】  まず、組織情報参照部０１００４から取得した組織情報の省略値を補完し、組織階層情報に様式の承認経路の定義、及び、権限の定義を反映した中間情報０１０６２を作成する。【００９９】  （１）すべての部門を対象に処理を行う。
（１．１）権限の定義が記述されていなければ、上位の部門の権限の定義を、コピーする。
（１）承認経路の定義に記述された定義の数だけ繰り返す。
（１．１）承認経路の定義に承認不要部門０１０５０が記述されていた場合
（１．１．１）組織階層情報の対象部門に承認不要０１０６３を追加する
（１．２）承認経路の定義にスタッフによる承認の有無０１０４９が記述されていた場合
（１．２．１）組織階層情報の対象部門にスタッフ部門承認要０１０６４を追加する
（２）権限の定義に記述された定義の数だけ繰り返す。
（２．１）すべての部門を対象に処理を行う。
（２．１．１）権限の定義に承認権限の定義が記述されていた場合
（２．１．１．１）組織階層情報の承認権限の定義０１０６５を変更する。
（２．１．２）権限の定義に所有時権限の定義が記述されていた場合
（２．１．２．１）組織階層情報の所有時権限の定義０１０６６を変更する。
（２．１．３）権限の定義に決裁後権限の定義が記述されていた場合
（２．１．３．１）組織階層情報の決裁後権限の定義０１０６７を変更する。【０１００】  上記処理内容のフローチャートを図１６に示す。【０１０１】  また、作成された「組織階層情報に様式の承認経路の定義、及び、権限の定義を反映した中間情報０１０６２」の例を図１７に示す。【０１０２】  次に、組織階層情報に承認経路の定義を反映した中間情報０１０６２から以下の手順で承認経路０１０６８を作成する。【０１０３】  （１）中間情報０１０６２から書類の作成者が所属する部門を特定する。
（２）承認経路０１０６８に作成者だけを残した当該部門を追加する。
（３）承認経路０１０６８にメンバーを削除し長だけにした当該部門を追加する。
（４）上位の部門を特定する。
（４．１）特定した部門が様式の所有者が所属する部門でない場合。
（４．１．１）特定した部門に承認不要０１０６３が追加されていない場合。
（４．１．１．１）承認経路０１０６８に、メンバーを削除し長だけにした当該部門を追加する。
（４．１．２）処理（４）へ戻る。
（４．２）特定した部門が様式の所有者が所属する部門である場合。
（４．２．１）承認経路０１０６８に、メンバーを削除し長だけにした当該部門を追加し、処理を終了する。【０１０４】  上記処理内容のフローチャートを図１８に示す。【０１０５】  最後に、承認経路０１０６８をＸＭＬに変換し、書類の承認経路要素０１０５９の下位に追加する。ＸＭＬへの変換ルールは以下となる。【０１０６】（１）承認経路０１０６８の部門の数だけ繰り返す。
（１．１）ひとつ目の時
（１．１．１）起案者要素０１０６９を作成する。
（１．１．２）起案者要素０１０６９の下位に予定者要素０１０７０を作成する。
（１．１．３）予定者要素０１０７０の下位に、作成者の部門名を内容に、部門の識別子をＩＤ属性とした、部門要素０１０７１を作成する。
（１．１．４）予定者要素０１０７０の下位に、作成者のユーザ名を内容に、ユーザの識別子をＩＤ属性とした、ユーザ要素０１０７２を作成する。
（１．１．５）起案者要素０１０６９の下位に、実施者要素０１０７３を作成する。実施者要素０１０７３の内容は空とする。
（１．１．６）起案者要素０１０６９の下位に、権限要素０１０７４を作成する。
（１．１．７）対象が作成者になっている承認権限の定義０１０６５から、承認権限要素０１０７５を作成し、権限要素０１０７４の下位に追加する。
（１．１．８）対象が作成者になっている所有時権限の定義０１０６６から、所有時権限要素０１０７６を作成し、権限要素０１０７４の下位に追加する。
（１．１．９）対象が作成者になっている決裁後権限の定義０１０６７から、決裁後権限要素０１０７７を作成し、権限要素０１０７４の下位に追加する。
（１．２）ひとつ目でも最後でもない時
（１．２．１）承認者要素０１０７８を作成する。
（１．２．２）承認者要素０１０７８の下位に予定者要素０１０７０を作成する。
（１．２．３）予定者要素０１０７０の下位に、承認者の部門名を内容に、部門の識別子をＩＤ属性とした、部門要素０１０７１を作成する。
（１．２．４）予定者要素０１０７０の下位に、承認者のユーザ名を内容に、ユーザの識別子をＩＤ属性とした、ユーザ要素０１０７２を作成する。
（１．２．５）承認者要素０１０７８の下位に、実施者要素０１０７３を作成する。実施者要素０１０７３の内容は空とする。
（１．２．６）承認者要素０１０７８の下位に、権限要素０１０７４を作成する。
（１．２．７）対象が承認者になっている承認権限の定義０１０６５から、承認権限要素０１０７５を作成し、権限要素０１０７４の下位に追加する。
（１．２．８）対象が承認者になっている所有時権限の定義０１０６６から、所有時権限要素０１０７６を作成し、権限要素０１０７４の下位に追加する。
（１．２．９）対象が承認者になっている決裁後権限の定義０１０６７から、決裁後権限要素０１０７７を作成し、権限要素０１０７４の下位に追加する。
（１．３）最後の時
（１．２．１）最終決裁者要素０１０７９を作成する。
（１．２．２）最終決裁者要素０１０７９の下位に予定者要素０１０７０を作成する。
（１．２．３）予定者要素０１０７０の下位に、最終決裁者の部門名を内容に、部門の識別子をＩＤ属性とした、部門要素０１０７１を作成する。
（１．２．４）予定者要素０１０７０の下位に、最終決裁者のユーザ名を内容に、ユーザの識別子をＩＤ属性とした、ユーザ要素０１０７２を作成する。
（１．２．５）最終決裁者要素０１０７９の下位に、実施者要素０１０７３を作成する。実施者要素０１０７３の内容は空とする。
（１．２．６）最終決裁者要素０１０７９の下位に、権限要素０１０７４を作成する。
（１．２．７）対象が最終決裁者になっている承認権限の定義０１０６５から、承認権限要素０１０７５を作成し、権限要素０１０７４の下位に追加する。
（１．２．８）対象が最終決裁者になっている所有時権限の定義０１０６６から、所有時権限要素０１０７６を作成し、権限要素０１０７４の下位に追加する。
（１．２．９）対象が最終決裁者になっている決裁後権限の定義０１０６７から、決裁後権限要素０１０７７を作成し、権限要素０１０７４の下位に追加する。【０１０７】  上記処理内容のフローチャートを図１９、２０に示す。【０１０８】  また、承認経路要素を追加したＸＭＬ形式の書類の例を図２１に示す。【０１０９】２−３−２−４．書類の保存
書類起案部０１０１０は、書類を保存するサーバ０１０１７に、以上の手順によって作成したＸＭＬ形式の書類を送信し、正常に終了した場合は作成した書類の識別子を様式選択画面０１０１８に返す。書類を保存するサーバ０１０１７は、送信されたＸＭＬ形式の書類を保存する。【０１１０】２−３−３．書類の表示
様式選択画面０１０１８は、リダイレクト等の方法で、書類入力画面０１０２０を呼び出す。この時書類の識別子を渡す。【０１１１】  書類入力画面０１０２０は、先ほど作成した書類を表示するために、書類参照部０１０１４に、ユーザＩＤと書類の識別子を渡す。書類参照部０１０１４は、書類の識別子を使って書類を保存するサーバ０１０１７から書類を取得し、書類の変更権限の確認を行う。書類の変更権限を確認する条件は以下のとおりである。【０１１２】  ・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の予定者要素に自身のユーザＩＤが存在し、当該起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素に値“ｗｒｉｔｅ”がある。【０１１３】  書類の変更権限に問題がなければ、書類参照部０１０１４は、書類入力画面０１０２０に当該書類を返却する。なお、承認経路の状態から判断して、自身が書類の作成や承認を行う順番にある状況を、書類の所有者であると呼ぶ。【０１１４】  書類入力画面０１０２０は、返却された書類をＨＴＭＬ形式に変換し、入力フォームを作成する。ＨＴＭＬへの変換方法は、ＸＭＬスタイルシートを使用する方法、ＪａｖａＳｃｒｉｐｔを使って変換する方法等が考えられる。変換はどのような方法を用いてもいいが、書面要素以下の項目要素を項目名のラベルと、インプットボックスに変換する。書類入力画面０１０２０は、作成した書類を提出するためのボタンを備えているものとする。項目の型属性から、チェックプログラムと補完プログラムの呼出を作成する。本実施例では、入力フォームの値が変更されたイベントで、補完プログラムを呼び出し、提出ボタンが押されたイベントでエラーチェックプログラムが呼び出されることとする。【０１１５】  書類入力画面０１０２０は、ｊａｖａｓｃｒｉｐｔのＸｍｌ＿Ｈｔｔｐ＿Ｒｅｑｕｅｓｔ等を用いて非同期で入力フォームの内容を送信し結果を受け取る。【０１１６】  利用者が入力フォームに値を入力すると、書類入力画面０１０２０から補完プログラムに入力された内容が送信され、補完プログラムによって補完値の取得が行われる。補完プログラムの結果、補完候補があれば、補完プログラムから補完候補が返却され、テキストボックスの下部に選択値を一覧表示する等の方法で補完候補を表示する。【０１１７】  ２−３−４．書類の提出
利用者が必要事項を全て入力し、提出ボタンをクリックすると、書類入力画面からチェックプログラムに入力フォームの内容が送信され、チェックプログラムによってエラーチェックが行われる。チェックプログラムの結果が返却されてエラーであれば、入力画面にエラーを表示する。入力画面にエラーを表示する方法としては、ダイアログボックスを使って警告する方法、入力値をフォーム要素の色を変えて警告する方法、ブロック要素の色や形等の属性値を変更して警告を行う方法などが用いられる。【０１１８】  エラーチェックの結果問題がなければ、書類入力画面０１０２０は、ユーザＩＤ、書類の識別子、及び、入力フォームの内容を書類提出部０１０１１に送信する。【０１１９】  書類提出部０１０１１は、チェックプログラム０１００７を呼び出し、入力フォームの内容を再度チェックする。エラーチェックの結果問題がなければ、入力フォームの内容を当該書類の項目に反映する。【０１２０】  書類提出部０１０１１は、書類の起案者要素０１０６９から作成者のユーザＩＤを探し、権限の確認を行う。提出の権限を確認する条件は以下のとおりである。【０１２１】  ・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の予定者要素に自身のユーザＩＤが存在し、当該起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”、及び、“ｗｒｉｔｅ”があり、当該起案者要素の承認権限要素に値“ｆｏｒｗａｒｄ”がある。【０１２２】  権限に問題がなければ、起案者要素０１０６９の実施者要素に作成者の所属部門ＩＤを内容にした部門要素、作成者のユーザＩＤを内容にしたユーザ要素、提出した日時を内容にした日付要素を追加する。ここで、実施者要素の内容を作成するということは、書類の作成が完了したことを意味するとともに、当該ユーザが所有者でなくなり、承認経路上の次のユーザが所有者になることを意味する。これは、所有時権限要素に記述された権限が無効になるということである。【０１２３】  更新した書類を、書類を保存するサーバ０１０１７に送信し、保存されている書類を更新する。【０１２４】  ２−４．  承認
次に、承認を行う際の処理手順について説明する。【０１２５】  ２−４−１．対象書類の検索
承認者が書類を承認する場合は、書類検索画面０１０１９から、書類が却下も削除もされておらず、自身が承認予定者で、まだ承認を実施していない書類を検索する。
書類の承認経路要素に対する具体的な検索条件は、以下のいずれかである。【０１２６】  ・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｆｏｒｗａｒｄ”があり、当該承認者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。【０１２７】  ・承認経路要素に却下要素、又は、削除要素が無く、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者要素の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該最終決裁者要素の承認権限要素に値“ｆｏｒｗａｒｄ”があり、当該最終決裁者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。【０１２８】  なお、書類検索画面０１０１９は、このような検索条件をユーザが任意に指定できるようにしてもよいし、事前に用意して、“承認待ち”のようなリンクを押下することで実行するようにしてもよい。【０１２９】  書類検索画面０１０１９は、検索条件を書類検索部０１０１３へ送信する。書類検索部０１０１３は、書類の承認経路要素に対して検索を実行し、該当書類を特定する。書類検索部０１０１３は該当書類の一覧を、書類検索画面０１０１９へ返す。書類検索画面０１０１９は該当書類の一覧を表示する。【０１３０】  図２２に検索画面の例を示す。【０１３１】２−４−２．書類の表示
承認者が、該当書類の一覧から承認対象の書類を選択すると、書類承認画面０１０２１が表示される。このとき書類検索画面０１０１９からは書類の識別子が渡される。書類承認画面０１０２１は書類参照部０１０１４へユーザＩＤと書類の識別子を渡す。書類参照部０１０１４は、書類を保存するサーバ０１０１７から、書類の識別子で特定される書類を取得する。書類参照部０１０１４は、検索を行った時と同じ条件で書類の承認が可能か確認する。条件は以下のいずれかである。【０１３２】  ・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｆｏｒｗａｒｄ”があり、当該承認者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。【０１３３】  ・承認経路要素に却下要素、又は、削除要素が無く、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者要素の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該最終決裁者要素の承認権限要素に値“ｆｏｒｗａｒｄ”があり、当該最終決裁者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。【０１３４】  権限に問題がなければ、書類参照部０１０１４は、取得した書類を書類承認画面０１０２１に返却し、書類承認画面０１０２１は返却されたＸＭＬ形式の書類をＨＴＭＬに変換し表示する。この時、書類承認画面０１０２１は、あらかじめ用意した承認ボタンを押下可能にする。【０１３５】  図２３に承認画面の例を示す。【０１３６】２−４−３．承認の実施（承認の場合）
承認者は、書類に問題がなければ、書類承認画面０１０２１に備えられた承認ボタンを押下する。書類承認画面０１０２１は、書類の識別子、利用者のユーザＩＤ、及び、承認を意味するフラグを引数に、書類承認部０１０１２を呼び出す。【０１３７】  書類承認部０１０１２は、検索を行った時、及び、書類を表示した時と同じ条件で書類の承認が可能か確認する。条件は以下のいずれかである。【０１３８】  ・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｆｏｒｗａｒｄ”があり、当該承認者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。【０１３９】  ・承認経路要素に却下要素、又は、削除要素が無く、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者要素の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該最終決裁者要素の承認権限要素に値“ｆｏｒｗａｒｄ”があり、当該最終決裁者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。【０１４０】  権限に問題がなければ、書類の承認者の実施者要素に承認者の所属部門ＩＤを内容にした部門要素０１０８０、承認者のユーザＩＤを内容にしたユーザ要素０１０８１、承認した日時を内容にした日時要素０１０８２、承認した旨を意味する承認要素０１０８３を追加する。書類承認部０１０１２は、変更した書類を書類を保存するサーバ０１０１７に送信し、保存されている書類を更新する。【０１４１】  図２４は、承認後の書類の承認者要素の例である。【０１４２】２−４−４．承認の実施（却下の場合）
書類を却下する場合も、同様の処理の流れとなる。却下の場合は、承認時の条件で確認する承認権限要素の値は“ｒｅｊｅｃｔ”となる。また、書類の実施者要素に追加する要素は、承認要素０１０８３ではなく却下要素０１０８４とする。【０１４３】２−４−５．承認の実施（差戻の場合）
書類を差戻しする場合に、書類参照部０１０１４が確認する条件は以下のいずれかである。これは、承認時の条件において、確認する承認権限要素の値を“ｒｅｔｕｒｎ”に置き換えたものである。【０１４４】  ・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｒｅｔｕｒｎ”があり、当該承認者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。【０１４５】  ・承認経路要素に却下要素、又は、削除要素が無く、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者要素の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該最終決裁者要素の承認権限要素に値“ｒｅｔｕｒｎ”があり、当該最終決裁者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。【０１４６】  書類承認画面０１０２１は“ｒｅｔｕｒｎ”のキーワードがあれば、差戻しボタンを押下可能にする。承認者が差戻しボタンを押下すると、書類承認画面０１０２１は、書類の識別子、承認者のユーザＩＤ、及び、差戻しを意味するフラグを引数に、書類承認部０１０１２を呼び出す。【０１４７】  書類承認部０１０１２は、書類参照部０１０１４と同様の条件で、所有者と権限の確認を行う。【０１４８】  書類を差戻しする場合に、書類承認部０１０１２が確認する条件は、書類参照部０１０１４が確認する条件と同じく、以下のいずれかである。【０１４９】  ・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｒｅｔｕｒｎ”があり、当該承認者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。【０１５０】  ・承認経路要素に却下要素、又は、削除要素が無く、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者要素の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該最終決裁者要素の承認権限要素に値“ｒｅｔｕｒｎ”があり、当該最終決裁者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。【０１５１】  問題がなければ、まず、一つ前の承認者要素か起案者要素の実施者要素の要素名を実施履歴要素０１０８５に変更し、新しく内容が空の実施者要素０１０９０を作成する。次に、承認者要素の下にも実施履歴要素０１０９１を作成し、承認者の所属部門ＩＤを内容にした部門要素０１０８０、承認者のユーザＩＤを内容にしたユーザ要素０１０８１、承認した日時を内容にした日時要素０１０８２、差戻しした旨を意味する差戻要素０１０９２を追加する。書類承認部０１０１２は、変更した書類を書類を保存するサーバ０１０１７に送信し、保存されている書類を更新する。【０１５２】  図２５は、差戻し後の書類の承認経路要素の例である。【０１５３】２−４−６．承認の実施（飛ばし承認）
書類の飛ばし承認（強制承認）や飛ばし決裁（強制決裁）を行う場合に、書類参照部０１０１４が確認する条件は以下のいずれかである。【０１５４】  ・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素に値があり、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｓｋｉｐ”があり、当該承認者要素の前の承認者要素の実施者要素に値がない。【０１５５】  ・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素に値があり、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者要素の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該最終決裁者要素の承認権限要素に値“ｓｋｉｐ”があり、当該最終決裁者要素の前の承認者要素の実施者要素に値がない。【０１５６】  書類承認画面０１０２１は“ｓｋｉｐ”のキーワードがあれば、飛ばし承認ボタンを押下可能にする。承認者が飛ばし承認ボタンを押下すると、書類承認画面０１０２１は、書類の識別子、承認者のユーザＩＤ、及び、飛ばし承認を意味するフラグを引数に、書類承認部０１０１２を呼び出す。【０１５７】  書類承認部０１０１２は、所有者と権限の確認を行う。【０１５８】  書類を飛ばし承認、又は、飛ばし決裁する場合に、書類承認部０１０１２が確認する条件は、書類参照部０１０１４が確認する条件と同じく、以下のいずれかである。【０１５９】  ・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素に値があり、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｓｋｉｐ”があり、当該承認者要素の前の承認者要素の実施者要素に値がない。【０１６０】  ・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素に値があり、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者要素の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該最終決裁者要素の承認権限要素に値“ｓｋｉｐ”があり、当該最終決裁者要素の前の承認者要素の実施者要素に値がない。【０１６１】  問題がなければ、一つ前の承認者の実施者要素０１０８６と自身の実施者要素双方に、承認者の所属部門ＩＤを内容にした部門要素０１０８０、承認者のユーザＩＤを内容にしたユーザ要素０１０８１、承認した日時を内容にした日時要素０１０８２、承認した旨を意味する承認要素０１０８７を追加する。書類承認部０１０１２は、変更した書類を書類を保存するサーバ０１０１７に送信し、保存されている書類を更新する。【０１６２】  図２６は、飛ばし承認後の書類の承認経路要素の例である。【０１６３】  ２−４−７．承認（取戻し）
書類の取戻しを行う場合に、書類参照部０１０１４が確認する条件は以下のいずれかである。【０１６４】  ・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素に自身のユーザＩＤが存在し、当該起案者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該起案者要素の承認権限要素に値“ｇｅｔｂａｃｋ”があり、当該起案者要素の一つ後の承認者要素に値が無い。【０１６５】  ・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の実施者要素に自身のユーザＩＤが存在し、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｇｅｔｂａｃｋ”があり、当該承認者要素の一つ後の承認者要素に値が無い。【０１６６】  書類承認画面０１０２１は“ｇｅｔｂａｃｋ”のキーワードがあれば、取戻しボタンを押下可能にする。承認者が取戻しボタンを押下すると、書類承認画面０１０２１は、書類の識別子、承認者のユーザＩＤ、及び、取戻しを意味するフラグを引数に、書類承認部０１０１２を呼び出す。【０１６７】  書類承認部０１０１２は、所有者と権限の確認を行う。
書類を取戻しする場合に、書類承認部０１０１２が確認する条件は、書類参照部０１０１４が確認する条件と同じく、以下のいずれかである。【０１６８】  ・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素に自身のユーザＩＤが存在し、当該起案者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該起案者要素の承認権限要素に値“ｇｅｔｂａｃｋ”があり、当該起案者要素の一つ後の承認者要素に値が無い。【０１６９】  ・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の実施者要素に自身のユーザＩＤが存在し、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｇｅｔｂａｃｋ”があり、当該承認者要素の一つ後の承認者要素に値が無い。【０１７０】  問題がなければ、まず、自身が実施した承認者要素か起案者要素の実施者要素の要素名を実施履歴要素０１０８５に変更し、新しく内容が空の実施者要素０１０９０を作成する。次に、次の承認者要素の下にも実施履歴要素０１０９１を作成し、取戻しを行ったユーザの所属部門ＩＤを内容にした部門要素０１０８０、取戻しを行ったユーザのユーザＩＤを内容にしたユーザ要素０１０８１、取戻しした日時を内容にした日時要素０１０８２、取戻しを意味する取戻要素０１０９３を追加する。書類承認部０１０１２は、変更した書類を書類を保存するサーバ０１０１７に送信し、保存されている書類を更新する。【０１７１】  ２−５．  削除
書類の削除を行う際の処理手順について説明する。【０１７２】  ２−５−１．対象書類の検索
利用者が書類を削除する場合は、書類検索画面０１０１９から自身が所有者で削除権限を付与されている書類の検索を行う。削除可能な書類を検索するための条件は以下のいずれかとなる。【０１７３】  ・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の予定者要素に自身のユーザＩＤが存在し、当該起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素に値“ｄｅｌｅｔｅ”がある。【０１７４】  ・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ｄｅｌｅｔｅ”があり、当該承認者要素の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。【０１７５】  ・承認経路要素に却下要素、又は、削除要素が無く、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者の実施者要素が空であり、当該最終決裁者の所有時権限要素に値“ｄｅｌｅｔｅ”があり、当該最終決裁者の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。【０１７６】  ・承認経路要素に削除要素が無く、すべての実施者要素が値を持ち、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素に値“ｄｅｌｅｔｅ”があり、決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。【０１７７】  ・承認経路要素に削除要素が無く、承認経路要素に却下要素があり、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素に値“ｄｅｌｅｔｅ”があり、決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。【０１７８】  最後の二つの条件については、所属部門、及び、所属メンバーが示す範囲を求めるために組織情報が必要である。書類検索部０１０１３は、組織情報・様式・既存の型を保存するサーバ０１００１から、組織情報を取得し、組織情報の組織階層情報から、決裁後権限要素を持つ実施者要素に書かれたユーザＩＤを特定する。【０１７９】  書類検索部０１０１３は、組織階層情報で特定した実施者のユーザＩＤを軸に、当該実施者の決裁後権限要素の対象部門要素に記述された相対的に対象部門を特定するキーワードを用いて、具体的な部門ＩＤを特定する。相対的に対象部門を特定するキーワードとは、例えば、“ｓｅｌｆ”であれば、実施者の所属部門、“ｃｈｉｌｄ”であれば、一つ下位の部門、“ａｎｃｅｓｔｏｒ”であれば上位の部門すべてを示す。【０１８０】  次に、書類検索部０１０１３は、決裁後権限要素の対象ユーザ要素に記述された対象メンバーの種類を示すキーワードと、特定した部門ＩＤから、最終的に参照権限を持ったユーザＩＤのリストを特定する。対象メンバーの種類を示すキーワードとは、例えば“ｈｅａｄ”であれば、部門の長を、“ｍｅｍｂｅｒ”であれば、部門のメンバーを示す。【０１８１】  この処理は、処理速度に問題がなければ、検索の度に行ってもよいし、書類ごとに事前に求めておいてもよい。【０１８２】  書類検索画面０１０１９は、検索条件を書類検索部０１０１３へ送信する。書類検索部０１０１３は、書類の承認経路要素に対して検索を実行し、���当書類を特定する。書類検索部０１０１３は該当書類の一覧を、書類検索画面０１０１９へ返す。書類検索画面０１０１９は該当書類の一覧を表示する。【０１８３】２−５−２．書類の表示
利用者が、該当書類の一覧から削除対象の書類を選択すると、書類参照画面０１０２２が表示される。このとき書類検索画面０１０１９からは書類の識別子が渡される。書類参照画面０１０２２は書類参照部０１０１４へユーザＩＤと書類の識別子を渡す。書類参照部０１０１４は、書類を保存するサーバ０１０１７から、書類の識別子で特定される書類を取得し、権限の確認を行う。書類参照部０１０１４が確認する権限の条件は、書類を検索する場合の条件と同じく、以下のいずれかである。【０１８４】  ・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の予定者要素に自身のユーザＩＤが存在し、当該起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素に値“ｄｅｌｅｔｅ”がある。【０１８５】  ・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ｄｅｌｅｔｅ”があり、当該承認者要素の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。【０１８６】  ・承認経路要素に却下要素、又は、削除要素が無く、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者の実施者要素が空であり、当該最終決裁者の所有時権限要素に値“ｄｅｌｅｔｅ”があり、当該最終決裁者の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。【０１８７】  ・承認経路要素に削除要素が無く、すべての実施者要素が値を持ち、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素に値“ｄｅｌｅｔｅ”があり、決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。【０１８８】  ・承認経路要素に削除要素が無く、承認経路要素に却下要素があり、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素に値“ｄｅｌｅｔｅ”があり、決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。【０１８９】  最後の二つの条件については、確認のために組織情報が必要であるから、組織情報・様式・既存の型を保存するサーバ０１００１から組織情報を取得して判定を行う。【０１９０】  書類参照部０１０１４は、組織情報・様式・既存の型を保存するサーバ０１００１から、組織情報を取得し、組織情報の組織階層情報から、決裁後権限要素を持つ実施者要素に書かれたユーザＩＤを特定する。【０１９１】  書類参照部０１０１４は、組織階層情報で特定した実施者のユーザＩＤを軸に、当該実施者の決裁後権限要素の対象部門要素に記述された相対的に対象部門を特定するキーワードを用いて、具体的な部門ＩＤを特定する。相対的に対象部門を特定するキーワードとは、例えば、“ｓｅｌｆ”であれば、実施者の所属部門、“ｃｈｉｌｄ”であれば、一つ下位の部門、“ａｎｃｅｓｔｏｒ”であれば上位の部門すべてを示す。【０１９２】  次に、書類参照部０１０１４は、決裁後権限要素の対象ユーザ要素に記述された対象メンバーの種類を示すキーワードと、特定した部門ＩＤから、最終的に参照権限を持ったユーザＩＤのリストを特定する。対象メンバーの種類を示すキーワードとは、例えば“ｈｅａｄ”であれば、部門の長を、“ｍｅｍｂｅｒ”であれば、部門のメンバーを示す。【０１９３】  書類参照部０１０１４は、参照画面から渡された、参照を行おうとしているユーザＩＤが、上記方法で割り出した参照権限を持ったユーザＩＤのリストに含まれれば、書類を参照可能と判断する。【０１９４】  権限に問題がなければ、書類承認部０１０１２は、取得した書類を書類承認画面０１０２１に返却し、書類承認画面０１０２１は返却されたＸＭＬ形式の書類をＨＴＭＬに変換し表示する。【０１９５】２−５−３．削除の実施
利用者は、書類を参照し、削除対象の書類であることを確認し、書類参照画面０１０２２に備えられた削除ボタンを押下する。書類参照画面０１０２２は、書類の識別子、利用者のユーザＩＤ、及び、削除を意味するフラグを引数に、書類削除部０１０１５を呼び出す。【０１９６】  書類削除部０１０１５は、書類を検索する際の条件、及び、書類参照部０１０１４が確認する条件と同じ条件で確認を行う。削除を実施できる条件は、以下のいずれかである。【０１９７】  ・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の予定者要素に自身のユーザＩＤが存在し、当該起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素に値“ｄｅｌｅｔｅ”がある。【０１９８】  ・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ｄｅｌｅｔｅ”があり、当該承認者要素の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。【０１９９】  ・承認経路要素に却下要素、又は、削除要素が無く、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者の実施者要素が空であり、当該最終決裁者の所有時権限要素に値“ｄｅｌｅｔｅ”があり、当該最終決裁者の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。【０２００】  ・承認経路要素に削除要素が無く、すべての実施者要素が値を持ち、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素に値“ｄｅｌｅｔｅ”があり、決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。【０２０１】  ・承認経路要素に削除要素が無く、承認経路要素に却下要素があり、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素に値“ｄｅｌｅｔｅ”があり、決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。【０２０２】  最後の二つの条件については、確認のために組織情報が必要であるから、組織情報・様式・既存の型を保存するサーバ０１００１から組織情報を取得して判定を行う。【０２０３】  書類削除部０１０１５は、組織情報・様式・既存の型を保存するサーバ０１００１から、組織情報を取得し、組織情報の組織階層情報から、決裁後権限要素を持つ実施者要素に書かれたユーザＩＤを特定する。【０２０４】  書類削除部０１０１５は、組織階層情報で特定した実施者のユーザＩＤを軸に、当該実施者の決裁後権限要素の対象部門要素に記述された相対的に対象部門を特定するキーワードを用いて、具体的な部門ＩＤを特定する。相対的に対象部門を特定するキーワードとは、例えば、“ｓｅｌｆ”であれば、実施者の所属部門、“ｃｈｉｌｄ”であれば、一つ下位の部門、“ａｎｃｅｓｔｏｒ”であれば上位の部門すべてを示す。【０２０５】  次に、書類削除部０１０１５は、決裁後権限要素の対象ユーザ要素に記述された対象メンバーの種類を示すキーワードと、特定した部門ＩＤから、最終的に参照権限を持ったユーザＩＤのリストを特定する。対象メンバーの種類を示すキーワードとは、例えば“ｈｅａｄ”であれば、部門の長を、“���ｅｍｂｅｒ”であれば、部門のメンバーを示す。【０２０６】  書類削除部０１０１５は、参照画面から渡された、参照を行おうとしているユーザＩＤが、上記方法で割り出した参照権限を持ったユーザＩＤのリストに含まれれば、書類を削除する権限を有していると判断する。【０２０７】  権限に問題がなければ、当該ユーザの実施者要素に削除したユーザの所属部門ＩＤを内容にした部門要素０１０８０、削除したユーザのユーザＩＤを内容にしたユーザ要素０１０８１、削除した日時を内容にした日時要素０１０８２、削除した旨を意味する削除要素０１０８８を追加し、書類を保存するサーバ０１０１７に保存されている書類を更新する。【０２０８】  ２−６．  参照
次に、書類の参照を行う際の処理手順について、説明する。【０２０９】  ２−６−１．書類の検索
利用者は、書類検索画面０１０１９を表示し、書類の検索を行う。【０２１０】    書類検索画面０１０１９は、検索条件を書類検索部０１０１３へ送信する。書類検索部０１０１３は、書類の承認経路要素に対して検索を実行し、該当書類を特定する。
自身が参照できる書類を検索する条件は、以下のいずれかである。【０２１１】  ・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の予定者要素に自身のユーザＩＤが存在し、当該起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素に値がある。【０２１２】  ・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値があり、当該承認者要素の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。【０２１３】  ・承認経路要素に却下要素、又は、削除要素が無く、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者の実施者要素が空であり、当該最終決裁者の所有時権限要素に値があり、当該最終決裁者の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。【０２１４】  ・すべての実施者要素が値を持つか、又は、承認経路要素に却下要素があり、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。【０２１５】  最後の条件については、所属部門、及び、所属メンバーが示す範囲を求めるために組織情報が必要であるから、組織情報・様式・既存の型を保存するサーバ０１００１から組織情報を取得して判定を行う。書類検索部０１０１３は、組織情報・様式・既存の型を保存するサーバ０１００１から、組織情報を取得し、組織情報の組織階層情報から、決裁後権限要素を持つ実施者要素に書かれたユーザＩＤを特定する。【０２１６】  書類検索部０１０１３は、組織階層情報で特定した実施者のユーザＩＤを軸に、当該実施者の決裁後権限要素の対象部門要素に記述された相対的に対象部門を特定するキーワードを用いて、具体的な部門ＩＤを特定する。相対的に対象部門を特定するキーワードとは、例えば、“ｓｅｌｆ”であれば、実施者の所属部門、“ｃｈｉｌｄ”であれば、一つ下位の部門、“ａｎｃｅｓｔｏｒ”であれば上位の部門すべてを示す。【０２１７】  次に、書類検索部０１０１３は、決裁後権限要素の対象ユーザ要素に記述された対象メンバーの種類を示すキーワードと、特定した部門ＩＤから、最終的に参照権限を持ったユーザＩＤのリストを特定する。対象メンバーの種類を示すキーワードとは、例えば“ｈｅａｄ”であれば、部門の長を、“ｍｅｍｂｅｒ”であれば、部門のメンバーを示す。【０２１８】  この処理は、処理速度に問題がなければ、検索の度に行ってもよいし、書類ごとに事前に求めておいてもよい。【０２１９】  値“ｒｅａｄ”以外の権限についても、各操作を行うためには参照が必要であるため、参照権限があると判断する。【０２２０】  なお、書類検索画面Ｘ０１５３は上記条件に加えて、日付や書類名などで、さらに絞り込む機能を持たせてもよい。【０２２１】  書類検索部０１０１３は該当書類の一覧を、書類検索画面０１０１９へ返す。書類検索画面０１０１９は該当書類の一覧を表示する。【０２２２】  ２−６−２．書類参照画面の表示
利用者が、該当書類の一覧から承認対象の書類を選択すると、書類参照画面０１０２２が表示される。このとき書類検索画面０１０１９からは書類の識別子が渡される。書類参照画面０１０２２は書類参照部０１０１４へ利用者のユーザＩＤと書類の識別子を渡す。【０２２３】  ２−６−３．書類の所有者と権限の確認
書類参照部０１０１４は、書類を保存するサーバ０１０１７から、書類の識別子で特定される書類を取得し権限の確認を行う。権限を確認するための条件は、書類を検索する場合の条件と同じく、以下のいずれかである。【０２２４】  ・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の予定者要素に自身のユーザＩＤが存在し、当該起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素に値がある。【０２２５】  ・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値があり、当該承認者要素の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。【０２２６】  ・承認経路要素に却下要素、又は、削除要素が無く、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者の実施者要素が空であり、当該最終決裁者の所有時権限要素に値があり、当該最終決裁者の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。【０２２７】  ・すべての実施者要素が値を持つか、又は、承認経路要素に却下要素があり、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。【０２２８】  最後の条件については、確認のために組織情報が必要であるから、組織情報・様式・既存の型を保存するサーバ０１００１から組織情報を取得して判定を行う。【０２２９】  書類参照部０１０１４は、組織情報・様式・既存の型を保存するサーバ０１００１から、組織情報を取得し、組織情報の組織階層情報から、決裁後権限要素を持つ実施者要素に書かれたユーザＩＤを特定する。【０２３０】  書類参照部０１０１４は、組織階層情報で特定した実施者のユーザＩＤを軸に、当該実施者の決裁後権限要素の対象部門要素に記述された相対的に対象部門を特定するキーワードを用いて、具体的な部門ＩＤを特定する。相対的に対象部門を特定するキーワードとは、例えば、“ｓｅｌｆ”であれば、実施者の所属部門、“ｃｈｉｌｄ”であれば、一つ下位の部門、“ａｎｃｅｓｔｏｒ”であれば上位の部門すべてを示す。【０２３１】  次に、書類参照部０１０１４は、決裁後権限要素の対象ユーザ要素に記述された対象メンバーの種類を示すキーワードと、特定した部門ＩＤから、最終的に参照権限を持ったユーザＩＤのリストを特定する。対象メンバーの種類を示すキーワードとは、例えば“ｈｅａｄ”であれば、部門の長を、“ｍｅｍｂｅｒ”であれば、部門のメンバーを示す。【０２３２】  書類参照部０１０１４は、参照画面から渡された、参照を行おうとしているユーザＩＤが、上記方法で割り出した参照権限を持ったユーザＩＤのリストに含まれれば、書類を参照する権限を有していると判断する。【０２３３】  ２−６−４．書類の表示
書類参照部０１０１４は、権限の確認に問題がなければ、書類参照画面０１０２２へ当該書類を返却する。書類参照画面０１０２２は、返却されたＸＭＬ形式の書類をＨＴＭＬへ変換して表示する。【０２３４】３．  権限のまとめ
処理の流れで説明した各処理における、権限の確認方法について図２７、２８にまとめる。【０２３５】  権限の確認は、ＷＥＢサーバ０１０２３の各画面が、対応するボタンを表示するかしないかを判断する場合や、アプリケーションサーバ０１０１６の各部が実際に処理を行ってよいかどうかを判断する場合に行われる。【０２３６】  なお、ハードウェアの構成について、本実施例では複数台のサーバとして記載しているが、もちろん単体のサーバとして実装してもよく、また、複数の筐体で構成することを否定するものではない。
【実施例２】
【０２３７】  実施例１において使用する、組織情報記述言語の一例を述べる。【０２３８】  組織情報はユーザ情報と組織階層情報で構成される。【０２３９】  ユーザ情報は、ユーザの識別子、氏名、役職のリストである。組織階層情報は組織を構成する部門の階層構造と、各部門に所属するユーザを定義する。部門には必ず部門を代表するユーザが一人存在する。ユーザの階層構造とせず、部門の階層構造とし、部門にユーザを所属させる構造としたことが特徴である。【０２４０】  以下に組織情報を定義する専用言語一例を示す。【０２４１】１．ユーザ情報
まず、ユーザ情報は以下の文法とする。
Ｕｓｅｒｓ｛
ユーザ０２００１
ユーザ０２００１
｝
ユーザ０２００１はユーザ一人の情報で、複数記述できる。
ユーザ０２００１は次のような構成になる。
Ｕｓｅｒ（ユーザ識別子０２００２）｛
Ｎａｍｅ：氏名０２００３
Ｐｏｓｔ：役職０２００４
Ｐａｓｓｗｏｒｄ：パスワード０２００５
｝【０２４２】  ユーザ識別子０２００２はユーザの識別子である。ユーザ情報内でユニークである必要がある。【０２４３】  氏名０２００３はユーザの氏名である。【０２４４】  役職０２００４はユーザの役職である。複数記述することができる。【０２４５】  ユーザ情報の記述例を図２９に示す。【０２４６】２．組織階層情報
次に組織階層情報は以下の文法とする。
Ｏｒｇａｎｉｚａｔｉｏｎ｛
部門０２００６
｝【０２４７】  部門０２００６は部門一つの情報で、最上位では一つ記述できる。【０２４８】  部門０２００６は次のような構成になる。
Ｓｅｃｔｉｏｎ（部門識別子０２００７）｛
Ｓｅｃｔｉｏｎ−ｎａｍｅ：部門名０２００８
Ｈｅａｄ：部門の長０２００９
Ｍｅｍｂｅｒ：所属メンバー０２０１０
権限の定義０２０１１
部門０２００６
スタッフ部門０２０１２
｝【０２４９】  部門識別子０２００７は部門の識別子である。組織階層情報の中でユニークである必要がある。【０２５０】  部門名０２００８は部門の名前である。【０２５１】  部門の長０２００９は、部門の長である。ユーザ情報で定義されたユーザ識別子を記述する。【０２５２】  所属メンバー０２０１０は部門に所属するユーザである。ユーザ情報で定義されたユーザ識別子を記述する。複数記述することができる。【０２５３】  部門０２００６は、当該部門の下位の部門である。複数記述することができる。【０２５４】  スタッフ部門０２０１２は、スタッフ部門である。スタッフ部門０２０１２は次のような構成になる。構成する各要素は、部門０２００６と同様である。
Ｓｔａｆｆ−Ｓｅｃｔｉｏｎ（部門識別子０２００７）｛
Ｓｅｃｔｉｏｎ−ｎａｍｅ：部門名０２００８
Ｈｅａｄ：部門の長０２００９
Ｍｅｍｂｅｒ：所属メンバー０２０１０
権限の定義０２０１１
部門０２００６
スタッフ部門０２０１２
｝【０２５５】  権限の定義０２０１１は、書類の権限を記述する。【０２５６】  権限の定義０２０１１は、次のように記述する。承認権限の定義０２０１３、所有時の権限定義０２０１４、最終決裁後の権限定義０２０１５がそれぞれ０回以上記述できる。
ｐｅｒｍｉｓｓｉｏｎ｛
承認権限の定義０２０１３
所有時の権限定義０２０１４
最終決裁後の権限定義０２０１５
｝【０２５７】  承認権限の定義０２０１３は、承認時に実行可能な操作を記述する。
ａｐｐｒｏｖａｌ−ｐｅｒｍｉｓｓｉｏｎ：（承認操作０２０１６，…，承認操作０２０１６），所有者の種類０２０１７
承認操作０２０１６は、キーワード“ｆｏｒｗａｒｄ”、“ｒｅｊｅｃｔ”、“ｒｅｔｕｒｎ”、“ｓｋｉｐ”、“ｇｅｔｂａｃｋ”のいずれかが記述できる。“ｆｏｒｗａｒｄ”は提出、承認、又は決裁を、“ｒｅｊｅｃｔ”は却下を、“ｒｅｔｕｒｎ”は差戻しを、“ｓｋｉｐ”は飛ばし承認（強制承認）、又は、飛ばし決裁（強制決裁）を、“ｇｅｔｂａｃｋ”は取戻しを意味する。【０２５８】  所有時の権限定義０２０１４は、書類の所有者の権限を記述する。
ｏｗｎｅｒ−ｐｅｒｍｉｓｓｉｏｎ：（権限０２０１８，…，権限０２０１８），所有者の種類０２０１７
権限０２０１８は、キーワード“ｒｅａｄ”、“ｗｒｉｔｅ”、“ｄｅｌｅｔｅ”、“ａｐｐｒｏｖａｌ”が記述できる。“ｒｅａｄ”は参照権限を、“ｗｒｉｔｅ”は変更権限を、“ｄｅｌｅｔｅ”は削除権限を、“ａｐｐｒｏｖａｌ”は承認権限を意味する。承認操作０２０１６は、“ａｐｐｒｏｖａｌ”が記述されている場合のみ有効である。【０２５９】  所有者の種類０２０１７は、キーワード“ｃｒｅａｔｏｒ”、“ａｐｐｒｏｖｅｒ”、“ｌａｓｔ−ａｐｐｒｏｖｅｒ”を記述できる。“ｃｒｅａｔｏｒ”は書類の作成者を、“ａｐｐｒｏｖｅｒ”は承認者を、“ｌａｓｔ−ａｐｐｒｏｖｅｒ”は最終決裁者を意味する。【０２６０】  最終決裁後の権限定義０２０１５は、最終決裁後の書類の権限を記述する。
ａｐｐｒｏｖｅｄ−ｐｅｒｍｉｓｓｉｏｎ：（権限０２０１９，…，権限０２０１９），所有者の種類０２０１７，対象部門０２０２０，対象ユーザ０２０２１【０２６１】  権限０２０１９は、キーワード“ｒｅａｄ”、“ｗｒｉｔｅ”、“ｄｅｌｅｔｅ”が記述できる。“ｒｅａｄ”は参照権限を、“ｗｒｉｔｅ”は変更権限を、“ｄｅｌｅｔｅ”は削除権限を意味する。【０２６２】  対象部門０２０２０は、書類の所有者を軸に相対的に部門の範囲を指定する。対象部門０２０２０は、キーワード“ａｌｌ”、“ｓｅｌｆ”、“ｐａｒｅｎｔ”、“ｃｈｉｌｄ”、“ｂｒｏｔｈｅｒ”、“ａｎｃｅｓｔｏｒ”、“ｄｅｓｃｅｎｄａｎｔ”を記述できる。“ａｌｌ”は全部門を、“ｓｅｌｆ”は所有者の所属部門を、“ｐａｒｅｎｔ”は所有者の所属部門の一つ上位の部門を、“ｃｈｉｌｄ”は所有者の所属部門の一つ下位の部門すべてを、“ｂｒｏｔｈｅｒ”は所有者の所属部門と上位部門を同じとする同会層の部門を、“ａｎｃｅｓｔｏｒ”は所有者の所属部門の上位全ての部門を、“ｄｅｓｃｅｎｄａｎｔ”は所有者の所属部門の下位全ての部門を意味する。【０２６３】  対象ユーザ０２０２１は、対象部門０２０２０で指定した部門において、部門に所属するユーザの種類を指定する。対象ユーザ０２０２１は、キーワード“ｓｅｌｆ”、“ｈｅａｄ”、“ｍｅｍｂｅｒ”、“ａｌｌ”を記述できる。“ｓｅｌｆ”は所有者自信を、“ｈｅａｄ”は部門の長を、“ｍｅｍｂｅｒ”は部門に所属するメンバーを、“ａｌｌ”は長とメンバー両方を意味する。【０２６４】  組織階層情報の記述例を図３０に示す。
【実施例３】
【０２６５】  実施例１において使用する、様式記述言語の一例を述べる。【０２６６】  様式は以下のような文法で定義する。
Ｔｅｍｐｌａｔｅ（様式名０３００１）｛
Ｏｗｎｅｒ：様式所有者０３００２
Ｔｙｐｅ｛
型定義部０３００３
｝
Ｓｔｒｕｃｔｕｒｅ｛
文書構造定義部０３００４
｝
Ａｐｐｒｏｖａｌ｛
承認経路定義部０３００５
｝
Ｐｅｒｍｉｓｓｉｏｎ｛
権限定義部０３００６
｝
｝【０２６７】  様式名０３００１は様式の識別子になる。【０２６８】  様式所有者０３００２は、この様式の作成者である。【０２６９】  様式所有者０３００２は、部門の識別子と、ユーザの識別子で構成される。部門の識別子とユーザの識別子については実施例２で述べる。【０２７０】  型定義部０３００３には実施例４、実施例７、及び、実施例９で示す、型の定義を記述する。【０２７１】  文書構造定義部０３００４には実施例４、実施例７、及び、実施例９で示す、文書構造の定義を記述する。【０２７２】  承認経路定義部０３００５には実施例５で示す、承認経路の定義を記述する。
権限定義部０３００６には実施例６で示す、権限の定義を記述する。【０２７３】  様式の記述例を図３１に示す。
【実施例４】
【０２７４】  実施例１における、様式に記述される型、及び、文書構造の定義をするための専用言語の詳細を述べる。【０２７５】  型の定義は以下のように行う。
型名０４００１：型の定義０４００２【０２７６】  型名０４００１は、型の名前である。様式内でユニークである必要がある。【０２７７】  型の定義０４００２は、型の定義を行う。型の定義には、正規表現型０４００３、列挙型０４００４、型名０４００５が記述できる。【０２７８】  正規表現型０４００３は次のように記述する。
型名０４００１：［“正規表現０４００６”］【０２７９】  正規表現０４００６は正規表現を記述する。【０２８０】  列挙型０４００４は次のように記述する。
型名０４００１：（列挙値０４００７，列挙値０４００７，…列挙値０４００７）【０２８１】  列挙値０４００７は、テキスト値、ＮＵＬＬ記号、又は型名を、カンマで区切って複数個記述する。テキスト値を記述する場合は、ダブルクォートで囲う。【０２８２】  次のように型の定義として型名を記述した場合、型に別名を付けたことになる。
型名０４００１：型名０４００５【０２８３】  また、次のようにスペースで区切って複数の型名を記述することも可能である。
型名０４００１：型名０４００５  型名０４００５  型名０４００５【０２８４】  この場合、型を組み合わせた、新しい型を定義したことになる。これは、例えばテキストボックスを３つ並べた、電話番号入力項目を定義したい場合等に用いる。【０２８５】  文書構造の定義は以下のように行う。
項目名０４００８：型０４００９【０２８６】  項目名０４００８は、書類の項目名である。複数並べて記述することで、文書構造を定義する。項目名０４００８様式中でユニークである必要がある。【０２８７】  型０４００９は、型名０４０１０、又は、型の定義０４００２を記述できる。型名０４０１０は型定義部で定義した型名か、システムで事前に用意した型があればその型名を記述できる。【０２８８】  図３２に型、及び、文書構造の定義の一例を示す。
【実施例５】
【０２８９】  様式に記述される承認経路の定義をするための専用言語の詳細を述べる。【０２９０】  承認経路の定義には、起案可能０５００１、起案不可０５００２、承認不要部門０５００３、スタッフ部門承認０５００４、承認ポリシー０５００５がそれぞれ０回以上記述できる。
Ａｐｐｒｏｖａｌ  ｛
起案可能０５００１
起案不可０５００２
承認不要部門０５００３
スタッフ部門承認０５００４
｝【０２９１】  起案可能０５００１はこの様式から書類を作成できるユーザを指定する。起案可能０５００１は次のように記述する。
ａｌｌｏｗ−ｃｒｅａｔｅ：対象部門０５００６，ユーザ範囲０５００７【０２９２】  対象部門０５００６は、部門を指定する。対象部門０５００６は、部門の識別子か、キーワード”ｓｅｌｆ”、“ｃｈｉｌｄ”、“ｄｅｓｃｅｎｄａｎｔ”、“ｂｏｔｔｏｍ”を記述できる。”ｓｅｌｆ”は、様式の所有者が所属する部門を指し示す。“ｃｈｉｌｄ”は様式の所有者の所属する部門の一つ下位の部門を指し示す。”ｄｅｓｃｅｎｄａｎｔ”は様式の所有者が所属する部門の下位の部門すべてを指し示す。“ｂｏｔｔｏｍ”は様式の所有者が所属する部門から見て、組織階層の最下層になる部門を指し示す。【０２９３】  ユーザ範囲０５００７は、部門に所属するユーザの範囲を指定する。ユーザ範囲０５００７は、はキーワード“ｈｅａｄ”、“ｍｅｍｂｅｒ”、“ｂｏｔｈ”が記述できる。”ｈｅａｄ”は部門の長を指し示す。“ｍｅｍｂｅｒ”は部門に所属するメンバーを指し示す。”ｂｏｔｈ”はその両方を指し示す。【０２９４】  もし起案可能０５００１を一つも記述しなかった場合は、「ａｌｌｏｗ−ｃｒｅａｔｅ：ｄｅｓｃｅｎｄａｎｔ，ｂｏｔｈ」が記述されているものとする。つまり様式の所有者の所属する部門の下位の部門すべてに所属する全てのユーザが起案可能となる。【０２９５】  起案不可０５００２はこの様式から書類を作成できないユーザを指定する。起案不可０５００２は次のように記述する。
ｄｅｎｙ−ｃｒｅａｔｅ：対象部門０５００６，ユーザ範囲０５００７【０２９６】  対象部門０５００６、及び、ユーザ範囲０５００７は、起案可能０５００１と同様である。【０２９７】  承認不要部門０５００３は、承認を必要としない部門を指定する。承認不要部門０５００３は、以下のように記述する。
ｄｅｎｙ−ａｐｐｒｏｖａｌ：対象部門０５００６
対象部門０５００６は前述のとおりである。【０２９８】  スタッフ部門承認０５００４は、スタッフ部門による承認の有無を指定する。スタッフ部門承認０５００４は以下のように記述する。
ａｐｐｒｏｖａｌ−ｓｔｕｆｆ−ｓｅｃｔｉｏｎ：対象部門０５００８，対象スタッフ部門０５００９，担当スタッフ部門０５０１０【０２９９】  対象部門０５００８は、スタッフ部門による承認を必要とする部門を指定する。対象部門０５００８は、部門の識別子か、キーワード”ｓｅｌｆ”、“ｃｈｉｌｄ”、“ｂｏｔｔｏｍ”が記述できる。キーワードの説明は前述のとおりである。【０３００】  対象スタッフ部門０５００９は、スタッフ部門の識別子を指定する。【０３０１】  担当スタッフ部門０５０１０は、スタッフ部門の識別子を指定する。担当スタッフ部門０５０１０は、組織階層情報上で対象スタッフ部門０５００９の配下の部門である必要がある。【０３０２】  承認経路の定義の記述例を図３３に示す。
【実施例６】
【０３０３】  様式に記述される権限の定義をするための専用言語の詳細を述べる。【０３０４】  権限の定義は実施例２で示した組織情報の権限の定義と同じである。【０３０５】  権限の定義には、承認権限の定義０２０１３、所有時の権限定義０２０１４、最終決裁後の権限定義０２０１５がそれぞれ０回以上記述できる。
ｐｅｒｍｉｓｓｉｏｎ｛
承認権限の定義０２０１３
所有時の権限定義０２０１４
最終決裁後の権限定義０２０１５
｝【０３０６】  承認権限の定義０２０１３は、承認時に実行可能な操作を記述する。
ａｐｐｒｏｖａｌ−ｐｅｒｍｉｓｓｉｏｎ：（承認操作０２０１６，…，承認操作０２０１６），所有者の種類０２０１７【０３０７】  承認操作０２０１６は、キーワード“ｆｏｒｗａｒｄ”、“ｒｅｊｅｃｔ”、“ｒｅｔｕｒｎ”、“ｓｋｉｐ”、“ｇｅｔｂａｃｋ”のいずれかが記述できる。“ｆｏｒｗａｒｄ”は提出、承認、又は決裁を、“ｒｅｊｅｃｔ”は却下を、“ｒｅｔｕｒｎ”は差戻しを、“ｓｋｉｐ”は飛ばし承認（強制承認）、又は、飛ばし決裁（強制決裁）を、“ｇｅｔｂａｃｋ”は取戻しを意味する。【０３０８】  所有時の権限定義０２０１４は、書類の所有者の権限を記述する。
ｏｗｎｅｒ−ｐｅｒｍｉｓｓｉｏｎ：（権限０２０１８，…，権限０２０１８），所有者の種類０２０１７【０３０９】  権限０２０１８は、キーワード“ｒｅａｄ”、”ｗｒｉｔｅ”、“ｄｅｌｅｔｅ”、“ａｐｐｒｏｖａｌ”が記述できる。“ｒｅａｄ”は参照権限を、“ｗｒｉｔｅ”は変更権限を、“ｄｅｌｅｔｅ”は削除権限を、“ａｐｐｒｏｖａｌ”は承認権限を意味する。承認操作０２０１６は、“ａｐｐｒｏｖａｌ”が記述されている場合のみ有効である。【０３１０】  所有者の種類０２０１７は、キーワード“ｃｒｅａｔｏｒ”、“ａｐｐｒｏｖｅｒ”、“ｌａｓｔ−ａｐｐｒｏｖｅｒ”を記述できる。“ｃｒｅａｔｏｒ”は書類の作成者を、“ａｐｐｒｏｖｅｒ”は承認者を、“ｌａｓｔ−ａｐｐｒｏｖｅｒ”は最終決裁者を意味する。【０３１１】  最終決裁後の権限定義０２０１５は、最終決裁後の書類の権限を記述する。
ａｐｐｒｏｖｅｄ−ｐｅｒｍｉｓｓｉｏｎ：（権限０２０１９，…，権限０２０１９），所有者の種類０２０１７，対象部門０２０２０，対象ユーザ０２０２１【０３１２】  権限０２０１９は、キーワード“ｒｅａｄ”、“ｗｒｉｔｅ”、“ｄｅｌｅｔｅ”が記述できる。“ｒｅａｄ”は参照権限を、“ｗｒｉｔｅ”は変更権限を、“ｄｅｌｅｔｅ”は削除権限を意味する。【０３１３】  対象部門０２０２０は、書類の所有者を軸に相対的に部門の範囲を指定する。対象部門０２０２０は、キーワード“ａｌｌ”、“ｓｅｌｆ”、“ｐａｒｅｎｔ”、“ｃｈｉｌｄ”、“ｂｒｏｔｈｅｒ”、“ａｎｃｅｓｔｏｒ”、“ｄｅｓｃｅｎｄａｎｔ”を記述できる。“ａｌｌ”は全部門を、“ｓｅｌｆ”は所有者の所属部門を、“ｐａｒｅｎｔ”は所有者の所属部門の一つ上位の部門を、“ｃｈｉｌｄ”は所有者の所属部門の一つ下位の部門すべてを、“ｂｒｏｔｈｅｒ”は所有者の所属部門と上位部門を同じとする同会層の部門を、“ａｎｃｅｓｔｏｒ”は所有者の所属部門の上位全ての部門を、“ｄｅｓｃｅｎｄａｎｔ”は所有者の所属部門の下位全ての部門を意味する。【０３１４】  対象ユーザ０２０２１は、対象部門０２０２０で指定した部門において、部門に所属するユーザの種類を指定する。対象ユーザ０２０２１は、キーワード“ｓｅｌｆ”、“ｈｅａｄ”、“ｍｅｍｂｅｒ”、“ａｌｌ”を記述できる。“ｓｅｌｆ”は所有者自信を、“ｈｅａｄ”は部門の長を、“ｍｅｍｂｅｒ”は部門に所属するメンバーを、“ａｌｌ”は長とメンバー両方を意味する。【０３１５】  権限の定義の記述例を図３４に示す。
【実施例７】
【０３１６】  実施例１を拡張し、項目間の値の関係を定義することで、複数項目にまたがるエラーチェック、及び、補完を可能とする方法を述べる。【０３１７】  本発明を実現するために必要な構成要素は実施例１と同様である。【０３１８】１．  専用言語の拡張
まず、型及び文書構造の定義をするための専用言語において、新たに、型を定義する方法として、タプルを使った項目間の値の関係の定義を可能とする。
（型名０７００１，型名０７００１…型名０７００１）：タプルの列挙型０７００２【０３１９】  型名０７００１は定義する型の名前である。カッコでくくり、カンマで区切ることで複数の型名を記述する。【０３２０】  タプルの列挙型０７００２は、以下のようにタプル０７００３を列挙したものになる。
（タプル０７００３，タプル０７００３，…タプル０７００３）【０３２１】  タプル０７００３は、以下のように列挙値０７００４を要素とするタプルである。
（列挙値０７００４，列挙値０７００４，…列挙値０７００４）【０３２２】  型名のタプルと、列挙値のタプルの要素数は同じで、要素の位置は対応している必要がある。つまり、型名のタプルの先頭の型名に対応する列挙値は、列挙値のタプルにおいても先頭である必要がある。【０３２３】  列挙値０７００４は実施例４の場合と同様に、テキスト値、ＮＵＬＬ記号、又は、正規表現型の型名を、カンマで区切って複数個記述する。【０３２４】  図３５に実際に定義した様式の一例を示す。【０３２５】２．  チェックプログラムの生成手順、及び、生成されるプログラムの変更
次に、実施例１の様式コンパイラ０１００２における、チェックプログラムの生成手順、及び、生成されるプログラムを次のように変更する。【０３２６】  実施例１の様式コンパイラ０１００２は、まず、既存の型、及び、様式に記述されたユーザ定義型を用いて、画面からの入力値のリストを引数にとり、入力値を型の定義と比較し、エラー判定結果を返却するチェックプログラムを定義された全ての型について生成する。チェックプログラムの処理内容は以下のようになる。【０３２７】（１）当該型の定義をタプルの列挙を行、タプル内の要素を列とした２次元配列に格納する。
（２）行の数だけ繰り返す。行の添え字はｉとし、初期値は１とする。
（２．１）列の数だけ繰り返す。列の添え字はｊとし、初期値は１とする。
（２．１．１）ｉ番目の行のｊ番目の列がＮＵＬＬ記号の場合。
（２．１．１．１）入力値のｊ番目の値が空の場合。
（２．１．１．１．１）当該行を削除する。
（２．１．２）ｉ番目の行のｊ番目の列がテキスト値の場合。
（２．１．２．１）入力値のｊ番目の値を、当該テキスト値と比較する。
（２．１．２．１．１）比較した結果が同じ場合
（２．１．２．１．１．１）何もしない
（２．１．２．１．２）比較した結果が違う場合
（２．１．２．１．２．１）当該行を削除する。
（２．１．３）ｉ番目の行のｊ番目の列が正規表現型の場合。
（２．１．３．１）入力値のｊ番目の値が当該正規表現にマッチするか確認する。
（２．１．３．１．１）マッチする場合
（２．１．３．１．１．１）何もしない
（２．１．３．１．２）マッチしない場合
（２．１．３．１．２．１）当該行を削除する。
（２．１．４）ｊを１増やす。
（２．２）ｉを１増やす。
（３）２次元配列の行数を確認する。
（３．１）行数が０の場合
（３．１．１）ＮＧを返却する。
（３．２）行数が１以上の場合
（３．２．１）ＯＫを返却する。【０３２８】  なお、この処理内容は、列数ｊを１とすれば、１項目の列挙型についても問題なく動作する。【０３２９】  上記処理内容のフローチャートを図３６に示す。【０３３０】３．  補完プログラムの生成手順、及び、生成される補完プログラムの変更
最後に、実施例１の様式コンパイラ０１００２における、補完プログラムの生成手順、及び、生成される補完プログラムを次のように変更する。【０３３１】  実施例１の様式コンパイラ０１００２は、まず、既存の型、及び、様式に記述されたユーザ定義型を用いて、画面からの入力値のリストを引数にとり、入力値を型の定義と比較し、補完値の２次元配列を返却する補完プログラムを定義された全ての型について生成する。補完プログラムの処理内容は以下のようになる。【０３３２】（１）当該型の定義をタプルの列挙を行、タプル内の要素を列とした２次元配列に格納する。
（２）行の数だけ繰り返す。行の添え字はｉとし、初期値は１とする。
（２．１）列の数だけ繰り返す。列の添え字はｊとし、初期値は１とする。
（２．１．１）ｉ番目の行のｊ番目の列がＮＵＬＬ記号の場合。
（２．１．１．１）入力値のｊ番目の値が空の場合。
（２．１．１．１．１）当該行を削除する。
（２．１．２）ｉ番目の行のｊ番目の列がテキスト値の場合。
（２．１．２．１）入力値のｊ番目の値を、当該テキスト値と比較する。
（２．１．２．１．１）比較した結果が同じ場合
（２．１．２．１．１．１）何もしない
（２．１．２．１．２）比較した結果が違う場合
（２．１．２．１．２．１）当該行を削除する。
（２．１．３）ｉ番目の行のｊ番目の列が正規表現型の場合。
（２．１．３．１）入力値のｊ番目の値が当該正規表現にマッチするか確認する。
（２．１．３．１．１）マッチする場合
（２．１．３．１．１．１）何もしない
（２．１．３．１．２）マッチしない場合
（２．１．３．１．２．１）当該行を削除する。
（２．１．４）ｊを１増やす。
（２．２）ｉを１増やす。
（３）２次元配列を返却する。【０３３３】  この処理内容についても、列数ｊを１とすれば、１項目の列挙型についても問題なく動作する。【０３３４】  上記処理内容のフローチャートを図３７に示す。
【実施例８】
【０３３５】  実施例１、及び、実施例７を拡張し、複数項目にまたがるエラーチェックと同時に単項目のエラーチェックを行う方法を述べる。【０３３６】  本実施例を実現するために必要な構成要素は実施例１と同様である。また、使用する専用言語は実施例１に実施例７を適用したものと同様である。【０３３７】  実施例７において、複数項目のエラーチェックを行う方法を述べたが、実施例７の方法では、複数項目で定義した型について、単項目でのエラー判定を行うことができない。【０３３８】  このような課題を解決するために、単項目の型の定義についても、チェックプログラムを生成するようにする。例えば、型の定義が（型名１、型名２、型名３）：（（値１１、値１２、値１３），（値２１、値２２、値２３），…（値ｎ１、値ｎ２、値ｎ３））となっていた場合、型（型名１、型名２、型名３）だけでなく、型名１、型名２、型名３についても、チェックプログラムを生成する。【０３３９】  実施例１の様式コンパイラ０１００２が、複数項目にまたがる列挙型の定義から、チェックプログラムを生成する際、まず、複数項目にまたがる列挙型を単項目に分解する。これは、同一列の型名と列挙値だけの型定義を生成し、列挙値に同一の値があった場合は集約を行うことで、作成できる。【０３４０】  次に、既存の型、様式に記述されたユーザ定義型、及び、複数項目にまたがる列挙型を単項目に分解した型を用いて、画面からの入力値のリストを引数にとり、入力値を型の定義と比較し、エラー判定結果を返却するチェックプログラムを既存の型、様式に記述されたユーザ定義型、及び、複数項目にまたがる列挙型を単項目に分解した型の数だけ作成する。チェックプログラムの処理内容は実施例７と同様である。【０３４１】  実施例１の書類入力画面０１０２０は、エラーチェックプログラムの結果を画面に表示する際、単項目のチェック結果と、複数項目のチェック結果をそれぞれ表示したり、エラー結果をテキストボックスや文字の色を警告色にすることで示す場合に、複数項目のチェックでエラーとなっても、単項目のチェックでエラーとならなければ、テキストボックスや文字の色を警告色に変更しなかったりと、より利用者に分かりやすい形でエラーを表示できる。
【実施例９】
【０３４２】  実施例１、及び実施例７を拡張し、項目に入力可能な値、及び／又は、項目間の値の関係を外部データベースに保存することで、外部データベースの値を列挙値として利用することを可能とする方法を述べる。【０３４３】  １．  システム構成の変更
実施例１の構成要素に加え、新たに外部データベース接続サーバ０９００１と、外部データベース接続インターフェース０９００２を用意する。【０３４４】  外部データベース接続インターフェース０９００２は、ＪＤＢＣやＯＤＢＣのような、データベース接続のインターフェース製品を用いて実現する。利用者は、あらかじめ利用する外部データベースを外部データベース接続インターフェース０９００２に登録しておく。【０３４５】  ２．  専用言語の変更
また、様式記述言語の型定義部を次のように拡張する。【０３４６】  外部データベースを使った型の定義は以下のように行う。
一番単純な方法は、次のように列挙型の代わりに外部データベース参照０９００４を記述する方法である。
型名０９００３：外部データベース参照０９００４【０３４７】  列挙型の列挙値として外部データベース参照０９００４を記述することもできる。
型名０９００３：（外部データベース参照，列挙値１，…，列挙値ｎ）【０３４８】  また、複数項目にまたがった場合も、以下のように記述できる。
（型名０９００３１，…，型名０９００３Ｎ）：外部データベース参照０９００４
又は、
（型名０９００３１，…，型名０９００３Ｎ）：（外部データベース参照０９００４，（列挙値１１，…，列挙値１Ｎ），…，（列挙値ｎ１，…，列挙値ｎＮ））【０３４９】  さらに、タプルの一部として外部データベース参照０９００４を記述することもできる。
（型名０９００３１，型名０９００３２，…，型名０９００３Ｎ）：（（列挙値１１，列挙値２１，外部データベース参照０９００４），（列挙値１２，列挙値２２，外部データベース参照０９００４））【０３５０】  いずれの場合も、外部データベース参照０９００４は、
＠外部データベース（“接続文字列０９００５”，”検索クエリ０９００６”）
と記述する。【０３５１】  接続文字列０９００５は、ＪＤＢＣまたはＯＤＢＣの接続文字列とする。【０３５２】  検索クエリ０９００６は、ＳＱＬ文とする。
ＳＱＬ文のＳＥＬＥＣＴ句には“＊”（アスタリスク）は記述できないものとする。【０３５３】  また、ＳＱＬ文の中では型名変数０９００７が記述できる。
型名変数０９００７は、
＄型名
のように記述する。
型名変数０９００７は、ＳＱＬ実行前に、対応する型に対して実際に入力した値に置き換えられる。【０３５４】  なお、ＳＱＬの実行結果の列数（タプルの一部として記述した場合は、ＳＱＬの実行結果の列数と要素数の合計）は、型の要素数と同じである必要がある。【０３５５】  外部データベース参照０９００４は、接続文字列０９００５とＳＱＬ文を使って、外部データベース接続インターフェース０９００２経由で取得した値が代入されることを意味する。【０３５６】  例えば、都道府県名が格納された“都道府県マスタ”テーブルが外部データベースにあったとし、
都道府県：＠外部データベース（″ｊｄｂｃ：ｐｏｓｔｇｒｅｓｑｌ：ｈｅｌｌｏｄｂ″，″ＳＥＬＥＣＴ  ｐｒｅｆｅｃｔｕｒｅｓ  ＦＲＯＭ′都道府県マスタ′″）
のように記述すると、
都道府県：（“北海道”，”青森県”，…，”沖縄県”）
と記述した場合と同じになる。【０３５７】  ここで、“都道府県マスタ”にはない”全国“という値を列挙値として含めたければ、
都道府県：（“全国”，＠外部データベース（″ｊｄｂｃ：ｐｏｓｔｇｒｅｓｑｌ：ｈｅｌｌｏｄｂ″，″ＳＥＬＥＣＴ  ｐｒｅｆｅｃｔｕｒｅｓ  ＦＲＯＭ′都道府県マスタ′″））
のように記述する。【０３５８】  都道府県名と対応する市町村名が格納された“市町村マスタ”テーブルが外部データベースにあったとすると、
（都道府県，市町村）：＠外部データベース（″ｊｄｂｃ：ｐｏｓｔｇｒｅｓｑｌ：ｈｅｌｌｏｄｂ″，″ＳＥＬＥＣＴ  ｐｒｅｆｅｃｔｕｒｅｓ，ｃｉｔｉｅｓ  ＦＲＯＭ′市町村マスタ′″）
と記述し、
（都道府県，市町村）：（（“北海道”，”札幌市”），（“北海道”，”函館市”），…，（“沖縄県”，”那覇市”））
のようになる。【０３５９】  タプルの一部として記述する場合は、
（都道府県，市町村）：（（“北海道”，＠外部データベース（″ｊｄｂｃ：ｐｏｓｔｇｒｅｓｑｌ：ｈｅｌｌｏｄｂ″，″ＳＥＬＥＣＴ  ｃｉｔｉｅｓ  ＦＲＯＭ′市町村マスタ′ＷＨＥＲＥ  ｐｒｅｆｅｃｔｕｒｅｓ＝‘北海道’″）），（“青森県”，＠外部データベース（″ｊｄｂｃ：ｐｏｓｔｇｒｅｓｑｌ：ｈｅｌｌｏｄｂ″，″ＳＥＬＥＣＴ  ｃｉｔｉｅｓ  ＦＲＯＭ′市町村マスタ′ＷＨＥＲＥ  ｐｒｅｆｅｃｔｕｒｅｓ＝‘青森県’″）））
又は
（都道府県，市町村）：（（“北海道”，＠外部データベース（″ｊｄｂｃ：ｐｏｓｔｇｒｅｓｑｌ：ｈｅｌｌｏｄｂ″，″ＳＥＬＥＣＴ  ｃｉｔｉｅｓ  ＦＲＯＭ′市町村マスタ′ＷＨＥＲＥ  ｐｒｅｆｅｃｔｕｒｅｓ＝‘＄都道府県’）），（“青森県”，＠外部データベース（″ｊｄｂｃ：ｐｏｓｔｇｒｅｓｑｌ：ｈｅｌｌｏｄｂ″，″ＳＥＬＥＣＴ  ｃｉｔｉｅｓ  ＦＲＯＭ′市町村マスタ′ＷＨＥＲＥ  ｐｒｅｆｅｃｔｕｒｅｓ＝‘＄都道府県’″）））
のように記述できる。【０３６０】  型名変数０９００７は、タプルの要素に記述する列挙値に、正規表現型を用いた場合に効果的である。
テキスト：［“．＋”］
（都道府県，市町村）：（（テキスト，＠外部データベース（″ｊｄｂｃ：ｐｏｓｔｇｒｅｓｑｌ：ｈｅｌｌｏｄｂ″，″ＳＥＬＥＣＴ  ｃｉｔｉｅｓ  ＦＲＯＭ′市町村マスタ′ＷＨＥＲＥ  ｐｒｅｆｅｃｔｕｒｅｓ＝‘＄都道府県’″）））
このように記述すれば、都道府県を任意のテキスト入力とし、実際に入力された値で、市町村を取得できる。【０３６１】  ３．  チェックプログラムの生成手順、及び、生成されるプログラムの変更
実施例１の様式コンパイラ０１００２における、チェックプログラムの生成手順、及び、生成されるプログラムを次のように変更する。【０３６２】  実施例１の様式コンパイラ０１００２は、まず、既存の型、及び、様式に記述されたユーザ定義型を用いて、画面からの入力値のリストを引数にとり、入力値を型の定義と比較し、エラー判定結果を返却するチェックプログラムを定義された全ての型について生成する。チェックプログラムの処理内容は以下のようになる。【０３６３】（１）当該型の定義をタプルの列挙を行、タプル内の要素を列とした２次元配列に格納する。
（２）行の数だけ繰り返す。行の添え字はｉとし、初期値は１とする。
（２．１）ｉ番目の行が外部データベース参照でない場合。
（２．１．１）列の数だけ繰り返す。列の添え字はｊとし、初期値は１とする。
（２．１．１．１）ｉ番目の行のｊ番目の列がＮＵＬＬ記号の場合。
（２．１．１．１．１）入力値のｊ番目の値が空の場合。
（２．１．１．１．１．１）当該行を削除する。
（２．１．１．１．２）ｊを１増やす。
（２．１．１．２）ｉ番目の行のｊ番目の列がテキスト値の場合。
（２．１．１．２．１）入力値のｊ番目の値を、当該テキスト値と比較する。
（２．１．１．２．１．１）比較した結果が同じ場合
（２．１．１．２．１．１．１）何もしない
（２．１．１．２．１．２）比較した結果が違う場合
（２．１．１．２．１．２．１）当該行を削除する。
（２．１．１．２．２）ｊを１増やす。
（２．１．１．３）ｉ番目の行のｊ番目の列が正規表現型の場合。
（２．１．１．３．１）入力値のｊ番目の値が当該正規表現にマッチするか確認する。
（２．１．１．３．１．１）マッチする場合
（２．１．１．３．１．１．１）何もしない
（２．１．１．３．１．２）マッチしない場合
（２．１．１．３．１．２．１）当該行を削除する。
（２．１．１．３．２）ｊを１増やす。
（２．１．１．４）ｉ番目の行のｊ番目の列が外部データベース参照の場合。
（２．１．１．４．１）外部データベース参照のＳＱＬ中に変数＄型名がある場合
（２．１．１．４．１．１）＄型名を入力値に置き換える。
（２．１．１．４．２）ＳＱＬのＷＨＥＲＥ句にＡＮＤ条件で対応する列と入力値のイコール条件を追加する。
（２．１．１．４．３）ＳＱＬの実行結果を得る。
（２．１．１．４．４）実行結果の行数を確認する。
（２．１．１．４．４．１）ＳＱＬの結果が１件以上の場合。
（２．１．１．４．４．１．１）何もしない
（２．１．１．４．４．２）ＳＱＬの結果が０件の場合。
（２．１．１．４．４．２．１）当該行を削除する。
（２．１．１．４．５）ｊをＳＱＬの実行結果の列数分増やす。
（２．２）ｉ番目の行が外部データベース参照の場合。
（２．２．１）ＳＱＬのＷＨＥＲＥ句にＡＮＤ条件で対応する列と入力値のイコール条件を追加する。
（２．２．２）ＳＱＬの実行結果を得る。
（２．２．３）実行結果の行数を確認する。
（２．２．３．１）ＳＱＬの結果が１件以上の場合。
（２．２．３．１．１）何もしない
（２．２．３．２）ＳＱＬの結果が０件の場合。
（２．２．３．２．１）当該行を削除する。
（２．２．４）ｊをＳＱＬの実行結果の列数分増やす。
（２．３）ｉを１増やす。
（３）２次元配列の行数を確認する。
（３．１）行数が０の場合
（３．１．１）ＮＧを返却する。
（３．２）行数が１以上の場合
（３．２．１）ＯＫを返却する。【０３６４】  なお、ＳＱＬの実行結果は、エラーの判定は１件以上あれば判断できるので、上限値を設けてもよい。【０３６５】  上記処理内容のフローチャートを図３８、３９に示す。【０３６６】  ４．  補完プログラムの生成手順、及び、生成される補完プログラムの変更
実施例１の様式コンパイラ０１００２における、補完プログラムの生成手順、及び、生成される補完プログラムを次のように変更する。
実施例１の様式コンパイラ０１００２は、まず、既存の型、及び、様式に記述されたユーザ定義型を用いて、画面からの入力値のリストを引数にとり、入力値を型の定義と比較し、補完値の２次元配列を返却する補完プログラムを定義された全ての型について生成する。補完プログラムの処理内容は以下のようになる。【０３６７】（１）当該型の定義をタプルの列挙を行、タプル内の要素を列とした２次元配列に格納する。
（２）行の数だけ繰り返す。行の添え字はｉとし、初期値は１とする。
（２．１）ｉ番目の行が外部データベース参照でない場合。
（２．１．１）列の数だけ繰り返す。列の添え字はｊとし、初期値は１とする。
（２．１．１．１）ｉ番目の行のｊ番目の列がＮＵＬＬ記号の場合。
（２．１．１．１．１）入力値のｊ番目の値が空の場合。
（２．１．１．１．１．１）当該行を削除する。
（２．１．１．１．２）ｊを１増やす。
（２．１．１．２）ｉ番目の行のｊ番目の列がテキスト値の場合。
（２．１．１．２．１）入力値のｊ番目の値を、当該テキスト値と比較する。
（２．１．１．２．１．１）比較した結果が同じ場合
（２．１．１．２．１．１．１）何もしない
（２．１．１．２．１．２）比較した結果が違う場合
（２．１．１．２．１．２．１）当該行を削除する。
（２．１．１．２．２）ｊを１増やす。
（２．１．１．３）ｉ番目の行のｊ番目の列が正規表現型の場合。
（２．１．１．３．１）入力値のｊ番目の値が当該正規表現にマッチするか確認する。
（２．１．１．３．１．１）マッチする場合
（２．１．１．３．１．１．１）何もしない
（２．１．１．３．１．２）マッチしない場合
（２．１．１．３．１．２．１）当該行を削除する。
（２．１．１．３．２）ｊを１増やす。
（２．１．１．４）ｉ番目の行のｊ番目の列が外部データベース参照の場合。
（２．１．１．４．１）外部データベース参照のＳＱＬ中に変数＄型名がある場合
（２．１．１．４．１．１）＄型名を入力値に置き換える。
（２．１．１．４．２）ＳＱＬのＷＨＥＲＥ句にＡＮＤ条件で対応する列と入力値のイコール条件を追加する。
（２．１．１．４．３）ＳＱＬの実行結果を得る。
（２．１．１．４．４）実行結果の行数を確認する。
（２．１．１．４．４．１）ＳＱＬの結果が１件以上の場合。
（２．１．１．４．４．１．１）当該行の内容を実行結果の行数−１行複製し追加する
（２．１．１．４．４．１．２）元の行と複製した行の数だけ繰り返す。添え字はｋとし、初期値は１とする。
（２．１．１．４．４．１．２．１）２次元配列のｋ＋ｉ行目のＳＱＬ文の書かれた列を実行結果のｋ行目の内容で置き換える。
（２．１．１．４．４．１．３）ｉをｋの数だけ増やす。
（２．１．１．４．４．２）ＳＱＬの結果が０件の場合。
（２．１．１．４．４．２．１）当該行を削除する。
（２．１．１．４．５）ｊをＳＱＬの実行結果の列数分増やす。
（２．２）ｉ番目の行が外部データベース参照の場合。
（２．２．１）ＳＱＬのＷＨＥＲＥ句にＡＮＤ条件で対応する列と入力値のイコール条件を追加する。
（２．２．２）ＳＱＬの実行結果を得る。
（２．２．３）実行結果の行数を確認する。
（２．２．３．１）ＳＱＬの結果が１件以上の場合。
（２．２．３．１．１）当該行の内容を実行結果の行数−１行複製し追加する
（２．２．３．１．１．２）元の行と複製した行の数だけ繰り返す。添え字はｌとし、初期値は１とする。
（２．２．３．１．１．２．１）２次元配列のｌ＋ｉ行目のＳＱＬ文の書かれた列を実行結果のｌ行目の内容で置き換える。
（２．２．３．１．１．３）ｉをｌの数だけ数増やす。
（２．２．３．２）ＳＱＬの結果が０件の場合。
（２．２．３．２．１）当該行を削除する。
（２．２．４）ｊをＳＱＬの実行結果の列数分増やす。
（２．３）ｉを１増やす。
（３）２次元配列を返却する。【０３６８】  なお、ＳＱＬの実行結果は、ハードウェアの処理能力メモリサイズを考慮し、実際に画面に表示できる件数を下回らない範囲で、上限値を設けてもよい。【０３６９】  上記処理内容のフローチャートを図４０、４１、４２、４３に示す。
【実施例１０】
【０３７０】  実施例１の入力画面生成方法を拡張し、ラベル、ラジオボタン、チェックボックス、セレクトボックス、及び、コンボボックスを列挙数や列挙値の内容から判断して、生成する方法を述べる。【０３７１】  書類承認画面０１０２１は、書類を表示する際、型の定義を参照し、書類をＨＴＭＬに変換するルールを次のようにする。【０３７２】  型が列挙型で、列挙数が１の場合、これは、利用者は値の選択の余地がないため、ラベルとなる。インプット要素ではなくスパン要素として表示する。【０３７３】  型が列挙型で、列挙値にＮＵＬＬ記号も、正規表現型もない場合、これは、複数の選択値から一つを必ず選ぶことになるため、ラジオボタンか、セレクトボックスとなる。列挙数に閾値を設けるか、レンダリング後の幅を計算し、その幅に閾値を設けるかして、ラジオボタンにするか、セレクトボックスにするか決定する。【０３７４】  型が列挙型で、正規表現型を含む場合、ラジオボタンを列挙数分並べ、さらに、その他を意味するラジオボタンを設け、その他を入力するテキストボックスを作成するか、コンボボックスとする。ラジオボタンにするか、コンボボックスにするかは、同様に閾値を設けて決定する。【０３７５】  型が列挙型で、ＮＵＬＬ記号を含む場合、選択数１のチェックボックスにするか、選択値に“選択しない“を含むセレクトボックスに変換する。チェックボックスにするか、セレクトボックスにするかは、同様に閾値を設けて決定する。【０３７６】  型がＮＵＬＬ記号とテキスト値の２値の列挙型の場合、チェックボックスに変換する。【０３７７】  型がスペースで区切った複数の型で構成され、それぞれの型がＮＵＬＬ記号とテキスト値の２値の列挙型の場合、複数選択可能なチェックボックスに変換する。
【実施例１１】
【０３７８】  実施例１、実施例４、及び、実施例７を拡張し、型に数値範囲の制限を加える方法を説明する。
本実施例を実現するために必要な構成要素は実施例１と同様である。【０３７９】  １．  専用言語の拡張
まず、型を定義する専用言語に、型に制限を加える新しい文法を加える。【０３８０】  型名１１００１：型の定義１１００２  型の制限１１００３【０３８１】  型名１１００１、及び、型の定義１１００２の意味は、実施例４と同じであるが、型の定義１１００２は正規表現型で、数値に変換可能である必要がある。【０３８２】  型の制限１１００３は以下のように記述する。
＠値域（式１１００４，…，式１１００４）【０３８３】  式１１００４には比較演算子“＞”、“＜”、“＞＝”、“＜＝”及び“＝”が記述でき、比較演算子の右辺と左辺に、変数１１００５と数値が記述できる。【０３８４】  変数１１００５は、型に対して実際に入力された値が代入される。
以下のように記述する。
＄型名【０３８５】  例えば、
年齢：［“￥ｄ＋”］＠値域（＄年齢＞＝０，＄＜１５０）
のように記述すれば、０以上、１４９以下の数値となる。【０３８６】  ２．  チェックプログラムの生成手順、及び、生成されるプログラムの変更【０３８７】  次に、実施例１の様式コンパイラ０１００２における、チェックプログラムの生成手順、及び、生成されるプログラムを次のように変更する。【０３８８】  実施例１の様式コンパイラ０１００２は、まず、既存の型、及び、様式に記述されたユーザ定義型を用いて、画面からの入力値のリストを引数にとり、入力値を型の定義と比較し、エラー判定結果を返却するチェックプログラムを定義された全ての型について生成する。チェックプログラムの処理内容は以下のようになる。【０３８９】（１）当該型の定義をタプルの列挙を行、タプル内の要素を列とした２次元配列に格納する。
（２）行の数だけ繰り返す。行の添え字はｉとし、初期値は１とする。
（２．１）列の数だけ繰り返す。列の添え字はｊとし、初期値は１とする。
（２．１．１）ｉ番目の行のｊ番目の列がＮＵＬＬ記号の場合。
（２．１．１．１）入力値のｊ番目の値が空の場合。
（２．１．１．１．１）当該行を削除する。
（２．１．２）ｉ番目の行のｊ番目の列がテキスト値の場合。
（２．１．２．１）入力値のｊ番目の値を、当該テキスト値と比較する。
（２．１．２．１．１）比較した結果が同じ場合
（２．１．２．１．１．１）何もしない
（２．１．２．１．２）比較した結果が違う場合
（２．１．２．１．２．１）当該行を削除する。
（２．１．３）ｉ番目の行のｊ番目の列が正規表現型の場合。
（２．１．３．１）入力値のｊ番目の値が当該正規表現にマッチするか確認する。
（２．１．３．１．１）マッチする場合。
（２．１．３．１．１．１）数値に変換する。
（２．１．３．１．１．１．１）数値に変換できなかった場合。
（２．１．３．１．１．１．１．１）しない。
（２．１．３．１．１．１．２）数値に変換できた場合。
（２．１．３．１．１．１．２．１）値域の定義があれば、範囲内であるか確認する。
（２．１．３．１．１．１．２．１．１）範囲内である。
（２．１．３．１．１．１．２．１．１．１）何もしない。
（２．１．３．１．１．１．２．１．２）範囲外。
（２．１．３．１．１．１．２．１．２．１）当該行を削除する。
（２．１．３．１．２）マッチしない場合
（２．１．３．１．２．１）当該行を削除する。
（２．１．４）ｊを１増やす。
（２．２）ｉを１増やす。
（３）２次元配列の行数を確認する。
（３．１）行数が０の場合
（３．１．１）ＮＧを返却する。
（３．２）行数が１以上の場合
（３．２．１）ＯＫを返却する。【０３９０】  上記処理内容のフローチャートを図４４、４５に示す。
【実施例１２】
【０３９１】  実施例１にて、組織を横断する承認経路を求める方法の詳細を述べる。【０３９２】  様式に、承認経路の定義として、スタッフ部門承認が記述されていた場合、当該部門の承認の前に、指定したスタッフ部門の承認が必要となる。【０３９３】実施例１の承認経路生成部行われる処理を以下のように変更する。【０３９４】  （１）経路中間情報から起案したユーザが所属する部門を特定する
（２）起案したユーザが所属する部門が起案可能である場合
（２．１）承認経路リストに当該部門を追加する
（２．２）組織階層情報から様式の所有者が所属する部門を特定する
（２．３）起案したユーザが所属する部門から、所有者が所属する部門まで繰り返す
（２．３．１）上位の部門を特定する
（２．３．２）特定した部門が承認不要でない場合
（２．３．２．１）特定した部門がスタッフ部門承認要の場合
（２．３．２．１．１）担当スタッフ部門と対象スタッフ部門を特定する
（２．３．２．１．２）承認経路リストに担当スタッフ部門を追加する
（２．３．２．１．３）担当スタッフ部門から対象スタッフ部門まで繰り返す
（２．３．２．１．３．１）上位の部門を特定する
（２．３．２．１．３．２）特定した部門が承認不要でない場合
（２．３．２．１．３．２．１）承認経路リストに当該部門を追加する
（２．３．２．２）承認経路リストに当該部門を追加する
（３）起案したユーザが所属する部門が起案可能でない場合
（３．１）エラーを返却する
（４）作成した承認経路リストをＸＭＬの承認経路要素Ｘ９０１に変換する【０３９５】  上記処理内容のフローチャートを図４６に示す。
【実施例１３】
【０３９６】  実施例１、実施例２、及び  実施例６を拡張し、書類の所有者が権限を変更できるようにする方法を説明する。本発明では、書類に関する権限を変更する権限を持つユーザを所有者と呼ぶ。【０３９７】  実施例１の構成要素に加え、アプリケーションサーバ０１０１６に、権限変更部１３０１２を、ＷＥＢサーバ０１０２３に権限変更画面１３００１を用意する。（図４７）【０３９８】１．  専用言語の拡張
まず、組織情報及び様式の権限の定義を記述する専用言語を次のように変更する。なお、文法に変更がない場合も、説明を省略せずに記述する。【０３９９】  権限の定義には、承認権限の定義１３００２、所有時の権限定義１３００３、所有時の変更権限定義１３００４、最終決裁後の権限定義１３００５、最終決裁後の変更権限定義１３００６がそれぞれ０回以上記述できる。
ｐｅｒｍｉｓｓｉｏｎ｛
承認権限の定義１３００２
所有時の権限定義１３００３
所有時の変更権限定義１３００４
最終決裁後の権限定義１３００５
最終決裁後の変更権限定義１３００６
｝【０４００】  承認権限の定義１３００２は、承認時に実行可能な操作を記述する。
ａｐｐｒｏｖａｌ−ｐｅｒｍｉｓｓｉｏｎ：（承認操作０２０１６，…，承認操作０２０１６），所有者の種類０２０１７【０４０１】  承認操作０２０１６は、キーワード“ｆｏｒｗａｒｄ”、“ｒｅｊｅｃｔ”、“ｒｅｔｕｒｎ”、“ｓｋｉｐ”、“ｇｅｔｂａｃｋ”のいずれかが記述できる。“ｆｏｒｗａｒｄ”は提出、承認、又は決裁を、“ｒｅｊｅｃｔ”は却下を、“ｒｅｔｕｒｎ”は差戻しを、“ｓｋｉｐ”は飛ばし承認（強制承認）、又は、飛ばし決裁（強制決裁）を、“ｇｅｔｂａｃｋ”は取戻しを意味する。【０４０２】  所有時の権限定義１３００３は、書類の所有者の権限を記述する。
ｏｗｎｅｒ−ｐｅｒｍｉｓｓｉｏｎ：（権限０２０１８，…，権限０２０１８），所有者の種類０２０１７，対象部門０２０２０，対象ユーザ０２０２１【０４０３】  権限０２０１８は、キーワード“ｒｅａｄ”、“ｗｒｉｔｅ”、“ｄｅｌｅｔｅ”、“ａｐｐｒｏｖａｌ”が記述できる。“ｒｅａｄ”は参照権限を、“ｗｒｉｔｅ”は変更権限を、“ｄｅｌｅｔｅ”は削除権限を、“ａｐｐｒｏｖａｌ”は承認権限を意味する。承認操作０２０１６は、“ａｐｐｒｏｖａｌ”が記述されている場合のみ有効である。【０４０４】  所有者の種類０２０１７は、キーワード“ｃｒｅａｔｏｒ”、“ａｐｐｒｏｖｅｒ”、“ｌａｓｔ−ａｐｐｒｏｖｅｒ”を記述できる。“ｃｒｅａｔｏｒ”は書類の作成者を、“ａｐｐｒｏｖｅｒ”は承認者を、“ｌａｓｔ−ａｐｐｒｏｖｅｒ”は最終決裁者を意味する。【０４０５】  対象部門０２０２０は、書類の所有者を軸に相対的に部門の範囲を指定する。対象部門０２０２０は、キーワード“ａｌｌ”、“ｓｅｌｆ”、“ｐａｒｅｎｔ”、“ｃｈｉｌｄ”、“ｂｒｏｔｈｅｒ”、“ａｎｃｅｓｔｏｒ”、“ｄｅｓｃｅｎｄａｎｔ”を記述できる。“ａｌｌ”は全部門を、“ｓｅｌｆ”は所有者の所属部門を、“ｐａｒｅｎｔ”は所有者の所属部門の一つ上位の部門を、“ｃｈｉｌｄ”は所有者の所属部門の一つ下位の部門すべてを、“ｂｒｏｔｈｅｒ”は所有者の所属部門と上位部門を同じとする同会層の部門を、“ａｎｃｅｓｔｏｒ”は所有者の所属部門の上位全ての部門を、“ｄｅｓｃｅｎｄａｎｔ”は所有者の所属部門の下位全ての部門を意味する。【０４０６】  対象ユーザ０２０２１は、対象部門０２０２０で指定した部門において、部門に所属するユーザの種類を指定する。対象ユーザ０２０２１は、キーワード“ｓｅｌｆ”、“ｈｅａｄ”、“ｍｅｍｂｅｒ”、“ａｌｌ”を記述できる。“ｓｅｌｆ”は所有者自信を、“ｈｅａｄ”は部門の長を、“ｍｅｍｂｅｒ”は部門に所属するメンバーを、“ａｌｌ”は長とメンバー両方を意味する。【０４０７】  例えば、書類の作成者自身に参照権限、変更権限、削除権限及び、承認権限を付与する場合は、以下のように記述する。
ｏｗｎｅｒ−ｐｅｒｍｉｓｓｉｏｎ：（ｒｅａｄ，ｗｒｉｔｅ．ｄｅｌｅｔｅ，ａｐｐｒｏｖａｌ），ｃｒｅａｔｅｒ，ｓｅｌｆ，ｓｅｌｆ
作成者の所属する部門の他のメンバーに参照権限を付与する場合は、以下のように記述すればよい。
ｏｗｎｅｒ−ｐｅｒｍｉｓｓｉｏｎ：（ｒｅａｄ），ｃｒｅａｔｅｒ，ｓｅｌｆ，ｍｅｍｂｅｒ【０４０８】  所有時の権限は、自身が所有者でなくなった時に、権限が無効になる。これは、付与された所有者以外のユーザも同じである。【０４０９】  所有時の変更権限定義１３００４は、自身が書類の所有者の時に、所有者が他のユーザに付与できる権限を記述する。
ｏｗｎｅｒ−ｃｈａｎｇｅｍｏｄｅ−ｐｅｒｍｉｓｓｉｏｎ：（権限０２０１８，…，権限０２０１８），所有者の種類０２０１７【０４１０】  例えば、
ｏｗｎｅｒ−ｃｈａｎｇｅｍｏｄｅ−ｐｅｒｍｉｓｓｉｏｎ：（ｒｅａｄ，ｗｒｉｔｅ，ａｐｐｒｏｖａｌ），ｃｒｅａｔｏｒ
と記述すれば、書類の作成者が所有者の時、別のユーザに、書類の参照権限、変更権限、提出権限を付与する権限が与えられる。後述する権限変更画面を利用することで、書類の代理作成を実現することが出来る。【０４１１】  最終決裁後の権限定義１３００５は、最終決裁後の書類の権限を記述する。
ａｐｐｒｏｖｅｄ−ｐｅｒｍｉｓｓｉｏｎ：（権限０２０１９，…，権限０２０１９），所有者の種類０２０１７，対象部門０２０２０，対象ユーザ０２０２１
権限０２０１９は、キーワード“ｒｅａｄ”、“ｗｒｉｔｅ”、“ｄｅｌｅｔｅ”が記述できる。“ｒｅａｄ”は参照権限を、“ｗｒｉｔｅ”は変更権限を、“ｄｅｌｅｔｅ”は削除権限を意味する。【０４１２】  最終決裁後の変更権限定義１３００６は、最終決裁後に、所有者が他のユーザに付与できる権限を記述する。
ａｐｐｒｏｖｅｄ−ｃｈａｎｇｅｍｏｄｅ−ｐｅｒｍｉｓｓｉｏｎ：（権限０２０１９，…，権限０２０１９），所有者の種類０２０１７【０４１３】  例えば、
ａｐｐｒｏｖｅｄ−ｃｈａｎｇｅｍｏｄｅ−ｐｅｒｍｉｓｓｉｏｎ：ｒｅａｄ，ｌａｓｔ−  ａｐｐｒｏｖｅｒ
と記述した場合、書類が最終決裁された後に、最終承認者によって、参照権限を他のユーザに付与できることを意味する。【０４１４】２．  書類の作成処理の変更
次に、実施例１の「２−３−３．書類の作成」で説明した書類の作成の処理を次のように変更する。【０４１５】２−１．様式からＸＭＬ形式の書類の作成
書類の作成者は、一覧から作成したい様式を選択し、書類の作成を実行する。作成を実行すると、様式選択画面は、書類起案部０１０１０に、ユーザＩＤと様式の識別子を送信する。書類起案部０１０１０は、様式検索部０１０５４に様式の識別子を送信し、当該様式を取得する。書類起案部０１０１０は、次の処理を行い、様式からＸＭＬ形式の書類を作成する。【０４１６】（１）ルート要素である書類要素０１０５５を作成する。
（２）書類の識別子を発行し、書類要素０１０５５のＩＤ属性０１０５６に記述する。
（３）書類要素０１０５５の下位に様式の識別子を内容とした様式ＩＤ要素０１０５７を作成する。
（４）書類要素０１０５５の下位に様式の所有者の部門ＩＤを内容とした様式所有者要素０１０５８を作成する。
（５）書類要素０１０５５の下位に承認経路要素０１０５９を作成する。
（６）書類要素０１０５５の下位に書面要素０１０６０を作成する。
（７）承認経路要素０１０５９の下位に承認経路の設定を作成する。承認経路の設定については後述する。
（８）様式の項目名と型名の定義の数だけ繰り返す。
（８．１）項目名を要素名とした項目要素０１０６１を作成する。
（８．２）型名を項目要素０１０６１の型属性０１０８９に記述する。【０４１７】  上記処理内容のフローチャートを図４８に示す。【０４１８】２−２．承認経路の設定の作成
承認経路の設定は以下の処理で作成する。【０４１９】  まず、組織情報参照部０１００４から組織情報を取得し、組織情報の省略値を補完し、組織階層情報に様式の承認経路の定義、及び、権限の定義を反映した中間情報１３０１３を作成する。【０４２０】  （１）すべての部門を対象に処理を行う。
（１．１）権限の定義が記述されていなければ、上位の部門の権限の定義を、コピーする。
（１）承認経路の定義に記述された定義の数だけ繰り返す。
（１．１）承認経路の定義に承認不要部門が記述されていた場合
（１．１．１）組織階層情報の対象部門に承認不要０１０６３を追加する
（１．２）承認経路の定義にスタッフ部門承認が記述されていた場合
（１．２．１）組織階層情報の対象部門にスタッフ部門承認要０１０６４を追加する
（２）権限の定義に記述された定義の数だけ繰り返す。
（２．１）すべての部門を対象に処理を行う。
（２．１．１）権限の定義に承認権限の定義が記述されていた場合
（２．１．１．１）組織階層情報の承認権限の定義０１０６５を変更する。
（２．１．２）権限の定義に所有時権限の定義が記述されていた場合
（２．１．２．１）組織階層情報の所有時権限の定義０１０６６を変更する。
（２．１．３）権限の定義に所有時変更権限の定義が記述されていた場合
（２．１．３．１）組織階層情報の所有時変更権限の定義１３００７を変更する。
（２．１．４）権限の定義に決裁後権限の定義が記述されていた場合
（２．１．４．１）組織階層情報の決裁後権限の定義０１０６７を変更する。
（２．１．５）権限の定義に決裁後変更権限の定義が記述されていた場合
（２．１．５．１）組織階層情報の決裁後変更権限の定義１３００８を変更する。【０４２１】  上記処理内容のフローチャートを図４９に示す。【０４２２】  また、図５０は、「組織階層情報に様式の承認経路の定義、及び、権限の定義を反映した中間情報１３０１３」の例である。【０４２３】  次に、組織階層情報に承認経路の定義を反映した中間情報から承認経路１３００９を作成する。【０４２４】  （１）組織階層情報から書類の作成者が所属する部門を特定する。
（２）承認経路に作成者だけを残した当該部門を追加する。
（３）承認経路にメンバーを削除し長だけにした当該部門を追加する。
（４）上位の部門を特定する。
（４．１）特定した部門が様式の所有者が所属する部門でない場合。
（４．１．１）特定した部門に承認不要０１０６３が追加されていない場合。
（４．１．１．１）承認経路にメンバーを削除し長だけにした当該部門を追加する。
（４．１．２）処理（４）へ戻る。
（４．２）特定した部門が様式の所有者が所属する部門である場合。
（４．２．１）承認経路１３００９にメンバーを削除し長だけにした当該部門を追加し、処理を終了する。【０４２５】  上記処理内容のフローチャートを図５１に示す。【０４２６】次に、承認経路１３００９をＸＭＬに変換し、書類の承認経路要素０１０５９の下位に追加する。ＸＭＬへの変換ルールは以下となる。【０４２７】（１）承認経路１３００９の部門の数だけ繰り返す。
（１．１）ひとつ目の時
（１．１．１）起案者要素０１０６９を作成する。
（１．１．２）起案者要素０１０６９の下位に予定者要素０１０７０を作成する。
（１．１．３）予定者要素０１０７０の下位に、作成者の部門名を内容に、部門の識別子をＩＤ属性とした、部門要素０１０７１を作成する。
（１．１．４）予定者要素０１０７０の下位に、作成者のユーザ名を内容に、ユーザの識別子をＩＤ属性とした、ユーザ要素０１０７２を作成する。
（１．１．５）起案者要素０１０６９の下位に、実施者要素０１０７３を作成する。実施者要素０１０７３の内容は空とする。
（１．１．６）起案者要素０１０６９の下位に、権限要素０１０７４を作成する。
（１．１．７）対象が作成者になっている承認権限の定義０１０６５から、承認権限要素０１０７５を作成し、権限要素０１０７４の下位に追加する。
（１．１．８）対象が作成者になっている所有時権限の定義０１０６６から、所有時権限要素０１０７６を作成し、権限要素０１０７４の下位に追加する。
（１．１．９）対象が作成者になっている所有時変更権限の定義１３００７から、所有時変更権限要素１３０１０を作成し、権限要素０１０７４の下位に追加する。
（１．１．１０）対象が作成者になっている決裁後権限の定義０１０６７から、決裁後権限要素０１０７７を作成し、権限要素０１０７４の下位に追加する。
（１．１．１１）対象が作成者になっている決裁後変更権限の定義１３００８から、決裁後変更権限要素１３０１１を作成し、権限要素０１０７４の下位に追加する。
（１．２）ひとつ目でも最後でもない時
（１．２．１）承認者要素０１０７８を作成する。
（１．２．２）承認者要素０１０７８の下位に予定者要素０１０７０を作成する。
（１．２．３）予定者要素０１０７０の下位に、承認者の部門名を内容に、部門の識別子をＩＤ属性とした、部門要素０１０７１を作成する。
（１．２．４）予定者要素０１０７０の下位に、承認者のユーザ名を内容に、ユーザの識別子をＩＤ属性とした、ユーザ要素０１０７２を作成する。
（１．２．５）承認者要素０１０７８の下位に、実施者要素０１０７３を作成する。実施者要素０１０７３の内容は空とする。
（１．２．６）承認者要素０１０７８の下位に、権限要素０１０７４を作成する。
（１．２．７）対象が承認者になっている承認権限の定義０１０６５から、承認権限要素０１０７５を作成し、権限要素０１０７４の下位に追加する。
（１．２．８）対象が承認者になっている所有時権限の定義０１０６６から、所有時権限要素０１０７６を作成し、権限要素０１０７４の下位に追加する。
（１．２．９）対象が承認者になっている所有時変更権限の定義１３００７から、所有時変更権限要素１３０１０を作成し、権限要素０１０７４の下位に追加する。
（１．２．１０）対象が承認者になっている決裁後権限の定義０１０６７から、決裁後権限要素０１０７７を作成し、権限要素０１０７４の下位に追加する。
（１．２．１１）対象が承認者になっている決裁後変更権限の定義１３００８から、決裁後変更権限要素１３０１１を作成し、権限要素０１０７４の下位に追加する。
（１．３）最後の時
（１．２．１）最終決裁者要素０１０７９を作成する。
（１．２．２）最終決裁者要素０１０７９の下位に予定者要素０１０７０を作成する。
（１．２．３）予定者要素０１０７０の下位に、最終決裁者の部門名を内容に、部門の識別子をＩＤ属性とした、部門要素０１０７１を作成する。
（１．２．４）予定者要素０１０７０の下位に、最終決裁者のユーザ名を内容に、ユーザの識別子をＩＤ属性とした、ユーザ要素０１０７２を作成する。
（１．２．５）最終決裁者要素０１０７９の下位に、実施者要素０１０７３を作成する。実施者要素０１０７３の内容は空とする。
（１．２．６）最終決裁者要素０１０７９の下位に、権限要素０１０７４を作成する。
（１．２．７）対象が最終決裁者になっている承認権限の定義０１０６５から、承認権限要素０１０７５を作成し、権限要素０１０７４の下位に追加する。
（１．２．８）対象が最終決裁者になっている所有時権限の定義０１０６６から、所有時権限要素０１０７６を作成し、権限要素０１０７４の下位に追加する。
（１．２．９）対象が最終決裁者になっている所有時変更権限の定義１３００７から、所有時変更権限要素１３０１０を作成し、権限要素０１０７４の下位に追加する。
（１．２．１０）対象が最終決裁者になっている決裁後権限の定義０１０６７から、決裁後権限要素０１０７７を作成し、権限要素０１０７４の下位に追加する。
（１．２．１１）対象が最終決裁者になっている決裁後変更権限の定義１３００８から、決裁後変更権限要素１３０１１を作成し、権限要素０１０７４の下位に追加する。【０４２８】  上記処理内容のフローチャートを図５２、５３に示す。
また、承認経路要素を追加したＸＭＬ形式の書類の例を図５４に示す。【０４２９】  書類起案部０１０１０は、書類を保存するサーバ０１０１７に、以上の手順によって作成したＸＭＬ形式の書類を送信し、正常に終了した場合は作成した書類の識別子を様式選択画面０１０１８に返す。【０４３０】３．  権限の変更処理
書類の権限の変更を行う際の処理手順について説明する。ここでいう権限の変更とは、「１．専用言語の定義」において説明した権限の定義を変更することをいう。【０４３１】  ３−１．対象書類の検索
利用者が書類の権限の変更をする場合は、書類検索画面０１０１９から自身が所有者で権限の変更権限を付与されている書類の検索を行う。
書類の承認経路要素に対する具体的な検索条件は、以下のとおりである。【０４３２】  ・起案者要素の予定者要素に、自身のユーザＩＤが存在し、起案者要素の実施者要素が空であり、起案者要素の所有時変更権限要素に値がある。
又は、
・承認者要素の予定者要素に、自身のユーザＩＤが存在し、承認者要素の実施者要素が空であり、当該承認者要素の所有時変更権限要素に値があり、当該承認者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。
又は、
・実施者要素がすべて値を持ち、自身のユーザＩＤがいずれかの実施者要素に存在し、自身のユーザＩＤが存在した、実施者要素の親の、起案者要素か、承認者要素か、最終決裁者要素の決裁後変更権限に値がある。【０４３３】  上記検索条件は、作成されているが未提出の書類の作成者であるか、次の承認を行うべき承認者であるか、最終決裁後に変更権限を有するように設定された者であるかを書類の内容に基づいて照合するものである。【０４３４】  書類検索画面０１０１９は、検索条件を書類検索部０１０１３へ送信する。書類検索部０１０１３は、書類の承認経路要素に対して検索を実行し、該当書類を特定する。書類検索部０１０１３は該当書類の一覧を、書類検索画面０１０１９へ返す。書類検索画面０１０１９は該当書類の一覧を表示する。【０４３５】３−２．書類の表示
利用者が、該当書類の一覧から権限変更対象の書類を選択すると、権限変更画面１３００１が表示される。このとき書類検索画面０１０１９からは書類の識別子が渡される。権限変更画面１３００１は書類参照部０１０１４へユーザＩＤと書類の識別子を渡す。書類参照部０１０１４は、書類を保存するサーバ０１０１７から、書類の識別子で特定される書類を取得する。書類参照部０１０１４は、検索を行った時と同じ条件で権限の変更が可能か確認する。条件は以下のとおりである。【０４３６】  ・起案者要素の予定者要素に、自身のユーザＩＤが存在し、起案者要素の実施者要素が空であり、起案者要素の所有時変更権限要素に値がある。
又は、
・承認者要素の予定者要素に、自身のユーザＩＤが存在し、承認者要素の実施者要素が空であり、当該承認者要素の所有時変更権限要素に値があり、当該承認者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。
又は、
・実施者要素がすべて値を持ち、自身のユーザＩＤがいずれかの実施者要素に存在し、自身のユーザＩＤが存在した、実施者要素の親の、起案者要素か、承認者要素か、最終決裁者要素の決裁後変更権限要素に値がある。【０４３７】  権限に問題がなければ、書類参照部０１０１４は、取得した書類を権限変更画面１３００１に返却し、権限変更画面１３００１は返却されたＸＭＬ形式の書類をＨＴＭＬに変換し表示する。この時、権限変更画面１３００１には、所有時変更権限要素、又は、決裁後変更権限要素に記述された付与可能な権限の一覧を、選択できるように画面に表示する。また、権限を変更する対象部門と対象メンバーを選択できるように画面に表示する。【０４３８】  図５５に権限変更画面の例を示す。【０４３９】３−３．権限変更の実施
利用者は、書類を参照して、権限の変更対象の書類であることを確認し、付与する権限と、変更対象を選択して、権限変更画面１３００１に備えられた権限変更ボタンを押下する。書類参照画面０１０２２は、書類の識別子、利用者のユーザＩＤ、付与する権限、変更対象、及び、権限の変更を意味するフラグを引数に、権限変更部１３０１２を呼び出す。【０４４０】  権限変更部１３０１２は、書類の検索時、書類の表示時と同様に、次の条件で、権限を変更する権限があるか確認する。【０４４１】  ・起案者要素の予定者要素に、自身のユーザＩＤが存在し、起案者要素の実施者要素が空であり、起案者要素の所有時変更権限要素に付与しようとしている権限がある。
又は、
・承認者要素の予定者要素に、自身のユーザＩＤが存在し、承認者要素の実施者要素が空であり、当該承認者要素の所有時変更権限要素に値があり、当該承認者要素の一つ前の起案者要素か、承認者要素の実施者要素に付与しようとしている権限がある。
又は、
・実施者要素がすべて値を持ち、自身のユーザＩＤがいずれかの実施者要素に存在し、自身のユーザＩＤが存在した、実施者要素の親の、起案者要素か、承認者要素か、最終決裁者要素の決裁後変更権限要素に付与しようとしている権限がある。【０４４２】  権限に問題がなければ、条件にマッチした起案者要素、承認者要素、又は、最終決裁者要素に、書類が最終決裁前ならば所有時権限要素を、書類が最終決裁後ならば決裁後権限要素を作成し、変更した権限、対象部門、及び、対象メンバーの範囲を記述する。権限変更部１３０１２は、変更した書類を書類を保存するサーバ０１０１７に送信し、保存されている書類を更新する。【０４４３】  図５６は、最終決裁後に最終決裁者の所属部門の下位の部門の長に参照権限を付与した承認経路の例である。【０４４４】３−４．権限を付与されたユーザの操作
権限を付与されたユーザの、参照、変更、削除、及び、承認の処理手順は実施例１と同じである。それぞれの処理手順における、検索の条件、書類表示時の権限確認の条件、及び、操作時の権限確認の条件は、以下のとおりになる。【０４４５】３−４−１．参照
参照可能となる条件は、以下のいずれかとなる。【０４４６】  ・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。【０４４７】  ・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該承認者要素の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。【０４４８】  ・承認経路要素に却下要素、又は、削除要素が無く、当該最終決裁者の実施者要素が空であり、当該最終決裁者の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該最終決裁者の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。【０４４９】  ・すべての実施者要素が値を持つか、又は、承認経路要素に却下要素があり、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。【０４５０】３−４−２．変更
変更可能となる条件は、以下のいずれかとなる。【０４５１】  ・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素に値“ｗｒｉｔｅ”があり、当該起案者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。【０４５２】  ・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ｗｒｉｔｅ”があり、当該承認者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該承認者要素の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。【０４５３】  ・承認経路要素に却下要素、又は、削除要素が無く、当該最終決裁者の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ｗｒｉｔｅ”があり、当該最終決裁者の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる、当該最終決裁者の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。【０４５４】  ・すべての実施者要素が値を持ち、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素のに値“ｗｒｉｔｅ”があり、当該決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。【０４５５】３−４−３．削除
削除可能となる条件は、以下のいずれかとなる。【０４５６】  ・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素に値“ｄｅｌｅｔｅ”があり、当該起案者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。【０４５７】  ・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ｄｅｌｅｔｅ”があり、当該承認者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該承認者要素の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。【０４５８】  ・承認経路要素に却下要素、又は、削除要素が無く、当該最終決裁者の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ｄｅｌｅｔｅ”があり、当該最終決裁者の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該最終決裁者の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。【０４５９】  ・承認経路要素に削除要素が無く、すべての実施者要素が値を持ち、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素のに値“ｄｅｌｅｔｅ”があり、当該決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。【０４６０】  ・承認経路要素に削除要素が無く、承認経路要素に却下要素があり、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素のに値“ｄｅｌｅｔｅ”があり、当該決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。【０４６１】３−４−４．提出
提出可能となる条件は、以下となる。【０４６２】  ・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該起案者要素の承認権限要素に値“ｆｏｒｗａｒｄ”があり、当該起案者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。【０４６３】３−４−５．承認（承認、却下、差戻し）
承認可能（承認、却下、差戻し）となる条件は、以下のいずれかとなる。
・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｆｏｒｗａｒｄ”、“ｒｅｊｅｃｔ”、又は、“ｒｅｔｕｒｎ”があり、当該承認者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該承認者要素の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。【０４６４】  ・承認経路要素に却下要素、又は、削除要素が無く、当該最終決裁者の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該最終決裁者要素の承認権限要素に値“ｆｏｒｗａｒｄ”、“ｒｅｊｅｃｔ”、又は、“ｒｅｔｕｒｎ”があり、当該最終決裁者の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該最終決裁者の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。【０４６５】３−４−６．承認（取戻し）
承認可能（取戻し）となる条件は、以下のいずれかとなる。【０４６６】  ・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素に値があり、当該起案者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該起案者要素の承認権限要素に値“ｇｅｔｂａｃｋ”があり、当該起案者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該起案者要素の一つ後の承認者要素に値が無い。【０４６７】  ・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の実施者要素に値があり、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｇｅｔｂａｃｋ”があり、当該承認者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該承認者要素の一つ後の承認者要素に値が無い。【０４６８】３−４−７．承認（飛ばし承認、飛ばし決裁）
承認可能（飛ばし承認、飛ばし決裁）となる条件は、以下のいずれかとなる。【０４６９】  ・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素に値があり、承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｓｋｉｐ”があり、当該承認者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該承認者要素の前に実施者要素が空の連続した承認者要素が一つ以上ある。【０４７０】  ・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素に値があり、最終決裁者要素の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該最終決裁者要素の承認権限要素に値“ｓｋｉｐ”があり、当該最終決裁者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該最終決裁者要素の前に実施者要素が空の連続した承認者要素が一つ以上ある。【０４７１】  ＜付記１＞
なお、本明細書において説明した実施例１乃至１３は、任意のものを組み合わせることでも、本願の目的を達成しうる。【０４７２】  ＜付記２＞
また、実施例に含まれる各装置及びサーバは、合わせて一つの装置として実現してもよいし、任意のものを組み合わせて一つの装置としても、本願の目的を達成しうる。【０４７３】  ＜付記３＞
また、実施例に含まれる上記各機能は、任意のものをハードウェアとして構成してもよいし、コンピュータによって実行させることで、上記各機能として動作させるためのコンピュータプログラムとして構成してもよい。プログラムとして構成する場合は、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリなどの任意の記録媒体に格納される。
【図面の簡単な説明】
【０４７４】
【図１】実際の組織階層の例に当てはめた、命令と応答の説明の図である。
【図２】実際の組織階層の例に当てはめた、承認経路の説明の図である。
【図３】差戻しや飛び決の承認経路の図である。
【図４】組織階層を横断する承認経路の例である。
【図５】ライン部門配下の仮想的なスタッフ部門の図である。
【図６】書類の作成中の参照権限の図である。
【図７】書類が承認中の参照権限の図である。
【図８】書類の最終決裁後の参照権限の図である。
【図９】所有者を基準に組織階層上で相対的に参照権限を設定する例である。
【図１０】本発明を実現するために必要な構成要素のブロック図である。
【図１１】組織図のツリー構造を示したブロック図である。
【図１２】チェックプログラムの処理のフローチャートである。
【図１３】チェックプログラムの処理のフローチャートである。
【図１４】補完プログラムの処理のフローチャートである。
【図１５】書類の作成のフローチャートである。
【図１６】承認経路の設定のフローチャートである。
【図１７】組織階層情報に様式の承認経路の定義、及び、権限の定義を反映した中間情報０１０６２の例である。
【図１８】組織階層情報に承認経路の定義を反映した中間情報０１０６２から承認経路０１０６８を作成するフローチャートである。
【図１９】承認経路と書類の承認経路要素のＸＭＬへの変換ロジックのフローチャートである。
【図２０】承認経路と書類の承認経路要素のＸＭＬへの変換ロジックのフローチャートである。
【図２１】承認経路要素を追加したＸＭＬ形式の書類の例である。
【図２２】検索画面の例である。
【図２３】権限変更画面の例である。
【図２４】承認後の書類の承認者要素の例である。
【図２５】差戻し後の書類の承認経路要素の例である。
【図２６】飛ばし承認後の書類の承認経路要素の例である。
【図２７】権限のまとめの図である。
【図２８】権限のまとめの図である。
【図２９】組織情報記述言語（ユーザ情報）の記述例である。
【図３０】組織情報記述言語（組織階層情報）の記述例である。
【図３１】様式記述言語の構成の図である。
【図３２】様式に記述される型、及び、文書構造の定義の記述例である。
【図３３】様式記述言語（承認経路の定義）の記述例である。
【図３４】様式記述言語（権限の定義）の記述例である。
【図３５】複数項目にまたがるエラーチェック及び補完を可能とした型及び文書構造の記述例である。
【図３６】エラー判定結果を返却するチェックプログラムの処理のフローチャートである。
【図３７】補完値の２次元配列を返却する補完プログラムの処理のフローチャートである。
【図３８】外部データベースの値を列挙値として利用した場合のチェックプログラムの処理ジックのフローチャートである。
【図３９】外部データベースの値を列挙値として利用した場合のチェックプログラムの処理ジックのフローチャートである。
【図４０】外部データベースの値を列挙値として利用した場合のチェックプログラムの処理ジックのフローチャートである。
【図４１】外部データベースの値を列挙値として利用した場合のチェックプログラムの処理ジックのフローチャートである。
【図４２】外部データベースの値を列挙値として利用した場合のチェックプログラムの処理ジックのフローチャートである。
【図４３】外部データベースの値を列挙値として利用した場合のチェックプログラムの処理ジックのフローチャートである。
【図４４】型に数値範囲の制限を加える方法の処理のフローチャートである。
【図４５】型に数値範囲の制限を加える方法の処理のフローチャートである。
【図４６】組織を横断する承認経路を求める処理のフローチャートである。
【図４７】本発明を実現するために必要な構成要素のブロック図である。
【図４８】書類の作成処理のフローチャートである。
【図４９】承認経路の処理のフローチャートである。
【図５０】組織階層情報に様式の承認経路の定義、及び、権限の定義を反映した中間情報１３０１３の例である。
【図５１】組織階層情報に承認経路の定義を反映した中間情報から承認経路１３００９を作成する処理のフローチャートである。
【図５２】承認経路と書類の承認経路要素のＸＭＬへの変換ロジックのフローチャートである。
【図５３】承認経路と書類の承認経路要素のＸＭＬへの変換ロジックのフローチャートである。
【図５４】承認経路要素を追加したＸＭＬ形式の書類の例である。
【図５５】権限変更画面の例である。
【図５６】最終決裁後に最終決裁者の所属部門の下位の部門の長に参照権限を付与した承認経路の例である。
【符号の説明】
【０４７５】  ０１００１  組織情報・様式・既存の型を保存するサーバ
０１００２  組織情報、様式、及び、既存の型を解釈し、チェックプログラム、補完プログラム、及び、様式中間情報を生成する様式コンパイラ
０１００３  組織情報、様式、及び、既存の型を解釈し、チェックプログラム、補完プログラム、及び、様式中間情報を生成する様式コンパイラ０１００２を実行する様式コンパイルサーバ
０１００４  組織情報参照部
０１００５  様式検索部
０１００６  組織情報参照部０１００４と様式検索部０１００５からなるアプリケーションサーバ
０１００７  生成されたチェックプログラム
０１００８  補完プログラム
０１００９  生成されたチェックプログラム０１００７、及び、補完プログラム０１００８を実行するアプリケーションサーバ
０１０１０  書類起案部
０１０１１  書類提出部
０１０１２  書類承認部
０１０１３  書類検索部
０１０１４  書類参照部
０１０１５  書類削除部
０１０１６  書類起案部０１０１０、書類提出部０１０１１、書類承認部０１０１２、書類検索部０１０１３、書類参照部０１０１４、書類削除部０１０１５、及び、権限変更部１３０１２からなるアプリケーションサーバ
０１０１７  書類を保存するサーバ
０１０１８  様式選択画面
０１０１９  書類検索画面
０１０２０  書類入力画面
０１０２１  書類承認画面
０１０２２  書類参照画面
０１０２３  様式選択画面０１０１８、書類検索画面０１０１９、書類入力画面０１０２０、書類承認画面０１０２１、書類参照画面０１０２２、及び、権限変更画面１３００１を保存し配信するＷｅｂサーバ
０１０２４  認証サーバ
０１０２５  画面を表示するＷＥＢブラウザ
０１０２６  画面を表示するＷＥＢブラウザ０１０２５を持つ複数の利用者端末
１３００１  権限変更画面
１３０１２  権限変更部
【図１】
2015167006.tif 000003
【図２】
2015167006.tif 000004
【図３】
2015167006.tif 000005
【図４】
2015167006.tif 000006
【図５】
2015167006.tif 000007
【図６】
2015167006.tif 000008
【図７】
2015167006.tif 000009
【図８】
2015167006.tif 000010
【図９】
2015167006.tif 000011
【図１０】
2015167006.tif 000012
【図１１】
2015167006.tif 000013
【図１２】
2015167006.tif 000014
【図１３】
2015167006.tif 000015
【図１４】
2015167006.tif 000016
【図１５】
2015167006.tif 000017
【図１６】
2015167006.tif 000018
【図１７】
2015167006.tif 000019
【図１８】
2015167006.tif 000020
【図１９】
2015167006.tif 000021
【図２０】
2015167006.tif 000022
【図２１】
2015167006.tif 000023
【図２２】
2015167006.tif 000024
【図２３】
2015167006.tif 000025
【図２４】
2015167006.tif 000026
【図２５】
2015167006.tif 000027
【図２６】
2015167006.tif 000028
【図２７】
2015167006.tif 000029
【図２８】
2015167006.tif 000030
【図２９】
2015167006.tif 000031
【図３０】
2015167006.tif 000032
【図３１】
2015167006.tif 000033
【図３２】
2015167006.tif 000034
【図３３】
2015167006.tif 000035
【図３４】
2015167006.tif 000036
【図３５】
2015167006.tif 000037
【図３６】
2015167006.tif 000038
【図３７】
2015167006.tif 000039
【図３８】
2015167006.tif 000040
【図３９】
2015167006.tif 000041
【図４０】
2015167006.tif 000042
【図４１】
2015167006.tif 000043
【図４２】
2015167006.tif 000044
【図４３】
2015167006.tif 000045
【図４４】
2015167006.tif 000046
【図４５】
2015167006.tif 000047
【図４６】
2015167006.tif 000048
【図４７】
2015167006.tif 000049
【図４８】
2015167006.tif 000050
【図４９】
2015167006.tif 000051
【図５０】
2015167006.tif 000052
【図５１】
2015167006.tif 000053
【図５２】
2015167006.tif 000054
【図５３】
2015167006.tif 000055
【図５４】
2015167006.tif 000056
【図５５】
2015167006.tif 000057
【図５６】
2015167006.tif 000058