(57)【要約】【課題】本発明は、列値により統計列表中の統計データの操作権限をそれぞれ承認し、一つの統計列表は様々な統計データの操作権限を承認した後異なる実際の使用需要を満足することができ、統計列表の統計データをより綿密に制御することができ、管理の精細度を大幅に向上させ、企業および事業団体の要求を実際の運営使用中に満たす。【解決手段】本発明は、列値に基づいて統計列表操作権限をそれぞれ承認する方法を公開し、統計列表の操作権限の承認ステップ及び被承認者の選定ステップを含み、統計列表の操作権限の承認ステップは、Ｓ１：承認する必要がある統計列表を選定すること；Ｓ２：統計列表に承認する必要がある列を選択し、選択された列は列値を選択確定或は自動確定にする列であるべきであること；Ｓ３：選択された列の全ての列値のそれぞれ対応する統計データにより操作権限を与えることを含む。【選択図】図５
2020530614.tif 000002
【特許請求の範囲】
【請求項１】
列値に基づいて統計列表操作権限をそれぞれ承認する方法であって、統計列表の操作権限の承認ステップ及び被承認者の選定ステップを含み、統計列表の操作権限の承認ステップと被承認者の選定ステップには前後順序がなく、
前記統計列表の操作権限の承認ステップは、
Ｓ１：承認する必要がある統計列表を選定すること、
Ｓ２：統計列表に承認する必要がある列を選択し、選択された列は列値を選択確定或は自動確定にする列であるべきであること、
Ｓ３：選択された列の全ての列値のそれぞれ対応する統計データにより操作権限を与えることを含み、
前記被承認者の選定ステップに一つ或は複数の被承認者を選択する方法。
【請求項２】
前記操作権限は検分を含む請求項１に記載の方法。
【請求項３】
検分権限の具わらない列値に対応する統計データに対して、その表示方式は、
（１）前記列値を表示するが、前記列値に対応する統計データを隠し符で隠すこと、
（２）前記列値及び前記列値に対応する統計データを全く表示しないこと、
上記の一種或は多種を含む請求項２に記載の方法。
【請求項４】
前記被承認者を一つのみとなるように選定し、且つ承認する必要がある統計列表、統計列表中に承認する必要がある列を選定する時に、この前に前記被承認者が前記統計列表中の前記列の各列値に対応する統計データを操作する権限の承認状態を表示する請求項１に記載の方法。
【請求項５】
前記被承認者を二つ或は二つ以上となるように選定し、且つ承認する必要がある統計列表、統計列表中に承認する必要がある列を選定する時に、前記被承認者が前記統計列表中の前記列の各列値に対応する統計データを操作する権限の承認状態を表示しない請求項１に記載の方法。
【請求項６】
前記被承認者を一つのみとなるように選定し、且つ承認する必要がある統計列表、統計列表中に承認する必要がある列を選定する時に、前記被承認者に対して前記統計列表中の前記列を前回承認した操作者と操作時間を表示する請求項１に記載の方法。
【請求項７】
前記被承認者は一つ或は複数のロールであり、前記ロールはグループ／クラスではなく、独立した個体であり、一つのロールは同時期に唯一のユーザーを関連付けることができ、一つのユーザーは一つ或は複数のロールを関連付ける請求項１〜６のいずれか一項に記載の方法。
【請求項８】
列値に基づいて統計列表操作権限をそれぞれ承認する方法であって、テンプレート承認のステップも含み、（１）被承認者、承認する必要がある統計列表、承認する必要がある列を選択し、一つ或は複数の被承認者を選定し、承認する必要がある一つの統計列表を選定し、選定された統計列表から承認する必要がある列を選択すること、
（２）被承認者を承認し、一つの既有の被承認者或は作成済のテンプレートを設定して承認テンプレートとし、前記承認テンプレートの前記統計列表の前記列の各列値に対応する統計データの操作権限を前記被承認者に与えること、
（３）修正した後或は修正しないまま保存して前記被承認者が前記統計列表の前記列の各列値に対応する統計データを操作する権限を取得することを具体的に含む方法。
【請求項９】
列値に基づいて統計列表操作権限をそれぞれ承認する方法であって、統計列表の操作権限の承認ステップ及び被承認者の選定ステップを含み、統計列表の操作権限の承認ステップと被承認者の選定ステップには前後順序がなく、
前記統計列表の操作権限の承認ステップは、
Ｓ１：承認する必要がある統計列表を選定すること、
Ｓ２：統計列表に承認する必要がある列を選択し、選択された列は列値を選択確定或は自動確定にする列であるべきであること、
Ｓ３：選択された列の全ての列値のそれぞれ対応する統計データにより操作権限を与え、承認プロセスは、選択された列の列値のヌル値である統計データに対して操作権限を全体に承認するステップを含むことを含む方法。
【請求項１０】
列値に基づいて統計列表操作権限をそれぞれ承認する方法であって、統計列表の操作権限の承認ステップ及び被承認者の選定ステップを含み、統計列表の操作権限の承認ステップと被承認者の選定ステップには前後順序がなく、
前記統計列表の操作権限の承認ステップは、
Ｓ１：承認する必要がある統計列表を選定すること、
Ｓ２：統計列表に承認する必要がある列を選択し、選択された列は列値を選択確定或は自動確定にする列であるべきであること、
Ｓ３：選択された列の全ての列値のそれぞれ対応する統計データにより操作権限を与え、承認プロセスは、選択された列の全ての列値に対応する統計データに対して操作権限を全体に承認するステップを含み、全ての列値はヌル値である列値を含むことを含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＥＲＰ、ＣＲＭ等の管理ソフトウェアの統計列表の承認方法に関し、特に列値に基づいて統計列表操作権限をそれぞれ承認する方法に関する。
【背景技術】
【０００２】
統計列表はフォームと異なる概念である。（１）フォーム承認は、データベース中のデータ／フォームデータに対して追加や削除や変更や検分を主に表すことであるが、統計列表はデータベース中のデータ／フォームデータが修正できず、ある要求条件に応じてデータベース中のデータに対して問い合わせを行うばかりである。（２）フォームは、ある業務対象を表すことであり、例えば、注文や契約や顧客等、一つのフォームデータがそれぞれ唯一の業務対象に対応し、例としては顧客フォーム中の００１顧客が唯一の顧客００１を意味している（顧客００１は一つのフォームデータ／対象である）。しかも、統計列表は、通常某要求条件に応じて一つ／複数のフォームを統計することである。統計列表中には一行のデータが一つの業務対象ではなく、一つの統計結果であり、例えば、販売契約は署名部門により統計し、一行の統計データは、それぞれ一つの署名部門の管理する販売契約のいろいろな統計を表し、署名した契約数量の統計や署名した契約金額の統計や返金の統計や注文数の統計等を含むかもしれない。
【０００３】
ソフトウェアシステムは、通常、統計列表の表示及び検分機能が全て具わっているが、従来のソフトウェアシステムでは、被承認者は、統計列表中に某列にある全ての列値に対応する統計データを検分することができるか、全体の統計列表も見えないか、列値の統計データに対する操作権限により詳細化管理を行うことができない。使用には大きな制限がある。例えば、「販売契約の統計列表」に対して、その統計列表中の列名には署名部門や契約数量や契約金額や返金金額や注文数や出荷数量があり、署名部門の列値には販売一部や販売二部や販売三部等がある。今、販売総監に全体の販売部門の販売契約の統計データを提供する必要があると、販売総監にその統計列表を直接提供することができる。販売二部の経理に販売二部の販売契約の統計データを提供する必要のみがある場合に、システム中の表現方式は、販売二部のために新しい統計データ（同じ統計列表を利用することができない）を特に提供するか、全体の統計列表を提供するかである。１番目の方式を採用する場合に、統計列表中に関わる全ての列値は、表（販売二部のために統計列表をもう一度作る）を特に作る必要があり、予測不能な作業量がある。２番目の方式を採用する場合に、販売一部と販売三部の統計データも販売二部に漏れる。従来の方法では企業および企業および事業団体の要求が実際の運営使用中に満たされない。
【０００４】
又は、従来の承認方法は列値のヌル値である統計データに対して有効的な権限を与えることができない。いわゆる「列値のヌル値である」は列の内容がヌル値であること（未記入或は未選択）を指し、使用には大きな制限がある。例えば、契約を追加する時に署名部門を記入せず（その原因は、署名部門は記入必須項目ではない可能性があるため）、或は契約は兼職業務員に由来するので、列名「署名部門」によりこのような統計データに対して権限を与えることができない。これらの統計データに対して権限を与えるのを必要とする場合に、統計データごとに対して権限を一つずつ与えなければならない。これから、承認の作業量が大きく且つ間違いが現れ易い。
【０００５】
ロールベースのアクセス制御（ＲＢＡＣ）は、近年最も多く研究されるし、最も成熟したデータベース権限管理メカニズムの１つであり、従来の強制アクセス制御（ＭＡＣ）および自律アクセス制御（ＤＡＣ）に代わる理想的な候補と考えられる。従来の自律型アクセス制御は高い融通性を備えるが、セキュリティは低い。強制アクセス制御は高いセキュリティを備えるが、制限が強すぎる。ロールベースのアクセス制御は、両方の長所を兼ね備え、管理が簡単であるだけでなく、複雑さ、コスト、エラーの可能性を減らすこともできるため、近年大幅に成長している。ロールベースのアクセス制御（ＲＢＡＣ）の基本的な考え方は、企業組織ビューのさまざまな機能的位置を分割して異なるロールを形成し、データベースリソースのアクセス権をロールにカプセル化するに従って、ユーザーは、異なるロールを割り当てられることにより、データベースリソースに間接的にアクセスする。
【０００６】
大量のテーブルとビューが大規模なアプリケーションシステムに組み込まれているため、データベースリソースの管理と承認が非常に複雑になる。ユーザーがデータベースリソースのアクセスと権限承認を直接管理することは非常に困難である。ユーザーはデータベース構造を十分に理解し、ＳＱＬ言語を使用に精通している必要があり、アプリケーションシステム構造またはセキュリティ要件が変更されたら、大量の複雑かつ面倒な承認変更を実行するために、予期しない承認エラーに引き起こされるセキュリティ脆弱性が非常に発生しやすい。したがって、大規模なアプリケーションシステムのために簡単かつ効率的な権限の管理方法を設計することは、システムとシステムユーザーの共通の要件になっている。
【０００７】
ロールベースの権限制御メカニズムにより、システムのアクセス権を簡単かつ効率的に管理できる。これにより、システム権限管理の負担とコストが大幅に削減され、さらに、システム権限管理は、アプリケーションシステムのビジネス管理仕様とより一致している。
【０００８】
ただし、従来のロールベースのユーザー権限管理は、「ロール対ユーザー、１対多」の関連付けメカニズムを採用し、「ロール」はグループ／クラスの性質を有する。つまり、１つのロールは複数のユーザーが同時期に対応する／関連付けることができる。ロールは、役職／職務／職種の概念に似ている。この関連付けメカニズムに基づくユーザー権限の承認は、基本的に次の３つの形式に分けられる。１、図１に示すように、ユーザーが直接承認されるが、不利な点は、ワークロードが大きく、操作が頻繁且つ面倒である。従業員の変更（異動、離職など）が発生した場合、従業員に関わるすべての権限を適宜調整する必要がある。特に会社の経営陣にとっては、関与する権限が多く、権限調整の作業負荷が大きく複雑であり、ミスや脱落を起こしやすく、会社の正常な運転に影響を及ぼし、予測不可能な損失さえ引き起こす。
【０００９】
２、図２に示すように、ロール（クラス／グループ／役職／職種）は承認され（１つのロールを複数のユーザーに関連付けることができる）、ユーザーはロールを介して権限を取得し、権限承認の主体がグループ／クラスという性質を有するロールである。３、図３に示すように、上記の２つの方法が組み合わされている。
【００１０】
上記の説明では、２と３の両方にクラス／グループの性質を有するロールを承認する必要があり、クラス／グループ／役職／職種を有するロールを介して承認を行なう方法には次の欠点がある。１、ユーザーのアクセス権限が変わる場合、操作が難しくなる。実際のシステム使用プロセスでは、多くの場合、運用プロセス中にユーザーの権限を調整する必要がある。たとえば、従業員の権限の変更を処理する場合、ロールの関連付けた従業員の権限を変更するが、ロールは権限の変更されない他の従業員も関連付けたことで、個々の従業員の権限の変更により、ロール全体の権限を変更することができない。そのため、この状況に対応して、権限の変更した従業員に適うために新しいロールを作成するか、権限要件に基づいて従業員を直接承認（ロールからの離脱）する。上記の２つの処理方法は、ロールの権限が多数ある場合、ロールの承認に長い時間がかかるだけでなく、ミスを犯しやすく、ユーザーの操作がわずらわしく、面倒であり、システムユーザーの損失につながるエラーも発生しやすい。
【００１１】
従業員／ユーザーのフォーム操作権限を変更する場合、従業員／ユーザーをロールから離脱するか、承認プロセスの要件を満たすために新しいロールを追加する。１番目の方式は、欠陥が上記の「ユーザーを直接承認する」方法と同じである。２番目の方式は、新しいロールがロールの作成や関連付けや承認に関わる。特に、ロールが多くなるし、ロールを関連付けたユーザーも多くなる場合、どのユーザーがロールを具体的に関連付けているかを覚えるのは困難である。
【００１２】
２、ロールの含む特定の権限を長期的に覚えることは困難である。ロールに複数の権限機能がある場合、時間が経つにつれて、ロールの特定の権限を覚えることは困難になり、権限の類似したロール間の権限差別を覚えるのがより難しくなり、ロールの類似した権限も混同し易い。新しいユーザーを関連付けると、どうやって関連付けるかを正確に判断することはできない。
【００１３】
３、ユーザーの権限が変わることによって、ロールをその都度作成するということをもたらす（新しいロールを作成しない場合、ユーザーを直接承認する回数が大幅に増加する）。各ロール間の特定の差別を区別することはより困難である。
【００１４】
４、役職を調整するときに、異動するユーザーの多くの権限を他の複数のユーザーに割り当てる場合、異動するユーザーの権限を区分し、他の複数のユーザーを関連付けるためにそれぞれロールを作成する必要があるが、このような操作は、複雑であり、時間がかかるだけでなく、エラーが発生しやすい。
【発明の概要】
【発明が解決しようとする課題】
【００１５】
本発明の目的は、現行技術の欠陥を克服し、列値に基づいて統計列表操作権限をそれぞれ承認する方法を提供し、統計列表の統計データをより綿密に制御することができ、管理の精細度を大幅に向上させ、企業および事業団体の要求を実際の運営使用中に満たす。
【課題を解決するための手段】
【００１６】
本発明の目的は、以下の技術的手段により達成される。列値に基づいて統計列表操作権限をそれぞれ承認する方法は、統計列表の操作権限の承認ステップ及び被承認者の選定ステップを含み、統計列表の操作権限の承認ステップと被承認者の選定ステップには前後順序がなく、前記統計列表の操作権限の承認ステップは、Ｓ１：承認する必要がある統計列表を選定すること；Ｓ２：統計列表に承認する必要がある列を選択し、選択された列は列値を選択確定或は自動確定にする列であるべきであること；Ｓ３：選択された列の全ての列値のそれぞれ対応する統計データにより操作権限を与えることを含み、前記被承認者の選定ステップに一つ或は複数の被承認者を選択する。
【００１７】
前記操作権限は検分を含む。前記「選択された列は列値を選択確定或は自動確定にする列であるべきである」のうちの選択確定或は自動確定は、此処に前記列値が選択により決定されること（例えば、顧客統計列表中の顧客業界という列の列値に製造や金融や航空等が選択できる。これらの列値を人の手で記入することなく、選択方式により取得する。さらに、例えば、顧客の所在する城市や責任部門や顧客責任者や顧客責任者ロール等の列の列値も選択により決定される）或は自動的に決定されること（例えば、統計列表の、フォーム作成者、記録者、フォーム製作ロール、フォーム製作ユーザー、フォーム作る人等の列、これらの列値は相関規則により自動的に決定される）を特に指す。
【００１８】
検分権限の具わらない列値に対応する統計データに対して、その表示方式は、（１）その列値を表示するが、その列値に対応する統計データを隠し符で隠すこと；（２）その列値及びその列値に対応する統計データを全く表示しないこと、上記の一種或は多種を含む。
【００１９】
前記被承認者を一つのみとなるように選定し、且つ承認する必要がある統計列表、統計列表中に承認する必要がある列を選定する時に、この前にその被承認者がその統計列表中のその列の各列値に対応する統計データを操作する権限の承認状態を表示する。
【００２０】
前記被承認者を二つ或は二つ以上となるように選定し、且つ承認する必要がある統計列表、統計列表中に承認する必要がある列を選定する時に、その被承認者がその統計列表中のその列の各列値に対応する統計データを操作する権限の承認状態を表示しない。
【００２１】
前記被承認者を一つのみとなるように選定し、且つ承認する必要がある統計列表、統計列表中に承認する必要がある列を選定する時に、その被承認者に対してその統計列表中のその列を前回承認した操作者と操作時間を表示する。
【００２２】
前記被承認者は一つ或は複数のロールであり、前記ロールはグループ／クラスではなく、独立した個体であり、一つのロールは同時期に唯一のユーザーを関連付けることができ、一つのユーザーは一つ或は複数のロールを関連付ける。
【００２３】
列値に基づいて統計列表操作権限をそれぞれ承認する方法は、テンプレート承認のステップも含み、（１）被承認者、承認する必要がある統計列表、承認する必要がある列を選択し、一つ或は複数の被承認者を選定し、承認する必要がある一つの統計列表を選定し、選定された統計列表から承認する必要がある列を選択すること；（２）被承認者を承認し、一つの既有の被承認者或は作成済のテンプレートを設定して承認テンプレートとし、その承認テンプレートのその統計列表のその列の各列値に対応する統計データの操作権限をその被承認者に与えること；（３）修正した後或は修正しないまま保存してその被承認者がその統計列表のその列の各列値に対応する統計データを操作する権限を取得することを具体的に含む。
【００２４】
列値に基づいて統計列表操作権限をそれぞれ承認する方法は、統計列表の操作権限の承認ステップ及び被承認者の選定ステップを含み、統計列表の操作権限の承認ステップと被承認者の選定ステップには前後順序がなく、前記統計列表の操作権限の承認ステップは、Ｓ１：承認する必要がある統計列表を選定すること；Ｓ２：統計列表に承認する必要がある列を選択し、選択された列は列値を選択確定或は自動確定にする列であるべきであること；Ｓ３：選択された列の全ての列値のそれぞれ対応する統計データにより操作権限を与え、承認プロセスは、選択された列の列値のヌル値である統計データに対して操作権限を全体に承認するステップを含むことを含む。
【００２５】
列値に基づいて統計列表操作権限をそれぞれ承認する方法は、統計列表の操作権限の承認ステップ及び被承認者の選定ステップを含み、統計列表の操作権限の承認ステップと被承認者の選定ステップには前後順序がなく、前記統計列表の操作権限の承認ステップは、Ｓ１：承認する必要がある統計列表を選定すること；Ｓ２：統計列表に承認する必要がある列を選択し、選択された列は列値を選択確定或は自動確定にする列であるべきであること；Ｓ３：選択された列の全ての列値のそれぞれ対応する統計データにより操作権限を与え、承認プロセスは、選択された列の全ての列値に対応する統計データに対して操作権限を全体に承認するステップを含み、全ての列値はヌル値である列値を含むことを含む。
【発明の効果】
【００２６】
本発明の有益な効果は次のとおりである：１）本発明は、列値により統計列表中の統計データの操作権限をそれぞれ承認し、一つの統計列表は様々な統計データの操作権限を承認した後異なる実際の使用需要を満足することができ、統計列表の統計データをより綿密に制御することができ、管理の精細度を大幅に向上させ、企業および事業団体の要求を実際の運営使用中に満たす。
【００２７】
例えば、「販売契約の統計列表」に対して、その統計列表中の列名には署名部門や契約数量や契約金額や返金金額や注文数や出荷数量があり、署名部門の列値には販売一部や販売二部や販売三部等がある。販売総監に全体の販売部門の販売契約の統計データを提供する必要がある場合に、販売総監を被承認者として選定することができる。署名部門の列値が販売一部や販売二部や販売三部等である統計データに対して全て検分権限が備わるようにその権限を設定する。販売二部の経理に販売二部の販売契約の統計データを提供する必要のみがある場合に、販売二部の経理を被承認者として選定することができる。署名部門の列値が販売二部である統計データのみに対して検分権限が備わるようにその権限を設定する。
【００２８】
２）被承認者を一つ選定し、且つ承認する必要がある統計列表、統計列表に承認する必要がある列を選定する時に、その被承認者に対してその統計列表中のその列を最近承認した操作者及び操作時間を表示することができる。最近の操作者を表示して権限承認の間違いとなる時に出所と責任を探し出すのに都合がよい。最近の操作時間を表示してその統計列表中のその列に操作権限をもう一度与えるかどうかを直感的に判断するのに都合がよい。
【００２９】
例えば、李四は、２０１５年５月２１日１１：００に張三という被承認者が「販売契約の統計列表」、「署名部門」の統計データを前回検分する権限の承認操作を完成する。被承認者を張三と選定し、承認する必要がある統計列表を「販売業績の統計列表」と選定し、承認する必要がある列を「署名部門」と選定する時に、今回の承認操作者には、２０１５年５月２１日１１：００に李四が張三に「販売業績の統計列表」の「署名部門」の検分権限を前回与えたことを表示する。
【００３０】
張三は販売四部の販売契約の統計データを検分するべきではないとき、張三を前回承認した時に張三に販売四部の販売契約の統計データを検分する権限を持たせていた場合、責任者を探し出している後続の過程では前回の承認操作者を検索することにより責任者を見つけることができる。
【００３１】
さらに、例えば、操作者は１００人の被承認者に対して統計列表の操作権限を承認する必要があるが、即日、その操作者は７０人の被承認者に対する承認のみを完成した。その操作者は翌日に承認を続ける時、各被承認者の前回承認された時間を検分することにより、その被承認者を承認する必要があるかどうかを判断することができる。また、承認時間間隔により、指定された時間間隔に承認されたすべての被承認者を捜し出すこともできる。被承認者の前回承認された時間を検分することにより、被承認者の権限が修正されていない期間を知ることができるのは、其れを再承認する必要があるかどうかを直感的に判断するのに都合がよい。
【００３２】
３）本方法では、複数の被承認者を同時に選択して一括して承認することができ、承認効率を向上させる。他に、本方法はテンプレート承認を支える。即ち、一つの既存のロール或いは作成済のテンプレートを選択して承認テンプレートとし、その承認テンプレートのその統計列表のその列の操作権限をその被承認者（再度簡単に修正された後保存された）に直接与える（更新）。承認操作は簡単かつ高効率になる。２つの方法を組み合わせることにより、統計列表の操作権限の承認効率を大幅に向上させる。
【００３３】
４）本発明は、列値のヌル値である統計データに対して有効的な一括の権限承認を行うことができ、承認操作が便利となり、承認作業量が小さくなる。いわゆる「列値のヌル値である」は列の内容がヌル値であること（未記入或は未選択）を指し、例えば、契約を追加する時に署名部門を記入しない（その原因は、署名部門は記入必須項目ではない可能性があり、選択なしに契約を提出することができる）、或は契約が兼職業務員に由来する場合、列名「署名部門」によりこのような統計データに対して権限を与えることができない。この種類のデータが署名部門の列値のヌル値であるデータと分けられる。「ヌル」項目を選択することによりこの種類のデータの統計結果を一括して承認して操作が便利になる。
【００３４】
５）本発明は、選択された列の全ての列値の統計データに対して操作権限を一括与えることができ、承認操作は簡単になり、効率が高く、列に各列値の統計データの操作権限が同じである場合に特に適用する。例えば、署名部門の列値が何であるかに関わらず、統計データの操作権限が全て同じであり、且つそれに限らず、従って、その操作権限に「無制限」を直接選定し、すべての列値に対応する統計データがその操作権限であると表示する。「無制限」という機能を設定すると二つの利点がある：一つは、すべての権限を持つ会社高層指導者を承認する時、「無制限」を選定し利用することが可能である。もう一つは、「無制限」を選定した後、列値が増えても、選択されたのは「無制限」であるので、その被承認者の権限が依然として影響を受けない（無制限）。
【００３５】
６）本発明に、被承認者は独立した個体の性質を有するロールを採用することができる。従業員が離職し異動する時、ユーザーはロールと関連付ける／関連を取り消すことにより統計列表の操作権限の切り替えと更新をついでに実現し、操作権限のシームレスな引継ぎを達成することができ、ユーザーの統計列表の操作権限を適時に更新することを確保し、操作権限の更新の延時或は遺脱を防止し、企業の正常な運営に影響を及ぼさず、機密情報の洩れる危険も回避する。
【００３６】
離職を例にとって、張三という従業員に対応するユーザはロール「生産労働者１」を関連付けた。張三が離職する時、システム管理員（相応の管理員）は張三に対応するユーザとロール「生産労働者１」の関連を取り消すと、張三は「生産労働者１」に対応する統計列表の操作権限を自動的に失い、統計列表の操作権限の引継ぎが遅くなって張三が離職した後に幾つかの機密情報の検分する権限を持たせて相関の機密情報を張三に漏らすのにつながるのを回避する。李四という新入社員が張三の仕事を引き継ぐ時に、李四に対応するユーザーに「生産労働者１」を直接関連付けると、李四はロール「生産労働者１」に対応する統計列表の操作権限を自動的に取得し、李四に統計列表の操作権限をもう一度設置する必要がなく、操作が易くて速く、作業量を大幅に低減する。
【００３７】
異動を例にとると、従業員が生産部門から販売後部門への異動を希望すると、システム管理員（相応の管理員）は張三に対応するユーザと元のロール「生産労働者１」の関連を取り消して販売後部門の新しいロール「販売後サービススタッフ３」を再度関連付けると、張三は「販売後サービススタッフ３」に対応する統計列表の操作権限を自動的に取得する。
【００３８】
７）本発明は、ロールがユーザーとの１対１の関係にあり、一つのロールが唯一のユーザーを同時期に関連付けることができる。この利点は、ユーザーをロールに関連付けて権限を取得し（つまり、ユーザーは、その関連付けたロールの権限を取得する）、しかもロールの権限の変更は、従来のメカニズムにあるロールの権限の変更よりもはるかに小さくなる。独立した個体の性質（役職番号／職務番号の性質）を有するロールの数は少ない。従業員の異動は大きいが、役職番号／職務番号の変化は小さい（一定期間に変化さえなく、つまりロールは変わらない）。これにより、ユーザーの権限管理を大幅に簡易化し、システムの負担を削減する。
【００３９】
８）動的な管理、入職や異動等の操作が簡単と便利となり、効率と信頼性が高くなる。入職／離職／異動の適用は承認プロセスで簡単である。従業員／ユーザーを変更する場合、承認プロセスを再設定する必要がない。ユーザーはロールを取り消し、ロールを関連付けてもよい。そのロールを担わないユーザーは、ロールの関連付けを取り消し、そのロールを引き継ぐユーザーは、その役職番号のロールを関連付ける。ロールを関連付けたユーザーは、そのロールの統計列表操作権限を自動的に取得し、ロールを再承認する必要がない。これにより、プロセス設定の効率やセキュリティや信頼性を大幅に向上させる。
【００４０】
たとえば、張三というユーザーが離職または異動する原因で、張三は「バイヤー３」というロールとして働かなくなると、張三はロールとの関連付けを取り消す。ほかに、李四は、「バイヤー３」というロールとする仕事を引き継ぎ、李四はこのロールを関連付けられると、李四は承認プロセス中の「バイヤー３」というロールの統計列表の操作権限を自動的に取得する。
【００４１】
９）従来の権利管理メカニズムでは、ロールをグループ、職種、クラスなどに定義し、ロールがユーザーとの１対多の関係にある。実際にシステムを使用するプロセスでは、運用プロセス中にユーザーの権限を調整する必要がある。たとえば、従業員の権限変更を処理する場合、ロールを関連付ける従業員の権限が変更されるが、このロールは権限の変更しない他の従業員を関連付けており、個々の従業員の権限を変更するために、全体のロールの権限は変更できない。そのため、この状況に対応して、権限の変更された従業員に適うために新しいロールを作成するか、権限要件に基づいて従業員を直接承認（ロールからの離脱）する。上記の２つの処理方法は、ロールの権限が多数ある場合、ロールの承認に長い時間がかかるだけでなく、ミスを犯しやすく、ユーザーの操作がわずらわしく、面倒であり、システムユーザーの損失につながるエラーも発生しやすい。
【００４２】
しかし、本発明の方法では、ロールが独立した個体であるため、ロール権限を変更して目標を達成することができる。本発明の方法は、システムの初期化時にワークロードを増加させるように見えるが、ロールの作成或は権限授与の効率は、コピーなどの方法によってグループの性質を有する従来のロールより高くさせる。ユーザーを関連つける時にグループの性質を有するロールの共通性を考慮しないため、この発明技術的手段は、承認設定を明確にさせる。特に、システムが一定期間使用された後（ユーザー／ロールの権限が動的に変化している）、この発明技術的手段は、システム使用時のシステム管理の効率を大幅に向上させ、動的承認をより簡単、便利、明確にさせ、権限設定の効率と信頼性を向上させる。
【００４３】
１０）従来のグループ／クラスの性質を有するロールの承認方法はエラーが発生しやすく、本発明の方法では、従来の方法でこのグループの性質を有するロールを関連付ける複数のユーザーにどのような共通性があるかを考慮することなく、ロールを独立した個体として考慮するだけでよいため、本発明の方法は権限エラーの確率を大幅に低減させる。承認エラーが発生した場合でも、ロールを関連付けるその一つのユーザーのみに影響するが、従来のグループの性質を有するロールはそのロールを関連付ける全部のユーザーに影響する。承認エラーが発生した場合でも、本発明の修正方法は簡単であり、時間が短く、従来のグループの性質を有するロールはエラーを修正する時にそのロールを関連付ける全部のユーザーの共通性を考えなければならない。機能ポイントが多い場合、変更が面倒且つ複雑であるだけでなく、非常にエラーが発生しやすく、且つ多くの場合、新しいロールを作成するだけで解決できる。
【００４４】
１１）従来のグループの性質を有するロールの承認方法では、ロールの権限機能ポイントが多くある場合、時間が長くなると、ロールの具体的な権限を覚えにくく、権限の近付くロールの間の区別を覚えるのはより困難である。本発明の方法のロール自身は、役職番号／職務番号の性質を有しており、選択は明らかである。
【００４５】
１２）異動するときに、異動されたユーザーの多くの権限を他のユーザーに割り当てる場合、処理する時に異動されたユーザーのこれらの権限を区別して、他のユーザーを関連付けるようにロールをそれぞれ作成する必要がある。このような操作は、複雑であり、時間がかかるだけでなく、エラーが発生しやすくなる。
【００４６】
本発明の方法は次のとおりである：異動されたユーザーはいくつかのロールを関連付け、異動する場合、まずユーザーと元の部門のロールの関連を取り消し（これらの取り消されたロールは他のユーザーを再度関連付けることができる）、ユーザーは新しい部門のロールを関連付けてもよい。操作は簡単であり、エラーが現れない。
【図面の簡単な説明】
【００４７】
【図１】背景技術においてシステムがユーザーを直接承認する方法の概略図である。
【図２】背景技術においてシステムがグループ／クラスの性質を有するロールを承認する方法の概略図である。
【図３】背景技術においてシステムがユーザーを直接承認し、グループ／クラスの性質を有するロールを承認して組み合わせる方法の概略図である。
【図４】本発明のシステムにおいて独立した個体の性質を有するロールを介してユーザーを承認する方法の概略図である。
【図５】本発明において被承認者が一つであり且つ統計列表及び列を選定する時の概略図である。
【図６】本発明の販売契約の統計列表の一種の表示方式の概略図である。
【図７】本発明の販売契約の統計列表のもう一種の表示方式の概略図である。
【図８】李二が販売契約の統計列表に列名の署名部門である各列値に対応する統計データの操作権限を与える状態の概略図である。
【図９】本発明において選定された被承認者が複数であり且つ統計列表及び列を選定する時の概略図である。
【図１０】本発明に最近の承認操作者及び操作時間を表示する概略図である。
【図１１】本発明において承認テンプレートを被承認者として承認を行う時の概略図である。
【発明を実施するための形態】
【００４８】
本発明の技術的手段は、添付の図面を参照して以下でさらに詳細に説明されるが、本発明の保護範囲は以下に限定されない。
【実施例１】
【００４９】
列値に基づいて統計列表操作権限をそれぞれ承認する方法は、統計列表の操作権限の承認ステップ及び被承認者の選定ステップを含み、統計列表の操作権限の承認ステップと被承認者の選定ステップには前後順序がない。前記操作権限は検分を含む。
【００５０】
前記統計列表の操作権限の承認ステップは、以下のステップを含む。Ｓ１：承認する必要がある統計列表を選定する。Ｓ２：統計列表に承認する必要がある列を選択し、選択された列は列値を選択確定（例えば、顧客統計列表中の顧客業界という列の列値に製造や金融や航空等が選択できる。これらの列値を人の手で記入することなく、選択方式により取得する。さらに、例えば、顧客の所在する城市や責任部門や顧客責任者や顧客責任者ロール等の列の列値も選択により決定される）或は自動確定（例えば、統計列表の、フォーム作成者、記録者、フォーム製作ロール、フォーム製作ユーザー、フォーム作る人等の列、これらの列値は相関規則により自動的に決定される）にする列であるべきである。Ｓ３：選択された列の全ての列値のそれぞれ対応する統計データにより操作権限を与える。前記被承認者の選定ステップに一つ或は複数を被承認者を選択し、被承認者は従業員やユーザーやグループ／クラスの性質を有するロールや独立した個体の性質を有するロール等である。
【００５１】
本実施例は、列値により統計列表中の統計データの操作権限をそれぞれ承認し、一つの統計列表は様々な統計データの操作権限を承認した後異なる実際の使用需要を満足することができ、統計列表の統計データをより綿密に制御することができ、管理の精細度を大幅に向上させ、企業および事業団体の要求を実際の運営使用中に満たす。
【００５２】
例えば、「販売契約の統計列表」に対して、その統計列表中の列名には署名部門や契約数量や契約金額や返金金額や注文数や出荷数量があり、列名の署名部門である対応の列値には販売一部や販売二部や販売三部がある。張三という販売総監に全体の販売部門の販売契約の統計データを提供する必要がある場合に、張三を被承認者として選定することができる。統計列表を「販売契約の統計列表」と設定し、列名を「署名部門」と選定し、列値が販売一部や販売二部や販売三部である統計データに対して全て検分権限が備わるようにその権限を設定する。
【００５３】
図５に示すように、販売二部の経理に販売二部の販売契約の統計データを提供する必要のみがある場合に、李二という販売二部の経理を被承認者として選定することができる。統計列表を「販売契約の統計列表」と設定し、列名を「署名部門」と選定し、列値が販売二部である統計データのみに対して検分権限が備わるようにその権限を設定する。
【００５４】
本実施例には、検分権限の具わらない列値に対応する統計データに対して、その表示方式は以下の一種或は多種を含む。（１）図６に示すように、その列値を表示するが、その列値に対応する統計データを隠し符で隠す。（２）図７に示すように、その列値及びその列値に対応する統計データを全く表示しない（全く表示しないのは、全く表示しないと表すことができる。図７に示すように、「……」で標記された部分は全く表示せず、つまり、その行を表示し出さない或はその行を失う）。
【実施例２】
【００５５】
前記被承認者を一つのみとなるように選定し、且つ承認する必要がある統計列表、統計列表中に承認する必要がある列を選定する時に、この前にその被承認者がその統計列表中のその列の各列値に対応する統計データを操作する権限の承認状態を表示する（図８に示すように、この前、李二は、「販売契約の統計列表」に列名「署名部門」の列値の「販売一部」や「販売二部」や「販売三部」である統計データに対して検分権限を全て持つ）。
【実施例３】
【００５６】
前記被承認者を二つ或は二つ以上となるように選定し、且つ承認する必要がある統計列表、統計列表中に承認する必要がある列を選定する時に、その被承認者がその統計列表中のその列の各列値に対応する統計データを操作する権限の承認状態を表示しない（図９に示すように）。
【実施例４】
【００５７】
図１０に示すように、前記被承認者を一つのみとなるように選定し、且つ承認する必要がある統計列表、統計列表中に承認する必要がある列を選定する時に、その被承認者に対してその統計列表中のその列を前回承認した操作者と操作時間を表示する。
【００５８】
最近の操作者を表示して権限承認の間違いとなる時に出所と責任を探し出すのに都合がよい。最近の操作時間を表示してその統計列表中のその列に操作権限をもう一度与えるかどうかを直感的に判断するのに都合がよい。
【００５９】
例えば、李四は、２０１５年５月２１日１１：００に張三という被承認者が「販売契約の統計列表」、「署名部門」の統計データを前回検分する権限の承認操作を完成する。被承認者を張三と選定し、承認する必要がある統計列表を「販売業績の統計列表」と選定し、承認する必要がある列を「署名部門」と選定する時に、今回の承認操作者には、２０１５年５月２１日１１：００に李四が張三に「販売業績の統計列表」の「署名部門」の検分権限を前回与えたことを表示する。
【００６０】
張三は販売四部の販売契約の統計データを検分するべきではないと、張三を前回承認した時に張三に販売四部の販売契約の統計データを検分する権限を持たせて、責任を探し出している後続の過程では前回の承認操作者を検索することにより責任者を見つけることができる。
【００６１】
さらに、例えば、操作者は１００人の被承認者に対して統計列表の操作権限を承認する必要があるが、即日、その操作者は７０人の被承認者に対する承認のみを完成した。その操作者は翌日に承認を続ける時、各被承認者の前回承認された時間を検分することにより、その被承認者を承認する必要があるかどうかを判断することができる。また、承認時間間隔により、指定された時間間隔に承認されたすべての被承認者を捜し出すこともできる。被承認者の前回承認された時間を検分することにより、被承認者の権限が修正されていない期間を知ることができるのは、其れを再承認する必要があるかどうかを直感的に判断するのに都合がよい。
【実施例５】
【００６２】
列値に基づいて統計列表操作権限をそれぞれ承認する方法は、テンプレート承認のステップも含み、（１）被承認者、承認する必要がある統計列表、承認する必要がある列を選択し、一つ或は複数の被承認者を選定し、承認する必要がある一つの統計列表を選定し、選定された統計列表から承認する必要がある列を選択すること；（２）被承認者を承認し、一つの既有の被承認者或は作成済のテンプレートを設定して承認テンプレートとし、その承認テンプレートのその統計列表のその列の各列値に対応する統計データの操作権限をその被承認者に与えること；（３）修正した後或は修正しないまま保存してその被承認者がその統計列表のその列の各列値に対応する統計データを操作する権限を取得することを具体的に含む。
【００６３】
例えば、図１１に示すように、張三が販売契約の統計列表中の署名部門の各列値に対応する統計データを操作する権限を、承認テンプレートとして李二を承認する。
【００６４】
本方法では、複数の被承認者を同時に選択して一括して承認することができ、承認効率を向上させる。他に、本方法はテンプレート承認を支える。即ち、一つの既存のロール或いは作成済のテンプレートを選択して承認テンプレートとし、その承認テンプレートのその統計列表のその列の操作権限をその被承認者（再度簡単に修正された後保存された）に直接与える（更新）。承認操作は簡単かつ高効率になる。２つの方法を組み合わせることにより、統計列表の操作権限の承認効率を大幅に向上させる。
【実施例６】
【００６５】
列値に基づいて統計列表操作権限をそれぞれ承認する方法は、統計列表の操作権限の承認ステップ及び被承認者の選定ステップを含み、統計列表の操作権限の承認ステップと被承認者の選定ステップには前後順序がなく、前記統計列表の操作権限の承認ステップは、以下のステップを含む。Ｓ１：承認する必要がある統計列表を選定する；Ｓ２：統計列表に承認する必要がある列を選択し、選択された列は列値を選択確定或は自動確定にする列であるべきである；Ｓ３：選択された列の全ての列値のそれぞれ対応する統計データにより操作権限を与え、承認プロセスは、選択された列の列値のヌル値である統計データに対して操作権限を全体に承認するステップを含む。
【００６６】
前記被承認者の選定ステップに一つ或は複数を被承認者を選択し、被承認者は従業員やユーザーやグループ／クラスの性質を有するロールや独立した個体の性質を有するロール等である。
【００６７】
図５、図８−１１に示すように本発明は、列値のヌル値である統計データに対して有効的な一括の権限承認を行うことができ、承認操作が便利となり、承認作業量が小さくなる。いわゆる「列値のヌル値である」は列の内容がヌル値であること（未記入或は未選択）を指し、例えば、契約を追加する時に署名部門を記入しない（その原因は、署名部門は記入必須項目ではない可能性があり、選択なしに契約を提出することができる）、或は契約が兼職業務員に由来する場合、列名「署名部門」によりこのような統計データに対して権限を与えることができない。この種類のデータが署名部門の列値のヌル値であるデータと分けられる。「ヌル」項目を選択することによりこの種類のデータの統計結果を一括して承認して操作が便利になる。
【実施例７】
【００６８】
列値に基づいて統計列表操作権限をそれぞれ承認する方法は、統計列表の操作権限の承認ステップ及び被承認者の選定ステップを含み、統計列表の操作権限の承認ステップと被承認者の選定ステップには前後順序がなく、前記統計列表の操作権限の承認ステップは、以下のステップを含む。Ｓ１：承認する必要がある統計列表を選定する；Ｓ２：統計列表に承認する必要がある列を選択し、選択された列は列値を選択確定或は自動確定にする列であるべきである；Ｓ３：選択された列の全ての列値のそれぞれ対応する統計データにより操作権限を与え、承認プロセスは、選択された列の全ての列値の統計データに対して操作権限を全体に承認するステップを含み、全ての列値はヌル値である列値を含む。
【００６９】
前記被承認者の選定ステップに一つ或は複数を被承認者を選択し、被承認者は従業員やユーザーやグループ／クラスの性質を有するロールや独立した個体の性質を有するロール等である。
【００７０】
図５、図８−１１に示すように、本発明は、選択された列の全ての列値の統計データに対して操作権限を一括与えることができ、承認操作は簡単になり、効率が高く、列に各列値の統計データの操作権限が同じである場合に特に適用する。例えば、署名部門の列値が何であるかに関わらず、統計データの操作権限が全て同じであり、且つそれに限らず、従って、その操作権限に「無制限」を直接選定し、すべての列値に対応する統計データがその操作権限であると表示する。「無制限」という機能を設定すると二つの利点がある：一つは、すべての権限を持つ会社高層指導者（例えば、販売総監）を承認する時、「無制限」を選定し利用することが可能である。もう一つは、「無制限」を選定した後、列値が増えても、選択されたのは「無制限」であるので、その被承認者の権限が依然として影響を受けない（つまり、増えた列値に対応する統計データは権限も具わる）。
【実施例８】
【００７１】
列値に基づいて統計列表操作権限をそれぞれ承認する方法は、統計列表の操作権限の承認ステップ及び被承認者の選定ステップを含み、前記統計列表の操作権限の承認ステップは、以下のステップを含む。Ｓ１：承認する必要がある統計列表を選定する；Ｓ２：統計列表に承認する必要がある列を選択し、選択された列は列値を選択確定或は自動確定にする列であるべきである；Ｓ３：選択された列の全ての列値のそれぞれ対応する統計データにより操作権限を与える。前記被承認者の選定ステップに一つ或は複数を被承認者を選択し、前記被承認者は一つ或は複数のロールである。図４に示すように、前記ロールは、グループ／クラスではなく、独立した個体であり、同時期に一つのロールが唯一のユーザーを関連付けることができ、一つのユーザーが１つ或は複数のロールを関連付ける。ロールの作業内容によりロールを承認し、ユーザーはその関連付けたロールの権限を取得する。
【００７２】
本実施例に、被承認者は独立した個体の性質を有するロールを採用し、従業員が離職し異動する時、ユーザーはロールと関連付ける／関連を取り消すことにより統計列表の操作権限の切り替えと更新をついでに実現し、操作権限のシームレスな引継ぎを達成することができ、ユーザーの統計列表の操作権限を適時に更新することを確保し、操作権限の更新の延時或は遺脱を防止し、企業の正常な運営に影響を及ぼさず、機密情報の洩れる危険も回避する。
【００７３】
離職を例にとって、張三という従業員に対応するユーザはロール「生産労働者１」を関連付けた。張三が離職する時、システム管理員（相応の管理員）は張三に対応するユーザとロール「生産労働者１」の関連を取り消すと、張三は「生産労働者１」に対応する統計列表の操作権限を自動的に失い、統計列表の操作権限の引継ぎが遅くなって張三が離職した後に幾つかの機密情報の検分する権限を持たせて相関の機密情報を張三に漏らすことにつながることを回避する。李四という新入社員が張三の仕事を引き継ぐ時に、李四に対応するユーザーに「生産労働者１」を直接関連付けると、李四はロール「生産労働者１」に対応する統計列表の操作権限を自動的に取得し、李四に統計列表の操作権限をもう一度設置する必要がなく、操作が易くて速く、作業量を大幅に低減する。
【００７４】
異動を例にとると、従業員が生産部門から販売後部門への異動を希望すると、システム管理員（相応の管理員）は張三に対応するユーザと元のロール「生産労働者１」の関連を取り消して販売後部門の新しいロール「販売後サービススタッフ３」を再度関連付けると、張三は「販売後サービススタッフ３」に対応する統計列表の操作権限を自動的に取得する。
【００７５】
更に、ロールを作成した時或は後にそのロールのために一つの部門を選定すると、そのロールがその部門に属し、ロールの作業内容によりロールを承認し、且つそのロールの名称がその部門に唯一であり、そのロールの番号がシステムに唯一である。前記ユーザーが異動する時、ユーザーと元のロールの関連を取り消して、ユーザーを新しいロールに関連付ける。
【００７６】
ユーザーが異動を必要とする場合に、ユーザーの異動管理のステップを更に含み、（１）ユーザーと元のロールの関連を取り消すこと；（２）ユーザーを異動した後の対応の新しいロールに関連付け、ユーザーはその新しいロールの統計列表の操作権限を自動的に取得することを具体的に含む。
【００７７】
以下は、独立した個体の性質を有するロールを介してユーザーを承認する方法の利点を分析している。ユーザーは、それとロールの関連により権限を（取得）決定する。ユーザーの権限を修正しようとしている場合、ロールの所有する権限を調整することによりそのロールを関連付けるユーザーの権限を変更する目的を達成する。ユーザーがロールを関連付けると、そのユーザーはそのロールの統計列表の操作権限を持っている。
【００７８】
ロールは、ユーザーとの１対１の関係にある（そのロールは、ユーザーを関連付ける場合、他のユーザーはそのロールをもう一度関連付けることができない；そのロールは、ユーザーを関連付けていない場合、他のユーザーが選択して関連付けることができる）。ユーザーは、ロールとの１対多の関係にある（一つのユーザーは同時に複数のロールを関連付けることができる）。
【００７９】
ロールの定義：ロールは、グループ／クラス／カテゴリ／役職／職務／職種の性質を有しないが、非集合の性質を有する。ロールは唯一性を有し、独立して存在している個体である。ロールは企業や機関の応用で役職番号と同等である（役職番号はここで役職ではなく、一つの役職に同時に複数の従業員がいるが、１つの役職番号は同時に一つの従業員にしか対応できない）。
【００８０】
たとえば、会社のシステムは次のロールを作成する可能性がある：総経理、副総経理１、副総経理２、北京販売部Ｉの経理、北京販売部ＩＩの経理、北京販売部ＩＩＩの経理、上海販売エンジニア１、上海販売エンジニア２、上海販売エンジニア３、上海販売エンジニア４、上海販売エンジニア５  等。ユーザーとロールの関連関係：その会社の従業員である張三は、会社の副総経理２を務め、同時に北京販売部Ｉの経理を務める場合、張三は副総経理２及び北京販売部Ｉの経理というロールを関連付ける必要がある。張三は両方のロールに対する権限を持っている。
【００８１】
従来のロールの概念は、グループ／クラス／役職／職務／職種の性質であり、１つのロールは複数のユーザーに対応できる。本発明の「ロール」の概念は、役職番号／職務番号と同等であり、映画やテレビドラマのロールに似ている。一つのロールは一つの俳優のみに同時に（幼年、少年、中年．．．）演じられ、一つの俳優は複数のロールを演じることができる。
【００８２】
ロールを作成した後、ユーザーを作成するプロセスでロールを関連付けることができ、または、ユーザーを作成した後、いつでもロールを関連付けることができる。ユーザーは、ロールを関連付けた後ロールとの関係がいつでも解除でき、他のロールとの関係がいつでも確立できる。
【００８３】
前記ロールの構成は、職名＋職務番号である。例えば、作業場生産労働者１、作業場生産労働者２、作業場生産労働者３等のロールは、独立した個体であり、これは役職番号／職務番号と同等であり、従来の権限管理システムのロールとは異なる。従来のシステムのロールの概念は、役職／職務／職種等のグループ／クラスの性質である。
【００８４】
次の例では、張三という従業員が入社した後、従業員やユーザーやロールの関係を示していった。１、新入職：従業員は新しく雇用され、そのユーザー（従業員）のために相応の役職番号／職務番号のロールを直接選定して関連付けてもよい。例えば、張三は会社に加わった（会社は張三に張三というユーザーを割り当てた）。仕事内容は、営業部Ｉにおいて、北京地区の冷蔵庫製品の販売を担当することである（対応するロールは販売部Ｉの「販売エンジニア５」というロールである）。次に、張三というユーザーが「販売エンジニア５」というロールを直接選択してもよい。
【００８５】
２、職務の追加：一定期間勤務した後、張三は北京で地域テレビ製品の販売を担当するようになり（対応するロールは販売部Ｉの「販売エンジニア８」というロールである）、同時に販売後部門の主管を兼務した（販売後部門の主管というロールに対応する）。次に、張三というユーザーは、販売部Ｉの「販売エンジニア８」と販売後部門の「販売後主管」という二つのロールを増やして関連付けた。この時に、張三という従業員には、三つのロールを関連付け、これらは、ぞれぞれ販売部Ｉの「販売エンジニア５」、「販売エンジニア８」、及び販売後部門の「販売後主管」であり、張三というユーザーは、この様な３つのロールに対する権限を持った。
【００８６】
３、職務の減少：しばらくして、会社は張三を販売後部門の経理（販売後部門の「販売後経理」というロールに対応する）として任命し、他の仕事を兼務しないようにすることを決めった。次に、張三というユーザーは、販売後部門の「販売後経理」というロールに関連付けられ、以前に関連付けられていた３つのロールを取り消された（販売部Ｉの「販売エンジニア５」、「販売エンジニア８」、及び販売後部門の「販売後主管」）。この時に、張三というユーザーは販売後部門の「販売後経理」というロールの権限のみを持っていた。
【００８７】
４、ロールの権限の調整（ロールの自身所有する権限に対して調整する）：会社が販売後経理の権限を増やすことを決定した場合、販売後経理というロールの権限を増やすだけでよく、張三というユーザーは販売後経理というロールの権限が増加するため、張三というユーザーの権限も増加した。
【００８８】
５、離職：１年後、張三は離職した。張三というユーザーと販売後部門の「販売後主管」というロールの関連を取り消してもよい。
【００８９】
例えば、会社は、動的な経営中に、従業員の入社と退社が頻繁かつ継続的に発生するが、役職番号／職務番号の修正は非常にわずかである（特定の期間で変化しない）。
【００９０】
従来の承認方法：システム機能ポイントが多くある場合、従来のグループ／クラスの性質を有するロールを介して承認する。これは、承認に大量の複雑な作業負荷があるだけでなく、エラーが発生しやすい。エラーは、発生した場合でも、短時間で容易に見つけられず、システムのユーザーに損失を与えやすい。
【００９１】
本発明の承認方法：本発明は、役職番号／職務番号の性質を有するロールに対して承認し、ユーザーがロールを関連付けて権限を決定（取得）すると、ユーザーの権限の制御は、ユーザーとロールの単純な関連により実現される。これにより、権限の制御を簡単、便利、明確にして、権限承認の効率と信頼性を大幅に向上させる。
【００９２】
上記は本発明の優先的な実施形態だけである。本発明は、本明細書に開示された形態に限定されないと理解され、他の実施形態を除くとみなされず、却って様々な他の組み合わせや修正や環境に利用でき、本明細書のコンセプトの範囲内で、上記の教示または関連分野の技術または知識により修正を行うことができる。当業者に行われる修正及び変更は、本発明の趣旨及び範囲から逸脱するものではなく、全部と本発明に添付される請求項の範囲内にあるべきである。
【図１】
2020530614.tif 000003
【図２】
2020530614.tif 000004
【図３】
2020530614.tif 000005
【図４】
2020530614.tif 000006
【図５】
2020530614.tif 000007
【図６】
2020530614.tif 000008
【図７】
2020530614.tif 000009
【図８】
2020530614.tif 000010
【図９】
2020530614.tif 000011
【図１０】
2020530614.tif 000012
【図１１】
2020530614.tif 000013
【国際調査報告】
2020530614.tif 000014
2020530614.tif 000015
2020530614.tif 000016
2020530614.tif 000017
2020530614.tif 000018
2020530614.tif 000019