HK1218811B - Method and apparatus for managing user accounts - Google Patents

Description

User account management method and device

Technical Field

The present application relates to the field of internet technologies, and in particular, to a method and an apparatus for managing a user account.

Background

In the world of the internet, more applications are currently required for users to participate in specific identities, such as e-commerce and social applications, in addition to traditional media-like applications. The user registers an account under the application, and the login mode is generally realized by a login name (also called a login number) and a login password. In most applications, the login name is usually a string of numbers (such as a QQ number), a nickname, or a mailbox name, and some systems use a mobile phone number as the login name.

Whatever form of login name is used, there is basically a control mechanism for the uniqueness of login names within a system for providing services. For example, a login name such as a mobile phone number is used, and a contradiction is generated between the uniqueness control requirement of the login name in the application system and the user experience due to the problem of secondary number allocation. The secondary number allocation refers to a process that after an original user of the mobile phone number abandons the mobile phone number actively/passively, the mobile phone number is recovered by a telecom operator based on a specific condition and then is allocated to a new user for use. After the secondary number allocation phenomenon occurs, the new user faces the problem that the mobile phone number cannot register specific application. For example, an old user of a mobile phone number registers a payroll account with the mobile phone number. Then when the new user registers the paymate account using the mobile phone number, the paymate service system may find the login name conflict and may temporarily reject the registration until the conflict is resolved. In addition, if the old user does not change the mobile phone number in time, the old user may cause a problem that a service short message or a security verification short message is sent to the mobile phone number and is received by a new user of the mobile phone number. Therefore, the problem of reduction of user experience can be caused on one hand by secondary number allocation, and potential safety hazards can be caused on the other hand.

In fact, with the development of the internet, the phenomenon of secondary number allocation is not limited to mobile phone numbers, but also exists in the fields of mailboxes, QQ numbers and the like. For example, the transfer of the QQ unique number can actually result in the secondary number allocation of the QQ number, and a large-scale Web mail service provider often recycles the mail accounts which are not used for a long time and then registers the mail accounts for new users, which also results in the fact that the secondary number allocation is generated. Therefore, the phenomenon of secondary number allocation is widely applied to the Internet.

The current solution to the above problem relies mainly on manual handling. For example, a new user of the mobile phone number finds the artificial customer service of the payment device, proves that the new user is the legal owner of the mobile phone number, the artificial customer service forcibly processes the artificial customer service in the background, and the original user of the mobile phone number is left in the system to modify the mobile phone number, so that the aim of releasing the mobile phone number can be achieved. After the release, the mobile phone number does not exist in the system, so that the new user can use the mobile phone number to register, the uniqueness control requirement is met, and the registration can be successful.

The manual treatment mode has obvious defects: firstly, the labor cost is high, the number of users is huge in large-scale internet application such as panning or new wave microblog, the number of secondary number allocation is not small, the problem is solved manually, and the cost is too high; secondly, the user experience is poor, and manual customer service generally needs a new user of the mobile phone number to provide various evidences to prove the legal possession of the user on the mobile phone number, so that a lot of additional operation requirements of the user are undoubtedly increased; thirdly, the manual customer service needs a long time for information checking and processing, and the user cannot complete registration in time; fourth, how to properly handle the mobile phone number in the old user account is a problem to be solved again manually.

Disclosure of Invention

In view of the above, the present application provides a user account management apparatus, applied to a server, including: the system comprises a preposed checking unit, a conventional registration unit, a special registration unit and a login management unit, wherein:

the system comprises a preposed checking unit, a login name body and an account table, wherein the preposed checking unit is used for acquiring the login name body in a registration request of a current user and searching whether a conflict old user using the login name body exists in the account table; if yes, processing by a special registration unit;

the special registration unit is used for acquiring the login additional factor corresponding to the conflict old user and generating a login additional factor different from the conflict old user for the current user; when the user registration is successful, creating an account record in an account table based on the login additional factor corresponding to the current user and the login name body and the login password in the user registration request;

the login management unit is used for acquiring a login name body and a login password in the current user login request and searching whether a matched account record exists in an account table; if a plurality of matched account records exist, an additional factor verification interface is sent to the user, and the user is allowed to log in the corresponding account after the login additional factor corresponding to any account is verified successfully; if the uniquely matched account record exists, allowing the user to log in the account; if not, the user is refused to log in.

The application also provides a user account management method, which is applied to the server and comprises the following steps:

acquiring a login name body in a registration request of a current user, and searching whether a conflict old user using the login name body exists in an account table;

if the conflict old user using the login name ontology exists, acquiring a login additional factor corresponding to the conflict old user, and generating a login additional factor different from the conflict old user for the current user; when the user registration is successful, creating an account record in an account table based on the login additional factor corresponding to the current user and the login name body and the login password in the user registration request;

acquiring a login name body and a login password in a current user login request, and searching whether a matched account record exists in an account table; if a plurality of matched account records exist, an additional factor verification interface is sent to the user, and the user is allowed to log in the corresponding account after the login additional factor corresponding to any account is verified successfully; if the uniquely matched account record exists, allowing the user to log in the account; if not, the user is refused to log in.

Compared with the prior art, the method and the device effectively solve the problems that the user experience is reduced under the condition that login name conflict is caused by the phenomena of secondary number allocation and the like, and the conflict manual customer service cost is high.

Drawings

Fig. 1 is a logical structure and hardware environment diagram of a user account management apparatus according to an example of the present application.

FIG. 2 is a process flow diagram of a method for user account management in one example of the application.

FIG. 3 is a schematic diagram of an interface for prompting a user to record additional factors for login in one example of the present application.

Fig. 4 is a flowchart for guiding a user to modify a mobile phone number according to an example of the present application.

FIG. 5 is a schematic diagram of an interface for a user to retrieve a password in one example of the application.

FIG. 6 is a schematic diagram of an interface for a user to retrieve a password in another example of the present application.

Detailed Description

According to the application, the problem that the user experience is reduced due to registration conflict caused by secondary number allocation is greatly improved by improving the data organization mode in the application system and the corresponding processing flow. Referring to table 1, in an embodiment of the present application, driven by a special business scenario, in an account table (see the example of table 1) that records information of each user account in a system, a login name field (field one) may include more parameters besides a login name body, but data in the login name field of any one account record has uniqueness in a database table of an application system, and the system ensures the uniqueness of the login name data in the login name field through the introduction of a conflict identification parameter, while the login name body allows duplication. From the use point of view of the user, the user still continues to use the login name ontology as the login name, that is, the change of the data structure of the login name field is not necessary to be perceived by the user, and the login name considered by the user is actually the login name ontology in the system, which may be the login name data itself in the system or only a part of the login name data. Meanwhile, due to the introduction of the character strings, even under the condition that the login name bodies are the same, effective distinguishing can be realized according to the difference of the character strings based on the combination of the login name body and the character strings, namely, the difference of the login names is actually realized. Therefore, even under the condition that the login name body and the login password are the same, different accounts can be accurately distinguished, and normal login of each account is ensured.

Referring to the example of table 1, where user Tony uses mobile phone number 18611180751 as the login name, the login name data in the login name field of the user account record in the system is "18611180751", and user Kevin also uses 18611180751 as the login name, the login name data in the login name field of the user Kevin account record in the system may be "18611180751 | R". By such a data organization, uniqueness of the login name in the system database is guaranteed, and how to provide users with experience better services based on the data organization will be described continuously below. It is noted that in this example, the login name field further includes a predefined delimiter "|", and the introduction of the delimiter is a choice that allows for scalability of the service, but is not a necessary choice. For example, in the continental china, all the mobile phone numbers are 11 digits currently, and for service providers whose services are concentrated in the continental china, a separator is not required to be introduced in the implementation process, and the system can determine the boundary between the mobile phone number and the conflict identification parameter according to the length of the mobile phone number, so that the mobile phone number and the conflict identification parameter can be accurately determined. However, for the service provider serving more country/region users, because the number of digits of the mobile phone number is different for each country/region, a separator is introduced between the login name body and the conflict identification parameter to help distinguish the login name body and the conflict identification parameter.

Serial number	Field one	Field two
				Login name + separator + identifier	Login password
1	13900100110	aaaaaa
			2	18611180751|R	bbbbbb
3	18611180751	cccccc
			4	13988888888	aaaaaa
……	……	……

TABLE 1

It should be noted that: when a user sets a login password, the user often uses numbers, letters or a combination of numbers, letters or the combination of the numbers, the letters or the combination having commemorative significance such as birthdays of the user, but some users like to use very simple passwords such as '123456', 'abcdef', 'asdfgh' and the like for the purposes of convenience in memory and the like, so that the probability that login name bodies and login passwords of two users are repeated exists. Although in the above description, the problem of login name collision in the system database can be avoided by the introduction of the "collision recognition parameter", in practice, a situation has been caused in which the user cannot be distinguished by the combination of "login name ontology + login password".

Referring to table 2, in another embodiment of the present application, a corresponding login additional factor is generated for each user based on the "login name ontology + login password", so as to form a combination of "login name ontology + login password + login additional factor". In the new combination shown in table 2, it is assumed that the user Tony uses the mobile phone number 18611180751 as the login name, the login name data in the login name field of the user account record in the system is "18611180751", the user Kevin also uses 18611180751 as the login name, and the login name data in the login name field of the user Kevin account record in the system is "18611180751 | R"; when both the login passwords used by Tony and Kevin are simple passwords "123456", since the login additional factor adopted by Tony is "20140222" and the login additional factor adopted by Kevin is "20091023", accurate distinction between Tony and Kevin can be realized.

Serial number	Field one	Field two
				Login name + separator + identifier	Login password
1	13900100110	aaaaaa
			2	18611180751|R	123456
3	18611180751	123456
			4	13988888888	aaaaaa
……	……	……

TABLE 2

Based on the change of the data organization structure, in one software implementation mode, the application provides a user account management device and a corresponding management method. Referring to fig. 1, the user account management device may be understood as a logic device running on a server. At the hardware level, the server includes a processor, a memory, and a non-volatile memory, but may also include hardware required for other services. The processor reads a corresponding computer program from the nonvolatile memory into the memory and then runs the computer program to form the user management device on a logic level, and the user management device can be understood as a part of an external service of an application system, such as a part of an external service of a pay service system. Of course, besides the software implementation, the present application does not exclude other implementations, such as logic devices or a combination of software and hardware, and the like, that is, the execution main body of the processing flow of the following management method is not limited to each logic unit, and the execution main body of the management method may also be hardware or logic devices.

In a software embodiment, the user management device comprises a pre-check unit, a regular registration unit, a special registration unit and a login management unit. Referring to fig. 2, the apparatus performs the following processes during operation.

Step 201, a preposed checking unit obtains a login name body in a registration request of a current user, and searches whether a conflict old user using the login name body exists in an account table; if not, go to step 202, if yes, go to step 203;

step 202, the conventional registration unit generates a login additional factor corresponding to the current user, and creates an account record for the user in an account table based on the login additional factor, a login name body and a login password in the registration request;

step 203, the special registration unit acquires a login additional factor corresponding to the conflict old user and generates a login additional factor different from the conflict old user for the current user; when the user registration is successful, creating an account record in an account table based on the login additional factor corresponding to the current user and the login name body and the login password in the user registration request; introducing conflict identification parameters into the login name field where the login name body of the conflict old user is located;

step 204, the login management unit acquires a login name body and a login password in the current user login request, and searches whether a matched account record exists in an account table; if a plurality of matched account records exist, an additional factor verification interface is sent to the user, and the user is allowed to log in the corresponding account after the login additional factor corresponding to any account is verified successfully; if the uniquely matched account record exists, allowing the user to log in the account; if not, the user is refused to log in.

It can be seen from the above steps that different users use different login additional factors, the application allows different users to use the same login name for registration, and the problem of inconvenience in registration and login caused by secondary number allocation is avoided. In the normal registration process, if the login name body used by the user is unique in the account table, that is, there is no conflict old user, at this time, the user initiating the registration request is obviously not a conflict new user, and the registration request is processed in a normal manner. Of course, additional processes such as verification may need to be initiated in the conventional registration process, and these processes may be implemented with reference to the prior art.

Meanwhile, the login name body, the login password and the login additional factor are used as combined parameters for identifying different users, so that even two users with the same login name body and login password can still realize accurate user identification and distinction through the login additional factor.

Referring to table 2, assume that entries 2 and 3 in table 2 are account records (also referred to as "user records") for users Kevin and Tony, respectively. Assuming that the login name body is a mobile phone number, the user Kevin uses the mobile phone number 18611180751 to register the account first, and then the user Kevin does not use the mobile phone number any more, and the operator recycles the number and then allocates the number to Tony for use. The user Tony uses the mobile phone number to register an account, and after the special processing of the step 203, the login name of Kevin is added with the conflict identification parameter on the basis of the mobile phone number, the login names of Kevin and Tony are not the same in the account table, and the uniqueness of the login name in the same field is ensured. At this point, the user Tony is allowed to register for an account without affecting the user Kevin's login.

Similar to the traditional processing mode, the application system of the application does not need to pay attention to the problem that whether the passwords of different accounts are the same or not, and because the login additional factors are differentiated, theoretically, all users in the application system can use the same login password. In the process of step 203, when the user Tony wants to register successfully, it is necessary to have an additional factor different from that of the user Kevin, so that even if the same login name body and login password are provided during the login process, the account can be matched based on the login additional factor. Specifically, when there are a plurality of account records corresponding to 18611180751, the login passwords need to be compared one by one. In the conventional scheme, because 18611180751 the login name body does not exist in two account records, 18611180751 is used in the searching process to search for one account record, but the password is not matched, the searching is immediately exited to prompt login failure, and in this case, the traversal process is continued until all login passwords in account records corresponding to 18611180751 are not matched, and the user login failure is determined; and when the login password is matched with a plurality of accounts again, the traversal needs to be continued according to the login additional factors, and the user login failure is determined until all the login additional factors in the account records corresponding to 18611180751 are not matched.

Based on the above login mechanism, when the current user requesting registration is a new conflicting user (e.g. Tony) corresponding to the old conflicting user, the application guides Tony to use a different login additional factor than Kevin of the old conflicting user during the registration process. There are various types of additional factors that are registered, and the following examples are listed as implementation references. In a preferred embodiment, the login additional factor includes two broad categories, one is a string associated with the user's registration time, and the other is a verification option for identity information verification. Of course, other ways of defining the login cofactors may be used by those of ordinary skill in the art.

a. Character string related to user registration time

In implementation, since it is obviously impossible for two users to perform registration operations using the identical login name ontology and login password at the identical time point, even if there is a case of registration on the same day with a very low probability, it is possible to distinguish different users in terms of registration time by improving the accuracy (for example, to the hour, minute, second, etc.) of the acquired registration time. Therefore, the conventional registration unit may acquire a corresponding registration time when each user performs a normal user registration operation, and generate a login additional factor corresponding to the current user according to the registration time. For example, if the user Kevin completed registration using the login name ontology "18611180751" on 10/23/2009, then "20091023" may be used as the login additional factor corresponding to the user Kevin, and the user Kevin may be prompted to record the login additional factor (i.e., "unique login identification code" shown in the figure) in the manner shown in fig. 3 a.

When a user Tony uses a login name ontology "18611180751" to register in 22 months 2 and 2014, and a special registration unit detects that the login name ontology in the current user Tony registration request is the same as the user Kevin, a login additional factor "20140222" shown in FIG. 3b is generated for the user Tony, and a conflict identification parameter is added in a login name field where the login name ontology of the user Kevin is located. In the registration process, because the addition operation of the conflict identification parameter is completed in the background, and the login additional factor is a process which is inevitably experienced by the user registration process, the registration process and the obtained experience which are experienced by the user Kevin and the user Tony are the same, the difference treatment can not be caused due to the conflict of the login name ontology, the situation that the user Tony realizes that the current login name ontology is used is avoided, and the account safety of both the user Tony and the user Kevin is improved.

Selecting the user registration time to generate a corresponding login additional factor, which is actually convenient for the user to memorize and avoids the phenomenon that the user cannot log in due to forgetting of the login additional factor; in theory, however, as long as it can be ensured that the current user and the conflicting old user correspond to different character strings respectively, the new user and the conflicting old user can be used as the login additional factor of the technical scheme of the application.

Further, when the login-added factor is a character string, instead of using the login-added factor as a separate field in the user-account table (e.g., field three shown in table 2), it may be used as information in the login-name field shown in table 3. When the login additional factor is used as the information in the login name field, the uniqueness of the data in the account database can be realized without introducing conflict identification parameters; of course, the conflict identification parameter can also be used for accurately identifying the old conflicting user, so as to guide the old conflicting user to change the login name ontology of the old conflicting user, and the corresponding login name ontology is handed back to the real owner of the mobile phone number, and the specific process is referred to as a conflict elimination mechanism below.

Serial number	Field one	Field two
				Login name + separator + identifier	Login password
1	13900100110	aaaaaa
			2	18611180751|R20091023	123456
3	18611180751|20140222	123456
			4	13988888888	aaaaaa
……	……	……

TABLE 3

b. Verification options for identity verification

In the registration process, besides the login name body and the login password, which are filled in by the user, the user is required to fill in authentication information, such as: verifying a mailbox, a home address, or checking a question and answer, etc. Each user may fill in one or more pieces of information for authentication, for example, if user Kevin fills in an authentication mailbox and three check answers at the time of registration, the authentication mailbox may be used as a login additional factor (as shown in fig. 3 c), or any one or more of the check answers may be used as a login additional factor (as shown in fig. 3 d).

When a user Tony registers, if the user Tony detects that the user Tony uses a login name ontology which is the same as Kevin of the user, a login additional factor corresponding to the Kevin of the user is obtained, for example, the login additional factor is a check question answer 'favorite movie' and a corresponding answer 'seventh guing' shown in FIG. 3 d; since the questions in the verification question-answering can be selected by the user from a plurality of questions preset by the system, when the user Tony wishes to select the verification question, the question of 'favorite movie' can be shielded, so as to avoid that the user Tony fills in the same answer as the user Kevin; or, because the probability that the answers filled by different users are the same is very low, a shielding measure may not be taken, but when the user Tony actually fills the answer that is the same as the user Kevin, the user Tony is forced to fill more verification questions and answers until different verification questions and answers exist between the user Tony and the user Kevin or different answers exist to the same verification question.

The technical advantages of the present application are illustrated by a preferred embodiment in combination with more applications on the basis of the above embodiments. In the following description, the login name will be exemplified by a mobile phone number. In a scheme close to actual deployment, the following optimization measures are proposed in the application to further improve the implementation effect of the application in actual use, although the measures are not necessary, and how to combine various optimization measures can be flexibly selected according to needs.

On the basis of the above embodiments, the present application may further introduce a collision elimination mechanism. In one embodiment, the present application further includes a conflict resolution mechanism on the basis of steps 201 to 204. The foregoing embodiments solve the registration conflict and login conflict problems. Although there is no problem when two users log in using one mobile phone number at the same time, the mobile phone number is undoubtedly important for the users from the perspective of using application services, such as receiving a check short message. If an application needs to receive a verification short message and backfill the short message on a page, at the moment, because the mobile phone number is owned by one user (such as Tony) at the same time, another user (such as Kevin) cannot receive the verification short message of the other user at the moment. The method comprises the steps that the user login name is checked to see whether a conflict identification parameter is included in the user login name or not under the condition that the user login is successful, if yes, the login management unit further pushes a mobile phone number modification interface to guide an old user in conflict to modify the mobile phone number, the mobile phone number is updated in a corresponding account record after the new mobile phone number input by the user is received, and when the user logs in again, the new mobile phone number is required to be used as a login name body to log in. In a specific implementation, after the user inputs a new mobile phone number, the login management unit usually further initiates a check on the mobile phone number, for example, sends a check short message including a check code to the new mobile phone number, and compares whether the check code submitted by the user on the interface is correct to determine whether the user really owns the mobile phone number.

There may still be a special case where the conflicting old user modifies the phone number as directed. Assuming that the mobile phone number input by the user Kevin is still 18611180751, and is consistent with the original mobile phone number, and is not a new mobile phone number, at this moment, the system cannot determine that Kevin or Tony has the mobile phone number at the end. One simple way to do this is that Kevin must change the phone number, otherwise it is not allowed to continue logging in. However, in fact, there may be only temporary use of the mobile phone number of Kevin by Tony, and Kevin is the true owner of the mobile phone number, please refer to fig. 4, for which, in a more complete embodiment, the process of guiding the user to modify the mobile phone number includes the following steps:

step 401, the login management unit checks whether the login name field of the user account record includes a conflict identification parameter under the condition that the current user login is successful; if yes, sending a login name body modification interface to the user to guide the user to modify the login name body;

step 402, a special registration unit acquires a login name body input by a current user through a login name body modification interface, searches whether a new conflict user using the login name body exists in an account table, if not, updates the login name body in the current user account record, if so, determines a login additional factor corresponding to the new conflict user, enables the current user to adopt a login additional factor different from the new conflict user, and adds a conflict identification parameter in the login name field of the new conflict user to enable the new conflict user to become an old conflict user; and eliminating the conflict identification parameters in the login name field of the current user account record.

Still taking user Kevin and user Tony as an example, assuming that user Kevin is an old user in conflict, the mobile phone number submitted on the login name modification interface by user Kevin is indeed changed, for example, to 18611223344, at this time, according to the processing in steps 401 to 402, there will be no conflict between user Kevin and user Tony, the login name of user Kevin will become a uniquely used mobile phone number, and at this time, the account table will be updated from table 2 to the example in table 4.

Serial number	Field one	Field two	Field three
					Login name + separator + identifier	Login password	Login additional factor
1	13900100110	aaaaaa	20100605
				2	18611223344	123456	20091023
3	18611180751	123456	20140222
				4	13988888888	aaaaaa	20101010
……	……	……	……

TABLE 4

However, assuming that the mobile phone number entered by the user Kevin is still 18611180751, it means that the user Kevin indicates to the system that he owns the mobile phone number, and at this time, the system cannot determine whether Kevin or Tony owns the mobile phone number at all. The system can therefore initiate a check to the user before step 402, and if the check is successful, the check process will not be described in detail and can be performed with reference to the prior art. Kevin will become the conflicting new user at this point, and Tony will change from the conflicting new user to the conflicting old user. Table 2 will now be updated to the example of table 5. The design can well solve the problem of 'pseudo secondary number allocation', and the real secondary number allocation is changed by a host of the mobile phone number. The pseudo secondary number allocation is that secondary number allocation is generated through the cross use of the mobile phone numbers, and the application system considers that the secondary number allocation occurs due to the cross use. For example, Kevin is the real owner of 18611180751 who has registered with the mobile phone number at the payer, and the payer system has an account record. Tony is a brother of Kevin, and under some special or temporary application requirements, Tony temporarily registers a Payment treasure account by using a mobile phone number of Kevin, and the process triggers the processing of steps 201 to 204, which causes Kevin to become a conflict old user in a Payment treasure system, and Tony becomes a conflict new user through a "robbing" behavior. When the Kevin logs in again, the system sends a login name modification interface for the conflicting old user Kevin step 401 directing the Kevin to modify the phone number, which may still have entered 18611180751 since the Kevin is 18611180751 a true owner. The system can think that Kevin executes the anti-robbing operation, the anti-robbing behavior of Kevin is verified through the check short message, if the anti-robbing behavior of Kevin passes the check short message, the Kevin is changed into a new conflict user, and Tony is changed into an old conflict user. And when Tony logs in again, the system still guides Tony to modify the mobile phone number through a login name modification interface. If Tony modifies its phone number, such as to 18622223333, then the conflict will disappear.

Serial number	Field one	Field two	Field three
					Login name + separator + identifier	Login password	Login additional factor
1	13900100110	aaaaaa	20100605
				2	18611180751	123456	20091023
3	18611180751|R	123456	20140222
				4	13988888888	aaaaaa	20101010
……	……	……	……

TABLE 5

With continued reference to fig. 5, based on the processing mechanism of step 204, the present application may further provide a mechanism for the user to create an independent sub-account having an association relationship with the primary account. Suppose that the mobile phone number of the user Jack is 13988888888, Jack uses the mobile phone number to register a pay bank account Jack1, which is used by Jack to purchase office supplies for own company, but also hopes that Jack can register another pay bank account Jack2 with the mobile phone number and then use the account Jack2 to purchase private supplies for itself, so that company purchasing and personal consumption can be clearly distinguished. In the conventional art, such user demands cannot be satisfied. In the application, when a current user successfully logs in through a current account (set as a main account) and then receives a sub-account creation request sent by the user, a special registration unit pushes a login additional factor different from the current login account to the user to serve as a login additional factor corresponding to the sub-account, creates the sub-account based on a login name body of the current login account, a login password and the login additional factor corresponding to the sub-account, and adds an associated identification parameter in a login name field of the sub-account. Referring to the example of table 6, in the present embodiment, the character "T" is used as the association identification parameter. After the sub-account is successfully created, Jack can log in two accounts by using '13988888888' as a login name, the main account of Jack1 can be logged in by inputting the login additional factor 20101010, and the sub-account can be logged in by inputting the login additional factor 20121212.

Serial number	Field one	Field two	Field three
					Login name + separator + identifier	Login password	Login additional factor
1	13900100110	aaaaaa	20100605
				2	18611180751|R	bbbbbb	20091023
3	18611180751	cccccc	20140222
				4	13988888888	aaaaaa	20101010
5	13988888888|T	aaaaaa	20121212
				……	……	……	……

TABLE 6

On the basis of the above embodiment, the present application further considers the processing mechanism of password recovery. In a preferred mode, the user management apparatus further includes a password retrieving unit, where the password retrieving unit, when receiving a password retrieving request from a user, checks whether a login name body used by the user corresponds to a plurality of account records in an account table, and if so, sends an additional factor verification interface to the user, where the additional factor verification interface is used for the user to fill in a character string as a login additional factor, or displays verification options corresponding to the plurality of account records, and after determining that the login additional factor corresponding to any one account is successfully verified, sends a password resetting interface corresponding to the account to the current user; and if the login additional factor is a verification option, each verification option is a verification option irrelevant to the login name.

Assuming that any one of Tony and Kevin forgets its own password, it will initiate a password recovery request on the corresponding page. If the implementation is conventional, the user may need to fill in his/her own mobile phone number on the interface, but since the mobile phone number 18611180751 is used by both Tony and Kevin, the application system cannot determine which user is requesting to retrieve the password at this time. In order to avoid the mobile phone number, one way to deal with this problem is that Tony or Kevin can be handled by manual customer service, but this affects the user experience.

In the present application, the password recovery unit does not verify the password by sending a short verification message to 18611180751, because it may happen that Tony resets the password of Kevin, or Kevin resets the password of Tony. In this application, as an exemplary embodiment, if the login additional factor is a character string, please refer to the example in fig. 5, and the password retrieving unit generates the login additional factor corresponding to the user input on the additional factor verification interface, since each user only knows the login additional factor of the user, and the login additional factors of Tony and Kevin are different (it is ensured that the login additional factors of Tony and Kevin are different at the time of registration), the real identity of the current user can be identified according to the login additional factor input by the user.

As another exemplary embodiment, if the login additional factor is a verification option for identity information verification, referring to the embodiment of fig. 6, the password recovery unit generates an additional factor verification interface including verification options corresponding to both of Tony and Kevin users, and sends the additional factor verification interface to the current user. In practice, these check options may be placed in a pull-down menu, since each user typically knows his or her own check option (e.g., password question or combination of password questions). Considering that a few users still forget what the password problem set by themselves is, in an optimized scheme closer to the user experience, the additional factor verification interface includes a verification sub-interface corresponding to the user account, the verification option of each user is in the respective sub-interface, and the verification option in each sub-interface may be one or more. At this time, the current user can select to complete verification on any one of the verification sub-interfaces. For the same reason, for the main account and the sub account using one mobile phone number, the above procedure may be adopted for the password recovery processing.

Assume that the left syndrome boundary corresponds to Tony and the right syndrome boundary corresponds to Kevin. At this time, if the user is Tony, he or she will complete the check options of "mother birthday" and "father birth place" on the left check-sub interface, because the check option in the right check-sub interface is not Tony, and Tony is generally not able to be completed. On the contrary, if the user is Kevin, the user will complete the verification option consisting of two password problem combinations of "who is the primary school third class of class owner" and "favorite movie" on the right verification sub-interface, and of course, the verification option may be other verification methods besides the password problem or the password problem combination, and the present application is not limited thereto. In fact, the verification options of multiple login name conflict users are listed in a classified manner under the same interface, and the mode does not generally affect the current user to retrieve the password through the operation of the verification options. In fact, as long as the user operates the verification option under any one of the verification sub-interfaces and the verification is successful, the system knows that the account of the current user is recorded at this time.

As previously mentioned, in the present application, the login name field of each user in the account table may include a conflict identification parameter or an association identification parameter, first, the two parameters do not conflict. Referring to the example of table 7, for the flow process of the application system, the character selection and the corresponding position of two parameters are defined. For example, the collision recognition parameter selection character "R" is positioned on the right side of the delimiter "|", and the associated recognition parameter selection character "T" is positioned on the right side of the collision recognition parameter "R"; of course, those skilled in the art can also adopt other data format defining modes according to the requirements of actual service applications. Secondly, considering that in the case of a very small number, three times of number allocation may occur, or when the system allows a user to create a plurality of associated sub-accounts based on one main account, such very special requirements cannot be met only by one conflict recognition parameter (of course, such a requirement system may not support). To meet this particular requirement, a string of random numbers comprising a plurality of characters may be added after the identification parameter. Referring to the example of table 7, in a preferred embodiment, for development convenience, an identification parameter may also be introduced for a regular account (not a conflicting old user, nor a sub-account), such as a normal account represented by the character "a". "13900100110 | A987688 ab" in Table 7 characterizes a conventional account; whereas "18611180751 | Rktttdihs" characterizes a conflicting old user. "13988888888 | RT0208 adkz" characterizes a conflicting old user, while the user's account is a sub-account of other user accounts.

Serial number	Field one	Field two	Field three
					Login name + separator + identifier	Login password	Login additional factor
1	13900100110|A987688ab	aaaaaa	20100605
				2	18611180751|Rkttdihss	123456	20091023
3	18611180751|Aktsd098	123456	20140222
				4	13988888888|R36derdd	aaaaaa	20101010
5	13988888888|RT0208adkz	dddddd	20121212
				6	13988888888|RT4654sdfg	eeeeee	20121215
7	13988888888|A4756lkj	ffffff	20140302
				……	……	……	……

TABLE 7

Alternatively, as shown in table 8, when the login-added factor is a character string, the login-added factor may be directly used as a part of the login-name field, and a plurality of accounts having the same login-name body may be similarly distinguished. "13988888888 | R20101010" in Table 8 characterizes a conflicting old user; "13988888888 | RT 20121212" characterizes a conflicting old user, and the user's account is the subaccount of "13988888888 | R20101010"; "13988888888 | RT 20121215" characterizes a conflicting old user, and the user's account is also a child account of "13988888888 | R20101010"; "13988888888 | A20140302" then characterizes a conventional account.

Serial number	Field one	Field two
				Login name + separator + login additional factor	Login password
1	13900100110|A20100605	aaaaaa
			2	18611180751|R20091023	123456
3	18611180751|A20140222	123456
			4	13988888888|R20101010	aaaaaa
5	13988888888|RT20121212	dddddd
			6	13988888888|RT20121215	eeeeee
7	13988888888|A20140302	ffffff
			……	……	……

TABLE 8

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The above description is only exemplary of the present application and should not be taken as limiting the present application, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the scope of protection of the present application.

Claims (20)

1. A user account management device applied to a server comprises: the system comprises a preposed checking unit, a conventional registration unit, a special registration unit and a login management unit, and is characterized in that:

the system comprises a preposed checking unit, a login name body and an account table, wherein the preposed checking unit is used for acquiring the login name body in a registration request of a current user and searching whether a conflict old user using the login name body exists in the account table; if yes, processing by a special registration unit; the special registration unit is used for acquiring the login additional factor corresponding to the conflict old user and generating a login additional factor different from the conflict old user for the current user; when the user registration is successful, creating an account record in an account table based on the login additional factor corresponding to the current user and the login name body and the login password in the user registration request;

the login management unit is used for acquiring a login name body and a login password in the current user login request and searching whether a matched account record exists in an account table; if a plurality of matched account records exist, an additional factor verification interface is sent to the user, and the user is allowed to log in the corresponding account after the login additional factor corresponding to any account is verified successfully; if the uniquely matched account record exists, allowing the user to log in the account; if not, the user is refused to log in.

2. The apparatus of claim 1, wherein: wherein

The special registration unit is also used for introducing conflict identification parameters into the login name field where the login name body of the conflict old user is located;

the login management unit is also used for checking whether the login name field of the user account record contains a conflict identification parameter under the condition that the current user logs in successfully; and if so, sending a login name ontology modification interface to the user to guide the user to modify the login name ontology.

3. The apparatus of claim 2, wherein: wherein

The special registration unit is also used for acquiring a login name body input by a current user through a login name body modification interface, searching whether a conflict old user using the login name body exists in an account table, if not, updating the login name body in the account record of the current user, if so, determining a login additional factor corresponding to the conflict old user, enabling the current user to adopt a login additional factor different from the conflict old user, and adding a conflict identification parameter in the login name field of the conflict old user; and eliminating the conflict identification parameters in the login name field of the current user account record.

4. The apparatus of claim 1, wherein:

the login additional factor is a character string or a verification option for identity information verification.

5. The apparatus of claim 4, wherein:

in the case where the login-added factor is a character string, the character string is associated with a user registration time.

6. The apparatus of claim 4 or 5, wherein:

and under the condition that the login additional factor is a character string, the login additional factor is positioned in a login name field where the corresponding login name body is positioned.

7. The apparatus of claim 4, wherein:

and under the condition that the login additional factor is a check option, the special registration unit is further used for displaying a preset check question to be selected to the current user and generating a corresponding login additional factor according to the check question selected by the current user and the filled check answer, wherein the check question to be selected does not contain the check question selected by the conflicting old user.

8. The apparatus of claim 1, further comprising:

and the conventional registration unit is used for generating a login additional factor corresponding to the current user when the pre-checking unit does not find the conflicted old user using the login name body in the registration request of the current user, and creating an account record for the user in the account table based on the login additional factor, the login name body in the registration request and the login password.

9. The apparatus of claim 1, further comprising:

and the password recovery unit is used for checking whether the login name body used by the user corresponds to a plurality of account records in the account table when a password recovery request of the user is received, if so, sending an additional factor verification interface to the user, and sending a password resetting interface corresponding to the account to the current user after the login additional factor corresponding to any account is successfully verified.

10. The apparatus of claim 1, wherein:

the special registration unit pushes a login additional factor different from the current login account to the user to serve as the login additional factor corresponding to the sub-account when receiving a sub-account creation request sent by the user after the user successfully logs in, and creates the sub-account based on the login name body, the login password and the login additional factor corresponding to the sub-account of the current login account; and adding the associated identification parameters in the login name field of the sub-account.

11. A user account management method is applied to a server and is characterized by comprising the following steps:

acquiring a login name body in a registration request of a current user, and searching whether a conflict old user using the login name body exists in an account table;

if the conflict old user using the login name ontology exists, acquiring a login additional factor corresponding to the conflict old user, and generating a login additional factor different from the conflict old user for the current user; when the user registration is successful, creating an account record in an account table based on the login additional factor corresponding to the current user and the login name body and the login password in the user registration request;

acquiring a login name body and a login password in a current user login request, and searching whether a matched account record exists in an account table; if a plurality of matched account records exist, an additional factor verification interface is sent to the user, and the user is allowed to log in the corresponding account after the login additional factor corresponding to any account is verified successfully; if the uniquely matched account record exists, allowing the user to log in the account; if not, the user is refused to log in.

12. The method of claim 11, further comprising:

introducing conflict identification parameters into the login name field where the login name body of the conflict old user is located;

under the condition that the current user logs in successfully, checking whether a login name field of the user account record contains a conflict identification parameter; and if so, sending a login name ontology modification interface to the user to guide the user to modify the login name ontology.

13. The method of claim 12, further comprising:

acquiring a login name body input by a current user through a login name body modification interface, searching whether a conflict old user using the login name body exists in an account table, if not, updating the login name body in the account record of the current user, if so, determining a login additional factor corresponding to the conflict old user, enabling the current user to adopt a login additional factor different from the conflict old user, and adding a conflict identification parameter in a login name field of the conflict old user; and eliminating the conflict identification parameters in the login name field of the current user account record.

14. The method of claim 11, wherein:

the login additional factor is a character string or a verification option for identity information verification.

15. The method of claim 14, wherein:

in the case where the login-added factor is a character string, the character string is associated with a user registration time.

16. The method of claim 14 or 15, wherein:

and under the condition that the login additional factor is a character string, the login additional factor is positioned in a login name field where the corresponding login name body is positioned.

17. The method of claim 14, wherein:

and under the condition that the login additional factors are check options, displaying preset check problems to be selected to the current user, and generating corresponding login additional factors according to the check problems selected by the current user and the filled check answers, wherein the check problems to be selected do not include the check problems selected by the conflicting old users.

18. The method of claim 11, further comprising:

and if the conflict old user using the login name body in the registration request of the current user does not exist, generating a login additional factor corresponding to the current user, and creating an account record for the user in an account table based on the login additional factor, the login name body in the registration request and the login password.

19. The method of claim 11, further comprising:

when a user password retrieval request is received, whether a login name body used by the user corresponds to a plurality of account records is checked in an account table, if yes, an additional factor verification interface is sent to the user, and after the login additional factor corresponding to any account is verified successfully, a password resetting interface corresponding to the account is sent to the current user.

20. The method of claim 11, further comprising:

when a sub-account creation request sent by a user is received after the user successfully logs in, pushing a login additional factor different from the current login account to the user to serve as a login additional factor corresponding to the sub-account, and creating the sub-account based on a login name body, a login password and the login additional factor corresponding to the sub-account of the current login account; and adding the associated identification parameters in the login name field of the sub-account.