(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-01-31
(45)【発行日】2024-02-08
(54)【発明の名称】使用者に承認プロセスとその承認ノードの権限を与える方法
(51)【国際特許分類】
G06Q 10/06 20230101AFI20240201BHJP
【ＦＩ】
G06Q10/06
【請求項の数】
10
(21)【出願番号】P 2020505892
(86)(22)【出願日】2018-08-09
(65)【公表番号】
(43)【公表日】2020-10-29
(86)【国際出願番号】 CN2018099768
(87)【国際公開番号】W WO2019029649
(87)【国際公開日】2019-02-14
【審査請求日】2021-05-18
(31)【優先権主張番号】201710682787.8
(32)【優先日】2017-08-10
(33)【優先権主張国・地域又は機関】CN
(73)【特許権者】
【識別番号】519375273
【氏名又は名称】成都牽牛草信息技術有限公司
【氏名又は名称原語表記】ＣＨＥＮＧＤＵ ＱＩＡＮＮＩＵＣＡＯ ＩＮＦＯＲＭＡＴＩＯＮ ＴＥＣＨＮＯＬＯＧＹ ＣＯ．， ＬＴＤ．
【住所又は居所原語表記】Ｎｏ．１６０９， １６ｔｈ Ｆｌｏｏｒ， Ｈｅｍｅｉ Ｈａｉｔａｎｇ Ｃｅｎｔｅｒ （Ｔｉａｎｆｕ Ｃｈｕａｎｇｋｅ） Ｎｏ．２０３９， Ｓｏｕｔｈ Ｓｅｃｔｉｏｎ ｏｆ Ｔｉａｎｆｕ Ａｖｅｎｕｅ， Ｔｉａｎｆｕ Ｎｅｗ Ａｒｅａ， Ｃｈｉｎａ （Ｓｉｃｈｕａｎ） Ｐｉｌｏｔ Ｆｒｅｅ Ｔｒａｄｅ Ｚｏｎｅ Ｃｈｅｎｇｄｕ， Ｓｉｃｈｕａｎ ６１００００， Ｃｈｉｎａ
(74)【代理人】
【識別番号】100091683
【弁理士】
【氏名又は名称】▲吉▼川 俊雄
(74)【代理人】
【識別番号】100179316
【弁理士】
【氏名又は名称】市川 寛奈
(72)【発明者】
【氏名】陳達志
【審査官】加内 慎也
(56)【参考文献】
【文献】特開２００４－３３４８４４（ＪＰ，Ａ）
【文献】特開２００８－１３０００６（ＪＰ，Ａ）
【文献】特開２００１－０２２８２７（ＪＰ，Ａ）
【文献】特開２０１７－０２１５５３（ＪＰ，Ａ）
【文献】特開２００３－２２８６４８（ＪＰ，Ａ）
【文献】特開２０００－１３２６２５（ＪＰ，Ａ）
【文献】特開２０１５－０１８５０９（ＪＰ，Ａ）
【文献】米国特許出願公開第２００９／０１８２６０７（ＵＳ，Ａ１）
【文献】特表２００８－５４２８７２（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１４／００８２６８９（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００－９９／００
(57)【特許請求の範囲】
【請求項1】
管理ソフトウェアシステムが使用者に承認プロセスの権限を与える方法であって、承認操作者が前記管理ソフトウェアシステムにおける一人の使用者を選定すること、
前記管理ソフトウェアシステムが、前記管理ソフトウェアシステムにおける全ての承認プロセスを表示し、且つ選定された前記使用者の各承認プロセスに対する現在の使用権限状態を表示すること、及び、
前記管理ソフトウェアシステムが、選定された前記使用者に承認プロセスの使用権限を授与することを含み、
前記使用者はロールを含み、前記ロールはグループ／クラスではなく、独立した個体であり、一つのロールは同時期に唯一のユーザーを関連付けることができ、一つのユーザーは一つ或いは複数のロールを関連付け、ユーザーは関連付けられたロールの権限を取得し、
前記管理ソフトウェアシステムが、選定された前記使用者が使用権限を有する全ての承認プロセスを表示し、これらの承認プロセスに対する前記使用者の使用権限について、前記承認操作者による修正を受け付けて修正された使用権限を抹消し、かつ、選定された前記使用者が使用権限を有しない一つあるいは複数の承認プロセスについて、前記承認操作者による選定を受け付けて選定された承認プロセスに対する前記使用者の使用権限を設定する、方法。
【請求項2】
二つ或いは二つ以上の承認プロセスが同じフォームに属する場合に、一人の使用者に一つの承認プロセスの使用権限を授与することしかできない、請求項１に記載の方法。
【請求項3】
前記使用者はロール、ユーザー、従業員、グループ、及び、クラスのうちの一種或いは複数種を含み、前記ロールはグループ／クラスではなく、独立した個体であり、一つのロールは同時期に唯一のユーザーを関連付けることができ、一つのユーザーは一つ或いは複数のロールを関連付け、ユーザーは関連付けられたロールの権限を取得する、請求項１に記載の方法。
【請求項4】
一人の使用者を選定した後、選定した使用者に各承認プロセスの使用権限を前回授与した操作者及び操作時間をそれぞれ表示する、請求項１に記載の方法。
【請求項5】
管理ソフトウェアシステムが使用者に承認ノードの権限を与える方法であって、承認操作者が前記管理ソフトウェアシステムにおける一人の使用者を選定すること、
前記管理ソフトウェアシステムが、前記管理ソフトウェアシステムにおける全ての承認プロセスの全ての承認ノードを表示し、且つ選定された前記使用者の各承認ノードに対する現在の承認権限状態を表示すること、及び、
前記管理ソフトウェアシステムが、選定された前記使用者に承認ノードの承認権限を授与すること、を含み、
前記使用者はロールを含み、前記ロールはグループ／クラスではなく、独立した個体であり、一つのロールは同時期に唯一のユーザーを関連付けることができ、一つのユーザーは一つ或いは複数のロールを関連付け、ユーザーはその関連付けられたロールの権限を取得し、
前記管理ソフトウェアシステムが、前記使用者が承認権限を有する全ての承認ノードを表示し、これらの承認ノードに対する前記使用者の承認権限について、前記承認操作者による修正を受け付けて修正された承認権限を抹消し、且つ、前記使用者が承認権限を有しない一つ或いは複数の承認ノードについて、前記承認操作者による選定を受け付けて選定された承認ノードに対する前記使用者の承認権限を設定する、方法。
【請求項6】
前記管理ソフトウェアシステムが使用者に承認ノードの権限を与える方法は、選定した使用者に承認ノードの所在する承認プロセスに対応するフォームのフォームフィールド／フィールド値の検分及び／又は修正の権限を授与することも含む、請求項５に記載の方法。
【請求項7】
前記使用者はロール、ユーザー、従業員、グループ、及び、クラスのうちの一種或いは複数種を含み、前記ロールはグループ／クラスではなく、独立した個体であり、一つのロールは同時期に唯一のユーザーを関連付けることができ、一つのユーザーは一つ或いは複数のロールを関連付け、ユーザーはその関連付けられたロールの権限を取得する、請求項５に記載の方法。
【請求項8】
前記ユーザーが異動する時、ユーザーと元のロールの関連を取り消し、ユーザーを新しいロールに関連付ける、請求項７に記載の方法。
【請求項9】
管理ソフトウェアシステムが使用者に承認ノードの権限を与える方法であって、承認操作者が前記管理ソフトウェアシステムにおける一人の使用者を選定し、前記使用者が部門主管であること、
前記管理ソフトウェアシステムが、前記管理ソフトウェアシステムにおける全ての承認プロセスの全ての承認ノードを表示し、且つ選定された前記部門主管の各承認ノードに対する現在の承認権限状態を表示すること、及び、
前記管理ソフトウェアシステムが、選定された前記部門主管に承認ノードの承認権限を授与すること、を含み、
前記使用者はロールを含み、前記ロールはグループ／クラスではなく、独立した個体であり、一つのロールは同時期に唯一のユーザーを関連付けることができ、一つのユーザーは一つ或いは複数のロールを関連付け、ユーザーはその関連付けられたロールの権限を取得し、
前記管理ソフトウェアシステムが、前記使用者が承認権限を有する全ての承認ノードを表示し、これらの承認ノードに対する前記使用者の承認権限について、前記承認操作者による修正を受け付けて修正された承認権限を抹消し、且つ、前記使用者が承認権限を有しない一つ或いは複数の承認ノードについて、前記承認操作者による選定を受け付けて選定された承認ノードに対する前記使用者の承認権限を設定する、方法。
【請求項10】
前記管理ソフトウェアシステムが使用者に承認ノードの権限を与える方法は、選定した部門主管に承認ノードの所在する承認プロセスに対応するフォームのフォームフィールド／フィールド値の検分及び／又は修正の権限を授与することも含む、請求項９に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、使用者に承認プロセスとその承認ノードの権限を与える方法に関する。
【背景技術】
【0002】
ロールベースのアクセス制御（ＲＢＡＣ）は、近年最も多く研究されるし、最も成熟したデータベース権限管理メカニズムの１つであり、従来の強制アクセス制御（ＭＡＣ）および自律アクセス制御（ＤＡＣ）に代わる理想的な候補と考えられる。ロールベースのアクセス制御（ＲＢＡＣ）の基本的な考え方は、企業組織ビューのさまざまな機能的位置を分割して異なるロールを形成し、データベースリソースのアクセス権をロールにカプセル化するに従って、ユーザーは、異なるロールを割り当てられることにより、データベースリソースに間接的にアクセスする。
【0003】
大量のテーブルとビューが大規模なアプリケーションシステムに組み込まれているため、データベースリソースの管理と承認が非常に複雑になる。ユーザーがデータベースリソースのアクセスと権限承認を直接管理することは非常に困難である。ユーザーはデータベース構造を十分に理解し、ＳＱＬ言語を使用に精通している必要があり、アプリケーションシステム構造またはセキュリティ要件が変更されたら、大量の複雑かつ面倒な承認変更を実行するために、予期しない承認エラーに引き起こされるセキュリティ脆弱性が非常に発生しやすい。したがって、大規模なアプリケーションシステムのために簡単かつ効率的な権限の管理方法を設計することは、システムとシステムユーザーの共通の要件になっている。
【0004】
ロールベースの権限制御メカニズムにより、システムのアクセス権が簡単かつ効率的に管理できる。これにより、システム権限管理の負担とコストが大幅に削減され、さらに、システム権限管理は、アプリケーションシステムのビジネス管理仕様とより一致している。
【0005】
ただし、従来のロールベースのユーザー権限管理は、「ロール対ユーザー、１対多」の関連付けメカニズムを採用し、「ロール」はグループ／クラスの性質を有する。つまり、１つのロールは複数のユーザーが同時期に対応／関連付できる。ロールは、役職／職務／職種の概念に似ている。この関連付けメカニズムに基づくユーザー権限の承認は、基本的に次の３つの形式に分けられる。１、図１に示すように、ユーザーが直接承認されるが、不利な点は、ワークロードが大きく、操作が頻繁且つ面倒である。２、図２に示すように、ロール（クラス／グループ／役職／職種）は承認され（１つのロールを複数のユーザーに関連付けることができる）、ユーザーはロールを介して権限を取得する。３、図３に示すように、上記の２つの方法が組み合わされている。
【0006】
上記の説明では、２と３の両方にクラス／グループの性質を有するロールを承認する必要があり、クラス／グループ／役職／職種の性質を有するロールを介する承認及びワークフロー制御の方法には次の欠点がある。１、ユーザーのアクセス権限が変わる場合、操作が難しくなる。実際のシステム使用プロセスでは、多くの場合、運用プロセス中にユーザーの権限を調整する必要がある。例えば、従業員の権限の変更を処理する場合、ロールの関連付けた従業員の権限を変更するが、ロールは権限の変更されない他の従業員も関連付けたことで、個々の従業員の権限の変更により、ロール全体の権限を変更することができない。そのため、この状況に対応して、権限の変更した従業員に適うために新しいロールを作成するか、権限要件に基づいて従業員を直接承認（ロールからの離脱）する。上記の２つの処理方法は、ロールの権限が多数ある場合、ロールの承認に長い時間がかかるだけでなく、ミスを犯しやすく、ユーザーの操作がわずらわしく、面倒であり、システムユーザーの損失につながるエラーも発生しやすい。
【0007】
２、ロールの含む特定の権限を長期的に覚えることは困難である。ロールに複数の権限機能がある場合、時間が経つにつれて、ロールの特定の権限を覚えることは困難になり、権限の類似したロール間の権限差別を覚えるのがより難しくなる。新しいユーザーを関連付けると、どうやって関連付けるかを正確に判断することはできない。
【0008】
３、ユーザーの権限が変わるため、ロールをますます作成するのをもたらす（新しいロールを作成しない場合、ユーザーを直接承認するのが大幅に増加する）。各ロール間の特定の差別を区別することはより困難である。
【0009】
４、役職を調整するときに、異動するユーザーの多くの権限を他の複数のユーザーに割り当てる場合、異動するユーザーの権限を区分し、他の複数のユーザーを関連付けるためにそれぞれロールを作成する必要があるが、このような操作は、複雑であり、時間がかかるだけでなく、エラーがより発生しやすい。
【0010】
現有のＥＲＰ等の管理ソフトウェアシステムでは、システムの使用者を追加した後、追加した使用者に承認プロセスの使用権限（例えば、某フォームのフォームデータを提出して承認する時にどちらの承認プロセスを利用する）及び／或いは承認ノードの承認権限を授与する必要がある。承認プロセスの使用権限を授与する既有の方法は、先ず承認する必要がある承認プロセスを見つけて、次にその承認プロセスの使用者でその使用者を追加してその使用者にそのプロセスの使用権限を持たせる。追加した使用者が承認プロセスの複数の使用権限を有する可能性があるので、この時に、承認プロセスを一つずつ承認して使用権限を授与する方法を採用する場合と、承認作業量を巨大にさせ、承認の間違いをもたらしやすい。承認ノードの承認権限を授与する既有の方法は、承認する必要がある承認ノードの所属する承認プロセスを見つけて、次にその承認プロセス中から承認する必要がある承認ノードを見つけて追加した使用者を承認する必要がある承認ノードの各承認者にそれぞれ添える。承認過程は承認プロセスの権限授与よりも煩わしい。承認する必要がある承認プロセスが多くなる場合に、同様に承認作業量を巨大にさせ、承認の間違いをもたらしやすい。
【0011】
会社の運営過程では、各種の原因で某使用者の承認プロセスの使用権限及び／或いは承認ノードの承認権限をより大幅に調整する必要があり、作業量が巨大になる。又は、現有のＥＲＰ等のソフトウェアシステムでは承認プロセス、承認ノードの権限を授与する時に承認プロセスの使用権限を一つずつ授与し、且つ承認ノードの承認権限を一つずつ授与する必要があるので、その承認方法は、使用者がシステムにおける全ての承認プロセス或いは承認ノードに対する現在の権限状態を一度に表示することができず、使用者の権限を再授与するのに不利であり、承認の間違いをもたらしやすい。
【発明の概要】
【発明が解決しようとする課題】
【0012】
本発明の目的は、現行技術の欠陥を克服し、使用者に承認プロセスとその承認ノードの権限を与える方法を提供し、使用者を選定した後システムにおける全ての承認プロセス或いは承認ノードを表示し、承認プロセス或いは承認ノードを漏らすことができず、使用者のために相関権限を速く授与するのに都合がよい。
【課題を解決するための手段】
【0013】
本発明の目的は、以下の技術的手段により達成される。使用者に承認プロセスの権限を与える方法は、システムにおける一人の使用者を選定すること；システムにおける全ての承認プロセスを表示し、且つ選定した使用者の各承認プロセスに対する使用権限状態を表示すること；選定した使用者に承認プロセスの使用権限を授与することを含む。
【0014】
優先的に、二つ或いは二つ以上の承認プロセスが同じフォームに属する場合に、一人の使用者にその中の一つの承認プロセスの使用権限を授与することしかできない（つまり、一人の使用者は、同じフォームのうちの一つの承認プロセスの使用権限を授与されるしかない）。
【0015】
優先的に、前記使用者はロール、ユーザー、従業員、グループ、及び、クラスのうちの一種或いは複数種を含み、前記ロールはグループ／クラスではなく、独立した個体であり、一つのロールは同時期に唯一のユーザーを関連付けることができ、一つのユーザーは一つ或いは複数のロールを関連付ける。ユーザーはその関連付けられたロールの権限を取得する。
【0016】
優先的に、一人の使用者を選定した後、選定した使用者に各承認プロセスの使用権限を前回授与した操作者及び操作時間をそれぞれ表示する。
【0017】
使用者に承認ノードの権限を与える方法は、システムにおける一人の使用者を選定すること；システムにおける全ての承認プロセスの全ての承認ノードを表示し、且つ選定した使用者の各承認ノードに対する現在の承認権限状態を表示すること；選定した使用者に承認ノードの承認権限を授与することを含む。
【0018】
優先的に、使用者に承認ノードの権限を与える方法は、選定した使用者に承認ノードの所在する承認プロセスに対応するフォームのフォームフィールド／フィールド値の検分及び／又は修正の権限を授与することも含む。
【0019】
優先的に、前記使用者はロール、ユーザー、従業員、グループ、及び、クラスのうちの一種或いは複数種を含み、前記ロールはグループ／クラスではなく、独立した個体であり、一つのロールは同時期に唯一のユーザーを関連付けることができ、一つのユーザーは一つ或いは複数のロールを関連付ける。ユーザーはその関連付けられたロールの権限を取得する。
【0020】
優先的に、前記ユーザーが異動する時、ユーザーと元のロールの関連を取り消し、ユーザーを新しいロールに関連付ける。
【0021】
使用者に承認ノードの権限を与える方法は、システムにおける一人の使用者を選定し、前記使用者が部門主管であること；システムにおける全ての承認プロセスの全ての承認ノードを表示し、且つ選定した部門主管の各承認ノードに対する現在の承認権限状態を表示すること；選定した部門主管に承認ノードの承認権限を授与することを含む。
【0022】
優先的に、使用者に承認ノードの権限を与える方法は、選定した部門主管に承認ノードの所在する承認プロセスに対応するフォームのフォームフィールド／フィールド値の検分及び／又は修正の権限を授与することも含む。
【0023】
優先的に、前記使用者／部門主管はロール、ユーザー、従業員、グループ、及び、クラスのうちの一種或いは複数種を含み、前記ロールはグループ／クラスではなく、独立した個体であり、一つのロールは同時期に唯一のユーザーを関連付けることができ、一つのユーザーは一つ或いは複数のロールを関連付ける。ユーザーはその関連付けられたロールの権限を取得する。
【0024】
優先的に、前記部門主管のために対応の主管ロール／ユーザー／従業員を設定する。
【0025】
優先的に、システムにおけるその使用者の使用権限を有する全ての承認プロセス／承認権限を有する全ての承認ノードを表示し、これらの承認プロセス／承認ノードに対して使用権限／承認権限を修正し、且つ必要に応じてその使用者の使用権限を有しない一つ或いは複数の承認プロセス／承認権限を有しない一つ或いは複数の承認ノードを選定して使用権限／承認権限を設定する。
【0026】
優先的に、「システムにおける全ての承認プロセスの全ての承認ノードを表示する」は、「操作者のシステム中で検分できる全ての承認プロセスの全ての承認ノードを表示する」である。
【0027】
優先的に、「システムにおける全ての承認プロセスを表示する」は、「操作者のシステム中で検分できる全ての承認プロセスを表示する」である。
【0028】
優先的に、使用者の権限を有する承認プロセス及び／或いは承認ノードを区別して表示する。例えば、使用者の権限を有する承認プロセス及び／或いは承認ノードを前に表示し、又は使用者の権限を有する承認プロセス及び／或いは承認ノードを反転表示させ、又は使用者の権限を有する承認プロセス及び／或いは承認ノードを識別するための色／標識等と表示する。
【発明の効果】
【0029】
本発明の有益な効果は次のとおりである：（１）使用者を選定した後システムにおける全ての承認プロセス或いは承認ノードを表示し、承認プロセス或いは承認ノードを漏らすことができず、使用者のために相関権限を速く授与するのに都合がよい。
【0030】
（２）システムにおける全ての承認プロセス或いは承認ノードを表示する時に選定した使用者の各承認プロセスに対する現在の使用権限状態或いは選定した使用者の各承認ノードに対する現在の承認権限状態を表示し、承認操作者がここに基づいて修正を行うのに都合がよい。使用者に承認プロセス或いは承認ノードの権限を速く授与するのを達成し、承認効率を向上させ且つ承認の誤り率を低減する（選定した使用者の各承認プロセスに対する現在の使用権限状態或いは選定した使用者の各承認ノードに対する現在の承認権限状態をつかむのにも都合がよい。一度表示してそれを全体に了解することができ、一つずつ検分すればより煩わしく、且つ全体／全面性が欠乏する）。
【0031】
（３）一人の使用者を選定した後、選定した使用者に各承認プロセスの使用権限或いは各承認ノードの承認権限を前回授与した操作者及び操作時間をそれぞれ表示し、使用者の権限を間違う時に責任を探し出す、並びに使用者は承認する必要があるかどうかを判断するのに都合がよい。
【0032】
（４）部門主管に承認ノードの承認権限を授与することができる。部門主管が相関ロール、ユーザー或いは従業員に動的に対応するので、部門の主管ロール、主管ユーザー及び主管従業員が変わる時に部門主管も新しい主管ロール、主管ユーザー及び主管従業員に自動的に対応し、新しい主管ロール、主管ユーザー及び主管従業員に相関承認ノードの承認権限を再度授与する必要がなく、承認作業量を低減する。
【0033】
（５）従来の権利管理メカニズムでは、ロールをグループ、職種、クラスなどに定義し、ロールがユーザーとの１対多の関係にあり、実際にシステムを使用するプロセスでは、運用プロセス中にユーザーの権限を調整する必要がある。例えば、従業員の権限変更を処理する場合、ロールを関連付ける従業員の権限が変更され、このロールは権限の変更しない他の従業員を関連付けるので、個々の従業員の権限を変更したため、全体のロールの権限が変更できない。そのため、この状況に対応して、権限の変更された従業員に適うために新しいロールを作成するか、権限要件に基づいて従業員を直接承認（ロールからの離脱）する。上記の２つの処理方法は、ロールの権限が多数ある場合、ロールの承認に長い時間がかかるだけでなく、ミスを犯しやすく、ユーザーの操作がわずらわしく、面倒であり、システムユーザーの損失につながるエラーも発生しやすい。
【0034】
しかし、本発明の方法では、ロールが独立した個体であるため、ロール権限を変更して目標を達成することができる。本発明の方法は、システムの初期化時にワークロードを増加させるように見えるが、ロールの作成或いは権限授与の効率は、コピーなどの方法によってグループの性質を有する従来のロールより高くする。ユーザーを関連付ける時にグループの性質を有するロールの共通性を考慮しないため、この発明技術的手段は、承認設定を明確にする。特に、システムが一定期間使用された後（ユーザー／ロールの権限が動的に変化している）、この発明技術的手段は、システム使用時のシステム管理の効率を大幅に向上させ、動的承認をより簡単、便利、明確にし、権限設定の効率と信頼性を向上させる。
【0035】
（６）従来のグループ／クラスの性質を有するロールの承認方法はエラーが発生しやすく、本発明の方法では、従来の方法でこのグループの性質を有するロールを関連付ける複数のユーザーにどのような共通性があるかを考慮することなく、ロールを独立した個体として考慮するだけでよいため、本発明の方法は権限エラーの確率を大幅に低減させる。承認エラーが発生した場合でも、ロールを関連付けるその一つのユーザーのみに影響するが、従来のグループの性質を有するロールは前記ロールを関連付ける全部のユーザーに影響する。承認エラーが発生した場合でも、本発明の修正方法は簡単であり、時間が短く、従来のグループの性質を有するロールはエラーを修正する時に前記ロールを関連付ける全部のユーザーの共通性を考えなければならない。機能ポイントが多い場合、変更が面倒且つ複雑であるだけでなく、非常にエラーが発生しやすく、且つ多くの場合、新しいロールを作成するだけで解決できる。
【0036】
（７）従来のグループの性質を有するロールの承認方法では、ロールの権限機能ポイントが多くある場合、時間が長くなると、ロールの具体的な権限を覚えにくく、権限の近付くロールの間の区別を覚えるのはより困難である。新しいロールを関連付けると、どうやって選択して関連付けるべきであるかを確かに判断することができない。本発明の方法のロール自身は、役職番号／職務番号の性質を有しており、選択は明らかである。
【0037】
（８）異動するときに、異動されたユーザーの多くの権限を他のユーザーに割り当てる場合、処理する時に異動されたユーザーのこれらの権限を区別して、他のユーザーを関連付けるようにロールをそれぞれ作成する必要がある。このような操作は、複雑であり、時間がかかるだけでなく、エラーが発生しやすくなる。
【0038】
本発明の方法は次のとおりである：異動されたユーザーはいくつかのロールを関連付け、異動する場合、まずユーザーと元の部門のロールの関連を取り消し（取り消されたロールを外のユーザーに再度関連付けることもできる）、ユーザーは新しいロールを関連付けてもよい。操作は簡単であり、エラーが現れない。
【0039】
（９）ロールを作成する時或いは後、一つの部門を選定する必要として前記ロールが前記部門に属した後、部門が変更できず、ロールは部門が変更できないのはなぜであるか？理由１：本発明のロールの性質は役職番号／職務番号と同等であるため、様々な役職番号／職務番号の作業内容／権限は異なる。例えば、販売部門の販売員１のロールと技術部門の開発者１のロールは、２つの役職番号／職務番号がまったく異なり、権限が違う。理由２：販売員１のロールの部門（販売部門）が技術部門に置き換えられる場合、販売員１のロールを変更しないと、技術部門には販売部門の権限を有するロールがある。これは、管理の混乱とセキュリティの脆弱性につながる可能性がある。
【図面の簡単な説明】
【0040】
【図1】背景技術においてシステムがユーザーを直接承認する方法の概略図である。
【図2】背景技術においてシステムがグループ／クラスの性質を有するロールを承認する方法の概略図である。
【図3】背景技術においてシステムがユーザーを直接承認し、グループ／クラスの性質を有するロールを承認して組み合わせる方法の概略図である。
【図4】本発明において使用者に対して承認プロセスを承認する方法の一種のフローチャートである。
【図5】本発明において使用者に対して承認プロセスを承認する方法の一つの概略図である。
【図6】本発明のシステムにおいて独立した個体の性質を有するロールを介してユーザーを承認する方法の概略図である。
【図7】本発明において使用者に対して承認ノードを承認する方法の一種のフローチャートである。
【図8】本発明において使用者に対して承認ノードを承認する方法の一つの概略図である。
【図9】一つの承認プロセスの概略図である。
【図10】本発明において使用者に対して承認ノードを承認する方法のもう一種のフローチャートである。
【図11】本発明において使用者に対して承認ノードを承認する方法のもう一つの概略図である。
【発明を実施するための形態】
【0041】
本発明の技術的手段は、添付の図面を参照して以下でさらに詳細に説明されるが、本発明の保護範囲は以下に限定されない。
【実施例1】
【0042】
図４に示すように、使用者に承認プロセスの権限を与える方法は、以下のステップを含む。Ｓ１１、システムにおける一人の使用者を選定する。
【0043】
例えば、図５に示すように、ロール１を使用者として選定する。
【0044】
前記使用者はロール、ユーザー、従業員、グループ、及び、クラスのうちの一種或いは複数種を含む。
【0045】
図６に示すように、前記ロールはグループ／クラスではなく、独立した個体であり、一つのロールは同時期に唯一のユーザーを関連付けることができ、一つのユーザーは一つ或いは複数のロールを関連付ける。ユーザーはその関連付けられたロールの権限を取得する。ロールを作成した時或いは後に前記ロールに一つの部門を選定すると、前記ロールが前記部門に属し、ロールの作業内容によりロールを承認し、且つ前記ロールの名称が前記部門に唯一であり、前記ロールの番号がシステムに唯一である。
【0046】
ロールの定義：ロールは、グループ／クラス／カテゴリ／役職／職務／職種の性質を有しないが、非集合の性質を有する。ロールは唯一性を有し、独立して存在している個体である。ロールは企業や機関の応用で役職番号と同等である（ここで役職番号は役職ではなく、一つの役職に同時に複数の従業員がいるが、１つの役職番号は同時に一つの従業員にしか対応できない）。
【0047】
例えば、会社のシステムは次のロールを作成する可能性がある：総経理、副総経理１、副総経理２、北京販売部Ｉの経理、北京販売部ＩＩの経理、北京販売部ＩＩＩの経理、上海販売エンジニア１、上海販売エンジニア２、上海販売エンジニア３、上海販売エンジニア４、上海販売エンジニア５等。ユーザーとロールの関連関係：その会社の従業員である張三は、会社の副総経理２を務め、同時に北京販売部Ｉの経理を務める場合、張三は副総経理２及び北京販売部Ｉの経理というロールを関連付ける必要がある。張三は両方のロールに対する権限を持っている。
【0048】
従来のロールの概念は、グループ／クラス／役職／職務／職種の性質であり、１つのロールは複数のユーザーに対応できる。本発明の「ロール」の概念は、役職番号／職務番号と同等であり、映画やテレビドラマのロールに似ている。一つのロールは一つの俳優のみに同時に（幼年、少年、中年．．．）演じられ、一つの俳優は複数のロールを演じることができる。
【0049】
前記ユーザーが異動する時に、ユーザーと元のロールの関連を取り消して、ユーザーを新しいロールに関連付けると、ユーザーは元のロールの権限を自動的に失い、新しいロールの権限を自動的に取得する。
【0050】
従業員が入職する時、従業員に対応するユーザーにロールを関連付けた後、そのユーザーはその関連付けられたロールの権限を自動的に取得する。従業員が離職する時、従業員に対応するユーザーとそのユーザーの関連付けられたロールの関連関係を取り消した後、そのユーザーは元々関連付けられたロールの権限を自動的に失う。
【0051】
ロールを作成した後、ユーザーを作成するプロセスでロールを関連付けることができ、または、ユーザーを作成した後、いつでもロールを関連付けることができる。ユーザーは、ロールを関連付けた後ロールとの関係がいつでも解除でき、他のロールとの関係がいつでも確立できる。
【0052】
一つの従業員が一つのユーザーに対応し、一つのユーザーが一つの従業員に対応し、従業員がそれに対応するユーザーの関連付けるロールにより権限を決定（取得）する。
【0053】
更に、従業員がユーザーを一生結びつけ、ユーザーが従業員に対応した後、従って、そのユーザーがその従業員に属し、ユーザーが他のロールを関連付けることができない。その従業員が離職する場合、そのユーザーは他のロールにも対応することができない。従業員が再度入職した後、その従業員が依然として元のユーザーを使用する。
【0054】
Ｓ１２、システムにおける全ての承認プロセスを表示し、且つ選定した使用者の各承認プロセスに対する現在の使用権限状態を表示する。
【0055】
例えば、図５に示すように、ロール１を選定した後、システムにおける全ての承認プロセスを表示する。承認プロセスは契約フォームの承認プロセス１、契約フォームの承認プロセス２、契約フォームの承認プロセス３、顧客フォームの承認プロセス１等を含む。その中に、ロール１は契約フォームの承認プロセス１と顧客フォームの承認プロセス１に対して使用権限を現在持つ。
【0056】
Ｓ１３、選定した使用者に承認プロセスの使用権限を授与する。二つ或いは二つ以上の承認プロセスが同じフォームに属する場合に、（使用権限は、某フォームのフォームデータを提出して承認する時にどちらの承認プロセスを利用することである）一人の使用者にその中の一つの承認プロセスの使用権限を授与することしかできない（フォームは一種の業務対象と表す。例えば、注文や契約や顧客等。一つのフォームデータは唯一の業務対象に対応する。例えば、顧客フォーム中の００１顧客は唯一の顧客００１を表す。顧客００１はフォームデータ／対象である）。
【0057】
例えば、図５に示すように、契約フォームの承認プロセス１、契約フォームの承認プロセス２、契約フォームの承認プロセス３は契約フォームに属する。ロール１は、契約フォームの承認プロセス１の使用権限のみを現在持つ。
【0058】
一人の使用者を選定した後、選定した使用者に各承認プロセスの使用権限を前回授与した操作者及び操作時間をそれぞれ表示し、その使用者が承認プロセスの使用権限を授与する必要があるかどうかを判断するのに都合がよい。例えば、某承認操作者は１００個のロールに対して承認プロセスの使用権限を授与する必要があるが、即日、その承認操作者は７０個のロールに対して承認プロセスの使用権限を授与する操作を完成した。その承認操作者は翌日にロールに対して承認プロセスの使用権限を授与する操作を続ける時、ロールに承認プロセスの使用権限を前回授与した承認操作者或いはロールに承認プロセスの使用権限を前回授与した承認時間を選別することにより、承認プロセスの使用権限を授与する必要があるロールを見つけることができる。もう例えば、某ロールに承認プロセスの使用権限を前回授与した承認時間を選別することにより、前記ロールの各承認プロセスに対する使用権限が修正されていない期間を知ることができるのは、前記ロールに承認プロセスの使用権限を再授与する必要があるかどうかを判断するのに都合がよい。
【0059】
例えば、図５に示すように、ロール１に契約フォームの承認プロセス１、契約フォームの承認プロセス２、契約フォームの承認プロセス３、顧客フォームの承認プロセス１の使用権限を前回授与した承認操作者はユーザーＡであり、承認時間が２０１７年６月１日である。
【0060】
更に、システムにおけるその使用者の使用権限を有する全ての承認プロセスを表示し、これらの承認プロセスに対して使用権限を修正し、且つ必要に応じてその使用者の使用権限を有しない一つ或いは複数の承認プロセスを選定して使用権限を設定する。
【0061】
更に、「システムにおける全ての承認プロセスを表示する」は、「操作者のシステム中で検分できる全ての承認プロセスを表示する」である。
【0062】
更に、使用者の権限を有する承認プロセスを区別して表示する。例えば、使用者の権限を有する承認プロセスを前に表示し、又は使用者の権限を有する承認プロセスを反転表示させ、又は使用者の権限を有する承認プロセスを識別するための色／標識等と表示する。
【実施例2】
【0063】
図７に示すように、使用者に承認ノードの権限を与える方法は、以下のステップを含む。Ｓ２１、システムにおける一人の使用者を選定する。
【0064】
例えば、図８に示すように、ロール１を使用者として選定する。
【0065】
前記使用者はロール、ユーザー、従業員、グループ、及び、クラスのうちの一種或いは複数種を含む。
【0066】
図６に示すように、前記ロールはグループ／クラスではなく、独立した個体であり、一つのロールは同時期に唯一のユーザーを関連付けることができ、一つのユーザーは一つ或いは複数のロールを関連付ける。ユーザーはその関連付けられたロールの権限を取得する。ロールを作成した時或いは後に前記ロールに一つの部門を選定すると、前記ロールが前記部門に属し、ロールの作業内容によりロールを承認し、且つ前記ロールの名称が前記部門に唯一であり、前記ロールの番号がシステムに唯一である。
【0067】
前記ユーザーが異動する時に、ユーザーと元のロールの関連を取り消して、ユーザーを新しいロールに関連付けると、ユーザーは元のロールの権限を自動的に失い、新しいロールの権限を自動的に取得する。
【0068】
従業員が入職する時、従業員に対応するユーザーにロールを関連付けた後、そのユーザーはその関連付けられたロールの権限を自動的に取得する。従業員が離職する時、従業員に対応するユーザーとそのユーザーの関連付けられたロールの関連関係を取り消した後、そのユーザーは元々関連付けられたロールの権限を自動的に失う。
【0069】
ロールを作成した後、ユーザーを作成するプロセスでロールを関連付けることができ、または、ユーザーを作成した後、いつでもロールを関連付けることができる。ユーザーは、ロールを関連付けた後ロールとの関係がいつでも解除でき、他のロールとの関係がいつでも確立できる。
【0070】
一つの従業員が一つのユーザーに対応し、一つのユーザーが一つの従業員に対応し、従業員がそれに対応するユーザーの関連付けるロールにより権限を決定（取得）する。
【0071】
更に、従業員がユーザーを一生結びつけ、ユーザーが従業員に対応した後、従って、そのユーザーがその従業員に属し、ユーザーが他のロールを関連付けることができない。その従業員が離職する場合、そのユーザーは他のロールにも対応することができない。従業員が再度入職した後、その従業員が依然として元のユーザーを使用する。
【0072】
Ｓ２２、システムにおける全ての承認プロセスの全ての承認ノードを表示し、且つ選定した使用者の各承認ノードに対する現在の承認権限状態を表示する。
【0073】
例えば、図８に示すように、ロール１を選定した後、システムにおける全ての承認プロセスの全ての承認ノードを表示する。全ての承認ノードは契約フォームの承認プロセス１の承認ノード１と承認ノード２、契約フォームの承認プロセス２の承認ノード１、承認ノード２、承認ノード３、契約フォームの承認プロセス３の承認ノード１、顧客フォームの承認ノード１、承認ノード２等を含む。その中に、ロール１は契約フォームの承認プロセス１の承認ノード１と承認ノード２及び顧客フォームの承認プロセス１の承認ノード１に対して承認権限を現在持つ。
【0074】
前記承認プロセスは、開始ノード、承認ノード、完了ノードを含む。一つの承認プロセスには承認ノードの数目は一つであり、又は複数であることができる。承認ノードの承認者は承認任務を承認する。
【0075】
図９は、販売契約を署名した前の承認プロセスである。そのプロセスは開始ノード、承認ノード、完了ノードを含む。前記開始ノードは発起者を含み、販売契約の承認プロセスを発起／申請／提出するのに用いる。前記承認ノード（図９に示すように、承認ノードは五つある）販売主管Ａ、財務主管Ｂ、技術主管Ｃ、生産主管Ｄ、経理Ｅを含み、販売主管Ａは販売契約の全ての情報承認を担当し、財務主管Ｂは販売契約の財務承認を担当し、技術主管Ｃは販売契約の技術承認を担当し、生産主管Ｄは販売契約の生産承認を担当し、経理Ｅは販売契約の顧客情報を除く全ての情報承認を担当する。
【0076】
Ｓ２３、選定した使用者に承認ノードの承認権限を授与する。つまり、使用者を相応の承認ノードの承認者と選定／設定する。
【0077】
使用者に承認ノードの権限を与える方法は、選定した使用者に承認ノードの所在する承認プロセスに対応するフォームのフォームフィールド／フィールド値の検分及び／又は修正の権限を授与することも含む（つまり、その承認者／選定した使用者にその承認ノードに承認する権限を授与する時に、そのフォームのどちらのフィールド／フィールド値を検分及び／又は修正することができる）。使用者を一つの承認ノードの承認者と設定した後、その承認者はその承認ノードにある「フォームフィールド／フィールド値の承認」により相応の操作を行う。
【0078】
一人の使用者を選定した後、選定した使用者に各承認プロセスの承認ノードの承認権限を前回授与した操作者及び操作時間をそれぞれ表示する。
【0079】
例えば、図８に示すように、ロール１に契約フォームの承認プロセス１の承認ノード１と承認ノード２及び顧客フォームの承認プロセス１の承認ノード１の承認権限を前回授与した承認操作者はユーザーＡであり、承認時間が２０１７年６月１日である。
【0080】
更に、システムにおけるその使用者の承認権限を有する全ての承認ノードを表示し、これらの承認ノードに対して承認権限を修正し、且つ必要に応じてその使用者の承認権限を有しない一つ或いは複数の承認ノードを選定して使用権限を設定する。
【0081】
更に、「システムにおける全ての承認プロセスの全ての承認ノードを表示する」は、「操作者のシステム中で検分できる全ての承認プロセスの全ての承認ノードを表示する」である。
【0082】
更に、使用者の権限を有する承認プロセス及び／或いは承認ノードを区別して表示する。例えば、使用者の権限を有する承認プロセス及び／或いは承認ノードを前に表示し、又は使用者の権限を有する承認プロセス及び／或いは承認ノードを反転表示させ、又は使用者の権限を有する承認プロセス及び／或いは承認ノードを識別するための色／標識等と表示する。
【実施例3】
【0083】
図１０に示すように、使用者に承認ノードの権限を与える方法は、以下のステップを含む。Ｓ３１、システムにおける一人の使用者を選定し、前記使用者が部門主管である。
【0084】
例えば、図１１に示すように、販売部門主管を使用者として設定する。
【0085】
前記部門主管は部門の現在の主管従業員／主管ユーザー／主管ロールである（又は、その主管ロールの関連付けたユーザー、或いはその主管ロールの関連付けたユーザーに対応する従業員）。前記主管従業員／主管ユーザー／主管ロールの設置方法は、一つの従業員／ユーザーを選定して一つ或いは複数の部門の主管従業員／主管ユーザーとし、部門に属しないロールを選定して一つの部門の主管ロールとし、又は部門に既に属したロールを選定して前記ロールの所属する部門の主管ロールとすることである。部門の主管従業員／主管ユーザー／主管ロールが変わる時に、前記部門主管は新しい従業員／主管ユーザー／主管ロールである（即ち、現在の主管）。
【0086】
例えば、販売部門の主管ロールは販売員１であり、この時、販売部門の部門主管は販売員１である。販売員２は販売部門の主管ロールに代わると、この時、販売部門の部門主管は販売員２である。
【0087】
Ｓ３２、システムにおける全ての承認プロセスの全ての承認ノードを表示し、且つ選定した部門主管の各承認ノードに対する現在の承認権限状態を表示する。
【0088】
前記承認プロセスは、開始ノード、承認ノード、完了ノードを含む。一つの承認プロセスには承認ノードの数目は一つであり、又は複数であることができる。
【0089】
例えば、図１１に示すように、販売部門主管を選定した後、システムにおける全ての承認プロセスの全ての承認ノードを表示する。全ての承認ノードは契約フォームの承認プロセス１の承認ノード１と承認ノード２、契約フォームの承認プロセス２の承認ノード１、承認ノード２、承認ノード３、契約フォームの承認プロセス３の承認ノード１、顧客フォームの承認ノード１、承認ノード２等を含む。その中に、販売部門主管は契約フォームの承認プロセス１の承認ノード１と承認ノード２及び顧客フォームの承認プロセス１の承認ノード１に対して承認権限を現在持つ。
【0090】
Ｓ３３、選定した部門主管に承認ノードの承認権限を授与する。
【0091】
使用者に承認ノードの権限を与える方法は、選定した部門主管に承認ノードの所在する承認プロセスに対応するフォームのフォームフィールド／フィールド値の検分及び／又は修正の権限を授与することも含む。部門主管を一つの承認ノードの承認者と設定した後、その承認者はその承認ノードにある「フォームフィールド／フィールド値の承認」により相応の操作を行う。
【0092】
一つの部門主管を選定した後、選定した部門主管に各承認プロセスの承認ノードの承認権限を前回授与した操作者及び操作時間をそれぞれ表示する。
【0093】
例えば、図１１に示すように、部門主管に契約フォームの承認プロセス１の承認ノード１と承認ノード２及び顧客フォームの承認プロセス１の承認ノード１の承認権限を前回授与した承認操作者はユーザーＡであり、承認時間が２０１７年６月１日である。
【0094】
上記は本発明の優先的な実施形態だけである。本発明は、本明細書に開示された形態に限定されないと理解され、他の実施形態を除くとみなされず、却って様々な他の組み合わせや修正や環境に利用でき、本明細書のコンセプトの範囲内で、上記の教示または関連分野の技術または知識により修正を行うことができる。当業者に行われる修正及び変更は、本発明の趣旨及び範囲から逸脱するものではなく、全部と本発明に添付される請求項の範囲内にあるべきである。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
