(57)【要約】  本発明は、ロールが独立した個体であり、従来のグループ／クラスを性質とするロールとは異なり、１つのロールは同時に単一のユーザーを関連付けることができる。システム使用時のシステム管理の効率を大幅に向上させ、動的承認をより簡単、便利、明確にさせ、権限設定の効率と信頼性を向上させる。本発明は、ロール対ユーザーに基づく１対１の権限承認方法とシステムを公開し、以下の順序のステップを含む。Ｓ１：各ロールがグループ／クラスではなく独立した個体であるロールを作成する。Ｓ２：Ｓ１で作成されたロールをそれぞれ承認する。Ｓ３：ユーザーをロールに関連付けさせる。１つのロールは同時に単一のユーザーを関連付けることができ、１つのユーザーは１つ以上のロールを関連付ける。【選択図】  図４
2020520034.tif 000002
【特許請求の範囲】
【請求項１】
ロール対ユーザーに基づく１対１の権限承認方法であって、Ｓ１：各ロールがグループ／クラスではなく独立した個体であるロールを作成すること；Ｓ２：Ｓ１で作成されたロールをそれぞれ承認すること；Ｓ３：ユーザーをロールに関連付けさせ、１つのロールは同時に単一のユーザーを関連付けることができ、１つのユーザーは１つ以上のロールを関連付ける順序のステップを含む承認方法。
【請求項２】
前記ロールを作成する時、１つの部門を選択しなければならず、ロールが作成されると、そのロールはその部門に属し、そのロールはその部門内に唯一であり、ロールの作業内容に従ってロールを承認する請求項１に記載の承認方法。
【請求項３】
更にユーザーの部門間の異動管理ステップを含み、具体的に（１）ユーザーと元の部門のロールの関連を取り消すこと、（２）ユーザーを新しい部門のロールに関連付けさせることを含む請求項２に記載の承認方法。
【請求項４】
前記ユーザーはロールとの関連付けだけによって権限を決定する請求項１に記載の承認方法。
【請求項５】
ロール対ユーザーに基づく１対１の権限承認方法であって、Ｓ１：各ロールがグループ／クラスではなく独立した個体であるロールを作成すること；Ｓ２：ユーザーをロールに関連付けさせ、１つのロールは同時に単一のユーザーを関連付けることができ、１つのユーザーは１つ以上のロールを関連付けること；Ｓ３：Ｓ１で作成されたロールをそれぞれ承認することの、この順序のステップを含む承認方法。
【請求項６】
前記ロールを作成する時、１つの部門を選択しなければならず、ロールが作成されると、そのロールはその部門に属し、そのロールはその部門内に唯一であり、ロールの作業内容に従ってロールを承認する請求項５に記載の承認方法。
【請求項７】
更にユーザーの部門間の異動管理ステップを含み、具体的に（１）ユーザーと元の部門のロールの関連を取り消すこと、（２）ユーザーを新しい部門のロールに関連付けさせることを含む請求項５に記載の承認方法。
【請求項８】
前記ユーザーはロールとの関連付けだけによって権限を決定する請求項５に記載の承認方法。
【請求項９】
ロール対ユーザーに基づく１対１の権限承認システムであって、ロール建てユニット、ロール承認ユニット及びユーザー−ロール関連付けユニットを含み、前記ロール建てユニットは、ロールに従ってロール配置を実行し、システムロールを建てるように用い、各ロールは、グループ／クラスではなく、独立した個人であり、前記ロール承認ユニットは、ロールの作業内容に従ってロールに権限を割り当てるように用い、前記ユーザー−ロール関連付けユニットは、ユーザーをロールに関連付けさせるように用い、これにより、１つのロールは同時に単一のユーザーを関連付けることができ、１つのユーザーは１つ以上のロールを関連付けることを確実にする承認システム。
【請求項１０】
前記ロールの構成は、職名＋職務番号である請求項９に記載の承認方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＥＲＰなどの管理ソフトウェアシステムのユーザー権限管理方法に関し、特にロール対ユーザーに基づく１対１の権限承認方法とシステムに関する。
【背景技術】
【０００２】
ロールベースのアクセス制御（ＲＢＡＣ）は、近年最も研究され成熟したデータベース権限管理メカニズムの１つであり、従来の強制アクセス制御（ＭＡＣ）および自律アクセス制御（ＤＡＣ）に代わる理想的な候補と考えられる。ロールベースのアクセス制御（ＲＢＡＣ）の基本的な考え方は、企業組織ビューのさまざまな機能的位置を分割して異なるロールを形成し、データベースリソースのアクセス権をロールにカプセル化することで、ユーザーは、異なるロールを割り当てることにより、データベースリソースに間接的にアクセスするというものである。
【０００３】
大量のテーブルとビューが大規模なアプリケーションシステムに組み込まれているため、データベースリソースの管理と承認が非常に複雑になる。ユーザーがデータベースリソースのアクセスと権限の許可を直接管理することは非常に困難である。ユーザーはデータベース構造を十分に理解し、ＳＱＬ言語の使用に精通している必要があり、アプリケーションシステム構造またはセキュリティ要件が変更されると、大量の複雑かつ面倒な認証変更を実行するために、予期しない認証エラーにより引き起こされるセキュリティ脆弱性が非常に発生しやすい。したがって、大規模なアプリケーションシステムのために簡単かつ効率的な権限の管理方法を設計することは、システムとシステムユーザーの共通の要件になっている。
【０００４】
ロールベースの権限制御メカニズムにより、システムのアクセス権が簡単かつ効率的に管理できる。これにより、システム権限管理の負担とコストが大幅に削減され、さらに、システム権限管理は、アプリケーションシステムのビジネス管理仕様とより一致している。
【０００５】
ただし、従来のロールベースのユーザー権限管理及びワークフロー制御方法は、「ロール対ユーザー、１対複数」の関連付けメカニズムを採用し、「ロール」はグループ／クラスの性質を有する。つまり、１つのロールが複数のユーザーに同時に対応／関連付けできる。ロールは、役職／職務／職種の概念に似ている。この関連付けメカニズムに基づくユーザー権限の承認は、基本的に次の３つの形式に分けられる。１．図１に示すように、ユーザーを直接承認するが、不利な点は、ワークロードが大きく、操作が頻繁且つ面倒であることである。２．図２に示すように、ロール（クラス／グループ／役職／職種）は承認され（１つのロールを複数のユーザーに関連付けさせることができる）、ユーザーはロールを介して権限を取得し、承認操作の主体はグループ／クラスというロールである。３．図３に示すように、上記の２つの方法が組み合わされている。
【０００６】
上記の説明では、２と３の両方がクラス／グループの性質のロールを承認する必要があり、クラス／グループ／役職／職種のロールを介する承認およびワークフロー制御の方法には次の欠点がある。１．ユーザーのアクセス権限を変更する場合、操作が難しい。実際のシステム使用プロセスでは、多くの場合、運用プロセス中にユーザーの権限を調整する必要がある。たとえば、従業員の権限の変更を処理する場合、ロールに関連付けられる従業員の権限を変更するが、ロールは権限の変更されない他の従業員にも関連付けられることで、個々の従業員の権限の変更により、ロール全体の権限を変更することができない。そのため、この状況に対応して、権限の変更された従業員に適うために新しいロールを設立するか、権限要件に基づいて従業員を直接承認（ロールからの離脱）する。上記の２つの処理方法は、ロールの権限が多数ある場合、ロールの承認に長い時間がかかるだけでなく、ミスをおかしやすく、ユーザーの操作がわずらわしく、面倒であり、システムユーザーの損失につながるエラーも発生しやすい。
【０００７】
２．ロールに含まれる特定の権限を長期的に覚えることは困難である。ロールに複数の権限機能がある場合、時間が経つにつれて、ロールの特定の権限を覚えることは困難になり、権限の類似したロール間の権限差別を覚えるのがより難しくなる。新しいユーザーを関連付けると、どのようにして関連付けるか正確に判断することはできない。
【０００８】
３．ユーザーの権限が変更されるため、ロールをさらに設立することをもたらす（新しいロールを設立しない場合、ユーザーを直接承認することが大幅に増加する）。各ロール間の特定の差を区別することはより困難である。
【０００９】
４．役職を調整するときに、異動するユーザーの多くの権限を他の複数のユーザーに割り当てる場合、異動するユーザーの権限を区分し、他の複数のユーザーを関連付けるためにそれぞれロールを設立する必要があるが、このような操作は、複雑であり、時間がかかるだけでなく、エラーをより発生させやすい。
【発明の概要】
【発明が解決しようとする課題】
【００１０】
本発明の目的は、先行技術の欠点を克服し、ロール対ユーザーに基づく１対１の権限承認方法とシステムを提供し、１つのロールは単一のユーザーを同時に関連付けることができ、システムの使用中の権限管理は効率が大幅に改善され、動的承認がより簡単に、より便利に、より明確になり、権限設定効率と信頼性を向上させる。
【課題を解決するための手段】
【００１１】
本発明の目的は、以下の技術的手段により達成される。ロール対ユーザーに基づく１対１の権限承認方法は、以下の順位のステップを含む。Ｓ１：各ロールがグループ／クラスではなく独立した個体であるロールを作成する。Ｓ２：Ｓ１で作成されたロールをそれぞれ承認する。Ｓ３：ユーザーをロールに関連付けさせ、１つのロールは同時に単一のユーザーを関連付けることができ、１つのユーザーは１つ以上のロールを関連付ける。
【００１２】
ロールに対する承認は、フォームに対する承認、メニューに対する承認、または機能に対する承認を含む。
【００１３】
前記ロールを作成する時、１つの部門を選択しなければならない。ロールが作成されると、そのロールはその部門に属し、そのロールはその部門内に唯一であり、ロールの作業内容に従ってロールを承認する。
【００１４】
ロール対ユーザーに基づく１対１の権限承認方法は、更にユーザーの部門間の異動管理ステップを含み、具体的に（１）ユーザーと元の部門のロールの関連を取り消すこと、（２）ユーザーを新しい部門のロールに関連付けさせることを含む。
【００１５】
前記ユーザーはロールとの関連付けだけによって権限を決定する。
【００１６】
ロール対ユーザーに基づく１対１の権限承認方法は、以下の順位のステップを含む。Ｓ１：各ロールがグループ／クラスではなく独立した個体であるロールを作成する。Ｓ２：ユーザーをロールに関連付けさせ、１つのロールは同時に単一のユーザーを関連付けることができ、１つのユーザーは１つ以上のロールを関連付ける。Ｓ３：Ｓ１で作成されたロールをそれぞれ承認する。
【００１７】
ロールに対する承認は、フォームに対する承認、メニューに対する承認、または機能に対する承認を含む。
【００１８】
前記ロールを作成する時、１つの部門を選択しなければならない。ロールが作成されると、そのロールはその部門に属し、そのロールはその部門内に唯一であり、ロールの作業内容に従ってロールを承認する。
【００１９】
ロール対ユーザーに基づく１対１の権限承認方法は、更にユーザーの部門間の異動管理ステップを含み、具体的に（１）ユーザーと元の部門のロールの関連を取り消すこと、（２）ユーザーを新しい部門のロールに関連付けさせることを含む。
【００２０】
前記ユーザーはロールとの関連付けだけによって権限を決定する。
【００２１】
ロール対ユーザーに基づく１対１の権限承認システムは、ロール建てユニット、ロール承認ユニット及びユーザー−ロール関連付けユニットを含む。前記ロール建てユニットは、ロールに従ってロール配置を実行し、システムロールを建てるように用い、各ロールは、グループ／クラスではなく、独立した個人である。前記ロール承認ユニットは、ロールの作業内容に従ってロールに権限を割り当てるように用いる。前記ユーザー−ロール関連付けユニットは、ユーザーをロールに関連付けるように用い、これにより、１つのロールは同時に単一のユーザーを関連付けることができ、１つのユーザーは１つ以上のロールを関連付けることを確実にする。
【００２２】
前記ロールの構成は、職名＋職務番号である。
【００２３】
（１）従来の権利管理メカニズムでは、ロールをグループ、職種、クラスなどに定義し、ロールがユーザーとの１対複数の関係にあり。実際にシステムを使用するプロセスでは、運用プロセス中にユーザーの権限を調整する必要がある。たとえば、従業員の権限変更を処理する場合、ロールを関連付ける従業員の権限が変更され、このロールは権限を変更しない他の従業員を関連付けることで、個々の従業員の権限を変更したため、全体のロールの権限が変更できない。そのため、この状況に対応して、権限の変更された従業員に適うために新しいロールを設立するか、権限要件に基づいて従業員を直接承認（ロールからの離脱）する。上記の２つの処理方法は、ロールの権限が多数ある場合、ロールの承認に長い時間がかかるだけでなく、ミスをおかしやすく、ユーザーの操作がわずらわしく、面倒であり、システムユーザーの損失につながるエラーも発生しやすい。
【００２４】
しかし、本発明の方法では、ロールが独立した個体であるため、ロール権限を変更して目標を達成することができる。本発明の方法は、システムの初期化時にワークロードを増加させるように見えるが、ロールの作成あるいは権限授与の効率は、コピーなどの方法によってグループを性質とする従来のロールより高くなる。ユーザーに関連付ける時にグループを性質とするロールの共通性を考慮しないため、この発明技術的手段は、許可設定を明確にさせる。特に、システムが一定期間使用された後（ユーザー／ロールの権限動的に変化している）、この発明技術的手段は、システム使用時のシステム管理の効率を大幅に向上させ、動的認証をより簡単、便利、明確にさせ、権限設定の効率と信頼性を向上させる。
【００２５】
（２）従来のグループを性質とするロールの承認方法はエラーが発生しやすく、本発明の方法では、従来の方法でこのグループを性質とするロールを関連付ける複数のユーザーにどのような共通性があるかを考慮することなく、ロールを独立した個体として考慮するだけでよいため、本発明の方法は権限エラーの確率を大幅に低減させる。承認エラーが発生した場合でも、ロールを関連付けるその１つのユーザーのみに影響するが、従来のグループを性質とするロールはそのロールを関連付ける全てのユーザーに影響する。承認エラーが発生した場合でも、本発明の修正方法は簡単であり、かかる時間が短く、従来のグループを性質とするロールはエラーを修正する時にそのロールを関連付ける全てのユーザーの共通性を考えなければならない。機能ポイントが多い場合、変更が面倒かつ複雑であるだけでなく、非常にエラーが発生しやすく、かつ多くの場合、新しいロールを作成するだけで解決できる。
【００２６】
（３）従来のグループを性質とするロールの承認方法では、ロールの権限機能ポイントが多くある場合、時間が長くなると、ロールの具体的な権限を覚えにくく、権限に近付くロールの間の区別を覚えるのはより困難である。本発明の方法のロール自身は、役職番号／職務番号の性質を有しており、選択は明らかである。
【００２７】
（４）異動するときに、異動したユーザーの多くの権限を他のユーザーに割り当てる場合、処理する時に異動したユーザーのこれらの権限を区別して、他のユーザーを関連付けるようにロールをそれぞれ作成する必要がある。このような操作は、複雑であり、時間がかかるだけでなく、エラーが発生しやすくなる。
【００２８】
本発明の方法は次のとおりである：異動したユーザーはいくつかのロールを関連付け、異動する場合、まず元の部門のロールとのユーザーの関連付けを取り消し（これらの取り消されたロールは他のユーザーを再度関連付けることができる）、ユーザーは新しい部門のロールを関連付けてもよい。操作は簡単であり、エラーが現れない。
【００２９】
（５）ロールを作成するときは、部門を選定する必要がある。ロールが作成されると、部門を置き換えることはできない。ロールは部門が変更できないのはなぜか？理由１：本発明のロールの性質は役職番号／職務番号と同等であるため、様々な役職番号／職務番号の作業内容／権限は異なる。例えば、販売部門の販売員１のロールと技術部門の開発者１のロールは、２つの役職番号／職務番号がまったく異なり、権限が異なる。理由２：販売員１のロールの部門（販売部門）が技術部門に置き換えられる場合、販売員１のロールを変更しないと、技術部門には販売部門の権限を持つロールがある。これは、管理の混乱とセキュリティの脆弱性につながる可能性がある。
【図面の簡単な説明】
【００３０】
【図１】背景技術においてシステムがユーザを直接承認する方法の概略図である。
【図２】背景技術においてシステムがグループ／クラスを性質とするロールを承認する方法の概略図である。
【図３】背景技術においてシステムがユーザーを直接承認し、グループ／クラスを性質とするロールを承認して組み合わせる方法の概略図である。
【図４】本発明のシステムが独立した個々のロールを通じてユーザーを承認する方法の概略図である。
【図５】本発明による承認方法のフローチャートである。
【発明を実施するための形態】
【００３１】
本発明の技術的手段は、添付の図面を参照して以下でさらに詳細に説明されるが、本発明の保護範囲は以下に限定されない。
【実施例１】
【００３２】
図１に示すように、ロール対ユーザーに基づく１対１の権限承認方法は、以下の順位のステップを含む。Ｓ１：各ロールがグループ／クラスではなく独立した個体であるロールを作成する。Ｓ２：Ｓ１で作成されたロールをそれぞれ承認する。Ｓ３：ユーザーをロールに関連付けさせ、１つのロールは同時に単一のユーザーを関連付けることができ、１つのユーザーは１つ以上のロールを関連付ける。ユーザーはロールとの関連付けだけによって権限を決定する。ユーザーの権限を変更する場合は、ロールの所有する権限を調整することで、ロールに関連付けられたユーザーの権限を変更する目的が達成できる。ユーザーに対しては、直接承認するのではなく、関連付けられたロールによりユーザーを承認する。ユーザーがロールを関連付けると、ユーザーはロールのすべての操作権限を持つ。
【００３３】
ロールは、ユーザーとの１対１の関係にある（そのロールが、ユーザーを関連付ける場合、他のユーザーはそのロールを関連付けることができなくなる；そのロールが、ユーザーを関連付けていない場合、他のユーザーが選択して関連付けることができる）。ユーザーは、ロールとの１対複数の関係にある（１つのユーザーは同時に複数のロールを関連付けることができる）。
【００３４】
ロールの定義：ロールはグループ／クラス／カテゴリ／役職／職務／職種等の性質を有さないが、非集合の性質である。ロールは唯一性を有し、独立して存在している個体である。ロールは企業や機関の応用で役職番号と同等である（役職番号はここでは役職ではなく、１つの役職に同時に複数の従業員がいるが、１つの役職番号は同時に１つの従業員にしか対応できない）。
【００３５】
たとえば、会社のシステムは次のロールを設立できる：総経理、副総経理１、副総経理２、北京販売部Ｉの経理、北京販売部ＩＩの経理、北京販売部ＩＩＩの経理、上海販売エンジニア１、上海販売エンジニア２、上海販売エンジニア３、上海販売エンジニア４、上海販売エンジニア５など。ユーザーとロールの関連関係：その会社の従業員である張三さんは、会社の副総経理２を務め、同時に北京販売部Ｉの経理を務める場合、張三さんは総経理２及び北京販売部Ｉの経理というロールに関連付ける必要がある。張三さんは両方のロールに対する権限を持っている。
【００３６】
ロールに対する承認：システムのロールに対する承認は、フォームに対する承認、メニューに対する承認、または機能に対する承認を含むが、これらに限定されない。フォームに対する操作承認には、追加や削除や変更や検分の権限を含むが、これらに限定されない。
【００３７】
従来のロールの概念は、グループ／クラス／役職／職務／職種の性質であり、１つのロールは複数のユーザーに対応できる。本発明の「ロール」の概念は、役職番号／職務番号と同等であり、映画やテレビドラマのロールに似ている。１つのロールは１つの俳優のみに同時に（幼年、少年、中年...）演じられ、１つの俳優は複数のロールを演じることができる。
【００３８】
システムのロールに対する承認は、フォームに対する承認、メニューに対する承認、または機能に対する承認を含むが、これらに限定されない。
【００３９】
前記ロールを作成する時、１つの部門を選択しなければならない。ロールが作成されると、そのロールはその部門に属し、そのロールはその部門内で唯一であり、ロールの作業内容に従ってロールを承認する。
【００４０】
ユーザーが部門を変更したい場合、部門間の異動に関する。その具体的な操作過程は、（１）ユーザーと元の部門のロールの関連を取り消すこと、（２）ユーザーを新しい部門のロールに関連付けさせることを含む。
【００４１】
ロールを作成した後、ユーザーを作成するプロセスでロールを関連付けることができ、または、ユーザーを作成した後ロールをいつでも関連付けることができる。ユーザーがロールを関連付けた後、ロールとの関係はいつでも解除でき、他のロールとの関係をいつでも作成できる。
【実施例２】
【００４２】
ロール対ユーザーに基づく１対１の権限承認方法は、以下の順位のステップを含む。Ｓ１：各ロールがグループ／クラスではなく独立した個体であるロールを作成する。Ｓ２：ユーザーをロールに関連付けさせ、１つのロールは同時に単一のユーザーを関連付けることができ、１つのユーザーは１つ以上のロールを関連付ける。Ｓ３：Ｓ１で作成されたロールをそれぞれ承認する。
【実施例３】
【００４３】
上記の承認方法を実現するために、ロール対ユーザーに基づく１対１の権限承認システムは、少なくとも、ロール建てユニット、ロール承認ユニット及びユーザー−ロール関連付けユニットを含む。前記ロール建てユニットは、ロールに従ってロール配置を実行し、システムロールを建てるように用い、各ロールは、グループ／クラスではなく、独立した個人である。前記ロールの構成は、職名＋職務番号である。例えば、作業場生産労働者１、作業場生産労働者２、作業場生産労働者３のようなロールは、独立した個体であり、これは役職番号／職務番号と同等であり、従来の権限管理システムのロールとは異なる。従来のシステムのロールの概念は、役職／職務／職種等のグループ／クラスの性質である。
【００４４】
前記ロール承認ユニットは、ロールの作業内容に従ってロールに権限を割り当てるように用いる。前記ユーザー−ロール関連付けユニットは、ユーザーをロールに関連付けるように用い、これにより、１つのロールは同時に単一のユーザーを関連付けることができ、１つのユーザーは１つ以上のロールを関連付けることを確実にする。
【実施例４】
【００４５】
次の例は、張三という従業員が入社した後、従業員、ユーザーやロールの関係を示している。１．新入職：従業員は新しく雇用され、そのユーザー（従業員）の対応する役職番号／職務番号のロールを直接関連付けてもよい。例えば、張三は会社に加わった（会社は張三に張三というユーザーを割り当てた）。仕事内容は営業部Ｉにあり、北京地区の冷蔵庫製品の販売を担当した（対応するロールは販売部Ｉの「販売エンジニア５」というロールである）。次に、張三というユーザーが「販売エンジニア５」というロールを直接選択してもよい。
【００４６】
２．職務の追加：一定期間勤務した後、張三は北京で地域テレビ製品の販売を担当するようになり（対応するロールは販売部Ｉの「販売エンジニア８」というロールである）、同時に販売後部門の主管を兼務した（販売後部門の主管というロールに対応する）。次に、張三というユーザーは、販売部Ｉの「販売エンジニア８」と販売後部門の「販売後主管」という２つのロールを増やして関連付けた。この時に、張三という従業員には、３つのロールを関連付け、これらは、ぞれぞれ販売部Ｉの「販売エンジニア５」、「販売エンジニア８」、及び販売後部門の「販売後主管」であり、張三というユーザーは、これら３つのロールに対する権限を持った。
【００４７】
３．職務の減少：しばらくして、会社は張三を販売後部門の経理（販売後部門の「販売後経理」というロールに対応する）として任命し、他の仕事を兼務しないようにすることを決定した。次に、張三というユーザーは、販売後部門の「販売後経理」というロールに関連付けられ、以前に関連付けられていた３つのロールを取り消した（販売部Ｉの「販売エンジニア５」、「販売エンジニア８」、及び販売後部門の「販売後主管」）。この時に、張三というユーザーは販売後部門の「販売後経理」というロールの権限のみを持っていた。
【００４８】
４．ロールの権限の調整（役割自身が所有する権限に対して調整する）：会社が販売後経理の権限を増やすことを決定した場合、販売後経理というロールの権限を増やすだけでよく、張三というユーザーは販売後経理というロールの権限が増加するため、張三というユーザーの権限も増加した。
【００４９】
５．辞任：１年後、張三は辞任した。張三というユーザーと販売後部門の「販売後主管」というロールの関連を取り消してもよい。
【００５０】
例えば、会社の動的な運用では、スタッフの入退場が頻繁に行われるが、役職番号／職務番号の変更は非常にわずかである（一定期間内でも変更はない）。
【００５１】
従来の承認方法：システム機能が多くある場合、従来のグループ／クラスの性質でロールを承認すると、承認ワークロードが大きく複雑であるだけでなく、ミスをおかしやすく、間違っていても短時間で見つけるのは容易ではないため、システムユーザーに損害を与えやすい。
【００５２】
本発明の承認方法：本発明は、役職番号／職務番号という性質を有するロールを承認し、ユーザーはロールを関連付けて権限を決定する。次に、ユーザー権限の制御を簡単にユーザーとロールの関連関係を通じて達成する。これにより、権限制御が簡単で操作しやすく、明確になり、承認の効率と承認の信頼性が大幅に向上する。
【００５３】
上記は本発明の優先的な実施形態にみを示している。本発明は、本明細書に開示された形態に限定されるわけではないと理解され、他の実施形態を除くとみなされず、かえって様々な他の組み合わせ、修正や環境に利用でき、本明細書の概念の範囲内で、上記の教示または関連分野の技術または知識により修正を行うことができる。当業者に行われる修正及び変更は、本発明の趣旨及び範囲から逸脱するものではなく、全て本発明に添付される請求項の範囲内にあるべきである。
【図１】
2020520034.tif 000003
【図２】
2020520034.tif 000004
【図３】
2020520034.tif 000005
【図４】
2020520034.tif 000006
【図５】
2020520034.tif 000007
【国際調査報告】
2020520034.tif 000008
2020520034.tif 000009
2020520034.tif 000010
2020520034.tif 000011