JP7365609B2 - 全てのシステム使用者の最近の権限状態を表示する承認方法 - Google Patents

Description

本発明は、ＥＲＰ等の管理ソフトウェアシステムの承認方法に関し、特に全てのシステム使用者の最近の権限状態を表示する承認方法に関する。

ロールベースのアクセス制御（ＲＢＡＣ）は、近年最も多く研究されるし、最も成熟したデータベース権限管理メカニズムの一つであり、従来の強制アクセス制御（ＭＡＣ）および自律アクセス制御（ＤＡＣ）に代わる理想的な候補と考えられる。ロールベースのアクセス制御（ＲＢＡＣ）の基本的な考え方は、企業組織ビューのさまざまな機能的位置を分割して異なるロールを形成し、データベースリソースのアクセス権をロールにカプセル化するに従って、ユーザーは、異なるロールを割り当てられることにより、データベースリソースに間接的にアクセスする。

大量のテーブルとビューが大規模なアプリケーションシステムに組み込まれているため、データベースリソースの管理と承認が非常に複雑になる。ユーザーがデータベースリソースのアクセスと権限承認を直接管理することは非常に困難である。ユーザーはデータベース構造を十分に理解し、ＳＱＬ言語の使用に精通している必要があり、アプリケーションシステム構造またはセキュリティ要件が変更されたら、大量の複雑かつ面倒な承認変更を実行するために、予期しない承認エラーに引き起こされるセキュリティ脆弱性が非常に発生しやすい。したがって、大規模なアプリケーションシステムのために簡単かつ効率的な権限の管理方法を設計することは、システムとシステムユーザーの共通の要件になっている。

ロールベースの権限制御メカニズムにより、システムのアクセス権が簡単かつ効率的に管理できる。これにより、システム権限管理の負担とコストが大幅に削減され、さらに、システム権限管理は、アプリケーションシステムのビジネス管理仕様とより一致している。

ただし、従来のロールベースのユーザー権限管理は、「ロール対ユーザー、１対多」の関連付けメカニズムを採用し、「ロール」はグループ／クラスの性質を有する。つまり、一つのロールは複数のユーザーが同時期に対応／関連付けできる。ロールは、役職／職務／職種の概念に似ている。この関連付けメカニズムに基づくユーザー権限の承認は、基本的に次の３つの形式に分けられる。１、図１に示すように、ユーザーが直接承認されるが、不利な点は、ワークロードが大きく、操作が頻繁且つ面倒である。２、図２に示すように、ロール（クラス／グループ／役職／職種）は承認され（一つのロールを複数のユーザーに関連付けることができる）、ユーザーはロールを介して権限を取得する。３、図３に示すように、上記の２つの方法が組み合わされている。

上記の説明では、２と３の両方にクラス／グループの性質を有するロールを承認する必要があり、クラス／グループ／役職／職種の性質を有するロールを介する承認及びワークフロー制御の方法には次の欠点がある。１、ユーザーのアクセス権限が変わる場合、操作が難しくなる。実際のシステム使用プロセスでは、多くの場合、運用プロセス中にユーザーの権限を調整する必要がある。例えば、従業員の権限の変更を処理する場合、ロールの関連付けた従業員の権限を変更するが、ロールは権限の変更されない他の従業員も関連付けたことで、個々の従業員の権限の変更により、ロール全体の権限を変更することができない。そのため、この状況に対応して、権限を変更した従業員に適う新しいロールを作成するか、権限要件に基づいて従業員を直接承認（ロールからの離脱）する。上記の２つの処理方法は、ロールの権限が多数ある場合、ロールの承認に長い時間がかかるだけでなく、ミスを犯しやすく、ユーザーの操作がわずらわしく、面倒であり、システムユーザーの損失につながるエラーも発生しやすい。

２、ロールを含む特定の権限を長期的に覚えることは困難である。ロールに複数の権限機能がある場合、時間が経つにつれて、ロールの特定の権限を覚えることは困難になり、権限の類似したロール間の権限差別を覚えるのがより難しくなる。新しいユーザーを関連付けると、どうやって関連付けるかを正確に判断することはできない。

３、ユーザーの権限が変わるため、ロールをますます作成するのをもたらす（新しいロールを作成しない場合、ユーザーを直接承認するのが大幅に増加する）。各ロール間の特定の差別を区別することはより困難である。

４、役職を調整するときに、異動するユーザーの多くの権限を他の複数のユーザーに割り当てる場合、異動するユーザーの権限を区分し、他の複数のユーザーを関連付けるためにそれぞれロールを作成する必要があるが、このような操作は、複雑であり、時間がかかるだけでなく、エラーがより発生しやすい。

図４に示すように、現有のフォーム等の承認方法では、二つ或いは二つ以上の従業員を選択した後、一つのフォームをもう一度選択すると、選定された従業員の選定されたフォームに対する状態を表示することができない。同様に、一つのフォームを選択した後、二つ或いは二つ以上の従業員をもう一度選択すると、選定された従業員の選定されたフォームに対する状態を表示することができない。複数のユーザーを同時に承認する時に承認操作者に間違わせやすい。

システムを使用する時に、管理需要によりいつも権限を調整する必要がある。例えば、会社は管理需要により、今に顧客フォームの顧客電話フィールド（フィールドのフィールド内容）に対して検分／修正権限を調整する必要があり（例えば、検分権限を有する一部のユーザーが検分権限を有しないように調整され、検分権限を有しない一部のユーザーが検分権限を有するように調整され、修正権限を有しない一部のユーザーが修正権限を有するように調整され、修正権限を有しない一部のユーザーが修正権限を有するように調整され、一部のユーザーの権限を調整しない）、現有の方法は、ユーザーとフォームを順次選択し、又は、フォームとユーザーを順次選択することしかできず、その後に、フォームの顧客電話フィールドを承認する。ユーザーを一つずつ承認すると、作業量が大きくなり、且つ間違いやすい。複数或いは全部のユーザーを選択して承認すると、その顧客電話フィールドを全て一括承認することしかできない。一旦承認を行うと、選定された全てのユーザーは同じ権限を持ち、しかも区別して承認できない。最も重要なことは、各ユーザーの顧客電話フィールドを承認する状態を表示することができず、この前に各ユーザーの承認状態に対して顧客電話フィールドを参照しないと、承認操作者はこれらのユーザーがこの前にその顧客電話フィールドを承認する状態を知らず、承認操作者が承認を間違いやすい。

本発明の目的は、現行技術の欠陥を克服し、全てのシステム使用者の最近の権限状態を表示する承認方法を提供し、システム中の全てのシステム使用者を表示した後、各システム使用者の選定した要素項に対する最近の権限状態を表示する。承認操作者がここに基づいて修正し、システム使用者の選定した要素項を承認することを実現するのに都合がよく、承認効率が向上し、承認誤り率を大幅に低減する。

本発明の目的は、以下の技術的手段により達成される。全てのシステム使用者の最近の権限状態を表示する承認方法は、一つのフォームを選定すること；前記フォームの一種のフォーム要素の一つの要素項を選択すること；前記要素項を選定した後、システム中の全てのシステム使用者を表示し、且つ各システム使用者の選定した要素項に対する最近の権限状態を表示すること；一つ或いは複数の前記システム使用者に対して選定した要素項を承認することを含む。

優先的に、前記フォーム要素の種類はフォーム操作権限とフォームフィールドと時間特性フィールドとフォームフィールド値のうちの一種或いは複数種を含み、前記フォームフィールド値は選択確定或いは自動確定される。

優先的に、前記システム使用者はロール、ユーザー、従業員、グループ、クラス、またはテンプレートのうちの一種或いは複数種を含み、前記ロールはグループ／クラスではなく、独立した個体であり、一つのロールは同時期に唯一のユーザーを関連付けることができ、一人のユーザーは一つ或いは複数のロールを関連付ける。

優先的に、ロールを作成した時或いは後に前記ロールのために一つの部門を選定すると、前記ロールが前記部門に属し、ロールの作業内容によりロールを承認し、且つ前記ロールの名称が前記部門に唯一であり、前記ロールの番号がシステムに唯一である。前記ユーザーが異動する時、ユーザーと元のロールの関連を取り消して、ユーザーを新しいロールに関連付ける。

優先的に、一種のフォーム要素の一つの要素項を選定した後、各システム使用者に対して選定した要素項を前回承認した操作者及び承認時間をそれぞれ表示する。

全てのシステム使用者の最近の権限状態を表示する承認方法は、一つの統計列表を選定すること；前記統計列表の一種の統計列表要素の一つの要素項を選択すること；前記要素項を選定した後、システム中の全てのシステム使用者を表示し、且つ各システム使用者の選定した要素項に対する最近の権限状態を表示すること；一つ或いは複数の前記システム使用者に対して選定した要素項を承認することを含む。

優先的に、前記統計列表要素の種類は統計列表操作権限と統計列表の列名と時間特性列名と統計列表の列名値のうちの一種或いは複数種を含み、前記統計列表の列名値は選択確定或いは自動確定される。

優先的に、前記システム使用者はロール、ユーザー、従業員、グループ、クラス、またはテンプレートのうちの一種或いは複数種を含み、前記ロールはグループ／クラスではなく、独立した個体であり、一つのロールは同時期に唯一のユーザーを関連付けることができ、一人のユーザーは一つ或いは複数のロールを関連付ける。

全てのシステム使用者の最近の権限状態を表示する承認方法は、一つのメニューを選定すること；前記メニューを選定した後、システム中の全てのシステム使用者を表示し、且つ各システム使用者の選定したメニューに対する最近の権限状態を表示すること；一つ或いは複数の前記システム使用者に対して選定したメニューを承認することを含む。

優先的に、前記システム使用者はロール、ユーザー、従業員、グループ、クラス、またはテンプレートのうちの一種或いは複数種を含み、前記ロールはグループ／クラスではなく、独立した個体であり、一つのロールは同時期に唯一のユーザーを関連付けることができ、一人のユーザーは一つ或いは複数のロールを関連付ける。

本発明の有益な効果は次のとおりである：（１）本発明に、システム中の全てのシステム使用者を表示した後、各システム使用者の選定した要素項に対する最近の権限状態を表示する。承認操作者がここに基づいて修正し、システム使用者の選定した要素項を承認することを実現するのに都合がよく、承認効率が向上し、承認誤り率を大幅に低減する。

（２）本発明は、承認を行う時、システム中の全てのシステム使用者を表示し、承認遺脱等の状況が現れない。

（３）一種のフォーム要素の一つの要素項を選定した後、各システム使用者に対して選定した要素項を前回承認した操作者及び承認時間をそれぞれ表示し、システム使用者の権限は間違いになる時責任を探し出し並びにシステム使用者が承認する必要があるかどうかを判断するのに都合がよい。

（４）従来の権利管理メカニズムでは、ロールをグループ、職種、クラスなどに定義し、ロールがユーザーとの１対多の関係にあり、実際にシステムを使用するプロセスでは、運用プロセス中にユーザーの権限を調整する必要がある。例えば、従業員の権限変更を処理する場合、ロールを関連付ける従業員の権限が変更され、このロールは権限の変更しない他の従業員を関連付けるので、個々の従業員の権限を変更したため、全体のロールの権限が変更できない。そのため、この状況に対応して、権限の変更された従業員に適う新しいロールを作成するか、権限要件に基づいて従業員を直接承認（ロールからの離脱）する。上記の２つの処理方法は、ロールの権限が多数ある場合、ロールの承認に長い時間がかかるだけでなく、ミスを犯しやすく、ユーザーの操作がわずらわしく、面倒であり、システムユーザーの損失につながるエラーも発生しやすい。

しかし、本発明の方法では、ロールが独立した個体であるため、ロール権限を変更して目標を達成することができる。本発明の方法は、システムの初期化時にワークロードを増加させるように見えるが、ロールの作成或いは権限授与の効率は、コピーなどの方法によってグループの性質を有する従来のロールより高くなる。ユーザーを関連つける時にグループの性質を有するロールの共通性を考慮しないため、この発明技術的手段は、承認設定を明確にする。特に、システムが一定期間使用された後（ユーザー／ロールの権限が動的に変化している）、この発明技術的手段は、システム使用時のシステム管理の効率を大幅に向上させ、動的承認をより簡単、便利、明確にし、権限設定の効率と信頼性を向上させる。

（５）従来のグループ／クラスの性質を有するロールの承認方法はエラーが発生しやすく、本発明の方法では、従来の方法でこのグループの性質を有するロールを関連付ける複数のユーザーにどのような共通性があるかを考慮することなく、ロールを独立した個体として考慮するだけでよいため、本発明の方法は権限エラーの確率を大幅に低減させる。承認エラーが発生した場合でも、ロールを関連付けるその一人のユーザーのみに影響するが、従来のグループの性質を有するロールは前記ロールを関連付ける全部のユーザーに影響する。承認エラーが発生した場合でも、本発明の修正方法は簡単であり、時間が短く、従来のグループの性質を有するロールはエラーを修正する時に前記ロールを関連付ける全部のユーザーの共通性を考えなければならない。機能ポイントが多い場合、変更が面倒且つ複雑であるだけでなく、非常にエラーが発生しやすく、且つ多くの場合、新しいロールを作成するだけで解決できる。

（６）従来のグループの性質を有するロールの承認方法では、ロールの権限機能ポイントが多くある場合、時間が長くなると、ロールの具体的な権限を覚えにくく、権限の近いロールの間の区別を覚えるのはより困難である。新しいロールを関連付けると、どうやって選択して関連付けるべきであるかを確かに判断することができない。本発明の方法のロール自身は、役職番号／職務番号の性質を有しており、一つのロールは一つの役職番号／職務番号に相当し、選択は明らかである。

（７）異動するときに、異動されたユーザーの多くの権限を他のユーザーに割り当てる場合、処理する時に異動されたユーザーのこれらの権限を区別して、他のユーザーを関連付けるようにロールをそれぞれ作成する必要がある。このような操作は、複雑であり、時間がかかるだけでなく、エラーが発生しやすくなる。

本発明の方法は次のとおりである：異動されたユーザーはいくつかのロールを関連付け、異動する場合、まずユーザーと元の部門のロールの関連を取り消し（役職番号／職務番号を置き換えるしかなければ、一つのロールを取り消してもよい。取り消されたロールを他のユーザーに再度関連付けることもできる）、ユーザーは新しいロールを関連付けてもよい。操作は簡単であり、エラーが現れない。

（８）ロールを作成する時或いは後、一つの部門を選定する必要として前記ロールが前記部門に属した後、部門が変更できず、ロールは部門が変更できないのはなぜであるか？理由１：本発明のロールの性質は役職番号／職務番号と同等であるため、様々な役職番号／職務番号の作業内容／権限は異なる。例えば、販売部門の販売員１のロールと技術部門の開発者１のロールは、２つの役職番号／職務番号がまったく異なり、権限が違う。理由２：販売員１のロールの部門（販売部門）が技術部門に置き換えられる場合、販売員１のロールを変更しないと、技術部門には販売部門の権限を有するロールがある。これは、管理の混乱とセキュリティの脆弱性につながる可能性がある。

背景技術においてシステムがユーザーを直接承認する方法の概略図である。 背景技術においてシステムがグループ／クラスの性質を有するロールを承認する方法の概略図である。 背景技術においてシステムがユーザーを直接承認し、グループ／クラスの性質を有するロールを承認して組み合わせる方法の概略図である。 現行技術において複数のユーザーを承認する概略図である。 本発明においてシステム使用者のためにフォーム承認を行うフローチャートである。 本発明において一つのフォーム要素の要素項を選定した後の概略図である。 本発明においてもう一つのフォーム要素の要素項を選定した後の概略図である。 本発明においてもう一つのフォーム要素の要素項を選定した後の概略図である。 本発明においてもう一つのフォーム要素の要素項を選定した後の概略図である。 本発明のシステムにおいて独立した個体の性質を有するロールを介してユーザーを承認する方法の概略図である。 本発明においてシステム使用者のために統計列表の承認を行うフローチャートである。 は、本発明においてシステム使用者のためメニュー承認を行うフローチャートである。

本発明の技術的手段は、添付の図面を参照して以下でさらに詳細に説明されるが、本発明の保護範囲は以下に限定されない。

図５に示すように、全てのシステム使用者の最近の権限状態を表示する承認方法は、以下のステップを含む。Ｓ１１、一つのフォームを選定する。

例えば、図６に示すように、顧客フォームを選定する。

Ｓ１２、前記フォームの一種のフォーム要素の一つの要素項を選択する。

前記フォーム要素の種類はフォーム操作権限とフォームフィールドと時間特性フィールドとフォームフィールド値のうちの一種或いは複数種を含み、前記フォームフィールド値は選択確定或いは自動確定される。

前記フォーム操作権限の要素項は、追加や削除や検分や相関情報の検分や印刷や導入や導出等のうちの一種或いは複数種を含む。例えば、顧客フォームの前記フォームフィールドの要素項は、顧客名称や顧客業界や顧客住所等（即ち、フォームのフィールド）を含む。前記フォームフィールド値の要素項は、フィールドのフィールド値であり、ここにフィールド値の選択確定或いは自動確定になるフィールド値を特に指す。例えば、顧客フォーム中の顧客級別のオプション値「一級、二級、三級…」、又は顧客業界フィールドのオプション値「ソフトウェア、化工、建材…」、又は顧客の責任部門フィールドのオプション値「販売一部、販売二部、販売三部…」、又は顧客の責任者フィールドのオプション値「張三、李四、王五…」、又は顧客の住所地フィールドのオプション値「北京、上海、広州…」等（フォームフィールド値の種類は、承認する必要があるのはフィールド値であるが、そのフィールド値に対応するフィールドでない）、且つフィールドごとのフィールド値には一つのヌル及び全てのフィールド値を含む（ヌルは「ファイルがヌルである」を表し、全ては「全てのフィールド値」を表す）。前記時間特性フィールドの要素項は、時間の性質を有するフィールドであり、例えば、フォームの作成時間と最近修正時間等のフィールド（ここで「フォームの作成時間、最近修正時間」は、時間特性フィールドの要素項であり、顧客フォームの要素項でもある）である。その中に、相関情報の検分は、そのフォームの相関情報の検分操作機能であり、例えば、顧客フォームの相関情報の検分は関連契約の検分や関連注文の検分や集金記録や出荷記録等の検分操作である。

フォーム要素の種類はフォームフィールド値である時に、その要素項に対して承認操作を行うのは実質的にその要素項に対するフォームデータを承認することである（フォームデータを例にとって、例えば、顧客フォームには某顧客は顧客フォームデータとなる）。

例えば、図６に示すように、顧客フォームにフォーム操作権限中（フォーム要素）の検分（要素項）を選定する。

前記フォームフィールド値は選択確定（例えば、顧客フォームに顧客業界というフィールドのフィールド値には製造や金融や航空等の業界オプションがあってフォーム操作者に選択される。例えば、契約フォームに契約署名者というフィールドのフィールド値には張三や李四や王五等の会社職員オプションがあってフォーム操作者に選択される。これらのフィールド値を人工で記入しなくて選択方式で取得する。例えば、契約フォームに契約級別や顧客所在地や契約署名部門や契約責任部門や契約執行者や契約責任ロール等というフィールドのフィールド値も選択的である）或いは自動確定（例えば、契約フォームに契約作成者というフィールドのフィールド値には張三や李四や王五等の会社職員オプションがあるが、その顧客を作成する時に作成者の値は、最近の操作者を自動的に取得して作成者とする。記録者やフォーム製作ロールやフォーム作る人等のフィールドのフィールド値も同じであり、この様なフィールドのフィールド値を相関規則により自動的に確定する）される。

更に、時間特性フィールドの一つの要素項を選定した後、全てのシステム使用者及び各使用者の六種の時間帯の設置様式を表示して相応時間を設定するのに承認操作者に提出する。前記六種の時間帯の設置様式は、現在時点から固定の時間を逆にして得られた時点から現在時点までの時間帯、開始時点から現在時点までの時間帯、終了時点からシステムの初期化時までの時間帯、開始時点から終了時点までの時間帯、時間フィールド値がヌル値である時間帯、システムの初期化時から現在時点までの時間帯を含む。前記システムの初期化時から現在時点までの時間帯は時間フィールド値のヌル値である時間帯を含む。前記開始時点と終了時点を承認操作者で設定する。

以下は、例を挙げて上記の６つの時間帯を説明する。現在時点から固定の時間を逆にして得られた時点から現在時点までの時間帯は、例えば、２０１７年６月２０日に、従業員Ａに対しては、２０１７年６月２０日から６日間を逆にして得られた時点から２０１７年６月２０日まで（即ち、現在時点、確定時点ではない）の時間帯に署名された契約フォーム（契約）を検分する権限を与え、即ち、従業員Ａは、２０１７年６月２０日に、２０１７年６月１５日から２０１７年６月２０日まで署名された契約フォーム（契約）を即日検分することができ、２０１７年６月２１日に、２０１７年６月１６日から２０１７年６月２１日まで署名された契約フォーム（契約）を即日検分することができ、２０１７年６月２２日に、２０１７年６月１７日から２０１７年６月２２日まで署名された契約フォーム（契約）を即日検分することができ、その他もろもろ、枚挙にいとまがない。つまり、この時間帯の時間の長さは固定であり、開始時点と終了時点は全て動的である。

開始時点から現在時点までの時間帯（現在時点は動態的である）は、例えば、従業員Ａに対しては、２０１５年５月１日に２０１５年２月１日から即日（現在時点）まで署名された契約フォームを検分する権限を与えると、従業員Ａは、２０１５年２月１日から２０１５年５月１日まで署名された全部の契約フォーム（契約）を検分することができ、２０１５年５月２日に２０１５年２月１日から２０１５年５月２日まで署名された契約フォーム（契約）を検分することができる（さらに、開始時点は開始時点を含まないと言い表すことができ、開始時点を含まない場合、２０１５年２月１日に署名された契約を検分することができず、２０１５年２月１日以降署名された全部の契約を検分することしかできない）。

終了時点からシステムの初期化時までの時間帯は、例えば、従業員Ａに対しては、２０１５年２月１日からシステムの初期化時まで署名された契約フォーム（契約）を検分する権限を与えると、従業員Ａは、２０１５年２月１日からシステムの初期化時まで署名された全部の契約フォーム／契約を検分することができる（即ち、従業員Ａは、２０１５年２月１日とその時点以前に署名されたシステム内の全ての契約を検分することができる）；（さらに、終了時点は終了時点を含まないと説明でき、終了時点を含まない場合、２０１５年２月１日に署名された契約を検分することができず、２０１５年２月１日以前に署名された契約のみを検分することができる。さらに、システムの初期化時が設定できず、終了時点のみを設定すると、従業員Ａは、終了時点とその以前に署名された全部の契約を検分することができ、または、終了時点以前に署名された全部の契約を検分することができる）。

開始時点から終了時点までの時間帯は、例えば、従業員Ａに対しては、２０１５年２月１日から２０１５年６月１日まで署名された契約フォーム（契約）を検分する権限を与えると、従業員Ａは、２０１５年２月１日から２０１５年６月１日で署名された全部の契約フォーム（契約）を検分することができる。

時間フィールド値がヌル値である時間帯は、例えば、契約の納期は記入必須項目ではない。契約フォーム（契約）に納期を書き入れない場合に、従業員Ａに対しては、納期の時間フィールド値がヌルである契約フォーム（契約）を検分する権限を与えると、従業員Ａは、納期が書き入れない全部の契約フォーム（契約）を検分することができる。

システムの初期化時から現在時点までの時間帯（現在時点は動態的である）は、例えば、従業員Ａに対しては、２０１７年６月１日にシステムの初期化時から現在時点まで署名された契約フォーム（契約）を検分する権限を与えると、従業員Ａは、２０１７年６月１日に、システムの初期化時から２０１７年６月１日まで署名された全部の契約フォーム（契約）を検分することができ、２０１７年６月２日に、システムの初期化時から２０１７年６月２日まで署名された全部の契約フォーム（契約）を検分することができ、その他もろもろ、枚挙にいとまがない。前記システムの初期化時から現在時点までの時間帯は、時間フィールドがヌルである時間帯を含む（更に、システムの初期化時と現在時点の具体的な数値が設定されず、従業員Ａに対しては、「システムの初期化時から現在時点までの時間帯」のその設置を設定すると、従業員Ａは、システムに何時でも調印され、ヌル値となる時間を含む全部の契約を検分することができる）。

前記開始時点と終了時点を承認操作者で設定する。

Ｓ１３、前記要素項を選定した後、システム中の全てのシステム使用者を表示し、且つ各システム使用者の選定した要素項に対する最近の権限状態を表示する。

例えば、図６に示すように、検分（要素項）を選定した後、ユーザーＡやユーザーＢやユーザーＣやユーザーＤやユーザーＥやユーザーＦ等のシステム使用者を表示し、その中に、ユーザーＡ、ユーザーＤ、ユーザーＦは全てその権限を現在持っている。

更に、一種のフォーム要素の一つの要素項を選定した後、各システム使用者に対して選定した要素項を前回承認した操作者及び承認時間をそれぞれ表示し、そのシステム使用者が承認を行う必要があるかどうかを判断するのに都合がよい。例えば、某承認操作者は１００個のロールに対して承認操作を行う必要があるが、即日、その承認操作者は７０個のロールに対する承認操作のみを完成した。その承認操作者は翌日に承認を続ける時、承認操作者或いはロールの前回承認された時間を選別することにより、承認する必要があるロールを見つける。例えば、某ロールの前回承認された時間を検分することにより、前記ロールが変更していない期間を知ることができるのは、前記ロールを再承認する必要があるかどうかを判断するのに都合がよい。

例えば、図６に示すように、ユーザーＡ、ユーザーＢ、ユーザーＣ、ユーザーＤ、ユーザーＥ、ユーザーＦに対して顧客フォームのフォーム操作権限の検分を前回承認した承認操作者はユーザーＢであり、ユーザーＡ、ユーザーＢ、ユーザーＣに対して顧客フォームのフォーム操作権限の検分を前回承認した時間は、２０１６年５月１日であり、ユーザーＤ、ユーザーＥ、ユーザーＦに対して顧客フォームのフォーム操作権限の検分を前回承認した時間は２０１７年５月１日である。

図７に示すように、顧客フォームのフォーム操作権限（フォーム要素）の削除を選定する。削除（要素項）を選定した後、ユーザーＡ、ユーザーＢ、ユーザーＣ、ユーザーＤ、ユーザーＥ、ユーザーＦ等のシステム使用者を表示し、その中に、ユーザーＡ、ユーザーＤ、ユーザーＥ、ユーザーＦは全てその権限を現在持っている。ユーザーＡ、ユーザーＢ、ユーザーＣ、ユーザーＤ、ユーザーＥ、ユーザーＦに対して顧客フォームのフォーム操作権限の削除を前回承認した承認操作者はユーザーＢであり、ユーザーＡ、ユーザーＢ、ユーザーＣに対して顧客フォームのフォーム操作権限の削除を前回承認した時間は、２０１６年５月１日であり、ユーザーＤ、ユーザーＥ、ユーザーＦに対して顧客フォームのフォーム操作権限の削除を前回承認した時間は２０１７年５月１日である。

図８に示すように、顧客フォームのフォームフィールド（フォーム要素）の顧客名称（要素項）を選定する。顧客名称（要素項）を選定した後、ユーザーＡ、ユーザーＢ、ユーザーＣ、ユーザーＤ、ユーザーＥ、ユーザーＦ等のシステム使用者を表示し、その中に、ユーザーＡ、ユーザーＤ、ユーザーＥは全て顧客名称を検分し修正する権限を現在持っている。ユーザーＡ、ユーザーＢ、ユーザーＣ、ユーザーＤ、ユーザーＥ、ユーザーＦに対して顧客フォームのフォームフィールドの操作権限の検分及び修正を前回承認した承認操作者はユーザーＢであり、ユーザーＡ、ユーザーＢ、ユーザーＣに対して顧客フォームのフォームフィールドの操作権限の検分及び修正を前回承認した時間は、２０１６年５月１日であり、ユーザーＤ、ユーザーＥ、ユーザーＦに対して顧客フォームのフォームフィールドの操作権限の検分及び修正を前回承認した時間は２０１７年５月１日である。

図９に示すように、顧客フォームの時間特性フィールド（フォーム要素）の作成時間（要素項）を選定する。作成時間（要素項）を選定した後、ユーザーＡ、ユーザーＢ、ユーザーＣ、ユーザーＤ等のシステム使用者を表示し、その中に、ユーザーＢの最近の時間帯は今から５日間を逆にして得られた時点から今までの時間帯であり、ユーザーＣの最近の時間帯はシステムの初期化時から現在時点までの時間帯である。その中に、時間帯を設定する時、時間帯Ａ、時間帯Ｂ、時間帯Ｃ、時間帯Ｄは元の承認状態に基づいて選定し、時間帯Ｅ、時間帯Ｆは元の承認状態に基づいて選定する。

図９に示すように、時間帯Ａは現在時点から固定の時間を逆にして得られた時点から現在時点までの時間帯を表し、時間帯Ｂは開始時点から現在時点までの時間帯を表し、時間帯Ｃは終了時点からシステムの初期化時までの時間帯を表し、時間帯Ｄは開始時点から終了時点までの時間帯を表し、時間帯Ｅは時間フィールド値がヌル値である時間帯を表し、時間帯Ｆはシステムの初期化時から現在時点までの時間帯を表す。

更に、前記要素項を選定した後、システム中の全てのシステム使用者を表示し、前記「システム中の全てのシステム使用者」は「システム中のその選択操作者の権限の承認できる全てのシステム使用者」である。

前記システム使用者はロール、ユーザー、従業員、グループ、クラス、またはテンプレートのうちの一種或いは複数種を含む。

図１０に示すように、前記ロールはグループ／クラスではなく、独立した個体であり、一つのロールは同時期に唯一のユーザーを関連付けることができ、一人のユーザーは一つ或いは複数のロールを関連付ける。ユーザーは関連ロールの権限を取得する。ロールを作成した時或いは後に前記ロールのために一つの部門を選定すると、前記ロールが前記部門に属し、ロールの作業内容によりロールを承認し、且つ前記ロールの名称が前記部門に唯一であり、前記ロールの番号がシステムに唯一である。

ロールの定義：ロールは、グループ／クラス／カテゴリ／役職／職務／職種の性質を有しないが、非集合の性質を有する。ロールは唯一性を有し、独立して存在している個体である。ロールは企業や機関の応用で役職番号と同等である（ここで役職番号は役職ではなく、一つの役職に同時に複数の従業員がいるが、一つの役職番号は同時に一つの従業員にしか対応できない）。

例えば、会社のシステムは次のロールを作成する可能性がある：総経理、副総経理１、副総経理２、北京販売部Ｉの経理、北京販売部ＩＩの経理、北京販売部ＩＩＩの経理、上海販売エンジニア１、上海販売エンジニア２、上海販売エンジニア３、上海販売エンジニア４、上海販売エンジニア５等。ユーザーとロールの関連関係：その会社の従業員である張三は、会社の副総経理２を務め、同時に北京販売部Ｉの経理を務める場合、張三は副総経理２及び北京販売部Ｉの経理というロールを関連付ける必要がある。張三は両方のロールに対する権限を持っている。

従来のロールの概念は、グループ／クラス／役職／職務／職種の性質であり、一つのロールは複数のユーザーに対応できる。本発明の「ロール」の概念は、役職番号／職務番号と同等であり、映画やテレビドラマのロールに似ている。一つのロールは一つの俳優のみに同時に（幼年、少年、中年．．．）演じられ、一つの俳優は複数のロールを演じることができる。

前記ユーザーが異動する時に、ユーザーと元のロールの関連を取り消して、ユーザーを新しいロールに関連付けると、ユーザーは元のロールの権限を自動的に失い、新しいロールの権限を自動的に取得する。

従業員が入職する時、従業員に対応するユーザーにロールを関連付けた後、そのユーザーはその関連付けたロールの権限を自動的に取得する。従業員が離職する時、従業員に対応するユーザーとそのユーザーの関連付けたロールの関連関係を取り消した後、そのユーザーは元々関連付けたロールの権限を自動的に失う。

ロールを作成した後、ユーザーを作成するプロセスでロールを関連付けることができ、または、ユーザーを作成した後、いつでもロールを関連付けることができる。ユーザーは、ロールを関連付けた後ロールとの関係がいつでも解除でき、他のロールとの関係がいつでも確立できる。

一つの従業員が一人のユーザーに対応し、一人のユーザーが一つの従業員に対応し、従業員がそれに対応するユーザーの関連付けるロールにより権限を決定（取得）する。

更に、従業員がユーザーを一生結びつけ、ユーザーが従業員に対応した後、従って、そのユーザーがその従業員に属し、ユーザーが他のロールを関連付けることができない。その従業員が離職する場合、そのユーザーは他のロールにも対応することができない。従業員が再度入職した後、その従業員が依然として元のユーザーを使用する。

Ｓ１４、一つ或いは複数の前記システム使用者に対して選定した要素項を承認することを含む。

図１１に示すように、全てのシステム使用者の最近の権限状態を表示する承認方法は、以下のステップを含む。Ｓ２１、一つの統計列表を選定する。

Ｓ２２、前記統計列表の一種の統計列表要素の一つの要素項を選択する。

前記統計列表要素の種類は統計列表操作権限と統計列表の列名と時間特性列名と統計列表の列名値のうちの一種或いは複数種を含む。前記列名値はその列名の所在する列の列値である（例えば、統計列表に一つの列名が顧客級別であり、列表に統計して表示した「一級、二級、三級…」は顧客級別の列値である。又は、もう一つの列名は訪問回数であり、列表に統計して表示した「１１２、５、８…」は訪問回数の列値である）。

統計列表要素の種類は統計列表の列名値である時、その要素項に対して承認操作を行うのは実質的にその要素項に対するデータを承認することである。

前記統計列表の操作権限の要素項は検分／問合せ等を含む。例えば、顧客統計列表の前記統計列表の列名の要素項は、顧客級別や顧客業界や顧客区域等（即ち、統計列表の列名、その列名の所在する列／列に対応するデータを承認する）を含む。前記統計列表列名値の要素項は、列名に対応する列名値であり、ここに列名値の選択確定或いは自動確定になる列名値を特に指す。例えば、顧客フォームに顧客級別という列名のオプション値「一級、二級、三級…」、又は顧客業界という列名のオプション値「ソフトウェア、化工、建材…」、又は顧客の責任部門という列名のオプション値「販売一部、販売二部、販売三部…」、又は顧客の責任者という列名のオプション値「張三、李四、王五…」、又は顧客の住所地という列名のオプション値「北京、上海、広州…」等（統計列表列名値の種類は、承認する必要があるのは列名値であるが、その列名値に対応するフィールドでない）、且つこの様な列名値の列名の列名値には一つのヌル及び一つの全て／無制限のフィールド値を含む（ヌルは「列名値がヌルである」を表し、全ては「全ての列名値」を表す）。前記時間特性列名の要素項は、時間の性質を有する列名である。例えば、統計列表の列名作成時間と最近修正時間等の時間特性列名（ここに「作成時間及び最近修正時間」は、時間特性列名の要素項であり、統計列表の列名の要素項でもある。又は、時間特性列の所在する列は、時間の性質を有するデータ或いは内容を統計しなければならない。また、時間特性列名の一つの要素項を選定した後、その要素に対する承認操作／設置は、本発明の「フォームに時間特性フィールドの一つの要素項を選定した後」の承認操作／設置方式と同じである）。

前記統計列表列名値は選択確定（例えば、顧客統計列表に顧客業界という列名の所在する列の列名値には製造や金融や航空等の業界オプションがあり、これらの列名値を人工で記入しなくて選択方式で取得する。例えば、顧客所在地や顧客責任部門や顧客責任者や顧客責任ロール等という列名の列名値も選択的である）或いは自動確定（例えば、統計列表の作成者や記録者やフォーム製作ロールやフォーム製作ユーザーやフォーム作る人等という列名、この様な列名の列名値を相関規則により自動的に確定する）される。

Ｓ２３、前記要素項を選定した後、システム中の全てのシステム使用者を表示し、且つ各システム使用者の選定した要素項に対する最近の権限状態を表示する。

更に、前記要素項を選定した後、システム中の全てのシステム使用者を表示し、前記「システム中の全てのシステム使用者」は「システム中のその選択操作者の権限の承認できる全てのシステム使用者」である。

前記システム使用者はロール、ユーザー、従業員、グループ、クラス、またはテンプレートのうちの一種或いは複数種を含む。

前記ロールはグループ／クラスではなく、独立した個体であり、一つのロールは同時期に唯一のユーザーを関連付けることができ、一人のユーザーは一つ或いは複数のロールを関連付ける。ロールを作成した時或いは後に前記ロールのために一つの部門を選定すると、前記ロールが前記部門に属し、ロールの作業内容によりロールを承認し、且つ前記ロールの名称が前記部門に唯一であり、前記ロールの番号がシステムに唯一である。

前記ユーザーが異動する時に、ユーザーと元のロールの関連を取り消して、ユーザーを新しいロールに関連付けると、ユーザーは元のロールの権限を自動的に失い、新しいロールの権限を自動的に取得する。

従業員が入職する時、従業員に対応するユーザーにロールを関連付けた後、そのユーザーはその関連付けたロールの権限を自動的に取得する。従業員が離職する時、従業員に対応するユーザーとそのユーザーの関連付けたロールの関連関係を取り消した後、そのユーザーは元々関連付けたロールの権限を自動的に失う。

ロールを作成した後、ユーザーを作成するプロセスでロールを関連付けることができ、または、ユーザーを作成した後、いつでもロールを関連付けることができる。ユーザーは、ロールを関連付けた後ロールとの関係がいつでも解除でき、他のロールとの関係がいつでも確立できる。

一つの従業員が一人のユーザーに対応し、一人のユーザーが一つの従業員に対応し、従業員がそれに対応するユーザーの関連付けるロールにより権限を決定（取得）する。

更に、従業員がユーザーを一生結びつけ、ユーザーが従業員に対応した後、従って、そのユーザーがその従業員に属し、ユーザーが他のロールを関連付けることができない。その従業員が離職する場合、そのユーザーは他のロールにも対応することができない。従業員が再度入職した後、その従業員が依然として元のユーザーを使用する。

更に、一種の統計列表要素の一つの要素項を選定した後、各システム使用者に対して選定した要素項を前回承認した操作者及び承認時間をそれぞれ表示する。

Ｓ２４、一つ或いは複数の前記システム使用者に対して選定した要素項を承認することを含む。

図１２に示すように、全てのシステム使用者の最近の権限状態を表示する承認方法は、以下のステップを含む。Ｓ３１、一つのメニューを選定する。

Ｓ３２、前記メニューを選定した後、システム中の全てのシステム使用者を表示し、且つ各システム使用者の選定したメニューに対する最近の権限状態を表示する。

更に、前記メニューを選定した後、システム中の全てのシステム使用者を表示し、前記「システム中の全てのシステム使用者」は「システム中のその選択操作者の権限の承認できる全てのシステム使用者」である。

前記システム使用者はロール、ユーザー、従業員、グループ、クラス、またはテンプレートのうちの一種或いは複数種を含む。

前記ロールはグループ／クラスではなく、独立した個体であり、一つのロールは同時期に唯一のユーザーを関連付けることができ、一人のユーザーは一つ或いは複数のロールを関連付ける。ロールを作成した時或いは後に前記ロールのために一つの部門を選定すると、前記ロールが前記部門に属し、ロールの作業内容によりロールを承認し、且つ前記ロールの名称が前記部門に唯一であり、前記ロールの番号がシステムに唯一である。

前記ユーザーが異動する時に、ユーザーと元のロールの関連を取り消して、ユーザーを新しいロールに関連付けると、ユーザーは元のロールの権限を自動的に失い、新しいロールの権限を自動的に取得する。つまり、ユーザーはその関連付けたロールの権限を取得する。

従業員が入職する時、従業員に対応するユーザーにロールを関連付けた後、そのユーザーはその関連付けたロールの権限を自動的に取得する。従業員が離職する時、従業員に対応するユーザーとそのユーザーの関連付けたロールの関連関係を取り消した後、そのユーザーは元々関連付けたロールの権限を自動的に失う。

ロールを作成した後、ユーザーを作成するプロセスでロールを関連付けることができ、または、ユーザーを作成した後、いつでもロールを関連付けることができる。ユーザーは、ロールを関連付けた後ロールとの関係がいつでも解除でき、他のロールとの関係がいつでも確立できる。

一つの従業員が一人のユーザーに対応し、一人のユーザーが一つの従業員に対応し、従業員がそれに対応するユーザーの関連付けるロールにより権限を決定（取得）する。

更に、従業員がユーザーを一生結びつけ、ユーザーが従業員に対応した後、従って、そのユーザーがその従業員に属し、ユーザーが他のロールを関連付けることができない。その従業員が離職する場合、そのユーザーは他のロールにも対応することができない。従業員が再度入職した後、その従業員が依然として元のユーザーを使用する。

更に、メニューを選定した後、各システム使用者に対して選定したメニューを前回承認した操作者及び承認時間をそれぞれ表示する。

Ｓ３３、一つ或いは複数の前記システム使用者に対して選定したメニューを承認する。

上記は本発明の優先的な実施形態だけである。本発明は、本明細書に開示された形態に限定されないと理解され、他の実施形態を除くとみなされず、却って様々な他の組み合わせや修正や環境に利用でき、本明細書のコンセプトの範囲内で、上記の教示または関連分野の技術または知識により修正を行うことができる。当業者に行われる修正及び変更は、本発明の趣旨及び範囲から逸脱するものではなく、全部と本発明に添付される請求項の範囲内にあるべきである。

Claims (4)

1. システムを制御する制御手段が全てのシステム使用者の直前の権限状態を表示する承認方法であって、
   前記制御手段が一つのフォームの選定を受け付けること、
   前記制御手段が前記フォームの一種のフォーム要素の一つの要素項の選択を受け付けること、
   前記制御手段が前記要素項の選定を受け付けた後、システム中の全てのシステム使用者を表示し、且つ各システム使用者の選定した要素項に対する直前の権限状態を表示すること及び、
   前記制御手段が一人或いは複数の前記システム使用者に対して選定した要素項の承認を受け付けること、を含み、
   前記システム使用者はロール、ユーザー、従業員、グループ、クラス、及び、テンプレートのうちの一種或いは複数種を含み、前記ロールはグループではなく、唯一性を有して独立であり、一つのロールは同時期に唯一のユーザーを関連付けることができ、一人のユーザーは一つ或いは複数のロールを関連付ける、承認方法。
2. 前記フォーム要素の種類は、フォーム操作権限とフォームフィールドと時間特性フィールドとフォームフィールド値のうちの一種或いは複数種を含み、前記フォームフィールド値は選択確定或いは自動確定される請求項１に記載の承認方法。
3. 前記制御手段がロールを作成した時或いは後に前記ロールのために一つの部門の選定を受け付けると、前記ロールが前記部門に属し、ロールの作業内容によりロールの承認を受け付け、且つ前記ロールの名称が前記部門に唯一であり、前記ロールの番号がシステムに唯一であり、
   前記ユーザーが異動する時、前記制御手段がユーザーと元のロールの関連を取り消す設定を受け付け、ユーザーを新しいロールに関連付ける設定を受け付ける、請求項１に記載の承認方法。
4. 前記制御手段が一種のフォーム要素の一つの要素項の選定を受け付けた後、各システム使用者に対して選定した要素項を前回承認した操作者及び承認時間をそれぞれ表示する、請求項１に記載の承認方法。