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