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