(57)【要約】【課題】本発明は、第三者フィールドがフォーム中のフィールド値の検分／修正権限を承認することを必要とする被承認フィールドを設定することにより、被承認者の検分／修正権限がその職責と一致するように設定でき、従って、被承認者が作業に関係のないフォーム情報を検分／修正することが防がれ、企業情報の漏洩の可能性を減らす。【解決手段】本発明は、第三者フィールドを介してフォームフィールドのフィールド値を承認する方法を公開し、１つまたは複数の被承認者を選択すること；  承認しようとする一つフォームを選択し、そのフォームに第三者フィールドでそのフィールド値の検分権限の承認を制御する必要がある被承認フィールドを表示すること；  各被承認フィールドのために１つまたは複数の第三者フィールドをそれぞれ選択し、前記第三者フィールドは、一つまたは複数のオプションを含むこと；各第三者フィールドの各オプションに対応するフォームデータの被承認フィールドのフィールド値の検分権限をそれぞれ承認することを含む。【選択図】図４
2020528600.tif 000002
【特許請求の範囲】
【請求項１】
第三者フィールドを介してフォームフィールドのフィールド値を承認する方法であって、
１つまたは複数の被承認者を選択すること、
承認しようとする一つフォームを選択し、そのフォームに第三者フィールドでそのフィールド値の検分権限の承認を制御する必要がある被承認フィールドを表示すること、
各被承認フィールドのために１つまたは複数の第三者フィールドをそれぞれ選択し、前記第三者フィールドは選択されたフォームの中のフィールドであり、前記第三者フィールドは、一つまたは複数のオプションを含むこと、
各第三者フィールドの各オプションに対応するフォームデータの被承認フィールドのフィールド値の検分権限をそれぞれ承認すること、を含む方法。
【請求項２】
前記被承認者は、人やユーザーやグループやクラスやロールのうちの一種または多種を含み、前記ロールは、グループ／クラスではなく、独立した個体であり、同時期に一つのロールが唯一のユーザーを関連付けることができ、一つのユーザーが１つまたは複数のロールを関連付ける請求項１に記載の方法。
【請求項３】
前記ロールは部門に属し、そのロールは部門に唯一であり、ロールの作業内容によりロールを承認し、ユーザーは関連するロールを介して承認を取得する請求項２に記載の方法。
【請求項４】
ユーザーは部門間で異動する時、ユーザーと元の部門内のロールの関連を取り消して、ユーザーを新しい部門のロールに関連付ける請求項３に記載の方法。
【請求項５】
前記第三者フィールドは時間特性フィールドと非時間特性フィールドを含み、前記時間特性フィールドのオプションが承認操作者に決定され、前記非時間特性フィールドのフィールド値が選択的に決定されまたは自動的に決定され、選択的に決定されるまたは自動的に決定される時の全てのオプションを非時間特性フィールドのオプションとする請求項１に記載の方法。
【請求項６】
前記時間特性フィールドのオプションは、現在時点から固定の時間を逆にして得られた時点から現在時点までの時間帯、開始時点から現在時点までの時間帯、終了時点からシステムの初期化時までの時間帯、開始時点から終了時点までの時間帯、時間フィールド値がヌル値である時間帯、システムの初期化時から現在時点までの時間帯の一つまたは複数を含み、前記のシステムの初期化時から現在時点までの時間帯は時間フィールド値がヌル値である時間帯を含む請求項５に記載の方法。
【請求項７】
被承認者が一つである場合、被承認者のそのフォームの被承認フィールドのフィールド値の検分権限は、被承認者のそのフォームの被承認フィールドのフィールド値が前回承認された時に保存された検分権限と表示し、被承認者が二つまたは三つ以上である場合、前記被承認者のそのフォームの被承認フィールドのフィールド値の検分権限を表示しない請求項１に記載の方法。
【請求項８】
検分権限を有しないフィールド値に対して、表示方式は、（１）そのフィールド値に対応するフィールドを表示するが、フィールド値を隠し符号で隠すこと、（２）フィールド値もフィールド値に対応するフィールドも表示されないことを含む請求項１に記載の方法。
【請求項９】
第三者フィールドを介してフォームフィールドのフィールド値を承認する方法であって、
１つまたは複数の被承認者を選択すること、
承認しようとする一つフォームを選択し、そのフォームに第三者フィールドでそのフィールド値の検分権限の承認を制御する必要がある被承認フィールドを表示すること、
テンプレートを選択し、一つの既存の被承認者または作成されたテンプレートを選択して承認テンプレートとし、前記被承認者のそのフォームの被承認フィールドのフィールド値の検分権限を承認テンプレート中の相応のフィールドのフィールド値の検分権限に更新すること、
テンプレートを選択した後修正し続けるかどうかを判断し、修正し続ける場合に、各被承認フィールドのために１つまたは複数の第三者フィールドをそれぞれ決定し、前記第三者フィールドは選択されたフォームの中のフィールドであり、前記第三者フィールドは、一つまたは複数のオプションを含み、各第三者フィールドの各オプションのフォームデータの被承認フィールドのフィールド値の検分権限をそれぞれ承認／修正し、続いて保存すること、
テンプレートを選択した後修正し続けないとき、保存すること、を含む方法。
【請求項１０】
第三者フィールドを介してフォームフィールドのフィールド値を承認する方法であって、
１つまたは複数の被承認者を選択すること、
承認しようとする一つフォームを選択し、そのフォームに第三者フィールドでそのフィールド値の修正権限の承認を制御する必要がある被承認フィールドを表示すること、
各被承認フィールドのために１つまたは複数の第三者フィールドをそれぞれ選択し、前記第三者フィールドは選択されたフォームの中のフィールドであり、前記第三者フィールドは、一つまたは複数のオプションを含むこと、
各第三者フィールドの各オプションに対応するフォームデータの被承認フィールドのフィールド値の修正権限をそれぞれ承認すること、を含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＥＲＰなどの管理ソフトウェアシステムにフォームを承認する方法に関し、特に、第三者フィールドを介してフォームフィールドのフィールド値を承認する方法に関する。
【背景技術】
【０００２】
従来のＥＲＰ管理ソフトウェアは、フォームフィールド値に基づいてフォームを検分し変更する権限をそれぞれ承認することを提供する。たとえば、契約フォームは、フォームのフィールドが契約署名時間、契約署名者、顧客名、顧客の所属する産業等を含み、ユーザーに検分されたフィールド内容がそれぞれ承認でき、ユーザーＡがフォームの契約署名時間と契約署名者を検分することを許し、ユーザーＡが顧客名と顧客の所属する産業を検分することを許さず、従って、会社情報の秘密保持を実現し、機密情報の漏洩を防ぐ。ただし、これらのＥＲＰ管理ソフトウェアは各ユーザーをそれぞれ承認することしかできず、ユーザーの一括承認が達成できず、承認操作は非効率的であり、多数のユーザーがいるシステムに巨大なワークロードをもたらす。また、既存のソフトウェアではフォーム内のフィールドをさらに制限することはできない。その結果、ユーザーはフィールドのフィールド値を検分する権限を取得した後、大量のデータを検分することができる。作業の責任を細分する会社にとって情報漏えいを引き起こしやすい。たとえば、ユーザーＣは、契約署名時間、契約署名者、契約フォームの顧客名が検出できる権限を与えられるが、ユーザーＣの実際の職責は金融業界の契約情報の統計のみを担当する。ただし、既存の承認設定方法は、ユーザーＣが金融業界を除く他の契約情報を検分することを引き起こし、会社の情報セキュリティにとって不利になる。
【０００３】
従来のフォームフィールド値の承認は、第三者フィールドでフォームの被承認フィールドのフィールド値を制御することができない。たとえば、注文フォームを承認する時、フィールドの承認のみにより張三にソフトウェア業界の注文の単価フィールドの価格を検分させることを実現しようとしているが、その単価フィールドの価格が変更できない。又は、張三にソフトウェア業界と化学工業の注文の単価フィールドの価格しか検分させずに、且つ化学工業の注文の単価フィールドの価格しか変更させないことを実現しようとしている。従来のソフトウェアは、このようなきめ細かいフィールドのフィールド値の差別化承認を実現することができず、高い要求がある管理需要を実現することもできない。
【０００４】
ロールベースのアクセス制御（ＲＢＡＣ）は、近年最も多く研究されており、最も成熟したデータベース権限管理メカニズムの１つであり、従来の強制アクセス制御（ＭＡＣ）および自律アクセス制御（ＤＡＣ）に代わる理想的な候補と考えられる。ロールベースのアクセス制御（ＲＢＡＣ）の基本的な考え方は、企業組織ビューのさまざまな機能的位置を分割して異なるロールを形成し、データベースリソースのアクセス権をロールにカプセル化するに従って、ユーザーは、異なるロールを割り当てられることにより、データベースリソースに間接的にアクセスするというものである。
【０００５】
大量のテーブルとビューが大規模なアプリケーションシステムに組み込まれているため、データベースリソースの管理と承認が非常に複雑になる。ユーザーがデータベースリソースのアクセスと権限承認を直接管理することは非常に困難である。ユーザーはデータベース構造を十分に理解し、ＳＱＬ言語を使用に精通している必要があり、アプリケーションシステム構造またはセキュリティ要件が変更されたら、大量の複雑かつ面倒な承認変更を実行するために、予期しない承認エラーによって引き起こされるセキュリティ脆弱性が非常に発生しやすい。したがって、大規模なアプリケーションシステムのために簡単かつ効率的な権限の管理方法を設計することは、システムとシステムユーザーの共通の要件になっている。
【０００６】
ロールベースの権限制御メカニズムにより、システムのアクセス権が簡単かつ効率的に管理できる。これにより、システム権限管理の負担とコストが大幅に削減され、さらに、システム権限管理は、アプリケーションシステムのビジネス管理仕様とより一致している。
【０００７】
ただし、従来のロールベースのユーザー権限管理は、「ロール対ユーザー、１対多」の関連付けメカニズムを採用し、「ロール」はグループ／クラスの性質を有する。つまり、１つのロールには複数のユーザーが同時期に対応／関連付できる。ロールは、役職／職務／職種の概念に似ている。この関連付けメカニズムに基づくユーザー権限の承認は、基本的に次の３つの形式に分けられる。１、図１に示すように、ユーザーは直接承認されるが、不利な点は、ワークロードが大きく、操作が頻繁且つ面倒であることである。２、図２に示すように、ロール（クラス／グループ／役職／職種）は承認され（１つのロールを複数のユーザーに関連付けることができる）、ユーザーはロールを介して権限を取得する。３、図３に示すように、上記の２つの方法が組み合わされている。
【０００８】
上記の説明では、２と３の両方にクラス／グループの性質を有するロールを承認する必要があり、クラス／グループ／役職／職種の性質を有するロールを介する承認及びワークフロー制御の方法には次の欠点がある。１、ユーザーのアクセス権限を変更する場合、難しい操作となる。実際のシステム使用プロセスでは、多くの場合、運用プロセス中にユーザーの権限を調整する必要がある。たとえば、従業員の権限の変更を処理する場合、ロールに関連付けられる従業員の権限を変更するが、ロールは権限を変更されない他の従業員にも関連付けられているので、個々の従業員の権限の変更のために、ロール全体の権限を変更することはできない。そのため、この状況に対応して、権限の変更された従業員に適うために新しいロールを設立するか、権限要件に基づいて従業員を直接承認（ロールからの離脱）する。上記の２つの処理方法は、ロールの権限が多数ある場合、ロールの承認に長い時間がかかるだけでなく、ミスを犯しやすく、ユーザーの操作がわずらわしく、面倒であり、システムユーザーの損失につながるエラーも発生しやすい。
【０００９】
２、ロールに含まれる特定の権限を長期的に覚えていることは困難である。ロールに複数の権限機能がある場合、時間が経つにつれて、ロールの特定の権限を覚えていることは困難になり、権限の類似したロール間の権限差別を覚えていることがより難しくなる。新しいユーザーを関連付けると、どうやって関連付けるかを正確に判断することはできない。
【００１０】
３、ユーザーの権限が変更されるために、ロールがますます設立されるということをもたらす（新しいロールを設立しない場合、ユーザーを直接承認する回数が大幅に増加する）。各ロール間の特定の差別を区別することはより困難である。
【００１１】
４、役職を調整するときに、異動するユーザーの多くの権限を他の複数のユーザーに割り当てる場合、異動するユーザーの権限を区分し、他の複数のユーザーを関連付けるためにそれぞれロールを設立する必要があるが、このような操作は、複雑であり、時間がかかるだけでなく、エラーがより発生しやすい。
【発明の概要】
【発明が解決しようとする課題】
【００１２】
本発明の目的は、現行技術の欠陥を克服し、第三者フィールドを介してフォームフィールドのフィールド値を承認する方法を提出し、第三者フィールドでフォームの被承認フィールドのフィールド値を制御することにより、きめ細かいフィールドのフィールド値の差別化承認を実現する。
【課題を解決するための手段】
【００１３】
本発明の目的は、以下の技術的手段により達成される。第三者フィールドを介してフォームフィールドのフィールド値を承認する方法は、（１）１つまたは複数の被承認者を選択すること；（２）承認しようとする一つフォームを選択し、前記フォームに第三者フィールドでそのフィールド値の検分権限の承認を制御する必要がある被承認フィールドを表示すること；（３）各被承認フィールドのために１つまたは複数の第三者フィールドをそれぞれ選択し、前記第三者フィールドは選択されたフォームの中のフィールドであり、前記第三者フィールドは、一つまたは複数のオプションを含むこと；（４）各第三者フィールドの各オプションに対応するフォームデータの被承認フィールドのフィールド値の検分権限をそれぞれ承認すること、を含み、ステップ（２）、（３）、（４）を順番に実行し、ステップ（１）がステップ（２）の前、ステップ（２）と（３）の間、ステップ（３）と（４）の間、またはステップ（４）後に実行される。
【００１４】
優先的に、前記被承認者は、人やユーザーやグループやクラスやロールのうちの一種または多種を含み、前記ロールは、グループ／クラスではなく、独立した個体であり、同時期に一つのロールが唯一のユーザーを関連付けることができ、一つのユーザーが１つまたは複数のロールを関連付ける。
【００１５】
優先的に、前記ロールは部門に属し、そのロールは部門に唯一であり、ロールの作業内容によりロールを承認し、ユーザーは関連するロールを介して承認を取得する。
【００１６】
優先的に、ユーザーは部門間で異動する時、ユーザーと元の部門内のロールの関連を取り消して、ユーザーを新しい部門のロールに関連付ける。
【００１７】
優先的に、前記第三者フィールドは時間特性フィールドと非時間特性フィールドを含み、前記時間特性フィールドのオプションが承認操作者に決定され、前記非時間特性フィールドのフィールド値が選択的に決定されまたは自動的に決定され、選択的に決定されるまたは自動的に決定される時の全てのオプションを非時間特性フィールドのオプションとする。
【００１８】
優先的に、前記時間特性フィールドのオプションは、現在時点から固定の時間を逆にして得られた時点から現在時点までの時間帯、開始時点から現在時点までの時間帯、終了時点からシステムの初期化時までの時間帯、開始時点から終了時点までの時間帯、時間フィールド値がヌル値である時間帯、システムの初期化時から現在時点までの時間帯の一つまたは複数を含み、前記のシステムの初期化時から現在時点までの時間帯は時間フィールド値がヌル値である時間帯を含む。
【００１９】
優先的に、被承認者が一つである場合、被承認者のそのフォームの被承認フィールドのフィールド値の検分権限は、被承認者のそのフォームの被承認フィールドのフィールド値が前回承認された時に保存された検分権限と表示し、被承認者が二つまたは三つ以上である場合、前記被承認者のそのフォームの被承認フィールドのフィールド値の検分権限を表示しない。
【００２０】
優先的に、検分権限を有しないフィールド値に対して、表示方式は、（１）そのフィールド値に対応するフィールドを表示するが、フィールド値を隠し符号で隠すこと；（２）フィールド値もフィールド値に対応するフィールドも表示されないことを含む。
【００２１】
第三者フィールドを介してフォームフィールドのフィールド値を承認する方法は、１つまたは複数の被承認者を選択すること；  承認しようとする一つフォームを選択し、そのフォームに第三者フィールドでそのフィールド値の検分権限の承認を制御する必要がある被承認フィールドを表示すること；  テンプレートを選択し、一つの既存の被承認者または作成されたテンプレートを選択して承認テンプレートとし、前記被承認者のそのフォームの被承認フィールドのフィールド値の検分権限を承認テンプレート中の相応のフィールドのフィールド値の検分権限に更新すること；  テンプレートを選択した後修正し続けるかどうかを判断し、修正し続ける場合に、各被承認フィールド（修正する必要がある）のために１つまたは複数の第三者フィールドをそれぞれ決定し、前記第三者フィールドは選択されたフォームの中のフィールドであり、前記第三者フィールドは、一つまたは複数のオプションを含み、各第三者フィールド（修正する必要がある）の各オプションのフォームデータの被承認フィールドのフィールド値の検分権限をそれぞれ承認／修正し、続いて保存すること；  テンプレートを選択した後修正し続けないとき、保存することを含む。
【００２２】
「各被承認フィールドのために１つまたは複数の第三者フィールドをそれぞれ決定する」というステップが「テンプレートを選択する」というステップの前にも置かれる。
【００２３】
第三者フィールドを介してフォームフィールドのフィールド値を承認する方法は、（１）１つまたは複数の被承認者を選択すること；（２）承認しようとする一つフォームを選択し、そのフォームに第三者フィールドでそのフィールド値の修正権限の承認を制御する必要がある被承認フィールドを表示すること；（３）各被承認フィールドのために１つまたは複数の第三者フィールドをそれぞれ選択し、前記第三者フィールドは選択されたフォームの中のフィールドであり、前記第三者フィールドは、一つまたは複数のオプションを含むこと；（４）各第三者フィールドの各オプションに対応するフォームデータの被承認フィールドのフィールド値の修正権限をそれぞれ承認すること、を含み、ステップ（２）、（３）、（４）を順番に実行し、ステップ（１）がステップ（２）の前、ステップ（２）と（３）の間、ステップ（３）と（４）の間、またはステップ（４）後に実行される。
【発明の効果】
【００２４】
本発明の有益な効果は次のとおりである：（１）本発明は、第三者フィールドがフォーム中のフィールド値の検分／修正権限を承認することを必要とする被承認フィールドを設定することにより、被承認者の検分／修正権限がその職責と一致するように設定でき、従って、被承認者が作業に関係のないフォーム情報（フォームのフィールド内容情報）を検分／修正することが防がれ、企業情報の漏洩の可能性を減らす。
【００２５】
（２）被承認者が一つである場合、被承認者のそのフォームの被承認フィールドのフィールド値の検分権限を、その被承認者のそのフォームの被承認フィールドのフィールド値が前回承認された時に保存された検分権限と表示するため、承認操作者がこれに基づいて修正するのに都合がよく、フォームの承認効率を向上させる。二つまたは三つ以上の被承認者を同時に承認することができるため、権限の完全に同じまたはほとんど同じである一括被承認者の承認効率を向上させる。
【００２６】
（３）被承認者のフォームの被承認フィールドのフィールド値の検分権限を承認テンプレート中の相応のフィールドのフィールド値の検分権限と更新し、フォームの承認効率を向上させる可能性があり、特に、権限の完全に同じまたはほとんど同じである大ロットのフォームの承認効率を向上させる。
【００２７】
（４）従来の権利管理メカニズムでは、ロールをグループ、職種、クラスなどと定義し、ロールがユーザーとの１対多の関係にあり。実際にシステムを使用するプロセスでは、運用プロセス中にユーザーの権限を調整する必要がある。たとえば、従業員の権限変更を処理する場合、ロールを関連付ける従業員の権限が変更されるが、このロールは権限の変更しない他の従業員を関連付けているので、個々の従業員の権限を変更するために、全体のロールの権限は変更できない。そのため、この状況に対応して、権限の変更された従業員に適うために新しいロールを設立するか、権限要件に基づいて従業員を直接承認（ロールからの離脱）する。上記の２つの処理方法は、ロールの権限が多数ある場合、ロールの承認に長い時間がかかるだけでなく、ミスを犯しやすく、ユーザーの操作がわずらわしく、面倒であり、システムユーザーの損失につながるエラーも発生しやすい。
【００２８】
しかし、本発明の方法では、ロールが独立した個体であるため、ロール権限を変更して目標を達成することができる。本発明の方法は、システムの初期化時にワークロードを増加させるように見えるが、ロールの作成または権限授与の効率を、コピーなどの方法によってグループの性質を有する従来のロールより高くさせる。ユーザーに関連つける時にグループの性質を有するロールの共通性を考慮しないため、この発明技術的手段は、承認設定を明確にさせる。特に、システムが一定期間使用された後（ユーザー／ロールの権限動的に変化している）、この発明技術的手段は、システム使用時のシステム管理の効率を大幅に向上させ、動的認証をより簡単、便利、明確にさせ、権限設定の効率と信頼性を向上させる。
【００２９】
（５）従来のグループの性質を有するロールの承認方法はエラーが発生しやすく、本発明の方法では、従来の方法でこのグループの性質を有するロールを関連付ける複数のユーザーにどのような共通性があるかを考慮することなく、ロールを独立した個体として考慮するだけでよいため、本発明の方法は権限エラーの確率を大幅に低減させる。承認エラーが発生した場合でも、ロールを関連付けるその一つのユーザーのみに影響するが、従来のグループの性質を有するロールはそのロールを関連付ける全部のユーザーに影響する。承認エラーが発生した場合でも、本発明の修正方法は簡単であり、時間が短く、従来のグループの性質を有するロールはエラーを修正する時にそのロールを関連付ける全部のユーザーの共通性を考えなければならない。機能ポイントが多い場合、変更が面倒且つ複雑であるだけでなく、非常にエラーが発生しやすく、且つ多くの場合、新しいロールを作成するだけで解決できる。
【００３０】
（６）従来のグループの性質を有するロールの承認方法では、ロールの権限機能ポイントが多くある場合、時間が長くなると、ロールの具体的な権限を覚えにくく、権限の近付くロールの間の区別を覚えているのはより困難である。本発明の方法のロール自身は、役職番号／職務番号の性質を有しており、選択は明らかである。
【００３１】
（７）異動するときに、異動されたユーザーの多くの権限を他のユーザーに割り当てる場合、処理する時に異動されたユーザーのこれ等の権限を区別して、他のユーザーを関連付けるためにロールをそれぞれ作成する必要がある。このような操作は、複雑であり、時間がかかるだけでなく、エラーが発生しやすくなる。
【００３２】
本発明の方法は次のとおりである：異動されたユーザーは複数のロールを関連付け、異動する場合、まずユーザーと元の部門の関連付けを取り消し（これ等の取り消されたロールを他のユーザーに再度関連付けることができる）、ユーザーは新しい部門のロールを関連付けてもよい。操作は簡単であり、エラーが現れない。
【００３３】
（８）ロールが部門に属している場合、ロールは部門が変更できず、ロールは部門が変更できないのはなぜですか？理由１：本発明のロールの性質は役職番号／職務番号と同等であるため、様々な役職番号／職務番号の作業内容／権限は異なる。例えば、販売部門の販売員１のロールと技術部門の開発者１のロールは、２つの役職番号／職務番号がまったく異なり、権限が違う。理由２：販売員１のロールの部門（販売部門）が技術部門に置き換えられる場合、販売員１のロールを変更しないと、技術部門には販売部門の権限を持つロールがある。これは、管理の混乱とセキュリティの脆弱性につながる可能性がある。
【図面の簡単な説明】
【００３４】
【図１】背景技術においてシステムがユーザーを直接承認する方法の概略図である。
【図２】背景技術においてシステムがグループ／クラスの性質を有するロールを承認する方法の概略図である。
【図３】背景技術においてシステムがユーザーを直接承認し、グループ／クラスの性質を有するロールを承認して組み合わせる方法の概略図である。
【図４】本発明の一種の実施例のフローチャートである。
【図５】本発明のシステムにおいて独立した個体の性質を有するロールを介してユーザーを承認する方法の概略図である。
【図６】本発明におけるフォームの概略図である。
【図７】図６に契約署名時間を選択した後の概略図である。
【図８】図６に顧客の所属する産業を選択した後の概略図である。
【図９】契約フォームの概略図である。
【図１０】本発明の他種の実施例のフローチャートである。
【図１１】承認テンプレートを選択した後のフォーム概略図である。
【図１２】本発明の他種の実施方式のフローチャートである。
【発明を実施するための形態】
【００３５】
本発明の技術的手段は、添付の図面を参照して以下でさらに詳細に説明されるが、本発明の保護範囲は以下に限定されない。
【実施例１】
【００３６】
図４に示すように、第三者フィールドを介してフォームフィールドのフィールド値を承認する方法は、１つまたは複数の被承認者を選択する。前記被承認者は、人やユーザーやグループやクラスやロールのうちの一種または多種を含み、前記ロールは、グループ／クラスではなく、独立した個体でり、同時期に一つのロールが唯一のユーザーを関連付けることができ、一つのユーザーが１つまたは複数のロールを関連付ける。
【００３７】
図５に示すように、前記ロールは部門に属し、ロールの作業内容によりロールを承認し、前記ロール名称は部門内で唯一であり、前記ロール番号はシステム内で唯一である。前記ユーザーはロールを関連付けるにより権限を確定し、一つの従業員は一つのユーザーに対応し、一つのユーザーは一つの従業員に対応する。
【００３８】
ロールの定義：ロールは、グループ／クラス／カテゴリ／役職／職務／職種の性質を有しないが、非集合の性質を有する。ロールは唯一性を有し、独立して存在している個体である。ロールは企業や機関の応用で役職番号と同等である（役職番号はここで役職ではなく、一つの役職に同時に複数の従業員がいるが、１つの役職番号は同時に一つの従業員にしか対応できない）。
【００３９】
たとえば、会社のシステムは次のロールを設立する可能性がある：総経理、副総経理１、副総経理２、北京販売部Ｉの経理、北京販売部ＩＩの経理、北京販売部ＩＩＩの経理、上海販売エンジニア１、上海販売エンジニア２、上海販売エンジニア３、上海販売エンジニア４、上海販売エンジニア５  等。ユーザーとロールの関連関係：その会社の従業員である張三は、会社の副総経理２を務め、同時に北京販売部Ｉの経理を務める場合、張三は副総経理２及び北京販売部Ｉの経理というロールを関連付ける必要がある。張三は両方のロールに対する権限を持っている。
【００４０】
従来のロールの概念は、グループ／クラス／役職／職務／職種の性質であり、１つのロールは複数のユーザーに対応できる。本発明の「ロール」の概念は、役職番号／職務番号と同等であり、映画やテレビドラマのロールに似ている。一つのロールは一つの俳優のみに同時に（幼年、少年、中年・・・）演じられ、一つの俳優は複数のロールを演じることができる。
【００４１】
前記ユーザーは部門間で異動する時、ユーザーと元の部門のロールの関連を取り消し、ユーザーを新しい部門のロールに関連付ける。ロールを作成した後、ユーザーを作成するプロセスでロールを関連付けることができ、または、ユーザーを作成した後、いつでもロールを関連付けることができる。ユーザーは、ロールを関連付けた後ロールとの関係がいつでも解除でき、他のロールとの関係がいつでも確立できる。
【００４２】
承認しようとする一つフォームを選択し、そのフォームに第三者フィールドで其れのフィールド値の検分権限の承認を制御する必要がある被承認フィールドを表示し、ここで、それは被承認フィールドを指す。図６に示すように、契約フォームは顧客名、製品数量、製品単価を含む。
【００４３】
被承認者が一つである場合、被承認者のそのフォームの被承認フィールドのフィールド値の検分権限は、被承認者のそのフォームの被承認フィールドのフィールド値が前回承認された時に保存された検分権限と表示する。被承認者が二つまたは三つ以上である場合、前記被承認者のそのフォームの被承認フィールドのフィールド値の検分権限を表示しない。
【００４４】
被承認者が一つである場合、被承認者とフォームを選定した後、被承認者のそのフォームの被承認フィールドのフィールド値の検分権限の前回承認された承認操作者と承認時間を表示する。被承認者の権限は誤りが発生する時責任を追究し、且つ被承認者のそのフォームの被承認フィールドのフィールド値が承認する必要とするかどうかを判断するのに都合がよい。図６に示すように、事務員１の契約フォームの被承認フィールドのフィールド値の検分権限の前回承認された承認操作者は張三であり、承認時間は２０１７年５月６日１５：００である。例えば、操作者は１００人のロールに対して契約フォームフィールド値を承認する必要があるが、即日、その操作者は７０人のロールに対する承認のみを完成した。その操作者は翌日に承認を続ける時、承認操作者またはフォームの被承認フィールドのフィールド値の検分権限の前回承認された時間を選別することにより、承認を必要とするロールを検索することができる。別の例として、ロールのフォームの被承認フィールドのフィールド値の検分権限の前回承認された時間を検分することにより、そのフォームの被承認フィールドのフィールド値の検分権限のどれくらい変更されていないかを知る可能性があり、そのフォームの被承認フィールドのフィールド値の検分権限を再度承認する必要があるかどうかを判断するのに都合がよい。
【００４５】
各被承認フィールドのために１つまたは複数の第三者フィールドをそれぞれ選択し、前記第三者フィールドは選択されたフォームの中のフィールドであり、前記第三者フィールドは、一つまたは複数のオプションを含む。図６に示すように、検分権限においては、被承認フィールド「顧客名」に選択された第三者フィールドは「契約署名時間」であり、被承認フィールド「製品単価」に選択された第三者フィールドは「顧客の所属する産業」である。
【００４６】
前記第三者フィールドは時間特性フィールドと非時間特性フィールドを含み、前記時間特性フィールドのオプションが承認操作者に決定される。前記非時間特性フィールドのフィールド値が選択的に決定され（たとえば、顧客フォームに顧客の所属する産業というフィールドのフィールド値は、製造、財務、航空などから選択でき、このようなフィールドに顧客レベル、部門などがあり、手動で記入しない。）または自動的に決定される（たとえば、フォーム作成者、記録者、フォーム製作ロール、フォーム作る人などのフィールドは、フォームデータが決定／保存されると、そのフォームのフィールド値が関連するルールに従って自動的に決定／保存される。たとえば、作成者（フィールド）のオプションはシステム全体の人であるが、作成者はフォームを作成するときにルールに従って自動的に取得される現在の人である）。選択的に決定されるまたは自動的に決定される時の全てのオプション（そのフィールドのフィールド値の全てのオプション）を非時間特性フィールドのオプション（その非時間特性フィールド）とする。
【００４７】
前記時間特性フィールドのオプションは、現在時点から固定の時間を逆にして得られた時点から現在時点までの時間帯、開始時点から現在時点までの時間帯、終了時点からシステムの初期化時までの時間帯、開始時点から終了時点までの時間帯、時間フィールド値がヌル値である時間帯、システムの初期化時から現在時点までの時間帯の一つまたは複数を含み、前記のシステムの初期化時から現在時点までの時間帯は時間フィールド値がヌル値である時間帯を含む。その中、現在時点から固定の時間を逆にして得られた時点から現在時点までの時間帯、開始時点から現在時点までの時間帯、終了時点からシステムの初期化時までの時間帯、開始時点から終了時点までの時間帯は、承認操作者が記入して決定し、時間フィールド値がヌル値である時間帯、システムの初期化時から現在時点までの時間帯は、承認操作者が選定して決定する。図７に示すように、第三者フィールドが「契約署名時間」として選択された後に表示される契約署名時間の４つのオプションのうち、開始時点から現在時点までの時間帯は、承認操作者が記入する。つまり、２０１６年１月１日から現在時点まで、時間フィールド値がヌル値である時間帯は、承認操作者が選択する。
【００４８】
以下は、例を挙げて上記の６つの時間帯を説明する。現在時点から固定の時間を逆にして得られた時点から現在時点までの時間帯は、例えば、２０１７年６月２０日に、従業員Ａに対しては、２０１７年６月２０日から６日間を逆にして得られた時点から２０１７年６月２０日までの時間帯に署名された（契約署名時間）契約フォーム（契約）の顧客名を検分する権限を与え、即ち、従業員Ａは、２０１７年６月２０日に、２０１７年６月１５日から２０１７年６月２０日まで署名された（契約署名時間）契約フォーム（契約）の顧客名（その顧客名はその顧客名フィールドの内容を参照し、以下も同じである）を即日検分することができ、２０１７年６月２１日に、２０１７年６月１６日から２０１７年６月２１日まで署名された（契約署名時間）契約フォーム（契約）の顧客名を即日検分することができ、２０１７年６月２２日に、２０１７年６月１７日から２０１７年６月２２日まで署名された（契約署名時間）契約フォーム（契約）の顧客名を即日検分することができ、その他もろもろ、枚挙にいとまがない。
【００４９】
開始時点から現在時点までの時間帯（現在時点は動態的である）は、例えば、従業員Ａに対しては、２０１５年５月１日に２０１５年２月１日から即日（現在）まで署名された（契約署名時間）契約フォーム（契約）の顧客名を検分する権限を与えると、従業員Ａは、２０１５年２月１日から２０１５年５月１日まで署名された（契約署名時間）全部の契約フォーム（契約）の顧客名を検分することができ、２０１５年５月２日に２０１５年２月１日から２０１５年５月２日まで署名された契約フォームの顧客名を検分することができる（さらに、開始時点は開始時点を含まないと説明でき、開始時点を含まない場合、２０１５年２月１日に署名された契約の顧客名を検分することができず、２０１５年２月１日以降署名された契約の顧客名のみを検分することができる）。
【００５０】
終了時点からシステムの初期化時までの時間帯は、例えば、従業員Ａに対しては、２０１５年２月１日からシステムの初期化時まで署名された（契約署名時間）契約フォーム（契約）の顧客名を検分する権限を与えると、従業員Ａは、２０１５年２月１日からシステムの初期化時まで署名された（契約署名時間）全部の契約フォーム（契約）の顧客名を検分することができる（即ち、従業員Ａは、２０１５年２月１日とその時点以前に署名されたシステム内の全ての契約の顧客名を検分することができる）；（さらに、終了時点は終了時点を含まないと説明でき、終了時点を含まない場合、２０１５年２月１日に署名された契約の顧客名を検分することができなく、２０１５年２月１日以前に署名された契約の顧客名のみを検分することができる。さらに、システムの初期化時が設定できず、終了時点のみを設定すると、従業員Ａは、終了時点とその以前に署名された全部の契約の顧客名を検分することができ、または、終了時点以前に署名された全部の契約の顧客名を検分することができる）。
【００５１】
開始時点から終了時点までの時間帯は、例えば、従業員Ａに対しては、２０１５年２月１日から２０１５年６月１日まで署名された（契約署名時間）契約フォーム（契約）の顧客名を検分する権限を与えると、従業員Ａは、２０１５年２月１日から２０１５年６月１日で署名された（契約署名時間）全部の契約フォーム（契約）の顧客名を検分することができる。
【００５２】
時間フィールド値がヌル値である時間帯は、例えば、契約の納期は記入必須項目ではない。契約フォーム（契約）に納期を書き入れない場合に、従業員Ａに対しては、納期の時間フィールド値がヌルである契約フォームの顧客名を検分する権限を与えると、従業員Ａは、納期が書き入れない全部の契約フォーム（契約）の顧客名を検分することができる。
【００５３】
システムの初期化時から現在時点までの時間帯（現在時点は動態的である）は、例えば、従業員Ａに対しては、２０１７年６月１日にシステムの初期化時から現在時点まで署名された（契約署名時間）契約フォームの顧客名を検分する権限を与えると、従業員Ａは、２０１７年６月１日に、システムの初期化時から２０１７年６月１日まで署名された（契約署名時間）全部の契約フォーム（契約）の顧客名を検分することができ、２０１７年６月２日に、システムの初期化時から２０１７年６月２日まで署名された（契約署名時間）全部の契約フォーム（契約）の顧客名を検分することができ、その他もろもろ、枚挙にいとまがない。前記システムの初期化時から現在時点までの時間帯は、時間フィールドがヌルである時間帯を含む（更に、システムの初期化時と現在時点の具体的な数値が設定されなく、従業員Ａに対しては、「システムの初期化時から現在時点までの時間帯」のその設置を設定したと、従業員Ａは、システムに何時でも署名され、ヌル値となる時間を含む全部の契約の顧客名を検分することができる）。
【００５４】
各第三者フィールドの各オプションに対応するフォームデータの被承認フィールドのフィールド値の検分権限をそれぞれ承認する。図８に示すように、第三者フィールドが「顧客の所属する産業」と選択された後表示された顧客の所属する産業に対応するフォームデータから「ヌル」と「電器」を選択し、ここで「ヌル」とは、所属する産業がヌルであることを意味する。つまり、事務員１は、電気産業（顧客の所属する産業が電器産業である）と所属する産業がヌルである（顧客の所属する産業がヌルであるか、顧客の所属する産業のフィールドはフィールド値／内容が存在しない）契約の製品単価の価格が検分できる。図８において「無制限」が選択されたと仮定すると、事務員１は、電気や機械等のすべての産業（後で追加される産業を含む）及び顧客の所属する産業のフィールド値がヌルである契約の製品単価の価格が検分できる。
【００５５】
検分権限を有しないフィールド値に対して、表示方式は、（１）そのフィールド値に対応するフィールドを表示するが、フィールド値を隠し符号で隠すこと；（２）フィールド値もフィールド値に対応するフィールドも表示されないことを含む。図９に示すように、ユーザが契約を検分する場合、ユーザは、顧客連絡方式及び連絡先の権限を持たないため、契約フォームを検分する時、連絡方式及び連絡先が「＊」と表示される。
【実施例２】
【００５６】
図１０に示すように、第三者フィールドを介してフォームフィールドのフィールド値を承認する方法は、１つまたは複数の被承認者を選択する。前記被承認者は、人やユーザーやグループやクラスやロールのうちの一種または多種を含み、前記ロールは、グループ／クラスではなく、独立した個体であり、同時期に一つのロールが唯一のユーザーを関連付けることができ、一つのユーザーが１つまたは複数のロールを関連付ける。前記ロールは部門に属し、そのロールは部門に唯一であり、ロールの作業内容によりロールを承認し、ユーザーは関連するロールを介して承認を取得する。ユーザーは部門間で異動する時、ユーザーと元の部門内のロールの関連を取り消して、ユーザーを新しい部門のロールに関連付ける。
【００５７】
承認しようとする一つフォームを選択し、そのフォームに第三者フィールドでそれのフィールド値の検分権限の承認を制御する必要がある被承認フィールドを表示し、ここで、それとは被承認フィールドを指す。
【００５８】
被承認者が一つである場合、被承認者のそのフォームの被承認フィールドのフィールド値の検分権限は、被承認者のそのフォームの被承認フィールドのフィールド値が前回承認された時に保存された検分権限と表示する。被承認者が二つまたは三つ以上である場合、前記被承認者のそのフォームの被承認フィールドのフィールド値の検分権限を表示しない。
【００５９】
被承認者が一つである場合、被承認者とフォームを選定した後、被承認者のそのフォームの被承認フィールドのフィールド値の検分権限の前回承認された承認操作者と承認時間を表示する。被承認者の権限は誤りが発生する時責任を追究し、且つ被承認者のそのフォームの被承認フィールドのフィールド値が承認する必要とするかどうかを判断するのに都合がよい。
【００６０】
テンプレートを選択し、一つの既存の被承認者または作成されたテンプレートを選択して承認テンプレートとし、前記被承認者のそのフォームの被承認フィールドのフィールド値の検分権限を承認テンプレート中の相応のフィールドのフィールド値の検分権限と更新する。図１１に示すように、作成されたテンプレート１を承認テンプレートとして選択する。
【００６１】
テンプレートを選択した後修正し続けるかどうかを判断し、修正し続ける場合に、各被承認フィールド（修正する必要がある）のために第三者フィールドをそれぞれ決定し、前記第三者フィールドは選択されたフォームの中のフィールドであり、前記第三者フィールドは、一つまたは複数のオプションを含み、各第三者フィールドの各オプションに対応するフォームデータの被承認フィールドのフィールド値の検分権限をそれぞれ承認し、続いて保存する。テンプレートを選択した後修正し続けないとき、保存する。
【００６２】
前記第三者フィールドは時間特性フィールドと非時間特性フィールドを含み、前記時間特性フィールドのオプションが承認操作者に決定される。前記非時間特性フィールドのフィールド値が選択的に決定され（たとえば、顧客フォームに顧客の所属する産業というフィールドのフィールド値は、製造、財務、航空などから選択でき、このようなフィールドに顧客レベル、部門などがあり、手動で記入しない。）または自動的に決定される（たとえば、フォーム作成者、記録者、フォーム製作ロール、フォーム作る人などのフィールドは、フォームデータが決定／保存されると、そのフォームのフィールド値が関連するルールに従って自動的に決定／保存される。たとえば、作成者（フィールド）のオプションはシステム全体の人であるが、作成者はフォームを作成するときにルールに従って自動的に取得される現在の人である）。選択的に決定されるまたは自動的に決定される時の全てのオプション（そのフィールドのフィールド値の全てのオプション）を非時間特性フィールドのオプション（その非時間特性フィールド）とする。
【００６３】
前記時間特性フィールドのオプションは、現在時点から固定の時間を逆にして得られた時点から現在時点までの時間帯、開始時点から現在時点までの時間帯、終了時点からシステムの初期化時までの時間帯、開始時点から終了時点までの時間帯、時間フィールド値がヌル値である時間帯、システムの初期化時から現在時点までの時間帯の一つまたは複数を含み、前記のシステムの初期化時から現在時点までの時間帯は時間フィールド値がヌル値である時間帯を含む。
【００６４】
検分権限を有しないフィールド値に対して、表示方式は、（１）そのフィールド値に対応するフィールドを表示するが、フィールド値を隠し符号で隠すこと；（２）フィールド値もフィールド値に対応するフィールドも表示されないことを含む。
【実施例３】
【００６５】
図１２に示すように、第三者フィールドを介してフォームフィールドのフィールド値を承認する方法は、１つまたは複数の被承認者を選択する。前記被承認者は、人やユーザーやグループやクラスやロールのうちの一種または多種を含み、前記ロールは、グループ／クラスではなく、独立した個体であり、同時期に一つのロールが唯一のユーザーを関連付けることができ、一つのユーザーが１つまたは複数のロールを関連付ける。前記ロールは部門に属し、そのロールは部門に唯一であり、ロールの作業内容によりロールを承認し、ユーザーは関連するロールを介して承認を取得する。ユーザーは部門間で異動する時、ユーザーと元の部門内のロールの関連を取り消して、ユーザーを新しい部門のロールに関連付ける。
【００６６】
承認しようとする一つフォームを選択し、そのフォームに第三者フィールドでそれのフィールド値の修正権限の承認を制御する必要がある被承認フィールドを表示し、ここで、それとは被承認フィールドを指す。
【００６７】
被承認者が一つである場合、被承認者のそのフォームの被承認フィールドのフィールド値の修正権限は、被承認者のそのフォームの被承認フィールドのフィールド値が前回承認された時に保存された修正権限を表示する。被承認者が二つまたは三つ以上である場合、前記被承認者のそのフォームの被承認フィールドのフィールド値の修正権限を表示しない。
【００６８】
被承認者が一つである場合、被承認者とフォームを選定した後、被承認者のそのフォームの被承認フィールドのフィールド値の修正権限の前回承認された承認操作者と承認時間を表示する。被承認者の権限は誤りが発生する時責任を追究し、且つ被承認者のそのフォームの被承認フィールドのフィールド値が承認する必要とするかどうかを判断するのに都合がよい。
【００６９】
各被承認フィールドのために１つまたは複数の第三者フィールドをそれぞれ選択し、前記第三者フィールドは選択されたフォームの中のフィールドであり、前記第三者フィールドは、一つまたは複数のオプションを含む。図６に示すように、修正権限においては、被承認フィールド「顧客名」に選択された第三者フィールドは「契約署名時間、契約署名者」であり、被承認フィールド「製品数量」に選択された第三者フィールドは「契約レベル」である。
【００７０】
前記第三者フィールドは時間特性フィールドと非時間特性フィールドを含み、前記時間特性フィールドのオプションが承認操作者に決定される。前記非時間特性フィールドのフィールド値が選択的に決定され（たとえば、顧客フォームに顧客の所属する産業というフィールドのフィールド値は、製造、財務、航空などから選択でき、このようなフィールドに顧客レベル、部門などがあり、手動で記入しない。）または自動的に決定される（たとえば、フォーム作成者、記録者、フォーム製作ロール、フォーム作る人などのフィールドは、フォームデータが決定／保存されると、そのフォームのフィールド値が関連するルールに従って自動的に決定／保存される。たとえば、作成者（フィールド）のオプションはシステム全体の人であるが、作成者はフォームを作成するときにルールに従って自動的に取得される現在の人である）。選択的に決定されるまたは自動的に決定される時の全てのオプション（そのフィールドのフィールド値の全てのオプション）を非時間特性フィールドのオプション（その非時間特性フィールド）とする。
【００７１】
前記時間特性フィールドのオプションは、現在時点から固定の時間を逆にして得られた時点から現在時点までの時間帯、開始時点から現在時点までの時間帯、終了時点からシステムの初期化時までの時間帯、開始時点から終了時点までの時間帯、時間フィールド値がヌル値である時間帯、システムの初期化時から現在時点までの時間帯の一つまたは複数を含み、前記のシステムの初期化時から現在時点までの時間帯は時間フィールド値がヌル値である時間帯を含む。
【００７２】
各第三者フィールドの各オプションに対応するフォームデータの被承認フィールドのフィールド値の修正権限をそれぞれ承認する。
【００７３】
修正権限を有しないフィールド値は、修正権限を有するフィールド及びフィールド値と区別して表示される。修正権限を有するフィールド及びフィールド値が黒色に表示されれば、修正権限を有しないフィールド及びフィールド値、又は修正権限を有しないフィールド値が灰色に表示される。
【００７４】
上記は本発明の優先的な実施形態だけである。本発明は、本明細書に開示された形態に限定されないと理解され、他の実施形態を除くとみなされなく、却って様々な他の組み合わせや修正や環境に利用でき、本明細書のコンセプトの範囲内で、上記の教示または関連分野の技術または知識により修正を行うことができる。当業者に行われる修正及び変更は、本発明の趣旨及び範囲から逸脱するものではなく、全部と本発明に添付される請求項の範囲内にあるべきである。
【図１】
2020528600.tif 000003
【図２】
2020528600.tif 000004
【図３】
2020528600.tif 000005
【図４】
2020528600.tif 000006
【図５】
2020528600.tif 000007
【図６】
2020528600.tif 000008
【図７】
2020528600.tif 000009
【図８】
2020528600.tif 000010
【図９】
2020528600.tif 000011
【図１０】
2020528600.tif 000012
【図１１】
2020528600.tif 000013
【図１２】
2020528600.tif 000014
【国際調査報告】
2020528600.tif 000015
2020528600.tif 000016
2020528600.tif 000017
2020528600.tif 000018
2020528600.tif 000019