IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 成都牽牛草信息技術有限公司の特許一覧

特許7540660フォームフィールド値の操作権限承認方法
<>
  • 特許-フォームフィールド値の操作権限承認方法 図1
  • 特許-フォームフィールド値の操作権限承認方法 図2
  • 特許-フォームフィールド値の操作権限承認方法 図3
  • 特許-フォームフィールド値の操作権限承認方法 図4
  • 特許-フォームフィールド値の操作権限承認方法 図5
  • 特許-フォームフィールド値の操作権限承認方法 図6
  • 特許-フォームフィールド値の操作権限承認方法 図7
  • 特許-フォームフィールド値の操作権限承認方法 図8
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-08-19
(45)【発行日】2024-08-27
(54)【発明の名称】フォームフィールド値の操作権限承認方法
(51)【国際特許分類】
   G06Q 10/00 20230101AFI20240820BHJP
【FI】
G06Q10/00
【請求項の数】 7
(21)【出願番号】P 2019571525
(86)(22)【出願日】2018-06-28
(65)【公表番号】
(43)【公表日】2020-09-17
(86)【国際出願番号】 CN2018093432
(87)【国際公開番号】W WO2019007260
(87)【国際公開日】2019-01-10
【審査請求日】2021-02-05
【審判番号】
【審判請求日】2023-06-14
(31)【優先権主張番号】201710543859.0
(32)【優先日】2017-07-05
(33)【優先権主張国・地域又は機関】CN
(73)【特許権者】
【識別番号】519375273
【氏名又は名称】成都牽牛草信息技術有限公司
【氏名又は名称原語表記】CHENGDU QIANNIUCAO INFORMATION TECHNOLOGY CO., LTD.
【住所又は居所原語表記】No.1609, 16th Floor, Hemei Haitang Center (Tianfu Chuangke) No.2039, South Section of Tianfu Avenue, Tianfu New Area, China (Sichuan) Pilot Free Trade Zone Chengdu, Sichuan 610000, China
(74)【代理人】
【識別番号】100091683
【弁理士】
【氏名又は名称】▲吉▼川 俊雄
(72)【発明者】
【氏名】陳達志
【合議体】
【審判長】伏本 正典
【審判官】佐藤 智康
【審判官】松田 直也
(56)【参考文献】
【文献】特開2008-299702(JP,A)
【文献】特開2013-007708(JP,A)
【文献】特開2013-065297(JP,A)
【文献】特開2005-038145(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00-99/00
(57)【特許請求の範囲】
【請求項1】
ソフトウェアシステムにおけるフォームフィールド値の操作権限承認方法であって、
一つのフォームフィールド値の操作権限承認ステップと一つの被承認者の選択ステップを含み、フォームフィールド値の操作権限承認ステップと被承認者の選択ステップには前後順序がなく、
前記フォームフィールド値の操作権限承認ステップは、
S1:操作者が、承認しようとしているフォームを選択すると、前記ソフトウェアシステムは、前記フォーム中に操作権限制御を必要とするフィールドを表示すること、
S2:前記操作者が、フィールド毎にフィールド値の操作権限をそれぞれ承認することを含み、
前記被承認者が1つまたは複数のロールであり、前記ロールがグループ/クラスではなく、独立しており、一つのロールは同時期に唯一のユーザーを関連付けることができ、一つのユーザーは1つまたは複数のロールを関連付けるフォームフィールド値の操作権限承認方法であって、
前記操作権限は、検分と修正の中の一種または二種を含む、フォームフィールド値の操作権限承認方法であって、
前記ロールは部門に属し、そのロールはその部門内で唯一である、フォームフィールド値の操作権限承認方法。
【請求項2】
表示権限を有しないフィールド値に対しては、その表示方式が、
(1)前記フィールド値に対応するフィールドを表示するが、隠し符号でフィールド値を隠すこと、
(2)そのフィールド値及びそのフィールド値に対応するフィールドを全て表示しないことを含む請求項1に記載のフォームフィールド値の操作権限承認方法。
【請求項3】
被承認者が選択されており、且つ一つだけであり、操作者が、承認しようとしているフォームを選択する時、前記ソフトウェアシステムは、被承認者に対してそのフォームフィールド値を最近承認した操作者と操作時間を表示する請求項1に記載のフォームフィールド値の操作権限承認方法。
【請求項4】
ロール名称は部門内で唯一であり、ロール番号はシステム内で唯一である請求項1に記載のフォームフィールド値の操作権限承認方法。
【請求項5】
ユーザーは部門間で異動する時、前記操作者が、ユーザーと元の部門内のロールの関連を取り消して、ユーザーを新しい部門のロールに関連付ける請求項1又は4に記載のフォームフィールド値の操作権限承認方法。
【請求項6】
更にテンプレート承認ステップも含み、具体的に、前記操作者が、
(1)被承認者と承認フォームを選択し、1つまたは複数のロールを選択して被承認者とすること、
(2)被承認者に対し1つまたは複数のロールの承認を行い、一つの既存のロールまたは作成されたテンプレートを選択して承認テンプレートとし、その承認テンプレートのフォームフィールド値の操作権限をその被承認者に与えること、
(3)修正した後または修正しなかった後、その結果を保存して被承認者のフォームフィールド値の操作権限を取得することを含む請求項1に記載のフォームフィールド値の操作権限承認方法。
【請求項7】
ソフトウェアシステムにおけるフォームフィールド値の操作権限承認方法であって、
一つのフォームフィールド値の操作権限承認ステップと一つの被承認者の選択ステップを含み、フォームフィールド値の操作権限承認ステップと被承認者の選択ステップには前後順序がなく、
前記フォームフィールド値の操作権限承認ステップは、
S1:操作者が、承認しようとしているフォームを選択すること、
S2:前記操作者が、承認しようとしている操作権限を選択すること、
S3:前記操作者が、選択された操作権限を有するフォーム中にフィールドを設定すると、前記ソフトウェアシステムは、設定されたフィールドに選択された操作権限を備えるように処理することを含み、
前記被承認者が1つまたは複数のロールであり、前記ロールがグループ/クラスではなく、独立しており、一つのロールは同時期に唯一のユーザーを関連付けることができ、一つのユーザーは1つまたは複数のロールを関連付けるフォームフィールド値の操作権限承認方法であって、
前記操作権限は、検分と修正の中の一種または二種を含む、フォームフィールド値の操作権限承認方法であって、
前記ロールは部門に属し、そのロールはその部門内で唯一である、フォームフィールド値の操作権限承認方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ERPなどの管理ソフトウェアフォームを承認する方法に関し、特に、フォームフィールド値の操作権限承認方法に関する。
【背景技術】
【0002】
従来のソフトウェアシステムでは、フォームフィールド値に基づいてフォーム検分権限をそれぞれ承認することを実現できる。例えば、選択されたフォームタイプは「注文」であり、フォーム中に承認制御を必要とするフィールドは「注文番号」、「顧客名」、「顧客住所」、「電話」、「連絡先」、「顧客の所属する産業」、「製品モデル」、「製品数量」、「製品単価」等である。システムユーザーは注文フォーム中にさまざまな注文情報を検分する権限をそれぞれ制御することができる。例えば、注文フォーム中の顧客名を検分するのを許し、注文フォーム中の電話を検分するのを許さない。ただし、従来のソフトウェアシステムにある欠点は次のとおりである。(1)フォームフィールド値の承認を行う時に、最近承認された操作者と操作時間が表示できず、フォームの権限承認にエラーが発生する時、説明責任が果たされず、目下の承認操作者に承認時間の参照を提供することもできず、使用はあまり便利ではない。(2)複数のロールに対してフォームフィールド値の操作権限を一括して承認することができず、テンプレート承認機能も支えられず、承認するたびにフィールドを一つずつ設定する必要があり、承認の効率は低い。大規模なソフトウェアシステム中にフォームフィールドは非常に多く、従来の承認方法には大きな作業負荷がある。
【0003】
その上、ロールベースのアクセス制御(RBAC)は、近年最も多く研究されており、最も成熟したデータベース権限管理メカニズムの1つであり、従来の強制アクセス制御(MAC)および自律アクセス制御(DAC)に代わる理想的な候補と考えられる。従来の自律型アクセス制御は高い融通性を備えるが、セキュリティは低い。強制アクセス制御は高いセキュリティを備えるが、制限が強すぎる。ロールベースのアクセス制御は、両方の長所を兼ね備え,管理が簡単であるだけでなく、複雑さ、コスト、エラーの可能性を減らすこともできるため、近年大幅に成長している。ロールベースのアクセス制御(RBAC)の基本的な考え方は、企業組織ビューのさまざまな機能的位置を分割して異なるロールを形成し、データベースリソースのアクセス権をロールにカプセル化するに従って、ユーザーは、異なるロールを割り当てられることにより、データベースリソースに間接的にアクセスする。
【0004】
大量のテーブルとビューが大規模なアプリケーションシステムに組み込まれているため、データベースリソースの管理と承認が非常に複雑になる。ユーザーがデータベースリソースのアクセスと権限承認を直接管理することは非常に困難である。ユーザーはデータベース構造を十分に理解し、SQL言語の使用に精通している必要があり、アプリケーションシステム構造またはセキュリティ要件が変更されたら、大量の複雑かつ面倒な承認変更を実行するために、予期しない承認エラーによって引き起こされるセキュリティ脆弱性が非常に発生しやすい。したがって、大規模なアプリケーションシステムのために簡単かつ効率的な権限の管理方法を設計することは、システムとシステムユーザーの共通の要件になっている。
【0005】
ロールベースの権限制御メカニズムにより、システムのアクセス権を簡単かつ効率的に管理できる。これにより、システム権限管理の負担とコストが大幅に削減され、さらに、システム権限管理は、アプリケーションシステムのビジネス管理仕様とより一致している。
【0006】
ただし、従来のロールベースのユーザー権限管理は、「ロール対ユーザー、1対多」の関連付けメカニズムを採用し、「ロール」はグループ/クラスの性質を有する。つまり、1つのロールは複数のユーザーが同時期に対応する/関連付けることができる。ロールは、役職/職務/職種の概念に似ている。この関連付けメカニズムに基づくユーザー権限の承認は、基本的に次の3つの形式に分けられる。1、図1に示すように、ユーザーが直接承認されるが、不利な点は、ワークロードが大きく、操作が頻繁且つ面倒であることである。従業員の変更(異動、辞任など)が発生した場合、従業員に関わるすべてのプロセスを適宜調整する必要がある。特に会社の経営陣にとっては、相関の承認プロセスの数が多く、プロセス調整の作業負荷が大きく複雑であり、ミスや脱落を起こしやすく、会社の正常な運転に影響を及ぼし、予測不可能な損失さえ引き起こす。
【0007】
2、図2に示すように、ロール(クラス/グループ/役職/職種)は承認され(1つのロールを複数のユーザーに関連付けることができる)、ユーザーはロールを介して権限を取得し、承認操作の主体がグループ/クラスという性質を有するロールである。3、図3に示すように、上記の2つの方法が組み合わされている。
【0008】
上記の説明では、2と3の両方にクラス/グループの性質を有するロールを承認する必要があり、クラス/グループ/役職/職種を有するロールを介する承認及びワークフロー制御の方法には次の欠点がある。1、ユーザーのアクセス権限を変更する場合、難しく操作する。実際のシステム使用プロセスでは、多くの場合、運用プロセス中にユーザーの権限を調整する必要がある。たとえば、従業員の権限の変更を処理する場合、ロールを関連付けられる従業員の権限を変更するが、ロールは権限の変更されない他の従業員にも関連付けられることで、個々の従業員の権限の変更により、ロール全体の権限を変更することができない。そのため、この状況に対応して、権限の変更された従業員に適うために新しいロールを設立するか、権限要件に基づいて従業員を直接承認(ロールからの離脱)する。上記の2つの処理方法は、ロールの権限が多数ある場合、ロールの承認に長い時間がかかるだけでなく、ミスを犯しやすく、ユーザーの操作がわずらわしく、面倒であり、システムユーザーの損失につながるエラーも発生しやすい。
【0009】
従業員/ユーザーの承認権限を変更する場合、従業員/ユーザーをロールから離脱するか、承認プロセスの要件を満たすために新しいロールを追加する。1番目の方式は、欠陥が上記の「ユーザーを直接承認する」方法と同じである。2番目の方式は、新しいロールがロールの設立や関連付けや承認に関わる。特に、多数のロールと、ロールを関連付けられた多数のユーザーの場合、どのユーザーがロールを具体的に関連付けられているかを覚えるのは困難である。
【0010】
2、ロールに含まれる特定の権限を長期的に覚えていることは困難である。ロールに複数の権限機能がある場合、時間が経つにつれて、ロールの特定の権限を覚えていることは困難になり、権限の類似したロール間の権限差別を覚えているのがより難しくなり、ロールの類似した権限も混同し易い。新しいユーザーを関連付けると、どうやって関連付けるか正確に判断することはできない。
【0011】
3、ユーザーの権限が変更されるため、ロールをますます設立することをもたらす(新しいロールを設立しない場合、ユーザーの直接承認が大幅に増加する)。各ロール間の特定の差別を区別することはより困難である。
【0012】
4、役職を調整するときに、異動するユーザーの多くの権限を他の複数のユーザーに割り当てる場合、異動するユーザーの権限を区分し、他の複数のユーザーを関連付けるためにそれぞれロールを設立する必要があるが、このような操作は、複雑であり、時間がかかるだけでなく、エラーをより発生しやすくする。
【発明の概要】
【発明が解決しようとする課題】
【0013】
本発明の目的は、現行技術の欠陥を克服し、フォームフィールド値の操作権限承認方法を提供し、フォームフィールド値の操作権限をそれぞれ承認することを達成し、システム管理の精度を向上させる。一つのロールは同時期に唯一のユーザーを関連付けることができ、これにより、システムを使用する時に権限管理の効率が大幅に向上し、動的承認がより簡単、便利、明確になり、権限承認の効率と信頼性を向上させる。
【課題を解決するための手段】
【0014】
本発明の目的は、以下の技術的手段により達成される。フォームフィールド値の操作権限承認方法は、一つのフォームフィールド値の操作権限承認ステップと一つの被承認者の選択ステップを含み、フォームフィールド値の操作権限承認ステップと被承認者の選択ステップには前後順序がなく、前記フォームフィールド値の操作権限承認ステップは、S1:承認しようとしているフォームを選択し、前記フォーム中に操作権限制御を必要とするフィールドを表示すること、S2:フィールド毎にフィールド値の操作権限をそれぞれ承認することを含み、前記被承認者が1つまたは複数のロールであり、前記ロールがグループ/クラスではなく、独立した個体であり、一つのロールは同時間に唯一のユーザーを関連付けることができ、一つのユーザーは1つまたは複数のロールを関連付ける。
【0015】
前記操作権限は、検分と修正の中の一種または二種を含む。
【0016】
表示権限を有しないフィールド値に対しては、その表示方式が、(1)前記フィールド値に対応するフィールドを表示するが、隠し符号でフィールド値を隠すこと、(2)そのフィールド値及びそのフィールド値に対応するフィールドを全て表示しないことを含む。
【0017】
被承認者が選択されてあり、且つ一つだけであり、承認しようとしているフォームを選択する時、被承認者に対してそのフォームフィールド値を最近承認する操作者と操作時間を表示する。
【0018】
前記ロールは部門に属し、そのロールはその部門内で唯一であり、ロールの作業内容によりロールを承認し、ユーザーはロールを関連付けることにより権限を取得する。
【0019】
前記ロール名称は部門内で唯一であり、ロール番号はシステム内で唯一である。
【0020】
ユーザーは部門間で異動する時、ユーザーと元の部門内のロールの関連を取り消して、ユーザーを新しい部門のロールに関連付ける。
【0021】
フォームフィールド値の操作権限承認方法は、更にテンプレート承認ステップも含み、具体的に、(1)被承認者と承認フォームを選択し、1つまたは複数のロールを選択して被承認者とすること、(2)被承認者に対し承認を行い、一つの既存のロールまたは作成されたテンプレートを選択して承認テンプレートとし、その承認テンプレートのフォームフィールド値の操作権限をその被承認者に与えること、(3)修正後または修正しない後、保存して被承認者のフォームフィールド値の操作権限を取得することを含む。
【0022】
フォームフィールド値の操作権限承認方法は、一つのフォームフィールド値の操作権限承認ステップと一つの被承認者の選択ステップを含み、フォームフィールド値の操作権限承認ステップと被承認者の選択ステップには前後順序がなく、前記フォームフィールド値の操作権限承認ステップは、S1:承認しようとしているフォームを選択すること、S2:承認しようとしている操作権限を選択すること、S3:選択された操作権限を有するフォーム中にフィールドを設定すると、設定されたフィールドは選択された操作権限を備えること(つまり、そのフィールドのフィールド値の相応の操作権限を備える)を含み、前記被承認者が1つまたは複数のロールであり、前記ロールがグループ/クラスではなく、独立した個体であり、一つのロールは同時間に唯一のユーザーを関連付けることができ、一つのユーザーは1つまたは複数のロールを関連付ける。
【発明の効果】
【0023】
本発明の有益な効果は次のとおりである。1)本発明は、フォームフィールド値の操作権限をそれぞれ承認することを達成し、システム管理の精度を向上させる。操作権限は検分と修正を含み、特にフォームに各フィールドのフィールド値がそれぞれ承認する必要がある状況に適用する。例えば、注文フォームでは、システムロールが「注文番号」、「顧客名」、「顧客住所」、顧客の所属する産業」、「製品モデル」、「製品数量」、「製品単価」を検分するのを許すが、「電話」と「連絡先」の様な機密フィールドの内容(フィールド値)を検分するのを許さない。本方法では、それぞれ承認することが迅速に達成できる。別の例として、システムロールが「製品単価」フィールドの内容を検分することを許すが、「製品単価」フィールドの内容を修正することを許さない。本方法も、権限を設定することが迅速に達成できる。
【0024】
2)被承認者が選択されており、且つ1つだけであり、承認しようとしているフォームを選定する時、被承認者に対してそのフォームフィールド値を最近承認する操作者と操作時間を表示する。最近の操作者を表示することは、フォームフィールド値の権限を承認してエラーが発生する時責任を追究するのに都合がよい。最近の操作時間を表示することは、フォームフィールド値を再承認する必要があるかどうかを直感的に判断するのに都合がよい。
【0025】
例えば、張三という被承認者の契約フォームフィールド値の操作権限を前回承認した操作は、2015年5月21日11:00に李四によって完成されたとする。被承認者を張三と選択し且つ承認フォームを契約と選択する時、今回の承認操作者のために、2015年5月21日11:00に李四が張三のために契約フォームを前回承認したことを表示する。
【0026】
張三は機密フィールドの内容を検分する権限を備えるべきではないとしたときに、然も張三に対して前回承認する時に張三にその機密フィールドの内容を検分する権限を備えさせたとする。続いて責任を追究する過程において、前回承認した操作者を検索することにより責任者を見つけることができる。
【0027】
別の例として、操作者は100人の被承認者に対して契約フォームフィールド値を承認する必要があるが、即日、その操作者は70人の被承認者に対する承認のみを完成した。その操作者は翌日に承認を続ける時、各被承認者の前回承認された時間を検分することにより、その被承認者を承認する必要があるかどうかを判断することができる。また、承認時間間隔により、指定された時間間隔に承認されたすべての被承認者を捜し出すこともできる。被承認者の前回承認された時間を検分することにより、被承認者の権限が修正されていない期間を知ることができるのは、其れを再承認する必要があるかどうかを直感的に判断するのに都合がよい。
【0028】
3)本方法では、複数の承認されたロールを同時に選択して一括して承認することができ、承認の効率を向上させる。その上、本方法はテンプレート承認を支える。即ち、一つの既存のロールまたは作成されたテンプレートを選択して承認テンプレートとし、その承認テンプレートのフォームフィールド値の操作権限をその被承認者(再度簡単に修正された後保存された)に直接的に与える(更新)。承認操作は簡単かつ高能率になる。2つの方法を組み合わせることにより、システムのフォームフィールド値の操作権限の承認効率を大幅に向上させる。
【0029】
4)本発明は、ロールがユーザーとの1対1の関係にあり、一つのロールが唯一のユーザーを同時期に関連付けることができる。この利点は、ユーザーをロールに関連付けて権限を取得し(つまり、ユーザーは、関連付けられたロールの権限を取得る)、しかもロールの権限の変更は、従来のメカニズムにあるロールの権限の変更よりもはるかに小さくなる。独立した個体の性質(役職番号/職務番号の性質)を有するロールの数は少ない。従業員の異動は大きいが、役職番号/職務番号の変化は小さい(一定期間に変化さえない、つまりロールは変わらない)。これにより、ユーザーの権限管理を大幅に簡易化し、システムの掛かりを削減する。
【0030】
5)動的な管理、入職や異動等の操作が簡単かつ便利となり、効率と信頼性が高くなる。入職/離職/異動の適用は承認プロセスで簡単である。従業員/ユーザーを変更する場合、承認プロセスを再設定する必要はない。ユーザーはロールを取り消し、ロールを関連付けてもよい。そのロールを担わないユーザーは、ロールの関連付けを取り消し、そのロールを引き継ぐユーザーは、その役職番号のロールを関連付ける。ロールを関連付けたユーザーは、そのロールに関連するタスクと操作権限を自動的に取得し、ロールを再承認する必要はない。これにより、プロセス設定の効率やセキュリティや信頼性が大幅に向上する。
【0031】
たとえば、張三というユーザーが辞任または異動するといった原因で、張三は「バイヤー3」というロールとして働かなくなったとき、張三のロールとの関連付けを取り消す。他方、李四は、「バイヤー3」というロールとする仕事を引き継ぎ、李四にこのロールを関連付けると、李四は承認プロセス中の「バイヤー3」というロールの承認タスクと承認権限を自動的に取得する。
【0032】
6)従来の権利管理メカニズムでは、ロールをグループ、職種、クラスなどと定義し、ロールがユーザーと1対多の関係にある。実際にシステムを使用するプロセスでは、運用プロセス中にユーザーの権限を調整する必要がある。たとえば、従業員の権限変更を処理する場合、ロールを関連付ける従業員の権限が変更される。このロールは権限の変更をしない他の従業員も関連付けるので、個々の従業員の権限を変更するために、全体のロールの権限を変更することはできない。そのため、この状況に対応して、権限の変更された従業員に適うために新しいロールを設立するか、権限要件に基づいて従業員を直接承認(ロールからの離脱)する。上記の2つの処理方法は、ロールの権限が多数ある場合、ロールの承認に長い時間がかかるだけでなく、ミスを犯しやすく、ユーザーの操作がわずらわしく、面倒であり、システムユーザーの損失につながるエラーも発生しやすい。
【0033】
しかし、本発明の方法では、ロールが独立した個体であるため、ロール権限を変更して目標を達成することができる。本発明の方法は、システムの初期化時にワークロードを増加させるように見えるが、ロールの作成または権限承認の効率は、コピーなどの方法によってグループの性質を有する従来のロールより高くなる。ユーザーを関連つける時にグループの性質を有するロールの共通性を考慮しないため、この発明技術的手段は、承認設定を明確にさせる。特に、システムが一定期間使用された後(ユーザー/ロールの権限が動的に変化している)、この発明技術的手段は、システム使用時のシステム管理の効率を大幅に向上させ、動的承認をより簡単、便利、明確にさせ、権限設定の効率と信頼性を向上させる。
【0034】
7)従来のグループの性質を有するロールの承認方法はエラーが発生しやすく、本発明の方法では、従来の方法でこのグループの性質を有するロールを関連付ける複数のユーザーにどのような共通性があるかを考慮することなく、ロールを独立した個体として考慮するだけでよいため、本発明の方法は権限エラーの確率を大幅に低減させる。承認エラーが発生した場合でも、ロールを関連付けるその一つのユーザーのみに影響するが、従来のグループの性質を有するロールはそのロールを関連付ける全部のユーザーに影響する。承認エラーが発生した場合でも、本発明の修正方法は簡単であり、時間が短く、従来のグループの性質を有するロールはエラーを修正する時にそのロールを関連付ける全部のユーザーの共通性を考えなければならない。機能ポイントが多い場合、変更が面倒且つ複雑であるだけでなく、非常にエラーが発生しやすく、且つ多くの場合、新しいロールを作成するだけで解決できる。
【0035】
8)従来のグループの性質を有するロールの承認方法では、ロールの権限機能ポイントが多くある場合、時間が長くなると、ロールの具体的な権限を覚えにくく、権限の近いロールの間の区別を覚えるのはより困難である。本発明の方法のロール自身は、役職番号/職務番号の性質を有しており、選択は明らかである。
【0036】
9)異動するときに、異動されたユーザーの多くの権限を他のユーザーに割り当てる場合、処理する時に異動されたユーザーのこれらの権限を区別して、他のユーザーを関連付けるようにロールをそれぞれ作成する必要がある。このような操作は、複雑であり、時間がかかるだけでなく、エラーが発生しやすくなる。
【0037】
本発明の方法は次のとおりである。異動されたユーザーはいくつかのロールに関連付けられ、異動する場合、まず元の部門のロールとのユーザーの関連付けを取り消し(これらの取り消されたロールは他のユーザーに再度関連付けることができる)、ユーザーは新しい部門のロールに関連付けられてもよい。操作は簡単であり、エラーが現れない。
【図面の簡単な説明】
【0038】
図1】背景技術においてシステムがユーザーを直接承認する方法の概略図である。
図2】背景技術においてシステムがグループ/クラスの性質を有するロールを承認する方法の概略図である。
図3】背景技術においてシステムがユーザーを直接承認し、グループ/クラスの性質を有するロールを承認して組み合わせる方法の概略図である。
図4】本発明のシステムにおいて独立した個体の性質とするロールを介してユーザーを承認する方法の概略図である。
図5】本発明において選択された被承認者が一つであり、且つフォームを選択するときの概略図である。
図6】本発明において選択された被承認者が複数であり、且つフォームを選択するときの概略図である。
図7】本発明において承認テンプレートで被承認者のために承認するときの概略図である。
図8】本発明の実施形態における注文フォームの概略図である。
【発明を実施するための形態】
【0039】
本発明の技術的手段は、添付の図面を参照して以下でさらに詳細に説明されるが、本発明の保護範囲は以下に限定されない。
【実施例1】
【0040】
本実施形態では、まず操作権限を制御するフィールドを設定し、次に対応する操作権限を設定する。
【0041】
フォームフィールド値の操作権限承認方法は、一つのフォームフィールド値の操作権限承認ステップと一つの被承認者の選択ステップを含み、フォームフィールド値の操作権限承認ステップと被承認者の選択ステップには前後順序がない。前記フォームフィールド値の操作権限承認ステップは、以下のステップを含む。S1:承認しようとしているフォームを選択し、前記フォーム中に操作権限制御を必要とするフィールドを表示する。S2:各フィールドのためにフィールド値の操作権限をそれぞれ承認する(S1に表示されて操作権限の制御を必要とするフィールドに対して承認し、S1に表示されず操作権限の制御を必要としないフィールドに対してそのフィールド値が検分および/または修正の権限を有するのをデフォルトにできる)。前記操作権限は、検分と修正の中の一種または二種を含む。
【0042】
設定が完了すると、被承認者はフォーム内の各フィールドの内容(フィールド値)を検分し修正する権限を決定できる。
【0043】
本発明は、フォームフィールド値の操作権限をそれぞれ承認することを達成し、システム管理の精度を向上させる。操作権限は検分と修正を含み、特にフォームに各フィールドのフィールド値がそれぞれ承認する必要がある状況に適用する。例えば、注文フォームでは、事務職員(張三)というシステムロールが「注文番号」、「顧客名」、「顧客住所」、顧客の所属する産業」、「製品モデル」、「製品数量」、「製品単価」を検分するのを許すが、「電話」と「連絡先」の様な機密フィールドの内容(フィールド値)を検分するのを許さない。本方法では、それぞれ承認するのが迅速に達成できる。別の例として、事務職員(張三)というシステムロールが「製品単価」フィールドの内容を検分するのを許すが、「製品単価」フィールドの内容を修正するのを許さない。本方法も、権限を設定するのが迅速に達成できる。設定効果図を図5に示している。
【0044】
この実施形態では、図4に示すように、前記被承認者が一つまたは複数のロールであり、前記ロールがグループ/クラスではなく、独立した個体であり、一つのロールは同時間に唯一のユーザーを関連付けることができ、一つのユーザーは1つまたは複数のロールを関連付ける。前記ロールは部門に属し、そのロールはその部門内で唯一であり、ロールの作業内容によりロールを承認し、ユーザーはロールを関連付けることにより権限を取得する。前記ロール名称は部門内で唯一であり、ロール番号はシステム内で唯一である。ユーザーは部門間で異動する時、ユーザーと元の部門内のロールの関連を取り消して、ユーザーを新しい部門のロールに関連付ける。
【0045】
以下は、独立した個体の性質とするロールを介してユーザーにフィールド値の操作権限を承認する方法の利点を分析している。ユーザーは、それとロールの関連により権限を(取得)決定する。ユーザーの権限を修正しようとしている場合、ロールの所有する権限を調整することによりそのロールを関連付けるユーザーの権限が代わる目的を達成する。ユーザーがロールを関連付けると、そのユーザーはそのロールの全ての操作権限を持っている。
【0046】
ロールは、ユーザーとの1対1の関係にある(そのロールが、ユーザーを関連付ける場合、他のユーザーはそのロールを関連付けることができなくなる。そのロールが、ユーザーを関連付けていない場合、他のユーザーが選択して関連付けることができる)。ユーザーは、ロールとの1対多の関係にある(一つのユーザーに同時に複数のロールを関連付けることができる)。
【0047】
ロールの定義:ロールは、グループ/クラス/カテゴリ/役職/職務/職種の性質を有しないが、非集合の性質を有する。ロールは唯一性を有し、独立して存在している個体である。ロールは企業や機関の応用で役職番号と同等である(役職番号はここで役職ではなく、一つの役職に同時に複数の従業員がいるが、1つの役職番号は同時に一つの従業員にしか対応できない)。
【0048】
たとえば、会社のシステムは次のロールが設立できる:総経理、副総経理1、副総経理2、北京販売部Iの経理、北京販売部IIの経理、北京販売部IIIの経理、上海販売エンジニア1、上海販売エンジニア2、上海販売エンジニア3、上海販売エンジニア4、上海販売エンジニア5、等。ユーザーとロールの関連関係:その会社の従業員である張三さんは、会社の副総経理2を務め、同時に北京販売部Iの経理を務める場合、張三さんは副総経理2及び北京販売部Iの経理というロールを関連付ける必要がある。張三さんは両方のロールに対する権限を持っている。
【0049】
従来のロールの概念は、グループ/クラス/役職/職務/職種の性質であり、1つのロールは複数のユーザーに対応できる。本発明の「ロール」の概念は、役職番号/職務番号と同等であり、映画やテレビドラマのロールに似ている。一つのロールは一つの俳優のみに同時に(幼年、少年、中年・・・)演じられ、一つの俳優は複数のロールを演じることができる。
【0050】
ロールを作成した後、ユーザーを作成するプロセスでロールを関連付けることができ、または、ユーザーを作成した後、いつでもロールを関連付けることができる。ユーザーは、ロールを関連付けた後ロールとの関係がいつでも解除でき、他のロールとの関係をいつでも確立できる。
【0051】
前記ロールの構成は、職名+職務番号である。例えば、作業場生産労働者1、作業場生産労働者2、作業場生産労働者3等様なロールは、独立した個体であり、これは役職番号/職務番号と同等であり、従来の権限管理システムのロールとは異なる。従来のシステムのロールの概念は、役職/職務/職種等のグループ/クラスの性質である。
【0052】
次の例は、張三という従業員が入社した後、従業員やユーザーやロールの関係を示している。1.新入職:従業員は新しく雇用され、そのユーザー(従業員)に対応する役職番号/職務番号のロールを直接関連付けてもよい。例えば、張三は会社に加わった(会社は張三に張三というユーザーを割り当てた)。仕事内容は営業部Iにあり、北京地区の冷蔵庫製品の販売を担当した(対応するロールは販売部Iの「販売エンジニア5」というロールである)。次に、張三というユーザーが「販売エンジニア5」というロールを直接選択してもよい。
【0053】
2.職務の追加:一定期間勤務した後、張三は北京で地域テレビ製品の販売を担当するようになり(対応するロールは販売部Iの「販売エンジニア8」というロールである)、同時に販売後部門の主管を兼務した(販売後部門の主管というロールに対応する)。次に、張三というユーザーは、販売部Iの「販売エンジニア8」と販売後部門の「販売後主管」という二つのロールを増やして関連付けられた。この時に、張三という従業員には、三つのロールを関連付け、これ等は、ぞれぞれ販売部Iの「販売エンジニア5」、「販売エンジニア8」、及び販売後部門の「販売後主管」であり、張三というユーザーは、これら3つのロールに対する権限を持った。
【0054】
3.職務の減少:しばらくして、会社は張三を販売後部門の経理(販売後部門の「販売後経理」というロールに対応する)として任命し、他の仕事を兼務しないようにすることを決めた。次に、張三というユーザーは、販売後部門の「販売後経理」というロールに関連付けられ、以前に関連付けられていた3つのロールを取り消された(販売部Iの「販売エンジニア5」、「販売エンジニア8」、及び販売後部門の「販売後主管」)。この時に、張三というユーザーは販売後部門の「販売後経理」というロールの権限のみを持っていた。
【0055】
4.ロールの権限の調整(役割の自身所有する権限に対して調整する):会社が販売後経理の権限を増やすことを決定した場合、販売後経理というロールの権限を増やすだけでよく、張三というユーザーは販売後経理というロールの権限が増加するため、張三というユーザーの権限も増加した。
【0056】
5.辞任:1年後、張三は辞任した。張三というユーザーと販売後部門の「販売後経理」というロールの関連を取り消してもよい。
【0057】
例えば、会社は動的な経営中に、従業員の入社と退社が頻繁に継続的に発生するが、役職番号/職務番号の修正は非常にわずかである(特定の期間で変化しない)。
【0058】
従来の承認方法:システム機能ポイントが多くある場合、従来のグループ/クラスとするロールを介して承認する。これは、承認に大量の複雑な作業負荷があるだけでなく、エラーが発生しやすい。エラーは、発生した場合でも、短時間で容易に見つけられず、システムのユーザーに損失を与えやすい。
【0059】
本発明の承認方法:本発明は、役職番号/職務番号の性質とするロールに対して承認し、ユーザーがロールを関連付けて権限を決定(取得)すると、ユーザーの権限を制御するのは、単純なユーザーと役割の関連付けにより実現される。これにより、権限の制御を簡単、便利、明確にして、権限承認の効率と信頼性を大幅に向上させる。
【実施例2】
【0060】
この実施例には、被承認者を選択するときに1つ以上を選択することができ、承認しようとしているフォームを選択するときに1つのみを選択することができる。被承認者が選択されており、且つ1人だけであり、承認しようとしているフォームを選択する時、被承認者に対してそのフォームフィールド値を最近承認する操作者と操作時間を表示する。
【0061】
図5に示すように、一つの被承認者を選定し、且つ承認フォームを選定する時、最近フォームフィールド値の操作権限を承認する操作者と操作時間を表示する。そのフォームのフィールド値の操作権限に対するその被承認者の状態も表示でき、それを修正して保存した後新しいフィールド値の操作権限を取得する。
【0062】
図6に示すように、複数の被承認者を選定し、且つ承認フォームを選定する時、最近フォームフィールド値の操作権限を承認する操作者と操作時間には空を表示する。そのフォームのフィールド値の操作権限に対するその被承認者の状態も表示できない。
【0063】
最近の操作者を表示するのは、フォームフィールド値の権限を承認してエラーが発生する時責任を追究するのに都合がよい。最近の操作時間を表示するのは、フォームフィールド値を再承認する必要があるかどうかを直感的に判断するのに都合がよい。
【0064】
例えば、張三という被承認者の契約フォームフィールド値の操作権限を前回承認した操作は、2015年5月21日11:00に李四によって完成されたとする。被承認者を張三と選択し且つ承認フォームを契約と選択する時、今回の承認操作者のためは、2015年5月21日11:00に李四が張三のために契約フォームを前回承認したことを表示する。
【0065】
張三は機密フィールドの内容を検分する権限を備えるべきではないとしたときに、然も張三に対して前回承認する時に張三にその機密フィールドの内容を検分する権限を備えさせたとする。続いて責任を追究している過程に、前回承認する操作者を検索することにより責任者を見つけることができる。
【0066】
別の例としては、操作者は100人の被承認者に対して契約フォームフィールド値を承認する必要があるが、即日、その操作者は70人の被承認者に対する承認のみを完成した。その操作者は翌日に承認を続ける時、各被承認者の前回承認された時間を検分することにより、その被承認者を承認する必要があるかどうかを判断することができる。また、承認時間間隔により、指定された時間間隔に承認されたすべての被承認者を捜し出すこともできる。被承認者の前回承認された時間を検分することにより、被承認者の権限が修正されていない期間を知ることができるのは、其れを再承認する必要があるかどうかを直感的に判断するのに都合がよい。
【実施例3】
【0067】
本実施例には、表示権限を有しないフィールド値に対して、その表示方式が以下の方式を含む。(1)前記フィールド値に対応するフィールドを表示するが、隠し符号でフィールド値を隠し、例えば、図8に示すように、フィールド「電話」と「連絡先」を表示するが、フィールドの内容を隠し符号*で隠す、(2)そのフィールド値及びそのフィールド値に対応するフィールドを全て表示しない。
【0068】
修正権限の有無を区別して検分することも必要であり、たとえば、修正権限を有しないフィールド値は、図8に示すように灰色の陰影と表示される。
【0069】
具体的には、フォームが基本フィールドと詳細フィールドを含み、詳細フィールドがフォームの詳細リストの列名である。たとえば、注文フォームに基本フィールドが注文番号、顧客名、顧客住所、電話番号、連絡先、顧客の所属する産業などを含む。詳細フィールドが製品モデル、製品数量、製品単価などを含む。
【0070】
優先的に、操作者がフォームフィールド値の操作権限を承認する時、基本フィールドと詳細フィールドを区別して表示し、承認する時に操作者が区別するのに都合が良い。図5-7に示すように、注文番号、顧客名、顧客住所、電話、連絡先、顧客の所属する産業の様な基本フィールドを通常の字体で表示し、製品モデル、製品数量、製品単価の様な詳細フィールドを斜体で区別して表示する。
【実施例4】
【0071】
本実施例に、フォームフィールド値の操作権限承認方法は、更にテンプレート承認ステップも含み、具体的に、(1)被承認者と承認フォームを選択し、1つまたは複数のロールを選択して被承認者とすること、(2)被承認者に対し承認を行い、一つの既存のロールまたは作成されたテンプレートを選択して承認テンプレートとし、その承認テンプレートのフォームフィールド値の操作権限をその被承認者に与えること、(3)修正後または修正しない後、保存して被承認者のフォームフィールド値の操作権限を取得することを含む。
【0072】
図7に示すように、テンプレート承認方法は、まず、事務員1(張三)という被承認者を選択し、承認フォーム「注文フォーム」を選択し、作成されたテンプレート1を承認テンプレートとして選択し、作成されたテンプレート1のフォームフィールド値の操作権限を事務員1(張三)のフィールド値の操作権限として使用し、修正後または修正しない後、事務員1(張三)のフォームフィールド値の操作権限を保存して取得する。
【0073】
本方法では、複数の承認されたロールを同時に選択して一括して承認することができ、承認の効率を向上させる。外に、本方法はテンプレート承認を支える。即ち、一つの既存のロールまたは作成されたテンプレートを選択して承認テンプレートとし、その承認テンプレートのフォームフィールド値の操作権限をその被承認者(再度簡単に修正された後保存された)に直接的に与える(更新)。承認操作は簡単と高能率になる。2つの方法を組み合わせることにより、システムのフォームフィールド値の操作権限の承認効率を大幅に向上させる。
【実施例5】
【0074】
本実施例には、まず操作権限を選択し、次に操作権限を有するフィールドを設定する。
【0075】
フォームフィールド値の操作権限承認方法は、一つのフォームフィールド値の操作権限承認ステップと一つの被承認者の選択ステップを含み、フォームフィールド値の操作権限承認ステップと被承認者の選択ステップには前後順序がなく、前記フォームフィールド値の操作権限承認ステップは、S1:承認しようとしているフォームを選択すること、S2:承認しようとしている操作権限を選択すること、S3:選択された操作権限を有するフォーム中にフィールドを設定すると、設定されたフィールドは選択された操作権限を備えること(つまり、そのフィールドのフィールド値の相応の操作権限を備える)を含み、前記被承認者が1つまたは複数のロールであり、前記ロールがグループ/クラスではなく、独立した個体であり、一つのロールは同時間に唯一のユーザーを関連付けることができ、一つのユーザーは1つまたは複数のロールを関連付ける。
【0076】
上記は本発明の優先的な実施形態だけである。本発明は、本明細書に開示された形態に限定されないと理解され、他の実施形態を除くとみなされず、却って様々な他の組み合わせや修正や環境に利用でき、本明細書のコンセプトの範囲内で、上記の教示または関連分野の技術または知識により修正を行うことができる。当業者に行われる修正及び変更は、本発明の趣旨及び範囲から逸脱するものではなく、全部と本発明に添付される請求項の範囲内にあるべきである。
図1
図2
図3
図4
図5
図6
図7
図8