一种用户账户管理方法及装置

暂无

一种用户账户管理方法及装置\n技术领域\n[0001] 本申请涉及互联网技术领域，尤其涉及一种用户账户管理方法及装置。\n背景技术\n[0002] 在互联网的世界中，除了传统的媒体类应用之外，目前更多的应用需要用户以特定的身份参与，比如电子商务以及社交类应用。用户在该应用下进行账户注册，登录方式一般采用登录名(也称为“登录号”)和登录密码来实现。在大部分应用中，登录名通常为一串数字(如QQ号)、昵称或者邮箱名，也有一些系统采用手机号作为登录名。\n[0003] 无论采用哪种形式的登录名，对于提供服务的系统来说，基本上都有系统内登录名唯一性的控制机制。以手机号这样的登录名为例，因为二次放号的问题，会导致应用系统内登录名唯一性控制要求与用户体验之间产生矛盾。二次放号是指手机号的原使用者主动/被动放弃使用该手机号后，该手机号基于特定条件被电信运营商回收之后分配给新用户使用的过程。二次放号现象发生后，新用户面临手机号无法注册特定应用的问题。比如说手机号的老用户使用该手机号注册了支付宝账户。那么新用户再使用该手机号注册支付宝账户时，支付宝服务系统会发现登录名冲突，因而可能会暂时拒绝该注册，直到冲突解除。\n此外，若老用户没有及时更改手机号，其可能会导致业务短信或者安全校验短信发到该手机号，被该手机号新用户接收到的问题。由此可见，二次放号一方面可能会造成用户体验降低的问题，另一方面还可能引发安全隐患。\n[0004] 事实上，随着互联网的发展，二次放号现象不仅仅局限于手机号，还存在于邮箱以及QQ号等领域。比如说QQ靓号的转让，就会在事实上导致QQ号的二次放号，而大型的Web邮件服务商往往会回收那些长期不使用的邮件账户，然后给新用户注册使用，这也导致事实上二次放号的产生。由此可见，二次放号的现象广泛存在与互联网应用中。\n[0005] 目前上述问题的解决主要依赖人工处理。比如手机号的新用户找到支付宝的人工客服，证明自己是该手机号的合法拥有者，由人工客服在后台强行处理，将该手机号的原用户留存在系统中的手机号进行修改，这样就可以达到释放手机号的目标。释放之后，系统内该手机号不存在，那么新用户使用该手机号注册就满足唯一性的控制要求，注册于是就能够成功。\n[0006] 这种人工处理方式弊端显著：第一，人工成本高，在大型的互联网应用中，比如淘宝或新浪微博等，用户数量巨大，二次放号的数量不小，用人力去解决问题，成本太高；第二，用户体验差，人工客服通常需要手机号的新用户提供各种证据来证明自己对手机号的合法拥有，这无疑增加了用户很多额外的操作要求；第三，人工客服进行信息核对以及处理需要较长的时间，用户无法及时完成注册；第四，老用户账户中的手机号被修改，如何妥善处理又是一个需要人工再次解决的问题。\n发明内容\n[0007] 有鉴于此，本申请提供一种用户账户管理装置，应用于服务器上，包括：前置检查单元、常规注册单元、特殊注册单元以及登录管理单元，其中：\n[0008] 前置检查单元，用于获取当前用户的注册请求中的登录名本体，在账户表查找是否存在使用该登录名本体的冲突老用户；若存在，转特殊注册单元处理；\n[0009] 特殊注册单元，用于获取对应于冲突老用户的登录附加因子，并为当前用户生成不同于冲突老用户的登录附加因子；在该用户注册成功时，基于对应于所述当前用户的登录附加因子以及该用户注册请求中的登录名本体和登录密码在账户表中创建账户记录；\n[0010] 登录管理单元，用于获取当前用户登录请求中的登录名本体以及登录密码，在账户表中查找是否存在匹配的账户记录；若存在多个匹配的账户记录，则向该用户发送附加因子验证界面，并当任一账户对应的登录附加因子验证成功后，允许用户登录相应的账户；\n若存在唯一匹配的账户记录，则允许用户登录该账户；若不存在，则拒绝该用户登录。\n[0011] 本申请还提供一种用户账户管理方法，应用于服务器上，该方法包括：\n[0012] 获取当前用户的注册请求中的登录名本体，在账户表查找是否存在使用该登录名本体的冲突老用户；\n[0013] 若存在使用该登录名本体的冲突老用户，获取对应于冲突老用户的登录附加因子，并为当前用户生成不同于冲突老用户的登录附加因子；在该用户注册成功时，基于对应于所述当前用户的登录附加因子以及该用户注册请求中的登录名本体和登录密码在账户表中创建账户记录；\n[0014] 获取当前用户登录请求中的登录名本体以及登录密码，在账户表中查找是否存在匹配的账户记录；若存在多个匹配的账户记录，则向该用户发送附加因子验证界面，并当任一账户对应的登录附加因子验证成功后，允许用户登录相应的账户；若存在唯一匹配的账户记录，则允许用户登录该账户；若不存在，则拒绝该用户登录。\n[0015] 相较于现有技术，本申请有效地解决了二次放号等现象引发登录名冲突情况下所导致的用户体验下降，解决冲突人工客服成本高的问题。\n附图说明\n[0016] 图1是本申请一个例子中用户帐户管理装置的逻辑结构以及硬件环境图。\n[0017] 图2是本申请一个例子中用户帐户管理方法的处理流程图。\n[0018] 图3是本申请一个例子中提示用户记录登录附加因子的界面示意图。\n[0019] 图4是本申请一个例子中引导用户修改手机号的流程图。\n[0020] 图5是本申请一个例子中用户找回密码的界面示意图。\n[0021] 图6是本申请另一个例子中用户找回密码的界面示意图。\n具体实施方式\n[0022] 本申请通过改进应用系统内部的数据组织方式，以及对应的处理流程来大幅度改善二次放号引发注册冲突而导致用户体验下降的问题。请参考表1，在本申请一种实施方式中，在特殊业务场景的驱动下，在系统内记录每个用户账户信息的账户表(请参考表1的示例)中，登录名字段(字段一)中除了登录名本体之外还可以包括更多的参数，但是任意一条账户记录的登录名字段中的数据在应用系统的数据库表中具有唯一性，系统通过冲突识别参数的引入保证登录名字段内登录名数据的唯一性，而登录名本体则允许重复。从用户的使用角度来说，其依然会继续将登录名本体作为登录名，也就是说登录名字段的数据结构的变化对于用户而言是无需感知的，事实上用户认为的登录名在系统中事实上是登录名本体，其可能是系统中的登录名数据本身，也可能只是登录名数据的一部分。同时，由于字符串的引入，使得基于“登录名本体+字符串”的组合，即使在登录名本体相同的情况下，也可以根据字符串的差异实现有效区分，即实际上实现了登录名的差异化。因此，即便在登录名本体和登录密码相同的情况下，也能够准确区分不同账户，并确保每个账户的正常登录。\n[0023] 请参考表1的示例，其中用户Tony使用手机号18611180751作为登录名，在系统中该用户账户记录的登录名字段中的登录名数据则是“18611180751”，而用户Kevin也使用\n18611180751作为登录名，在系统中用户Kevin账户记录的登录名字段中的登录名数据则可以是“18611180751|R”。通过这样的数据组织方式，系统数据库中的登录名的唯一性得到了保证，以下将继续描述基于该数据组织方式如何为用户提供体验更好的服务。值得注意的是，在本示例中，登录名字段中还包括预先定义的分隔符“|”，分隔符的引入是考虑到业务的可扩展性，但并不是必须的选择。比如说在中国大陆地区，目前所有的手机号都是11位的，因为对于那些业务集中在中国大陆地区的服务商而言，实施过程中并不需要引入分隔符，因为系统可以根据手机号的长度来确定手机号与冲突识别参数的分界，从而准确地确定出手机号与冲突识别参数。但是对于服务更多国家/地区用户的服务商而言，由于各个国家/地区手机号码的位数不尽相同，因此在登录名本体与冲突识别参数之间引入分隔符来协助区分登录名本体以及冲突识别参数。\n[0024]\n序号 字段一 字段二\n  登录名+分隔符+识别因子 登录密码\n1 13900100110 aaaaaa\n2 18611180751|R bbbbbb\n3 18611180751 cccccc\n4 13988888888 aaaaaa\n…… …… ……\n[0025] 表1\n[0026] 需要指出的是：用户在设置登录密码时，往往使用自己的生日等具有纪念意义的数字、字母或其组合，但一些用户为了方便记忆等目的，喜欢使用一些极为简单的密码，如“123456”、“abcdef”、“asdfgh”等，使得存在两个用户的登录名本体和登录密码均重复的概率。虽然在上述描述中，可以通过对“冲突识别参数”的引入而避免系统数据库中的登录名冲突问题，但实际上已经导致了无法通过“登录名本体+登录密码”的组合来区分用户的情况。\n[0027] 请参考表2，在本申请的另一种实施方式中，在“登录名本体+登录密码”的基础上，为每个用户生成对应的登录附加因子，从而形成了“登录名本体+登录密码+登录附加因子”的组合。在表2所示的新组合中，假定用户Tony使用手机号18611180751作为登录名，在系统中该用户账户记录的登录名字段中的登录名数据则是“18611180751”，而用户Kevin也使用\n18611180751作为登录名，在系统中用户Kevin账户记录的登录名字段中的登录名数据则是“18611180751|R”；当Tony和Kevin使用的登录密码均为简单密码“123456”时，由于Tony采用的登录附加因子为“20140222”、Kevin采用的登录附加因子为“20091023”，因而能够实现准确区分Tony和Kevin。\n[0028]\n序号 字段一 字段二\n  登录名+分隔符+识别因子 登录密码\n1 13900100110 aaaaaa\n2 18611180751|R 123456\n3 18611180751 123456\n4 13988888888 aaaaaa\n…… …… ……\n[0029] 表2\n[0030] 基于上述数据组织结构的变化，在一种软件实施方式中，本申请提供一种用户账户管理装置及对应的管理方法。请参考图1，该用户账户管理装置可以理解为服务器上运行的一个逻辑装置。在硬件层面，该服务器包括处理器、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。所述处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成所述用户管理装置，该用户管理装置可以理解为应用系统对外服务的一个部分，比如支付宝服务系统对外服务的一个部分。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下管理方法的处理流程的执行主体并不限定于各个逻辑单元，管理方法的执行主体也可以是硬件或逻辑器件。\n[0031] 在软件实施方式中，该用户管理装置包括前置检查单元、常规注册单元、特殊注册单元以及登录管理单元。请参考图2，在运行过程中该装置执行如下处理过程。\n[0032] 步骤201，前置检查单元获取当前用户的注册请求中的登录名本体，在账户表查找是否存在使用该登录名本体的冲突老用户；若不存在，转步骤202，若存在，转步骤203；\n[0033] 步骤202，常规注册单元生成对应于当前用户的登录附加因子，并基于该登录附加因子以及注册请求中的登录名本体和登录密码在账户表中为该用户创建账户记录；\n[0034] 步骤203，特殊注册单元获取对应于冲突老用户的登录附加因子，并为当前用户生成不同于冲突老用户的登录附加因子；在该用户注册成功时，基于对应于所述当前用户的登录附加因子以及该用户注册请求中的登录名本体和登录密码在账户表中创建账户记录；\n在所述冲突老用户的登录名本体所在的登录名字段中引入冲突识别参数；\n[0035] 步骤204，登录管理单元获取当前用户登录请求中的登录名本体以及登录密码，在账户表中查找是否存在匹配的账户记录；若存在多个匹配的账户记录，则向该用户发送附加因子验证界面，并当任一账户对应的登录附加因子验证成功后，允许用户登录相应的账户；若存在唯一匹配的账户记录，则允许用户登录该账户；若不存在，则拒绝该用户登录。\n[0036] 从以上的步骤中可以看出，通过使不同用户采用不同的登录附加因子，本申请允许不同用户使用相同登录名进行注册，避免了二次放号引发的注册与登录不便的问题。在正常的注册过程中，若用户使用的登录名本体在账户表中是唯一的，也就是说没有冲突老用户的存在，此时发起注册请求的用户显然不是一个冲突新用户，其注册请求将按照正常的方式处理。当然常规注册过程中也可能需要发起校验等额外处理过程，这些处理可参考已有技术实现。\n[0037] 同时，由于采用了登录名本体+登录密码+登录附加因子来作为识别不同用户的组合参数，使得即便登录名本体和登录密码均相同的两个用户，仍然能够通过登录附加因子来实现准确的用户识别与区分。\n[0038] 请参考表2，假设表2中第2条以及第3条记录分别是用户Kevin以及Tony的账户记录(也称为“用户记录”)。假设登录名本体是手机号，用户Kevin使用手机号18611180751注册账户在先，后来用户Kevin不再使用该手机号，运营商回收该号码之后分配给Tony使用。\n用户Tony使用该手机号又进行账户注册，经过步骤203的特殊处理，Kevin的登录名在手机号的基础上又被添加了冲突识别参数，在账户表中，Kevin和Tony的登录名不再相同，同一字段中登录名的唯一性得到了保证。此时允许用户Tony进行账户注册并不会影响用户Kevin的登录。\n[0039] 类似于传统处理方式，本申请的应用系统不需要关注不同账户的密码是否相同的问题，因为通过登录附加因子的差异化，使得理论上应用系统中所有用户使用相同的登录密码也是可以的。在本申请步骤203的处理中，用户Tony若想注册成功，则必须与用户Kevin不同附加因子，从而在登录过程中，即便具有相同的登录名本体和登录密码，也能够基于登录附加因子实现对账户的匹配。具体地，当18611180751对应的账户记录存在多个时，需要逐一比对登录密码。在传统方案中，由于18611180751这个登录名本体并不会存在于两条账户记录中，于是查找过程使用18611180751进行查找发现一条账户记录，但密码不匹配，则立刻退出查找提示登录失败，而本申请在此情况下还需要继续遍历过程，直到所有\n18611180751对应的账户记录中的登录密码都不匹配时才确定用户登录失败；并且在登录密码再次匹配多个账户时，需要根据登录附加因子继续遍历，直至所有18611180751对应的账户记录中的登录附加因子都不匹配时才确定用户登录失败。\n[0040] 基于上述的登录机制，本申请在请求注册的当前用户是一个与冲突老用户对应的冲突新用户(比如Tony)时，在其注册过程中引导Tony使用与冲突老用户Kevin不同的登录附加因子。登录附加因子的类型有多种，现列举以下示例作为实施参考。在较佳的实施方式中，从大类上来说，登录附加因子包括两大类，一类是与用户注册时间相关的字符串，另一类是用于身份信息验证的校验选项。当然本领域普通技术人员也可以使用其他方式定义登录附加因子。\n[0041] a.与用户注册时间相关的字符串\n[0042] 在实现上，由于显然不可能存在两个用户在完全相同的时间点使用完全相同的登录名本体和登录密码进行注册操作，即便在极低概率下存在同一天注册的情况，也可以通过提高获取的注册时间的精确度(比如精确至小时、分钟、秒钟等)，从而在注册时间上区分不同用户。因此，常规注册单元可以在每个用户执行正常的用户注册操作时，获取相应的注册时间，并根据该注册时间生成对应于当前用户的登录附加因子。比如用户Kevin在2009年\n10月23日使用登录名本体“18611180751”完成了注册，则可以将“20091023”作为用户Kevin对应的登录附加因子，且可以通过图3a所示的方式来提示用户Kevin记录该登录附加因子(即图中所示的“唯一登录识别码”)。\n[0043] 当用户Tony在2014年2月22日使用登录名本体“18611180751”进行注册时，特殊注册单元检测到当前用户Tony注册请求中的登录名本体与用户Kevin相同，则为用户Tony生成如图3b所示的登录附加因子“20140222”，并在用户Kevin的登录名本体所处的登录名字段中添加冲突识别参数。在上述注册过程中，由于冲突识别参数的添加操作是后台完成的，而登录附加因子是用户注册过程必然经历的过程，使得用户Kevin和用户Tony所感受到的注册过程和得到的体验是相同的，并不会由于存在登录名本体的冲突而存在差异化对待，也避免用户Tony意识到当前的登录名本体已被使用，有助于提升用户Tony和用户Kevin双方的账户安全。\n[0044] 选择用户注册时间来生成对应的登录附加因子，实际上是为了便于用户记忆，避免登录附加因子的遗忘而导致用户无法登录；但理论上，只要能够确保当前用户和冲突老用户分别对应于不同的字符串，即可作为本申请技术方案的登录附加因子。\n[0045] 进一步地，当登录附加因子为字符串时，除了将登录附加因子作为用户账户表中的独立字段(如表2所示的字段三)，也可以采用如表3所示的将其作为登录名字段中的信息。当登录附加因子作为登录名字段中的信息时，实际上也可以不引入冲突识别参数，即可实现账户数据库内的数据唯一性；当然，通过引入冲突识别参数还可以用于准确识别出冲突老用户，从而引导其更改自身的登录名本体，并将相应的登录名本体“交还”至该手机号码的真正拥有者，具体过程参见下述的“冲突消除机制”。\n[0046]\n序号 字段一 字段二\n  登录名+分隔符+识别因子 登录密码\n1 13900100110 aaaaaa\n2 18611180751|R20091023 123456\n3 18611180751|20140222 123456\n4 13988888888 aaaaaa\n…… …… ……\n[0047] 表3\n[0048] b.用于身份验证的校验选项\n[0049] 在注册过程中，除了用户填写的登录名本体和登录密码外，还需要用户填写身份验证信息，比如：验证邮箱、家庭住址或者校验问答等。每个用户都可能填写一个或个用于身份验证的信息，比如用户Kevin在注册时，填写了验证邮箱和三个校验问答，则可以将验证邮箱作为登录附加因子(如图3c所示)，也可以将校验问答中的任意一个或多个作为登录附加因子(如图3d所示)。\n[0050] 当用户Tony注册时，检测到其使用了与用户Kevin相同的登录名本体，则获取用户Kevin对应的登录附加因子，比如该登录附加因子为图3d所示的校验问答“最喜欢的电影”及相应的答案“《七宗罪》”；由于校验问答中的问题可以由用户在系统预设的很多问题中进行选择，则在用户Tony希望选择校验问题时，可以屏蔽“最喜欢的电影”这个问题，以避免用户Tony填写了与用户Kevin相同的答案；或者，由于不同用户填写的答案相同的概率很低，可以不采取屏蔽的手段，而是在用户Tony确实填写了与用户Kevin相同的答案时，强制用户Tony填写更多的校验问答，直至用户Tony和用户Kevin之间存在不同的校验问答或对同一校验问题存在不同的答案。\n[0051] 以下在上述实施方式的基础上，结合更多的应用实际通过一个较佳的实施方式来阐述本申请的技术优势。在以下的描述中，登录名将以手机号为例。在一个接近实际部署的方案中，本申请提出以下几个优化措施来进一步提高本申请在实际使用中的实施效果，当然这些措施并不是必须的，而且各种优化措施如何组合可以根据需要来灵活选择。\n[0052] 在上述实施方式的基础上本申请可进一步引入冲突消除机制。在一种实施方式中，本申请在步骤201到204的基础上进一步包括冲突解决机制。前述实施方式解决了注册冲突和登录冲突问题。虽然两个用户同时使用一个手机号登录并无问题，但是从用户使用应用服务的角度而言，手机号对于用户而言无疑是比较重要的，比如说接收校验短信等。若一项应用需要接收校验短信并在页面上回填该短信，则此时由于手机号同一时刻只会被一个用户(比如Tony)拥有，那么另一个用户(比如Kevin)此时就无法接收到自己的校验短信。\n对于这样的情况本申请进行特别处理，在用户登录成功的情况下，检查该用户登录名中是否包括有冲突设别参数，如果有则所述登录管理单元进一步向该用户推送手机号修改界面引导该冲突老用户修改手机号，在接收到用户输入新手机号之后在对应的账户记录中将手机号更新，用户下次再此进行登录时，需要使用新手机号作为登录名本体进行登录。在具体实现上，用户输入新手机号之后，登录管理单元通常会进一步针对该手机号发起校验，比如发送包括校验码的校验短信给该新手机号，并对比用户在界面上提交的校验码是否正确来确认用户是否确实拥有该手机号，这个过程与常规注册过程是类似的，此处不再详述。\n[0053] 冲突老用户根据引导修改手机号依然可能存在一种特殊的情况。假设用户Kevin输入的手机号依然是18611180751，与原手机号一致，并不是新手机号，此时系统无法确定到底Kevin还是Tony拥有该手机号。一种简单的处理方式是，Kevin必须更改手机号，否则不允许其继续登录。然而事实上，Tony可能只是临时使用Kevin的手机号，Kevin才是真正的手机号主人，请参考图4，针对这种情况，在一种较为完整的实施方式中，引导用户修改手机号的流程包括如下步骤：\n[0054] 步骤401，登录管理单元在当前用户登录成功的情况下检查该用户账户记录的登录名字段中是否包括有冲突识别参数；如果有，则向该用户发送登录名本体修改界面，以引导该用户修改登录名本体；\n[0055] 步骤402，特殊注册单元获取当前用户通过登录名本体修改界面输入的登录名本体，在账户表查找是否存在使用该登录名本体的冲突新用户，如果不存在，则更新当前用户账户记录中的登录名本体，如果存在，则确定对应于该冲突新用户的登录附加因子，并使当前用户采用不同于冲突新用户的登录附加因子，且在该冲突新用户的登录名字段中添加冲突识别参数使其成为冲突老用户；将当前用户账户记录的登录名字段中的冲突识别参数消除。\n[0056] 仍然以用户Kevin与用户Tony为例，假设用户Kevin作为冲突老用户，其在登录名修改界面上提交的手机号确实发生了变化，比如变更为18611223344，此时根据步骤401到\n402的处理，用户Kevin与用户Tony之间将不存在冲突，用户Kevin的登录名将变成一个唯一使用的手机号，此时账户表将从表2更新为表4的示例。\n[0057]\n序号 字段一 字段二 字段三\n  登录名+分隔符+识别因子 登录密码 登录附加因子\n1 13900100110 aaaaaa 20100605\n2 18611223344 123456 20091023\n3 18611180751 123456 20140222\n4 13988888888 aaaaaa 20101010\n…… …… …… ……\n[0058] 表4\n[0059] 但是假设用户Kevin输入的手机号仍然是18611180751，也就意味着用户Kevin在向系统表明其拥有该手机号，此时系统无法确定到底是Kevin还是Tony拥有该手机号。因此系统在步骤402之前可以向用户发起校验，校验成功的话，校验过程不再详述，可参考现有技术执行。此时Kevin将变为冲突新用户，而Tony则从冲突新用户变为冲突老用户。此时表2将更新为表5的示例。这种设计可以很好地解决“伪二次放号”问题，真实的二次放号是一个手机号的主人发生了变更。而“伪二次放号”则是通过手机号的交叉使用产生了二次放号现象，这种交叉使用导致了应用系统认为发生了二次放号。比如说Kevin是18611180751的真实主人，其在支付宝使用该手机号进行了注册，支付宝系统拥有一条账户记录。Tony是Kevin的弟弟，其在一些特殊的或临时性的应用需求下，Tony临时使用Kevin的手机号注册了支付宝账户，这个过程将触发步骤201到204的处理，这导致Kevin在支付宝系统中变成了冲突老用户，而Tony通过“抢夺”行为则成为冲突新用户。Kevin再次登录时，系统在步骤401针对冲突老用户Kevin发送登录名修改界面引导Kevin修改手机号，此时由于Kevin是\n18611180751真实主人，其可能仍然输入了18611180751。系统此时可以认为是Kevin在执行“反抢”操作，通过校验短信对Kevin的“反抢”行为进行验证，若通过，则将Kevin变更为冲突新用户，而Tony则变为冲突老用户。Tony再次登录，系统仍然会通过登录名修改界面来引导Tony修改手机号。若Tony将自己的手机号修改，比如修改为18622223333，那么冲突将消失。\n[0060]\n序号 字段一 字段二 字段三\n  登录名+分隔符+识别因子 登录密码 登录附加因子\n1 13900100110 aaaaaa 20100605\n2 18611180751 123456 20091023\n3 18611180751|R 123456 20140222\n4 13988888888 aaaaaa 20101010\n…… …… …… ……\n[0061] 表5\n[0062] 请继续参考图5，在步骤204处理机制的基础上，本申请可进一步为用户提供创建与主账户具有关联关系的独立子账户的机制。假设用户Jack的手机号是13988888888，Jack使用该手机号注册了支付宝账户Jack1，其利用该账户为自己的公司购置办公用品，但Jack同时希望自己能够用该手机号注册另外一个支付宝账户Jack2，然后利用该账户Jack2为自己购买私人用品，这样可以清晰地区分公司采购与个人消费。在传统技术中，这种用户需求是无法满足的。在本申请中，特殊注册单元在当前用户通过当前账户(设为主账户)登录成功后接收到该用户发送的子账户创建请求时，向用户推送不同于当前登录账户的登录附加因子，以作为对应于子账户的登录附加因子，并基于当前登录账户的登录名本体、登录密码和对应于子账户的登录附加因子创建子账户，并在子账户登录名字段中添加关联识别参数。请参考表6的示例，在本实施方式中，使用字符“T”作为关联识别参数。子账户创建成功之后，Jack可以用“13988888888”作为登录名来分别登录两个账户，输入登录附加因子\n20101010则可以登录Jack1这个主账户，而输入登录附加因子20121212，则可以登录子账户。\n[0063]\n序号 字段一 字段二 字段三\n  登录名+分隔符+识别因子 登录密码 登录附加因子\n1 13900100110 aaaaaa 20100605\n2 18611180751|R bbbbbb 20091023\n3 18611180751 cccccc 20140222\n4 13988888888 aaaaaa 20101010\n5 13988888888|T aaaaaa 20121212\n…… …… …… ……\n[0064] 表6\n[0065] 在以上实施方式的基础上，本申请进一步考虑密码找回的处理机制。在优选的方式中，本申请所述用户管理装置还包括密码找回单元，密码找回单元在接收到用户密码找回请求时，在账户表中检查该用户使用的登录名本体是否对应于多个账户记录，如果是，则向该用户发送附加因子验证界面，其中该附加因子验证界面用于用户填写作为登录附加因子的字符串，或者显示出与所述多个账户记录分别对应的校验选项，在确定任意一个账户对应的登录附加因子验证成功后，发送与该账户的密码重置界面给当前用户；其中，若登录附加因子为校验选项，则各个校验选项均为登录名无关的校验选项。\n[0066] 假设Tony和Kevin任意一个人忘记了自身的密码，其会在对应的页面上发起密码找回请求。若按照传统实现，用户可能需要在界面上填入自身的手机号，但是由于手机号\n18611180751被Tony和Kevin同时使用，因此应用系统此时无法确定哪个用户在请求找回密码。为了回避手机号，一种处理方式是Tony或Kevin可以通过人工客服来解决该问题，但这样比较影响用户的体验。\n[0067] 在本申请中，密码找回单元并不会通过给18611180751发送校验短信息来进行校验，因为这样有可能会出现Tony重置了Kevin的密码，或者Kevin重置了Tony的密码。在本申请中，作为一示例性实施例，登录附加因子为字符串，则请参考图5的示例，密码找回单元生成附加因子验证界面上指示用户输入其对应的登录附加因子，则由于每个用户仅知道自己的登录附加因子，且Tony和Kevin两个用户的登录附加因子不相同(在注册时已经确保两者的登录附加因子不相同)，因而能够根据用户输入的登录附加因子来识别出当前用户的真实身份。\n[0068] 作为另一示例性实施例，登录附加因子为用于身份信息验证的校验选项，则请参考图6的实施例，密码找回单元生成包括与Tony和Kevin两个用户对应的校验选项的附加因子验证界面，并发送给当前用户。在实现上，可以把这些校验选项都放在一个下拉菜单中，因为每个用户通常都知道自己的校验选项(比如密码问题或密码问题组合)。考虑到仍然有少数用户会忘记自己当初设定的密码问题本身是什么，在一种比较贴近用户使用体验的优化方案中，所述附加因子验证界面包括与用户账户对应的校验子界面，每个用户的校验选项在各自的子界面中，且每个子界面中的校验选项可以为一个或多个。此时当前用户可以选择在任意一个校验子界面上完成校验。同样的道理，对于使用一个手机号的主账户以及子账户而言，密码找回的处理也可以采用上述流程。\n[0069] 假设左侧校验子界面与Tony对应，右侧校验子界与Kevin对应。此时若用户是Tony，则其会在左侧的校验子界面上完成“母亲生日”以及“父亲出生地”这些校验选项，因为右侧校验子界面中的校验选项并不是Tony的，因此Tony一般情况下是无法完成的。相反此时若用户是Kevin，则其会在右侧的校验子界面上完成“小学三年级班主任是谁”以及“最喜欢的电影”两个密码问题组合构成的校验选项，当然校验选项除了密码问题或密码问题组合之外，还可能是其他的校验方式，本申请对此并无特别限制。本实施方式事实上将多个登录名冲突用户的校验选项在同一个界面下分类列举，这个方式通常并不影响当前用户通过校验选项的操作来找回密码。事实上，只要用户操作了任意一个校验子界面下的校验选项，并且校验成功的话，那么此时系统就知道当前用户的账户记录了。\n[0070] 如前所述，在本申请中，账户表中每个用户的登录名字段可能会包括冲突识别参数或者关联识别参数，首先这两种参数并不冲突。请参考表7的示例，对于应用系统的流程处理而言，只要定义好两种参数的字符选择以及对应的位置即可。比如说，冲突识别参数选择字符“R”，位置在分隔符“|”右侧，而关联识别参数选择“T”，位置在冲突识别参数“R”的右侧；当然本领域技术人员也可以采用其他的符合实际业务应用需求的数据格式定义方式。\n其次，考虑到极其少量的情况下，可能会发生三次放号的情况，或者系统允许用户基于一个主账户创建多个关联的子账户时，仅凭一个冲突识别参数无法满足这种很特殊的需求(当然这种需求系统也可以不支持)。为了满足这种特殊需求，可以在识别参数之后再添加上一串包括多个字符的随机数。请参考表7的示例，在一种优选的实施方式中，为了开发便利，对于常规账户(不是冲突老用户，也不是子账户)也可以引入识别参数，比如用字符“A”表示正常账户。表7中“13900100110|A987688ab”表征一个常规账户；而“18611180751|Rkttdihss”则表征一个冲突老用户。“13988888888|RT0208adkz”表征一个冲突老用户，同时该用户的账户还是其他用户账户的子账户。\n[0071]\n序号 字段一 字段二 字段三\n  登录名+分隔符+识别因子 登录密码 登录附加因子\n1 13900100110|A987688ab aaaaaa 20100605\n2 18611180751|Rkttdihss 123456 20091023\n3 18611180751|Aktsd098 123456 20140222\n4 13988888888|R36derdd aaaaaa 20101010\n5 13988888888|RT0208adkz dddddd 20121212\n6 13988888888|RT4654sdfg eeeeee 20121215\n7 13988888888|A4756lkj ffffff 20140302\n…… …… …… ……\n[0072] 表7\n[0073] 或者，如表8所示，当登录附加因子为字符串时，也可以直接将登录附加因子作为登录名字段的一部分，同样能够区分相同登录名本体的多个账户。表8中的“13988888888|R20101010”表征一个冲突老用户；“13988888888|RT20121212”表征一个冲突老用户，且该用户的账户为“13988888888|R20101010”的子账户；“13988888888|RT20121215”表征一个冲突老用户，且该用户的账户也是“13988888888|R20101010”的子账户；“13988888888|A20140302”则表征一个常规账户。\n[0074]\n序号 字段一 字段二\n  登录名+分隔符+登录附加因子 登录密码\n1 13900100110|A20100605 aaaaaa\n2 18611180751|R20091023 123456\n3 18611180751|A20140222 123456\n4 13988888888|R20101010 aaaaaa\n5 13988888888|RT20121212 dddddd\n6 13988888888|RT20121215 eeeeee\n7 13988888888|A20140302 ffffff\n…… …… ……\n[0075] 表8\n[0076] 在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。\n[0077] 内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。\n[0078] 计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。\n计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。\n[0079] 还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。\n[0080] 以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。