CN101159589B

CN101159589B - 分布式用户确认及资料管理系统

Info

Publication number: CN101159589B
Application number: CN2007101376820A
Authority: CN
Inventors: 乔·乌尔巴内克; 柯蒂斯·布拉斯维尔; 玛丽·奥格登
Original assignee: Fisher Rosemount Systems Inc
Current assignee: Fisher Rosemount Systems Inc
Priority date: 2006-07-31
Filing date: 2007-07-31
Publication date: 2012-05-30
Anticipated expiration: 2027-07-31
Also published as: US20080028069A1; GB0714836D0; US8285845B2; JP2008033936A; DE102007035273A1; US20110173322A1; GB2440665A; GB2440665B; CN101159589A; HK1112518A1; JP5201904B2; US7921201B2

Abstract

一种分布式用户确认及资料管理系统运行，自动地确认及更新用户资料(例如那些储存于组织安全数据库内者)，以完全地反映组织内的不同用户的实际位置及他们对多种组织资产的使用权利，如计算机实施应用程序。此内描述的用户确认及资料管理系统包括一种用户确定引擎，用户确定引擎定期地以电子邮件的方式发送通知到组织内的不同用户，以启动更新及确认用户资料信息的过程。所有个别用户可通过访问或使用确认电子邮件内提供的电子链接、对确认电子邮件作出反应，以确认他们在组织内的位置及状况以及一名或更多其他密切相关用户(如一名经理或直接下属)的位置或状况。用户未对确认电子邮件作出反应会造成用户确认及资料管理系统在用户试图访问应用程序时确定用户资料为无效，因此防止该用户访问或使用组织内的网络化应用程序。

Description

分布式用户确认及资料管理系统

技术领域

本发明一般涉及计算机安全系统，尤其涉及计算机资源管理及电子门户访问系统的安全。

背景技术

许多典型的计算机网络-如与企业或其他组织关联的计算机网络-被用于使不同用户(这些用户典型地是雇员、顾问、或与有关组织合作或为有关组织工作的其他人员)能访问作为有关组织资源的部分的一种或多种计算机网络化应用程序。计算机应用程序可以包括典型的文字处理、电子制表软件、显像、电子邮件、关系管理应用程序或其他类别的一般应用程序，这些应用程序可能有、或可能没有其特殊的安全设置。计算机网络所提供的、作为组织资源的部分的应用程序可能还包括或选择性地包括多种组织特有或组织敏感应用程序，比如会计应用程序、策划及营销应用程序、资源管理应用程序、培训应用程序、雇员管理及人力资源应用程序，以及为执行对有关组织的运行有用的多种不同任务、而在有关组织内部提供的、或作为有关组织的部分提供的其他类别的应用程序。在许多情况下，这些应用程序具备与其相关的安全装置，以确保只是与有关组织相关的一些用户可以访问这些应用程序，或确保有些用户只能有限度地使用这些应用程序-视用户在有关组织中的职位、工作、头衔、部门、职责、等因素而定。因此，在许多情况下，每名用户只能访问在有关组织内使用的有限数目的应用程序，而且可能只能获得其可访问的应用程序中的一些程序或全部程序的有限访问权限或有限访问特权。

虽然在很小的组织或是由单一协合实体构成的组织，可以相当容易地管理该组织内部的用户对该组织所提供的不同应用程序的访问；但是，在较大的组织中，管理用户对组织的多种计算机资产的访问可能变成一种令人沮丧、费时而单调乏味的苦差，这是因为较大的组织典型地有更多用户访问应用程序，而且有更多与该组织内的不同任务或功能相关的应用程序。较大的组织也在大多时间有一些担当组织合伙人或代表的第三方公司或实体，而且这些第三方公司或实体因此必须获得某种对该组织的计算机应用程序的访问权限。此外，较大的组织内的就业变动更频繁，而且一般不集中，有时造成这些变动未被报告或未被该组织的较高管理层注意。因此，在过去，跟踪和更新(即：使与时俱进)提供给组织的各类用户的组织计算机网络资产访问特权，一直都是麻烦而又相当单调乏味的任务。在有些情况下，与组织相关的计算机网络上的每个单独的应用程序管理对该应用程序有访问权的用户，以及管理每一用户可获得的访问量或级别。虽然这种设置提供高级别的安全保障，但这种设置在大的组织中变得非常不实用，而且难于管理；这是因为在用户离开或加入组织的任何时间，访问特权必须按个别应用程序进行更改，而且在有些情况下，用户在组织内的职位或角色改变时，访问特权必须按个别应用程序进行更改。在较大的组织中，用户数目及/或应用程序数目较大，人员流动量及变动可能频繁地发生，使得更新每个应用程序的访问安全设置变得困难或费时。

为克服这个难题，组织-尤其是应用程序数目及/或雇员数目较大的组织-设立“全组织用户资料系统”，为每一用户定义该用户的身份以及该用户的有关信息，包括有关定义不同应用程序的信息，也可能包括有关定义该用户有权访问的不同应用程序内的访问或安全级别的信息。其后，当某一特定用户试图登录或访问某一应用程序时，一个与该应用程序联系的安全系统利用用户资料、确定该用户是否具备适当资格或安全性来访问和使用该应用程序，或确定该用户是否具备适当资格或安全性在其要求的访问级别访问和使用该应用程序。然而，还是需要保持用户资料随时更新和准确，以防止已经离开组织的用户能够访问组织应用程序，或确保在组织内改动职位的雇员按其目前职位、拥有正确的对应用程序的访问特权。

应该理解，在雇员离开组织时，典型地需要更改用户资料，以即时终止其对所有应用程序的访问。此外，在雇员在组织内的职位变动时，也可能需要更改用户资料，这是因为用户对特定应用程序和对同一应用程序内的特定内容的访问权限一般取决于用户资料的一个或多个属性，例如雇员的办事处ID、局、部门、职称、职责、技能级别、或地理区域位置。因此，在许多情况下，任何有关用户职位的变动必须即时记录或反映在应用程序的安全系统所使用的用户资料内，以确保在需要时可以审查及更新用户对内容的访问权限。

传统上，组织在内部提供了特定的和典型地集中的、主要职责在于更新应用程序安全系统所使用的用户资料的团组或部门(如人力资源部门、信息技术部门、或其他部门或团组)，以确保在雇员离开或在组织内变动职位时、用户对组织应用程序的访问正确。然而，特别是对于较大的组织而言，在集中位置或由特定部门对用户资料进行人工更新的过程对于那些被指派执行这项任务的人员来说，可以是非常单调乏味和费时的。此外，由与资料被更改的用户没有密切关系的团组来更新用户资料的过程可能充满错误与延误。此外，因为存在第三方代表，组织很可能从未知道用户何时离开或改动其资料。明确地说，在许多情况下，人力资源或信息技术部门并未适当地或一律地获知组织结构内的变动，这些变动可能导致需要对一份或更多用户资料进行变更，如组织责任变更、组织的部门内或部门之间的人员移动、组织的多个部门内的经理/下属关系的变更等等；这些变更中的任何变更或所有变更可能迫使必须对受组织变动影响的特定用户的访问权限进行变更。此外，在大组织或在人员流动率高或有第三方关联组织的组织内，因正常耗损而导致的用户资料创建及更改量可能变得相当费时及单调乏味，而且典型地是一个未在预定时间或定期地被适当关注的操作，这是由于其不费力，使得这个操作在组织中被忽略。这些情况可能因此导致适当反映不同用户的正确信息所需进行的用户资料移除、更新或修改工作被积压；而对于确保组织内的应用程序或计算机网络设施的正确使用而言，这些变更不可或缺。

不幸的是，未能及时为组织的网络化资产提供正确的安全性或访问特权，可能在有些情况下变得很严重。明确地说，不适当或不及时的用户资料更新可能导致储存于个人文档的商业秘密、机密技术、营销及销售信息、机密个人信息等等被泄露，这是由于这些安全失误可能被已经离开组织或已经在组织中变动职位的、不满或无道德的雇员利用，而对组织造成重大损害。

发明内容

一种分布式用户确认及资料管理系统运行以自动确认及更新用户资料(如那些储存于组织安全数据库内的用户资料)、藉以完全地反映不同用户在组织内的实际职位及其对多种组织资产的权利(如计算机实施应用程序)。这里描述的确认及资料管理系统包括一种用户确认引擎，用户确认引擎定期地(如以电子邮件的方式)传送通知给组织内的不同用户，以启动确认及更新用户资料信息的过程。个别的用户们可以(如通过访问或使用确认电子邮件中提供的电子链接)对确认电子邮件作出反应，以核实他们在组织内的职位及状况。在一个实例中，用户们核实他们还受雇于组织或核实他们还是以目前记录在案的用户资料中所提供的地位、与组织发生关系。用户未对确认电子邮件作出反应会促使用户确认及资料管理系统在该用户试图访问任何应用程序时确定用户资料无效，从而防止用户能得以访问或使用组织内的网络化应用程序。

此外，在另一实例中，特定用户可以、或在有些情况下必须核实或确认组织内的一名或更多其他用户，如特定用户的监督人或直接下属，即这里称为“与特定用户密切相关的用户”者。这个设置确保任何特定用户的状况(以及该用户的用户资料)由该特定用户及在组织内一名与该特定用户密切相关的人员(如该特定用户的经理或下属)核实。一名或更多与特定用户密切相关的用户未核实该特定用户，将导致该特定用户的用户资料被视为无效，因此将防止该特定用户能够访问组织的网络化资产。

此外，为防止用户确认及资料管理系统向任何特定用户传送大量电子邮件、或防止用户确认及资料管理系统变得使用户单调乏味，确认系统在接收确认电子邮件的用户组合之间交替发送电子邮件，所以用户不需要在每一确认期内核实他们自己和他们的密切相关用户。在一个实例中，用户确认及资料管理系统只是在每一其他确认期传送一个电子邮件到任何特定用户。因此，作为一个例子，在一个第一确认期，用户确认系统可以只向组织内的第一半数的用户传送一个电子邮件，要求作为确认电子邮件的传送对象的第一半数的用户确认他们自己以及第二半数的用户中的一名或更多其他密切相关用户(即：不是确认电子邮件的传送对象的半数用户)。其后，在另一确认期，确认系统只向组织内的第二半数的用户传送电子邮件，要求第二半数的用户中的每名用户确认他们自己以及在第二确认期内没有接收确认电子邮件、属于第一半数的一名或更多其他密切相关用户。照这样，确认系统更新或确认每一用户资料的次数，是任何特定用户必须对一个确认电子邮件作出反应的次数的两倍。

应该理解，这里描述的用户确认系统通过要求密切相关用户在每一其他确认期内相互确认，为用户的自我确认提供自动核对。照这样，虽然离开组织或在组织内变动职位的特定用户(但其尚可访问组织网络)可以在变更发生后的第一确认期内确认自己，但在变更发生后的第二确认期内、当该特定用户的指定密切相关用户(如该特定用户的经理或下属)需要确认该特定用户时，该特定用户将还是会被确定为无效，这是因为该特定用户的密切相关用户将知道该特定用户不应再被确认，而且将在其对确认电子邮件作出反应时拒绝确认该特定用户。

因此，这里描述的用户确认及资料管理系统提供了一种自动的、要求用户确认他们自己以及组织内的其他密切相关用户的方法，以提供一种自动、连续及定期更新的用户确认程序，这种用户确认程序在完全不需要特定团组(如人力资源部门)来启动、监视或人工地输入用户资料变更的情况下、提供更多安全性，及更好地确保对不同组织网络化设施的访问适当-虽然在有些情况下可能需要一名管理员来监视用户资料变更。此外，这里描述的用户确认系统在连续的确认期内交替确认任务，所以确认系统更新及核实每份用户资料的次数比任何特定用户需要在该系统内更新及核实他们自己的次数更频。这种系统因此提供更准确及更快捷、或至少是更经常的用户资料确认，并且根据用户在组织内的职位变动实施一种程序，防止用户在他们不应再访问组织资产时还能够戏耍系统而继续访问组织资产。此外，确认系统也可以轻易地根据用于定义确认系统使用的不同确认团组的关系、定义及更新描述组织内的经理/下属关系的组织结构图。

附图说明

本发明通过附图中的例子被阐明(而不是局限)，其中相似的附图标记表示类似的元件；而其中：

图1为框图/原理图，显示一个与组织相关的计算机网络，包括多用户应用程序、多用户界面装置、以及一个用户确认及资料管理系统；

图2为框图，显示图1的网络内的用户确认及资料管理系统的操作；

图3描绘一个组织结构图或层次，用于为图1及图2的用户确认及资料管理系统定义多个确认团组；

图4是一个模范显示屏幕，显示一个确认电子邮件，该确认电子邮件可以由图1及图2的用户确认及资料管理系统发送；

图5描绘一个屏幕显示，该屏幕显示与用于确认图1及图2的系统内的一名或更多用户的一个相关确认页；

图6显示一个用户档案范例，该用户档案有两组确认栏位，用于确定一份用户资料的有效性；

图7显示：为对确认电子邮件作出反应、三个密切相关用户的用户档案怎样被更新的一个范例；

图8显示：为对确认电子邮件作出反应、三个密切相关用户的用户档案怎样被更新的另一个范例；

图9显示三个密切相关用户的用户档案，这些用户档案与确定其用户资料的有效性或无效性的第一个范例有关；

图10显示三个密切相关用户的用户档案，这些用户档案与确定其用户资料的有效性或无效性的第二个范例有关；

图11显示三个密切相关用户的用户档案，这些用户档案与确定其用户资料的有效性或无效性的第三个范例有关；

图12显示一个组织结构图或层次，该组织结构图或层次创建自用户资料，并显示用户之间的经理/下属关系；

图13描绘一个组织结构图或层次，用于为图1及图2的用户确认及资料管理系统定义三个确认团组；

图14描绘一个组织结构图或层次，用于为图1及图2的用户确认及资料管理系统定义三个确认团组；

图15显示一份用户档案，该用户档案有三组确认栏位，用于确定一份相关用户资料的有效性；

图16显示：为对确认电子邮件作出反应、图15中所示类别的密切相关用户的用户档案怎样被更新的第一个范例；

图17显示：为对确认电子邮件作出反应、图15中所示类别的密切相关用户的用户档案怎样被更新的第二个范例；

图18显示三个密切相关用户的用户档案，这些用户档案有三组确认栏位，而且与第一次确定其用户资料的有效性或无效性的一个范例有关；

图19显示三个密切相关用户的用户档案，这些用户档案有三组确认栏位，而且与第二次确定其用户资料的有效性或无效性的一个范例有关；

图20显示三个密切相关用户的用户档案，这些用户档案有三组确认栏位，而且与第三次确定其用户资料的有效性或无效性的一个范例有关；

图21显示三个密切相关用户的用户档案，这些用户档案有三组确认栏位，而且与第四次确定其用户资料的有效性或无效性的一个范例有关。

具体实施方式

现在参考图1，其以框图的方式描述一个与某组织(如企业、非营利实体、公司、政府、政府实体、或任何其他组织实体)相关的计算机网络系统10。如图1中所示，计算机网络系统10包括一个局域网(LAN)12，局域网(LAN)12以网络化方式交互地连接多种不同类别的计算机硬件装置。明确地说，所述的计算机网络系统10包括多个用户工作站或用户界面14；通过用户工作站或用户界面14，与该组织相关的各类不同的用户可以访问经由局域网(LAN)12网络化的计算机设施。此外，各种计算机16(如服务器、数据库、应用程序站、等等)被交互地连接到局域网(LAN)12，并被用于储存及执行一个或更多应用程序18。此外，如图1中所示，应用程序18A被储存于计算机16A，而计算机16A经由一个门户或安全服务器装置24被连接到局域网(LAN)12；如果需要，门户或安全服务器装置24可以协调或执行涉及应用程序18A及/或应用程序18的用户确认。

一般而言，利用其中一个工作站14，用户可以实施或可以访问应用程序18及18A。当然，应用程序18及18A可以是任何符合要求的类别、性质、品牌的应用程序，例如包括会计应用程序、财务应用程序、人力资源应用程序、资源管理应用程序、培训应用程序、库存应用程序、维护应用程序、营销及销售应用程序、设计应用程序、或在组织内使用或有用的任何其他应用程序。此外，虽然在工作站14的用户中的多名用户可以经由局域网(LAN)12访问应用程序18及18A中的任何一个应用程序，但如果需要，应用程序18及18A可以以任何期望方式下载到工作站14并在工作站14内执行，或可以是原先储存于工作站14内。

此外，局域网(LAN)12可以通过节点26、26A及26B连接来提供对不同地理位置的组织资产的访问，以提供(例如)对组织内的、与组织相关的、或构成组织的不同部门、关联机构、或其他实体有关的网络化资产的访问。因此，如图1中所示，用户界面计算机14A及14B可以被连接到局域网(LAN)12A及局域网(LAN)12B，而且可以与离站设施或在工作站14所在设施的位置以外的设施发生关系。可以使用任何类别的通信网络-包括广域网(WAN)、卫星通信、互联网、专用网络等等-经由节点26、26A及26B、将用户界面计算机14A及14B连接到局域网(LAN)12。此外，虽然图1中没有显示，但可以将附加的应用程序18及18A储存于计算机装置上，或储存于与通信网络12A及12B连接的设施上。照这样，计算机网络系统10不但不受局限于一个单一站点，而且可以包括经由任何期望类别的通信结构(包括公共网络或专用网络、局域网[LAN]、广域网[WAN]、等等)互相连接的多个站点。

如图1中所示，门户24被连接到局域网(LAN)12，并用于将许多用户资料28储存于一个资料数据库30中。一般的情况是，与组织相关的各类用户中的每一用户至少有一份用户资料28；或可以访问计算机网络系统10的应用程序18及/或18A中的任何一个应用程序的每一用户至少有一份用户资料28。在运行时，门户24实施一个安全例程或一个安全引擎32，安全引擎32限制用户对应用程序18及/或18A的访问；根据某一特定用户的用户资料28、安全引擎32确定该特定用户是否拥有正当权力来访问或运行应用程序18或18A；如果该特定用户拥有正当权力来访问或运行应用程序18或18A，安全引擎32会确定该用户对应用程序18或18A的访问量和级别。

重要的是，门户24包括一个用户确认及资料管理系统，该用户确认及资料管理系统有一个确认引擎34和一个确认数据库36，(例如)在用户试图访问应用程序18或18A中的任何一个应用程序时，两者运行以自动地确认用户的用户资料。此外，如这里将作更详细描述的一样，用户确认及资料管理系统可以运行以使用户能根据组织内的变更(如雇用新用户、用户离开或在组织内变动职位、用户接受新的或不同的职责、用户迁移到组织内的新的或不同的职责或位置、等等)来更新用户资料数据库30内的用户资料28；任何这些行动可以对用户与组织的关系起重新定义作用，因此，也可以对用户应获得的应用程序18或18A访问权类别起重新定义作用。

为执行这些功能，用户确认及资料管理系统包括一个确认引擎34、一个确认数据库36、一个本地服务器38(可以是一个电子邮件及网络服务器)、以及(在有些情况下)一个公共服务器40(如连接到互联网或全球信息网的电子邮件服务器)。如图1中所示，本地服务器38可以经由局域网(LAN)12连接到各个工作站14，以通过组织内的内部网络发送电子邮件；本地服务器38还可以连接到公共服务器40，公共服务器40可以是互联网服务器或其他公共网络服务器，用于发送电子邮件到组织外的地址，或用于发送必须经由公共通信网络发送的电子邮件到与组织有关的用户。如这里稍后将作更详细描述的那样，确认引擎34生成确认通知(以电子邮件形式为宜)，经由本地服务器38(及/或公共服务器40)传送到各类用户，以启动确认及更新储存于用户资料数据库30内的用户资料28的过程。

在使用时，门户24利用用户确认及资料管理系统、向登录到用户界面14的一个或更多界面的用户提供应用程序18或18A的访问权，并实施自动及定期的用户确认程序。明确地说，在一个实例中，用户确认及资料管理系统作为门户24的部分进行操作，向一名或更多用户提供应用程序18A中的一个或更多应用程序的访问权。在这种情况下，当一名用户登录到门户24以及选择访问一个应用程序18A时，安全引擎32首先根据储存于确认数据库36内的确认信息，检查及确定该用户储存于用户资料数据库30内的用户资料28是否有效。如果该用户的用户资料28目前有效，门户24提供应用程序18A的访问权。作为这个过程的部分，应用程序18A或门户24内的安全引擎32可以根据该用户的用户资料28的细节或根据储存于应用程序18A内的其他信息，确定向该用户提供的安全级别或访问权级别。

图2以框图的形式描绘：为实施用户确认过程，安全引擎32及用户确认及资料管理系统与用户14中的一名或更多用户及应用程序18及/或18A逻辑地互动的一种方式。明确地说，当在工作站14的其中一个工作站的一名用户试图访问应用程序18A时，确认引擎34首先确定该用户的用户资料28是否有效。如图2中所示，在一个实例中，每份用户资料28包括一个相关组合的确认信息42(储存于图1中所示的确认数据库36内)，被确认引擎34用于确定用户资料28的有效性。每组合的确认信息42可以包括两个确认栏位，用于储存确认系统过去生成的确认电子邮件的日期；而确认引擎32根据预定确认规则、使用这些栏位来确定某特定用户资料28目前是否有效。如果该用户或相关用户资料28有效，则该用户按用户资料细节(例如：如果用户资料28的数据显示该用户应获得应用程序18A的访问权)、获得应用程序18A的访问权。此外，任何应用程序18A可以储存其安全或访问权信息、或可以使用用户资料28来确定应用程序18A应向该用户提供的访问权级别。如果用户资料28被确定为无效，则该用户被拒绝访问其要求的应用程序18A。然而，应注意的是，即使某份用户资料28可能显示相关用户拥有某一应用程序18A的访问权(例如：该用户的职位名称、职责、等等与该访问权相符合)，但根据储存于确认数据库36内的确认数据、该用户资料28可能还是被确定为无效。在这种情况下，门户24内的安全引擎32将不会向该用户提供其需要的应用程序的访问权，这是由于其用户资料已经被确定为无效-不论用户资料内储存的数据为何。

一般而言，用户确认系统30通过为自动化用户注册提供一个用户资料管理界面以及经由电子邮件周期性通信及资料确认活动、及/或与每名用户、每名用户的经理及每名用户的一名或更多直接下属或下属进行的网络活动，使用户资料信息的采集、核实及发送自动化。明确地说，用户确认系统30使用某用户与一名或更多相关用户(如该用户的经理和该用户的直接下属)之间的组织关系的有关采集及储存信息来创建一个组织树，以及允许用户确认及说明调动，或在该组织树上终止其本身或终止与其直接关联的任何人员。

如以上所述，确认系统的用户界面可以是一种门户应用程序，该门户应用程序除了执行以上讨论的安全设置以外，还为访问应用程序18A提供一个登录中心点；而且，如果需要，可提供应用程序18，应用程序18的用户必须由确认系统确认和维护。应该理解，用户资料确认是以不依赖发送自或发送至有关组织内的任何特定部门或有关组织的关联机构(如人力资源部门、信息技术部门、等等)的、关于雇员状况的信息的方式，通过电子邮件通信和网页登录来实现的。

此外，一旦设置确认系统，用户资料确认经常及定期地发生，这是由于确认系统自动及定期地要求用户们亲自更新确认数据库36内的确认数据42。为实施确认系统，该系统本身、或一名配置人员首先定义两个或更多不同的用户团组(称为“确认团组”)，其中每名用户属于而且仅属于一个确认团组。在一个实例中，确认系统30只使用两个不同的确认团组(或Vgrps)来执行用户资料确认，虽然在其他实例中可能使用更多团组。在使用两个确认团组的实例中，可以通过首先为每名用户定义该用户的经理及该用户的任何直接下属或下属来确定确认团组。这些定义关系实质上定义一个用户组织结构图。然后，根据该组织结构图，每名用户被定义属于或分配到该两个不同的确认团组中的一个(只是一个)团组。

图3显示一个组织树50，其中两个确认团组(Vgrps)被定义为第1确认团组(VGrp1)及第2确认团组(VGrp2)。如图3中所示，可以首先根据组织内的经理/用户/下属关系，建立一个层次树来确定确认团组，这些经理/用户/下属关系可以在最初注册时采集，其后可以由确认过程本身采集或通过用户进行的资料更新来采集。如图3中所示，当组织树50被确定时，该两个确认团组-第1确认团组(VGrp1)及第2确认团组(VGrp2)-被定义为该树内的交错层次。应该理解，图3中所示的每个框代表一名单一用户，该用户上方及直接连接到一名用户的一个框代表其经理，该用户下方及与该用户直接连接的每一个框代表该用户的下属或直接下属。如图3中所示，组织树50上的交错层次有不同的第1确认团组(VGrp1)及第2确认团组(VGrp2)，或与不同的第1确认团组(VGrp1)及第2确认团组(VGrp2)相关。一旦某个组织的确认团组被确定时，这些团组可以储存于确认数据库36(如图1中所示)或(如果需要)储存于任何其他数据库或储存器内。

在确认团组被确定后，确认引擎34在每一确认期向其中一个确定团组(称为“目标团组”)的用户发出一组合的确认通知(以电子邮件形式为宜)，所述每一确认期在本例子中将被定义为每两周。确认通知的目的在于提示用户确认他们及组织内的一名或更多其他用户还是有效用户。在一个实例中，在每一确认期，目标团组都在确认团组之间变动或交替。因此，如果确认电子邮件在第一个确认期是在1月2日发送到第1确认团组(VGrp1)，则确认电子邮件在第二个确认期是在1月16日发送到第2确认团组(VGrp2)，而且确认电子邮件接着又在第三个确认期即在1月30日发送到第1确认团组(VGrp1)，依此类推。当然，确认期并不限于两周，而是可以设为最适合有关组织需要的一个较大或较小的时程。应该理解，用户确认系统每两周(或设定的确认期)确认每名用户，但其确认方式是：任何特定用户每四周(或设定确认期的两倍)只收到确认电子邮件一次。

一旦一个确认电子邮件在目前的一个确认期发送到目标团组，确认系统要求目标团组的每名用户确认其本身，以及确认在组织树50直接连接于其上方的用户(典型地是其经理)及在组织树50直接连接于其下方的用户(典型地是任何直接下属或下属)。因此，当一名用户完成确认时，其已实质地确认其本身、其在目前确认期的经理、及任何直接下属或下属。由于在组织树50直接连接的两名用户一般将绝不会被分配到同一确认团组，这些用户将不会同时或在同一确认期内收到确认电子邮件；也就是说，在组织树50相互直接连接的用户(他们相互对彼此的就业状况大概会有最准确的信息)将相互确认，从而提供一个更准确以及更安全的确认过程。此外，在组织树50的不同层次、直接连接的用户在任何两个连续的确认期内将只需收到确认电子邮件一次(在这个例子中是每四周一次)。然而，由于第1确认团组(VGrp1)的用户确认在组织树50中层次在他们之上或他们之下的第2确认团组(VGrp2)的用户(反之亦然)，实际上每一用户在每一确认期(即：在每两周)被确认。

虽然以下的讨论提供一个利用确认电子邮件来更新确认数据库36，使得能够在组织内进行定期和及时的用户确认的方式的例子，但将可了解，这里描述的细节可以以许多方式更改或改变，以实施这里描述的用户确认及资料管理系统。

图4显示一个屏幕，屏幕显示一个确认电子邮件52的例子，该确认电子邮件52可以被发送到用户、用于启动确认过程；该用户在这个确认过程中确认其本身及一名或更多其他用户。如图4中所示，确认电子邮件52可以包含一个关于确认过程的简短讯息，连同一个通往确认系统的链接56。如果需要，链接56可以包括一个储存于用户资料的唯一值或ID(未显示)，这个唯一值或ID可用于识别组织内的用户。当用户点击链接56时，用户的计算机14打开一个浏览器，浏览器查找与确认系统相关的一个确认服务器(例如可以是图1中所示的本地服务器38)，确认服务器提供一个确认页，以用于执行确认。图5图示一个这样的确认显示的例子(或页60)。由于用户的身份可以从链接56的唯一ID或密码确定，确认服务器38可以在不要求用户登录的情况下生成确认页60，而且可以使用确认页60来要求用户核实其经理或任何直接下属。如图5中所示，确认页60包括一个部分62，部分62确定用户的经理、电子邮箱地址、办事处位置、及对清晰地及不含糊地定义经理有需要或有用的其他信息。同样地，确认页60包括一个部分64，部分64确定用户的所有直接下属或下属，如组织树50(图3)所定义者。

对于每名人员，包括经理及下属，确认页60向用户提供机会说明该用户还在同一位置及/或已经转移到不同位置及/或已经离开组织。以图5中显示的经理为例，用户可以简易地点击一个“完成”(Done)框66，而不需进行其他操作来确认经理。然而，如果该经理已经离开组织，用户可以在点击“完成”(Done)框66之前点击一个框68。该用户也可以利用一个“变换”(Change)框70来拨起另一页(未显示)，使用户可以说明用户的经理的变动或用户的经理的信息的变动。优先选择是不要让用户改变其经理的电子邮箱地址，这是因为确认电子邮件需发送到这个电子邮箱地址给该经理；因此，出于安全原因，用户的经理的电子邮箱地址应由该经理亲自更改。

以部分64中显示的直接下属为例，用户可以说明(例如通过点击一个适当的复选框)该人员还是为用户工作、已经转移到组织内的不同部门或实体、或已经离开组织。点击“完成”(Done)框66，将把这些变更或确认发送到确认系统，以供处理。在许多情况下，如果负责管理确认系统的人员未同意或未接受，确认系统可以储存已说明的变更，但不会对用户资料28中进行更改。无论如何，虽然确认页60中只显示用户的一个经理的一个框62，如果需要，一名用户可以确认更多经理；然而，优先选择是某特定用户的经理中的各个经理被分配到相同的确认团组，但被分配到与该用户所属确认团组不同的确认团组。同样地，可能在许多情况下，某特定用户可能只有一名或没有任何直接下属。然而，一般优先选择是(而且可能在很多情况下要求)每名用户确认至少一名其他用户，不论另一用户(称为“密切相关用户”)是一名经理或一名下属。虽然未显示，点击“完成”(Done)框66也说明该用户还是有效。因此，虽然图5中所示的确认页60不包括一个特定位置供用户确认其本身，只需简易地通过确认或不确认其他密切相关用户来对确认页60作出反应，用户也可确认其本身。当然，如果需要，可以向对确认电子邮件作出反应的用户提供一个特别或个别的确认部分。

一旦用户完成确认页60，在确认系统中，确认用户被标记为已确认或将被确定在该确认期有效。当然，目的在于尽量使确认过程简化，而不会变得使每两个确认期必须完成确认过程一次的用户们混淆或单调乏味。因此，确认页60的设计应考虑用户方便及使用方便。

对响应确认电子邮件的用户所提供的反馈作出反应，确认引擎32更新确认数据库36内的确认数据42，而且，如以上所述，确认引擎32使用该数据库36来确定系统内某用户资料是否有效。

在一个使用户能确认他们本身以及其他用户的实例中，每一份用户记录包括两组合的日期栏位，称为“确认组合1”(VSet 1)及“确认组合2”(VSet 2)。图6显示一个这种用户记录80的例子。在这个例子中，“确认组合1”(VSet 1)及“确认组合2”(VSet 2)中的每一组合包括一个“发送日期”(Sent Date)输入82及一个“接收日期”(Received Date)输入84。在这里，将可了解，图6中所示的用户记录80属于“第2确认团组”(VGrp 2)的一名用户。在这个例子中，每次一个确认电子邮件发送到该用户(属于“第2确认团组”[VGrp 2])时，该日期被记录在“确认组合2”(VSet 2)的“发送日期”(Sent Date)栏位。当该用户对确认电子邮件作出反应时，该日期被记录在“确认组合2”(VSet 2)的“接收日期”(ReceivedDate)栏位。当然，如果该用户属于“第1确认团组”(VGrp 1)，发送日期及接收日期将会被记录在“确认组合1”(VSet 1)的栏位。

同样地，每次一个确认电子邮件发送到属于“第2确认团组”(VGrp 2)的用户的一名密切相关用户(密切相关用户属于“第1确认团组”[VGrp 1])时，该日期被记录在该用户记录的“确认组合1”(VSet 1)的“发送日期”(Sent Date)栏位。当该密切相关用户(属于“第1确认团组”[VGrp 1])通过确认“第2确认团组”(VGrp 2)内的用户，对确认电子邮件作出反应时，该日期被记录在该用户记录的“确认组合1”(VSet 1)的“接收日期”(Received Date)栏位。

照这样，当一个确认电子邮件被发送到属于任何确认团组的用户时，该电子邮件发送对象的用户的记录中的“发送日期”(Sent Date)以及该用户的任何经理及任何直接下属(即：该电子邮件发送对象的用户的任何密切相关用户)的记录被调整为目前日期(即：发送该确认电子邮件的日期)。图7显示这项操作的一个例子，该例子涉及三名密切相关用户，包括一名特定用户90(属于“第2确认团组”[VGrp 2])、该特定用户的一名经理92、及该特定用户的一名下属94(后两者属于“第1确认团组”[VGrp 1])。在图7中所示的例子中，在2006年3月1日向与用户记录90关联的用户(属于“第2确认团组”[VGrp 2])发送确认电子邮件，使得经理记录92、用户记录90及直接下属记录94中每一记录的“确认组合2”(VSet 2)中的“发送日期”(Sent Date)被调整为2006年3月1日。当与用户记录90关联的用户(属于“第2确认团组”[VGrp 2])为其本身、经理92及直接下属94完成确认过程时，用户记录90、经理记录92及直接下属记录94中每一记录的“确认组合2”(VSet 2)中的相应“接收日期”(Received Date)栏位被更新为当时的日期。图8显示这项操作，其中属于“第2确认团组”(VGrp2)、与用户记录90关联的用户在2006年3月7日对2006年3月1日的确认电子邮件作出反应，因此确定经理92及直接下属94的记录。如果该用户90没有确认经理92及/或直接下属94中的一名或两名，经理记录92及/或直接下属记录94的“确认组合2”(VSet 2)中的“接收日期”(ReceivedDate)栏位将不会填上2006年3月7日的日期。同样地，如果与用户记录90关联的用户完全没有对确认电子邮件作出反应，则图8中所示的“确认组合2”(VSet 2)记录中的所有“接收日期”(Received Date)栏位将不会被调整或重新调整。

应该理解，当确认电子邮件被发送到属于“第1确认团组”(VGrp 1)的用户时，发生一种类似的操作，因此这些用户的记录及他们的密切相关用户的记录的“确认组合1”(VSet 1)栏位中的“发送日期”(Sent Date)将被调整为该确认电子邮件的发送日期。同样地，属于“第1确认团组”(VGrp1)的用户对确认电子邮件作出反应，将使得这些用户的记录及他们确认的密切相关用户记录中的“确认组合1”(VSet 1)栏位中的“接收日期”(ReceivedDate)被调整为响应日期。

其后，当任何用户登录到局域网(LAN)12(图1)上的组织内部网络或通过(例如：互联网、外部网络、等等)访问系统或门户24时，确认系统可以轻易地通过检查用户记录的“确认组合1”(VSet 1)及“确认组合2”(VSet 2)栏位中的“发送日期”(Sent Dates)及“接收日期”(ReceivedDates)来确定用户当时的确认状况。一般而言，任何特定用户要被确定为一名有效用户，其记录的两个“确认组合”(VSets)的栏位必须有效。在一个实例中，确认引擎34可以应用三个规则来确定某特定用户的“确认组合”(VSet)数据是否有效。明确地说，确认引擎34确定：(1)“接收日期”(Received Date)是否比“发送日期”(Sent Date)大(更新近)。如果是，则该用户有效。然而，如果上述(1)并不正确，则确认引擎34确定：(2)当日日期是否属于“确认组合”(VSet)的确认期的范围之内(即：“发送日期”[Sent Date]加两周)。如果是，该用户还是被确定为有效，这是由于该用户(或该用户的密切相关用户其中之一)还有时间回复最新近的确认电子邮件。(3)此外，如果某特定“确认组合”(VSet)栏位中无日期(这意谓该用户刚被添加为用户资料)，确认引擎34可以确定该用户为一名有效用户。一般而言，如果某特定用户记录的“确认组合”(VSet)栏位中与“确认团组”(VGrp)匹配(“第2确认团组”[VGrp 2]的“确认组合2”[VSet 2])的数据无效，则该用户将不会接收另一确认电子邮件，而且将被拒绝访问门户24中的应用程序。如果“确认团组”(VGrp)的其他“确认组合”(VSet)栏位(“第2确认团组”[VGrp 2]的“确认组合1”[VSet1])的数据无效，则该用户将被拒绝访问门户24中的应用程序，但将收到一个确认电子邮件。然而，如果需要，用户可在任何时间完成确认过程，并藉以即时为其本身及一名或更多密切相关用户恢复访问权。

“确认组合(VSet)确认期”可以通过添加确认期的长度(由组织确定)到“确认组合”(VSet)栏位的“发送日期”(Sent Date)来确定。在本讨论中，确认期为两周。因此，如果某“确认组合”(VSet)栏位的“发送日期”(Sent Date)是2006年6月2日，则该“确认组合”(VSet)栏位的“确认期”是从2006年6月2日到2006年6月16日。“确认组合(VSet)确认期”将保持不变，直到该用户或一名密切相关用户确认该“确认组合”(VSet)栏位及该用户接收一个新的确认电子邮件，藉而重新调整该“确认组合”(VSet)栏位的“发送日期”(Sent Date)为止。当然，确认期可以以其他方式确定。在所有这些例子中，系统通过检查“接收日期”(ReceivedDate)是不是在“发送日期”(Sent Date)后的一个特定范围内来确定有效性状况(特定期限的定义，可以以某特定日期[如月份中的首日]为基准，该特定日期定义一个确认期的开始，不论确认请求何时发送；或以发送确认请求的“发送日期”[Sent Date]为基准)。

图9-11显示三个特别例子，这些例子说明确认引擎34如何能够使用三个密切相关用户的用户记录90、92及94内的日期栏位，以根据这些数据来定义一份用户资料是否有效。在图9中所示的例子中，上一个确认期是从2006年2月15日到2006年2月28日。确认电子邮件在2006年2月15日被发送到属于“第1确认团组”(VGrp 1)的用户(即：发送到经理记录92的有关经理及发送到直接下属记录94的有关下属)。属于“第1确认团组”(VGrp 1)的用户最迟必须在2006年2月28日完成确认过程。在这个例子中，经理92在2006年2月19日回复，而直接下属94在2006年2月23日回复。此外，用户90(属于“第2确认团组”[VGrp 2])的“确认组合1”(VSet 1)栏位中的“接收日期”(Received Date)被调整为2006年2月23日，说明用户的直接下属94在2006年2月23日确认该用户。然而，在这个例子中，经理92也在2006年2月19日确认该用户90，但这个日期在直接下属94确认该用户90时被重写为2006年2月23日。

此外，在这个例子中，目前的确认期是从3月1日到3月14日。至“第2确认团组”(VGrp 2)的用户的确认电子邮件在2006年3月1日发送，而属于“第2确认团组”(VGrp 2)的用户90最迟必须在3月15日完成确认，以防止其账户及经理的账户92及任何直接下属的账户94被中止。在这里，图9中所示的每名用户(即：经理92、用户90及直接下属94)将被确定为有效用户。明确地说，如果用户的经理及直接下属已经完成上一确认期的确认过程(如“确认组合1”[VSet 1]栏位所示)，而该用户在下一确认期开始之前完成确认过程，某用户90保持有效。同样地，虽然“确认组合2”(VSet 2)栏位的接收日期(Received Dates)未设定，但还是在目前的确认期内，这就是说用户90最迟必须在3月15日对在2006年3月1日向用户90发送的确认电子邮件作出反应。

图10显示与2006年4月3日一名无效用户的账户相关的一个数据库情况。注意用户90、92及94中的每一名用户的“确认组合1”(VSet 1)栏位都有效。然而，用户90、92及94中的任何一名用户的“确认组合2”(VSet2)栏位都是无效，这是因为其“接收日期”(Received Date)比其“发送日期”(Sent Date)早，并且其目前日期不在“确认组合2”(VSet 2)的确认期的范围内，即，4月3日不在3月15日和3月29日之间。相反地，图11描述一个显示一组合有效用户账户的例子。即使“确认组合2”(VSet2)的“接收日期”(Received Date)在其“发送日期”(Sent Date)之前，两个“确认组合”(VSets)还是有效，这是由于其“发送日期”(Sent Date)在目前的确认期的范围内，即3月1日在3月1日和3月15日之间。因此，属于“第2确认团组”(VGrp 2)的该用户在账户被视为无效之前，最迟可在3月15日进行确认。

将可了解，在有些情况下，某一特定用户可以有多名密切相关用户。既然这样，一个单一密切相关用户在该特定用户没有收到确认电子邮件的确认期内确认该用户，便已足够。因此，需要在非确认期被确认的用户可以只需要由一名单一的密切相关用户确定，便可保持有效。然而，如果需要，以及为了提供更多安全性，确认引擎34可以被设置要求某一特定用户的每一密切相关用户确认该特定用户，以保持该特定用户有效，或确认引擎34可以应用一个投票方案(如三分之二、五分之三等投票方案)来确定密切相关用户的响应是否足以保持该特定用户有效。

在有些情况下，例如在某一用户离开或该用户的经理依赖该用户确认时(这种情况可以在经理的一个单一直接下属离开时发生)，该系统可以在发现终止或转移时，自动地为该用户离开时的确认期确认该经理。典型地，任何密切相关用户(例如：即使是一名直接下属)对一名经理的一个单一“终止”将造成该经理被中止，直到该经理可以同意或不同意该“终止”为止。如果该经理已经离开组织，系统会在一个预定时限后将其中止状况更改为终止。

这里描述的系统为每一用户、经理及直接下属使用一个企业电子邮箱地址，因此，在一个实例中，该系统不依赖或使用公共域内的电子邮箱地址；假如其他安全保障(如适当的放火墙、登录程序、等等)更好地实施来防止系统被欺骗，则这些公共域的电子邮箱地址可以被使用。

除了执行初始的用户确认，如以上所述，用户确认系统可以用于控制及更新用户资料，以根据用户资料内的信息提供对一个或更多应用程序18及18A的不同访问权次级。明确地说，如果没有一贯的资料变更审查及执行对安全应用程序内的用户安全设定的更新，适当级别的安全性一般只是最初在系统内设置用户资料时有效。然而，组织内可以发生很多事件，这些事件将会导致用户资料的变更，因而可能导致对可通过组织资源获得的特定应用程序的有关访问权的变更。例如，对敏感销售信息的访问权可能对所有直接雇员开放，但可能对与组织相关的附属公司的雇员实施限制。然而，如果一名雇员转移到该附属公司，则其雇员状况应更改，以在保持该雇员对其他应用程序或特定应用程序的设置的访问权同时防止其访问销售信息。作为另一例子，对会计策略的访问权可能对所有涉及会计工作的销售人员开放，但可能对所有其他销售人员实施限制。如果一名销售人员在组织中变动角色而且不再负责某一特定账户的工作，则该人员不应访问有关账户信息。作为另一例子，产品培训可能对某些部门开放，但可能对那些有竞争性产品的第三方代表的部门实施限制。然而，如果一名雇员变更部门，该雇员应被防止访问产品培训应用程序。

一般而言，在过去，所有这些变更及许多可能在组织内发生的变更将会更好地引发应用程序管理员进行审查，应用程序管理员将会决定是否为经历位置变更的用户更改安全设定。然而，不幸的是，在许多情况下，这种审查完全没有发生或没有及时发生。用户资料变更未被注意的主要原因是因为应用程序的拥有者依赖组织内的一个或许多部门(如人力资源部门)来通知他们有关用户资料的变更。在许多时间，这个通知没有发生或没有很快地发生，而且其他时间负责这项工作的部门可能位于(例如)一个第三世界国家的一个附属公司的办事处，这样可能造成操作有些不可靠。因此，在许多情况下，由于多种原因，因组织内的变更而动用一个或更多部门来人工地更新用户资料及通知应用程序拥有者，是不可靠的。

为了克服或简化这个难题，用户可以通过确认电子邮件的链接或在任何其他时间使用门户24内的资料管理系统来更新其资料。此外，用户可以藉说明一个密切相关用户的转移来更新其资料。这个更新过程包括但不限于终止一名经理或一名直接下属。在这种情况下，被终止的用户可以即时被中止访问门户24及门户24内的应用程序或经由门户24访问应用程序。然而，如果需要，确认系统可以被设置来提示及/或只在用户资料中的特定栏位变更时更新外部应用程序，而不是在任何栏位变更时便发送通知。这些特定栏位可以被选择为应由一名应用程序管理员审查其变更的栏位，如果需要，应用程序管理员可以根据变更来更新该特定用户的安全设定。

因此，这里描述的确认系统也可以用于更新用户资料信息，以在组织内发生变更时，使得或容许各类用户能有多种应用程序的访问权。明确地说，如以上关于图1的讨论，用户确认系统维护每名用户的信息(即：姓名、公司、部门、电子邮箱地址、头衔、经理、等等)作为用户资料的部分，而图5中所示的确认页60可以使每名用户能为其本身及其他密切相关用户改动或更新这些信息。然而，在有些情况下，用户资料的变更可以在被实施之前提交予一名经理或其他人员以供审查，藉以确保用户授予其本身的访问权不超过其应得的访问权，或防止其他用户被无意或刻意的锁定(如被不满的雇员)在系统之外。

虽然这里描述的用户资料信息局部地被储存于门户24，但这些信息也可以或还可以通过各种通信方案(包括直接数据库通信、基于XML[可扩展标识语言]及URL[统一资源定位器]的通信，等等)，实时地分布到门户24内的应用程序18A。因而，外部应用程序18A及18能够采取任何被认为对事件适当的行动。在这些情况下，门户24只是确定用户是否应被允许访问一个应用程序18A或18，而且，可能由应用程序18A或18根据用户资料或储存于应用程序18A或18的其他信息来确定该用户的访问权级别或该用户可浏览的内容。

此外，由于这里描述的用户确定及资料管理系统跟踪每名用户的经理及直接下属的信息，所以该系统能在任何时间根据用户资料及定义的“确认团组”(VGrps)来绘制准确的组织树。图12描述一个这种组织树100的例子。报告结构内的变更可以在确认过程中或在任何时间，通过(例如)门户24的主页的一个“组织信息”(Organization Information)输入作出。然而，该系统可以在作出组织变更之前制定一个等候期，以防止不满或无道德雇员之间的勾结；不满或无道德的雇员可能通过创建他们与另一用户之间的链接试图欺骗确认系统。例如，在准许实施变更组织信息之前，该系统可以要求有关用户及该用户的前经理同意拟议的重组。任何涉及的用户可以不同意有关变更。最后，在这个例子中，一名门户管理员可以审查该要求并作出批准或不批准有关变更的决定。无论如何，在一名用户从一名经理转移到另一名经理或在组织中作出一些其他变更时，该系统可以自动地重新计算组织树100。由于所有涉及转移的人员在过程中有权选择终止该用户或经理，这种事件意味确定。因此，如果需要，该系统可以在这个过程中确认正被转移的用户以及该用户的经理。

虽然这里描述的确认过程使用两个确认团组及两组合的确认日期-“确认组合1”(VSet 1)及“确认组合2”(VSet 2)，每一用户记录的两个确认组合各有一个“发送日期”(Sent Date)及一个“接收日期”(Received Date)，该系统可以设计为有更多确认团组及日期组合。作为一个例子，如以下所述，可以使用三个确认团组及日期组合，其中确认期为两周。

如以上所述，确认系统适当地分配每名用户到正确的确认团组，确认团组用于确定用户何时应接收确认电子邮件。在这个例子中，用户将被分配到三个确认团组的其中一个团组，即“第1确认团组”(VGrp 1)、“第2确认团组”(VGrp 2)及“第3确认团组”(VGrp 3)。这些确认团组的计算，是根据最初在注册时采集的及在其后由确认过程本身采集的、或用户作出的资料更新而采集的用户/经理关系信息，通过建立一个层次树进行的。一旦建立了组织树，可以通过应用以下逻辑来确定“确认团组”(VGrps)：(1)不是经理(没有直接下属)的用户被分配到“第1确认团组”(VGrp1)；

(2)是经理(有至少一名直接下属)的用户被分配到“第2确认团组”(VGrp2)；以及

(3)“第2确认团组”(VGrp 2)的经理们被检查-从组织树的最下层开始，如果“第2确认团组”(VGrp 2)的某名经理没有至少一名在“第1确认团组”(VGrp 1)的直接下属，则该经理被分配到“第3确认团组”(VGrp 3)。随着该系统在组织树向上移动到另一层次，该系统修改对该“第2确认团组”(VGrp 2)经理的检查-如果某“第2确认团组”(VGrp 2)经理没有至少一名在“第1确认团组”(VGrp 1)或“第3确认团组”(VGrp 3)的直接下属，则该经理被分配到“第3确认团组”(VGrp 3)。

图13显示一个组织层次树110，组织层次树110在实施前述的前两个步骤后完成，在前述的前两个步骤中，确定了一个初始组合的“第1确认团组”(VGrp 1)及“第2确认团组”(VGrp 2)用户。图14显示在应用前述第三个步骤重新定义某些“第2确认团组”(VGrp 2)经理为“第3确认团组”(VGrp 3)经理后的同一个组织层次树110。应用前述第三个步骤的原因，是为了确保每名用户在组织层次树110上至少有一名与其直接连接、属于另一不同确认团组的其他用户。实质上，组织层次树110上的每名经理必须至少有一名被分配到电子邮件定时相反的一个确认团组的直接下属。照这样，在组织层次树110上连接并负责相互确认的两名人员将绝不会在同一时间(在同一确认期)接收确认电子邮件，而且，任何特定用户在一个四周期间(或每两个确认期)将绝不会接收电子邮件超过一次。如果在组织层次树110上相互直接连接的两名用户还是在同一确认团组内(如图14中的用户112及114)，则他们将不需要相互确认，这是由于还有其他属于不同确认团组(“第1确认团组”[VGrp 1]或“第3确认团组”[VGrp 3])的用户与用户112及114直接连接，而且这些用户可以提供确认功能。

以一种与上述涉及两个确认团组的实例稍微不同的方式，一个确认电子邮件在每个确认期被发送到“第1确认团组”(VGrp 1)及“第3确认团组”(VGrp 3)的用户或“第2确认团组”(VGrp 2)的用户，目标团组在每个确认期交替。这里，确认电子邮件在同一时间被发送到“第1确认团组”(VGrp1)及“第3确认团组”(VGrp 3)的用户，因此该两个确认团组逻辑上可以被视为同一团组。这个特征用于确保在组织层次树上连接的两名用户绝不会在同一确认期接收确认电子邮件。例如，如果确认电子邮件在1月2日被发送到“第1确认团组”(VGrp 1)及“第3确认团组”(VGrp 3)，则确认电子邮件将在1月16日被发送到“第2确认团组”(VGrp 2)，而确认电子邮件将又会在1月30日被发送到“第1确认团组”(VGrp 1)及“第3确认团组”(VGrp 3)，等等。

这里，确认系统要求被分配到“第1确认团组”(VGrp 1)(直接下属)的每名用户确认在组织树110上的直接在其上方与其连接的用户。被分配到“第2确认团组”(VGrp 2)(经理)的每名用户被要求确认在组织树110上的直接在其上方及下方与其连接的用户。因此，当一名用户完成确认时，其实质上已经为当时的确认期确认其本身、其经理、及任何直接下属。此外，在涉及两个确认团组的例子中，任何特定用户在每两个确认期内将绝不会接收确认电子邮件超过一次。此外，由于属于一个确认团组的用户确认直接在其上方及/或其下方的确认团组的用户，每名用户在每四周时期(2个确认期)内被确认两次，但只接收一个确认电子邮件。

如描述本例子的图15中所示，每份用户记录120有三组合的确认日期栏位122-称为“确认组合1”(VSet 1)、“确认组合2”(VSet 2)、及“本身日期”(Self Date)。如图15中所示，每组合的确认栏位122包含一个“发送日期”(Sent Date)及一个“接收日期”(Received Date)。应该理解，“确认组合”(VSets)链接在组织树110上相互直接连接的用户(即：密切相关用户)之间。当一个日期被分配到一份用户记录的一个“确认组合”(VSet)时，连接的用户记录中的链接日期也被分配同一日期。例如，在每次一个确认电子邮件被发送到属于“第1确认团组”(VGrp 1)的一名成员时，该用户的记录及该用户的经理的记录的“确认组合1”(VSet 1)日期栏位中的“发送日期”(Sent Dates)被调整为当时日期。“本身日期”(SelfDate)栏位不用于“第1确认团组”(VGrp 1)的用户。图16显示这项操作的一个例子，涉及一份直接下属记录130(属于“第1确认团组”[VGrp 1])及一份经理记录132(属于“第2确认团组”[VGrp 2])。

此外，每次一个确认电子邮件被发送到属于“第2确认团组”(VGrp 2)或“第3确认团组”(VGrp 3)的一名成员时，该用户的记录、该用户的直接下属的记录、及该用户的经理的记录的“确认组合2”(VSet 2)日期栏位中的“日期对”被调整为当时日期。图17显示这项操作的一个例子，涉及图16中所示的相同用户记录130及132。此外，对于“第2确认团组”(VGrp 2)及“第3确认团组”(VGrp 3)，如图17中所示，经理记录132的“本身日期”(Self Date)“日期对”中的“发送日期”(Sent Date)被调整为当时日期。当一名用户完成确认过程时，链接用户的相应“接收日期”(Received Dates)被更新为当时的日期。

在这个例子中，“确认组合”(VSets)的日期分配可以概括为以下规则：

(1)确认电子邮件总是在同一日期被发送到“第1确认团组”(VGrp 1)及“第3确认团组”(VGrp 3)。

(2)当“第1确认团组”(VGrp 1)的用户接收确认电子邮件时，“确认组合1”(VSet 1)的“发送日期”(Sent Date)被设定为当时日期(“确认组合1”[VSet 1]的“发送日期”[Sent Dates]链接在密切相关用户之间)。

(3)当“第2确认团组”(VGrp 2)或“第3确认团组”(VGrp 3)的用户接收确认电子邮件时，“确认组合2”(VSet 2)的“发送日期”(SentDate)被设定为当时日期。“第2确认团组”(VGrp 2)及“第3确认团组”(VGrp 3)可以被视为“经理”团组，这些团组中的用户总是至少有一名直接下属(“确认组合2”[VSet 2]的“发送日期”[Sent Dates]链接在密切相关用户之间)。

(4)当“第2确认团组”(VGrp 2)或“第3确认团组”(VGrp 3)的用户接收确认电子邮件时，“本身发送日期”(Sent Self Date)被设定为当时日期。该“本身发送日期”(Sent Self Date)没有与任何其他团组的“本身发送日期”(Sent Self Date)链接，而且只是接收确认电子邮件的用户被设定“本身发送日期”(Sent Self Date)。

(5)“第1确认团组”(VGrp 1)的用户绝对不被设定“本身日期”(SelfDates)。

(6)当“第1确认团组”(VGrp 1)的一名用户确认时，“第1确认团组”(VGrp 1)及“第2确认团组”(VGrp 2)被设定链接的“确认组合1”(VSet 1)“接收日期”(Received Dates)。

(7)当“第2确认团组”(VGrp 2)的一名用户确认时，“第1确认团组”(VGrp 1)、“第2确认团组”(VGrp 2)、及“第3确认团组”(VGrp 3)被设定链接的“确认组合2”(VSet 2)“接收日期”(ReceivedDates)。

(8)当“第3确认团组”(VGrp 3)的一名用户确认时，“第3确认团组”(VGrp 3)及“第2确认团组”(VGrp 2)被设定链接的“确认组合2”(VSet 2)“接收日期”(Received Dates)。

(9)如果一名用户没有完成确认，其将不会接收新的确认电子邮件，直到其完成确认为止。

(10)即使是一名无效用户，链接的“确认组合日期”(VSet Dates)将总是会被更新。

(11)当“第2确认团组”(VGrp 2)或“第3确认团组”(VGrp 3)的一名用户确认时，“本身接收日期”(Received Self Date)被设定。“本身日期”(Self Dates)没有链接在“确认团组”(VGrps)之间。

利用这个设置，当一名用户登录时，确认系统可以轻易地通过检查用户记录的“确认组合1”(VSet 1)、“确认组合2”(VSet 2)、及“本身日期”(Self Date)栏位中的“发送日期”(Sent Dates)及“接收日期”(ReceivedDates)来确定该用户当时的确认状况。所有日期团组必须是有效，该用户才是有效。这里，如果以下三条规则中的任何规则为正确，则确认引擎34可以确定某“确认组合”(VSet)栏位有效：

(1)“接收日期”(Received Date)是否比“发送日期”(Sent Date)大(更新近)；

(2)如果(1)的答案为否，但当日日期在“确认组合”(VSet)的确认期的范围之内(即：“发送日期”[Sent Date]加上两周)；或

(3)“发送日期”(Sent Date)栏位及“接收日期”(Received Date)栏位中是否都没有日期。

如果某一特定用户记录中与有关“确认团组”(VGroup)匹配的“确认组合”(VSet)栏位(“第2确认团组”[VGrp 2]的“确认组合2”[VSet 2])内的数据为无效，则该用户将不会接收另一确认电子邮件，而且将被拒绝访问门户24中的应用程序。如果有关“确认团组”(VGroup)的其他“确认组合”(VSet)栏位(“第2确认团组”[VGrp 2]的“确认组合1”[VSet 1])内的数据无效，则该用户将被拒绝访问门户24中的应用程序，但将接收一个确认电子邮件。

作为一个例子，图18显示一份经理记录(“第3确认团组”[VGrp 3])140、一份经理记录(“第2确认团组”[VGrp 2])142、及一份直接下属记录(“第1确认团组”[VGrp 1])144，这些记录将会在第一确认周期显示。该确认期从2006年2月24日开始。确认电子邮件在这个日期被发送到“第1确认团组”(VGrp 1)及“第3确认团组”(VGrp 3)。图18中的箭头145显示“第1确认团组”(VGrp 1)及“第2确认团组”(VGrp 2)的“确认组合1”(VSet 1)栏位中的“发送日期”(Sent Dates)之间的链接、以及“第3确认团组”(VGrp 3)及“第2确认团组”(VGrp 2)的“确认组合2”(VSet 2)栏位中的“发送日期”(Sent Dates)之间的链接。“第3确认团组”(VGrp 3)的用户的“本身发送日期”(Sent Self Date)也被设定为2月24日。此外，如图18中所示，用户144在2006年3月3日确认了其本身，还确认了密切相关用户142。箭头146显示记录144及142中的“确认组合1”(VSet 1)栏位的确认。

如果确认期为两周，则下一组合的确认电子邮件在2006年3月10日被发送到“第2确认团组”(VGrp 2)。图19显示在确认电子邮件在该日期被发送时将会显示的用户记录-假设“第1确认团组”(VGrp 1)的该用户在2006年3月3日确认。“第1确认团组”(VGrp 1)及“第2确认团组”(VGrp 2)的“确认组合1”(VSet 1)栏位中的链接“接收日期”(ReceivedDates)(以箭头146显示)反映用户144对经理142的确认。如图19中所示的同样方式，“第2确认团组”(VGrp 2)记录142中“确认组合2”(VSet2)栏位的“发送日期”(Sent Date)与其下方的“第1确认团组”(VGrp1)记录144及其上方的“第3确认团组”(VGrp 3)记录140中的“确认组合2”(VSet 2)栏位中的“发送日期”(Sent Dates)链接。现在，用户140、142及144在3月10日到3月24日(即：2006年3月24日之前)的确认期间的确认状况可以概括如下：

(1)“第3确认团组”(VGrp 3)的用户＝无效，因为“本身接收日期”(SelfReceived Date)为空白，而且“本身发送日期”(Self Sent Date)不在当时的确认期(3月10日到3月24日)的范围之内；

(2)“第2确认团组”(VGrp 2)的用户＝有效，因为根据前述三条确认规则，记录142的所有“确认组合”(VSets)的数据有效；以及

(3)“第1确认团组”(VGrp 1)的用户＝有效，因为根据前述三条确认规则，记录144的所有“确认组合”(VSets)的数据有效。

现在，在这个例子中，如图20中所示，下一组合的确认电子邮件将在2006年3月24日被发送到“第1确认团组”(VGrp 1)及“第3确认团组”(VGrp 3)。假设“第2确认团组”(VGrp 2)的用户142在2006年3月21日确认了其本身、经理140及直接下属144-如图20中的箭头148以及用户记录142的“本身日期”(Self Date)栏位中的“接收日期”(Received Date)所示。如可观察到者，“第1确认团组”(VGrp 1)、“第2确认团组”(VGrp2)、及“第3确认团组”(VGrp 3)中“确认组合2”(VSet 2)栏位中的“接收日期”(Received Dates)全部链接，而且已被更新为2006年3月21日。此外，“第2确认团组”(VGrp 2)的用户142的记录的“本身接收日期”(Received Self Date)被调整为2006年3月21日。必须注意的是，第3确认团组”(VGrp 3)的用户140在该确认期内并没有接收任何确定电子邮件。这是由于该用户的账户现在已经无效-因为该用户在2006年2月24日到2006年3月10日的确定期内还未确定，如记录140的“本身日期”(SelfDate)的“接收日期”(Received Date)栏位内的空白显示所示的那样。因此，“第3确认团组”(VGrp 3)及“第2确认团组”(VGrp 2)中“确认组合2”(VSet 2)栏位中的“发送日期”(Sent Dates)保持为2006年3月10日。该“本身接收日期”(Received Self Date)并不大于“本身发送日期”(Sent Self Date)，而且当日(3月26日)在2月24日到3月10日的确认期的范围之外。现在，用户在2006年3月26日的“确认情况”可以概括如下：

(1)“第3确认团组”(VGrp 3)的用户＝无效，因为“本身接收日期”(ReceivedSelf Date)＜“本身发送日期”(Sent Self Date)，而且当日(3月26日)在开始自“本身发送日期”(Self Sent Date)的确认期(2月24日到3月10日)的范围之外；

(2)“第2确认团组”(VGrp 2)的用户＝有效，因为根据前述三条确认规则，所有“确认组合”(VSets)的数据都有效；以及

(3)“第1确认团组”(VGrp 1)的用户＝有效，因为根据前述三条确认规则，所有“确认组合”(VSets)的数据都有效。

在这个例子之后，如图21中所示，下一组合的确认电子邮件将在2006年4月7日被发送到“第2确认团组”(VGrp 2)的用户142。这里，箭头149显示“第1确认团组”(VGrp 1)的用户144在2006年4月4日确认了用户142。即使“第3确认团组”(VGrp 3)无效，“第3确认团组”(VGrp3)中“确认组合2”(VSet 2)栏位的“发送日期”(Sent Date)被更新，这是由于该日期与“第2确认团组”(VGrp 2)中“确认组合2”(VSet 2)栏位的“发送日期”(Sent Date)链接。“本身日期”(Self Date)保持为2006年2月24日。现在，用户140、142及144中每名用户在2006年4月11日的“用户状况”可以概括如下：

(1)“第3确认团组”(VGrp 3)的用户＝无效，因为

“确认组合2”(VSet 2)：“接收日期”(Received Date)＞“发送日期”(Sent Date)；

“本身日期”(Self Date)：“本身接收日期”(Received Self Date)＜“本身发送日期”(Sent Self Date)，而且当日(4月11日)在开始自“本身发送日期”(Self Sent Date)的确认期(2月24日到3月10日)的范围之外；

(2)“第2确认团组”(VGrp 2)的用户＝有效，因为

“确认组合1”(VSet 1)：“接收日期”(Received Date)＞“发送日期”(Sent Date)；

“确认组合2”(VSet 2)：“接收日期”(Received Date)＜“发送日期”(Sent Date)，但当日(4月11日)在该“确认组合”(VSet)的确认期(4月7日到4月21日)的范围之内；以及

“本身日期”(Self Date)：“接收日期”(Self Date)＞“发送日期”(Sent Date)；

(3)“第1确认团组”(VGrp 1)的用户＝有效，因为

“确认组合1”(VSet 1)：“接收日期”(Received Date)＞“发送日(Sent Date)；以及

“确认组合2”(VSet 2)：“接收日期”(Received Date)＜“发送日期”(Sent Date)，但当日(4月11日)在该“确认组合”(VSet)的确认期(4月7日到4月21日)的范围之内。

当然，如以上所述，任何用户只有在下一确认期开始之前完成确认过程，该用户才可以保持有效。如果没有在下一确认期开始之前完成确认过程，则会造成该用户的账户、甚至其经理的账户、及/或其直接下属的账户变成无效，这意谓他们不再拥有对门户24、或门户24内的应用程序18A、或由其管理的应用程序18的访问权。无效的用户可以在任何时间完成确认过程，藉而即时恢复其本身、其经理及其所有直接下属的访问权。

虽然以上文字详细描述本发明的多种不同实例，但应明白：本发明的范围由本发明结尾篇章的权利要求的文字限定。以上详细描述仅应被解释为范例而已，而且并未描述本发明的每一可能实例，这是由于描述每一可能实例即使不是不可能，也将会是不切实际的。应用目前的技术、或应用在本发明提交日期之后开发的技术，可以实施许多替代性的实例，这些替代性实例将还是属于限定本发明的权利要求的范围。

因此，可以在不脱离本发明的精神和范围的情况下，对这里描述及图解的技术及结构进行许多修改及变更。因此，应明白：这里描述的各种方法及设备只是原理性的方法及设备，而且并未限制本发明的范围。

Claims

1.一种在计算机网络内电子地确定多个用户状况的方法，这种方法包括：

储存对计算机网络有访问权的第一用户和第二用户中的每一用户的状况表示，所述第一用户和第二用户中的每一特定用户的所述状况表示包括所述特定用户的资料信息，该资料信息表示所述特定用户拥有的、对可经由所述计算机网络获得的一个或更多应用程序的访问权；

分配第一用户到第一用户组合及分配第二用户到第二用户组合；以及

自动及定期地发送第一电子确认请求到第一用户组合内的第一用户，要求第一用户对第一电子确认请求作出反应，以确认第二用户的状况；

根据接收第一用户对第一电子确认请求的响应，确定第二用户的状况表示的有效性；

自动及定期地发送第二电子确认请求到第二用户组合内的第二用户，要求第二用户对第二电子确认请求作出反应，以确认第一用户的状况；

根据接收第二用户对第二电子确认请求的响应，确定第一用户的状况表示的有效性；

根据确定所述第一用户的状况表示的有效性，确定是否向所述第一用户提供对可经由所述计算机网络获得的所述一个或更多应用程序的访问权；以及

根据确定所述第二用户的状况表示的有效性，确定是否向所述第二用户提供对可经由所述计算机网络获得的所述一个或更多应用程序的访问权。

2.如权利要求1中所述的电子地确定多个用户状况的方法，包括：以交互的方式，在不同时间发送第一及第二电子确认请求。

3.如权利要求1中所述的电子地确定多个用户状况的方法，其中第一用户是第二用户的一名经理或一名直接下属。

4.如权利要求1中所述的电子地确定多个用户状况的方法，其中“根据接收第一用户对第一电子确认请求的响应，确定第二用户的状况表示的有效性”包括：确定第一用户对第一电子确认请求的响应是不是在与第一电子确认请求相关的一个预定期限内发送。

5.如权利要求1中所述的电子地确定多个用户状况的方法，其中“根据接收第二用户对第二电子确认请求的响应，确定第一用户的状况表示的有效性”包括：确定第二用户对第二电子确认请求的响应是不是在与第二电子确认请求相关的一个第二预定期限内发送。

6.如权利要求1中所述的电子地确定多个用户状况的方法，其中“发送第一电子确认请求到第一用户”包括：发送第二用户的状况表示、作为第一电子确认请求的部分，以及其中“根据接收第一用户对第一电子确认请求的响应，确定第二用户的状况表示的有效性”包括：确定第一用户是否同意在第一用户对第一电子确认请求的响应内发送的第二用户的状况表示。

7.如权利要求1中所述的电子地确定多个用户状况的方法，其中“发送第二电子确认请求到第二用户”包括：发送第一用户的状况表示，作为第二电子确认请求的部分，以及其中“根据接收第二用户对第二电子确认请求的响应，确定第一用户的状况表示的有效性”包括：确定第二用户是否同意在第二用户对第二电子确认请求的响应内发送的第一用户的状况表示。

8.如权利要求1中所述的电子地确定多个用户状况的方法，这种方法进一步包括：根据接收第一用户对第一电子确认请求的响应，确定第一用户的状况表示的有效性。

9.如权利要求1中所述的电子地确定多个用户状况的方法，这种方法进一步包括：根据接收第二用户对第二电子确认请求的响应，确定第二用户的状况表示的有效性。

10.如权利要求1中所述的电子地确定多个用户状况的方法，这种方法包括：定期地以相同的周期率发送第一电子确认请求及第二电子确认请求，但发送第一电子确认请求与发送第二电子确认请求的时间间隔大约为周期率期限的一半。

11.如权利要求1中所述的电子地确定多个用户状况的方法，这种方法包括：为第一用户创建一个第一储存栏位及为第二用户创建一个第二储存栏位，在第一及第二储存栏位储存对第一及第二电子确认请求的响应的表示，以及根据储存于第一储存栏位的信息确定第一用户在任何特定时间的状况表示的有效性，及根据储存于第二储存栏位的信息确定第二用户在任何特定时间的状况表示的有效性。

12.如权利要求11中所述的电子地确定多个用户状况的方法，其中“在第一及第二储存栏位储存对第一及第二电子确认请求的响应的表示”包括：在第一储存栏位内的一个第一储存位置储存有关第二电子确认请求何时被发送到第二用户的表示，及在第一储存栏位内的一个第二储存位置储存有关对第二电子确认请求的响应何时被接收的表示。

13.如权利要求11中所述的电子地确定多个用户状况的方法，其中“根据储存于第一储存栏位的信息确定第一用户在任何特定时间的状况表示的有效性”包括：确定对第二电子确认请求的响应是不是在相对于第二电子确认请求被发送的时间的一个特定时期内被接收。

14.如权利要求12中所述的电子地确定多个用户状况的方法，这种方法进一步包括：在第一储存栏位的一个第三储存位置储存有关第一电子确认请求何时被发送到第一用户的表示，及在第一储存栏位内的一个第四储存位置储存有关对第一电子确认请求的响应何时被接收的表示。

15.如权利要求14中所述的电子地确定多个用户状况的方法，其中“根据储存于第一储存栏位的信息确定第一用户在任何特定时间的状况表示的有效性”包括：确定对第一电子确认请求的响应是不是在相对于第一电子确认请求被发送的时间的一个特定时期内被接收。

16.如权利要求14中所述的电子地确定多个用户状况的方法，其中“根据储存于第一储存栏位的信息确定第一用户在任何特定时间的状况表示的有效性”包括：确定对第一电子确认请求的响应是不是在相对于第一电子确认请求被发送的时间的一个特定时间长度内被接收，及确定对第二电子确认请求的响应是不是在相对于第二电子确认请求被发送的时间的一个特定时间长度内被接收。

17.如权利要求12中所述的电子地确定多个用户状况的方法，其中“在第一及第二储存栏位储存对第一及第二电子确认请求的响应的表示”包括：在第二储存栏位内的一个第一储存位置储存有关其中一个第一电子确认请求何时被发送到第一用户的表示，及在第二储存栏位内的一个第二储存位置储存有关第一用户对其中一个第一电子确认请求的响应何时被接收的表示，以及包括：在第二储存栏位内的一个第三储存位置储存有关第二电子确认请求何时被发送到第二用户的表示，及在第二储存栏位内的一个第四储存位置储存有关第二用户对第二电子确认请求的响应何时被接收的表示。

18.一种在计算机网络内电子地确定多个用户状况的方法，这种方法包括：

储存对计算机网络有访问权的多名用户中的每一用户的状况表示，所述多名用户中的每一特定用户的所述状况表示包括所述特定用户的资料信息，该资料信息表示所述特定用户拥有的、对可经由所述计算机网络获得的一个或更多应用程序的访问权；

分配多名用户中的每一用户到第一用户组合或第二用户组合；

自动及定期地发送第一电子确认请求到第一用户组合内的一名或更多第一用户，要求第一用户组合内的一名或更多第一用户对第一电子确认请求作出反应，以确认第二用户组合内的至少一名第二用户的状况；

根据接收对第一电子确认请求的一个或更多响应，确定第二用户组合内的至少一名第二用户的状况表示的有效性；

自动及定期地发送第二电子确认请求到第二用户组合内的一名或更多第二用户，要求第二用户组合内的一名或更多第二用户对第二电子确认请求作出反应，以确认第一用户组合内的至少一名第一用户的状况；

根据接收对第二电子确认请求的一个或更多响应、确定第一用户组合内的至少一名第一用户的状况表示的有效性；

根据确定所述至少一名第一用户的状况表示的有效性，针对所述第一用户组合内的至少一名第一用户确定是否向所述至少一名第一用户提供对可经由所述计算机网络获得的所述一个或更多应用程序的访问权；以及

根据确定所述至少一名第二用户的状况表示的有效性，针对所述第二用户组合内的至少一名第二用户确定是否向所述至少一名第二用户提供对可经由所述计算机网络获得的所述一个或更多应用程序的访问权。

19.如权利要求18中所述的电子地确定多个用户状况的方法，这种方法包括：以交互的方式，在不同时间发送第一电子确认请求及发送第二电子确认请求。

20.如权利要求18中所述的电子地确定多个用户状况的方法，其中“根据接收对第一电子确认请求的一个或更多响应，确定其中一名第二用户的状况表示的有效性”包括：确定对第一电子确认请求的一个或更多响应是不是在一个预定期限内发送。

21.如权利要求18中所述的电子地确定多个用户状况的方法，其中“根据接收对第二电子确认请求的一个或更多响应，确定其中一名第一用户的状况表示的有效性”包括：确定对第二电子确认请求的一个或更多响应是不是在一个第二预定期限内发送。

22.如权利要求18中所述的电子地确定多个用户状况的方法，其中“发送第一电子确认请求到第一用户组合内的一名或更多第一用户”包括：发送其中至少一名第二用户的状况表示，作为至少一个第一电子确认请求的部分；而其中“确定至少一名第二用户的状况表示的有效性”包括：确定接收至少一个第一电子确认请求的第一用户是否同意所发送的至少一个第一电子确认请求内的至少一名第二用户的状况表示。

23.如权利要求18中所述的电子地确定多个用户状况的方法，这种方法进一步包括：根据接收其中一名第一用户对向其发送的其中一个第一电子确认请求的响应、确定一名第一用户的状况表示的有效性。

24.如权利要求18中所述的电子地确定多个用户状况的方法，这种方法包括：定期地以相同的周期率发送第一电子确认请求及第二电子确认请求，但发送第一电子确认请求与发送第二电子确认请求的时间间隔大约为周期率期限的一半。

25.如权利要求18中所述的电子地确定多个用户状况的方法，这种方法包括：为多名用户中的每一用户储存有关其对其中一个第一电子确认请求的一个响应的第一响应信息、及有关其对其中一个第二电子确认请求的一个响应的第二响应信息；以及根据在特定时间为特定用户储存的第一及第二响应信息，确定多名用户中的某个特定用户在任何特定时间的状况表示的有效性。

26.如权利要求25中所述的电子地确定多个用户状况的方法，其中“为某个特定用户储存第一响应信息”包括：储存有关其中一个第一电子确认请求何时被发送到其中一名第一用户的表示，以及储存有关其中一名第一用户对其中一个第一电子确认请求的响应何时被接收的表示。

27.如权利要求25中所述的电子地确定多个用户状况的方法，其中“根据第一及第二响应信息，确定多名用户中的某个特定用户在任何特定时间的状况表示的有效性”包括：确定对其中一个第一电子确认请求的响应是不是在相对于其中一个第一电子确认请求被发送的时间的一个特定时期内被接收。

28.如权利要求25中所述的电子地确定多个用户状况的方法，其中“为某个特定用户储存第二响应信息”包括：储存有关其中一个第二电子确认请求何时被发送到其中一名第二用户的表示，以及储存有关其中一名第二用户何时接收对其中一个第二电子确认请求的响应的表示。

29.如权利要求25中所述的电子地确定多个用户状况的方法，其中“根据第一及第二响应信息，确定多名用户中的某个特定用户在任何特定时间的状况表示的有效性”包括：确定对其中一个第二电子确认请求的响应是不是在相对于其中一个第二电子确认请求被发送的时间的一个特定时期内被接收。

30.一种用于计算机网络的用户确认系统，这种用户确认系统包括：

储存器；

储存单元，适合针对对计算机网络有访问权的多个用户中的每一特定用户，在储存器中储存包括所述特定用户的资料信息的状况表示，该资料信息表示所述特定用户拥有的、对可经由所述计算机网络获得的一个或更多应用程序的访问权；

被储存于储存器的表，使多个用户中的每一用户与第一用户组合或第二组合发生联系，以使第一用户在第一用户组合，第二用户在第二用户组合；

确认请求生成器，该确认请求生成器：自动及定期地发送第一电子确认请求到第一用户组合的一名或更多第一用户中的每一第一用户，要求第一用户组合的一名或更多第一用户中的每一第一用户对其中一个第一电子确认请求作出反应，以确认第二用户组合的至少一名第二用户的状况；并自动及定期地发送第二电子确认请求到第二用户组合的一名或更多第二用户中的每一第二用户，要求第二用户组合的一名或更多第二用户中的每一第二用户对其中一个第二电子确认请求作出反应，以确认第一用户组合的至少一名第一用户的状况；

响应单元，适合接收对第一电子确认请求及第二电子确认请求的响应，以及在储存器中储存有关接收对第一电子确认请求及第二电子确认请求的响应的信息的表示；

有效性分析器，适合根据储存的有关接收多名用户中的至少一名用户对第一电子确认请求及第二电子确认请求的响应的信息，来确定多名用户中的至少一名用户的状况表示的有效性；以及

访问门户，适合根据有效性分析器对任何特定用户的状况表示的有效性的确定，允许或拒绝多名用户中的任何特定用户经由计算机网络访问一个或更多应用程序的权利。

31.如权利要求30中所述的用户确认系统，其中确认请求生成器：在许多连续的确认期中的每个确认期内生成并发送第一电子确认请求至少一次，并且在许多连续的确认期中的每个确认期内生成和发送第二电子确认请求至少一次；其中确认请求生成器发送第一电子确认请求与发送第二电子确认请求的时间间隔大约为周期率期限的一半。

32.如权利要求30中所述的用户确认系统，其中确认请求生成器：在不同时间生成和发送第一电子确认请求及第二电子确认请求。

33.如权利要求30中所述的用户确认系统，其中储存器包括：每一用户的响应信息栏位；以及其中响应单元：适合为第一用户中的每一用户储存有关接收其中一名第二用户对其中一个第二电子确认请求的响应的信息。

34.如权利要求33中所述的用户确认系统，其中响应单元：适合为第二用户中的每一用户储存有关接收其中一名第一用户对其中一个第一电子确认请求的响应的信息。

35.如权利要求33中所述的用户确认系统，其中响应单元：适合为第一用户中的每一用户储存有关其中一名第二用户对其中一个第二电子确认请求的响应何时被接收的信息。

36.如权利要求30中所述的用户确认系统，其中储存器包括：多名用户中的每一用户的响应信息栏位，其中每一第一用户的响应信息栏位适合：储存有关其中一个第二电子确认请求何时被发送到其中一名第二用户的信息，及有关其中一名第二用户对其中一个第二电子确认请求的响应何时被接收的信息。

37.如权利要求36中所述的用户确认系统，其中每一第二用户的响应信息栏位：适合储存有关其中一个第一电子确认请求何时被发送到其中一名第一用户的信息，及有关其中一名第一用户对其中一个第一电子确认请求的响应何时被接收的信息。

38.如权利要求36中所述的用户确认系统，其中每一第一用户的响应信息栏位：进一步适合储存有关其中一个第一电子确认请求何时被发送到其中一名第一用户的信息，及有关其中一名第一用户对其中一个第一电子确认请求的响应何时被接收的信息。

39.如权利要求38中所述的用户确认系统，其中有效性分析器：根据其中一名第一用户对其中一个第一电子确认请求的响应是不是在相对于其中一个第一电子确认请求的一个预定时期内被接收，确定其中一名第一用户的状况表示的有效性。

40.如权利要求38中所述的用户确认系统，其中有效性分析器：根据其中一名第二用户对其中一个第二电子确认请求的响应是不是在相对于其中一个第二电子确认请求的一个预定时期内被接收，确定其中至少一名第一用户的状况表示的有效性；并进一步根据其中一名第一用户对其中一个第一电子确认请求的响应是不是在相对于其中一个第一电子确认请求的一个预定时期内被接收，确定其中一名第一用户的状况表示的有效性。

41.如权利要求36中所述的用户确认系统，其中有效性分析器：根据其中一名第二用户对其中一个第二电子确认请求的响应是不是在相对于其中一个第二电子确认请求的一个预定时期内被接收，确定其中至少一名第一用户的状况表示的有效性。

42.如权利要求30中所述的用户确认系统，其中确定请求生成器：生成其中一个第一确认请求，第一确认请求包括至少一名第二用户的状况表示；以及使接收其中一个第一确认请求的第一用户能同意或不同意对其中一个第一电子确认请求的响应中的至少一名第二用户的状况表示。

43.如权利要求30中所述的用户确认系统，其中确定请求生成器：生成每个第一确认请求，每个第一确认请求包括至少一名第二用户的状况表示；以及使接收第一确认请求的第一用户能在对第一电子确认请求的响应中说明至少一名第二用户的新的状况表示。